Torvalds: No Opinion On Systemd 385
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."
well said! (Score:4, Interesting)
Misleading slashdot headline (Score:5, Insightful)
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 (Score:5, Insightful)
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.
Re: (Score:2)
...monolithic and practical...
Of course, that depends upon one's opinion of "practical".
.
Some think that "practical" means a complex, overly interconnected maze of software.
Re:Misleading slashdot headline (Score:5, Insightful)
Practical is how we work. Monolithic or Micro based are independent of whether or not something is practical. What is practical in one situation (small robust control system with high availability) may not be practical (complex system of varying hardware) elsewhere.It is a matter of how close to sigma six you need to be, because each degree closer, is a magnitude more difficult to reach.
The fact is, you can talk all you want about what is "practical" in a specific case, and I may be arguing that your "practical" isn't practical for me and my specific case. We'd both be right, but not for each other. This is pragmatism at its core. One size doesn't fit all. Never has, never will.But you can build things so that One Size Fits Most, that works in 95% of the cases.
Systems that are outliers shouldn't be where we decide things for the 95%.
Re:Misleading slashdot headline (Score:4, Insightful)
Torvalds: UNIX Philosophy is Obsolete
I'm not sure that's accurate......it seems he's actually saying, "UNIX Philosophy is hard to implement in complex systems." It seems to me the reason he doesn't have much of an opinion is because he hasn't spent the time necessary to think it through deeply. There might be a better solution or not, he doesn't know.
And I think it makes sense......SystemD is a heap of trash, but System V isn't an example of great design, either.
Re: (Score:3, Interesting)
And that is part of the problem, that it is presented as a init vs init issue.
It has long since grown past that. Systemd, as a package, now holds udev, journald, its own cron replacement, a network manager, dhcp, ntp, inetd, etc etc etc.
But the crowning achievement may well be logind, that more and more DEs are getting a dependency on.
And logind can only function with systemd as the init, full
Re: (Score:3)
There are several inaccuracies on that list; systemd has timers that may be used as a cron substitute, but really is a different design, so therefore cron can happily co-exist, and nobody forces anybody to use the systemd solution. Systemd doesn't have a replacement for a N
Re: (Score:3)
therefore LINUX is obsolete.
so really Tanenbaum was right all along.
systemd is objectionable because: (Score:4, Interesting)
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.
Re: (Score:3)
Re: (Score:2)
I have no opinion on it.
Re: (Score:3, Funny)
I'm sure Linus is so broken up by your statement that he will have to cry himself to sleep for weeks.
Re: (Score:2, Funny)
Re: (Score:3, Insightful)
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.
Re:well said! (Score:5, Funny)
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! (Score:5, Funny)
Repent or be tormented forever by a Daemon
by the daemon called systemd....
Re:well said! (Score:5, Insightful)
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.
Re:well said! (Score:4, Insightful)
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.
Re:well said! (Score:4, Interesting)
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 this - complex systems *do* work this way, lots of small pieces interfacing with each other is the way complex systems work. Whether its a GUI app where each control is an independent object, or an internet where each website is independent or a business where labour is divided up into divisions or departments.
What happens when you try to make a complex system that is a tangled web of interconnections that have too many dependencies with each other is a system that does not work.
DRY, SOLID principles are all current buzzwords, but the truth behind them is that complexity is managed by standard interface protocols that allow components to be practically self-contained. UNIX got this right.
Re: (Score:3, Interesting)
Re:well said! (Score:5, Funny)
Simple set of pipelined utilties! (Score:5, Interesting)
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! (Score:5, Insightful)
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! (Score:4, Interesting)
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.
We all stopped using UNIX long ago, it's GNU/Linux now and it's only somewhat inspired by UNIX. What the UNIX people did 30 years ago is interesting from a historical perspective, but is not in any way the only right way to do things. I say did because that's now even how modern unices work. Solaris has for example been running on SMF since 2005 and they are doing just fine.
Re: (Score:2)
It's Linux, not GNU/Linux, no matter what Stallman insists. Linux is released under the GPL, but it is not, itself, part of the GNU project.
3dldf, a2ps, acct, acm, adns, alive, anubis, apl, archimedes, aris, aspell, auctex, autoconf, autoconf-archive, autogen, automake, avl, ballandpaddle, barcode, bash, bayonne, bazaar, bc, bfd, binutils, bison, bool, bpel2owfn, c-graph, ccaudio, ccd2cue, ccide, ccrtp, ccscript, cflow, cgicc, chess, cim, classpath, classpathx, clisp, cobol, combine, commoncpp, complexi
Re: (Score:2)
I'm not talking about the kernel, I'm talking about the operating system often referred to as GNU/Linux. Systemd has nothing to do with the kernel, except that it uses its functionality.
Re: (Score:3)
Re: (Score:3)
When I was in university,I used an HPUX system that had been heavily retrofitted to use all of the gnu applications and utilities that were available at the time. Nobody ever insisted that it ever should have been called GNU/HPUX. At east one release of Minix extensively used gnu software as well. If that was ever an expectation of Stallman's for operating system installations that heavily depended on GNU, then should have been in v1 of the GPL. Doing otherwise, and pulling this only after Linux had started to acquire some notoriety of its own makes him look just as bad as people who sit on patents until some really big company start to use it without knowing about the patent, and start enforcing it only then.
Agreed. Even Solaris uses mostly GNU software now. So are you going to call it GNU/OpenSolaris or GNU/Solaris? Or GNU/MacOSX?
No. It's just Solaris, OpenSolaris, and MacOS X.
Re: (Score:3)
I use GNU/Windows [cygwin.com] ;-)
Are you even aware of SystemD works? (Score:5, Insightful)
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.
Re:Are you even aware of SystemD works? (Score:5, Informative)
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.
Re:Are you even aware of SystemD works? (Score:5, Informative)
(Reliable process supervision which cannot be evaded,
cgroups existed before systemd.
the cgroups functionnality existed in the kernel but wasn't really used that much before. /etc/init.d/apache can't without fumbling of shell scripts.
systemd, with its tasks in setup/startup of things can handle the creation of jails during lauch when needed.
whereas current
sane handling of process stdout/stderr
Up to the init script.
And thus each script end up fucking things up in its own original and different way.
proper handling of dependencies at runtime
Already handled by several init systems.
None of which are the original sysvinit.
Either it's relying on LSB-extended script and a different core which starts the scripts. (Debian had a makefile based one)
Or it's an entirely new system anyway like upstart.
socket activation
We call it inetd.
Or cron if it's time-based activation. Or udev if it's hardware based activation. Etc.
Why do we need 83 different way to start some code ?!
Wasn't the whole point of Unix philosophy having one piece of software which concentrates into doing one thing and doing it well?
With systemd, setup/startup/stop/teardown responsibilities are concentrated with PID1 and it's helpers.
Before, you'd have the same concept spread into a dozen of different systems, each only doing part of that functionnality.
I like systemd, it makes my work easier on desktop, on server, on virtual machines, etc. and although it used to have hiccups when it was introduced before in opensuse, by now it has had the time to mature.
no need to bash it. if you don't like it, don't use it.
and perhaps the fact that it's slowly gaining popularity in lots of mainstream distro might be due not because systemd is "a spreading cancer" but because systemd is actually useful and solves real world problem
Also concentrate it in 1 point. (Score:5, Informative)
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".
Re:Simple set of pipelined utilties! (Score:5, Insightful)
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! (Score:5, Informative)
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.
Re: (Score:3, Informative)
Xorg, which on desktop is as critical as init to keep running, is not really simple.
Never go full retard. X is not even remotely as important as init. For one thing, if X dies, who will restart it? And do we really want computers that explode when the GUI dies? I, for one, would like network services to terminate gracefully. The whole idea of TCP/IP networks, the dominant network used with Unix, is peer-to-peer. I may well run both services and clients on my machine. If X dies, the clients may die (if they're not text and running in screen) but the servers won't.
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.
So the argument is that sin
Re: (Score:3)
Untrue. I've had the X server hang up and I've logged in via the network and killed it and restarted it. I can't restart systemd without restarting the whole system. Furthermore, I don't run the X server on our mission critical machines.
Re:Simple set of pipelined utilties! (Score:5, Insightful)
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! (Score:4, Informative)
You can't seriously claim that systemd provides nothing that can't be done by script based init systems, shell scripts and existing daemons
Yes, yes I can. And I did.
logind is just one example
Does nothing a script can't do
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"
Systemd doesn't even fucking use capabilities, just cgroups. Which we could use before systemd. Systemd manages permissions in lieu of using capabilities, e.g. apparmor or selinux.
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?
No. That is the virtue. They are simple. Simplicity is still a virtue.
All the analyses I have seen shows that moving crucial processes into PID2, just makes everything more fragile and opens up security holes.
Making PID1 more complex 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.
NIH
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,
This is making init do stuff it doesn't need to do, which makes it more complex, which makes it more fragile. You should not need a detailed explanation to understand why this is a bad thing.
Re:Simple set of pipelined utilties! (Score:5, Informative)
logind is just one example
Does nothing a script can't do
Do you really think it is a serious argument is that you could re-implement "logind" as a bash script? We are talking serious hardcore system stuff here, which is why no-one have made an alternative to "logind" or "ConsoleKit" despite upstream projects have pleaded for such a program for several years.
Systemd doesn't even fucking use capabilities, just cgroups. Which we could use before systemd. Systemd manages permissions in lieu of using capabilities, e.g. apparmor or selinux.
You are seriously misinformed on how systemd works and what it can do:
It uses kernel namespaces and capabilities to protect the system; this is on top of SELinux etc.
Here is a general overview:
http://0pointer.de/blog/projec... [0pointer.de]
Here are some of the config options for the daemons you can use. See "CapabilityBoundingSet=" for one way of using kernel "capabilities":
http://0pointer.de/public/syst... [0pointer.de]
There are so many freaking cool security features in systemd. As time goes by, developers, distro maintainer, and systemd administrators, can add more and more options to the running processes, like "NoNewPrivileges=" to prevent privilege escalation, or "ProtectHome=" to prevent malware and exploited processes from stealing info from /home, even if they otherwise had permission to read in home.
All this great new stuff can be turned on and used by adding a simple keyword to a structured text file. As time goes by, systemd distros will become ever more hardened.
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,
This is making init do stuff it doesn't need to do, which makes it more complex, which makes it more fragile. You should not need a detailed explanation to understand why this is a bad thing.
Well, it does need to be handled somewhere; if you want features, you will get complexity, it is that simple. But as explained, the features and complexity isn't running in PID1; PID1 (systemd) is just a hub for relaying those features to other processes.
I really think so much of the systemd opponents talk about "Unix way" and "PID1" should be simple, is hand waving to gloss over the fact that the non-systemd distros have no feature parity with systemd to speak of; SysVinit is crude and no one in their right mind would design a init system these days with executable config files. Service configuration files should be non-executable text only.
General and vague criticism against systemd really doesn't convince anybody. Anyway, the Linux community have spoken with a large majority of Linux distros using systemd in the future.
If SysVinit systems really have all the features of systemd, just much better because they are simpler, you would expect a "SysVinit" boom in the future with lots of developers and users.
Personally, I think the systemd opponents are too concerned with negative campaigns against systemd, that they entirely forget to code any alternatives, so I predict ever more distros like Slackware abandoning script based init systems; they simply don't have an alternative.
Re:Simple set of pipelined utilties! (Score:5, Interesting)
The complaint is that the process at PID 1 should be simple.
That's just passing the buck. What you don't do in PID 1, needs to be done by PID 2 or 3 or 4...
One has to understand that system start up is a complex task. Systemd, sysvinit, launchd, and what-not are just a matter of optics, no matter which one you choose, you are only changing how you look at the problem, you aren't making the problem any easier. That's the important thing to remember, that all of these inits are just different views on how to solve the problem. No matter how many times you break the process up (into PID 4 through 380), it's still a complex task that needs to get done.
That said, sysvinit comes with the idea that you're going to have a lot of people looking inward at what's been done historically, they're going to make really useful tools, and the expectation is that those that follow will use those tools. That's nice and there is a real benefit for that, but that's not what vendors are going after, that's not what third-parties want, and that's not what end-consumers want. The only people that sysvinit caters to any more is developers and neck-breads. Vendors are going to write their own tools for start up. Third-parties are going to package up the process into something that can be simply delivered to the customer. Standard end-users just don't give a shit so long as the screen comes up. Heck, even server admins won't really care so long as management can still log in. There just isn't clientele for the old way. That's not to say that the old way isn't useful, but honestly you are asking a bunch of Pepsi drinkers to switch over to Coke for just the sake of "it is easier to make."
SystemD puts all the cards closer together, this allows smaller teams to do useful stuff, and let's face it, the number of people writing kernel, sub-system, and start up code is only going to keep dropping. The hotness is much, much higher up. Vendors like systemd because it works better than script->call program in their deployment cycle. Now they can use systemd reporting to bubble back up into the UI as oppose to writing to some arcane log file. No one can defend the old log files, they seriously were so confusing that there are companies that you can hire and tools that you can buy that can turn your log file into something easier to read. That's just indefensible. I'm not saying that systemd is some magical power that's turned a turd into gold (starting up a system is still a pain in the ass), but it serves a wider group that more than likely (as all the neck-beards die off from old age) will be maintaining this whole thing in the longer term and simplifies something that has gone from, "it was good and easy" to "holy crap! The log file is 23MB!!" Back when we were starting up an FTP server and that's about it, it was great, but now that every sub-system from the kernel feels a need to write to the log on top of everything else that you vendor starts up, it's just a flipping mess.
It's important to remember the Unix way, but systems have gotten so complex we just don't do it that way in reality anymore.
Re: (Score:3)
That's true, but pid 2 crashing won't halt the system, because pid 1 can restart it. If pid 1 crashes, it's power cycle time.
If PID2 is responsible for critical features like eg. cgroups which affects all running processes, including PID1, then it won't make a difference.
I do really think that the systemd designers have actually done their homework quite well when they started out. PID1 is quite small and only contain what is needed, everything else runs as helper processes.
Besides that, systemd can supervise itself (PID1) by using a watchdog, so the system can react if PID1 doesn't answer the watchdog "ping".
http://0pointer.de/b [0pointer.de]
Re: (Score:3)
This isn't the 1700s anymore. Next to no one gives a shit about The Constitution or its "philosophy" anymore outside of neckbeard circle jerks.
A philosophy doesn't become irrelevant, simply because it is old.
Re:Simple set of pipelined utilties! (Score:5, Insightful)
Re:Simple set of pipelined utilties! (Score:5, Funny)
hokey philosophies and ancient pipelines are no match for a modern java GUI IDE
-- Han Slowmo, Unix Wars, episode IV
Re:Simple set of pipelined utilties! (Score:4, Insightful)
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.
Re:Simple set of pipelined utilties! (Score:4, Insightful)
Are you suggesting that Systemd is prone to crash?
Re: (Score:2)
It doesn't even need to be "crashing". It could simply be "user error" incurred because the system is more complex, more difficult to deal with, and new and interesting "user driven" failure cases have been added.
Upstart is a real peach in that regard. I've blown my toe of with it already. If SystemD is anything like that, no thanks..
Re: (Score:2)
If its doing more than it should be then yes, theres more code that could have bugs, unhandled exceptions, etc.
Its the same logic thats applied when hardening a system, minimize what it is running so there is less that can be attacked / have a bug / crash.
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
Pipeline intercommunication aside, most large programs of any quality *are* formed from a bunch of small "do one thing well" utilities. They're commonly called "libraries".
Emacs is *one* thing he's written. Wasn't he responsible for the first versions of pretty much *all* the GNU userspace tools? You
Re: (Score:2, Offtopic)
Pipeline intercommunication aside, most large programs of any quality *are* formed from a bunch of small "do one thing well" utilities. They're commonly called "libraries".
Hit it dead on.
People don't want the added work of making things work. It's like building a floor: you need to strip off the old finish, reenforce the subfloor, ensure the floor is level, pour thinset, roll ditra, pour more thinset, lay tile, clean, and grout. Some folks leave old linoleum or hardwood flooring, claiming it's stable, and then pour self-leveling compound or just screw down concrete board, then put tiles on top. Some just cement tile straight to the floor, or pour SLC and cement the til
Re: (Score:2)
It can be a collection of utilities all dependent on each other, running 3 or 5 or 15 services all communicating with each other, all to bring up the system and supply system state management. This is the simplest and easiest way to make a complex system
Why not make 3-15 modularly written sets of source files, and compile them into a single binary ? It's hardly more complex than 3-15 separate programs, and it makes communication of structured information a lot easier.
Re: (Score:3)
It can be a collection of utilities all dependent on each other, running 3 or 5 or 15 services all communicating with each other, all to bring up the system and supply system state management. This is the simplest and easiest way to make a complex system
Why not make 3-15 modularly written sets of source files, and compile them into a single binary ? It's hardly more complex than 3-15 separate programs, and it makes communication of structured information a lot easier.
And is in fact, how SystemD is put together and intended to be expanded, for better or worse.
Re: (Score:3)
Religious sentiments aside, systemd scratches a number of itches that eventually needed to be addressed. The main one is parallel startup of daemons. On a SSD based machine (and note, these are anecdotal runs), CentOS 6.5 takes about a minute to fully boot to a login prompt. On CentOS 7.0 with systemd starting anything that isn't relying on another process at the same time, well under ten seconds. Similar with a shutdown.
The second item is being able to place processes in containers and set limits befor
Re:Simple set of pipelined utilties! (Score:5, Insightful)
> 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.
Yes, pipelined utilities, like the logs (Score:5, Insightful)
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.
Re: (Score:3)
You don't have to. If you really want your old way then just have journald pass everything along to syslog and it's back to normal.
Re: (Score:3, Insightful)
Unfortunately that's not quite true. You *can* configure systemd to spit out text logs as well as the binaries but that is a delayed process, so in the one case where you MOST want text logs (where a crash has occured with the file open) it's absolutely worthless.
Re: (Score:2)
Some of us like the new features.
Re:Yes, pipelined utilities, like the logs (Score:4, Insightful)
That is a valid complaint. Adding functionality so startup is parallel is one thing. Having one's own binary log format [1] is a big downside. To boot, rsyslog uses cryptographically signed logs. That means that I lose protection on systemd's logs because in theory an attacker could tamper with those. Should the logs go to rsyslog, the files either will show tampering or be missing.
This also prevents logging to a remote machine as well.
I'm not a fan of binary logs. Even AIX will log stuff from the errpt command if you turn on the right syslog settings. Binary logs make a program like Splunk a necessity, and that is not a cheap tool once you start talking about gigs a day hitting your index servers.
[1]: I don't like the "pro" for it saying that journalctl can give you just the info that you need. For the info I need, I have grep, egrep, and many other tools.
Re: (Score:3)
1) You can still use rsyslog (or syslog-ng or ...) with journald if you want and I believe all the major distros still do: http://blog.gerhards.net/2013/... [gerhards.net]
2) journald supports "Forward Secure Sealing" to prevent tampering of its logs: http://lwn.net/Articles/512895... [lwn.net] See the "Seal" option in journald.conf: http://www.freedesktop.org/sof... [freedesktop.org]
Re:Yes, pipelined utilities, like the logs (Score:5, Interesting)
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.
Sometimes new stuff is actually much better than then old stuff. I was skeptical about binary logs until I actually tried it. The advantages of a indexed journal is overwhelmingly positive. "journalctl" is an extremely powerful logfilter exactly because of the indexed and structured logs. .xsessionerrors and what not; everything goes into the journal.
Systemd's journal also collects all logs in the same place, so no need to use "last" to read the binary "wtmp" log files, or locate
Also, all the usual text tools like grep, tee, sed etc. all works with the journal by the standard Unix concept of piping. "journalctl" simply enhances the Unix text tools.
Give "journalctl" a serious spin someday; you may like it.
The problem... (Score:5, Insightful)
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.
Re: (Score:3)
The journal is primarily append based, so it designed to be very robust against corruption, the log is also rotated whenever a corruption is detected. So usually the corruption you see are a single line that was malformed when writing because e.g. the daemon died unexpectedly; this happens all the time with text based logs, but because they have no inbuilt integrity checks like systemd, it doesn't get discovered.
So in most cases you don't really loose any log info, and the rest of the log remains fully read
Re:The problem... (Score:4, Informative)
I've been a sysadmin for 20 years, and I've seen systems break in lots of interesting ways. What I want is a log mechanism which is as simple as possible so that it as least has a chance of giving me the info I need even if the rest of the system is in the process of going to hell.
What I don't want is an unnecessarily (you aren't even able to explain the advantages, actually some of your "advantages" are disadvantages like the corruption detection) complex system which will take ages to debug, IF it will ever be - most software is already too complex and too fast moving to be ever debugged sufficiently. It violates the KISS principle. And the advantage of Linux over Windows used to be the KISS principle...
systemd's logging facilities are superior to old syslog in several ways. Fx. systemd and journald lives in initramfs while the system is booting, so it can collect logging info from before the root fs is even mounted. Since systemd actually have knowledge about mount points and files systems, it can also delay to the very last moment the things needed for journald to write to the log.
There is also kernel guarantee that the daemons/pid's/programs that appear in the log are the real ones since systemd have total control and supervision of all processes. So if "lp0: printer on fire" appears in the log, you will know whether it is a prank or a real message.
The structure and index makes it possible to store lots of interesting meta-data, like monotonic time-stamps, GUI, PID, command line, marks from where every boot started and ended ("journalctl -b -p err" shows all loglevel "error" messages generated last boot only). Using monotonic timestamps to compare two boot sequences on perhaps two similar machines, is quite interesting and very easy to do.
It also allows for multi-language log support, supplementary help files that can explain what the error message means, suggest how to solve the problem, etc.
Here is a list of fields in the journal. Because of the index, the journal have real time knowledge about what is written in the fields, so there is tab completion and extremely powerful sorting available:
http://www.freedesktop.org/sof... [freedesktop.org]
If you care about logging with systemd, take a look a the original design document behind journal
https://docs.google.com/docume... [google.com]
Notice how simplicity is design goal number 1.
If you intend to remain (a paid) Linux sysadmin in the future now where all major distro are starting to convert to systemd, you should really study systemd's journal.
It is much easier to "get" the power of a indexed and structured log file by trying it, than describing it. Fedora 20/CentOS 7 are reasonable choices to learn it on.
check out systemd's "nspawn" too: OS containers really are the future.
Re: (Score:3)
None of which requires that logging be moved into PID 1. Instead, all you need is the ability to support a new log format in some syslogd. Unless you were some kind of moron, you'd design the new program to be able to log to both text and binary formats at the same time so that you could enjoy the benefits of both formats. Systemd may or may not do this, I don't care; there's no reason whatsoever why logging should not be a separate daemon.
Logging isn't done by or in PID1. It is done by the "journald" daemon that have its own pid. I must say, that whoever telling you about how systemd is designed and works, doesn't have a clue what they are talking about. I strongly suggest you check out the systemd homepage for some basic information about systemd.
http://www.freedesktop.org/wik... [freedesktop.org]
People are hard to satisfy: some complain that systemd replaces daemons, and now you complain about it _doesn't_ replace syslog for writing text logs?
People who wan
Re:Yes, pipelined utilities, like the logs (Score:5, Funny)
In fact, you have *two* programs to read all logs. More and less.
Re: (Score:3)
If web browsers and other modern programs do not follow the "many small tools doing 1 thing well" model, that's only due to programmer mediocrity and market pressure.
It would be a much better world if I could just replace the JavaScript-interp
Re: (Score:2)
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.
You seem to think that those hating on systemd like having to use bloated, slow, barely-configurable, GUI-only, privacy-hemorrhaging browsers just to access their {bank/email/news/etc.}.
The existence of some high-profile non-UNIX projects isn't an excuse to dismiss UNIX practices. In fact, popularity is often correlated with barely-adequate, lowest-common-denominator offerings (eg. pop music).
"Do one thing well" and pipes aren't the same (Score:3)
"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
Re: (Score:2)
I'll buy that GW is dangerous when ALGORE sells his beach house
The beach house that's 2 miles from the beach, at an elevation of 510 feet?
How about all of his oil shares?
http://www.forbes.com/sites/la... [forbes.com]
This thread is only for ignorant argument (Score:2)
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.
Re: (Score:3)
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.
systemd (Score:5, Informative)
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... [wikipedia.org] - because TFS, TFA and links from them don't tell you much in this regard.
Sounds like Mr. Torvalds has an opinion. (Score:2)
"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.
Re: (Score:2, Informative)
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.
Do it well (Score:5, Informative)
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.
Re: (Score:3)
That is, support *functional* dependencies between processes,
Well, explicit stated dependencies are there. If you mean something beyond that, I get very concerned.
caching of input/output.
What i/o are you referring to? I/O generally is already cached as intelligently as the filesystem or block subsystem can manage. At filesystem or lower or inside the application are your opportunities to enhance things, not much room in between. If you mean cache data that is piped around or networked around, that is absolutely a horrible idea that is really infeasible unless it
Now ask him if he trusts systemd upstream "taste" (Score:5, Informative)
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.
Re: (Score:3)
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.
Torvalds is neutral (Score:5, Funny)
Re:Torvalds is neutral (Score:5, Insightful)
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!"
Wow, a dose of pragmatism... (Score:2)
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.
Re: (Score:2)
> You mean.... gasp! ... PostgresSQL isn't a shell script pipelining a bunch of sed/awk/grep/mv/cp commands?
In terms of the larger systems that it is integrated with, that is EXACTLY what it is. It is a highly specialized application that does one thing well and leaves the scope creep for other programs that consume it's services.
It may even be broken down into a lot of highly specialized background processes like Oracle.
Fortune (Score:2)
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.
So what's wrong with systemd, really? (Score:5, Insightful)
(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 [wikipedia.org] ##
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: (Score:3)
Binding previously-separate features into one project is bad design, by itself, the problem with systemd.
Why? Justify that statement without using any reference to the UNIX way or it being the way things have always been designed.
IMHO a coordinated set of functions that are used in a common way should be combined. Why is it that to parse a log file I need to run grep, and sed, and all these other utilities in a continuous pipe? For that matter why should the tail command be able to open a file, is that against the unix way because everything should be grepped into it?
I'm getting sick of using 1000 different ut
Re: (Score:3)
You know I heard a computer fault once killed someone. We should ban these computer things. Wait what? Oh we weren't playing the "Use the most extremely bad example and extrapolate it to mean everything is bad game?"
No I don't mean the Windows Registry. That should be called out for the load of garbage that it is. But if you want to dig through windows internals there are plenty of examples of one stop common configuration stops that make me want to go out and stab all people faithful to the UNIX philosophy
I Can't Agree More (Score:3)
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.
Why would Linus care about systemd? (Score:5, Insightful)
Whatever (Score:2)
He clearly doesn't understand Linux.
Arguably Linus Torvalds understands Linux better than the rest of us.
Re: (Score:2)
You've been away for a while, haven't you.
Re:i don't have any opinions (Score:5, Funny)
He said he didn't have any colorful opinions on it. I thought Linus couldn't make breakfast with out swearing twice.
Re: (Score:3)
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
Re: (Score:3)
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!
Re: (Score:3)
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.
Re:One down... (Score:4, Funny)