On Fri, Jan 21, 2011 at 3:07 AM, Heiko Baums <lists@baums-on-web.de> wrote:
1. A possible loss of control over my system due to many unnecessary automations and dynamizations.
I agree that the user should be in control of his system. If you find any examples of loss of control, please file bug reports or send an email, I'd be happy to follow up on it.
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.
Unless you actively enable automounting (which is really cool btw) it will not be used.
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.
There are work underway to deal with this (and in my experience it is already dealt with by the simple readahead implementation that comes with systemd), again bug reports are welcome (bootchart2 is a great tool for this).
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.
You have the choice in systemd between starting the service as soon as possible or (if the service supports it) as late as possible. The former would be used for services that are used most of the time, the latter for services that are seldom used.
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.
This functionality would be opt-in (it is not there yet for the case of apache), and if the attack vector you outline is valid I can assure you that this would not be allowed upstream.
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.
This I doubt is a real issue. The memory footprint is tiny, and most of the time it will be swapped out. If you have some numbers showing me wrong, this would be a bug I'd be happy to look into.
7. I'm using LVM and harddisk encryption. So systemd seems not to work for me anyway.
This should work. However, we desperately need testers for this (as the LVM support is not upstream, but written by yours truly, based on the Arch initscripts).
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.
There is quite a lot more to controlling daemons than this. I'd recommend having a look at the blog entries linked to in the beginning of this thread.
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.
If you want to try out systemd and have any problems/questions let me know. (If you prefer to stick with sysvinit, that's fine too ;-) ). Cheers, Tom