The Grumpy Editor's guide to surviving the systemd debate [LWN.net]

The Grumpy Editor's guide to surviving the systemd debate

Posted Dec 2, 2014 8:34 UTC (Tue) by anselm (subscriber, #2796)
In reply to: The Grumpy Editor's guide to surviving the systemd debate by blujay
Parent article: The Grumpy Editor's guide to surviving the systemd debate

Systemd is changing quickly because it is a new project (compared to OpenSSH, anyway). It will eventually settle down and evolve at a much slower rate, at which point a “portable” version may become more interesting to consider.

It is also worth pointing out that the systemd developers have not said that they will not ever consider any “portability patches” whatsoever, just that the idea doesn't make a lot of sense because systemd relies extensively on Linux-only kernel features and that as long as such patches don't exist the point is moot, anyway. Again, from the systemd developers' POV it makes good technical sense to focus on Linux first, and to deliver a clean and correct code base that runs on Linux. Once systemd does what it is supposed to do on Linux, there may come a time to think about what parts of systemd's functionality can usefully be adapted for other systems, and what extensions to those systems (e.g., additional kernel features or Linux compatibility layers) would be required for systemd support. This might eventually lead to a “portable” systemd maintained in a separate repository à la OpenSSH, and while the systemd developers may not be interested in “portability patches” per se, if there are reasonable “cleanup patches” that facilitate this without unduly complicating systemd's Linux-oriented code base then I think those might well be accepted.

to post comments

The Grumpy Editor's guide to surviving the systemd debate

Posted Dec 2, 2014 17:41 UTC (Tue) by dlang (guest, #313) [Link] (1 responses)

given that the scope of systemd is not defined, how long for it to settle down? it could be a couple of decades.

Part of what people aren't liking is the dependence on linux-only features without any fallback to operate without them.

If cgroups are required to be in the kernel, but you can operate without using any controllers (as was stated in some thread on lwn in the last few days), then refusing to boot when cgroups aren't in the kernel is the wrong thing to do. That would be one linux-only feature that would change from a hard dependency to a feature to be used when available.

The Grumpy Editor's guide to surviving the systemd debate

Posted Dec 2, 2014 20:51 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

> If cgroups are required to be in the kernel, but you can operate without using any controllers (as was stated in some thread on lwn in the last few days), then refusing to boot when cgroups aren't in the kernel is the wrong thing to do.
Uhm, you still NEED cgroups to use systemd. It can't really work without them.

However, you don't need any cgroups-based resource management to be turned on (or even compiled in). In this case cgroups will be used only for process tracking and nothing else.