Another daemon for managing control groups [LWN.net]

Another daemon for managing control groups

Posted Dec 6, 2013 16:50 UTC (Fri) by anselm (subscriber, #2796)
In reply to: Another daemon for managing control groups by dlang
Parent article: Another daemon for managing control groups

nobody is forcing anyone to use the new filesystem.

Nobody is »forcing« anyone to use the new init system, either. It may be the case that a Linux distribution or a project like GNOME decides to take advantage of the new features and better integration that something like systemd has to offer, but if you don't want to come along for the ride there's always the likes of Slackware. The beauty of free software means that for as long as enough people want to stick with SysV init desperately enough, there will be a distribution (or distributions) around that is based on SysV init.

As far as file systems are concerned, the most recent SUSE distributions, for example, do »force« you onto Btrfs if you want to avail yourself of advanced tools like Snapper – and SUSE's enterprise-class distribution doesn't even support Ext4 (which arguably is the file system one would want to use if one didn't want to use Btrfs). Hence the situation isn't all that different, it's just that with file systems the »out with the old, in with the new« phenomenon isn't as widespread yet. This may also be to do with the fact that an init system is conceptually a lot simpler than a modern advanced file system, and that, for the time being, people (and in particular distribution makers) appear to be more inclined to trust systemd over SysV init than Btrfs over Ext4.

Another daemon for managing control groups

Posted Dec 6, 2013 23:19 UTC (Fri) by nix (subscriber, #2304) [Link] (4 responses)

I note that people who write filesystems are paranoid bastards who know what backward compatibility is for. The history of udev and pulseaudio and all of Lennart's projects makes me think that he wouldn't know backward compatibility if it shook him very hard by the throat. PA only settled down and stopped breaking things for all its users on almost every upgrade when Lennart was no longer doing most of the maintenance. I see no sign that udev (which I long gave up trying to upgrade at despair at its constant pointless disruptive changes) and systemd are ceasing in their ongoing attempts to break the world.

After all, adapting to all that breakage is up to the *distribution*! And, oh yes, if you're not using Fedora and/or otherwise *precisely* the same platform Lennart is and experience problems you can bugger off. Or that's what I've seen Lennart saying over and over and over to quite tiresome lengths. (And, no, I'm *not* going to use a distro with a six-month lifespan for anything important. I need a greater degree of stability, without being stuck in the six-year-old software mire of the 'enterprise' distros, which apparently makes me a niche market nobody cares about.)

Another daemon for managing control groups

Posted Dec 7, 2013 0:20 UTC (Sat) by pizza (subscriber, #46) [Link] (3 responses)

Comments:

udev was primarily developed by GregKH. Though udev is now part of the systemd tree it is an independently-developed component that is one of the fundamental building blocks of a Linux system.

Meanwhile, Pulseaudio's user-facing problems were threefold -- Bugs in hardware drivers, bugs in ALSA's user plugin system, and horrendously buggy applications. Oh, and it was still a vast, vast improvement over what came before. (I say this as someone who has written a decent amount of audio code over the years..)

This is not unlike NetworkManager, which exposed the inconsistent behaviour of wifi drivers supposedly implementing the same Wireless Extensions interface (and the even more inconsistent event interface) and how every single WEXT client had to use device-specific hacks to ensure consistent behaviour.

I find it sad that the folks who put forth the effort to sanitize core infrastructure bits are blasted for all of the bugs they uncover (and fix!) in the process, while those same voices complain about how Linux isn't ready because things aren't transparently integrated and fully tested like $somecommercialos. This work doesn't just happen, and there are frightfully few people with the technical chops and skin thick enough to accomplish this.

Another daemon for managing control groups

Posted Dec 9, 2013 2:40 UTC (Mon) by ThinkRob (guest, #64513) [Link] (2 responses)

> Meanwhile, Pulseaudio's user-facing problems were threefold -- Bugs in hardware drivers, bugs in ALSA's user plugin system, and horrendously buggy applications. Oh, and it was still a vast, vast improvement over what came before. (I say this as someone who has written a decent amount of audio code over the years..)

Wasn't one of the somethings that came before something that had per-application mixing, a consistent cross-platform API (and cross-platform implementations), existing application support, and precise, lower-latency mixing? i.e. most of pulse's features, sans network streaming?

Another daemon for managing control groups

Posted Dec 9, 2013 13:44 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (1 responses)

If you're thinking of JACK, it is a little on the high end and complicated for just getting mplayer to play audio at the same time as notifications. Pulseaudio works with JACK for handoff IIRC, so they can cooperate. If you're thinking of OSS4 or aRTS, I think those are pretty much dead in Linux-land.

Another daemon for managing control groups

Posted Dec 10, 2013 5:56 UTC (Tue) by ThinkRob (guest, #64513) [Link]

I was thinking of OSS4, which is both still developed for, and still quite usable in Linux. It's just (sadly) no longer the default, in large part due to self-inflicted wounds.