[eythian]

My feeling, without evidence, is that a lot of the hate is vocal people who don't like this thing that does stuff differently to what they're used to. I get the feeling, I still understand /etc/init.d and runlevel symlinks and /var/log better than systemd, but that's because I have many more years of experience interacting with it, breaking it, fixing it. Whenever I have to do stuff with systemd it's a bit annoying to have to go learn new stuff, but when I do I find it reasonably straightforward. Just different, and most likely better.

[FuriouslyAdrift]

A lot of the hate was because the main developers interactions wiht just about everyone was horrible, the code was opaque at best most of the time and constantly changed, scope creep, and the feeling that it was a massive power grab by Red Hat.

It can be argued that it didn't solve very many problems and added a huge amount of complexity.

[const_cast]

The problem with the complaints is that they're all made up. Well, except maybe developer interactions - assholes can be assholes.

systemd isn't opaque, it's open-source. systemd is objectively less opaque than init scripts, because it's very well documented. Init scripts are not.

Sure, you can read them. But then you'd realize that glued together init scripts just re-implement systemd but buggier and slower, at which point you might as well just read the systemd source. Or, better yet, the documentation.

systemd ALSO does not constantly change. The init system has been virtually untouched in a decade, save for bug fixes and a few new features. Your unit files will "just work", across many years and many distros. Yes, systemd is more portable than init scripts.

systemd ALSO does not have any scope creep. Here, people get confused between systemd-init, and systemd the project.

systemd-init is just an init system. Nothing more, nothing less, for a long time now, and forever. There is no scope creep, the unix principle is safe, yadda yadda yadda.

systemd coincidentally is also the name of a project which includes many binaries. All of those binaries are optional. They aren't statically linked, they're not even dynamically linked - they communicate over IPC like every other program on your computer.

systemd is also not complex, it's remarkably simple. systemd unit files are flat, declarative config files. Bash is a turing-complete scripting language with more footguns than C++. Which sounds more complex?

[simoncion]

> systemd[-init] ALSO does not constantly change. The init system has been virtually untouched in a decade...

Sure, I'll bite. It'll be more interesting than watching some stupid Twitch streamer.

Gentoo Linux was using OpenRC back in 2002. Looking at the copyright notice in relevant source files, it looks like OpenRC is a project that has been under development since 1999, so I'd expect it was in use back in 1999. However, I will use 2002 as the start date for this discussion because that's when I started using it.

The simple OpenRC service file I mention in footnote 3 in [0] is syntactically identical to the syslogd service file added in to the OpenRC repo back in this commit in late 2007 [1]. The commit that appears to add support for 'command_args' and friends is earlier that day.

So, four years before SystemD's experimental release, the minimal OpenRC service file (that I talk about in [0]) was no more complicated than what would become the minimal SystemD service file no less than four years later. What's more, the more-verbose syntax for service files written in 2002 was supported by 2007's OpenRC, and continues to be supported by 2025's OpenRC.

23 years is quite a bit longer than 15.

> systemd is also not complex, it's remarkably simple. systemd unit files are flat, declarative config files.

See above (and below).

> Here, people get confused between systemd-init, and systemd the project.

In that case, it doesn't do you credit to use "systemd-init" and "systemd" interchangably in your commentary. SystemD absolutely has scope creep. systemd-init... well, I think I remember when it wasn't possible to have it rexecute itself for a no-reboot upgrade of PID 1. And does it still have a dependency on DBus, or did they see sense and get rid of that?

[0] <https://news.ycombinator.com/item?id=44945789>

[1] <https://github.com/OpenRC/openrc/commit/3ec2cc50261f37b76e0e...>

[const_cast]

systemd, the project, isn't a binary. Its dozens of binaries. It can't have scope creep because that's impossible - they're literally dozens of separate things.

We call that the unix principle, lol.

Saying systemd has scope creep is like saying GNU has scope creep because they have a compiler and a text editor. Makes no fucking sense.

I also don't consider a dependency on dbus "scope creep". It has to communicate over IPC - okay, don't reinvent the wheel, just use dbus. Every program ever supports dbus if it has a public API over IPC. Sorry if that bothers you.

And sure, maybe OpenRC is just as simple as systemd, but the reality is every distro chose systemd and that's that, and for MOST of them they switched from primarily scripts to unit files.

That is a HUGE reduction in complexity. HUGE.

[simoncion]

> systemd, the project, isn't a binary. Its dozens of binaries. It can't have scope creep because that's impossible - they're literally dozens of separate things.

I suppose you don't understand (or are pretending not to understand) what "scope creep" means. Oh well.

> I also don't consider a dependency on dbus "scope creep".

I also don't consider a dependency on DBus scope creep. I consider making PID 1 crash whenever DBus needs to restart because of a upgrade/security fix/etc. in DBus or one of the libraries it links against to be a fantastically poor design decision.

> And sure, maybe OpenRC is just as simple as systemd...

It's far simpler. It concerns itself with bringing up and supervising services. It doesn't contain a DNS resolver, a (subtly buggy) Cron, a syslog daemon, and the many other things SystemD has decided to (whether correctly or incorrectly) reimplement.

[FuriouslyAdrift]

Scope creep as in SystemD is now: the init daemon (systemd-init & systemctl), device manager (systemd-udevd), replaced cron, mount point manager, hostname and time/date controller (hostnamectl, timedatectl), container management (systemd-nspawn, machinectl), session manager (systemd-logind), and of course... the horrific syslog replacement (journald).

It's made Linux more Mac/Windows-like. When it works, it works very well... but when it breaks... good luck figuring out anything.

I guess that's OK for a "desktop" but for a server it's a huge pain in the butt.

[strawhatguy]

yes, especially the scope and power creep, which is antithetical to what unix was all about. Which was doing one thing, and doing it well. What started as a neat way to start servers in parallel, as systemd handles the sockets, now can control your home directory. Like what?

[dpkirchner]

One of my earliest memories of using systemd involved logs being corrupted. journalctl would just say the file is corrupted but wouldn't even print the name of the file -- I had to resort to strace. That left a real bad taste in my mouth.

[antod]

My systemd grumpiness was mostly due to only just (nearly) finishing an upstart migration. The thought of another one so soon after wasn't fun, even if I liked some of the new features. Those days are over though, and I'm glad there's a mostly unified approach.