[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[Lennart Poettering] Re: A few observations about systemd

Forwarded by permission from the author.

-- Juliusz
--- Begin Message --- 
On Sun, 17.07.11 14:47, Juliusz Chroboczek (jch@pps.jussieu.fr) wrote:

> Dear all,

Wow, you are amazingly badly informed.

> Systemd is bloated.  It apparently attempts to take over the roles of
> init, cron, at, inet, ConsoleKit, sethostname, modprobe, mount -a, and
> probably others.  The result is that you end up running 50000 lines of
> C code as PID 1, as compared to the 8000 lines of SV init or the 6000
> lines of runit.

Seriously?

You have a pretty bogus definition of bloat.

If you want to compare systemd in lines-of-code with sysvinit, then you
need to sum everything up: inetd, the numerous rcS scripts and
even the enourmous duplication that sysv init scripts are. And yes,
systemd will easily win if you do: it will be much shorter.

In fact, a minimal systemd system will win in almost very aspect against
a remotely similarly powerful sysvinit system: you will need much fewer
processes to boot. That means much shorter boot times. That means much
fewer resources. You need a smaller set of packages to built it. It's
fewer lines of code. And yet, it will be much more powerful.

Also, systemd does not "take over the role" of modprobe in any way. I
am not sure where you have that from.

> For a low-level piece of infrastructure, systemd interacts with a lot of
> high-level software; while this might be okay for a workstation running
> Gnome, it makes me wonder whether it will be usable on servers.
> A cursory look shows that systemd intrinsically depends on D-Bus (the
> *desktop* bus) and knows about Plymouth, RedHat's implementation of
> a splash screen.  More on that below.

Oh, come on.

systemd does not depend on Plymouth, it merely interacts with it if it
is around it. Where interaction simply means writing a single message
every now and then to ply to keep it updated how far the boot
proceeded. It's more or a less a single line of text we send over every
now and then in very terse code.

It would be rother strange if we'd spawn a process for this each time
(which would practically double the number of processes we need to spawn
at boot). And even more stupid to spawn a shell script for it (which
would at least triple it).

I am not sure what makes you think D-Bus was only for the "desktop". It
hasn't been for quite some time, as most commercial distros already
shipped Upstart before systemd, which had a hard dependency on it. I
like to think that that "D-Bus" actually stands for "D-Bus Bus", a truly
recursive acronym.

Also, the claim of D-Bus not being useful and unncessary on anything but
the desktop is pure ignorance. Advanced programs need a form of
call-based IPC. Now you have two options: every project can implement
its own IPC, duplicate code, and fuck it up. Or all projects use the
same, powerful one with bindings for all programming languages, that has
been reviewed thoroughly, is well known and hence relatively
secure. Reusing the same code also makes things much smaller, in
contrast to the "bloat" that occurs when everybody implements their own
IPC.

You know, you are welcome to criticise D-Bus for its code or other
qualities. But if you doubt its usefulness or the need for it, then this
reveals more about your nescience than about D-Bus.

> Systemd hard-wires special cases
> --------------------------------
>
> Rather than relying on distribution-specific shell scripts, systemd
> hard-wires much of its behaviour in C code.  The most shocking case,
> already mentioned above, is that systemd interacts with Plymouth.  This
> is not done by using some generic early-boot protocol -- systemd
> contains code that is explicitly meant to communicate with Plymouth, the
> one and only implementation of a splash screen.

Oh god. It's about 30 lines of code, which become NOPs if Plymouth is
not around. it's the simplest scheme thinkable, and debloats the system a
lot (see above).

I see no point in supporting numerous alternative implementations of
splash screens. We gently try to push people to use Plymouth, and only
Plymouth, since it is the sanest implementation around. But that
deosn't mean you have to use it. There is no dependency between the
two. It's just that when you use the combination of systemd and Plymouth
you get the most powerful combination. If you use only one of them
things will still work.

If you find short and minimal code "shocking", then you are easily
shocked. 

I might recommend you a less drastic language though.

> Another case that I've actually been bitten by is that systemd
> hard-wires runlevel 5 in its SV init compatibility code; that's merely
> inflexible under Fedora, but clearly wrong under Debian.  (I've now
> fixed my system to run the exact same initscripts in all four multi-user
> runlevels.)

Simply not true. You can assign legacy runlevels to systemd targets
relatively freely, by placing symlinks in /etc/systemd/. (With the
exception of runlevels 0,1,6 which however cannot really be
reconfigured on sysvinit either). I'll not comment on the benefit of
doing so though.

> Systemd deprecates shell scripts
> --------------------------------
>
> With systemd, you're no longer supposed to write your service
> definitions in shell; instead, you write them in systemd's declarative
> language.  Where you used to say
>
>   ulimit -d 40000000
>
> you now say
>
>   LimitDATA = 40000000
>
> The trouble with that is that while we all know how to write shell
> scripts, systemd requires that we learn a new language.

That "language" are .ini-files. Everybody knows .ini files. They are so
simple and have been around for so long, that you don't need to learn
them. Many programming languages come with parsers for them out of the
box.

OTOH shell is a turing complete language, and a very weird one on top.

>  What is more, we are now limited to configuring those aspects that
> systemd's author has implemented; this is unlike shell scripts, where
> we can configure anything that can be configured either from the shell
> or from a utility callable from the shell.  (Compare with runit, which
> simply ships with a utility to change a bunch of process paramaters
> not otherwise tweakable from the shell, and expects you to write a
> single-line shell script in order to tweak process state.)

Yeah, well, systemd is a lot more powerful with a much simpler
language. To configure stuff like the IO or CPU scheduler, the CPU
affinity, OOM adjustment, timer slack, capabilities, privilege dropping,
namespaces, control groups, secure bits, and so on, you just need a line
each in the systemd unit files. In shell however, you will have a hard
time. You can install additional packages to make some of these things
work, but that again increases bloat, and slows down boot (since it
multiplies the number of processes you need).

systemd, with all the power it gives you in unit files, encourages
developers to ship their software robust and secure *by default*. In
shell this is not realistically doable, unless you want to pull in a lot
of additional dependencies. Again, systemd helps "debloating", and
sysvinit encourages it.

On top of that, everybody can easily understand systemd unit files,
without having to learn a programming language. Unit files can easily be
generated programmatically and parsed programmatically too. Shell
scripts cannot be, unless you reimplement a full bourne shell
interpereter.

Finally, systemd does not stop you from using shell scripts. There are
certainly things systemd won't do for you, and never will. If that's the
case and you don't want to add that feature to your daemon code itself,
then you are welcome to just spawn a shell script from the unit file,
nothing will stop you.

As every good software should: systemd makes the frequent things easy
and the other thinks possible.

> Systemd is Linux-specific
> -------------------------
>
> Systemd is specific to Linux.  This is strange, since the only feature
> of Linux used by systemd that doesn't have an exact equivalent on other
> systems, cgroups, is optional in systemd.

Yeah, that is really bogus.

Here's a short and very incomprehensive list of Linux interfaces that
systemd uses that the other Unixes don't have. We make use of these
features and we empower the user and admin to take advantage of them,
which we couldn't if we cared about POSIX and POSIX only:

cgroups
namespaces
selinux
autofs4
capabilities
udev
oom score adjust
RLIMIT_RTTIME
RLIMIT_RTPRIO
ionice
SCHED_RESET_ON_FORK
/proc/$PID/stat
fanotify
inotify
TIOCVHANGUP
IP_TRANSPORT
audit
F_SETPIPE_SZ
CLONE_xxx
BTRFS_IOC_DEFRAG
PR_SET_NAME
PR_CAPBSET_DROP
PR_SET_PDEATHSIG
PR_GET_SECUREBITS
/proc/$PID/comm
/proc/$PID/cmdline
/proc/cmdline
numerous GNU APIs like asprintf
SOCK_CLOEXEC, O_CLOEXEC
/proc/$PID/fd
/dev/tty0
TIOCLINUX
VT_ACTIVATE
TIOCNXCL
KDSKBMODE
/dev/random
/dev/char/
openat() and friends
/proc/$PID/root
waitid()
/dev/disk/by-label/
/dev/disk/by-uuid/
/sys/class/tty/console/active
/sys/class/dmi/id
/proc/$PID/cgroup
\033[3J
/dev/rtc
settimeofday() and its semantics

(sure, some of the other unixes have a few of these features, but that's
not the point, and it doesn't make this POSIX)

And this list isn't complete. It's just grepping through two source
files.

There's a reason why systemd is more powerful than other init systems:
we don't limit ourselves to POSIX, we actually want to give the
user/administrator the power that Linux can offer you.

> Systemd's author is annoying
> ----------------------------
>
> While I haven't had the pleasure to meet Lennart in private, I find his
> public persona annoying, both on-line and at conferences.

While I haven't had the pleasure to meet Juliusz in private, I find his
personal and public persona annoying online. He writes personal emails
to people telling them how he finds them annoying. He sends FUD mails
around while being amazingly badly informed.

> He practices misleading advertising[2], likes to claim that the
> universal adoption of systemd by all distributions is a done thing[3],
> and attempts to bully anyone who has the gall to think that the
> discussion is still open[4].

Juliusz practices misleading anti-advertising [1], likes to ignore the
fact that all major distros either made systemd the default or include
it in their distro with the exception of Ubuntu.

[1] The mail this mail is a response to.

You know, you personally attack me and that's quite an unfriendly
move. Even if you think I am dick, I can tell you that I am not the one
who runs personal attacks like this, and publicly calls people by their
name.

You write personal hate mail. I don't. Who's the real dick here?

> Conclusion
> ==========
>
> Systemd is the first init replacement worth criticising.

Nah, the conclusion is more likely that nescience doesn't stop people
from writing stupid opinion pieces.

Feel free to forward this to your mailing list, since you wouldn't have
forwarded this to me if you didn't want me to reply to this. And don't
conveniently leave parts out of it.

Cheers,

Lennart

--- End Message ---
Reply to: