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
