Am Fri, 21 Jan 2011 09:03:23 +0800 schrieb Ng Oon-Ee <ngoonee@xxxxxxxxx>: > 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
