SoylentNews is people
SoylentNews
Controversy is nothing new when it comes to systemd. Many people find this new Linux init system to be inherently flawed in most ways, yet it is still gaining traction with major distros like Arch Linux, openSUSE, Fedora, and soon both Ubuntu and Debian GNU/Linux. The adoption of systemd for Debian 8 "Jessie" has been particularly fraught with strife and animosity.
Some have described the systemd adoption process as having been a "coup", while others are vowing to stick with Debian 7 as long as possible before moving to another distro. Others are so upset by what they see as a complete betrayal of the Debian and open source communities that there is serious discussion about forking Debian. Regardless of one's stance toward systemd, it cannot be argued that it has become one of the most divisive and disruptive changes in the long history of the Debian project, threatening to destroy both the project and the community that has built up around it.
(Score: 5, Interesting) by zocalo on Sunday September 28 2014, @03:09PM
SystemD is *not* monolithic, at least not any more. It's actually quite modular, consisting of a large number of separate binaries that can be include or excluded at build time. The problem here is that it is very easy for distros that have decided to adopt SystemD's init replacement to adopt everything else that does with it - it does make life a lot easier for them, so users get SystemD versions of Cron, Syslog and all the others on the growing list by default, whether they want them or not. Depending on the daemon it may be possible for the user the disable and replace the SystemD version, or they may need to run both in parallel - the amount of effort to do this however can be quite cumbersome, in a way no different from how Microsoft embeds IE into Windows (albeit at a much lower level, at least for now) - and that quite rightly provoked a lot of protests from those that didn't want it on their system in the first place.
SystemD is *not* responsible for the applications that rely on the services it provides; e.g. Gnome. That is a decision that you need to lay with the relevant developers of the tools that have SystemD as a dependency, although since many of those development teams are heavily influenced by Red Hat you may feel free to make allegations of collusion - I certainly suspect this may have occured. SystemD itself actually has very few pre-requisites; the Linux kernel and a few other essential bits and pieces that will almost certainly need to be installed anyway, but that's about it.
When it works (which is most of the time, to be fair), then for many users it does generally make life easier, and few users will need to do more than use SystemD to start/stop/disable daemons anyway. The original init, while it gets the job done, *is* long in the tooth. Debugging it can be a nightmare, despite the claims made by the team, and while the code might be somewhat modular many of the interprocess communications are still hard, if not impossible, to get a handle on depending on what state the system is in - especially given the braindead decision to adopt a binary logfile format. The "NOTABUG" / "WONTFIX" attitude of the devs is also well documented - unlike the software itself, although the documentation is still better than many other OSS projects.
Personally though, I've made my view clear in several discussion on the topic here and on the other site: I'd still like to see SystemD replaced with something else, or at least take the current modularity to the next step, making it much easier for users to disable and/or replace services that it provides. Specifically, I'd like to see the various daemons SystemD is replacing in their own packages so I can, for instance, choose to install systemd-{daemon}, a third party daemon of my choice, neither, or both, depending on my personal preference and build requirements. That's an issue for the distros though, not the SystemD team, although they could certainly help make this task a lot easier for packagers to undertake. I'd also say that they need to make troubleshooting it when you are in recovery mode following a major crash or system compromise much easier, provide an option for text only logfiles, and addressing several other outstanding issues that people clearly have with it. SystemD is clearly dividing the Linux community, and while some might jump ship to BSD, the main beneficiary of this infighting is going to be Microsoft - and none of us want that.
[1] We started looking elsewhere because we didn't like RHEL6 in general. We run a mix of desktops and servers, but mostly headless servers. The prevalence of SystemD prompted us to include BSDs in our candidates along with other Linux distros and the cleaner installs, less complex dependencies, and generally much faster performance we saw with BSD made us make the leap.
UNIX? They're not even circumcised! Savages!
(Score: 1, Interesting) by Anonymous Coward on Sunday September 28 2014, @03:54PM
Some of the complaints could be expressed better, interesting that you dissected them when you are well aware of the real issues.
Technically correct but as you point out, effectively not since the default for everything will be systemd-daemons and replacing them is cumbersome. I fear the word monolithic is being banded about here when the real complaint is that linux distros may become a monoculture.
Systemd *is* responsible for consuming udev and dbus. The developers are responsible for making underhand political decisions and attempting to pass them off as technical concerns -- as if we're all morons.
(Score: 4, Insightful) by tonyPick on Sunday September 28 2014, @04:37PM
SystemD is *not* monolithic, at least not any more. It's actually quite modular, consisting of a large number of separate binaries that can be include or excluded at build time.
Great. So you can take a machine that doesn't have systemd and is running a 2.6 series kernel, and just run the standalone journald binary on it? Or put it on a BSD box? (Answer: not really)
The thing that makes it monolithic is the fact that all the pieces of it are interdependent. Putting it into separate binaries makes it Modular, but it can still be a Monolithic architecture. Monolithic and Modular are not antonyms.
Or, to quote wikipedia, a monolithic architecture is one in which the functionally distinct aspects:
are not architecturally separate components but are all interwoven
And given the systemd authors stance that you can't take out some key pieces like logind and reimplement it separately (See http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/ [freedesktop.org]), that's a pretty good description of systemd to me.
(Score: 2) by zocalo on Sunday September 28 2014, @05:13PM
Ultimately, I think SystemD is here to stay, and will likely end up as much a part of Linux as the kernel and GLibC. Too many distros have too much invested in it now to change direction, and it would be a rare distro that will be prepared to completely drop all of the growing numbers of packages that only work if SystemD is present. We can either keep bitching about it (which appears to be futile), produce a workable alternative that is appealing enough to encourage distros to switch (which will probably take too long given the growing list of dependencies upon SystemD that will break), or try and convince the SystemD team and distro packagers to address the concerns being raised by the community (which currently appears to be falling on deaf ears). It's a Hobson's Choice, but I think the last one is probably the best option - other than switching to BSD, anyway.
UNIX? They're not even circumcised! Savages!