[arch-general] When will Arch switch to Systemd

[Heiko Baums]

Am Fri, 21 Jan 2011 09:03:23 +0800
schrieb Ng Oon-Ee <ngoonee at gmail.com>:

> This talk is probably a year or so out of date however. Try pulseaudio
> now, I think you'll be pleasantly surprised. You'd also have noticed
> that actual bug reports on our forums/ML etc. concerning pulseaudio
> have dropped to close to nil.

Well, PulseAudio is a bit off-topic here, but PulseAudio doesn't work
with professional or semi-professional audio cards like ice1712 based
cards like the M-Audio Audiophile 24/96 that I've got. And there's also
no working PA mixer for these audio cards. ALSA is working perfectly
with these cards including mixing sounds of every software by dmix and
the only, but perfectly working mixer for these cards is envy24control
from alsa-tools or alsa-tools-ice1712. This issue is quite old on
upstream's bug tracker, but not fixed, yet. And the posted workarounds
don't work for me or, if they could work, are just PITA.

My concerns regarding systemd are:

1. A possible loss of control over my system due to many unnecessary
automations and dynamizations.

2. I don't like automounting. I want to have control over my drives and
partitions and want to decide which partition is (auto-)mounted
(that's what /etc/fstab is for) or not.

3. Parallel booting (staring several daemons parallel at boot time) can
make booting significantly slower particularly on older and slower
systems. Serial is quite often a lot faster than parallel. The harddisk
can only make one read or write access at a time. So there's hardly
benefit of starting daemons (reading them from the harddisk) parallel.
Btw., such a parallelization of starting daemons is already possible
with Arch's and Gentoo's sysv init system. So systemd is not needed for
that.

4. Somewhere (I can't remember where) I've read that systemd starts
daemons only when they are needed. So if the daemons aren't started at
boottime but later than it's obvious that the system is booting faster.
But starting the daemons at runtime will take this saved time later,
means you first have to wait longer for the daemon to be started and to
be able to use its service for the first time. And again there's the
point of loss of control over the system. I want to decide when a
daemon is needed and when a daemon shall be started, and I don't want
another daemon to decide that.

5. In the same article I read that systemd binds itself to port 80
instead of starting apache at boottime and starts apache only if a
request to port 80 comes in. This is not the task of an init system, and
I have slight security concerns about that. If I tell the init system
that I want apache being started then I want to have apache started at
boottime or when I say so and not when systemd thinks it is needed.
And this way systemd first needs to unbind itself from port 80 and then
start apache and bind it to port 80. So if I open port 80 in my firewall
this port is open without a software being bound to it, even if it's
only a millisecond.

6. There's again an additional daemon which is always running in the
background and eating unnecessarily system resources which could much
better be used for the programs which are really used.

7. I'm using LVM and harddisk encryption. So systemd seems not to work
for me anyway.

Regarding the arguments about having more control over started daemons.
Have you guys already read the boot messages? There are such nice
messages "[BUSY]", "[DONE]", "[FAIL]" at the end of almost every line.
And there's /var/log, dmesg and tools like ps, top, htop, etc. For my
part I have total control over my running or not running daemons and
other software.

I'm not quite sure if I'm right with my concerns, because I haven't
tested systemd and don't know much about it, yet. So, please, correct
me if I'm wrong and explain it. But I don't like too much automation
and dynamization anyway, because it easily can make things worse and
lead to loss of control over the system.

I'm quite satisfied with the current sysv init. It does everything
which is needed to be done at boottime. And the init process simply is
only for booting the system and for nothing else.

Btw., Ubuntu with its upstart or systemd is not starting faster for me
than Arch Linux with its sysv init, at least not in Virtualbox and QEMU.

Heiko