Dev.SN ♥ developers
Sections
Dev.SN
from the Boot-him?-I-just-met-him! dept.
jbernardo writes:
"Having had several issues with systemd, and really not liking the philosophy behind it, I am looking into alternatives. I really prefer something that follows the Unix philosophy of using small, focused, and independent tools, with a clear interface. Unfortunately, my favourite distro, Arch Linux, is very much pro-systemd, and a discussion of alternatives is liable to get you banned for a month from their forums. There is an effort to support openrc, but it is still in its infancy and without much support.
So, what are the alternatives, besides Gentoo? Preferably binary... I'd rather have something like arch, with quick updates, cutting edge, but I've already used a lot in the past Mandrake, RedHat, SourceMage, Debian, Kubuntu, and so on, so the package format or the package management differences don't scare me."
[ED Note: I'm imagining FreeBSD sitting in the room with the all the Linux distros he mentioned being utterly ignored like Canada in Hetalia.]
(Score: 5, Informative) by mth on Wednesday February 26 2014, @11:38AM
I know a few reasons why it is unpopular, but a lot of those are not flaws of systemd itself.
It's new, so it has bugs and especially the service configuration files will have bugs. New sysvinit scripts also often have bugs (dealing poorly with exceptional situations), but those have been ironed out over the years. Switching to systemd introduces new bugs that will take time to iron out.
Systemd starts services in parallel, which is useful in reducing boot time, but is also a lot less predictable. If dependencies are either specified wrong or not well designed, the system might boot fine sometimes and fail to boot at other times.
It uses new syntax, both in configuration files and on the command line. For example, to access logging there are log filter options on a log DB instead of grep+less on plain text logs. While the new logging is a lot more powerful, it does mean learning a new syntax. And you're confronted with this while troubleshooting, which is not the ideal moment to appreciate a new design.
Systemd tries to do a lot of things: starting services, logging, cron-like scheduling, managing /dev. This is not the typical modular UNIX philosophy (do one thing and do it well). Maybe this is necessary to do these thing better, maybe it's lazyness of not wanting to design new interfaces between modules. I don't understand the details well enough to make that call, but in general I'm suspicious of projects' scopes that continue to grow.
Lennart Poettering made PulseAudio, which has a lot of enemies. And while I wouldn't consider myself an enemy of it, I did disable it on my desktop since it didn't provide any value for me and it did add to the audio latency.
I wasn't a fan of sysvint: there is a lot of boilerplate code that is copy-pasted, there are unnecessary differences between distros (whether the "status" subcommand works, for example) and flattening the dependecy graph to a linear startup sequence had to be done manually while that is something that computers excel at. But I've also ran into a several problems with systemd; the first time I tried it my PC wouldn't even boot at all. Time will tell whether it is an improvement in the long run.
In my opinion sysvinit is a dead end: it is good enough, but it isn't great and it won't be getting any better because the limits of the design have been reached. So I welcome new approaches; I'm just not sure yet whether systemd is the answer.