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

Simple set of pipelined utilties!

[CajunArson]

It sounds great in theory but...
1. If you really buy that principle and want to enforce it religiously, then please never use a web browser again (even Lynx!), not to mention any other complex program that isn't formed from a bunch of small "do one thing well!" utilities that are executed in a pipeline.

2. Please tear up your Richard Stallman fanclub cards because what little software he's written has mostly been Emacs and Emacs is the anti-UNIX based on the "pure" UNIX philosophy.

That't the issue: Every single person who hates SystemD because "UNIX PHILOSOPHY!!" has no problem violating that philosophy to actually get things done in a whole bunch of other areas. That's not even bringing up the fact that SystemD is.. wait for it... built from a bunch of individual utilities that can actually be used by non-systemd programs.

Re:Simple set of pipelined utilties!

[drinkypoo]

If you really buy that principle and want to enforce it religiously,

It's not a religion, it's a principle. When it makes sense, you put it aside and get work done. The argument against systemd is that it doesn't make sense. systemd is a simple case of NIH because it provides absolutely nothing which could not be implemented with the existing daemons and some small shell scripts.

That't the issue: Every single person who hates SystemD because "UNIX PHILOSOPHY!!" has no problem violating that philosophy to actually get things done in a whole bunch of other areas.

That's right.

That's not even bringing up the fact that SystemD is.. wait for it... built from a bunch of individual utilities that can actually be used by non-systemd programs.

That's not the complaint. The complaint is that the process at PID 1 should be simple. You people running around screaming about a bunch of different processes are only compounding the proof that you do not understand Unix. It's not a problem to have many processes.

Re:Simple set of pipelined utilties!

[paskie]

But it's not actually clear why is it critical that PID 1 is simple (and if situation is so much worse with systemd).

Xorg, which on desktop is as critical as init to keep running, is not really simple.

kernel, which is also as critical as init to keep running, and it is *much* *much* more complex than systemd. systemd is not at the "bottom layer" of the system, there's the whole of kernel underneath still.

And one common myth is that systemd has these so many features and systemd is pid 1 therefore pid 1 is this huge bloated monster that does udev, logging and NTP, right? Wrong; actually, just the core bits of systemd run in pid 1 and the rest is compartmentalized in a bunch of separate daemon processes.

So, this "increased complexity" issue is not really as bad as it sounds, realistically.

Re:Simple set of pipelined utilties!

[Peter H.S.]

It's not a religion, it's a principle. When it makes sense, you put it aside and get work done. The argument against systemd is that it doesn't make sense. systemd is a simple case of NIH because it provides absolutely nothing which could not be implemented with the existing daemons and some small shell scripts.

You can't seriously claim that systemd provides nothing that can't be done by script based init systems, shell scripts and existing daemons, logind is just one example (ConsoleKit is a dead project with no alternative).

But it would be an interesting project to make a Linux SysVinit distro that tried get feature parity with systemd, so that daemons could utilize the kernel "namespaces" and "capabilities" to massively strengthen security, or have a total supervision chain of all processes, including PID1 etc. There is so much good stuff in systemd that the SysVinit-like init distros could clone.

That's not the complaint. The complaint is that the process at PID 1 should be simple. You people running around screaming about a bunch of different processes are only compounding the proof that you do not understand Unix. It's not a problem to have many processes.

Isn't that argument just trying to make a virtue out of the fact, that SysVinit and the like, are totally crude and primitive init systems that are unable to anything much of interest?

All the analyses I have seen shows that moving crucial processes into PID2, just makes everything more fragile and opens up security holes.

I think that there are actually very good design reasons for why systemd is designed like it is.
It only runs one process as PID1, the daemon "systemd" which is rather small. This daemon however, is capable of "talking" with with several other processes, which gives it many advantages, since it can act as a mediator between kernel features like cgroups and "capabilities" and the processes it controls.

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.

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.

Misleading slashdot headline

[penguinoid]

As usual, the headline is misleading. What's less usual is that they totally undersensationalized the news.

Torvalds: No Opinion On Systemd
vs
Torvalds: UNIX Philosophy is Obsolete

Re:Misleading slashdot headline

[Carewolf]

As usual, the headline is misleading. What's less usual is that they totally undersensationalized the news.

Torvalds: No Opinion On Systemd
vs
Torvalds: UNIX Philosophy is Obsolete

I think you missed the micro-kernel vs macro-kernel debate that happened when Linux was born. That Linus likes things more monolithic and practical is OLD news.

Are you even aware of SystemD works?

