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 🤔

  • Chinstrap@lemmy.ml
    link
    fedilink
    English
    arrow-up
    26
    ·
    10 months ago

    If you manage to infect your systemd unit list which requires root privilege and give it a permission to run on boot I don’t think it’s an attack vector anymore its one’s stupidity. Systemd is the furthest thing from an outside attack. Someone might poison your bashrc and its more possible than someone inserting a malicious unit file and asking you to run.

    • BlanK0@lemmy.mlOP
      link
      fedilink
      arrow-up
      1
      arrow-down
      10
      ·
      10 months ago

      I didn’t know about bashrc poisoning, thx for the intel.

      You are probably right, systemd attack vector might not be that big as it seems. But its a bit unfortunate that it has that small extra negative layer of security.

      • palebluethought@lemmy.world
        link
        fedilink
        English
        arrow-up
        9
        ·
        edit-2
        10 months ago

        The bashrc poisoning thing was sarcastic. the point is it’s not important as an attack vector because if that’s even part of your surface area, then the attacker is already pretty well into your system

  • Vilian@lemmy.ca
    link
    fedilink
    arrow-up
    19
    ·
    10 months ago

    the init is just a binary, the others systemd features are different programs from different binary, and you are not forced to use them, you can use only the init and don’t use the others, it’s not gonna affect security, systemd init is the most tested one

    and you can’t, a lot of technology that make NixOS and others immutable distros works exists only because of systemd

    and if others init system worked as well, the entire of the linux community would not have changed voluntarily nor indenpendently to it

    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?

    doubt, is too much work just to make a systemd alternative, without the reliability and support that systemd have, but i think it could be a fun hack

    • nyan@lemmy.cafe
      link
      fedilink
      English
      arrow-up
      3
      arrow-down
      1
      ·
      10 months ago

      To set the record straight, since you apparently have no idea of the history: systemd isn’t the original Linux init system, and wasn’t foisted on the Linux community because it was technically superior for most people’s use cases. It still isn’t the only viable Linux init system, but it pulled a Microsoftian embrace-extend-extinguish on udev, which makes it more difficult to switch away. Its current popularity is still not based on technical merits. Instead, it’s political, because most people don’t care about what init they’re using and most distro-makers take the path of least resistance.

      It’s true that you’re not required to use all of the individual executables that comprise systemd, but most distros will require you to install them. So they’re still present as unwanted clutter, and bugs could still pose a security risk if an attacker can run the executables. (This doesn’t mean that OpenRC or runit would necessarily be any more secure—every non-trivial piece of software has bugs, and some percentage of those are going to be security-relevant. You’re not required to care about small amounts of on-disk clutter, either, but some people choose to make their system partitions small and micromanage the contents even if they’re not working on embedded.)

      Compiling your own copy of systemd without the clutter, judging from the contents of the systemd ebuild, requires setting more than 30 compiler options. And then installing the result manually without trashing your system. Not trivial, in other words.

      If systemd works for you, then by all means use it, but accept that other people may choose to install something different on their own machines for what you consider to be bad reasons, or no reason at all, and arguing about it just annoys them without providing any benefit to you.

  • Lupec@lemm.ee
    link
    fedilink
    arrow-up
    16
    ·
    10 months ago

    My understanding as a NixOS user is a lot of its fundamentals are very strongly coupled to systemd. It’s responsible for things like running system activation scripts and managing any services it exposes options to, so replacing it sounds like a tall order.

    I’m not aware of any Nix-based alternatives, but I’d definitely welcome them! Oh and also, as others have pointed out, Guix might fit the bill depending on your needs.

    • BlanK0@lemmy.mlOP
      link
      fedilink
      arrow-up
      3
      arrow-down
      11
      ·
      10 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."

      • Vilian@lemmy.ca
        link
        fedilink
        arrow-up
        10
        ·
        10 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 removed, if it wasn’t secure companies wouldn’t buy it

        • BlanK0@lemmy.mlOP
          link
          fedilink
          arrow-up
          2
          arrow-down
          9
          ·
          10 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.

          • atzanteol@sh.itjust.works
            link
            fedilink
            arrow-up
            7
            ·
            10 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@kafeneio.social
              link
              fedilink
              arrow-up
              2
              ·
              10 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

            • BlanK0@lemmy.mlOP
              link
              fedilink
              arrow-up
              2
              arrow-down
              2
              ·
              10 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).

    • BlanK0@lemmy.mlOP
      link
      fedilink
      arrow-up
      2
      ·
      edit-2
      10 months ago

      GNU Guix, definitely going to check out! I think also most of the packages I have are foss, for non-foss I have flatpak anyway 🤔👍

  • YIj54yALOJxEsY20eU@lemm.ee
    link
    fedilink
    arrow-up
    5
    ·
    10 months ago

    Does Void linux come with a way to handle systemd service files? I’m curious how people do it when so many packages require a daemon running.

    • BlanK0@lemmy.mlOP
      link
      fedilink
      arrow-up
      3
      arrow-down
      2
      ·
      edit-2
      10 months ago

      For daemons, its simply symlinking the services in the ‘sv’ folder to the var/services, it should be running after that.

      Not sure how compatibility with systemd apps work on other inits but for what I know the packages that are shipped focus on specifically the init system that you are running (from whatever repo you use to install on the distro, for example artix has other inits besides runit).

      Edit: Also you have the ‘sv’ command on runit that acts exactly like systemctl. You can stop, start and all that stuff