[arch-general] When will Arch switch to Systemd
yaro at marupa.net
Thu Jan 20 19:25:24 EST 2011
On Thursday, January 20, 2011 05:45:46 pm Tom Gundersen wrote:
> 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
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
> 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?
More information about the arch-general