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.
He clearly doesn't understand Linux.
Arguably Linus Torvalds understands Linux better than the rest of us.
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.
I think he just doesn't care about things that don't get in his way.
A few weeks ago, when systemd would lock up the system if you turned kernel debugging on, he did have rather colorful opinions about systemd and the systemd developers who insisted that systemd was doing the correct thing.
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.
You mean.... gasp! ... PostgresSQL isn't a shell script pipelining a bunch of sed/awk/grep/mv/cp commands? Minecraft isn't some big long awk script that calls perl when it runs out of gas? I never woulda guessed!
Seriously though, and without belittling the value of the bunch 'o pipelined commands (especially for sysadmins), it's nice to hear someone clearly and concisely articulate this rather obvious reality.
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 switched to BSD a while back and I couldn't be happier.
Oh, great, NOW look what you guys did - you woke up the BSD zealots!
#DeleteChrome
Much of the systemd debacle has been a clash of mindsets between the old Unix guard and a newer generation of developers focused on integration. The old Unix philosophy of each module doing one thing and doing it well allows developers to take a bottom-up approach and glue existing modules together to provide solutions rapidly. However, as Linus alludes, this method doesn't scale well, especially as many modules are cobbled together to implement much more complicated tasks. At a certain point, a top-down approach works a lot better for those larger tasks. The top-down approach provides a more user-centric look at how to create a well-integrated solution and may use existing modules just as would be the case in the bottom-up approach. Since it is more focused on the user's perspective (rather than the developer's perspective), it tends to realize shortcomings in existing modules earlier and therefore may lead the developers to make the decision to write some of their own modules rather than mostly relying on extending modules well-beyond their intended purposes.
Systemd takes a top-down approach, and while some may argue that it's design leaves a lot to be desired, that doesn't mean that a bottom-up approach is automatically better. Based on the dependency tree, this appears to be a project that started out with few requirements and quickly grew after it was deep in the implementation phase, which is a problem regardless of either development approach. And then you have just bone-headed moves on top of that such as using binary logging. In any event, it's being widely adopted, it's here to stay, and I'm sure it will continue to remain controversial.
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.
Being paid to program doesn't make you a professional.
Being paid to do anything by definition makes you a professional. Professional does not mean 'better', it just carries the connotation since frequently someone who cannot get paid for their work where another can is due to things that lack. In coding, sometimes being 'professional' versus 'amatuer' really boils down to being loud enough to get taken seriously.
XML is like violence. If it doesn't solve the problem, use more.
I thought his cat already had a point and click interface. The button is on the laser pointer.
It runs in user space, not kernel space, so it isn't really his problem. :)
I write sci-fi for metalheads
Well said. One problem here is that systemd indeed increases complexity significantly and decreases the flexibility and control of the system administrator. That can still result in a good outcome, but not with these people in control and it shows in numerous places already.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Honestly, what's wrong with just manually altering registers to initialize the OS? We could have little buttons that just turn individual bits on and off.
It seems that there are lots of new capabilities with systemd, but it has come to market with lousy documentation. The purveyors are receiving a thorough flogging at the hands of the greybeards, which they richly deserve.
"Do one thing well" is how Unix kernel functions are written, and it's just plain a good idea. Systemd probably follows the first principle internally, many programs do.
Creating production systems[1] out of single-purpose commands connected by pipelines is a different principle, and only works if you keep them pretty simple. It's not a prionciple, but it is how a lot of Unix scripts are written, NOT including the shell that glues the parts together, and not including all the more complex programs, like ed or mail. Systemd doesn't follow the second, because it's more like ed than a text transformation like spell.
A more useful question is whether systemd as a whole does one thing, and does it well. About that, one might usefully discuss whether the Unix principle applies.
--dave
[Pipelines were patterned after a subset of "production systems" in early AI, which applied transforms to "produce" new things. They're not the kind of production systems you put on a raised floor]
davecb@spamcop.net
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 ]
B) Monolithic hasn't really been considered a good idea for complex systems since before he was born
And it definitely wasn't considered a good idea for OS kernels when he was first writing Linux. History shows us that in that case, the proponents of "lots of independent bits that send messages between them" turned out to be a lot less successful (and a lot more wrong) than Linus and Linux, which monolithically just got the job done, was delivered in a reasonable time scale and with reasonable performance.
Yes, Linus prefers practical considerations over ideological, but even ideologically it surely wouldn't be a surprise to find him supporting a monolithic approach (and supporting it against prevailing wisdom).