For a practical example of this, the XZ backdoor [1] affected liblzma which is (was?) a dependency for libsystemd, and some distributions patched OpenSSH to include libsystemd. As a result, the decision of putting journal file compression functionality directly into your init system means that a significant portion of all Linux systems out there came this close to being backdoored.
What about the seemingly Apple monoculture on HN?
What about the OpenBSD monoculture with OpenBSD!!!!!
You know what Linux needs? Another audio stack. Be sure it's backwards compatible with all the others, just like the last dozen were.
...yes? Obviously?
> What about the seemingly Apple monoculture on HN?
I don't think that exists, but if it did then I would object to it.
> What about the OpenBSD monoculture with OpenBSD!!!!!
What would that even mean? ...Actually, no, even if I sort of pretend that the concept makes sense it's not really a thing; OpenBSD constantly exports their software to be usable on other systems (ex. OpenSSH is an OpenBSD project) and imports general unix-like software to work on it. So no, there is no OpenBSD monoculture and wouldn't be even if it was that popular.
> You know what Linux needs? Another audio stack. Be sure it's backwards compatible with all the others, just like the last dozen were.
See, the real reason that this is funny is that PipeWire is a new audio system, is mostly superior to its predecessors, and largely is successful because it is backwards compatibile. So... Yes, actually, exactly what you said but unironically and without the slightest bit of sarcasm.
And pipewire is fine and good? Ask a sound engineer.
Just link in a huge library into security critical code, what could go wrong?!
using this library should be preferred in order to avoid code duplication
Then, you look at the reference code and see some reasonably nontrivial stuff that's a bit outside the maintainer's remit to add.
All of that is going to lead people in the direction of linking the library rather than reimplementing from scratch.
> In the past, I have been telling anyone who wanted to listen that if all you want is sd_notify() then don't bother linking to libsystemd, since the protocol is stable and should be considered the API, not our C wrapper around it. After all, the protocol is so trivial
I'm actually surprised that they added the note about code duplication after adding the standalone implementation specifically so people won't do that.
The takeway that sensible people go away with is that core critical infrastructure needs to be properly funded, and people need to stop harassing open source maintainers.
Idiots instead rant about "muh systemd" and use it to attack other maintainers.
I get why some people don't want to use systemd. That's fine.
I really don't understand why this group of people are so passionate about broadcasting this opinion to anyone within earshot. They don't like a piece of software, great! They've got different values! Use something else!
I personally do not use GNOME, nor am I running a non-systemd system at the moment. This is the first time I wrote a single word about systemd vs other inits on the internet, explicitly because it couldn't be more on-topic.
It's a common false compromise to say you now depend on a component but welcome alternative implementations. In reality, this quickly becomes treadmill for their maintainers, forced to adapt to its quirks so the dependent software even has a chance of working. You can read more about eudev as a more notable example of that dynamic. Projects like Wayland avoid it by having a committee of major implementations vote on proposed specs.
It's fine if they don't. Other users of GNOME will want to push back on API changes and deprecation. This is normal in software.
I think, if this is a surprise to anyone, they're not really paying attention. If you want GNOME you go along for the ride, and that's the message we've all gotten for the past 10 years. This same conversation keeps coming back up.
Just use KDE or something else if that's not an experience you, or other's, want. Personally, I despise GNOME, so problem solved for me. But, we have these conflicting takes where people will complain about fragmentation on Linux and then also complain about monocultures like GNOME. That's the experience GNOME very clearly wants to give, so if that's bad to you, then don't use it. And, on a distro level, maintainers can decide if they want to ship GNOME or if they want to make it the default.
Systemd was chosen by distros and users across different communities because it solves hard problems better than the others. We can debate about why that is, but the maintainers of Systemd aren't running smear campaigns against other open source projects. Often systemd is the subject of such ire.
They chose to solve hard problems and people adopted it. It's not anything more sinister. It's definitely not an "un-auditable mess". It's written in well formatted C with structure, good tooling, and an open community. You can disagree with the ideology but that's open source for you.
Additionally and away from my point, I believe that Systemd won our because they chose to embrace some complexity to solve really hard problems. Let's not pretend that a modern "init" does only system initialisation by calling shell scripts and then disappearing.
My completely oblique, binary logs disagree. It won because it solved problems companies with money needed solved. There is no indication that it succeeded on merit.
If it works for me but not for you, does it have more merit?
Usually I'm doing that from within htop, or btop++. Under systemd that is slow, the process-tree of FF takes several seconds to vanish.
That felt very wrong. I increased the update frequency of htop and btop++ to 200ms (usually they poll/actualize/redraw at 2 seconds only) to investigate.
Then I retested that with Runit/S6(6) on the same systems.
Magic! The process-tree is instantly gone! And if you only SigHup it, it instantly reappears. BAM! BAM! BAM!
This applies to all sorts of process-trees also, not only FF.
Compared to that systemd feels like a sloth.
Yes, Yes, I did that under several different distros, initially AntiX, recently "init diversity edition"(Debian derivative optimized for 'live-booting', running from RAM, in all sorts of 'Frugal' installs), some Arch-derivatives, sometimes 'riced' to the max, and default Debian, just to be sure.
Over several years. Initially on a Core-i7 640LM with only 8GB RAM, more recently on Core-i5 7500t, and Core-i7 7700t with 32GB RAM.
Verdict: systematically slo(w)thified.
The tools they have for their logs are pretty good, and its incredibly easy to disable, if you do, you will never notice a difference.
Helping engineers solve technical problems is not 'success'? Its only 'success' if open source nerds use it in their basement to run on an old sun workstation? What kind of dumb logic is that?
Why do you think Linux sees so much development?
After holding up well for a long time, absence of evidence becomes a good indicator for actual evidence of absence.
Also show me evidence of them "shopping around" code. I'll wait.
Just ignore them. Their validation is meaningless. Their ignorance is mostly meaningless, too, for reasons that feel mean to type out.
I have worked on DEs, I have committed to compositors. I know which side has more merit.
> I believe that systemd won out because they chose to embrace some complexity to solve really hard problems. Let's not pretend that a modern "init" does only system initialization by calling shell scripts and then disappearing.
I made a point to clarify I do not think SysV init scripts are a good solution for most systems Starting the services in a correct maximally parallel order is a constraint satisfaction problem, and many modern alternative init systems understand that. My personal favorite, dinit, explicitly uses the systemd model to great success, being faster than runit or OpenRC with less LoC. If someone finds that too opaque, they are free to use a more imperative init system without any obstacles.
> They chose to solve hard problems and people adopted it. It's not anything more sinister. It's definitely not an "un-auditable mess". It's written in well-formatted C with structure, good tooling, and an open community. You can disagree with the ideology but that's open source for you.
A piece of software being hard to understand doesn't imply it's because it's badly written. systemd is simply more complex as an "enterprise" piece of software. Think about it: RedHat's business is selling support contracts, so they won't risk losing a major contract by not implementing a feature their client needs, even if most won't use it. This both made it more robust and much wider in scope than other init systems, maintained mostly by hobbyist desktops.
For contrast, despite Canonical having killed Upstart in 2014, Google still feels confident enough in its security to deploy it across millions of ChromeOS devices, because it's a simple program that does one thing well, and thus no more risky than any other privileged binary.
> systemd was chosen by distros and users across different communities because it solves hard problems better than the others. We can debate about why that is, but the maintainers of Systemd aren't running smear campaigns against other open source projects. Often systemd is the subject of such ire.
I'm not ascribing any intent to systemd maintainers. But it's undeniable there exists a connection between GNOME, Freedesktop, and systemd, namely that each receive support from RedHat and share the most active RedHat contributors. When systemd releases a new feature, GNOME very soon integrates it, which FreeDesktop then uses as a justification for their new specification, which other desktops soon follow. This often lead us to fast-tracking adoption of genuinely good standards, but there is the confounding factor of funding to their general merit.
Where are you getting this from? I do not see it at all. The parent comment just says that it is an emergent compromise they don't think is a good one. That the code cannot be audited is also not necessarily a quality issue, either. It is just impossible to feasibly audit over 10 million lines of C. (this criticism applies equally to the kernel, although I doubt anyone would claim the kernel is less audited than systemd)
> Let's not pretend that a modern "init" does only system initialisation by calling shell scripts and then disappearing.
Nobody is pretending this. the comment you are replying to literally says "I don't think it represents the current state of the community".
I have been using Linux on many desktops, laptops, servers, including on my primary workstations, for the last 30 years. I have also managed Linux on the computers of other people who have successfully used Linux for many years, despite the fact that they did not know what "Linux" is.
During all these years, both at home and at various companies, I have never encountered any of those problems for which systemd is supposedly required.
Using systemd appears to be a matter of preference, not of necessity. However I have never seen any Linux users who could explain their preference for systemd.
Systemd is ubiquitous now because it has been chosen by the maintainers of most major Linux distributions, not because it has been chosen by any end-users. Most maintainers also have not chosen it for any personal reasons, but because the maintenance of the distribution would have become a PITA without systemd, due to the dependencies introduced by a few important packages, like GNOME, which were thought to be indispensable in any distribution.
Perhaps systemd has some advantages that I am not aware of, but with certainty the proponents of systemd suck at selling it, because they have never been able to describe those advantages. Instead of trying to convince others that systemd is technically superior, the dependencies upon systemd have been imposed by force upon all Linux users by a relatively small number of developers.
By coincidence, just these days I have begun to study elogind, which is mentioned in TFA and which is a workaround for not having a complete systemd.
Until a couple of weeks ago, I had succeeded to not use even elogind, but the last version of the Xorg server has acquired a hard dependency on systemd, so after upgrading it now I have to run this additional useless elogind daemon, to simulate the presence of systemd. I have begun to study elogind because launching it early during boot seems to have introduced some bugs in the behavior of the Linux virtual consoles. Even if I normally do not use those, I have been intrigued so I have started to investigate what elogind really does.
After these news about GNOME, I think that I will be forced to do a much more thorough study of elogind and systemd than I would have ever wanted to do, in order to write some replacements for satisfying any systemd dependencies in the applications that I am interested. I do not use GNOME, but there are useful applications that expect some GNOME services, and those may become now more dependent of systemd.
I hate that I will have to do a lot of work without any obvious useful purpose, just to keep running the same programs that previously worked fine without systemd.
You don't need to reimplement logind or D-Bus, but you will need to patch your mechanisms of choice into Gnome itself. Gnome isn't planning on maintaining a second copy of common system services that exist on modern systems anymore (a copy that is based on a hack in the first place). The burden of maintenance now falls on whoever wants to provide their own alternative.
All the extra work you need to do to get alternative init systems working is work the Gnome team no longer needs to do.
no longer…
https://catfox.life/2024/09/05/porting-systemd-to-musl-libc-...
People want to understand their software as well as it's practically possible. It's not an uncommon preference; worse-is-better was quite successful for a reason. As systemd stands, it's an unauditable mess of tightly-coupled components built to handle any conceivable need. These features create new attack vectors: for instance, systemd-machined credential passing system, which can inject arbitrary files such as keys and configs into the guest, also runs on bare metal. And some are just running a musl system that can't even use systemd.
Some might look at the old SysV init scripts through rose-tinted glasses, but I don't think it represents the current state of the community. We have the modern OpenRC with parallel startup, dependency-based initialization, supervision, network management, and cgroups; dinit, which tries to imitate the 80% of systemd features that people use with 20% of its footprint; s6 with its supervision trees; runit that just works; and GNU Shepherd, which gives you an entire Scheme interpreter to configure your system.
Monocultures are bad because they eliminate competitive pressure for good design and create single points of failure that affect everyone. systemd was an excellent addition to the ecosystem in its day, but has become uncomfortably sticky: you can't just choose to replace systemd; you'll need to reimplement udevd, logind, D-Bus activation interfaces, and now userdb, all of which have their own subtle quirks you'll need to replicate. Look to the state of mdev or elogind and you'll see why it's not a sustainable compromise.