On Sat, Apr 13, 2013 at 8:34 PM, Stefan Seyfried
Right now I would appreciate a working SysV-Init implementation we had for 20 years much more than the ever changing and ever broken crap that systemd is.
It is not.
Maybe it works for you, but for me it is an nondeterministic heap of crap. Latest example: Curiously after timedatectl was mentioned in this hread, I issued "timedatectl" as a nonprivileged user(!) to see what it would give me. Now I no longer can start / stop ntp and ntp is broken. WTF? (Yes, I killed all involved processes I could find in the mean time). Probably the solution will be a reboot. Systemd really brings us closer to the other "great" Desktop OS's.
Initially I was thinking that systemd was a good idea, right now I'm seriously considering switching to a busybox based home-built primitive init that *just works* in a deterministic way (I have about 20 different systems sitting in my A/V shelf, all running different busybox-based init systems just fine and very reliably). In theory, systemd should be more deterministic, but obviously it is only tested in very few different scenarios and mine (a pretty normal, moderately old laptop with bluetooth and wireless networking used and an encrypted $HOME) is not one of them. Probably it's too exotic. Encryption is only for terrorists and as such not supported :-)
At least I'll use busybox init as an alternative implementation to get the system up when systemd fails.
This story reminds me of ReiserFS. Good in theory, not so hot in practice. I must say that after updating that old ReiserFS-based system I had (from back when Reiser was SUSE's default), it's now working quite glitch-free. No tree rebuilds have been necessary in ages. I'd expect SystemD will become usable far far after people give up on it. All because it was introduced into distros quite prematurely. In any case, aside from the obscurity of it, I haven't found such big roadblocks with SystemD. It has an incredibly steep learning curve though. For those used to the simplicity of SysVInit (once installed), SystemD is as obscure as Windows' registry database. I felt like that when I wanted to move kdm's startup sequence to a bit earlier (it seems to wait for way more than would be required, delaying the login screen), and for the life of me every step felt like I was going to have to ask a clairvoyant or something, because it was nigh-impossible to follow. I failed, btw, since the dependency is buried away in heaps of indirection, and changing it would have required massive restructuring of the distro's init sequence. Not to mention the error messages, SystemD must have been the golden disciple of C++ in that sense. TBH, from what I saw, I think most of this obscurity stems from trying to keep sysvinit scripts around. Anyway, I digress. SLES will probably end up using SystemE, a fictitious next-incarnation of SystemD, built with all the experience learned from SystemD's mistakes Like btrfs seems compared to ReiserFS. Only that will take about 5 years, if Reiser's story holds equivalent. Until then... prepare to rebuild your tree... I mean swap your busybox quite often. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org