|
|
Log in / Subscribe / Register

Another daemon for managing control groups

Another daemon for managing control groups

Posted Dec 8, 2013 13:13 UTC (Sun) by pizza (subscriber, #46)
In reply to: Another daemon for managing control groups by cas
Parent article: Another daemon for managing control groups

> and each of those modules can evolve independently of each other, with different implementations of each all striving to be the best of their kind (or, at least, to provide their own unique trade-off of features vs benefits). remember: one size does not fit all.

The problem with your argument is that it presumes that any of the alternatives are worth using -- Especially when you factor in the very real opportunity/maintainence/support cost of continuing to support alternatives with drastically fewer capabilities. You're forced to write everything to the least common denominator because you can't assume anything about anything else, and you're strongly discouraged from trying anything new because, well, it's "different."

Meanwhile, in the real world, modularity has always fallen away in favor of tight integration. For example, cars no longer let you bolt in any engine the manufacturer makes. They now have a single integrated IVI system that encompasses the radio, HVAC, and telemetry information. They are less maintainable and modifiable than ever, but in exchange for that they are by far the safest, most reliable and most performant that they have ever been.

Closer to home, computers have shed most of their modular expandability with the mass shift to laptops, and even laptops with their modicum of modularity are rapidly falling to a totally integrated tablet. OSes too have shed most of their modularity in favor of integration.

Modularity used to be a necessity to get anything done, now it mostly just adds disproportionate amounts of complexity for its little (real-world) gain. This is the same reason we use pre-packaged Linux distros/installers rather than building everything completely from scratch each time we do an install on a new system...


to post comments

Another daemon for managing control groups

Posted Dec 8, 2013 13:22 UTC (Sun) by Jandar (subscriber, #85683) [Link] (6 responses)

> For example, cars no longer let you bolt in any engine the manufacturer makes.

Car manufacturers are an example of increasing modularity. Where a few years ago every model had its own varying parts nowadays the same parts are used in numerous models.

Another daemon for managing control groups

Posted Dec 8, 2013 13:44 UTC (Sun) by pizza (subscriber, #46) [Link] (5 responses)

> Car manufacturers are an example of increasing modularity. Where a few years ago every model had its own varying parts nowadays the same parts are used in numerous models.

That's not *you* swapping parts willy-nilly, it's the manufacturer simplifying their designs to save themselves money at the time of design and manufacture.

For a typical modern car, you have no choice whatsoever when it comes to what core components you can use.

Try swapping out the fuel injection system. Or transmission. Or the engine. Or bolt on a supercharger/turbocharger. Or try to change the front-end suspension setup. Or raise the ground clearance. Or add a pickup bed.

Unless the manufacturer specifically sold that combination as an option, you're in for a serious world of hurt. Because modern cars are only modular when it comes to their manufacture, not their end-user.

Another daemon for managing control groups

Posted Dec 8, 2013 14:13 UTC (Sun) by Jandar (subscriber, #85683) [Link]

When was the last time where you could swap the engine between any chevrolet and any bmw?

Another daemon for managing control groups

Posted Dec 8, 2013 23:42 UTC (Sun) by dlang (guest, #313) [Link]

you must not be aware of the automotive aftermarket.

all the things that you talk about can be done, some brands are easier to work on than others, but there is a good supply of superchargers that you can add to your car, along with everything else.

Another daemon for managing control groups

Posted Jan 3, 2014 17:34 UTC (Fri) by aigarius (guest, #7329) [Link] (2 responses)

Right, and car manufacturers in this analogy are distributions and system administrators of large installations. Systemd is not flexible enough as designed. I want to replace the cron-equivalent with another tool, I want to use a different logind, I want to use a different cgroups manager.
Currently systemd attitude is that to get there I would need to recompile systemd with some custom options and possibly patch the code if I want different cgroups functionality.
That is not going to fly.
Systemd may expose some special functionality when run with its own cron, but to be a viable replacement it must be able to co-exist with the existing tools.
It could be as simple as wrapper-binaries - if you want proper permissions and monitoring for processes started from ye odle crond, you just add "systemd-start" to the beggining of the command line in your crontab.

The arrogance in refusing all the previous and competing solutions because "we've already considered it all and found it lacking" is a honking huge red flag for the health of the community.

Even if systemd was the greatest thing since sliced bread technically it would have to be forked and removed from the current development community before the rest of us could start becoming comfortable in depending on that.

Another daemon for managing control groups

Posted Jan 3, 2014 17:43 UTC (Fri) by andresfreund (subscriber, #69562) [Link]

Uh. And what exactly stops you from using vixie cron or your own logind implementation?

The case with cgroups is a bit different, but that's not really systemd's fault - the kernel/Tejun wants to move towards a single hierarchy, not systemd. Since systemd relies on controlling the cgroup hierarchy it cannot easily use a separate cgroup controlling daemon without having pid 1 rely on other processes without similar protections as pid 1 has from the kernel.

If there's things to critize about system's cgroup handling it's that they've built an API to control cgroups in a relatively short time which they are bound to continue to provide. Since it has to be generic enough to a) be implementable by others b) not block any future cgroup usage that makes me a bit wary.

Another daemon for managing control groups

Posted Jan 3, 2014 18:08 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

>Right, and car manufacturers in this analogy are distributions and system administrators of large installations. Systemd is not flexible enough as designed. I want to replace the cron-equivalent with another tool, I want to use a different logind, I want to use a different cgroups manager.

Nothing stops you from running your own cron implementation, syslog implementation or eschewing logind entirely. Systemd simply provides a lot of very convenient utilities but they are not mandatory.

The only problem is in the boneheaded single-writer cgroups hierarchy. But that's not entirely a systemd's failure.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds