I love Void and Alpine Linux in concept, and it sounds like I might love this as well if only for how weird it is… But every time I try to use them for real I just keep banging my head into how much config BS is left up to the user. Debian has just spoiled me too much with the amount of little Mystery Edge Cases it solves for you: if you install a program, it has all the correct paths, config file locations, etc for running on a Debian system. If you install a program that is a service, such as a database or server, then it starts up after install, is enabled so it starts on each boot, and has sane defaults that lock it down from external access. If you install a server that provides stuff for local use like pulseaudio or Xorg, it generally turns itself on and integrates nicely with whatever else you have installed so you don’t need to wire up all the horrible edge-cases by hand.
Spoiled, I know. But my day job is wiring up all the horrible edge-cases of various programs by hand and then packaging the results for other people to use, so I suppose I can’t be arsed to do it for fun.
Hell no, this is exactly why you roll a distribution and not some hand selected binaries. Good defaults by people who had more time to select what makes sense.
Have never understood this perspective of Debian. It’s never seemed to solve edge cases for me, only create them - so many programs modified in completely unexpected and often poorly documented ways that I’ve had to fight with just to get expected behaviour. Void Linux is probably the best Linux I have used (sans NixOS but that doesn’t count so much, it’s too different).
If you install a program that is a service, such as a database or server, then it starts up after install, is enabled so it starts on each boot…
Opinions are funny… The “auto-start after install” is one of my least favorite things about debian. It seems so ridiculous to me that something would start immediately after I install it, before I have even managed to configure it or modify the defaults!
I sympathize! But the defaults are always good, is the thing. A lot of the common stuff doesn’t need configuring (pulseaudio, Xorg), and a lot of the less-common stuff (nginx, postfix) still has sane defaults so you can see that it works at all before tinkering with it.
I guess I have run into too many cases where I have found the defaults irritating (not always good for me, apparently), requiring me to stop the service, configure, clean-up after the defaults (eg. some default database having been created in a place I didn’t want), configure the service, then start it… and if I want to “try a service out”, I can just start it myself.
I have run into many cases over the years of that where “auto start on install” has been problematic and/or annoying.
Luckily I have to choice to just not use debian on any of my “pet” servers[1]!
[1]: This is less of an issue on “cattle” servers, as the configuration there is typically put in place before the package is installed. But startup and run-at-boot is also configured by the same mechanism there, so that is fairly pointless too.
I have run into many cases over the years of that where “auto start on install” has been problematic and/or annoying.
One such example I have seen recently is glances. Someone installed it on our servers for its useful interface, not realizing that it would also activate a service running a server mode.
Of course the Debian developers have taken the precaution of binding it to localhost, so it was only annoying. But since this is done by hardcoding the IP address in a trivial systemd service file, I am not sure what the value is anyway.
I used Void for a headless build/test machine at a database startup. At the time I had no good reason to install it, I just kinda felt like it. But for building and performance testing it was pretty nice. There were only 7-8 userspace processes running at a time, including my sshd session subprocess, which was surreal. Void really nailed that use case where I specifically wanted my machine doing nothing except handling syscalls and configuring nothing except SSH.
I definitely would avoid it for anything production, internet facing, or as a daily driver. It was great for doing exactly what I wanted, but probably only because I didn’t want to do anything interesting.
That’s not a bad idea. Every time I touched Void I’m impressed by how much it doesn’t do. Then I want to use it as a desktop and so it needs to be running dbus, a sound server, NetworkManager, all that nonsense, and so I have to set all that stuff up by hand. I like my minimalism, but I also like getting shit done and not having to jump through hoops to connect to a coffee shop’s wifi and listen to music on my bluetooth headphones.
I use an SSH terminal server pretty darn frequently though, I might try slapping Void onto it and seeing how it feels. Where did I leave my Raspberry Pi…
on chimera these are pretty much just dinitctl enable networkmanager as root and dinitctl enable wireplumber; dinitctl enable pipewire-pulse as user and that’s… about it (no manual dbus setup, no manual soundserver setup stuff that is not plain basic service enablement, etc)
i don’t consider simplicity to be an excuse for laziness, so you’ll find chimera workflows to be a lot more methodical and less ad-hoc than void/alpine (unhappiness with that was among one of the major reasons why start the project in the first place), and built-in first-class support for user services and login session tracking helps too, as well as being more opinionated (i found the zen of python to be a major inspiration there, particularly “there should be one obvious way to do it” and “simple is better than complex, but complex is better than complicated”)
Being proprietary apps 1Password, Obsidian, and CLion all would not run due to depending on glibc but fortunately they are all available as Flatpaks on Flathub. Installation was a simple flatpak install. Later Flatpak also saved the day when it came to Prusa Slicer, which despite being open-source depends on a specific patched development version of wxWidgets.
Dynamic linking remains an endless source of problems. Proponents keep highlighting its benefits, but ultimately, things just don’t run and you end up shipping whole packages with everything included, like Flatpak does. Dynamic linking is ripe for disruption (not the kind of disruptions it already causes), we need a major revision regarding discovery, versioning, dependency resolution and installation.
Dynamic linking works fine for Windows and macOS and is why they can keep backwards compatibility. IMHO, it’s more a discipline problem in the fd.o space.
The problem with dynamic linking is only a historical lack of proper package managers that could actually solve the problem, requiring pushing the problem around, like putting everything into a container. Note that static typing wouldn’t be a proper solution either — what version did you use for compilation? Is that reproducible?
I’ve been keeping my eye on Chimera. I am a big fan[1] of Alpine, and Dinit seems like a very nice choice as well – I wish Alpine had picked it as their new future[2] init system.
Looking forward to trying Chimera out on a server once I get some time.
I love Void and Alpine Linux in concept, and it sounds like I might love this as well if only for how weird it is… But every time I try to use them for real I just keep banging my head into how much config BS is left up to the user. Debian has just spoiled me too much with the amount of little Mystery Edge Cases it solves for you: if you install a program, it has all the correct paths, config file locations, etc for running on a Debian system. If you install a program that is a service, such as a database or server, then it starts up after install, is enabled so it starts on each boot, and has sane defaults that lock it down from external access. If you install a server that provides stuff for local use like pulseaudio or Xorg, it generally turns itself on and integrates nicely with whatever else you have installed so you don’t need to wire up all the horrible edge-cases by hand.
Spoiled, I know. But my day job is wiring up all the horrible edge-cases of various programs by hand and then packaging the results for other people to use, so I suppose I can’t be arsed to do it for fun.
Hell no, this is exactly why you roll a distribution and not some hand selected binaries. Good defaults by people who had more time to select what makes sense.
Have never understood this perspective of Debian. It’s never seemed to solve edge cases for me, only create them - so many programs modified in completely unexpected and often poorly documented ways that I’ve had to fight with just to get expected behaviour. Void Linux is probably the best Linux I have used (sans NixOS but that doesn’t count so much, it’s too different).
Hence why different distros exist. Solve different problems for different people!
Opinions are funny… The “auto-start after install” is one of my least favorite things about debian. It seems so ridiculous to me that something would start immediately after I install it, before I have even managed to configure it or modify the defaults!
I sympathize! But the defaults are always good, is the thing. A lot of the common stuff doesn’t need configuring (pulseaudio, Xorg), and a lot of the less-common stuff (nginx, postfix) still has sane defaults so you can see that it works at all before tinkering with it.
I guess I have run into too many cases where I have found the defaults irritating (not always good for me, apparently), requiring me to stop the service, configure, clean-up after the defaults (eg. some default database having been created in a place I didn’t want), configure the service, then start it… and if I want to “try a service out”, I can just start it myself.
I have run into many cases over the years of that where “auto start on install” has been problematic and/or annoying.
Luckily I have to choice to just not use debian on any of my “pet” servers[1]!
[1]: This is less of an issue on “cattle” servers, as the configuration there is typically put in place before the package is installed. But startup and run-at-boot is also configured by the same mechanism there, so that is fairly pointless too.
One such example I have seen recently is
glances. Someone installed it on our servers for its useful interface, not realizing that it would also activate a service running a server mode.Of course the Debian developers have taken the precaution of binding it to localhost, so it was only annoying. But since this is done by hardcoding the IP address in a trivial systemd service file, I am not sure what the value is anyway.
I used Void for a headless build/test machine at a database startup. At the time I had no good reason to install it, I just kinda felt like it. But for building and performance testing it was pretty nice. There were only 7-8 userspace processes running at a time, including my sshd session subprocess, which was surreal. Void really nailed that use case where I specifically wanted my machine doing nothing except handling syscalls and configuring nothing except SSH.
I did have to patch the openssh package to allow building with GSSAPI support once we started using kerberos for git, but that turned out to be pleasantly easy.
I definitely would avoid it for anything production, internet facing, or as a daily driver. It was great for doing exactly what I wanted, but probably only because I didn’t want to do anything interesting.
That’s not a bad idea. Every time I touched Void I’m impressed by how much it doesn’t do. Then I want to use it as a desktop and so it needs to be running dbus, a sound server, NetworkManager, all that nonsense, and so I have to set all that stuff up by hand. I like my minimalism, but I also like getting shit done and not having to jump through hoops to connect to a coffee shop’s wifi and listen to music on my bluetooth headphones.
I use an SSH terminal server pretty darn frequently though, I might try slapping Void onto it and seeing how it feels. Where did I leave my Raspberry Pi…
on chimera these are pretty much just
dinitctl enable networkmanageras root anddinitctl enable wireplumber; dinitctl enable pipewire-pulseas user and that’s… about it (no manual dbus setup, no manual soundserver setup stuff that is not plain basic service enablement, etc)i don’t consider simplicity to be an excuse for laziness, so you’ll find chimera workflows to be a lot more methodical and less ad-hoc than void/alpine (unhappiness with that was among one of the major reasons why start the project in the first place), and built-in first-class support for user services and login session tracking helps too, as well as being more opinionated (i found the zen of python to be a major inspiration there, particularly “there should be one obvious way to do it” and “simple is better than complex, but complex is better than complicated”)
Dynamic linking remains an endless source of problems. Proponents keep highlighting its benefits, but ultimately, things just don’t run and you end up shipping whole packages with everything included, like Flatpak does. Dynamic linking is ripe for disruption (not the kind of disruptions it already causes), we need a major revision regarding discovery, versioning, dependency resolution and installation.
Dynamic linking works fine for Windows and macOS and is why they can keep backwards compatibility. IMHO, it’s more a discipline problem in the fd.o space.
The problem with dynamic linking is only a historical lack of proper package managers that could actually solve the problem, requiring pushing the problem around, like putting everything into a container. Note that static typing wouldn’t be a proper solution either — what version did you use for compilation? Is that reproducible?
Thankfully all that is solved now thanks to Nix.
I’ve been keeping my eye on Chimera. I am a big fan[1] of Alpine, and Dinit seems like a very nice choice as well – I wish Alpine had picked it as their new future[2] init system.
Looking forward to trying Chimera out on a server once I get some time.
[1]: I use it on my servers as well as a desktop.
[2]: https://ariadne.space/2021/03/25/lets-build-a-new-service-manager-for-alpine/