2 ms·

they are separate binaries - however all of them depend on systemd (post rev 205) and cannot be run independently. this is because all of systemd's services re

they are separate binaries - however all of them depend on systemd (post rev 205) and cannot be run independently. this is because all of systemd's services rely strongly on cgroups for resource control and upstream kernel wants a single reader/writer for the cgroups API (the current filesystem model is going away). systemd is just following lockstep with what kernel wants and is becoming that API. There has been a lot of FUD around the "PID 1" disaster, but invariably every init system will have to have a single point cgroup writer. Systemd is just ahead of the curve.

ithkuil 13y ago
http://lists.freedesktop.org/archives/systemd-devel/2013-June/011521.html http://lists.freedesktop.org/archives/systemd-devel/2013-Jun... Anyone has more information about this from the kernel perspective ? Will systemd be the only API ? Sounds strange.
- sandGorgon 13y ago
  This is a reasonable evaluation of the status - https://lwn.net/Articles/575672/ https://lwn.net/Articles/575672/ Basically, if you use systemd as the init system, then yes - it is the only API [1] . If you dont want to use systemd then there are alternate implementations of the cgroup API (e.g. cgmanager - http://cgmanager.linuxcontainers.org/ http://cgmanager.linuxcontainers.org/ ). IMHO, they are both incompatible with each other. Lennart has a reasonable justification of why systemd is implementing it's own API [2] [1] https://lwn.net/Articles/557111/ https://lwn.net/Articles/557111/ [2] https://lwn.net/Articles/557140/ https://lwn.net/Articles/557140/