The rants are cool and all, it’s more like a journal to me. But think of it like reading a whole website that you just randomly found online (idk, UnixSheik?). You wouldn’t be going from the beginning to the end (although you could, just skip the parts that don’t seem interesting). I screw around there with SBCs, lab, random internet stuff, life experiences, different OS, solar conversion and more.
If you’re interested in the s6 suite, read the 2 wikis on the forum and its adjacent comments. Maybe help me improve the wiki, comment there and let me know what I should improve.
I wish I had a personal git (github sucks and I’m there too), to have bugs open for my wikis and track them (it’s easy to lose track of stuff here, which is why I kinda added [WIP] everywhere on the wiki that needs improvements, but I need to read it again for context, then remember what was I supposed to add there).
With the exception of systemd-boot, most of the systemd-somethings bit me (networkd, timed and mount come to mind immediately).
gummi-boot is nice, I used it on arch eons ago. I use it on proxmox now (because grub on my hardware is broken if you don’t have a keyboard plugged-in). I also have the gummiboot-efistub (not the full gummi-boot) on my system (which isn’t even running systemd) to start zfs-boot-menu.
I prefer abduco + dvtm, but I’m not so high up my horses that I’d even suggest that you change your workflow, I’m just stating my preference. But I love how tmux folks didn’t compromise in that thread.
Artix is my least favorite s6 implementation, because everything is literally started daemon-tools style - there’s the dependencies.d definition, but nobody in artix thought it was a good idea to use it, so that means, for instance, that sshd starts, there’s no network, crashes, starts, there’s no network, crashes, then there’s network and then starts, instead of just using dependencies and wait until networking is available - you can do that yourself, but come on!, at least do some sane defaults.
That’s why I’m working on my opinionated s6_services git repo and the 2 wikis on the forum (the one on how to install and the other, more generic, how to use s6 and s6-rc).
I’ve got eudevd on my system. Works fine, got enp-something-something as int names. S6 suite provides mdev, which is minimal. I didn’t try it, idk what it does (besides being a hotplug daemon like udev), but I’m not using it, I stuck with eudev. I might give it a shot if I’ll ever work on a minimal system. skarnet.org runs on a custom distro running on busybox with s6, with the whole website being hosted on the smallest gandi.net 1 core 512mb of ram offering (serves http and git, what more could you want?).
Why do you need to filter interfaces, out of curiosity? Well, with the exception of devices not starting up in the same order on boot up, then I don’t see any reason not to use the classic ethX. If your int names are randomized, then you’ve got a problem if you have static configurations (unless you check for the mac and apply them on the int with the correct mac, which sounds like a nightmare to maintain anyway - I’m glad I don’t have to go through that and that my interface names remain the same across reboots).
The reason I moved to s6-rc is because my uptime was so short. I wanted to ensure that a) my startup services always respect the same dependencies / order and that b) no services are stopped in the wrong order. I solved a) pretty easily in the runit service files (the run script that launches the daemon), but I couldn’t get b) to work (everything is killed in parallel in runit).
I was thinking of moving to nixos (which uses systemd, but it’s so removed from systemd in its own way), but then I (re-)found s6-rc. I’d still love to have a declarative os, like nixos, but for what I’m doing, as long as I back up my configurations and my actual data, I don’t need to deploy the same thing over and over (although it was really nice when I did that on 2 or 3 raspberry pis).
IDK how well would s6-rc work for systemd veterans. I love that it just gets out of your way, but the service files are scripts. Worst, they are execline scripts (which is awesome in its own way, but you need to learn execline). Well, you can literally write the run services in shell, perl, python or anything else, really, as long as you specify the shebang, but ideally you use execline to just call the shell run services from another location.
Unlike systemd, you don’t have soft dependencies and ordering. Everything is a hard dependency. And there are a few concepts that go way above systemd’s design, like bundles, which are so flexible, yet so simple, it’s incredible.
And like its daemon-tools predecessor, the context for a service always remains the same for every execution, so you always have a clean environment for your programs to run.
.