76
Why do you use a systemd-less distro (if you do)? (programming.dev)
submitted 3 days ago by to c/linux@programming.dev
69 comments fedilink hide all child comments
 

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

you are viewing a single comment's thread
view the rest of the comments
[–] 51 points 3 days ago (25 children)

I'm the type of person who wants more systemd in my computer, but if I think the arguments for a systemd-less system are:

  • Making sure that apps remain open and compatible with other init systems, so that if systemd turns evil there is a easy way to escape.
  • Trimming and removing bloat that some people feel systemd provides.
  • Testing out other init systems just for the fun of it, like distro hopping.
  • permalink
  • fedilink
  • source
  • hideshow 25 child comments
    •
  • [–] 12 points 3 days ago (3 children)

    Making sure that apps remain open and compatible with other init systems, so that if systemd turns evil there is a easy way to escape.

    Since systemD is open source, even if they do turn evil it could be forked from the last non-evil version, or another implementation could be made. I do agree with the other two points though.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 6 points 3 days ago* (1 child)

    I’m the type of person who wants more systemd in my computer,

    Why? Don't get me wrong, I have nothing against systemd and will continue using a distribution if it has it or not, it's not a deciding factor right now. But I'm also no one who says "I want more of it" or the opposite "I want less of it`.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 4 points 3 days ago

    I like ot when the software I use feels cohesive, and systemd has a whole echosystem of things that does things the same way. Like, I use quadlets to manage my home server's containers the same way I set up mount points.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 2 points 3 days ago* (last edited 3 days ago) (16 children)

    I’m the type of person who wants more systemd in my computer

    Hear hear. A couple hundred more should do the trick.

    bootctl
busctl
coredumpctl
homectl
hostnamectl
importctl
installkernel -> kernel-install
journalctl
kernel-install
localectl
loginctl
machinectl
mount.ddi -> systemd-dissect
mount.mstack -> systemd-mstack
mount.storage -> storagectl
networkctl
oomctl
portablectl
resolvectl
run0 -> systemd-run
storagectl
systemctl
systemd-ac-power
systemd-analyze
systemd-ask-password
systemd-cat
systemd-cgls
systemd-cgtop
systemd-confext -> systemd-sysext
systemd-creds
systemd-cryptenroll
systemd-cryptsetup
systemd-delta
systemd-detect-virt
systemd-dissect
systemd-escape
systemd-firstboot
systemd-home-fallback-shell -> homectl
systemd-hwdb
systemd-id128
systemd-inhibit
systemd-machine-id-setup
systemd-mount
systemd-mstack
systemd-mute-console
systemd-notify
systemd-nspawn
systemd-path
systemd-pty-forward
systemd-repart
systemd-resolve -> resolvectl
systemd-run
systemd-socket-activate
systemd-stdio-bridge
systemd-sysext
systemd-sysinstall
systemd-sysusers
systemd-tmpfiles
systemd-tty-ask-password-agent
systemd-umount -> systemd-mount
systemd-vmspawn
systemd-vpick
timedatectl
udevadm
updatectl
userdbctl
varlinkctl
  • permalink
  • fedilink
  • source
  • parent
  • hideshow 16 child comments
    •
  • [–] 6 points 3 days ago* (last edited 3 days ago) (15 children)

    Majority of these are separate utilities developed under systemd umbrella.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 15 child comments
    •
  • [–] 3 points 3 days ago (14 children)

    No, they aren't. These are the binaries from THE systemd package , built from systemd releases, from THE systemd repo.

    A single source tree looking like an "umbrella", and an overreaching one at that, is THE point.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 14 child comments
    •
  • [–] 6 points 3 days ago (11 children)

    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?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 11 child comments
    •
  • [–] -1 points 3 days ago* (10 children)

    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".

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 10 child comments
    •
  • [–] 2 points 2 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.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 2 points 3 days ago* (last edited 2 days ago) (8 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 8 child comments
    •
  • [–] 1 point 3 days ago (7 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 7 child comments
    •
  • [–] 1 point 2 days ago (6 children)

    Lol, you are a clown. First one on the list.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 0 points 2 days ago (5 children)

    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
  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 1 point 2 days ago* (last edited 2 days ago) (4 children)

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

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 1 point 2 days ago (3 children)

    How ironic!

    Now post the output:

    ls -ld /run/systemd/io.*
  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 1 point 2 days ago* (2 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 2 days ago (1 child)

    Good.

    So the tool YOU chose is NOT:

    • standalone at the project level ✅
    • standalone at the repo level ✅
    • standalone at the source level (trivially shown with the libsystemd-shared.so dep without requiring looking further) ✅
    • standalone/fully independent at the runtime level ✅

    This and the sibling sub-thread where I mentioned presets show with actual facts how the systemd forced hegemony actually works, where it's not just a simple case of "they just have some stand-alone cli tools under their umbrella bro".

    The project itself wouldn't try to (clumsily) dispute this either, since it's at the core of what they consider a selling point; interface unification and deeper integration with the system.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •