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.

  • Auzy@beehaw.org
    link
    fedilink
    arrow-up
    0
    ·
    edit-2
    10 months 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
      link
      fedilink
      arrow-up
      0
      ·
      edit-2
      10 months 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