Slashdot Mirror
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."
Not really. His argument lost some credibility when he compared a system level utility to a graphical application.
Linux creator Linus Torvalds is well-known for his strong opinions on many technical things.
Yeah, "strong opinions". More like utter childish anger and unprofessionalism.
Just listen to this guy's question and the answer to it...
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.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Not really. His argument lost some credibility when he compared a system level utility to a graphical application.
What's the difference? Both are complex systems.
I think there is a major difference between having a big possibly over-complicated application program in userspace, and putting something like that in a critical spot in the system itself.
If your application program has a flaw, it's probably not a huge deal. Maybe it crashes occasionally. You save often, you have autosave, it's not a big deal.
But a system component that can crash the system, render it unbootable, hand control to a hostile third party, etc - it's much more important in that case to keep things clean and proper to keep the machine itself stable.
Part of the disconnect between the Sysd cabal and the traditionalists here is about what we mean by the machine. We are often running linux on bare metal as our workstation. From what I have been told, they typically run it in virtual machines on server farms instead, and use Apple workstations. So from their point of view, it is just another application, and it shouldnt be a big deal to restart it occasionally - especially after they put so much work into improving boot times. But from our point of view, we dont care much about fast boot times, we want a stable system that doesnt need to be rebooted all the time.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
Are you suggesting that Systemd is prone to crash?
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
Don't waste your vote! Vote for whoever you want, unless you live in a swing state it won't matter anyways
The logging is a perfect example. Why do I have to learn a new program (journalctl) just to read the system logs? What if I had to learn the syntax of a new program to read the logs of every program that I used? That would suck. If openvpn and mysql and httpd and sshd all had their own little program that I had to use to read their logs, I would give up using Unix.
I already have a program to read all logs, more or less. And I already have a program that searches all the logs, egrep. Yes, I had to learn egrep syntax, but now that I know it, I can do almost any search imaginable of any program's logs. Except systemd.
A philosophy doesn't remain true either, just because it's old.
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.
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.
(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
Ce n'est pas une signature automatique.
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.
A Pirate and a Puritan look the same on a balance sheet.
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.
It's not the fall that kills you. It's the sudden stop at the end. -Douglas Adams
> The main one is parallel startup of daemons.
This leads to a Windows style boot process where things might not even be ready when they are needed. I see this with one of my more complex Ubuntu boxes. It HALTS the boot process. Now I have to find a way to manually repair that so that box can boot on it's own without human intervention.
So you have this mindless following of the Windows mentality where it doesn't matter so much if the machine is useful. It just needs to appear to be useful for marketing purposes.
"Booting fast" is a pretty low priority item to trash a core system process over.
A Pirate and a Puritan look the same on a balance sheet.
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!"
Only to idiots, are orders laws.
-- Henning von Tresckow
People have reported corrupt log files. The result is all the data is unrecoverable. The complaints have been answered 'as designed'.
When things are right, it works as intended. When things are bad, it can go far off the rails. Considering it is the system log used to debug what is wrong when things are off the rails, a full binary log is a dubious proposition.
There are benefits to binary log, but they could have been done to varying degrees with structured text and/or external binary metadata, rather than a corruptable binary blob.
XML is like violence. If it doesn't solve the problem, use more.
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.
It runs in user space, not kernel space, so it isn't really his problem. :)
I write sci-fi for metalheads
It's also a matter of perspective. Systemd runs on the kernel not the other way round. So we have Linus upstream, watching the lovely daisies and the froglets jumping around, then Lennart & C pissing in the stream, then a bunch of devs/sysadmins thinking "WTH Lennart", then, downstream, the unsuspecting masses.
---- MISSING MISCELLANEOUS DATA SEGMENT --- [sigdash] trolololol