I like the idea of nixOS and will definitely try it in the future to see how portable I can make the setup be (hopefully a couple of files that can configure the entire machine).

But the only thing in my mind that is stopping it not being the absolute almost perfection of a tech-savy distro is the reliance of systemd, which has software that I as a user will never going to touch which adds unnecessary bloat to the init (also more unnecessary attack vectors). And if I really needed to have some of the systemd programs, there are replacements out there that do the job that can be later installed when needed, like having log files and stuff.

What do you think of some day seeing a fork of nixOS that uses other init systems and works well? Or is it just me that likes this idea? Like a voidish nixOS 🤔

  • @[email protected]OP
    link
    fedilink
    -811 months ago

    From a forum:

    "Systemd provides a lot of network functionality in systemd-networkd, journald, timesyncd, etc. that is remote attack surface. All the systemd “cloud of daemons” is tightly coupled by dbus interfaces that enable an attacker to move from one exploited system service to the next. Even if the attacker doesn’t manage to find an exploit in another system service, DoS is easily possible because the DBUS interfaces are quite fragile. Even as a benevolent admin it is easily possible to get the system into a state where e.g. clean shutdown is no longer possible because systemctl doesn’t want to talk to systemd any longer and you cannot fix that. systemd-udevd also has raceconditions galore, so sending any message to it in the wrong order relative to another one will kill the system, maybe even open exploit vectors. At the very least I would, for hardening, recommend not using any network-facing systemd functionality.

    And lines of code are not ridiculous, they are the best first-order estimate available. Of course an actual inspection of the code is better for a comparison, but that is a huge task. sloccount is quick and easy."

    • @[email protected]
      link
      fedilink
      1211 months ago

      err, why would a forum post single-handed prove that the entire linux enterprise world are being stupid, and how you can prove that he is even correct?, he is alone, against the entire world, red hat sell that shit, if it wasn’t secure companies wouldn’t buy it

      • @[email protected]OP
        link
        fedilink
        -711 months ago

        I am not saying this proves single-handedly that systemd has vulnerabilities but it is one of probably many out there. I am not saying enterprise is stupid but I could definitely see some sacrifice being possibly made to spend less time setting up utilities on every systemd machine for enterprise work.

        • @[email protected]
          link
          fedilink
          711 months ago

          I could definitely see some sacrifice being possibly made to spend less time setting up utilities on every systemd machine for enterprise work.

          I’m not sure how much time do you think anyone spends setting up systemd utilities… but as a home admin systemd has saved me a ton of time over the ragtag collection of shell scripts we had in the past. And a lot of that is because of its vastly improved logging.

          I suppose if you consider logs to be “bloat” you won’t understand though. I consider them to be essential services.

          • yianiris
            link
            fedilink
            311 months ago

            s6/66 simplifies dependency of running/starting, automatically enables an s6-log for each service/daemon/bundle it is much faster and smaller than systemd (by a factor of 10 maybe), and once it is up and running it is virtually impossible to bring down without its own routine. Servers have run consistenly for a decade with s6, including skarnet.org

            @atzanteol @BlanK0

          • @[email protected]OP
            link
            fedilink
            011 months ago

            I was saying that you do spend less time cause it is already there. Also you can have logs on other init systems, what I said on the post is that if later I wanted logs I could just setup instead of being already there (and the other utilities, not just the logs of course).