[arch-general] When will Arch switch to Systemd

Tom Gundersen teg at jklm.no
Thu Jan 20 18:45:46 EST 2011

On Thu, Jan 20, 2011 at 11:17 PM, Jan Steffens <jan.steffens at gmail.com> wrote:
> Note that grouping processes using cgroups does not imply having to
> use the group scheduler . IIRC systemd uses a debugging hierarchy by
> default which does not affect program resources.

This is correct. If you want, systemd can put your program in
different kinds of cgroups to restrict resources (have a look in
/etc/systemd/system.conf), but because of the possible problem
outlined by "FA" above, the cpu cgroup hirearchy is off by default
(hopefully the underlying problem will be fixed in the kernel soon, so
we can enable some usefull cgroups by default, but in any case this
functionality can always be turned off).


1) In my experience Lennart has been a pleasure to work with.

2) Regarding systemd and "The Arch Way", I guess this is a matter of
opinion, but the way I see it, systemd fits perfecttly. For two
reasons (off the top of my head, there might be more):

Firstly, while systemd is more complex (due to more features) than
sysvinit, the arch-specific parts of systemd are much simpler than the
arch-specific parts of sysvinit (since systemd does most of what
rc.sysinit and rc.shutdown do for sysvinit). In fact, by pushing as
much as our boot process "upstream" and sharing it with other
distributions, we simplify our lives significantly due to the "free"
testing and development effort we receive (especially the integration
of the init system and related packages like udev and util-linux).

Secondly, in a world where devices might come and go and their
dependencies might be arbitrarily complex, the sysvinit architecture
cannot work in a clean way. SysVinit was created when all setups could
be assumed to be static, and this is simply no longer the case (this
can best be seen in a setup with lots of raid/lvm/encrypted devices).



More information about the arch-general mailing list