Author: Laurent Bercot Date: To: dng Subject: Re: [DNG]
The show goes on: “su” command replacement merged into systemd on Fedora Rawhide
On 31/08/2015 20:56, Tobias Hunger wrote: > Oh, I am pretty happy with systemd and won't lie about that. I would
> still like to see some competition going.
That's pretty much the crux of the problem here. Nothing can compete
with systemd on the same grounds, because systemd covers so much ground
and does so many things (that *it should not* be doing) that any good
engineer who wants to design an alternative will see a lot of insane
features and immediately say "Nope, I'm not doing that, it's not the
init system's job"; and systemd proponents will always answer "See?
systemd is the only one that does that stuff, and all the competition
is inferior".
Even where competition *can* happen, systemd likes to fudge the odds.
For an example that I know because I had to deal with it not long ago:
the sd_notify() protocol was made so that a process' supervisor has to
be listening on a Unix domain socket, which ultimately favors the model
where the supervisor for all the daemons is a single program performing
all the service management tasks: so in order to implement a server for
sd_notify, you basically have to adopt the systemd monolithic architecture,
which means, in essence, rewrite systemd - and, obviously, no sane
person wants to do that.
So by this single design choice, systemd ensures that it's the only
service manager that can actually implement sd_notify. And systemd
enthusiasts actively try to make daemon authors use sd_notify, saying
"Oh, but it's a good notification protocol; and the protocol is free,
and it's all open source, so people who want to write an alternative
server are free to do so!" with a bright smile and big, innocent
eyes; but it's nothing short of misleading and dishonest.
systemd does not play fair by *any* measure; the only way to provide
healthy competition is to ignore everything it's doing, and design
a sane, Unixish init system, as well as sane, Unixish administrative
tools, from the ground up.
I'm working on it with s6-rc. Jude is working on the udev system
with vdev. Other people are working on the other parts of the Linux
userspace that systemd would love to phagocyte. And we are not
getting the kind of money or resources that the systemd lead
developers are, so it's a longer, harder task; but don't worry, the
competition exists and is getting better everyday.