In my opinion, this is the best that has been written about init or
supervisor,

(I'm absolutely agree with this)

"There's no need to search for the perfect init or supervisor. Long ago
we got a bunch of them that are all good enough, and can be combined to
fill almost any need. This continuing search for a perfect init is just
wheel spinning, or perhaps an excuse for profit-driven complexification"


the search for the perfect dictator is not the great idea, at least
that's what I think

in the same way that there's not a perfect graphical desktop for all the
people, is sure that there's not a perfect init system for all the
situations in which you can use a computer

the init system must be something that the people can change in an easy
way, and so, choose between different options for different situations

sometimes I think that the people that is focused in develop software
quickly, is the people that search for a perfect init system, so they
can develop fast software

but fast software is like fast food,

I think that freedom is better that fast software


José María Ávila

On 17.04.2017 03:57, Steve Litt wrote:
> On Sun, 16 Apr 2017 19:22:36 -0400
> Hendrik Boom <hendrik@???> wrote:
>
>> On Sun, Apr 16, 2017 at 05:04:18PM -0400, Hendrik Boom wrote:
>> > On Sun, Apr 16, 2017 at 09:59:36PM +0200, Enrico Weigelt, metux IT
>> > consult wrote:
>
>> > > By the way: maybe we should write an RFC draft for the whole
>> > > issue ...
>> >
>> > Looked for a relevant RFC. But found only this:
>> > https://lists.ubuntu.com/archives/kernel-team/2008-December/003628.html
>> > [RFC] [PATCH] notify init daemon when children are reparented to it
>> >
>> > But this doesn't seem to be quite what we want, and I can't say I
>> > have enough context to understand it.
>>
>> That so-calledRFC seems to be very much in the style of
>> requiring the init process to be intimately involved in process
>> supervision actions, which is a strong constraint on what init
>> systems can be chosen. And, I suspect, an init system that is so
>> involved is a potential tool to gradually take over the entire OS, as
>> systemd has done.
>
> And, in fact, being written in 2008, that so called rfc might have been
> either the excuse or the inspiration for systemd.
>
> The "rfc" suffers from a perfectionism related to bikeshedding. Heaven
> forbid there's ever a zombie or a process with a 'T' in the ps status
> field! We simply MUST make a perfect init or supervisor system: Nothing
> less will do. And while we're indulging our perfection, it's important
> to remember that simplicity not be a priority at all. We will remain
> oblivious to the fact that complexity and lack of encapsulation
> creates flaws far worse than the flaws we're moving heaven and earth
> to get rid of. And for gosh sakes, let's forget the facts:
>
> THE FACTS
>
> * sysvinit is perfectly workable for the vast majority of users, or at
> least it was until the systemd people influenced the "upstreams" to
> build in code to fail with sysvinit.
>
> * sysvinit plus daemontools is perfectly workable for almost all users
> who are capable of writing a short run file and creating a symlink.
> Daemontools suffers from none of the problems hand-wrung by the
> "rfc", and indeed in a daemontools world (or at least as a runit
> world which I assume is the same), the only process whose parent is
> PID1 is runsvdir (equivalent of daemontools svscanboot). On my
> computer, the executables reparented to PID1 are all stuff spawned by
> dmenu or UMENU, as well as the gvim executable, which doubleforks
> itself automatically. More on this later...
>
> * sysvinit plus OpenRC is perfectly workable for most users who don't
> want daemon respawning.
>
> * sysvinit plus OpenRC plus daemontools is perfectly workable for users
> who want some daemons respawnable.
>
> * A PID1 consisting of an rc file that somehow respawns the virtual
> terminals, background-runs any daemons necessary, and then ends in a
> loop that listens for and handles signals to PID1, is perfectly
> workable for a person operating a small, special purpose computer. If
> I knew how to respawn virtual terminals I'd do just that as a
> demonstration, but respawning gettys is incredibly difficult: It
> often kills the process that tried to respawn it.
>
> * The 83 line Suckless Init spawning an rc file is perfectly workable
> for someone wanting simplicity and the ultimately simple PID1.
>
> Bottom line, all this bikeshedding perfectionism is unnecessary unless
> you're a big commercial company trying to turn Free Software into a
> cash cow by complexifying it. All the problems were solved long ago, or
> are easily solvable by simple, user space addons needing no
> modification to the likes of sysvinit, daemontools, runit, s6, Epoch,
> OpenRC and the like.
>
> For instance, I have a real problem with zombies and T status processes
> created by my use of dmenu and UMENU. It wouldn't be particularly
> difficult for me to build a userspace daemontools analog, where one
> process parented to PID1 (my analog of svscanboot) would spin around
> listening for commands and/or scripts to run in such a way that IT was
> the parent, or perhaps via analogs of svscan that don't respawn. I
> could then modify dmenu and UMENU to message my daemon in order to run
> commands. Notice the idea in this paragraph requires not one
> modification to whatever "init system" you're using. And it's simple
> enough that even I could implement it, given the time.
>
> There's no need to search for the perfect init or supervisor. Long ago
> we got a bunch of them that are all good enough, and can be combined to
> fill almost any need. This continuing search for a perfect init is just
> wheel spinning, or perhaps an excuse for profit-driven
> complexification.
>
> SteveT
>

> Steve Litt
> April 2017 featured book: Troubleshooting Techniques
>      of the Successful Technologist
> http://www.troubleshooters.com/techniques
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng