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.
but, i do have this opinion!
he's right of course but why not just state the opinion.
Next step: Replace Torvald's cat, ls and rm with a point-and-click interface.
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.
I think his defense of his leadership style during the DebConf 14 was rather uncomfortable to watch (see youtube video...)
I don't think his opinions are really all that strong. He's just abrasive.
If you know how systemd works, go to another thread, please only reply if you're ignorant and want to have an angry, ill-informed debate.
Personally, I think you should be able to start and stop systemd when you want it.
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)
I switched to BSD a while back and I couldn't be happier. All three are written by people who actually know how to program as opposed to amateur primadonnas like Lennart Poettering.
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...
He clearly doesn't understand Linux.
What do the true experts think? Where is the Slashdot poll on this topic? Is systemd programmed in COBOL? Did its development follow the innovative FDD? (Fear-Driven-Development, for those who don't follow the hottest new trends)
Of course, the kernel is special, and kernel engineers are just better people. Everybody knows that.
Given his communications style I'm not surpassed by this quote.
Or maybe I am just missing the implied "/s" .. yeah .. right .. NOT.
I am Slashdot. Are you Slashdot as well?
You are not immediately struck by a elegance and simplicity. I think this is a man who revels in complexity.
Just like systemd.
Torvalds doesn't say he has no opinion on it, he says he doesn't have _lots of colorful_ opinions on it.
The source article is actually titled "Torvalds says he has no strong opinions on systemd".
He clearly voices his opinion on systemd.
"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."
That sure sounds like an opinion to me. I suspect he stated he didn't have an opinion just so he would start a war among his fanbois.
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.
I prefer not to have to re-learn how a system boots. I was quite happy before systemd. I would prefer having a choice on install.
Having said that I'm happy that someone if thinking ahead and offer things that will do a better job in the future.
The amount of emotions is understandable. Some of the outrage is just dramatizations which is changing the attention from the issue to the noise.
Cool heads usually win the day and are nicer to have around. Making a good to-the-point case shooting down the issue point by point is bringing focus to the issue which others can understand and effectivey fall behind.
Of course this is slashdot which is known for, well, being slashdot. YMMV.
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 question isn't whether or not the UNIX philosophy is still relevant to software development in general. The "do one thing and do it well" is a very useful abstraction, but it's just one model (like OOP) of a how a system could work, and nobody is saying it's the right model for every application.
The question is whether or not the UNIX philosophy is a useful model for init, and the answer is still yes. There is simply no defensible reason to combine tons of daemons into PID 1 when it could otherwise be smaller and simpler. There is no reason to have binary logs. There is no reason to have D-Bus integration with all its complications. In short, the "do one thing and do it well" is still a perfectly relevant and smart model for and init system.
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.
strange, just a very few weeks ago systemd was "a bad idea" (http://meetings-archive.debian.net/pub/debian-meetings/2014/debconf14/webm/QA_with_Linus_Torvalds.webm). i guess the situation has improved, or something.
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.
I just don't use it.
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.
After reading the comments, I noticed the following fortune at the bottom of /.
Many people write memos to tell you they have nothing to say.
"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
Linus hasn't spent time as a sysadmin for a long long time now. He would probably rather compile a new binary than edit a shell script. "Do one thing and do it well" is exactly how complex systems really work (when they work). When they don't work, it's usually because things started doing stuff outside their scope.
(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.
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.
I don't mind most of systemd. The binary logs are an exception, what a dumb idea.
What I don't want is system-everything. Which seems to be slowly happening.
It runs in user space, not kernel space, so it isn't really his problem. :)
I write sci-fi for metalheads
Linus generally fixes or addresses only those things that give him immediate pain, and never looks ahead far enough for the future to worry him. We've seen examples of this lack of strategic thinking in the past.
For example, it's why he doesn't worry about the kernel being monolithic instead of partitioned defensively by the MMU so that kernel bugs in one area can't affect another part of the same address space. He's informed well enough (of course) to know that he's living on borrowed time because eventually he won't be able to manage the kernel's bugs as it grows forever bigger, but it's not something he cares about enough to act on NOW --- he'll wait until he feels the pain first.
The issue with systemd is similar. He's informed well enough to realize that a huge, multi-faceted subsystem in process slot 1 will be damaging to the stability and reliability of Linux distros, but he won't act on this until he personally feels the pain, not even to the extent of sounding cautious. His comments were phrased in a neutral manner simply because he hasn't felt any clear damage from systemd yet, and that's his motivating force. It's quite common among younger techies, and at 44 he is still young.
Meanwhile, it's up to other more cautious (and usually older) folk to think ahead and worry about the future more strategically. This isn't Linus's forte.
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.
I am curious on why Tovalds opinion on systemd really matters.
I congratulate him for his work on the Linux Kernel, He made a really good OS, and put enough effort and skill to keep a strong team of developers focused.
However that doesn't make him an expert in all thing. Even all things related to the OS he had pivotal to create.
The systemd argument is about methodology not technology. It is the same as most political redirect. Two groups with a different vision of an end goal, taking different approaches to get there.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
mod up.
When all you have is a hammer, every problem starts to look like a thumb.
When I first read about the systemd vs. initd kerfuffle a few weeks ago, I was somewhat amused that a lot of it came down to similar points as in the Tanenbaum–Torvalds debate over Minix vs. Linux ... i.e., microkernel vs. monolithic kernel. In this analogy, initd is like a microkernel and systemd is like a monolithic kernel. We all know Torvalds went in that debate, so it's not surprising that he has no problem with the "monolithic" systemd. What's amusing to me, though, is the inconsistency of the rest of us who are worrying about keeping systemd out of Linux. If we're so worried about the monolithic nature of systemd, why are we so smug that the monolithic kernel won out over the microkernel in Linux?
You mentioned X11 as a counter-example, but you couldn't be more wrong.
The X11 server crashes or hangs fairly regularly if you are a heavy user of OpenGL, it's by far the flakiest part of Linux desktop systems. And when it does crash or hang, it takes all X11 applications down with it. Nothing else is as flaky in Linux as X11 is.
That's pretty analogous to the role of process 1 in Unix overall --- if process 1 dies, hangs or loops rapidly, the whole system is toast.
We most definitely don't want whole Linux systems behaving like whole X11 systems do. Having a complex (and hence inevitably buggy) component at a single point of failure is a disaster.
He's not "professional" and he doesn't have to be. A billion people will continue to use his product, thousands will help build it without having to interact with him at all. He doesn't have to give a flying fuck about your opinion on how polite he should be, and it infuriates you that he won't bow down. If he never started Linux and all he accomplished was pissing off people like you by existing, he would still be my hero.
Associated Press -- September 17, 2014
In his latest interview, Linus Torvalds shocked the world with his pronouncement that "Cheerios are delicious! Wheaties taste like fucking crap!" When asked to comment, a spokesperson for General Mills stated "Linus is right. Except about the Wheaties." The AP will stay on top of this breaking news and continue to bring you the latest on CerealGate, as it happens.
No, no, you're not thinking; you're just being logical. --Niels Bohr
Since when is "I am all for it!" considered "no opinion?"
WTF? They need to screen people, whomever put that feature in has to be a Microsoft employee! Don't think MS wouldn't stoop that low, they would.
Democracy Now! - uncensored, anti-establishment news
The difference in complex systems is that they do one thing and well inside of functions or classes or what not.
Its because its MUCH, MUCH, easier/faster to do it there, than make a complete program/progress and use sockets/pipes/what not to communicate with the other tool. So sometimes its still useful but most of the time its too much effort too little gain (heck, you also lose performance, time, etc.)
Thats what Linus means as well, I think.
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.
I am sure that, if you have a talk about Linux security with Samsung/HTC/LG... you will hear some unprintable commentary on Linux security.
To a great extent, it's correct. While a lot of phones have been broken wide open, the same flaw can be used by a hostile app to own your phone (to say nothing of what could be done to a vulnerable enterprise system).
"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
Some of this likely decision making by individual distros. If you do a base install with Arch Linux you'll get systemd and some other userland utils but not much else, and most of systemd-*d services will not be enabled by default which I discovered when my network didn't come up on first boot like I expected.
Personally I'm waiting to see if CentOS 7 will do a 'minimal' install spin like they did with 6.
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 ]
I found a ton of videos on youtube where the speaker claims systemd is the best thing since sliced bread. In most of them, the guy speaking was this weird person called Poettering.
Anyone know of any videos explaining why systemd is bad?
Thanks
I have no opinion on Torvalds having no opinion on this matter.
My ism, it's full of beliefs.
There's a simple reason for that: HPUX was and is not GNU is Not Unix. GNU/Linux is GNU is Not Unix. It has little to do with how much is GNU-written software but how this was the end result of building a Unix from free sources.
Agreed.
The real issue with systemd is that the vast majority of its development is funded by Red Hat. This means that while they claim systemd is modular, they don't accept any code that would actually facilitate that modularity by letting you replace udev with eudev, for example, because it's not useful to them and increases the maintenance burden.
Compare this to the kernel, which has deliberately been managed by a neutral party (the Linux Foundation) from the start. Can you imagine what the kernel would look like if it had been run by Red Hat, and only accepted code for kernel modules that were considered useful? My guess is we wouldn't have seen half the innovation we have, and things like btrfs wouldn't even exist.
Most human behaviour can be explained in terms of identity.
Systemd for all it's benefits, has evolved beyond what is expected from a staple init drop in. This is what happens when a bunch of arrogant developers drive a project without a clear thought at the helm. Red Hat will gladly jump on the bandwagon, seeing more is to gain in terms of paid support for a work-in-progress product. Brilliant business strategy, now to get the general audience to see through the features they'll soon be paying for to understand.