Re: [DNG] Mixing different init benefits: was: without-systemd.org not working
On Wed, May 27, 2020 at 08:29:05PM -0400, Steve Litt wrote: > On Tue, 26 May 2020 17:51:20 +0200 > Didier Kryn wrote: > > > Le 26/05/2020 à 10:26, Steve Litt a écrit : > > > On Mon, 25 May 2020 10:08:17 -0700 > > > Ian Zimmerman wrote: > > > > > >> On 2020-05-21 14:09, Steve Litt wrote: > > > > > > Thanks for pointing out Shepherd. > > > > > +1. > > > > Questions and remarks: > > > > How much can one trust a program written in the Guile language and > > running as PID1 as suggested? > > My experimentations with Guile > ( http://troubleshooters.com/codecorn/scheme_guile/index.htm ) produced > no results indicating any kind of intermittent or unexpected behavior > in Guile. > > Guile is pure functional programming: With a few eceptions (like > printing), there is no state and no side effects. Loops are done with > recursion, best done with tail recursion. There is a purity of function > unavailable from OOP bolt-ons like C++, Perl, and to a lesser extent > Python. Anyone understanding recursion, functional programming and > lambdas can handle Guile, at least for reasonably simple code. As long > as the Guile interpreter is available on a mounted drive in early boot, > I see no reason for caution about Guile. Guile is an implementation of Scheme. While the functional style of programming us the most common style there, it certaionly does have imperative features for when you need them. It is functional, which I think is a good thing. It's not dogmatically purely functional, which I also think is a good thing. -- hendrik > > I think 80% of us grew up with Procedural or OOP languages and are > familiar with them. Just like OOP requires different thought patterns > than procedural, functional languages require (much) different thought > patterns than Procedural or OOP. So Guile might prove a challenge to > some, not because it's defective or complex in any way, but because > functional programming requires much different thought patterns. > > SteveT > > Steve Litt > May 2020 featured book: Troubleshooting Techniques > of the Successful Technologist > http://www.troubleshooters.com/techniques > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Mixing different init benefits: was: without-systemd.org not working
On Tue, 26 May 2020 17:51:20 +0200 Didier Kryn wrote: > Le 26/05/2020 à 10:26, Steve Litt a écrit : > > On Mon, 25 May 2020 10:08:17 -0700 > > Ian Zimmerman wrote: > > > >> On 2020-05-21 14:09, Steve Litt wrote: > > Thanks for pointing out Shepherd. > > > +1. > > Questions and remarks: > > How much can one trust a program written in the Guile language and > running as PID1 as suggested? My experimentations with Guile ( http://troubleshooters.com/codecorn/scheme_guile/index.htm ) produced no results indicating any kind of intermittent or unexpected behavior in Guile. Guile is pure functional programming: With a few eceptions (like printing), there is no state and no side effects. Loops are done with recursion, best done with tail recursion. There is a purity of function unavailable from OOP bolt-ons like C++, Perl, and to a lesser extent Python. Anyone understanding recursion, functional programming and lambdas can handle Guile, at least for reasonably simple code. As long as the Guile interpreter is available on a mounted drive in early boot, I see no reason for caution about Guile. I think 80% of us grew up with Procedural or OOP languages and are familiar with them. Just like OOP requires different thought patterns than procedural, functional languages require (much) different thought patterns than Procedural or OOP. So Guile might prove a challenge to some, not because it's defective or complex in any way, but because functional programming requires much different thought patterns. SteveT Steve Litt May 2020 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Mixing different init benefits: was: without-systemd.org not working
On 2020-05-26 17:51, Didier Kryn wrote: > Did it exist prior to the creation of Systemd? I think it depends on how you count. There was a predecessor project called dmd which was created to be PID 1 on Hurd. If you count dmd then it precedes systemd, otherwise not. -- Ian ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Mixing different init benefits: was: without-systemd.org not working
Le 26/05/2020 à 10:26, Steve Litt a écrit : > On Mon, 25 May 2020 10:08:17 -0700 > Ian Zimmerman wrote: > >> On 2020-05-21 14:09, Steve Litt wrote: >> >>> * Busybox init >>> * Epoch >>> * OpenRC >>> * Runit >>> * s6 (plus s6-rc) >>> * Suckess init plus [daemontools | runit | s6] >>> * systemd >>> * sysvinit >> * GNU Shepherd ? >> >> https://www.gnu.org/software/shepherd/ > The preceding looks like an extremely capable init system that will > handle almost any situation, assuming the admin has the skill to make > it so. It seems to enable one to do tons of things that runit doesn't > facilitate. > > On the other hand, GNU Shepherd makes me realize how easy runit is to > administer. I can do it in my sleep. > > If anyone does a Jitsi presentation on GNU Shepherd, I'd *really* like > to be in the audience. This looks potentially like a very high quality > init, probably for the kind of person with lots of tricky daemons to > administer. > > Thanks for pointing out Shepherd. > +1. Questions and remarks: How much can one trust a program written in the Guile language and running as PID1 as suggested? Note it does not seem mandatory to run it as PID1. It being an official GNU product makes it deserve a try a priori. Did it exist prior to the creation of Systemd? Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Mixing different init benefits: was: without-systemd.org not working
On 2020-05-26 03:26, Steve Litt wrote: On Mon, 25 May 2020 10:08:17 -0700 Ian Zimmerman wrote: On 2020-05-21 14:09, Steve Litt wrote: > * Busybox init > * Epoch > * OpenRC > * Runit > * s6 (plus s6-rc) > * Suckess init plus [daemontools | runit | s6] > * systemd > * sysvinit * GNU Shepherd ? https://www.gnu.org/software/shepherd/ The preceding looks like an extremely capable init system that will handle almost any situation, assuming the admin has the skill to make it so. It seems to enable one to do tons of things that runit doesn't facilitate. On the other hand, GNU Shepherd makes me realize how easy runit is to administer. I can do it in my sleep. If anyone does a Jitsi presentation on GNU Shepherd, I'd *really* like to be in the audience. This looks potentially like a very high quality init, probably for the kind of person with lots of tricky daemons to administer. Thanks for pointing out Shepherd. SteveT FWIW, Shepherd has been on the Devuan beta website's init freedom page for some time: https://beta.devuan.org/os/init-freedom golinux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Mixing different init benefits: was: without-systemd.org not working
On Mon, 25 May 2020 10:08:17 -0700 Ian Zimmerman wrote: > On 2020-05-21 14:09, Steve Litt wrote: > > > * Busybox init > > * Epoch > > * OpenRC > > * Runit > > * s6 (plus s6-rc) > > * Suckess init plus [daemontools | runit | s6] > > * systemd > > * sysvinit > > * GNU Shepherd ? > > https://www.gnu.org/software/shepherd/ The preceding looks like an extremely capable init system that will handle almost any situation, assuming the admin has the skill to make it so. It seems to enable one to do tons of things that runit doesn't facilitate. On the other hand, GNU Shepherd makes me realize how easy runit is to administer. I can do it in my sleep. If anyone does a Jitsi presentation on GNU Shepherd, I'd *really* like to be in the audience. This looks potentially like a very high quality init, probably for the kind of person with lots of tricky daemons to administer. Thanks for pointing out Shepherd. SteveT Steve Litt May 2020 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Mixing different init benefits: was: without-systemd.org not working
On 2020-05-21 14:09, Steve Litt wrote: > * Busybox init > * Epoch > * OpenRC > * Runit > * s6 (plus s6-rc) > * Suckess init plus [daemontools | runit | s6] > * systemd > * sysvinit * GNU Shepherd ? https://www.gnu.org/software/shepherd/ -- Ian ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Mixing different init benefits: was: without-systemd.org not working
(Apologies for restating that - I thought that my original mention of it hadn't made the list for some reason. I now see that it did.) On Fri, 2020-05-22 at 10:19 +0100, Peter Duffy wrote: > (There's a brilliant moment in "The Taking of Pelham 123" ... ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Mixing different init benefits: was: without-systemd.org not working
I know about uselessd - I suspect that it was reading about it that planted the seed for the "init-wrapper" idea - that of limiting systemd's power without systemd even being aware that it was being limited. I've not got far in thinking this through in terms of details - I assumed that it would be impossible to implement in a practical sense, and anyway the idea was just too crazy to be taken seriously. If I did contemplate doing it, first thoughts would be on the lines of modified libraries which would pre-empt existing ones. I agree that the value of this would increase substantially if the abstraction/glue layer was viewed as a general init system monitoring/controlling/auditing facility - it did occur to me that it would be a way of distilling out the best of all the init systems to which it was exposed. Just supposing that this led anywhere, I certainly wouldn't propose proactively keeping the systemd team updated re. progress. Obviously, given that it would presumably be an open-source project, they'll find out anyway - but if they can't see the obvious win-win from making systemd optional, they're not going to see the benefits of a project which could conceivably control and limit systemd's power and influence (both in terms of individual systems and the linux community as a whole). Thinking about systemd, and choosing whether to do what it asked and what to report back, the image which kept coming to mind (can't imagine why ;) ) was that of a convicted gangster controlling the mob from a prison cell - but he or she is completely at the mercy of feedback received, and has no way of knowing what is actually taking place. (There's a brilliant moment in "The Taking of Pelham 123". They're trying to get the money to the subway station before any more hostages get shot, and aren't going to make the deadline. Garber, the train dispatcher, suddenly realises that the crooks can't know what's happening on the surface, and tells them that the money's arrived before it actually does.) On Thu, 2020-05-21 at 14:09 -0400, Steve Litt wrote: > On Thu, 21 May 2020 10:59:15 +0100 > Peter Duffy wrote: > > > I think that the thing that I found tantalising was the idea of > > sniffing what systemd tried to do, and then deciding whether or not > > to do it, > > Many have tried this. Web search "uselessd". > > But your suggestion becomes much more valuable if expressed as > "sniffing what each init system tried to do, and then deciding whether > or not to do it". > > * Busybox init > * Epoch > * OpenRC > * Runit > * s6 (plus s6-rc) > * Suckess init plus [daemontools | runit | s6] > * systemd > * sysvinit > > > and what responses to send back to systemd. > > If you mean the daemon reports back to the process supervisor success > or failure, s6 has that now, in a much simpler form than systemd's > dbus-centered bizarro. And such reporting isn't all that necessary > because the admin can roll his own tests. > > If you mean do this research and report the research results back to > the systemd project, I'm not interested in helping systemd, and systemd > isn't interested in anything making them more interoperative. > > SteveT > > Steve Litt > May 2020 featured book: Troubleshooting Techniques > of the Successful Technologist > http://www.troubleshooters.com/techniques > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Mixing different init benefits: was: without-systemd.org not working
On Thu, 21 May 2020 10:59:15 +0100 Peter Duffy wrote: > I think that the thing that I found tantalising was the idea of > sniffing what systemd tried to do, and then deciding whether or not > to do it, Many have tried this. Web search "uselessd". But your suggestion becomes much more valuable if expressed as "sniffing what each init system tried to do, and then deciding whether or not to do it". * Busybox init * Epoch * OpenRC * Runit * s6 (plus s6-rc) * Suckess init plus [daemontools | runit | s6] * systemd * sysvinit > and what responses to send back to systemd. If you mean the daemon reports back to the process supervisor success or failure, s6 has that now, in a much simpler form than systemd's dbus-centered bizarro. And such reporting isn't all that necessary because the admin can roll his own tests. If you mean do this research and report the research results back to the systemd project, I'm not interested in helping systemd, and systemd isn't interested in anything making them more interoperative. SteveT Steve Litt May 2020 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
