So, how are any of you systemd apologists defending this little gem?
https://twitter.com/MartinCracauer/status/109470986305220199...
Linux distros without systemd
291–300 of 449 posts
Re: Linux distros without systemd
#292Earlier quoted context omitted.
Most of the problem I have it is with the imperialistic culture that came with it and with the serious security bugs that they keep sweeping under the rug. It is easier to configure and is convenient to have one holistic system in a lot of ways, but... They pushed for Gnome to have a hard dependency on it so that everyone would be _forced_ to use it instead of just letting it be accepted by merits. They have a track…
> They have a track record of labeling serious bugs as non-issues, ignoring them, or just not filing them as CVEs. Serious issues keep coming up. Additionally, this is not likely to stop, since they took an init system that was (mostly) written in a memory-safe language (bash) and rewrote it in a memory-unsafe language (C++), thus enabling a whole class of systemic security issues that will keep popping up in the fut…
> they took an init system that was (mostly) written in a memory-safe language (bash) and rewrote it in a memory-unsafe language (C++)
While Bash is memory safe, it is also very error prone to write and the potential of shooting yourself in the foot with it is rather big, especially with bigger scripts and considering these are executed mostly with root privileges, bash is not an ideal choice either.
I'd prefer if systemd was a Rust project for sure, but they went with C, presumably to remain consistent with the kernel, GNOME and most lower-level Linux system software, (also, Rust was pre-1.0 at the time).
Re: Linux distros without systemd
#293Earlier quoted context omitted.
Why is it another open source developer's obligation to satisfy your design desires? Are you paying them? If not, put your time where you aren't putting your money, become the purveyor of diversity, and submit a patch. Fork, if necessary and it matters to you that much--it's your right to do so.
Full disclosure: I'm a systemd skeptic. The problem is basically that Linux used to be about choice (choose your distro! choose your DE! choose your shell! choose your browser!) but now that it's become big business, large corporations like Red Hat (developer of systemd) have transformed the evolution of Linux from a bottom-up consensus system to a top-down "we develop all the stuff you use and now it all uses our st…
I am not a systemd skeptic, but I'm also not somebody who cares that much. (Which might seem at odds with this thread, but I'm in a lot of meetings today. ;) I use it and it gets out of my way. For me, it's fine.
I'm not qualified to judge the quality of the code in systemd directly; I've browsed it a little but I am a middling C++ programmer and while it hasn't stood out to me as smelly I would defer to more knowledgeable heads. I get the drive for very rugged underpinnings, and I'm on board with that; in things that aren't C++ I frequently am the one with the scalpels making criticisms similar to yours, so that totally resonates with me. I am not, however, convinced that any of the alternatives that currently exist are materially better, so I kinda shrug a bit? Further, it seems to me that the generally modular nature of systemd (regardless of how coupled one believes those separate modules to be) suggests that a determined programmer could probably build a drop-in replacement--Rust? Where's my Rust Evangelization Strike Force?--that plays nicely with it and grows to replace poor and soft design.
The social aspect you bring up is, to me, the most compelling argument against systemd (because monocultures aren't great in general, etc.--I think most people agree on that). Thing is, though, I think that that bottom-up consensus model was doomed from the start. I don't think it was ever going to be tenable as soon as there's any money in it. Red Hat wants consistency, their stuff is going to have consistency, you can use it or go off-roading.
I don't think there's a great solution aside from "build your own ecosystem and don't let it get capitalism.txt'd to death." Which is a deeply unsatisfying and impractical answer. And to be clear, people who feel strongly about it should do that. I'm not being snarky when I say that. I'm a pragmatist--if it's better, I'll use it, too, and submit patches if needed and when I'm capable. ;)
Re: Linux distros without systemd
#294See also the search filter on Distrowatch for non-systemd distros: https://distrowatch.com/search.php?defaultinit=Not+systemd&s...
Re: Linux distros without systemd
#295Earlier quoted context omitted.
Given the timeframe, something like OCaml would likely have been a better option.
Ocaml parallelism/concurrency story was not that good - but Haskell has just got its fancy new epoll based I/O manager (100000+ lightweight threads) around that time, with the 7.0.1 release (16 November 2010) They could have even take inspiration, imagine: typed, functional, monadic init files - "systemd: avoid success at all costs" :)
> Ocaml parallelism/concurrency story was not that good
I wouldn't expect CPU-bound multithreading to be much of a concern in an init/rc system. And resource thriftiness and predictability would likely be a bigger concern.
Re: Linux distros without systemd
#296Earlier quoted context omitted.
This is always the case with any new software. Things may get a bit worse before they get better. Honestly Systemd addresses the complexities of a modern system in the simplest fashion but no simpler, and that is the key. It is in the same spirit as launchd on macOS. It works well overall and end up being more portable and consistent in the long run. Hatred for it seems to come mostly out of dogma, something to be av…
launchd doesn't break nohup. It doesn't have any opinions about processes started from shells. systemd does, which is completely inappropriate scope creep.
I agree with the systemd developers on this one. It's weird that processes started by users when their logged in by don't end when they log out unless they voluntarily terminate when sent a signal.
And nohup was always a hack. Now that we actually have a functioning user-level service manager keeping processes alive by throwing them at PID 1 to parent needs to go away. I really hope that systemd eventually uses subreapers to keep all user processes under the session leader.
I feel like it's weird to talk about scope creep when logind is pretty much the first system to define what a session even means on a Linux system.
Re: Linux distros without systemd
#297I don't like it when my process init and logging system also tries to manage my volume mounts. If I unmount a device, I don't want systemd going behind my back and remounting it for me. It's non standard behavior changes like this that drive systemd hate.
From what I observe, the hate from systemd USERS towards non-systemd advocates is higher than the hate of non-systemd advocates to systemd.
I've never seen systemd users make t-shirts against the others, send death threats, hijack any conversation where systemd might come up to advocate their side… non-systemd advocates on the other hand…
Re: Linux distros without systemd
#298Earlier quoted context omitted.
I agree with your logical consistency, but I'm curious: is D-Bus sufficiently specified that one could write an alternative to it? That is, is it a hard dependency or is it itself an interface? I'm not nearly sufficiently experienced with desktop Linux application development to know. ;)
I'm not a huge fan, but dbus at least runs on FreeBSD and others.
FreeBSD developers are actually looking at something like systemd themselves. The fact that systemd itself doesn't run on it is just the consequence of POSIX being inadequate for its implementation, since it relies on a bunch of Linux specific features, like cgroups etc.
I am personally in the camp that doesn't mind that, Linux users should get the best possible software given their system capabilities, not the lowest common denominator one just for the sake of it. (Free)BSD developers are also not looking to make sure their stuff works with Linux, which I think it's a valid approach.
GNOME itself does exist on the BSDs, by the way knocking down the argument of systemd being a hard dependency of GNOME along the way.
Re: Linux distros without systemd
#299Earlier quoted context omitted.
It's not the init replacement part that bugs me. It's the expansion into audio, kernel logging, resolvers, containers, and so forth that is the issue. It's a monolith of sorts that breaks the loosely coupled toolbox concept of Unix.
Systemd is a bunch of loosely coupled tools, though; it's not a monolith at all. PulseAudio was written by Lennart but isn't part of systemd. You don't have to use systemd's resolver. systemd-nspawn is a completely separate process and isn't required for systemd as a whole. It's worth watching Benno Rice (a BSD developer, actually) discuss systemd and some of the misconceptions, some of which you're expressing, there…
There are lots of variations on the UNIX philosophy [1], but two core points are to:
1. Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features".
2. Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input.
systemd has binary format data all over the place, and it is quite difficult to separate out an individual component and have it work properly on its own. Not to mention trying to replace a subcomponent with something else.
systemd is, in general, a tightly coupled system with lots of interdependencies. It is, in many respects, the antithesis of the UNIX design philosophy.
Hell, even modern Software Engineering practices still talk about decreasing coupling and increasing cohesion.
Re: Linux distros without systemd
#300I mainly use FreeBSD, but I have a number of Linux VMs that I use where appropriate. The big thing, for me, that systemd brings to the table is consistency. Managing services on CentOS is the same as managing them on Debian which is the same as managing them on OpenSUSE. This makes it a lot easier to deal with the various different Linuxes. Also, it seems to make writing a service a lot easier. Instead of the service…
> Managing services on CentOS is the same as managing them on Debian which is the same as managing them on OpenSUSE. It's not really the same, some systemd-based distros diverge a lot and anything non-systemd much more so, including FreeBSD. Even something as basic as network configuration could be completely different on systemd distros, like Ubuntu with its netplan weirdness and Archlinux going into the opposite di…
> But still, if you want any sanity in your deployment across different distros
This might be true for your in-house app but if you want sanity in packaging your service for inclusion in various distros you include a .service file.