Linux

You're missing a TON of history here. Like udev being a dependency to all those projects AND systemd, which led to systemd adding it to their project. Really it could be said that udev is the critical component here.

As you mentioned networkmanager, you clearly know that many popular distros use that rather than systemd-networkd.

Grub2 is by far the most popular boot loader, so far ahead that it's not even worth considering others. Grub has had several major issues, every distro uses it, why not pick on grub as the risk?

Did you have these same concerns about sysvinit? About the various distro network scripts? What about libc? Good god if there's a problem with libc we're all in deep trouble.

Yes, code has bugs. But New code has new bugs (ironically an argument previously used against systemd). Whatever you replace these components with will be just as likely to have a critical vulnerability, but far fewer maintainers and resources to fix it. Systemd has simplified and improved features of so many parts of Linux that it's funny to see how vehemently people argued against it. Feel free to disable any parts you don't need, but I think you're missing 20 years of painful history that led us here.

Systemd-init, the core part of systemd, offersa wide range of features surpassing other init systems. More features lead to more bugs and security vulnerabilities.

This is a bad take. Many of systemd's features improve security significantly. And having all that code in one cohesive place can't possibly be inherently less secure than the cornucopia of init scripts we used to use.

Many maintainers use the entire systemd suite, even if they don’t require all its components.

This is the level of systemd-critic today?

Most of what you said applies to the Linux kernel too. It's good to have other options, but being popular does not mean something is bad.

The link lists 78 CVEs of varying severity levels opened over a period of 11 years. Many of them are patched. (I don't know how to easily check how many are patched. The NIST listings provide issue tracker links and severity levels, and the handful of CVEs I looked at had fixes released.) I'm not convinced this is evidence that systemd is unacceptably insecure.

I get that it's frustrating that systemd has such a broad scope, and that it's not portable. But these are trade-offs. In exchange we get power that we wouldn't get otherwise. For example tying device management and scheduled tasks into systemd lets us use the same declarative dependency management in those domains as in the init system. The system is able to bring up services only when needed, boot faster, use fewer resources. The non-portability allows use of, for example, Linux cgroups to cleanly shut down forked processes. Even if we were using an alternative like Upstart I'm gonna guess we would end up relying on cgroups.

Red Hat's role is certainly something to keep an eye on. But systemd is open source, and it can be forked if necessary.

I disagree with a lot of this. Some of it is assumption, some is just wrong.

1. Why is that a bad thing? They should try to use the full thing for standardisation purposes
2. So don't add features to anything? It also has features which improve security.. Splitting all these features up into different projects just means a similar number of bugs spread over many projects, and worse integration
3. So developers need to now also think about compilation speed, for people who don't really gain anything by compiling everything themselves anyway? Maybe you can assist by assisting with GCC and other compilers then?
4. Why are we catering for FreeBSD or OpenBSD?
   • They have negligible market share (even worse so if you ignore TrueNAS).
   • They can port SystemD to their own platforms if they want and improve their compatibility layers with Linux.
   • Theo de Raadt from OpenBSD is a total d*** I respect the work he's done, but who would want to work with him.
   • There is nothing stopping you from porting SystemD stuff to FreeBSD and enhancing their compatibility layers
5. You're making assumptions. RHEL likely won't do that lol, and if they did, other distros would fork and take over (its LGPL).

if its easy to find a "serious vulnerability", show us how its done. In fact, show us more than one.. There's literally nothing stopping from assisting with auditing Systemd code either.. Or forking it.

In fact, I find it literally insane the amount of attention a small number of people are focusing on attacking systemd. Literally, there are so many targets in Linux that are lacking, or not ideal.. But, you guys are focusing so much attention on this. It's like all the complainers about Pulseaudio, who are likely the main people complaining about RHEL now (who released Pipewire, which fixes the last major audio issue in Linux because nobody in the community did something similar).

I use systemd-nuclear-reactor in my system, systemd-spoon and systemd-fork weren't good enough to replace just using my hands though.

security? I don't think systemd vulnerabilities are that critical, a vulnerability in systemd will provide a way to privesc at most, which means that the attacker must have initial access to exploit it. And considering that most linux servers are using containerized systems, a direct systemd exploit is not possible in most cases

also, more people using systemd means more devs working on systemd, so more security issues will be found and patched

Personally my only gripe with systemd is that the systemctl and journalctl commands are cryptic and unintuitive. Every time I have to use one (which thankfully isn't often), I have to spend 5 minutes reading man pages to remind myself whether -u is "user" or "unit", what the difference is between a "unit" and a "service", etc.

I imagine this is what non-developers feel like when they're forced to use git—having a whole pile of unfamiliar vocabulary and syntax thrown in your face when you're just trying to do one simple thing.

Just waiting for systemd-kernel to replace the "old archaic" Linux kernel. j/k j/k j/k don't block me yet!

I used to be very much against systemd and I still don't like the interdependencies to everything (as highlighted in the OP), but at the same time - this is a decade old discussion and everything that was worth saying was already said back then and nothing has really changed much.

Most popular distros adopted systemd and that's that and we've since then kept piling in more eggs to that same basket. There are options (distros) available if you don't like it, but most of the "Linux community" chose systemd and that's where we've been for a decade.

I don't really have strong opinions these days - systemd boots my computer and most days I don't need to know about it. I still have to check the manpages for usage because the flags are just archaic as fuck, but that's more of a "me problem" than problem with the software.

I am worried about IBM though. The steps RedHat has been taking under their new mothership have been worrying and I have a feeling we "parasites" (as the RH CEO called us) might have just seen the beginning of this new strategy.

This isn't systemd specific fear, but while the "well we just fork it" is a nice thought, I'm not sure were "we" have the resources and money to continue maintaining it.

Anyway, that's just idle speculation from my part. Systemd discussions tend to be as constructive as "vi vs. emacs". Sides have been picked. Time has passed.

It is what it is.

I'm actually leaving systemd completely, I plan on using libudev-zero and it seems pretty viable to me

ok boomer

Technically, it isn't true that there is no alternative whatsoever to udev/eudev. It's possible to build a system around Busybox's mdev, although it's nontrivial enough that most people aren't going to want to try to do that for an interactive desktop.

Sure its complexity and feature creep lead to endless bugs, dependency hell, and limited system configuration options, but such is the price of progress. The initial goal of saving multiple seconds of boot time on older hardware compared to the slowest of the older init systems has been finally achieved. Imagine if startup took 5 seconds instead of 4. Then where would we be? Probably still waiting for the Year of the Linux Desktop in 2024.