Debian debates systemd

Posted Jul 30, 2011 2:31 UTC (Sat) by sbergman27 (guest, #10767)
Parent article: Debian debates systemd

After living through (and continuing to live through) the nightmare of pulseaudio these last several years, I'm quite leary of Lennart Poettering's software. Debian is a damned good distro for its intended audience. If you have hardware that is less than a couple of years old, you might not want to bother. But if you don't, and want a nice, stable environment, use Debian. Systemd is an incredibly bad fit here.

We're talking about a distro which, to its credit, defaults to ext3, and goes the extra mile of seeing through the bullshit that made data=writeback the default for ext3 in kernel 2.6.30, and sets the kernel config option to make the tried and true data=ordered the default.

I just can't see perpetually alpha quality software like systemd going into Debian. And if they were going to change their init system, which I would not advise for their next release, Upstart would be a less bad choice.

Despite what people might tell you, the SysV Init system is still quite serviceable. It's not the fanciest. And it's not the best, if you're looking for features. But it works, and works well.

-Steve

Debian debates systemd

Posted Jul 30, 2011 15:53 UTC (Sat) by BenHutchings (subscriber, #37955) [Link] (3 responses)

I would consider most init scripts to be 'perpetually alpha quality software'.

Debian debates systemd

Posted Jul 31, 2011 2:10 UTC (Sun) by sbergman27 (guest, #10767) [Link] (2 responses)

I would consider most init scripts to be 'perpetually alpha quality software'.

Really? If I had to bet my life on something working properly, Debian's init scripts would definitely make the short list. Not so, systemd. Look, Debian is not Fedora. People simply expect Fedora to be shiny and have problems. And they expect Debian to be boring and work right. And I'll take boring and working right any day of the week. I'd give both systemd and upstart a pass until Debian x+2.

Debian debates systemd

Posted Aug 1, 2011 8:45 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

LOL ROTFL.

I've had many many many problems with Debian init scripts over the years. Right now, on one machine BIND init script hangs the shutdown process (luckily not after SSH is shut down). I've no idea why and too lazy to check it.

I've seen problems with Apache init scripts, lighttpd init scripts, postfix init scripts and so on over the years. All in Debian (I don't really use other distributions).

That's why I consider systemd to be such a good idea. Getting rid of these scripts is a great way to improve Linux.

Debian debates systemd

Posted Aug 1, 2011 19:40 UTC (Mon) by bronson (subscriber, #4806) [Link]

> If I had to bet my life on something working properly, Debian's init scripts would definitely make the short list.

Really??? I guess we'll miss you when you're gone.

Half of Debian's init scripts don't even support restart properly. Ever purged a package and found the daemon still running? Ever tried /etc/init.d/blah stop, seen no error, yet you need to go hunt down the daemon by hand? Happens to me all the time.

I love Debian, but please never ever bet your life on its crawling mess of always changing init scripts!

Debian debates systemd

Posted Jul 31, 2011 0:24 UTC (Sun) by gerdesj (subscriber, #5446) [Link] (9 responses)

What the hell has PulseAudio got to do with systemd?

I'll digress:

I run Gentoo on everything I have. I don't run PulseAudio on anything, whatever that is. I don't think its an OS and I'm pretty sure I can ignore it if I don't want it.

I do have to start and stop services on my systems and it would be nice if I could do that with some certainty as to their behaviour. Now Gentoo does things quite similarly to the SysV Init way, which is crap. You tell the service to stop and for some reason it doesn't but the system thinks it has. Then I get to play with ps and then kill or killall. This wastes my time.

Now, systemd can guarantee that a service has stopped by using the kernel interface by dropping the cgroup. It does things the right way.

There are quite a few other aspects of systemd that are quite useful.

As a sysadmin of quite a few systems, systemd is looking like a good idea.

Cheers
Jon

PS L Poetering does come across as a bit of a wanker but you cant fault systemd for that.

Debian debates systemd

Posted Jul 31, 2011 1:55 UTC (Sun) by sbergman27 (guest, #10767) [Link] (8 responses)

"What the hell has PulseAudio got to do with systemd?"

Everything. Years after its initial debut, I still have to kill PA and restart it on both desktop machines and my netbook something like twice a day. (No. I'm not exagerating.) It goes into a mode where everything sounds like alien flute tunes. Every 6 months, I encounter another set of PA problems. Not a huge deal since it's simply a sound issue. But it says something about the author/maintainer. I certainly would never want to trust my customers' servers to Lennart's idea of software quality. The guy has an attitude problem, and it shows up, clearly, in his work.

Debian debates systemd

Posted Aug 1, 2011 8:48 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (7 responses)

Hm. It looks like your drivers are crap.

I've been running PulseAudio on tens of different devices without any problem at all for a couple of years now.

Debian debates systemd

Posted Aug 1, 2011 16:38 UTC (Mon) by sbergman27 (guest, #10767) [Link] (6 responses)

Right. All my machines for the last several years have had crap drivers. If that's the case, what does it say about Linux?

Odd thing, though. If I disable PA completely and replace it with esd, all those problems magically disappear.

Debian debates systemd

Posted Aug 1, 2011 16:41 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (5 responses)

It says that sound drivers are crap.

And I really find it hard to believe that it all magically works with ESD without having a lot of fun with ALSA config files.

Debian debates systemd

Posted Aug 1, 2011 17:50 UTC (Mon) by sfeam (subscriber, #2841) [Link] (1 responses)

The difference being that once you have an ALSA configuration working, it stays working. Whereas in my sad experience pulseaudio's configuration only stays working until the next suspend/resume or reboot or phase of the moon. For USB sound, chances are about 50/50 that after a resume pulseaudio will refuse to admit the device still exists. The only reliable fix I've found for this is to blow away ~/.pulse and restart from scratch. Now maybe there is a configuration option that I've failed to find - one that says "pin this device across suspend/resume; even if you don't see it immediately, it _will_ come back." If so, I may be falsely blaming the implementation when it is more correctly a documentation failure.

Debian debates systemd

Posted Aug 1, 2011 19:07 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

Not so. I've had persistent problems with ALSA (and OSS) before the PA.

Your USB issue seems to be related to your USB devices. I have a USB camera/microphone and they work just fine.

May be you should file bugs?

Debian debates systemd

Posted Aug 2, 2011 2:34 UTC (Tue) by Trelane (subscriber, #56877) [Link]

Perhaps, but at least it says that Linux device drivers aren't the same as Windows device drivers, leading to bugs in the hardware getting exposed to Linux and not Windows. See also mjg59's stuff on the importance of Doing It Like Windows.

Debian debates systemd

Posted Aug 4, 2011 21:25 UTC (Thu) by oak (guest, #2786) [Link] (1 responses)

ESD? Shudder. When they finally abandoned it, it still had battery eating daemon/lib error-handling/busyloop bug(s). KDE's sound daemon wasn't any better in the bugginess department. And I think these bugs were in the daemons themselves, not in the audio drivers.

Debian debates systemd

Posted Aug 8, 2011 10:51 UTC (Mon) by nye (subscriber, #51576) [Link]

>ESD? Shudder. When they finally abandoned it, it still had battery eating daemon/lib error-handling/busyloop bug(s).

Battery-eating isn't the end of the world - especially back when ESD was written since we didn't have all the CPU power states we do now, and hardly anyone had a laptop, so it didn't end up making much difference. The real problem with ESD was the randomly high latency and the fact that it was buggy and unstable.

That said, even today it's the only reliable-ish method of forwarding sound from a Linux machine to a Windows machine. Fortunately it looks like some brave soul has been working on getting PA running on Windows, so maybe within a year or two this crawling horror can finally be put to rest.