4 ms·
Every time I read something complaining about systemd from a centralization/reducing-choices POV, I mentally replace the word "systemd" with "glibc" and check t
by zbentley 9y ago
Every time I read something complaining about systemd from a centralization/reducing-choices POV, I mentally replace the word "systemd" with "glibc" and check to see if the argument still holds water.
Mind you, there are plenty of other complaints (stability, back-compatibility, etc.) that are useful/valid regarding this software, but the above litmus serves to eliminate rather a lot of FUD and hand-wringing in my experience.
- benchaney 9y agoWhat criticisms have you eliminated using this strategy? glibc does not do the things that people hate about systemd.
- zbentley 9y agoIt filters out: people who just want to complain about centralization; people who are annoyed about change and trying to rationalize it without trying or learning the new tool; and people who irrationally feel like they are no longer in control. Paradoxically, this improves the signal of discussions about systemd's flaws, and there are plenty. With the obviously irrational/haven't-used-it/axe-to-grind stuff filtered out, it's much easier to learn about real features, problems, fixes, benefits, and drawbacks of any project, systemd included.
- greenhouse_gas 9y ago>Every time I read something complaining about systemd from a centralization/reducing-choices POV, I mentally replace the word "systemd" with "glibc" and check to see if the argument still holds water. Actually, I replace systemd with *BSD. You know, the OS which has blessed core packages which are not replaceable?
- petre 9y agoActually the BSDs with their non-replaceable core packages are a sane alternative to Linux w/ systemd.
- dijit 9y agoThe difference is that in the BSDs (especially OpenBSD) a lot of care is taken to be configurable. Consistent. Clear and transparent. OpenBSD has the most extensive suite of tools built specifically for systems administrators that exists in a base system. SystemD has opaque behaviour and binary interfaces. It's the antithesis of the BSD model. Despite BSDs being quite coupled groupings of software. Anecdotally we're attempting to move to BSDs instead of upgrading to RHEL7 due to SystemD.
- justinclift 9y agoOne gotcha (for me) with BSD is that I'm developing on Golang. It doesn't really debug well on anything other than Linux... so had to move to that for development. ... and for deployment, the Golang debugger doesn't even run on BSD at this point. So, going to have to setup new Linux (likely CentOS 6 - no systemd - or 7) boxes soon now that we're getting closer to first initial real world deployment for the project I'm on.
- greenhouse_gas 9y agoI'm not comparing code quality. I never looked at either and therefore can't comment on that. It's just the "UNIX is supposed to be decoupled" line that gets repeated every time systemd comes up that BSD (which, ironically, those people want to switch to) disproves.
- JdeBP 9y agoAs the author of a toolset that can replace parts of Base such as init, van Mewburn rc, and service with its own system, service, terminal, and logging management, I point out that "not replaceable" is not exactly true. * http://jdebp.eu./Softwares/nosh/ http://jdebp.eu./Softwares/nosh/
- agwa 9y agoglibc's actually pretty bad, and many people prefer alternatives such as musl. Ideally, it would be easier to use an alternative libc. Wherever possible we should encourage modularization and standards-compliance, not lock-in, so that the best implementation can rise to the top. So yes, the same centralization/reducing-choices arguments apply to glibc.
- zbentley 9y agoThose are good points. Systemd is somewhat modular/swappable for other init (et cetera) systems, but the practice of actually swapping it out as a dependency of a given package is roughly as tricky as switching out glibc for something else. You have to crack open the package and make it not depend on/automatically install the init system (or libc) you don't want, tell it to install one that you do want, and then thoroughly test to make sure that the old version wasn't depending on a piece of behavior specific to the init (or libc) that you switched out. Or you could build and package the software yourself, with similar hassles to address. The problem with standards compliance is that, once something becomes ubiquitous enough, its compliance begins to "drift", and replacement parts get harder to find. Is it tricky to swap out the init component of systemd with something else? Not terribly. Is it tricky to swap out its dbus messaging setup with something equivalent that can still be used by unaltered software that was previously talking via the systemd setup? Yes, a bit. And so on. For equivalent hassles regarding libcs, check out some of the FOSDEM talks from the musl folks, or the alpine folks, where they talked about the difficulties in porting software that had come to depend on the quirks of glibc. Or just, you know, google "quirks mode" and get simultaneously nostalgic and sad :)
- JdeBP 9y agoThere is no need for nostalgia. There is a contemporary quirks mode to be found at http://jdebp.eu./Softwares/nosh/guide/convert-systemd-units.html http://jdebp.eu./Softwares/nosh/guide/convert-systemd-units.... . (-:
- bitwize 9y agoOddly enough, systemd depends on glibc, which is why Void Linux is the only Linux distro that I know of to switch away from systemd (to runit): they wanted to provide a musl option. I am running Void with musl on a Raspberry Pi 2. I love it.