[arch-general] When will Arch switch to Systemd

[Yaro Kasear]

On Thursday, January 20, 2011 05:45:46 pm Tom Gundersen wrote:

(snip)

> @Yaro:
> 
> 1) In my experience Lennart has been a pleasure to work with.
> 

I, personally, have never worked with him. I have seen enough criticism of 
Pulse Audio, for example, getting handwaved and pinned on someone else's 
project. I think about it logically: 

If it works fine with ALSA, why did it inexplicably stop working fine with 
Pulse Audio running? Why, when he claims that PA not working is the fault of 
some distribution doing it wrong that it's busted no matter what system I try 
it on?

Lennart has never, in his explanations of how PA actually screws up, actually 
explained to my satisfaction. And with PA being as flawed as it seems to me, 
systemd really worries me. From my perspective he couldn't get a sound daemon 
written that couldn't get sound working right on my system, why am I to 
believe systemd would fare any better.

Let me put it another way, it seems like Lennart's great on new ideas on how 
to do things, poor on execution. From where I am sitting, anyway

This is getting off-topic, and I don't mean to start a "Lennart sucks" flame 
war.

> 2) Regarding systemd and "The Arch Way", I guess this is a matter of
> opinion, but the way I see it, systemd fits perfecttly. For two
> reasons (off the top of my head, there might be more):
> 
> Firstly, while systemd is more complex (due to more features) than
> sysvinit, the arch-specific parts of systemd are much simpler than the
> arch-specific parts of sysvinit (since systemd does most of what
> rc.sysinit and rc.shutdown do for sysvinit).

Isn't the fact that systemd is more complex already makes it more or less 
against Arch's KISS principles? Or am I confused?

> In fact, by pushing as
> much as our boot process "upstream" and sharing it with other
> distributions, we simplify our lives significantly due to the "free"
> testing and development effort we receive (especially the integration
> of the init system and related packages like udev and util-linux).
>

I certainly can't fault that part. That's probably open source's greatest 
strength. ESR called it "Linus' Law" and he explained it succinctly in the 
CatB paper. My concern is about how cooperative and willing to fix known 
issues upstream will have. You can write patches, but only one person (Or 
possibly, a group of people.) can approve it for an official inclusion with 
upstream. How many patches has Lennart rejected on systemd? How many has he 
accepted? Of those has he rejected has he given a verifiable reason?

> Secondly, in a world where devices might come and go and their
> dependencies might be arbitrarily complex, the sysvinit architecture
> cannot work in a clean way. SysVinit was created when all setups could
> be assumed to be static, and this is simply no longer the case (this
> can best be seen in a setup with lots of raid/lvm/encrypted devices).
> 

I admit to never using RAID/LVM/ENCRYPTION. But last I checked init had 
nothing whatsoever to do with how /dev is populated or managed. We have udev 
for that, and udev doesn't care what init system we use. All inits do is call 
udev when their scripts tell them to. I don't see how this makes systemd more 
viable than SysV when udev is what controls this instead, as udev works the 
same no matter if its SysV, Upstart, or systemd.

Perhaps you can clarify init's role in device population besides running udev 
when appropriate, as SysV is already capable of that?

> Cheers,
> 
> Tom