SoylentNews is people
SoylentNews
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: 1) by Mr Dave on Wednesday February 26 2014, @09:19PM
My main problems with systemd are not technical.
1. It is LGPL. So there is no need to redistribute fixes. This is a RedHat sponsored project. The systemd developers do not at the moment seem to publish backport fixes just update fixes. So if RedHat (the company) for RedHat (the product) decide to backport fixes to a particular release, as they normally do, they are not under any obligation to publish source code of these fixes giving them a clear advantage and making Ubuntu server, Oracle Unbreakable, Scientific et al do all that rework.
2. All the daemons are bundled and tightly integrated. So if you choose a window display manager that requires the systemd-logind component your entire init system choice is now overridden. There is no plan to break up functionality into seperate packages that are independent so you can pick and choose what you want. The amount of services it has subsumed are core, critical and required by many other systems. dbus, logind, init, cgroup management et al.
3. No "advanced mode". Everything must go through systemd. For example, if there is some novel thing you want to try with cgroups it must be done via systemd. The last I read on the systemd devel list was that systemd will go as far as hiding cgroups from users (by users I mean sysadmins) and presenting slices. No ability to create your own cgroup policy engine, you have to use an api/dbus to instruct systemd to act on your cgroups.
4. Stifling independent innovation. Assuming points 1 to 3 are valid, developers must work in the systemd ecosystem or face not being adopted. Even if new "hyper init system X" gets invented and has unheard of, unimaginable functionality it will have to be integrated into the systemd packages or not be used. People won't be able to try it, they won't be able to install it without installing huge core components of their OS. And once a project is part of the systemd project the independant philosophy that may have driven the innovation will be subsumed.
In my opinion, this is very much the policy attitude of gnome all over again. Choices on behalf of the user "for their own benefit". "We're doing it to help you" etc. Remember the whole gnome argument about opening a new file explorer window every time? You couldn't have the old behaviour anymore because the gnome developers decided it was inefficient and you didn't want it.
Following the idea of "do not attribute to malice what can be explained by ignorance", I expect these developers are genuinely trying to build a better system and fix problems they perceive as important.
The problem is that it is a viral solution. All it takes is your favourite application to require one tiny aspect of systemd and you have the whole thing, whether you want it or not.
Systemd developers do not seem to be interested in building a system that contains independent and replaceable modules. Which is fine, it is their idea and their product. It does however mean that it heavily restricts the choice of sysadmins, distribution maintainers and users.
**By modular I don't mean ~100 tiny binaries in a single package, which is the current systemd. I mean 20 packages each with a well contained bundle of functionality, that you can choose from as other alternatives become available.
(Score: 2) by RobotMonster on Thursday February 27 2014, @07:24AM
Coherent explanation; thank you!
(Score: 1) by Eunuchswear on Thursday February 27 2014, @02:56PM
There is nothing in the LGPL that says this.
If you distribute modified versions of LGPL code you must distribute the modifications, just like GPL.
Watch this Heartland Institute video [youtube.com]