[arch-general] When will Arch switch to Systemd

[Philipp Überbacher]

Excerpts from Heiko Baums's message of 2011-01-21 03:07:27 +0100:
> 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

I'm worried about pretty much the same things.

I have to admit that I don't know a lot of technical details, be it
about SysVinit or systemd but I start to see what kind of person Lennart
is and hence in which direction the systemd project is going. systemd,
same as avahi, PA, CK and PK is going to end up in pretty much every
distribution. Lennart doesn't care about the unix way, so systemd won't
be unixey. He also doesn't care about simplicity, so it won't be simple.
I'm not sure he care more about the Desktop (or 'DAU'-top as I like to
call what I have in mind) or servers, but he cares about inventing the
next big thing, which needs to have big impact on everyone. So by
definition systemd or anything else he writes can't just be a neat
program that some users find handy, it needs to be everywhere.

Now I know what avahi and PA does, and I don't have a user for either,
yet they are there. I don't have the slightest idea what CK and PK does,
they don't have any tangible benefit for me, yet they are there.
I'm not sure whether systemd will fall into the former or later
category, but I'd be really surprised if it had any real benefit for me
Yet I'm sure to have it on my machine within a year or so.

Philipp