I'm fairly skilled up with Linux, but I don't often read about anything the community is doing, saying or thinking. What is it that everyone hates about Systemd?
Note that this is not a list of distributions hating systemd. Some distributions just don't use systemd for technical reasons or because of other design considerations.
One example is GuixSD, which uses Guile for everything, including the init (via GNU Shepherd).
In its naive form, it seems very monolithic, which seems un-unixlike. And its adoption was largely driven by decisions by large distributions, rather than organic growth. To some, this feels very corporate and centralized, which seems un-linuxlike.
Isn't being somewhat monolithic Linux-like in itself? I've always been under the impression that Linux is a monolith kernel approach to Unix. Unless we're all switching to Hurd, caring about a monolith init system while running the Linux kernel seems philosophically inconsistent.
Please note that my comment carefully articulates the perception of systemd, without commitment to it being the reality. I actually like systemd, and don't care whether it's "monolithic" or not.
> And its adoption was largely driven by decisions by large distributions, rather than organic growth.
Yes, that's not stated enough. According to systemd proponents, systemd was demanded. Truth is I've never witnessed or heard about a rush towards RedHat distributions because they had systemd first. Never. That's what should have happened if systemd was so attractive, shouldn't it? Nor have I ever heard a user demanding systemd in order to solve his problems.
It was pushed by distribution maintainers, not users. I remember when Arch decided to switch to systemd. The maintainers made false claims (which were repeated by other distributions later) and false promises.
They claimed that systemd would relieve them from the terrible burden of maintaining init scripts. Many times have I asked to give example of this burden, I was never given an answer. Of course, the software packages are mostly all already present, there are very few new ones coming who require an init script, and the existing ones have had their script running for years and years, there is very little fixing or evolution in those. It's difficult to give proofs of a burden that did not exist, but that claim persisted, despite never being backed by anything.
Arch maintainers, in order to get allowed to switch to systemd, promised that the previous init system would stay beside systemd and be maintained. That was a swindle: once they got the agreement to proceed with systemd on that condition, it was a matter of only a couple of months for them to ditch that promise. And 6 months after, the maintainer who made this promise in order to butter the opposition up and pass the deal for systemd as Arch init, was hired by RedHat...
One of the main problems was the speed with which systemd was rolled out on all the major Linux distros, despite it being relatively immature and very controversial at that.
The second major issue is it growing way out of the bounds of being just an init replacement, thereby violating the so-called Unix Philosophy of doing one-thing well. For a user app to do that is one thing, but for a core OS component to do that just smells way too much like forcing Linux to be more like Windows, which a lot of hard-core Linux users are ideologically opposed to.
The third major issue is that on most major Linux distros, users are not given an easy way to avoid using systemd, no matter how much they hate it or oppose it.
The fourth issue is the apparent arrogance of the people responsible for systemd, and their off-hand dismissal of mature and widely respected unix conventions.
The fifth problem is that when systemd breaks, troubleshooting and fixing it can be a lot harder than doing the same with an init script.
All of this adds up to a storm of controversy that the systemd people mostly brought upon themselves. Had they just been more humble about their creation and waited until it was mature and well-tested and did all the wonderful things they claim it could and should do instead of stuffing what was widely seen as a broken-by-design piece of garbage down everybody's throat, maybe much of the Linux community wouldn't have been nearly so outraged by it.
3: Users are not given an easy way to avoid using libc or the kernel calls or ASCII text either, so that a non-issue unless you already decided that it's important not to use those things.
I'm sorry. But the "Unix" way is to do one thing well.
Why is it that every single app needs to support a "daemon" mode?
It is the biggest pain in the but.
You weren't looking very hard for such solutions, obviously, as you missed 20 years of stuff. The idea that applications do not have to have their own code to daemonize had been around for about a decade and a half before systemd was even an idea, and there were plenty of toolsets that one could employ to manage daemons where exactly this idea was part of the design. I myself was explaining not to make this design mistake before the turn of the century.
Is just that it's obvious that the feature creep tendencies are strong, and a lot of tangential daemons and tools are affected.
All in all, I've come to the conclusion that it's probably for the better, but I must admit that even small things like an embedded 'more' implementation seems a bit off somehow.
You like the one sane thing systemd does - very few folks argue that it's implementation of unit files and friends is a bad thing. Other init systems were progressing in the same direction though.
The problem is everything under the hood. Have you ever tried to debug a wedged Linux server with a somewhat esoteric startup issue these days? It's exceedingly difficult, and not simply because you need to learn an new tool chain. It's simply made many things opaque and replaced other bits no one sane would ever expect (e.g. having to remember systemd re-implements 'rm' and the quirks that brings, etc.)
As a cranky systemd-hater I also love the unit/service files - they work great, and as you say one tool that does it well. And systemd excels at making any random program a reliable and standardized daemon. Why does it also need it's own dns resolver?
If I were simply an end-user or developer making apps to run on linux I'd love systemd. It's when you're maintaining the bare metal where you start to see it's lesser known and more ugly parts.
> One of the main problems was the speed with which systemd was rolled out on all the major Linux distros, despite it being relatively immature and very controversial at that.
When Debian/Ubuntu defaulted to systemd, systemd already had 5 years of existence. In Mageia, 2 years, while Arch Linux, took 2.5 years. Fedora was the only distro that ready adopted systemd by default very soon, in a year and half [1].
Compare this to upstart, that had an initial release in August 24, 2006 and adopted in the same year in Ubuntu 6.10 (and by default, since I don't know any distro that maintained a compatibility shim for those who didn't want to use upstart, like happens in systemd nowadays).
> The second major issue is it growing way out of the bounds of being just an init replacement, thereby violating the so-called Unix Philosophy of doing one-thing well. For a user app to do that is one thing, but for a core OS component to do that just smells way too much like forcing Linux to be more like Windows, which a lot of hard-core Linux users are ideologically opposed to.
However, systemd is not a single binary. Each additional funcionality is shipped in different binaries, so the init part only cares about init, journal part only cares about journal, etc.
This also happens in other projects. GNU Coreutils (ls, date, cut, du, df, echo, mkdir, etc.) for example, is a collection of binaries that do each its own part. It does as much sense of calling systemd violating Unix Philosophy because it has multiple funcionality implemented in the same source code as calling GNU Coreutils violating Unix Philosophy by the same reason.
> The third major issue is that on most major Linux distros, users are not given an easy way to avoid using systemd, no matter how much they hate it or oppose it.
This only became a problem after systemd it seems. Ubuntu/Fedora only offered upstart, Arch only offered BSD-style init, Debian only offered SysVinit, etc...
After systemd was adopted by default people started to whine to maintainers support multiple init systems, increasing the burden of maintance without obvious benefits (who are gonna fixes the bugs if the majority of developers are running something else?).
> The fourth issue is the apparent arrogance of the people responsible for systemd, and their off-hand dismissal of mature and widely respected unix conventions.
Well, the community is as bad or even worse than the maintainers, IMO.
> The fifth problem is that when systemd breaks, troubleshooting and fixing it can be a lot harder than doing the same with an init script.
Sure, however writing scripts was much worse since even the simpler things are incredible difficult to get right with scripts (want to get the PID of a daemonized process? PID files, except that now you can have racing conditions and possible problems with locking).
I recently migrated a script init-style startup file (used by a thin systemd service) to a native systemd service in my current work. Nobody understood the script file very well, while the .service native systemd file is much simpler and obvious about what is doing.
> All of this adds up to a storm of controversy that the systemd people mostly brought upon themselves. Had they just been more humble about their creation and waited until it was mature and well-tested and did all the wonderful things they claim it could and should do instead of stuffing what was widely seen as a broken-by-design piece of garbage down everybody's throat, maybe much of the Linux community wouldn't have been nearly so outraged by it.
Using words like "broken-by-design" without given reasonable arguments will only make your argument less convincing, you know?
The actual truth is that before the Hoo-Hah, Debian included packages for minit, runit, van Smoorenburg rc+init, filerc+van Smoorenburg init, Upstart, and even InitNG at one point. An OpenRC package was added by OpenRC people during the Hoo-Hah.
- upstart: ok, this is the only one that may count as a valid criticism. The reason give from Debian is simply "RoQA; unmaintained" in January 2016, while Upstart Bazaar received updates until May 2016 [5].
So except from upstart, all of those init systems that you cited still exists in current Debian or was removed well before systemd exists.
My original post is wrong (Debian supports multiple init systems, before and after systemd migration). However, I don't see the problem here, you only made my point stronger.
> instead of stuffing what was widely seen as a broken-by-design piece of garbage down everybody's throat
Here's the thing I don't understand. I don't want to get too deep into my bona fides, but I'm a "real professional" who's been in this industry twenty years now. I've been running Linux since it came on a stack of floppy disks. I've managed clusters of Sun machines, I've worked end-user IT support, I've deployed BSD on routers, I've carried the pager at Google, I've spent years and years at small startups writing the code, crimping cables, wiring racks, deploying the code, waking up at 3am when the code breaks.
So when I read an opinion like this, the only conclusion I can draw is these people are out to lunch, because to me it's clear that the systemd suite is so much better than the steaming pile it's replacing. The tools are consistent, composable, well documented, and fast. Binary logging is superior in every way (checksums, log shipping, metadata, search). It's got amazing sandboxing support right out of the box and makes it easy to configure (PrivateTmp, PrivateDevices, PrivateUsers, ProtectSystem, CapabilityBoundingSet, SystemCallFilter, NoNewPrivileges, MemoryDenyWrite, etc). It gives you fine-grained control over cpu scheduling and limits. It doesn't litter .pid and .lock files all over your system because the shitty bash script couldn't figure out the daemon died. The systemd-nspawn tool is chroot, but done correctly this time. Socket activation is totally awesome. Love user sessions -- systemd starts my emacs daemon and mail fetcher for me when I log in, sends their log output to the journal like every other service, and restarts them when they fall over. I chafe when I have to login to an older CentOS or Ubuntu system that doesn't have it.
As someone who is a heavy Windows user, this whole thing confuses me. Someone comes along, similar to Stallman who embraces Linux in the truest form: they build something for you. It has faults. It may not be great, but it does some things well. And somehow, it creeps over & takes over. On more than one comment here, people complained about how fast systemd (not systemD) took over -- and yet, is that the author (Pottering or whatever?) fault? I think not -- this is your fault. Your friends. Mine. My friends. The random dev in the corner who found it useful & uses it & realizes the potential.
I'd be curious to see what the Amazons, WalMarts & other large ''small service Linux-y thingy'' do to get so big & scale so fast: are they not essentially using CoreOS, many containers & making use of systemd to the fullest extent possible?
I just don't get it. Linux is all about choice (and yet nobody realizes too much choice is bad - just look at all the distros you have). Someone fixes it all for you & you get upset. Someone takes power away from Sysadmins & shifts it just a little more to Devs because they can't get work done. You get upset (I am admittedly in that camp) but, from the people that I hear good things about systemd, I hear great* things that convince me it's wonderful. The bad camp can't say the same thing on the same scale: it's just blame & resentment & frustration because they can't articulate what they don't like about it other than "It isn't the Linux way!!11Oneoneon1on1!! M$"
> is that the author (Pottering or whatever?) fault?
Yes, he's got technically good ideas, but not a great experience with either security or large systems. He's also terrible at receiving critical feedback which makes this unlikely to change.
Some people chose systemd for the positive technical merits and others disagree. But just because his ideas got popular, it doesn't make him right and without blame for other behaviour. We have enough bad, popular leaders recently.
Ideally, I'd like systemd with each project split out with separate leadership and without Pottering. Nobody getting a pwnie award should be a leader of a large project.
For those into minimalism, systemd is just the straw that broke the camel's back. Over the years the Linux distributions have been adding more and more cruft on top. Systemd was a relatively large chunk of cruft and forced some to look the complexity of the whole system and not like what they saw.
With the exception of slackware (which aims to be the most Unix-like Linux distro) I don't understand all the hate for systemd and why people continually try to remove it from their system. I've read countless blogs on the pitfalls of systemd, but all the benefits of systemd outweigh the downsides. It seems there are a lot of people who get way too hung up on sticking to the UNIX philosophy as closely as possible without taking other factors into consideration.
Then quite simply you haven't been listening or paying attention. I'm a gnu/gpl proponent, so I come into the systemd debate leaning towards the side that is simply requesting (why should they even have to? They don't!) init diversity. I've heard plenty of reasoned debate between both sides though, and things like "why people continually try to remove" have been layed out time and time again.
So after showing you aren't even aware of the current debates which are still ongoing, you try to criticize their points as being "too hung up on sticking to the UNIX philosophy"? That's not a good description of the antisystemd sides arguments, because the positions I have seen taken are more varied than that. Essentially that was just a strawman you took out of your hat because its one that sounds good.
Oh and if it's worth anything, as a sysadmin who has to support all the distro's, systemd has not been a panacea as touted by any stretch of the imagination. For example, logging. Why is that now a systemd thing? Just cause systemd is the creepy uncle that likes to touch everything it can? So I'm just gonna pipe that crap into syslog anyway... and don't get me started on LP's shenanigans.
I fully support devuan and all others in their pursuit of init freedom, because the user deserves to have choice. I hope fully gplv3'd init wins (systemd being agplv2 I think).
The anti-systemd trolling puts me off the whole anti-systemd camp as well.
It's dishonest, as far as I can tell: People trying to stir up trouble simply because they think they've found a new stick to poke people with, who don't understand the issue except to the extent it apparently is an issue for some people, but who can damned well be loud and obstreperous and who can make it sound like you're the one who is ignorant and you're the one who should be shamed.
Well, no. I don't feel shame for my choice of software. Sorry.
That's a bit of an odd thing to focus on (and I say this as a GNU person). But if you're looking for an init under the GPLv3 (or later): the GNU Shepherd fits that query.
https://www.gnu.org/software/shepherd/
I like the Shepherd but I don't see it winning over people who compare its feature set with other more featureful init systems.
> Why is that now a systemd thing? Just cause systemd is the creepy uncle that likes to touch everything it can? So I'm just gonna pipe that crap into syslog anyway... and don't get me started on LP's shenanigans.
Feature creep falls under the umbrella of sticking to the UNIX philosophy too closely, the first point of the UNIX philosphy is:
> Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features".
In any case, I think it's arguable if it's feature creep or not. The goal of an init system is to start your system up, it makes sense that the thing that starts daemons would also monitor them, take logs, and do other support actions as well.
The only complaint I actually agree is that systemd/journald uses a binary format to store logs, but I don't think that's a good enough complaint to warrant all the hatred.
The goal of an init system is to start daemons. It shouldn't have any opinions about which daemons you run, and it has no business doing random tampering like intercepting logins and DNS requests and renaming device nodes. Breaking "nohup foo & logout" is shockingly inappropriate; end users should never ever care how an admin may have booted the system much less have to know how to interact with it!
> it has no business doing random tampering like intercepting logins and DNS requests and renaming device nodes
I agree with the resolving DNS requests complaint, wasn't aware of that to be honest. That actually does seem somewhat odd.
However the other two make sense, systemd is used to init your system. Supporting login functionality as well as mounting and managing devices through udev (which supports renaming devices, as you said) doesn't seem too odd to me.
> Breaking "nohup foo & logout" is shockingly inappropriate;
Can you explain this to me? I never heard about this and my googlefu isn't returning anything fruitful.
> end users should never ever care how an admin may have booted the system much less have to know how to interact with it!
Unless you have an advanced user running `systemctl --user` or trying to check logs then I highly doubt the average user will need to know which init system you are using. For the most part, if you are just using your computer as a facebook/youtube/netflix machine then you probably don't care about the init system your computer is using (which I suspect describes 75% of users), assuming you even know what an init system is.
I think the problem is that not all people regard statements like
> Just cause systemd is the creepy uncle that likes to touch everything it can?
as "reasoned debate". For these people, there's not much arguments coming from the systemd hater camp.
(Not to mention some Devuan supporters using notation like "(((Poettering)))" which says a lot more about there real motivation... See "Triple parentheses" on Wikipedia.)
I'm using Void Linux which uses runit. Systemd is fine but runit works just as well. Void Linux has a bunch of other nice things (musl, xbps, build system, etc.). It would be a shame to overlook this fine distribution.
I had just recently tried to install this, but then I encountered a very strange bug with Firefox where any tab crashed immediately upon opening with some sort of IPC error, and I tried searching around but couldn't find any mention of it anywhere. I ended up just giving up on fighting systemd and install Xubuntu.
I love runit. It's simple and elegant, is in tune with the Unix Philosophy, and doesn't try to absorb a ton of unrelated, independent services into itself like systemd does.
If something like runit was chosen by RedHat and the distros that followed it, this holy war wouldn't exist.
> There might be some issues with systemd, but systemd is by far much better than anything else we had before.
Upstart was perfectly fine and just as fast. I've been moving all my personal systems over to Alpine Linux. Many others are doing the same. More complex services are being containerized and will eventually be ported to CoreOS.
PotteringOS is adding too much complexity and cruft and bugs[1] to my otherwise simple systems. Linux/Unix is supposed to be boring, simple, predictable, stable. This is not the case with SystemD in my experience.
Upstart was on the good path, but had its own issues as well. Detecting which process it should track was rather tricky in some cases. For example any server optionally spawning an extra command before forking is not possible to configure in a generic way. Shutting things down properly without cgroups can be bad too. (It's server's fault, but good init can help here)
I imagine it would get better if upstart got a serious v2 or higher, but it seems it won't get serious changes anymore.
Maybe I'm stepping into a hornets nest by commenting this but after some initial estrangement, I now absolutely love having systemd in the servers I manage. Thanks for providing me with an easy and sane way to manage processes, pretty simple one to configure control groups and other restricted execution environments, monitoring, etc.
That made me see how much time I wasted writing non-trivial init scripts and reworking with the trivial ones. I simply don't want to get back now.
I think it would still have to be some kind of structured format (one json object per "line", for instance), so that it could keep all of the metadata. On the other hand, you can use journalctl --output=json to get exactly that, so...
I have a grief with plain text logs. They are really nice if you want to read them manually with vim or less, but are super painful if you want to parse them automatically.
It doesn't help much that a fair number of logging libraries have buggy formatting to an extend that you can't safely parse plain text log files sometimes.
I used to hate systemd until we adopted CoreOS at our last job, which forced me to learn it. I have evolved and now love it. Once you learn the basics, getting new services up and running with it is easy.
I really like the other parts of the systemd ecosystem, too. journald makes it easy to view the logs of any given app/service without having to hunt through directories.
I also love systemd-networkd--it's a HUGE improvement over older attempts at managing network connections. I got my start on Linux in the < 1.0 kernel days and distros back then forced you to manually configure your interfaces. This was actually really nice because it was simple and reliable. When more modern distros came along, they introduced "fancy" network management which was complicated, inflexible, and often flaky. systemd-networkd restores sanity to network interface management.
Finally, there's a great message bus that allows for API-driven interaction with various systemd components. With a good language binding, it's now pretty straightforward to tie your custom code into some of the systemd components.
Oh, yes. I never really wrote a ton of systemv init scripts, but I wrote enough to always find it kind of a pain.
Writing systemd units by comparison? Heavenly. What really sealed the deal for me was when I needed a service to automatically restart itself if it died. Restart=always, RestartSec=10, done. If it dies, it's back up in 10 seconds.
I wouldn't even know how to do that with an init script, and though of course I could write something out with enough time and patience, how could that be an improvement over two easily-understood lines?
systemd is great, since I started using it about a year ago, never looked back. I like the fact that with a single service file, I have: well... services, services with dependencies, logging, automatic restarts, timers (no more cron, yay), sane pre-start, post-start and such.
Show me a viable, repeatably working alternative, I might consider. Until then I really don't care if it's the "UNIX philosophy". I used upstart, init and runit before. runit was close but there was just so much fiddling with it. Upstart kinda worked. init is init.
systemd just works - it does one thing well: allows me to launch my services reliably without having to install, configure and maintain tons of little fiddly bits to make the system work.
Personally as someone who uses Linux to get work done and make money (as opposed to tweaking my machine more than actually using it), systemd has been a blessing - it just works most of the time, and the rare time it doesn't (that did happen - some issues with dbus) I just consider the entire machine hosed and reboot - my software is designed to work around failed nodes so it's no big deal.
51 comments
[ 1.6 ms ] story [ 118 ms ] threadOne example is GuixSD, which uses Guile for everything, including the init (via GNU Shepherd).
Yes, that's not stated enough. According to systemd proponents, systemd was demanded. Truth is I've never witnessed or heard about a rush towards RedHat distributions because they had systemd first. Never. That's what should have happened if systemd was so attractive, shouldn't it? Nor have I ever heard a user demanding systemd in order to solve his problems.
It was pushed by distribution maintainers, not users. I remember when Arch decided to switch to systemd. The maintainers made false claims (which were repeated by other distributions later) and false promises.
They claimed that systemd would relieve them from the terrible burden of maintaining init scripts. Many times have I asked to give example of this burden, I was never given an answer. Of course, the software packages are mostly all already present, there are very few new ones coming who require an init script, and the existing ones have had their script running for years and years, there is very little fixing or evolution in those. It's difficult to give proofs of a burden that did not exist, but that claim persisted, despite never being backed by anything.
Arch maintainers, in order to get allowed to switch to systemd, promised that the previous init system would stay beside systemd and be maintained. That was a swindle: once they got the agreement to proceed with systemd on that condition, it was a matter of only a couple of months for them to ditch that promise. And 6 months after, the maintainer who made this promise in order to butter the opposition up and pass the deal for systemd as Arch init, was hired by RedHat...
The second major issue is it growing way out of the bounds of being just an init replacement, thereby violating the so-called Unix Philosophy of doing one-thing well. For a user app to do that is one thing, but for a core OS component to do that just smells way too much like forcing Linux to be more like Windows, which a lot of hard-core Linux users are ideologically opposed to.
The third major issue is that on most major Linux distros, users are not given an easy way to avoid using systemd, no matter how much they hate it or oppose it.
The fourth issue is the apparent arrogance of the people responsible for systemd, and their off-hand dismissal of mature and widely respected unix conventions.
The fifth problem is that when systemd breaks, troubleshooting and fixing it can be a lot harder than doing the same with an init script.
All of this adds up to a storm of controversy that the systemd people mostly brought upon themselves. Had they just been more humble about their creation and waited until it was mature and well-tested and did all the wonderful things they claim it could and should do instead of stuffing what was widely seen as a broken-by-design piece of garbage down everybody's throat, maybe much of the Linux community wouldn't have been nearly so outraged by it.
I love systemd. Finally a sane solution on linux.
* http://jdebp.eu./FGA/unix-daemon-design-mistakes-to-avoid.ht...
* http://jdebp.eu./FGA/daemontools-family.html
* http://blog.darknedgy.net/technology/2015/09/05/0/
Is just that it's obvious that the feature creep tendencies are strong, and a lot of tangential daemons and tools are affected.
All in all, I've come to the conclusion that it's probably for the better, but I must admit that even small things like an embedded 'more' implementation seems a bit off somehow.
The problem is everything under the hood. Have you ever tried to debug a wedged Linux server with a somewhat esoteric startup issue these days? It's exceedingly difficult, and not simply because you need to learn an new tool chain. It's simply made many things opaque and replaced other bits no one sane would ever expect (e.g. having to remember systemd re-implements 'rm' and the quirks that brings, etc.)
As a cranky systemd-hater I also love the unit/service files - they work great, and as you say one tool that does it well. And systemd excels at making any random program a reliable and standardized daemon. Why does it also need it's own dns resolver?
If I were simply an end-user or developer making apps to run on linux I'd love systemd. It's when you're maintaining the bare metal where you start to see it's lesser known and more ugly parts.
When Debian/Ubuntu defaulted to systemd, systemd already had 5 years of existence. In Mageia, 2 years, while Arch Linux, took 2.5 years. Fedora was the only distro that ready adopted systemd by default very soon, in a year and half [1].
Compare this to upstart, that had an initial release in August 24, 2006 and adopted in the same year in Ubuntu 6.10 (and by default, since I don't know any distro that maintained a compatibility shim for those who didn't want to use upstart, like happens in systemd nowadays).
> The second major issue is it growing way out of the bounds of being just an init replacement, thereby violating the so-called Unix Philosophy of doing one-thing well. For a user app to do that is one thing, but for a core OS component to do that just smells way too much like forcing Linux to be more like Windows, which a lot of hard-core Linux users are ideologically opposed to.
However, systemd is not a single binary. Each additional funcionality is shipped in different binaries, so the init part only cares about init, journal part only cares about journal, etc.
This also happens in other projects. GNU Coreutils (ls, date, cut, du, df, echo, mkdir, etc.) for example, is a collection of binaries that do each its own part. It does as much sense of calling systemd violating Unix Philosophy because it has multiple funcionality implemented in the same source code as calling GNU Coreutils violating Unix Philosophy by the same reason.
> The third major issue is that on most major Linux distros, users are not given an easy way to avoid using systemd, no matter how much they hate it or oppose it.
This only became a problem after systemd it seems. Ubuntu/Fedora only offered upstart, Arch only offered BSD-style init, Debian only offered SysVinit, etc...
After systemd was adopted by default people started to whine to maintainers support multiple init systems, increasing the burden of maintance without obvious benefits (who are gonna fixes the bugs if the majority of developers are running something else?).
> The fourth issue is the apparent arrogance of the people responsible for systemd, and their off-hand dismissal of mature and widely respected unix conventions.
Well, the community is as bad or even worse than the maintainers, IMO.
> The fifth problem is that when systemd breaks, troubleshooting and fixing it can be a lot harder than doing the same with an init script.
Sure, however writing scripts was much worse since even the simpler things are incredible difficult to get right with scripts (want to get the PID of a daemonized process? PID files, except that now you can have racing conditions and possible problems with locking).
I recently migrated a script init-style startup file (used by a thin systemd service) to a native systemd service in my current work. Nobody understood the script file very well, while the .service native systemd file is much simpler and obvious about what is doing.
> All of this adds up to a storm of controversy that the systemd people mostly brought upon themselves. Had they just been more humble about their creation and waited until it was mature and well-tested and did all the wonderful things they claim it could and should do instead of stuffing what was widely seen as a broken-by-design piece of garbage down everybody's throat, maybe much of the Linux community wouldn't have been nearly so outraged by it.
Using words like "broken-by-design" without given reasonable arguments will only make your argument less convincing, you know?
[1]: https://en.wikipedia.org/wiki/Systemd
[2]: https://en.wikipedia.org/wiki/Upstart
> writing scripts was
That is a fallacious argument. The false dichotomy and false history that it presumes is one of the fallacies that the "Uselessd Guy" describes at http://uselessd.darknedgy.net/ProSystemdAntiSystemd/ .
The actual truth is that before the Hoo-Hah, Debian included packages for minit, runit, van Smoorenburg rc+init, filerc+van Smoorenburg init, Upstart, and even InitNG at one point. An OpenRC package was added by OpenRC people during the Hoo-Hah.
* https://tracker.debian.org/pkg/minit
* https://tracker.debian.org/pkg/daemontools-run
* https://tracker.debian.org/pkg/runit-run
* https://tracker.debian.org/pkg/file-rc
* https://tracker.debian.org/pkg/initng
* https://tracker.debian.org/pkg/openrc
* https://tracker.debian.org/pkg/upstart
* http://jdebp.eu./FGA/debian-systemd-packaging-hoo-hah.html
- minit: "RoQA; no popcon recent users; abandoned 2007; not friendly" [1], so not supported by upstream since 2007.
- daemontools-run: still included in all current versions: https://packages.debian.org/search?suite=default§ion=all...
- runit-run: removed from Debian archives well before systemd even existed (2010) [2].
- file-rc: still included in all current versions: https://packages.debian.org/search?suite=default§ion=all...
- initng: c'mon, this package was last updated in 2007! [3]
- openrc: still included: https://packages.debian.org/search?suite=default§ion=all...
- upstart: ok, this is the only one that may count as a valid criticism. The reason give from Debian is simply "RoQA; unmaintained" in January 2016, while Upstart Bazaar received updates until May 2016 [5].
So except from upstart, all of those init systems that you cited still exists in current Debian or was removed well before systemd exists.
My original post is wrong (Debian supports multiple init systems, before and after systemd migration). However, I don't see the problem here, you only made my point stronger.
[1]: https://tracker.debian.org/news/726018
[2]: https://tracker.debian.org/news/649008
[3]: https://tracker.debian.org/news/614059
[4]: https://tracker.debian.org/news/739662
[5]: https://code.launchpad.net/upstart
Here's the thing I don't understand. I don't want to get too deep into my bona fides, but I'm a "real professional" who's been in this industry twenty years now. I've been running Linux since it came on a stack of floppy disks. I've managed clusters of Sun machines, I've worked end-user IT support, I've deployed BSD on routers, I've carried the pager at Google, I've spent years and years at small startups writing the code, crimping cables, wiring racks, deploying the code, waking up at 3am when the code breaks.
So when I read an opinion like this, the only conclusion I can draw is these people are out to lunch, because to me it's clear that the systemd suite is so much better than the steaming pile it's replacing. The tools are consistent, composable, well documented, and fast. Binary logging is superior in every way (checksums, log shipping, metadata, search). It's got amazing sandboxing support right out of the box and makes it easy to configure (PrivateTmp, PrivateDevices, PrivateUsers, ProtectSystem, CapabilityBoundingSet, SystemCallFilter, NoNewPrivileges, MemoryDenyWrite, etc). It gives you fine-grained control over cpu scheduling and limits. It doesn't litter .pid and .lock files all over your system because the shitty bash script couldn't figure out the daemon died. The systemd-nspawn tool is chroot, but done correctly this time. Socket activation is totally awesome. Love user sessions -- systemd starts my emacs daemon and mail fetcher for me when I log in, sends their log output to the journal like every other service, and restarts them when they fall over. I chafe when I have to login to an older CentOS or Ubuntu system that doesn't have it.
TL;DR: smells like Dunning-Krueger to me
I'd be curious to see what the Amazons, WalMarts & other large ''small service Linux-y thingy'' do to get so big & scale so fast: are they not essentially using CoreOS, many containers & making use of systemd to the fullest extent possible?
I just don't get it. Linux is all about choice (and yet nobody realizes too much choice is bad - just look at all the distros you have). Someone fixes it all for you & you get upset. Someone takes power away from Sysadmins & shifts it just a little more to Devs because they can't get work done. You get upset (I am admittedly in that camp) but, from the people that I hear good things about systemd, I hear great* things that convince me it's wonderful. The bad camp can't say the same thing on the same scale: it's just blame & resentment & frustration because they can't articulate what they don't like about it other than "It isn't the Linux way!!11Oneoneon1on1!! M$"
Yes, he's got technically good ideas, but not a great experience with either security or large systems. He's also terrible at receiving critical feedback which makes this unlikely to change.
Some people chose systemd for the positive technical merits and others disagree. But just because his ideas got popular, it doesn't make him right and without blame for other behaviour. We have enough bad, popular leaders recently.
Ideally, I'd like systemd with each project split out with separate leadership and without Pottering. Nobody getting a pwnie award should be a leader of a large project.
(Yes, it's long, but it's absolutely worth reading.)
There might be some issues with systemd, but systemd is by far much better than anything else we had before.
So after showing you aren't even aware of the current debates which are still ongoing, you try to criticize their points as being "too hung up on sticking to the UNIX philosophy"? That's not a good description of the antisystemd sides arguments, because the positions I have seen taken are more varied than that. Essentially that was just a strawman you took out of your hat because its one that sounds good.
Oh and if it's worth anything, as a sysadmin who has to support all the distro's, systemd has not been a panacea as touted by any stretch of the imagination. For example, logging. Why is that now a systemd thing? Just cause systemd is the creepy uncle that likes to touch everything it can? So I'm just gonna pipe that crap into syslog anyway... and don't get me started on LP's shenanigans.
I fully support devuan and all others in their pursuit of init freedom, because the user deserves to have choice. I hope fully gplv3'd init wins (systemd being agplv2 I think).
It's dishonest, as far as I can tell: People trying to stir up trouble simply because they think they've found a new stick to poke people with, who don't understand the issue except to the extent it apparently is an issue for some people, but who can damned well be loud and obstreperous and who can make it sound like you're the one who is ignorant and you're the one who should be shamed.
Well, no. I don't feel shame for my choice of software. Sorry.
That's a bit of an odd thing to focus on (and I say this as a GNU person). But if you're looking for an init under the GPLv3 (or later): the GNU Shepherd fits that query.
I like the Shepherd but I don't see it winning over people who compare its feature set with other more featureful init systems.Feature creep falls under the umbrella of sticking to the UNIX philosophy too closely, the first point of the UNIX philosphy is:
> Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features".
In any case, I think it's arguable if it's feature creep or not. The goal of an init system is to start your system up, it makes sense that the thing that starts daemons would also monitor them, take logs, and do other support actions as well.
The only complaint I actually agree is that systemd/journald uses a binary format to store logs, but I don't think that's a good enough complaint to warrant all the hatred.
I agree with the resolving DNS requests complaint, wasn't aware of that to be honest. That actually does seem somewhat odd.
However the other two make sense, systemd is used to init your system. Supporting login functionality as well as mounting and managing devices through udev (which supports renaming devices, as you said) doesn't seem too odd to me.
> Breaking "nohup foo & logout" is shockingly inappropriate;
Can you explain this to me? I never heard about this and my googlefu isn't returning anything fruitful.
> end users should never ever care how an admin may have booted the system much less have to know how to interact with it!
Unless you have an advanced user running `systemctl --user` or trying to check logs then I highly doubt the average user will need to know which init system you are using. For the most part, if you are just using your computer as a facebook/youtube/netflix machine then you probably don't care about the init system your computer is using (which I suspect describes 75% of users), assuming you even know what an init system is.
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394#221
* https://news.ycombinator.com/item?id=11797075
* https://news.ycombinator.com/item?id=11782364
systemd and Netflix:
* https://news.ycombinator.com/item?id=14837110
* https://www.theregister.co.uk/2017/07/24/underscore_domain_n...
I think the problem is that not all people regard statements like
> Just cause systemd is the creepy uncle that likes to touch everything it can?
as "reasoned debate". For these people, there's not much arguments coming from the systemd hater camp.
(Not to mention some Devuan supporters using notation like "(((Poettering)))" which says a lot more about there real motivation... See "Triple parentheses" on Wikipedia.)
If something like runit was chosen by RedHat and the distros that followed it, this holy war wouldn't exist.
Upstart was perfectly fine and just as fast. I've been moving all my personal systems over to Alpine Linux. Many others are doing the same. More complex services are being containerized and will eventually be ported to CoreOS.
PotteringOS is adding too much complexity and cruft and bugs[1] to my otherwise simple systems. Linux/Unix is supposed to be boring, simple, predictable, stable. This is not the case with SystemD in my experience.
[1] https://www.theregister.co.uk/2017/07/28/black_hat_pwnie_awa...
I imagine it would get better if upstart got a serious v2 or higher, but it seems it won't get serious changes anymore.
That made me see how much time I wasted writing non-trivial init scripts and reworking with the trivial ones. I simply don't want to get back now.
It doesn't help much that a fair number of logging libraries have buggy formatting to an extend that you can't safely parse plain text log files sometimes.
For example this bug (mostly fixed by now) https://github.com/sirupsen/logrus/issues/531
I really like the other parts of the systemd ecosystem, too. journald makes it easy to view the logs of any given app/service without having to hunt through directories.
I also love systemd-networkd--it's a HUGE improvement over older attempts at managing network connections. I got my start on Linux in the < 1.0 kernel days and distros back then forced you to manually configure your interfaces. This was actually really nice because it was simple and reliable. When more modern distros came along, they introduced "fancy" network management which was complicated, inflexible, and often flaky. systemd-networkd restores sanity to network interface management.
Finally, there's a great message bus that allows for API-driven interaction with various systemd components. With a good language binding, it's now pretty straightforward to tie your custom code into some of the systemd components.
Writing systemd units by comparison? Heavenly. What really sealed the deal for me was when I needed a service to automatically restart itself if it died. Restart=always, RestartSec=10, done. If it dies, it's back up in 10 seconds.
I wouldn't even know how to do that with an init script, and though of course I could write something out with enough time and patience, how could that be an improvement over two easily-understood lines?
I used to install systemd from backports on wheezy only because I don't have to write sysv-init scripts that way.
Show me a viable, repeatably working alternative, I might consider. Until then I really don't care if it's the "UNIX philosophy". I used upstart, init and runit before. runit was close but there was just so much fiddling with it. Upstart kinda worked. init is init.
systemd just works - it does one thing well: allows me to launch my services reliably without having to install, configure and maintain tons of little fiddly bits to make the system work.