Comment by dTal | Hacker News Reader

Comment by dTal | Hacker News Reader

Parent Full thread

I was careful not to include any value judgements in my comment. I simply wanted to lay to rest this "init system" business.

However, you ask a good question. Lots of people do like it, supposedly. But I think there's a large clue to its controversial nature in that people still call it an "init system", and pointing out that it isn't is interpreted by some as an attack.

Basically, it started out as an init system, which was used by Red Hat / Fedora, which was positioned well at a time when certain distros, notably Debian, used crufty SysV init scripts which they wanted to move on from. When Debian adopted systemd, after some debate, every Debian-based distro did too. This wasn't considered a particularly invasive change at the time. But systemd started to expand into its "middleware" position, absorbing vital system functions like udev. Distros which adopted systemd found themselves along for the ride, while distros that didn't increasingly found that software was starting to break, forcing them to maintain forks, or chisel out the piece of systemd that made it work and run it standalone. So was created a network effect that forced even more distros down the path of least resistance into systemd.

Meanwhile, amidst all the grumbling that this bait-and-switch was provoking, the systemd project leaders had an astonishingly bad attitude towards the maintainers of software that they were breaking, which fomented considerable personal animosity on top of the technical resentment. Not only were they driving a horse and cart through the standard ways of doing things, breaking a lot of stuff in the process, they were being rude about it.

So, more or less, people resent systemd because it's difficult to find - or build - a distro without it.

> When Debian adopted systemd, after some debate, every Debian-based distro did too. This wasn't considered a particularly invasive change at the time. But systemd started to expand into its "middleware" position, absorbing vital system functions like udev.

Your timing is off. udev became part of systemd in 2012. The big Debian debate was in 2013-2014, and was acrimonious enough to eventually cause several of the CTTE members to resign their position over it. One of the core issues driving the Debian systemd debate was the fact that GNOME was planning on dropping support for anything other than systemd-logind (or something like that), and there was definite concern that packages were already making decisions that were forcing everyone to adopt systemd as the only init system.

I stand corrected.

I eagerly await the publication of "SystemD: A History" and its subsequent adaptation into a dramatic screenplay.

You can get it in audiobook form here: https://www.youtube.com/watch?v=o_AIw9bGogo

> Basically, it started out as an init system... But systemd started to expand into its "middleware" position, absorbing vital system functions like udev.

Not true. From the start it was positioned as much more than an init system. This is clear just skimming the blog post announcing systemd http://0pointer.de/blog/projects/systemd.html

Among other things, it talks about:

-deferring launch of some services until they are needed, to speed up boot

-launching additional services and shutting down others in response to hardware changes (e.g. adding a usb device).

-taking some or all socket management away from daemons so that sockets can be ready before daemons are live or daemons can be shut down when there is no activity

-“babysitting” services including through cgroup based process management

-managing (some of the) access to /home and other directories

It’s quite a broad scoped announcement. Toward the end there is a “short list of other features”, numbered, ending at 20. Under “Where is this going?” he writes, “ The feature set described above is certainly already comprehensive. However, we have a few more things on our plate.”

systemd clearly started out as a broad based solution, and reading through that post, looking at the problems it addresses, and considering that launchd and upstart tackled similarly many issues, it’s clear why it is so broad - the world has changed. In the 70s on a pdp 11 it was sufficient to launch some daemons at boot, keep an eye on getty, and call it a day. Maybe ~50 years later a new, more comprehensive system makes sense? When Linux runs laptops and phones that are endlessly reconfiguring themselves in response to network, Bluetooth, usb, when systems are sleeping and waking routinely, when vastly more services run on a single machine, when conserving battery is important, when boot time can be reduced to seconds if things are better orchestrated? “standard ways of doing things” have changed in every other sector of society, basically, why wouldn’t they finally change in OS service management?

Sure, but most of that introductory post was about service management, and mount management, which are two areas the init system was traditionally heavily involved in. Sure, the init system might not technically have concerned itself with either, but a lot of the ordering considerations were very heavily concerned with both of those.

Now, no one will argue that systemd's service management capabilities far exceed what most historical init systems did. Heck, the traditional init system had interior service management to window's Service Control Manager implementation, since the classic init could not for example give a list of running services. And systemd is far more flexible and feature rich than Window's options now.

systemd-boot and timedated on the other hand are pretty darn disconnected from anything a classic init system was concerned with. It does feel like a lot of the non service/mount management parts of systemd are basically a grab bag of random stuff.

> This wasn't considered a particularly invasive change at the time.

It was pretty invasive - I tried to keep using Debian without systemd, but indirect dependencies always brought it in. Until I switched to Devuan.

And the dependencies brought in EVERYTHING. You could no longer mix and match, pick one part from here if it worked for you, and another part from there.

Which lead to the criticism that "systemd is not modular". Which Poettering denied, pointing out that there are modules at systemd-compile time, completely missing the point.

> So, more or less, people resent systemd because it's difficult to find - or build - a distro without it.

And I wouldn't have minded systemd as an INIT SYSTEM - the existing scripts WERE pretty bad. But systemd is like the Borg - it tries to assimilate everything. And it broke quite a bit of existing functionaility along this path.

Reply on news.ycombinator.com