New Group Calls For Boycotting Systemd

[interested]

There was some talk about how much code is needed...
All numbers per Dave Wheeler's "sloccount".
systemd is 228,830 loc, glib is 422,080 loc, dbus is 98,355 loc, libidn is 91,570 loc, kmod is 24,856 loc, pam is 45,788 loc.

OpenRC is 11,200 loc.
Busybox is 206,755 loc (including kconfig, vi, two shells, runit, init, cron, dhcp client/server, coreutils, a print server, modutils, mailutils, coreutils, and a whole lot more; much of it you will never use)
busybox-initscripts (alpine openrc scripts) plus the packaging are 196 lines.

sysvinit is 7094 loc.

toybox (includes init and a fair portion of a CLI system) is 37,858 loc.
To round it out I used openbsd ksh (I actually used loksh) @ 20,941 loc; netbsd sed @ 1860 loc; and openbsd awk @ 9367 loc for a total of 70,026 loc.

bash is 115,715 loc
mksh is 26,922 loc
(debian) dash is 14,167 loc
(Does anyone see why people complain about bash being bloated?)
coreutils is 206,654 loc
util-linux is 118,982 loc

So sysvinit with busybox and openrc is smaller than systemd alone (even though sysvinit is not needed that way...).
toybox with openrc would be less than half the size.
But if it's fair to count the shell against sysvinit, it's fair to count glib, dbus, PAM, etc. against systemd; even glib alone would nearly triple the lines of code.

coreutils + dash + sysvinit is almost exactly the same size as systemd alone, and adding util-linux (for getty/login) makes it half again as large; but glib makes systemd far larger when including dependencies.

Interesting calculations, if somewhat off the mark of the original discussion; they show that even though SysVinit is capable of so little, it can't even compete in the small embedded systems.

Anyway, systemd is very modular. It has +40 configure compile time switches. PAM, dbus etc are all optional. There is even instructions for making systemd even smaller than what the configure switches allows out of the box: http://freedesktop.org/wiki/Software...MinimalBuilds/

So you can squeeze systemd down to a very small size while still beating the pants off busybox implementations when it comes to core features like total process supervision, including systemd itself, and security, simply because it supply an easy framework to secure all processes with "Linux Capabilities", like preventing privilege escalation. With kdbus it also gains a kernel IPC system, making it even more attractive, and there is cgroup too.

I strongly suspect that systemd will dominate the embedded world too within not so many years; it will simply provide so many useful modern features, like auto configuration of hot plugged devices and launching of the the appropriate services when needed, and not before.

[Ibidem]

Interesting calculations, if somewhat off the mark of the original discussion; they show that even though SysVinit is capable of so little, it can't even compete in the small embedded systems.

Or rather, sysvinit + coreutils can't compete.

sysvinit would work with toybox or any other implementation of the core commands.
I could run even poorly written initscripts that need awk and sed with less than 100 kloc.

Anyway, systemd is very modular. It has +40 configure compile time switches. PAM, dbus etc are all optional. There is even instructions for making systemd even smaller than what the configure switches allows out of the box: http://freedesktop.org/wiki/Software...MinimalBuilds/

So you can squeeze systemd down to a very small size while still beating the pants off busybox implementations when it comes to core features like total process supervision, including systemd itself, and security, simply because it supply an easy framework to secure all processes with "Linux Capabilities", like preventing privilege escalation. With kdbus it also gains a kernel IPC system, making it even more attractive, and there is cgroup too.

First, check out what runit can do before you thumb your nose at busybox too much.

Second, capability bounding sets can prevent any descendents of a process from gaining a capability...but that's not really where the main problem is. Usually, someone triggers a bug in a process that's already running with the privileges they want.
Nonetheless, I might write a CLI tool to exec with bounding sets ("withcaps"), just because it seems interesting.

I'm currently using OpenRC with busybox; for my own purposes, it's much more than enough.

Anyhow, I tried building it...
Delete the configure test for ln --relative that autoconf insisted on sneaking in despite there being absolutely no use of it. I'm using Alpine Linux, so ln is the busybox implementation.
Install libcap-dev and gperf (why must I install gperf to compile this?)
Pass just about every disable option there is; it still checks for Python...
Try to build.
Disable a CFLAG that gcc doesn't like.
Now, try to build again.
# error: neither secure_getenv nor __secure_getenv are available.
That will be trivial to fix, if I just patch my libc:

#include "libc.h"
char * secure_getenv(const char *name)
{
return libc.secure ? 0 : getenv(name);
}

I strongly suspect that systemd will dominate the embedded world too within not so many years; it will simply provide so many useful modern features, like auto configuration of hot plugged devices and launching of the the appropriate services when needed, and not before.

Auto config of hot plugged devices?
eudev, mdev, nldev, hotplug2...
Launching of appropriate services when needed...isn't that what inetd does?
What you just described is systemd reimplementing a large number of features of other daemons as new daemons.

[Ibidem]

