I’m curious to know why people use systemd-less distributions. Which one would you recommend to someone who wants to stop using systemd?
I’m curious to know why people use systemd-less distributions. Which one would you recommend to someone who wants to stop using systemd?
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:
@HappyFrog @SwooshBakery624 I think the real fun (value) in not using systemd is much greater flexibility to mix and match different sub-systems and make the machine start up in the exact state you want it to, with just enough essential daemons.
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.
Chromium is open source. Google is evil.
“Fork it, grandpa!”
That’s a false equivalence and you know it
No, it’s not. It’s a great equivalence, even.
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
moreof it” or the opposite "I wantlessof it`.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.
I think you did a great job explaining it! I really liked my short time with void and would probably still be using I were more capable of setting up and maintaining a minimal distro
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 varlinkctlMajority of these are separate utilities developed under systemd umbrella.
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.
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?
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.
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”.
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.
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.
Lol, you are a clown. First one on the list.
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.
…so they are separate binaries
Systemd doesn’t require all of these to function. You can use systemd as just a init system
Share the content of the file
90-systemd.presetfrom your system.