I’m curious to know why people use systemd-less distributions. Which one would you recommend to someone who wants to stop using systemd?

  • esc@piefed.social
    link
    fedilink
    English
    arrow-up
    7
    arrow-down
    1
    ·
    8 days ago

    What do you think about coreutils, util-li nux, findutils, god forbid iproute2? They all are binaries from THE mentioned packages, built from THE repo (have you heard of monorepos?) are they also overreaching and that’s THE point?

    • BB_C@programming.dev
      link
      fedilink
      arrow-up
      4
      arrow-down
      5
      ·
      8 days ago

      Your “separate utilities developed under systemd umbrella” claim was simply false.

      Your attempted retort was even more funny, since many coreutils implementations can actually literally be built into a single binary with many symlinks, with dispatch done based on arg0. It’s even the preferred packaging option.

      There are a lot of interdependencies within those source trees. Nothing is self-contained. So the “itz just monorepo bro” is also false.

      they also overreaching and that’s THE point?

      You literally just listed multiple projects 🤭, where their collective surface is also nowhere close the the systemd forced hegemony. Maybe they should all unite and join the “umbrella”.

      • esc@piefed.social
        link
        fedilink
        English
        arrow-up
        3
        arrow-down
        1
        ·
        edit-2
        7 days ago

        It wasn’t because it’s true. They are literally separate utilities. Many is exactly two (i think) busybox and whatever the other one is called. For vast majority of people and in context it should be obvious that coreutils I was referring to is GNU coreutils, you are being intentionally obtuse. There are three, I believe, mandatory parts that fall under systemd umbrella everything else is either optional or separate. Interdependency angle is disengenious at best, programs can and have dependencies, it’s laughable that you think that they aren’t separate utilities because they depend on other utility.

        Forced hegemony I’m dying lol.

        • BB_C@programming.dev
          link
          fedilink
          arrow-up
          2
          arrow-down
          1
          ·
          8 days ago

          Let’s play a game. Pick a “separate utility” from the list above, and let’s see if you know what you’re talking about, or just waffling.

            • BB_C@programming.dev
              link
              fedilink
              arrow-up
              1
              arrow-down
              1
              ·
              7 days ago

              First one on the list.

              % readelf -d /usr/bin/bootctl | rg -r '$1' '.*NEEDED.*\[(.*)\]'
              libsystemd-shared-262-1.so
              libgcc_s.so.1
              libc.so.6
              
              • esc@piefed.social
                link
                fedilink
                English
                arrow-up
                1
                ·
                edit-2
                7 days ago

                Are you familiar with the concept of shared libraries? Please, stop embarrasing yourself.

                  • esc@piefed.social
                    link
                    fedilink
                    English
                    arrow-up
                    1
                    ·
                    7 days ago

                    How boring.

                    Will you ever get to the point where you say clearly why exactly bootctl isn’t a separate utility? No, having dependencies doesn’t make something not a separate utility. And no, communicating with systemd daemon over unix sockets doesn’t as well.

      • Tobias Hunger@programming.dev
        link
        fedilink
        arrow-up
        2
        ·
        7 days ago

        Of course there are dependencies. They all are tools that do one thing well amd call into other tools to do thenthings those tools were built to do. E.g. many need systemd-init to function as that is the tool to manage the livetime of services running on the system.