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

> 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 https://en.wikipedia.org/wiki/Systemd [2]: https://en.wikipedia.org/wiki/Upstart https://en.wikipedia.org/wiki/Upstart