[Anonymous Coward]

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.

systemd is a simple case of NIH because it provides absolutely nothing which could not be implemented with the existing daemons and some small shell scripts.

Given that both C and Shell are Turing Complete (well, disregarding finite memory), then yeah. We could also program an init system in Brainfuck, but that has no bearing on whether it's a better idea to do so. Exactly the same thing here.

Also, SystemD currently does a fuckton of stuff no other currently usable init system on Linux does. (Reliable process supervision which cannot be evaded, sane handling of process stdout/stderr, proper handling of dependencies at runtime, socket activation, etc. etc.)

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

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

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.

So what's wrong with systemd, really?

[Endymion]

(paraphrasing a previous post of mine, becuase more people should see this)

It breaks existing promises, and makes few new promises in return.

There has been a lot of talk about the various technical problems with systemd and its developers inexperience-betraying design decisions. As bad as those are, they miss the larger point. There has also been a lot of very important talk about philosophy of design ("the unix way") that again shows how little experience the developers have and their disregard for the work people have already done and will have to do to fix the systemd mess.

These topics are valid, but miss the larger problem that systemd represents and the threat it is to Free Software in the Linux ecosystem.

## The problem with systemd's design: embrace and extend ##

As an excuse for all the vertical integration Poettering's cabal have been busy aglutenating into what they still sometimes claim is "justs an init system" has been the laughable claim that systemd is in any way "modular". They claim that "modular" is a *compile time* feature, or some property related to the fact that they build several ELF binaries. This is not modular, because it does not represent some form of stable, well-defined API.

What is an API (Application Programming Interface)? It's not a technical feature. It is not documentation that describes how to use some set of features. It is not a calling convention. So what is it?

An API is a PROMISE .

It is a social feature, not a technical one.

The functions and documentation are just a particular implementation of that promise. The key attribute that makes an API an API is that it is a promise by the developer: "If you want to interact with some feature, this is the way to do so, because while other internal stuff may change at any time, I promise this set of functions will be stable and reliable".

Binding previously-separate features into one project is bad design, by itself, the problem with systemd. The problem came when Poettering stripped down the barriers betwen features with the specific goal of removing established APIs (and breaking existing promises that developers relied on). His stuff may compile into various separate programs, but Pottering is very careful to keep various key interfaces "unstable" (despite being good enough for RHEL), specifically to not make any promise about how those interfaces will work in the future. He likes to call this hididng of interfaces "efficency" or "removing complexity". What he never mentions is that many of us used those promises, and by removing them he has at best forced others to do a lot of work to fix the breakage, or at worse made various features impossible.

A good example is logind, which was absorbed into systemd just so promises about its behaviuor in the future ("stable APIs") could be removed.

The reason many of us that have been watching Poettering's cabal for many years now suggest these changes are intentional and malicious are based on this. Occasionally removing features because of a technical need or bug or security requirement is understandable. Purposfully stripping out entire sets of features - that is, the features that allow other groups to develop with confidence that some feature they won't simply vanish - is something entirely different.

If MS acted like Poettering's cabal and removed a formerly-public API that competetors used - while promoting their own product that happens to use internal, not-publicly-promised APIs, the world would be screaming "monopoly". This happened, and resulted in several high-profile court cases.

## systemd threatens the GPL ##

It goes without saying that many people would like to distribute various GPL licenced software and not be bound by the terms it requires. The fact that some of these same people use the courts to threaten people who do the same to their software is noted, but off topic for now. The problem is t

Re:Yes, pipelined utilities, like the logs

[Chris Mattern]

I already have a program to read all logs, more or less.

In fact, you have *two* programs to read all logs. More and less.

Re:Torvalds is neutral

[Savage-Rabbit]

This may be the best endorsement for systemd yet.

Don't knock it, the "I have no opinion" principle has gotten millions of men through their marriages with a minimum of trouble. Mind you some things you have to have an opinion on, like for example "Does my ass look big in these jeans", your little brain is saying "Yesssss, acres an acres of ass and it's all mine... I love it!", your rational brain prompted by your survival instinct modifies that to "No, dear!"

Re:well said!

[ArhcAngel]

I may shock the Lemmings and Fanboys, but we don't hold up people like Linus as if they are infallible. If we think our "leaders" are full of shit, we will happily say so. We don't treat our community leaders like Kings or Popes.

BLASPHEMY!!!
Repent or be tormented forever by a Daemon!

Re:well said!

[gbjbaanb]

Repent or be tormented forever by a Daemon

by the daemon called systemd....

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".