Spent like a few hours learning about and setting up snapshots, only to never every use them lol. I guess I just don't break my computer often enough nowadays. Copy-on-write is great tho, especially for making quick backups of a large directory structure before running that risky shell one-liner.
I don't support calling people who volunteer their time to develop free software "just shit", but I can't help but agree at least a little bit about redhat. Redhat is kind of like Richard Nixon: if you just assume that eveything you dislike is their fault, you would be right surprisingly often.
"Predictable" interface naming
avahi
dbus
That being said, they did also contribute to a lot of kickass software, from btrfs to Firefox to linux namespaces to qemu to pipewire, as well as to software that you can't really live without like glibc or gdb. So I guess the converse also holds: if you just assume that everything you like is there thanks to redhat, you would be correct pretty often as well. Can't really say that about Nixon though.
Good software can come from almost any language, but yeah there's just something about rust CLI tools. I've pretty much always had issues with incorrect file type associations on Linux, until I started using handlr. exa (or eza?) is great too. Just like ls but better in every way.
If you've never had a reason to not use it, then it's fine to continue using it. Systemd has been shown to be more or less stable, fast, and secure. The reason I don't like it is because it makes simple things really complicated. Some examples:
The meme
u/phoenixz@lemmy.ca example with sshd
Distros that use systemd init also seems to prefer using other systemd components as well. So you can get caught in weird situations where one task is spread across two different systems (e.g. systemd timers vs cron, systemd-elogind vs acpid)
If none of these sound familiar, then switching to a non-systemd distro likely won't make your life easier. But if you do, then it might be worth considering.
pretty sure the runnit solution won’t allow this either
I'm no expert, but I think you could make a special group, set the supervise directory to be owned by that group, and add all relevant users to that group? Either way, as I explained in a different reply, running the service as a user vs letting that user control a root service are completely different things, and one is not always a substitute for the other.
A technology that was made To Stop Criminals™ being used against a political whistleblower? Color me surprised! (thanks for sharing the link btw, didn't know about that)