Re: A few observations about systemd
]] Juliusz Chroboczek
(I'm the systemd maintainer in Debian)
| Systemd is bloated
| ------------------
|
| 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.
I disagree with this and you're muddying the waters:
it uses modprobe, it uses mount and setting the host name has always
been part of the boot process, so that init is doing this is just a
change in the sense that it's done by C code rather than a shell script,
so in those cases it just does what is already done by a bunch of shell
scripts.
as for trying to take over inetd's role: yes, it can replace inetd. You
don't have to do that, though. Replace cron and at? Not really, it has
support for timer events, but it does not have any replacement for the
user part of at and cron, so while it can do some of what at and cron
can, it's currently no replacement for them.
| 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.
I don't see why it shouldn't be.
| 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.
It uses dbus as an IPC mechanism rather than inventing its own. It does
not depend on dbus-daemon.
| 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.
What's so shocking about this? If somebody either creates a common API
that all splash implementations can use (and make plymouth switch to
that), I'm sure systemd will switch too. The point is there is no
current generic early boot protocol.
| 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.)
It does? To the best of my knowledge the Debian package does not treat
any of the «normal» runlevels differently.
| 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. 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.
ExecStart=/bin/sh -c 'ulimit -d 4000000; some_daemon'
should work just fine. (Sure, it's a bit ugly, and if you have anything
that makes sense to make generally available, we'll happily add it.)
| 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.
TTBOMK, cgroups are not optional.
Regards,
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
Reply to: