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."
I approve of this message.
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.
AntiFA: An abbreviation for Anti First Amendment.
Sounds good. What is it again? :reasons:".
I clicked links. Looked at the article. They all talk about systemd but none really define it, as in "systemd is this and does that, and is different because
So for any other systemd-impaired readers, click this: http://en.wikipedia.org/wiki/S... - because TFS, TFA and links from them don't tell you much in this regard.
...gis sdrawkcab (usually not responding to ACs; don't bother posting as AC)
If they're going to change it, I suggest they change it well.
That is, support *functional* dependencies between processes, and caching of input/output. Automatic starting of processes when configurations change, etc. Right now, my computer has to reboot whenever stuff changes and some script does not handle the changes correctly (or simply does not run).
Also, whenever I reboot my system, I don't know if I will get back the system that I shut down (some configurations may have been changed and may have broken my system without me knowing it, only to cause a nightmare when I reboot the system, which is usually the worst possible moment). That has to be fixed as well.
If Pandora's box is destined to be opened, *I* want to be the one to open it.
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.
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.
This may be the best endorsement for systemd yet.
He said he didn't have any colorful opinions on it. I thought Linus couldn't make breakfast with out swearing twice.
Non impediti ratione cogitationus.
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.
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 runs in user space, not kernel space, so it isn't really his problem. :)
I write sci-fi for metalheads
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".
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]