Hacker News new | past | comments | ask | show | jobs | submit login

You've read wrong, unfortunately. http://lwn.net/Articles/557082/ describes that:

> Unprivileged access to the cgroup hierarchy will be strongly discouraged; the hope is to have a single, privileged process handling all of the cgroup management tasks. That process will, in turn, provide some sort of higher-level interface to the rest of the system.

and that:

> This hierarchy becomes private property of systemd. systemd will set it up. Systemd will maintain it. Systemd will rearrange it. Other software that wants to make use of cgroups can do so only through systemd's APIs.

That is, systemd will implement a manager on top of the new cgroups API, and all cgroups users will be assumed to go through systemd.




systemd manages cgroups on systemd based system. The systems that do not use systemd can implement their own cgroup managers. The kernel makes no assumptions on what manager you use on userspace. Other managers could also reimplement the systemd dbus API for managing the cgroups.


> The systems that do not use systemd can implement their own cgroup managers. [...] Other managers could also reimplement the systemd dbus API for managing the cgroups.

True, except that the systemd developers are in charge of defining this API and have no reason to consult with other cgroups manager developers when defining it. This is, to make an analogy, equivalent to allowing Microsoft to unilaterally define all web standards from now on. The competitors are always going to be playing catch-up, and there's going to be tons of edge cases where the competitors don't quite work the same.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: