Another daemon for managing control groups [LWN.net]

Another daemon for managing control groups

Posted Dec 6, 2013 13:13 UTC (Fri) by roblucid (guest, #48964)
In reply to: Another daemon for managing control groups by neilbrown
Parent article: Another daemon for managing control groups

Whilst appreciating Neil's point, it also seems to a more open philosophy to have program packages focussed on related tasks eg) setting up & managing raid whilst leaving FS layout, backup and so on to other tools. That makes it easier to evolve with time, because new features or projects improving on past work, only need to replicate a limited set of functionality.

The monolithic approach is disliked, because it leads to stagnation and lock in. Perhaps a new kernel feeature, would in practice require support by systemd, which in might not be of interest to that project; yet other projects would be faced with a daunting task to replicate a whole host of systemd compatible features, because of it's wide remit. This is why it could be so hard to replace MS Exchange servers in business; they weren't just doing email, but group meeting planning and so on.

systemd, merging init(8) and inetd(8) makes good sense, it's less clear what the benefit is of multiple incompatible implementations of cgroup managament to me. systemd's implementation is going to be rather experimental, which is very different from integrating in a better more modern implementation init & inetd; they may not have the best ideas but because of systemd becoming ubiquitous we could be lumbered with something satisfactory, rather than the best.

to post comments

Another daemon for managing control groups

Posted Dec 6, 2013 15:00 UTC (Fri) by anselm (subscriber, #2796) [Link] (13 responses)

it also seems to a more open philosophy to have program packages focussed on related tasks eg) setting up & managing raid whilst leaving FS layout, backup and so on to other tools. That makes it easier to evolve with time, because new features or projects improving on past work, only need to replicate a limited set of functionality.

On the other hand, the latest fashion in file systems seems to be all-in-one approaches like ZFS and Btrfs, which combine file, volume, and RAID management, snapshots, etc. in one single implementation instead of relying on existing system features such as LVM and Linux kernel RAID.

It is interesting to note that the backlash against these new file systems is a lot less emotional than the one against systemd, even though the underlying idea of coming up with a radical new integrated design to replace a number of loosely-connected existing but sub-optimal infrastructure elements is quite similar. (But then again, Btrfs wasn't invented by Lennart Poettering.)

Another daemon for managing control groups

Posted Dec 6, 2013 16:27 UTC (Fri) by dlang (guest, #313) [Link] (10 responses)

> It is interesting to note that the backlash against these new file systems is a lot less emotional than the one against systemd

The reason for this is very easy to understand, nobody is forcing anyone to use the new filesystem.

Even if a distro were to change to use one of these new filesystems by default, the distro would not remove support for the existing filesystems, and would be extremely unlikely to make it so that if you selected one of the other filesystems you would have lots of other things you had to change in the distro as well.

It's really easy to have your system using different filesystems for different tasks.

It's really hard to have multiple init systems in your distro, even as options. And it's impossible to have a new init program on your system that you only use for some testing things.

Another daemon for managing control groups

Posted Dec 6, 2013 16:50 UTC (Fri) by anselm (subscriber, #2796) [Link] (6 responses)

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 18:09 UTC (Fri) by dlang (guest, #313) [Link]

sure, you can abandon the distro that you have been using when they change init systems.

you then have to listen to people harass other distros because they are being 'backwards' and not using the new init system.

people are far more careful about changing filesystems because a filesystem bug will eat their data, and distros that eat people's data tend to disappear :-)

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.

Another daemon for managing control groups

Posted Dec 10, 2013 19:06 UTC (Tue) by BenHutchings (subscriber, #37955) [Link] (2 responses)

Even if a distro were to change to use one of these new filesystems by default, the distro would not remove support for the existing filesystems,

It certainly might remove support for existing filesystems as root. For example, the package manager might be changed to require transaction support. (I would expect to hear a similar outcry if this actually happens in a mainstream distro.)

Another daemon for managing control groups

Posted Dec 10, 2013 22:12 UTC (Tue) by anselm (subscriber, #2796) [Link] (1 responses)

For example, the package manager might be changed to require transaction support. (I would expect to hear a similar outcry if this actually happens in a mainstream distro.)

OpenSUSE and SLES are apparently moving in that direction. Recent incarnations of YaST use a tool called »Snapper« to make snapshots of the root file system before and after configuration changes; if you want to avail yourself of that functionality you are pretty much forced to use Btrfs. So far people don't seem to get as worked up about this as they do over systemd (which to be fair was introduced to openSUSE some time ago, seemingly without much of a fuss either).

Another daemon for managing control groups

Posted Jan 1, 2014 12:27 UTC (Wed) by jospoortvliet (guest, #33164) [Link]

Note that some work is ongoing to support this on non-btrfs filesystems...

Another daemon for managing control groups

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

<quote> It is interesting to note that the backlash against these new file systems is a lot less emotional than the one against systemd, even though the underlying idea of coming up with a radical new integrated design to replace a number of loosely-connected existing but sub-optimal infrastructure elements is quite similar. (But then again, Btrfs wasn't invented by Lennart Poettering.) </quote>

AFAIK, no distros have plans to adopt a single filesystem as the One True filesystem and stop supporting all others. The same cannot be said for systemd.

The upshot of this is that while you're always free to run whatever FS you choose despite the default choice of your distro's installer, the same cannot be said for the ease with which one can switch init systems.

Another daemon for managing control groups

Posted Dec 10, 2013 8:29 UTC (Tue) by zdzichu (subscriber, #17118) [Link]

Memory fades fast. There was "blatant layering violation" as a nickname for ZFS for some time.

Another daemon for managing control groups

Posted Dec 7, 2013 0:26 UTC (Sat) by rgmoore (✭ supporter ✭, #75) [Link]

it's less clear what the benefit is of multiple incompatible implementations of cgroup managament to me.

The requirement of a single manager for cgroups is coming from the kernel side, not from systemd. Since systemd makes very heavy use of cgroups for process management, it makes sense for systemd to be that manager in distributions that use it. Otherwise, you have the init system depending on another process to do a truly essential part of its job, which doesn't seem any simpler than having an integrated system.