Steve Litt <slitt@???> writes:
> Rainer Weikusat via Dng said on Sun, 05 Mar 2023 19:31:09 +0000
>
>>Steve Litt <slitt@???> writes:
>
>>> There's no such thing as "init". There are many "init systems", but
>>> no such thing as "init".
>>
>>There's absolutely such a thing: init is a UNIX program which has
>>existed since at least 6th edition UNIX
>
> I'm snipping your historical and technical post, which is factually
> correct except you should have said "init system" or PID1 or the name
> of a specific init system, depending on what you were trying to express.
> Using the word "init" as a name of a program is misleading and ambiguous
> because what you're really referring to is either sysvinit, in which
> case that should be stated, or the entire set of init systems, which
> should be stated.

That's something I absolutely disagree with because it's simply
factually wrong. init is a program wich was part of the UNIX codebase
since at least the 6th edition of UNIX. After release of the 7th
edition, it split into two lines of development, a BSD-one and an AT&T
one, the latter eventually turning into the System V init program.

The System V init program is responsible for running gettys on terminal
lines and for initiating so-called run-level changes. What this
precisely means is outside of its scope. All it does in this respect is
execute the script /etc/init/rc with arguments (via environment
variables) specifying the present and the intended runlevel.

A process management system which might be employed by a particular kind
of system which is indirectly driven by init via invocation of a
particular kind of runlevel change script isn't part of init.

> Now let me tell you why I care...
>
> The systemd cabal (poeterpuke's word, not mine) continually used the
> word "init" instead of sysvinit in order to misleadingly imply that the
> only choices were sysvinit or systemd. Sometimes they threw Upstart
> into their propaganda to satisfy those with an IQ over 80.

Actually, they used init instead of "the RedHat process management system
built on top of /etc/init.d/rc" in order to imply that the only way to
get 'proper' process management on Linux was by replacing init and not
by fixing or rewriting all these messy and buggy RedHat scripts,
preferably while creating a set of process management tools supposed to
be used in such scripts in the process. That's a technically perfectly
feasible approach. It's just not particularly suitable for grandstanding
by 'solving' a set of simple problems with hundredthouhsands of lines of
hypercomplicated C code.

The 5355 lines of C code for process management tools I have acquired
since 2009 enable me to do stuff relatively easily systemd can't do at
all. That's why I'm still using them on top of systemd.

> Calling PID1 plus necessary instantiation and daemon management "init"
> enabled them to compare their massively entangled monolith only to
> sysvinit, which is a much easier job than comparing it to runit, s6,
> OpenRC, Busybox Init, and sysvinit PID1 plus [runit | s6 | OpenRC].

Methinks it's more a case of "referring to the Redhat process management
mess created by ... well ... Redhat" as init lead to init being replaced
by an even messier mess also created by RedHat while laying the blame
for the mess on someone else.

I suggest having a look at this:

https://man.freebsd.org/cgi/man.cgi?init

and then meditate some time over the question whether the (typically
highly complicated) "instantiation and daemon management systems" people
- for some unknown - always want to code into init are really necessary.

[...]

> Contrastingly, when you use the phrase "init system" to stand for the
> generic concept of PID1 plus instantiation plus daemon management, your
> meaning is unambigous and does not aid potterpunk's (now microsoft's)
> propaganda efforts.

When I write init I mean init, not some process management system built
on top of it or some process management system with a component which
can be used as replacement init.