Web lists-archives.com

Re: If Linux Is About Choice, Why Then ...

Le nonidi 19 germinal, an CCXXV, tomas@xxxxxxxxxx a écrit :
> So we always had multi-user: the trend is rather the other way:
> since everyone has his/her own gadget, complex things like desktop
> environments tend to do silly things spoiling the multi-user roots
> of UNIX.

We agree on that.

> Note that I'm a decided systemd opponent, and that might shine
> through the above. Feel free to correct any misrepresentation.

I would not have guessed. But you forgot a very important information:
what are you a PROponent of? A lot of people are only opponents, and
very vocal ones, and discussing with them is usually useless; I have
seen the symptoms on this very list. Being an opponent is easy,
everything has flaws that can be attacked; being a proponent is harder.

Now, back to the discussion at hand, namely a comparison between systemd
and the SysV init system:

> Personally I find SysV ugly, but in ways which could be made better.
> What systemd brings (mainly[1]) to the table is the decoupling of
> different "parts" of init: just imagine you have one service (let's
> say a web server) which depends on some other thing (say a file
> system being present via ummm... NFS, but it could be a RAID or a
> memory stick, you get the idea). With a SysV init you can't express
> that: you would have to script it explicitly. With systemd you
> can express that the web server is only to be started once that
> file system appears.
> So I'd rather say systemd is an adaptation to a much more volatile
> hardware landscape (which previously was only known in big iron)
> comming to the masses these days (just think USB). It corresponds
> to a more "dynamic" configuration.

This is true, and IMHO a balanced way of expressing things. But you
forgot a very important side to the question, that IMHO makes SysV init
unsalvageable: the init program, the one running as PID 1, itself.

With the SysV init system, the init program is stupid: it starts the
master script that spawns all the individual init scripts, it reaps its
children dutifully, but it does not keep track of anything beyond a
single 3-bits piece information called "runlevel".

Well, that is not entirely true: the init program can keep track of a
few specific children, defined in /etc/inittab with the "respawn"
keyword. But this feature is so limited and fragile that I have only
seen used to respawn gettys.

So, imagine you have an init script that starts, say, Apache httpd:
httpd double-forks and is adopted by PID 1. At some points later, the
httpd process exits; PID 1 reaps it, and that is all. Did it crash? Was
it stopped by the sysadmin? Is it completely stopped, or is there still
a mad subprocess running and monopolizing port 80? Nobody knows.

On the other hand, systemd keeps track. When httpd is started, systemd
knows "this is the httpd main process". Even better, it keeps track of
all the subprocesses started by it. If the main process exits, systemd
detects the return code, detects whether it is a crash or an explicit
shutdown, and logs it accordingly.

This makes a huge difference.

Of course, a lot of other init systems came along to try and address
that particular issue: daemontools, upstart, runit, etc. I have not
examined all of them very closely, but I am quite sure that any of them
is hugely better than SysV init.

But the arguments to compare them with systemd are not all the same.
That is why knowing what you are a proponent of is so important.

As far as I know, systemd is the one that makes the most use of the new
mutant powers of the Linux kernel: cgroups, namespaces... That makes the
whole thing more complicated, but that is what makes it possible to
implement certain features. For example, I have mentioned keeping track
of all the subprocess started by a daemon: I do not know if that would
have been possible without cgroups.

And of course, there are non-technical considerations. If there is a
technically awesome program but nobody uses it, maybe it is more
efficient to choose a slightly-less-awesome program for which
integration is already done and help is easier to find. That may not be
fully satisfactory, but not all battles are worth fighting. This
consideration makes a significant malus for init systems maintained by a
single developer with some help of her or his mailing-list friends. And
a significant bonus for init systems backed by a big corporation, even
if that gives it the awful taste of a corporate program.

On the non-technical side, having a non-obnoxious person as project
leader can definitely be counted as a plus. That is definitely not a
plus in the systemd (nor daemontools) column; I do not know for the


  Nicolas George

Attachment: signature.asc
Description: Digital signature