
Why did ArchLinux embrace Systemd? - barsonme
http://www.reddit.com/r/archlinux/comments/4lzxs3/why_did_archlinux_embrace_systemd/d3rhxlc
======
scrupulusalbion
Its nice to see this sort of explanation. I just wish this had come out
earlier, like when Arch was in the process of switching over to 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)?

~~~
digi_owl
Most sane package manager i have encountered will place a copy of the new
script or config file next to an existing one of there is some level of
mismatch.

And rarely would you not get a system to boot to some kind of login prompt
with traditional init. If the fear of not getting a GUI is what is driving he
adoption of systemd, then i really worry about future generations of admins...

------
digi_owl
One thing to ponder is that many of the people that introduced the various
problem spots mentioned, are the very same people that are today working on
systemd.

------
JdeBP
It's interesting contrasting Arch with the Debian hoo-hah.

* 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...](http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/system-5-rc-problems.html))

* 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...](http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh/avoid-dbus-bus-activation.html)

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

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

And Canonical gets yelled at for being NIH...

