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.

I love systemd. Finally a sane solution on linux.

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$"

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.

> 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?

[1]: https://en.wikipedia.org/wiki/Systemd

[2]: https://en.wikipedia.org/wiki/Upstart

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.

> 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...