From just a purely end-user perspective, systemd is an application that I’ve come to like a lot. And I think that its adoption by all Linux distributions will make it easier to manage Linux systems.
But it has come under heavy criticism from some quarters – for trying to be a Swiss-army-knife-type application. One that does practically anything and everything, which the critics claim is against the UNIX/Linux philosophy of coding an application to do one thing and do it well.
For those who are not yet familiar with systemd, here’s a short and to-the-point description of that it is:
systemd is a system and service manager for Linux, compatible with SysV and LSB init scripts. systemd provides aggressive parallelization capabilities, uses socket and D-Bus activation for starting services, offers on-demand starting of daemons, keeps track of processes using Linux control groups, supports snapshotting and restoring of the system state, maintains mount and automount points and implements an elaborate transactional dependency-based service control logic. It can work as a drop-in replacement for sysvinit.
To the critics, all those capabilities are exactly the problem with systemd. And they feel so strongly about their position that they set up a website where they listed all the ills of systemd. And I must say that many of the points they list on that website make sense. Here’s the first one:
systemd flies in the face of the Unix philosophy: “do one thing and do it well,” representing a complex collection of dozens of tightly coupled binaries1. Its responsibilities grossly exceed that of an init system, as it goes on to handle power management, device management, mount points, cron, disk encryption, socket API/inetd, syslog, network configuration, login/session management, readahead, GPT partition discovery, container registration, hostname/locale/time management, and other things. Keep it simple, stupid.
That makes sense, if you think about it and what could go wrong. Here’s another point:
systemd doesn’t even know what the fuck it wants to be. It is variously referred to as a “system daemon” or a “basic userspace building block to make an OS from”, both of which are highly ambiguous. It engulfs functionality that variously belonged to util-linux, wireless tools, syslog and other projects. It has no clear direction, other than the whims of the developers themselves. Ironically, despite aiming to standardize Linux distributions, it itself has no clear standard, and is perpetually rolling.
I’m really not sure where I stand on that, because I really don’t mind having an application that does a bunch of stuff, provided it does them well. One question I have is this: If the guys behind http://boycottsystemd.org/ are right, and I’m not sure whether they are or not, even though some of the issues they raise make sense, why did the people responsible for the development of the major Linux distributions accept it as a replacement for old init system?
By the way, systemd is the default on Fedora and will be in Ubuntu and Debian by the next major release of those distributions.
I would naturally think that if the greater Unix/Linux community feels that systemd designed with more modularization is essential, then it will eventually evolve in that direction. Can it not? Is it so poorly architecture that there’s no chance of that ever happening?
I don’t really have a issue with the using of SystemD, my issue with it is of course
the idea that it is a perfect breeding ground for NSA backdoors.
Redhat has the most government contracts out of any Linux based company,
in fact a ‘Red Hat’ as far as I could find info on is a hacker working for the
government against enemies both foreign and domestic.
I don’t want to be one of those ‘enemies’ that a over paranoid institution
has a backdoor built right into my system, or all Linux systems.
And like others have said that it is very much a Microsoft style power grab
but only a little different in form from their standard embrace, extend, extinguish.
I would like to say that is a lot I agree with in the design goals of SystemD, my concern is that it is a power grab to uniformly backdoor the Linux ecosystem, and will be used
to extinguish all competing technologies once its power is solidified.
What happened to http://boycottsystemd.org ? Safe to say now that Debian and Ubuntu had gone the Systemd route that they gave up on Boycott?
Perhaps they gone stealth. They might resurface sometime in the near future with a fully-functioning distro 😉
I migrated fully to NIX after 10-15 years as a Win admin and got tired of having control “hidden”. Worked with ESX and used the console and loved the freedom. The trend I am noticing with the systemd debate is VERY similar to what has happened with M$. Keep It Simple Stupid is something Nix should be doing, having things modular and not depending on something else makes life easier. If one thing breaks it’s not taking everything else with it. Further, if this is all done in binary and not easily read THIS IS NOT GOOD. I hated M$ making me download other crap to diagnose their BSODs if you like having your system flipping out and not saving your data then I guess systemd would be for you given it’s direction. This is also akin to making your browser part of your OS and having it intertwine with it. (Bad Voodoo) I’m using Mint and looking for a possible way to decouple from systemd. I just don’t see this as a good thing and it reminds me too much of M$ tactics. Now is the time to deviate from systemd and keep a more modular approach then watch and see if systemd starts to be an issue, which at this point if it keeps taking over more management it’s only a matter of time. I also wonder if the M$ embracing open source has anything to do with this, it certainly smells of large corporation thinking or lack there of. I like improving things, but this does not appear to be an improvement rather a bomb waiting to go off. On these points this is a bad idea, binary not an easy way to gain insight and correct issues and adding multiple processes to control with more being added. I was able to patch heartbleed within 15 minutes after finding out about it. In the M$/corp world good luck hope it’s this month.
I will admit right off, that I am not a linux designer or maintainer. I got started with linux about 20 years ago. People state that the old init system was fragile. Maybe it was, again…not building linux from scratch I wouldn’t know. I don’t recall ever having any issues though.
Whether right or wrong, from my (very) limited understanding, the systemd process is driven by binary files, which are not really meant to be edited or looked at by hand. So if something catastrophic happens (which granted hasn’t happened yet)…how would I fix it or know what to fix? Go to my distro’s forum and hope someone can fix it/release a patch soon?
Anyway, if one of the earlier commenters is correct, and there is no specific plan for systemd (which frankly is a scary thought)…how much more of the system will it continue to take over? And at what point does too much become too much?
I’m all for progress, but I think the Keep It Simple Stupid approach, which may not be “exciting” stuff to develop, it still the best approach.
“why did the people responsible for the development of the major Linux distributions accept it as a replacement for old init system?”
I can’t speak for the initial decision, but at this point, I would suspect that inertia is keeping it in place. I highly doubt that any of the major linux desktop systems that must current users depend on would even function without systemd…at least not without a lot of major programming changes to make it happen. If someone did take that route, then all of those custom changes then need to be maintained.
(Simplistically thinking) Why can’t things be more pluggable/portable? Distro X uses a systemd plugin for their init, and distro Y chooses to build against something else? Granted systemd is most likely now too big for that, but one can dream I suppose.
Yes. Systemd is a trojan.
Systemd is a perfect system for rootkits, and NSA backdoors.
Once it will be complete it will hide necessary processes even from root, it will filter unnecessary events from log, and it will do much much more.
But it seems, that only lower minority care about that.
IMHO, the downside of systems as a project is that its parts lack a defined stable interface. This means that you cannot replace one part with a different one, creating your own stack of tools. When you configure your desktop system, you can combine any display manager with any window manager with any panel or file manager. Can you replace networks with another tool transparently? If yes, can you be sure that your tool will keep working after the next systemd upgrade?
s/networks/networkd/
The reason Debian (and therefore Ubuntu) adopted SystemD is that the appointed Debian tech team is now devided equally between Ubuntu devs (which were Debian devs before Ubuntu came along) and Redhat employees. Look at the voting emails and 3 months of arguments.
The biggest issue is really not one of SystemD infiltration, but more of Redhat taking over every aspect of the Linux development process. Time and again, I have seen Canonical steer in their own direction, not because they want too go rogue, but because the upstreams for the main projects (Gnome, Wayland, Pulse Audio, now SystemD and possibly OpenStack, and even the kernel to some extent) are almost exclusively owned by Redhat, and only wish to make forward progress at their own pace (wayland has had almost twice the development time and resources as mir for example).
The REAL issue here is; who has the Linux community in their best interests? Do some real investigation and write a story on that.
There aren’t any Red Hat employees in the Debian CTTE. Ian works for Citrix, Steve and Colin for Canonical, Keith for Intel, Russ worked for the Stanford university and now Dropbox, Bdale worked for HP (and later for Samsung), Doc is postdoc at the University of Southern California and no idea for Andreas but certainly not for Red Hat.
Given your fallacious first statement, please understand that I don’t want to spend brain time on the rest…
I think systemd is a BAD THING…forced onto Linux, eventually becoming a dependancy which will be impossible to change from. When it breaks something else (as it will do), the developers will always blame the broken utility for not moving with the times. The issue is the bunch of us that say “As long as it works, who cares”. This encompasses the majority of folk, including possibly me. I would suggest even something like upstart was a far superior alternative, with fewer dependencies and easier to debug…but those systemd guys also happen to be bigger than me.
When I found out that systemd was written by the same person/people who made Pulse Audio, I realized that I didn’t like them for the same reason.
Wow, what a great argument. Nothing like an ad hominem to advance one’s cause.
The fact is system v init never did work very well, and has always been extremely fragile. anyone who’s worked with init scripts can tell you that. every script reivents the wheel for things like preventing more than one instance of a daemon from running, or keep-alive functionality. Linux is hardly the first to ditch sysv init. Every major unix out there ditched sysv init years ago for the very same reasons. Solaris has SMF (yuck), Apple has launchd (better). Systemd is better than both once it does mature a bit.
I’ve been running systemd for the last year or two and have had no problems. I don’t care much about boot times, but I do think the ability to daemonize some little python service I wrote with only a 3 or 4 line config file rocks. Especially because I can hand off daemon handling to systemd and it just works. With a simple API I can also have systemd open and manage sockets for me, and it’s still backwards compatible with systems that don’t have systemd yet. It’s a win win. It’s not something totally amazing, but it is a nice evolution.
Do you also consider it an “ad hominem” to consult a builder’s portfolio before hiring them to construct a new building? For that matter, did you somehow miss the entire practice of having job applicants submit a “resueme”/”CV”?
Past projects that demonstrate that an engineer has a history of poor-quality work is *very* relevant in judging if you want to trust their new project.
Exactly what makes systemd better than both launchd or SMF? I constanly see people say stuff like this with regards to systemd but offer no explanation as to WHY. Like they’re just repeating what someones else claims.
Just because it’s new and shiny, or because it can do much more doesn’t do it for me. These are often repeated but hollow statements.
systemd does its job well, but it is an immature design. Once systemd gets old and the next generation of Linux developers comes along to replace what they believe is broken will systemd prove to be a major pain, because of its many dependencies. Hence it is not going to have a long lasting future. The concepts carried on with UNIX however have endured for many decades and I believe it will outlast its challengers. It is actually good to challenge old concepts once in a while. If they survive will they only prove their stength.
I see their point, and they are right. Its like having a refrigerator that doubles as an oven and a water heater all in one. If it breaks your whole system is hosed.
However, if it works, who cares?
To run with your last statement, which I tend to agree with, two things about systemd trouble me:
The first is that they are indeed “tightly coupled binaries”, which in my experience means that if any one breaks, it’s going to effect the others.
The “Unix Philosophy” has given us an environment where if one thing breaks, it only breaks the one thing. So the “tightly coupled” part of the systemd suite seems to me to be a step backwards.
Second, systemd (as a name for all of the “tightly coupled binaries”) utilizes extra special functions of the Linux kernel. This makes it Linux specific, and possibly specific to only limited versions of the kernel.
This violates the “portability” idea.
Neither of these are deal breakers if, as you say, it _works_.
But just like Richard Stallman said of HURD, when it doesn’t work it’s going to be hell to debug.
Strange, is it not, how when you go to buy a multi-function printer/scanner, the advice is “don’t – too much complexity increases the likelihood of failure”. The same idea holds for hifi systems – separate units, one per function is best, multi-purpose towers are, by reputation, a bit rubbish. Ditto for TV’s with DVD players built in.
Etc.
But suddenly we can kick all this out the window and go for a more complex operating system and it’s all going to be just fine and dandy.
If you want to understand better the point of view of those opposed to systemd, read “Linux and the Unix Philosophy”.
I can only endorse that 100%.
If you do not understand the Unix philosophy you end up with Windoze.
Remember Microsoft was a Unix developer at one stage but they go for big integrated packages which are impossible to debug
“Not only is UNIX dead, it’s starting to smell really bad”
“We really are using a 1970s era operating system well past its sell-by date.”
(Rob Pike)
“[Linux] also certainly isn’t “Unix” as that is fairly dead. It met needs in the 60s and 70s and even to some extent the 80s quite well. But the needs we have today are very different.”
“Lots of separate tools only do 90% of the work. To do really complete work, you need real purpose-built tools. “do one thing and do it well” is good for prototypes, not for final products.”
(Neil Brown)
As you are praising the UNIX Philosophy, what do you think about these statements from two major UNIX personalities?
I’m not going to agree or disagree on whether UNIX is dead or not, but one thing is certain: Linux and UNIX-like operating systems are the best game in town. Just look around you. From the tiniest computing devices to supercomputers, Linux rules.
“do one thing and do it well” is good for prototypes, not for final products.”
I’ve heard some nonsense in my time but that takes the biscuit.
As we all know – multi-purpose tools are generally of lower quality and tend to break sooner.
And that’s why a spade is a spade (I’m English, forget your racist connotations) and no one has tried to make the spade into a dual purpose spade/hoe/fork.
There is a generation of people around at the moment who think that to change things is proof of their superiority when in fact it’s only proof of their arrogance and lack of wisdom.
Well you seem to know better than Neil Brown 🙁 And as you say, there is a generation of people around at the moment who think that to change things is proof of their superiority when in fact it’s only proof of their arrogance and lack of wisdom, including you…
Well you seem to know better than Neil Brown
Sorry. Is he a demi-god, incapable of error?
So, Unix is dead, or fairly dead? And Linux certainly is not Unix? So, does that mean Linux is alive and kicking, or is the point that Linux is just another way of beating a dead horse? And if Unix, or whatever it’s called these days, is dead and does not meet the needs of today, what is it that businesses are running their servers on? (I guess that would be nothing that resembles Unix.) Maybe, just maybe, the rest of the world did not get the memo from Rob and Neil. Better send that one out right away. No, wait. If they turn off all those not-Unix servers, the Internet will go down. Just kidding. Go ahead, unplug them and plug in whatever it is that Rob and Neil propose as a replacement. Which is… ?
@Scott
Plan 9 😀
Plan 9… of course! (face palm) Stupid me. New plan: UNinstall not-Unix. INstall Plan… hey, Hey, HEY! Oh, right. It’s a secret Plan. Shhh… ;^}
Except you, the author, has fallen into the same trap everyone else does… Confusing Systemd (the project) with systemd (the binary). Systemd, the project, is like Apache, its an umbrella term for a lot of other things. Systemd, logind, networkd, and other utilities.
Systemd, the binary, handles service management in pid1, that includes socket and explicit activation. Other tasks it passes off to non-pid 1 processes. For example: session management isn’t handled through systemd pid 1, its handled through logind.
Readahead is handled through a service file for systemd, just like other daemons.
syslog functionality isn’t handled in pid1, its handled in journald which is a separate process.
hostname, locale, and time registation are all handled through explicit utilities: hostnamectl, localectl, and timedatectl, which are done as separate processes.
Network configuration got added in networkd. What is networkd? The most minimal network userland you can have. Its for people who don’t want to write by-hand config files, but for whom NetworkManager is way overkill. Is it pid 1? Nope.
Yes, systemd started off as “just an init replacement.” It grew into more things. But don’t assume that “systemd” (the binary) is the same as “systemd” (the project). Most things that are added to systemd in recent times AREN’T pid 1 like boycottsystemd claims, they’re just small utilities that got added under the systemd umbrella project.
Ericg, thats the problem
systemmd has become a whole integrated stack
init.d while not easy to use for starters, was at least within the idea of simple units which can be mixed and matched to get the results the user wants – note user wants – not developer wants
hostname, locale, and time registation are all handled through explicit utilities: hostnamectl, localectl, and timedatectl, which are done as separate processes.
Missing the point.
People talk as though prior to systemd such tasks were beyond Linux, didn’t work, always crashed, were a nightmare to use or manage and that is not the case.
The only difference I see between my Linux machine now and my Linux machine of a few years ago is that it now boots faster. And that’s it. And whilst that’s nice, it’s so meaningless as to be painful to behold the enthusiasm that some display, as though all they did all day long was sit and reboot their machines with a stop watch in one hand.
The main problem with systemd is this – if there are ulterior motives at work here (and by definition they will be hidden at present) then by the time we find that out it will be too late.
And the other problem is that it takes a special kind of arrogance to sneer at 20+ years of development by some seriously smart people and claim that you, as a mere child, can do better. I do wonder how far systemd would have got had it not had Red Hat’s weight behind it. I do realise that improvement sometimes means kicking out old ‘tried and trusted’ methods. But it’s the way its happening with systemd that rings alarm bells – too many sneering, nasty bullies trashing anyone who disagrees (just like anyone who thinks Corporations should pay proper taxes is sneered at, or anyone who thinks Putin is not as bad as he is made out to be gets sneered at – sneering is the new way of silencing genuine debate, so when I come across it in Linuxland, alarm bells beging to ring).
Linux is about granular power and control, not convenience.
“The main problem with systemd is this – if there are ulterior motives at work here (and by definition they will be hidden at present) then by the time we find that out it will be too late.”
Just read http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html (without the blank space before “.net”) to find the ulterior motives.