But does it make sense to build the entire system around that contingency - that the admin doesn't have a bootable USB stick already sitting on his desk, doesn't have the ability to download one on-demand, *and* can repair the system using nothing but the minimal tools in /{s,}bin (assuming those haven't been hosed along with the rest of the system)? This seems a very niche use-case...

Try s/admin/laptop user/; it does happen.

[jacob]

Ever use single user mode? /bin and /sbin hold all the mission critical goop. That way, when /usr and /var are trashed, you boot into single user mode (no login required) and can repair them with all the tools in /bin and /sbin. It makes total sense to have a standalone root partition that is seldom written to (even read-only) that is resistant to corruption. There's your perfectly reasonable answer for 4 directories.

I should also mention that single user mode allows you to use the system prior to mounting any file system (with / mounted read-only), with no login and theoretically no restriction on what you can run as a user (just a single console though). It's also very handy when you forget root's password and have physical access to the machine.

initramfs does that, only better. In single user mode you still need to be able to mount /bin and /sbin, and there is no reason really to assume that they would get trashed any less or more often than /usr.

[jbernardo]

Thanks to Lennart Poettering Linux finally got a system-wide sound deamon, instead of several incompatible DE based sound deamons. It was an almost impossible job to do, but it was executed brilliantly with excellent backwards compatibility and without rewriting the entire sound system or all audio drivers.

I have to decide if you're a pathological liar or a moron. Nice attempt to rewrite history, maybe someone who has just started to use linux will believe you. Pulseaudio only started to work after Poettering abandoned it, it rewrites the sound system, it breaks Jack and many apps that talked to alsa, and it is still an unstable piece of code. The first versions were so bad that they broke almost everywhere, and worked only with a couple of soundboards. Too bad linux went with alsa instead of OSS4 for licensing issues, but plain alsa is still superior to that resource hog pulseaudio. If anyone is using rose tinted glasses, it is you.

[sdack]

Pythons looks larger and seems to have more code but that perl snippet is more complex than that python snippet. if i can show that in a couple lines of code that can easily scale upward to a larger project. systemd is larger for good reason it has increased functionality and is safer than the mess that is sysvinit.

You cannot say size would be a bad indicator, and then make a claim based on size. That is just nonsense. You may not like one language and like another better, but lines of code is a well established measure in computer science.

systemd is new and only this is why it is not a mess yet. sysvinit has been around for a very long time and has turned into a mess only lately. This is not the fault of sysvinit, but of people who have failed to use it right. It sure is not the fault of sysvinit, when distros have each their own layout for /etc and even keep some files in /usr/share. So when these same people now adopt systemd will they do the same nonsense as they did with sysvinit before. Nothing stopped them before and all you really have is a hope that it now will all get better.

[Karl Napf]

There was some talk about how much code is needed...

coreutils + dash + sysvinit is almost exactly the same size as systemd alone, and adding util-linux (for getty/login) makes it half again as large; but glib makes systemd far larger when including dependencies.

You are aware that you need a chunk of the systemd repo, even when running openrc? At the very least you want udev, which is in the systemd repo (or the eudev fork). You might also need logind (or its shim). The datetimectl is also nice to have if you want to change the system time with any modern desktop environment. Yeap, you do not need the network stuff included in systemd, but you need replacements from other projects.

I seriously doubt that the "lean" init systems are significant leaner than systemd once you add all the code necessary to run a modern desktop. A server might show a bit more difference, but even there I doubt that is significant.

If you want to have service monitoring (which none of the others can actually do properly, they need a monitoring process that may fail without anybody noticing) or cgroups you need to even add more code. Systemd offers all that out of the box.

[Karl Napf]

sysvinit has been around for a very long time and has turned into a mess only lately.

To be fair: sysvinit was a mess when I first ran into it in the early 1990. People were trying to replace it even back then!

The new systems had no compelling features (or stupid licenses), so they did not gain traction. Thanks to cgroups being in the kernel nowadays that is different this time round.

[curaga]

Interested, you twist history and write in such a way that if you wrote about Ukraine instead of Poettering, you'd have been paid by the Russian PR ops for over a decade now. That's how deeply brainwashed your writing is.

[sdack]

To be fair: sysvinit was a mess when I first ran into it in the early 1990. People were trying to replace it even back then!

The new systems had no compelling features (or stupid licenses), so they did not gain traction. Thanks to cgroups being in the kernel nowadays that is different this time round.

People have been trying to replace UNIX with Windows back then, too. It does not mean much. And if you think it was messy in the 90s then you took your sweet time to come forward. And how can you be so convinced of systemd being better in the short time it exists? You cannot, right? So I am going to assume that you only did not like sysvinit for personal reasons and now enjoy systemd like most people do when they get a new broom. And please do not get me wrong. I do not want to simply dismiss your comment. I only find it much harder to do the same with all the people who have given many good reasons why they think systemd is bad. The shit storm systemd has caused is very real.