- Apr 5, 2016
That's why it is/should be called systemd/linux -- maybe sometime it will be systemd/uboot with boot-to-systemd ... wait ... why stop there? why not integrate a bootloader into systemd?for me the beauty of gnu/linux is about modularity, do one thing at a time and do it right.
Afaik (one of the) main reason(s) for this is to unify init "scripts", so a vendor can ship them (instead of the maintainer). The fact that systemd does more than that is the main reason why people hate it.Debian people had long conversations on systemd, so did Arch
I have my doubts that systemd is the right choice for OSes targeting more than just desktop:
a) dbus - makes sense on a desktop pc, but not on server or embedded,
b) "permission management" (logind, etc.) makes only sense on desktop, imho. Linux' permission system (groups) works nicely for other use-cases.
c) reduced freedom/increased bloat (you can't just use/take/mix the parts you need/want),
d) not suitable for *all* devices (e.g. IoT, WRT, ...),
e) last but not least: despite the fact that performance should be better (multi-core C vs. single-core bash), it wasn't for a single device for me.
*BUT* since Pyra should be a ready-to-use end-user desktop-like device, systemd may/does make sense for pyra's default OS.
It's just not good/ready/bug-free enough. I used it since "day one" when Ubuntu forced it on us. It was really bad back then - but often still better than plain alsa or oss.I found Pulse audio to be easier to work with once I came to the realization that it works more or less like a professional sound mixing board that has had half of it's capabilities removed.
Anyway, after that I still had my share of problems with it. Being on Arch (rolling, latest pulse), I can say that it's still full of bugs, at least when mixing sound cards or using network streaming. The main difference to professional sound is the magical buffering system. It will increase buffer size on the go, which introduces delays, which leads to Problem 1: mixing different sound cards may (or will?) increase the buffer to unlimitted sizes (e.g. +1 second delay per minute). I fixed this by using PortAudio against ALSA and just "replaying" a sink to a source and Problem 2: when streaming over network, the delay will randomly increase (bad connection?) but the logic to decrease the buffer size seems to be missing. I found no settings whatsoever to fix this. You have to go through ALSA, manage the buffering youself and hope that PA does not insert a magic buffer (TM) between your ALSA stream and your ALSA (hardware) sink.
Anyway, for most use cases pulse is better than ALSA. The idea is good, but it has too many bugs and limitations. Routing *everything* through userspace and mixing *everything* in software (no hardware acceleration) using self-growing buffers defies the idea of a good, low-delay sound card.