• Systemd-init has a larger attack surface compared to runit, openrc, or sysVinit.

  • Systemd-logind relies on systemd, so we need to adapt it for non-systemD distributions to ensure compatibility with certain applications like GNOME.

  • Udev also depends on systemd.

  • SystemD is specific to Linux, which makes porting software to *BSD even more challenging. It’s uncertain what the future holds, and there may be circumstances where Linux becomes unusable for you (e.g., compatibility issues with your laptop). Having a good alternative that doesn’t require relearning everything is generally beneficial.

  • SystemD-based distributions often come with more than just “systemd-init.” They include additional components like logind, resolved, networkd, systemd-timers, etc. However, many people still prefer using the alternatives they were accustomed to before systemd became popular, such as dhcpcd and cron. Consequently, having both sets of tools installed can increase the attack surface.

  • Nibodhika@lemmy.world
    284·
    10 months ago
    • Systemd-init has a larger attack surface compared to runit, openrc, or sysVinit.

    So what? Linux Kernel has an even larger attack surface, the size of the attack surface is a moot point without examples of attacks being made

    • Systemd-logind relies on systemd, so we need to adapt it for non-systemD distributions to ensure compatibility with certain applications like GNOME.

    Yes, systemd modules depend on systemd, that’s like complaining that a GUI application depends on X.

    • Udev also depends on systemd.

    It doesn’t, that’s ridiculous, several distros don’t use systemd and still have udev

    • SystemD is specific to Linux, which makes porting software to *BSD even more challenging. It’s uncertain what the future holds, and there may be circumstances where Linux becomes unusable for you (e.g., compatibility issues with your laptop). Having a good alternative that doesn’t require relearning everything is generally beneficial.

    If your laptop doesn’t run Linux it will not run BSD since BSD has less hardware compatibility than Linux. Also BSD is a different system, you’ll need to relearn a lot of things, how to enable services is just one of them, and a pretty small one at that. And Finally there are forks of systemd that work on BSD, the reason it’s not used there is not technical.

    • SystemD-based distributions often come with more than just “systemd-init.” They include additional components like logind, resolved, networkd, systemd-timers, etc. However, many people still prefer using the alternatives they were accustomed to before systemd became popular, such as dhcpcd and cron. Consequently, having both sets of tools installed can increase the attack surface.

    Again, more attack surface does not mean anything, to add to that example most people use the precompiled kernel that comes with their distro instead of compiling a leaner one to diminish attack surface, because that’s irrelevant. You could have said let’s your system bloated which would be a somewhat valid point, the answer being if the person cared they would uninstall one of the alternatives, but you chose the most insignificant aspect of this, if there’s a vulnerability in your computer it’s 99.99999% coming from whatever you exposed in that computer, e.g. SSH, Nextcloud, etc, chances of an attack coming through systemd are so ridiculously small it’s not even worth mentioning, and if ever someone discovers an escalation privilege or something similar on systemd the fact that everyone uses it will make the fix available in 24h on most major distros.

    There are reasons to hate on systemd, but you didn’t provided a single valid one.

    • Unsafe@discuss.onlineOP
      36·
      10 months ago

      Yes, systemd modules depend on systemd, that’s like complaining that a GUI application depends on X.

      SystemD is not modular. Logind is just an executable that depends on systemD libs. Red Hat could design it to be init-agnostic(similar to elogind). But they didn’t. Any assumptions, why?

      • Nibodhika@lemmy.world
        7·
        10 months ago

        Yes module is not the correct word, but that’s nitpicking, the concept is still the same, it’s a binary that depends on systemd, that’s a developer choice, same as using GTK or Qt, there are up and downsides to choose what your program depends on, the developers of systemd-logind decided to depend on systemd knowing the downsides, and distros decide to use it also knowing of them. As for your question possibly the answer is that the added difficulties of making it system agnostic did not compensated for the low user base, same reason most games don’t have a native binary.

        • Unsafe@discuss.onlineOP
          42·
          10 months ago

          the added difficulties of making it system agnostic did not compensated for the low user base

          • 2003: Udev was launched, providing support for musl, non-systemd distros, and others.
          • 2004: NetworkManager was launched, with Udev as a crucial dependency.
          • 2006: Dbus was created without dependencies on distro-specific packages.
          • 2009: Dbus becomes a dependency for NetworkManager.
          • 2010: Red Hat introduces systemd, with core components including logind, journald, and timers.
          • 2012: Developers made udev less compatible with old kernels, musl-based, and non-systemd Linux distros by merging it with systemd. You can find more information about this here: https://lwn.net/Articles/490413, https://lwn.net/Articles/529314/
          • 2017: PipeWire was launched, with logind as a dependency.
          • 2017: Reimplementations of the bus protocol called dbus-broker were launched. Its compatibility launcher requires systemd.
          • 2020: After systemd had already been adopted by all major distros, systemd-tmpfiles gained the ability to be built as a standalone executable.
          • 2022: WirePlumber was launched, with pipewire as a hard dependency.

          Looks like Red Hat makes everything they can systemd-dependent. Including Gnome.

    • Unsafe@discuss.onlineOP
      15·
      10 months ago

      It doesn’t, that’s ridiculous, several distros don’t use systemd and still have udev

      Void uses eudev. Alpine uses eudev. Gentoos uses udev with patches. What non-systemd distros use vanilla udev?

      • Nibodhika@lemmy.world
        8·
        10 months ago

        Ah, so with udev you meant systemd-udev, in that case the answer is the same as systemd-login, complaining that a systemd module doesn’t work outside of systemd is ridiculous.

        • Unsafe@discuss.onlineOP
          14·
          10 months ago

          The thing is that it can work. Which shown by eudev. Looks like it’s important for Red Hat to make everyone dependent on SystemD suit.

    • Unsafe@discuss.onlineOP
      15·
      10 months ago

      Again, more attack surface does not mean anything, to add to that example most people use the precompiled kernel that comes with their distro instead of compiling a leaner one to diminish attack surface, because that’s irrelevant.

      Most people also don’t use selinux or apparmor, compile the kernel with -ftrivial-auto-var-init=zero and verify downloaded files using pgp signatures. But it doesn’t mean these things are irrelevant. Even your phone has selinux=enforced option set. Why do you think your pc is not worth it?

      • Nibodhika@lemmy.world
        51·
        10 months ago

        You went on a tangent, my point is that larger attack surface does not necessarily equate to more risk. As an example my kernel has controller support even though I have never plugged a controller to it, that grants it a larger attack surface, but does not make it less secure in any significant sense of the word. Therefore just claiming larger attack surface is not a valid criticism on it’s own unless you can provide examples of actual security flaws.

  • bionade24@kbin.social
    242·
    10 months ago

    I absolutely dislike the hate for systemd. Especially if there’s bullshit claims like

    having both sets of tools installed can increase the attack surface.

    in there.

    larger attack surface compared to runit, openrc, or sysVinit.

    Because they don’t execute million lines super thoroughly checked shell code or why exactly? Without any explanation total FUD.

    Some independent binaries from the systemd project, e.g. systemd nspawn, can even used on OpenRC and the systemd project explicitly didn’t change the way to launch udev in debug mode because the Gentoo non-systemd udev pkg maintainer asked to not do so (nicely).

    You should instead tell people why OpenRC/runit is (more) awesome in your opinion and maintain initscripts for them. Maybe you can volunteer at the Debian project and get them to adopt OpenRC aside systemd instead of only removing the remnants of sysVinit support. This would also be beneficial for pragmatic pro-systemd users that have to deal with docker or chroot environments.

    • Unsafe@discuss.onlineOP
      37·
      10 months ago

      Because they don’t execute million lines super thoroughly checked shell code or why exactly? Without any explanation total FUD.

      Because they are not merged with journaling system, job scheduler and watchdog. More features→more attack surface.

      • Unsafe@discuss.onlineOP
        18·
        10 months ago

        It’s a matter of probability. Probability of discovering vulnerabilities in multiple tools doing same thing is higher than in just one.

  • oranki@sopuli.xyz
    141·
    10 months ago

    Imagine if all the people who prefer systemd would write posts like this as often as the opposition. Just use what you like, there are plenty of distros to choose from.

    • Unsafe@discuss.onlineOP
      24·
      10 months ago

      Not really. Void, alpine, gentoo are the only usable ones(besides non-systemd forks of arch and Debian). These are the only ones maintaining enough packages, providing enough documentation, not being just poorly maintained forks of X distro.

  • Snot Flickerman@lemmy.blahaj.zoneEnglish
    186·
    10 months ago

    There is no such thing as a perfect OS where there is no attack surface or dependencies.

    OP, you’re absolutely right about systemd, but similar critiques can be given to nearly any underlying OS service. (Also, I’m sure this is in response to other posts praising systemd)

    I’m just starting to feel like it’s a little silly to even have a conversation one way or another about these things instead of just accepting that people could and should use the tools that fit their use case scenario the best.

    For most people, the stuff they gain from things (for example, systemd) outweighs the downsides.

    We don’t make such choices in a vacuum. It’s important to know limitations, attack surfaces, and dependencies, but it’s important mostly for being able to choose the right GNU tools for yourself.

    Nobody can tell you what the best OS/Kernel/GNU tool is to use, because that’s always deeply dependent on your specific needs for the task at hand. While PCs are “general purpose computing,” they all can have wildly different hardware and software hiccups, and only you can use your own knowledge to choose the best tools for your use-case.

    • Unsafe@discuss.onlineOP
      16·
      10 months ago

      What an average Mint user gains from systemd? A bit slower boot time? A bit more ram used? 50mb heavier system updates? What problems systemd solves? I use systemd, runit and openrc on different machines and I don’t face any significant problems.

  • Presi300@lemmy.worldEnglish
    8·
    10 months ago

    You can replace Systemd with any piece of software in the title and it’d still be correct…