Why did ArchLinux embrace Systemd?

>Lack of confiurability. It was impossible to change the behaviour of initscripts in a way that would survive system updates.

I wonder how often updates (dist-upgrades or package updates?) actually break initscripts. Further, would it make a system no longer boot fully (e.g. to the GUI login prompt)?

* In Debian, there was a whole load of voting, including votes by the entire membership; and upstart, systemd, and OpenRC were all considered in detail. In Arch, just one person decided to stop doing the Arch rc scripts and switch to systemd, without looking at upstart, OpenRC, or anything else.

* In Debian (some) people gave thought to the impact on the users, and to migration paths. (It didn't work out well in practice. There's a never-fixed systemd bug that stops Debian 7 systemd to Debian 8 systemd upgrade. But that's by the way.) In Arch, the driving concern was what's simplest for the maintainer.

* In Debian, the discussion involved reasons why one should switch to other systems. In Arch, the reasons given are all about why rc scripts are bad, something which we've known for three decades, and mainly deal in why one should switch away from rc scripts. (See http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/sy...)

* In Debian, the rc script maintainer (Roger Leigh) kept on with rc scripts and switched to Devuan. In Arch, the rc script maintainer dropped rc scripts and kept with Arch.

There are a few outright errors that the sort of peer review that the Debian hoo-hah did (which extended to things like how the daemon readiness protocols worked) would have caught but did not for Arch, since it was one person making a decision and publishing the reasons only years later. For examples:

> An system that can perform actions based on events - this is one of the major features of systemd.

No. This is a major feature of upstart. It is upstart that has the radically new and paradigm-shifting event-driven architecture; not systemd.

> Systemd has a 100% reliable solution for this based on Linux cgroups.

This is a myth. control groups are not jobs (in the VMS sense). They don't magically fix everything. There are (for example) systemd bugs, outstanding even now, dealing with the inability to atomically kill everything in a control group. systemd has to sit in a loop repeatedly re-reading the process list and sending out signals. An operating system kernel that provides a "job" abstraction provides a way of cancelling/killing an entire "job". Witness the Win32 TerminateJobObject() mechanism, for example. To repeat: control groups are not jobs.

> Udev or dbus don't start daemons anymore, they tell systemd that they need a specific daemon and systemd takes care of it.

This is a falsehood. Desktop Bus activation is unfortunately still with us, as is udev activation. There's irony in the case of Desktop Bus activation. The upstart people wanted to come up with a general protocol that would pass everything over to service management in a general way. The systemd people blocked the proposal.

* http://homepage.ntlworld.com./jonathan.deboynepollard/Softwa...

Indeed, Desktop Bus activation is one of the things involved in the recent kerfuffle over systemd killing nohupped processes, from wget and emacs to screen and tmux. The Freedesktop bug report (bug #94508) contains snapshots of several people's running systems showing quite a lot of servers that are still being spawned straight from the Desktop Bus broker.

It's also one of the reasons underlying the lesser-known still ongoing problem with systemd's DefaultTasksMax setting (https://news.ycombinator.com/item?id=11675129). People have been reporting servers spawned from the Desktop Bus broker all running within the broker's thread limits.