Torvalds: No Opinion On Systemd

An anonymous reader writes:Linux creator Linus Torvalds is well-known for his strong opinions on many technical things. But when it comes to systemd, the init system that has caused a fair degree of angst in the Linux world, Torvalds is neutral. "When it comes to systemd, you may expect me to have lots of colorful opinions, and I just don't," Torvalds says. "I don't personally mind systemd, and in fact my main desktop and laptop both run it." Torvalds added, "I think many of the 'original ideals' of UNIX are these days more of a mindset issue than necessarily reflecting reality of the situation. There's still value in understanding the traditional UNIX "do one thing and do it well" model where many workflows can be done as a pipeline of simple tools each adding their own value, but let's face it, it's not how complex systems really work, and it's not how major applications have been working or been designed for a long time. It's a useful simplification, and it's still true at some level, but I think it's also clear that it doesn't really describe most of reality."

Comments

Now ask him if he trusts systemd upstream "taste"

[Anonymous Coward]

Now, the real question one should ask Linus is whether he trusts systemd upstream's "taste". The answer will be nowhere near as nice.

The major issue with systemd is actually that we don't trust its upstream. They're known to cut (important!) corners since well before systemd (i.e. pulseaudio), and they have the "we know better" mentality.

The last time Linus had to trust systemd to do something (udev component), it caused a massive (and deserved) flamewar which ended up with the kernel removing support for udev's firmware loader, and switching to an in-kernel firmware loader to bypass udev.

Re:Simple set of pipelined utilties!

[jeremyp]

The argument is that, if pid 1 dies, everything dies. Also a big pid 1 presents a big attack surface for nasty people.

Of course the exact same argument applies to a kernel: if something goes wrong in the kernel, everything dies and a big kernel presents a big attack surface to nasty people. However, I observe Linux is not a microkernel but it has a reputation for both reliability and being relatively secure. On the other hand, the quality of the people developing the kernel seems to be higher than those developing systemd, or at least that is the perception I get from reading all the hate on the Internet.

Re:Are you even aware of SystemD works?

[drinkypoo]

You don't seem to understand how SystemD actually works. The PID 1 is relatively simple -- it uses all sorts of separate (i.e. non-PID 1) helper processes to do all the heavy and complicated lifting.

Lifting which should not be done by PID 1. And PID 1 has to be more complex than it should be just to handle those external programs.

SystemD currently does a fuckton of stuff no other currently usable init system on Linux does.

It does a lot of stuff the init system shouldn't do.

(Reliable process supervision which cannot be evaded,

cgroups existed before systemd.

sane handling of process stdout/stderr

Up to the init script.

proper handling of dependencies at runtime

Already handled by several init systems.

socket activation

We call it inetd.

I don't particularly care which init system my system runs, but I want those features and currently only SystemD can deliver them.

That is ignorance at best, or perhaps a lie.

Please stop spreading FUD about things you know next to nothing about.

You have no idea about anything, that didn't stop you. I see why you didn't log in.

Also concentrate it in 1 point.

[DrYak]

You don't seem to understand how SystemD actually works. The PID 1 is relatively simple -- it uses all sorts of separate (i.e. non-PID 1) helper processes to do all the heavy and complicated lifting.

And another thing I like about systemd:
- it groups into 1 single project: 1 single task (starting-up/seting-up things) that was spread accross way too many different project before.

Before systemd:

Want to start a service during boot-up ? Put it into sysvinit. Except if it's a file system, then it goes into /etc/fstab. Or if it's not a *service* but like of an interface like your terminal that should go into inittab (Except on distribution which do THE EXACT SAME THING but in init.d anyway).
The thing which start is related to actual hardware? the you need to put it into hal, no way we replaced that with udev... except that a few distro put them any way in init.d and thus your hardware might not work when plugged after booting... unless you also duplicate some code into modprobe.conf's post-runs.
And what if conditions for your code to start isn't "boot-up" nor "plug-in" ?
Then put it into inted/tpcd if it's network triggered. Except for code that doesn't work there, because the service needs to be compiled to use libwrap to work this way. So then you'll have to run the service constantly and fumble around with ip filtering to enable/disable it on demand.
Or put it into cron if it's time triggered.
And you need to start a service and the periodically monitor it for failure, and restart and raise alert if it has failed? Well either use an entirely separate custom system like djbdns's daemontools. Or write your own monitoring solution by writing a ton of scripts which tap into all those different ways to start/stop stuff and hope that it works.

And don't get me started about initialising containers (limited fonctionnality, tons of script), brokering access rights around (not really used. lot of interface must run as root and drop privileges, or lot of interface must be world accessible), handling situation as missing configuration or drivers in a system that hasn't fully booted up to the point where the GUI works and the user can fix things from here (huge tons of scripting to achieve way to detect that Xorg is failing and to propose solution to fix drivers)

All this written in shell script which can have their own pitfalls, and every single system using a different syntax.

After systemd:
PID1 and its herd of helpers take care of setup/start/stop/teardown.
Want to do *something*? Write a systemd config file, and describe which trigger (boot, after another service has started, on network, by clock, on device plug, etc.) should start it.
You can even call legacy systems from within systemd (cron can be reimplemented as a systemd service that runs periodically and reads/executes crontab, etc.)

You can have an LXC that is quickly setup. In fact you can quickly create throw-away container to jail any service separately (systemd is the kind of infrastructure that can boot a dedicated LXC jail to run Skype into, with restriction correctly setup so that no hidden backdoor could spy on you).
You can have systemd handle brokering the necessary rights (to the point that plugin an USB stick and having the currently active user access to it isn't a nightmare anymore).

If anything the handling of setup/startup/stop/teardown WAS NOT "unixy" before, it was "have 384 different programme which all do a different part of one single task in subtly different ways".