Systemd is the most common software suite for managing Linux-based systems. It includes init, rc, device manager, temporary files manger, network name resolution service, cron alternative, machine manager, spoon, fork, nuclear reactor, remote control of the world, etc.

Let’s see what problems could not be solved even after 14 years of development.

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

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

  3. Source-based distributions may experience increased compilation time due to systemd.

  4. Systemd is exclusive to Linux and cannot be used on other Unix-like operating systems such as FreeBSD or OpenBSD. This limitation means that software dependent on systemd, like GNOME, won’t be compatible with these non-Linux systems.

  5. The project is primarily led by Red Hat. There is a possibility of Red Hat stopping systemd development as a completely FOSS software and making it an exclusive feature of RHEL. Red Hat is a commercial company that will prioritize profit within legal boundaries. SystemD is still a tool used by Red Hat to increase its influence on GNU/Linux. The interdependence between SystemD and udev nowadays highlights the significance for Red Hat to encourage widespread adoption of their suite, rather than utilizing components developed by multiple teams of developers.

But you will still end up using SystemD, or at least some of its components. This is because opentmpfiles (the only alternative to systemd-tmpfiles) has been abandoned. Udev/Eudev has no alternatives and is a dependency for NetworkManager, Gnome, KDE, and many others. Gnome cannot function without logind/elogind. Systemd-boot is the default bootloader for certain Linux distributions (such as NixOS, for example). And it won’t get better from here. The further we go, the more dependent we will become on SystemD. And this needs to be somehow stopped. Because the more widely used a software is, the more people will search for vulnerabilities in it. And with the amount of code in SystemD, finding a serious vulnerability is not that difficult.

  • Dr. Dabbles@lemmy.worldEnglish
    39·
    1 year ago

    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.

    • dinckel@lemmy.world
      211·
      1 year ago

      Their entire post history is either trash-talking of popular software, or careful omission of important details, which also just feeds into the same kind of behavior. Don’t waste your time, trying to argue with someone who’s purposefully flaming the community

  • JWBananas@startrek.websiteEnglish
    39·
    1 year ago

    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.

      • Auzy@beehaw.org
        101·
        1 year ago

        That’s an understatement.

        If OP had their way, Gnome would just be a terminal window with applications listed, because it compiles quickly, and no features is better security You’d need to manually install the features you need.

        I used to use Gentoo and roll my own kernel. Total waste of time

    • kbal@fedia.io
      61·
      1 year ago

      Yeah I’m not really convinced that systemd is less secure than anything else would be in actual practice. But if you want to address the theory that its much-maligned style of software development methodology leads to worse outcomes, the usual high-level argument would be that well-defined interfaces between replaceable components is what leads to a more robust system. For example having several available alterternatives for logging, such as syslog, syslog-ng, rsyslog, et cetera as opposed to everyone being pushed into additionally having systemd-journald running because the other systemd components just assume that it will be there.

      There are certainly costs to the systemd style, it’s just a question of whether the benefits are worth it for you.

    • MonkderZweite@feddit.ch
      11·
      1 year ago

      Many of systemd’s features improve security significantly.

      But not the issues of any integrated service suite running as PID 1.

  • mogoh@lemmy.ml
    271·
    1 year ago

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

    This is the level of systemd-critic today?

  • LinuxSBC@lemm.ee
    14·
    1 year ago

    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.

  • Auzy@beehaw.org
    11·
    1 year ago

    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).

    • Auzy@beehaw.org
      4·
      1 year ago

      Also, just in case you want some targets to work on:

      1. Mobile phone app integration with Android. Waydroid works, but has some fairly big deficiencies compared to the Windows / OSX Mobile app integration. I feel a lot more polish and integration is required (it would be awesome if you added integration into the standard app “stores” like Discover). But even stuff like the keyboard entry popup doesn’t work well.
      2. I’m sure there is lots of Wayland related stuff you can assist with
      3. Improved window tiling for KDE / Gnome
      4. Hit the various bounties pages and feature requests in Bug trackers for the main projects
      5. Assist with Auditing Systemd
      6. Hardware support
        • Assist with Asahi for Apple silicon to allow Apple users to use Linux instead. Like it or not, their computers are popular, and they might be a good ARM target for many “mainstream” users. Things like DP ALT Mode still aren’t working
        • Fix NUC 12 Enthusiast
        • Streamdeck needs to be better supported (and is even more limited in wayland)
        • And I’m sure there’s many other hardware targets too
      7. Improved Self Healing and recovery mechanisms for Linux. Windows actually does an awesome job with this, where if things break, it can auto-rollback
      8. Forks for Redhat projects. Feel free to fork all the major Redhat Projects if you are concerned about them closing the source code. I don’t think its fair for people to be dissing RHEL, if they’ve never touched the source code…
      9. Or finally, sponsorship or help donation drives to fund these projects. I’m willing to bet developers want to work on their projects full time, but unless you’re hired by a company like Redhat, it won’t happen. Firefox was incredibly effective at this

      And I’m sure there are lots of other targest too

  • hallettj@beehaw.orgEnglish
    10·
    1 year ago

    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.

  • EccTM@lemmy.mlEnglish
    7·
    1 year ago

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

  • Snarwin@kbin.social
    6·
    1 year ago

    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.

    • tslnox@reddthat.com
      21·
      1 year ago

      I’m a long time Gentoo user. No systemd ever. When my old computer started failing and my Gentoo started falling apart (mostly because I made multiple mistakes when trying out testing versions of Plasma 5 and also due to me not updating for a long time and then getting into a long list of blockers) I installed OpenSUSE (Tumbleweed… Once you go rolling release, you can’t go back. :-D).

      In just a few weeks, no idea why or how, it started having a weird problem. When shutting down, every time, it got stuck on some error (waiting for session something, I believe, but I don’t remember really) and it was waiting 1.5min until it continued. No explanation of what exactly it’s waiting for, no way to say “continue now without waiting”… No amount of googling got me anywhere near to finding out what the problem was.

      Later I also ran into a problem where I was changing something about hard drives, I changed the fstab too, but for some reason systemd was getting stuck on trying to mount the drives that weren’t in the fstab anymore. Later I found out that it was my fault, I had a line that mounted the drive, and a few lines later I had some mount bind line operating on that first mount or something, but I still think the normal init system would just spit out that it can’t mount that and go on.

  • ngn@lemy.lolEnglish
    6·
    1 year ago

    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

  • 0xtero@beehaw.org
    61·
    1 year ago

    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.

    • lemmyvore@feddit.nlEnglish
      42·
      1 year ago

      The funniest thing is that most of the arguments against systemd can be made against X and the other way around. But with X the community opinion tends towards a “burn it with fire” or a completely new replacement, whereas for systemd all those arguments somehow get turned on their head.

      If you’re ever bored, try replacing systemd with “X” in a fan’s comment justifying the former.

      • drwankingstein@lemmy.dbzer0.comEnglish
        1·
        1 year ago

        I like running my distro portably (IE in a chroot) and systemd’s udev doesnt work in a chroot, as for everything else, I never really needed anything from systemd outside of the init system itself

  • nyan@lemmy.cafeEnglish
    1·
    1 year ago

    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.

  • kbal@fedia.io
    35·
    1 year ago

    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.