💾 Archived View for splint.rs › void.gmi captured on 2024-02-05 at 09:59:09. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-09-08)
-=-=-=-=-=-=-
It's the little things that make me feel comfy.
Systemd is fine, but I have to look up how to make a new unit file every time, and then input the path to the executable, which is generally some script I've written. With Void's runit, the service file *is* the script. There's nothing to learn or look up - you just write out a normal script, put it in a file called `run`, and runit will run that script.
Here we have the `at` service in its entirety:
#!/bin/sh exec atd -f
And the network time protocol daemon, running as the ntpd user:
#!/bin/sh exec isc-ntpd -g -u ntpd:ntpd -n >/dev/null 2>&1
And while this is a difference that really makes no difference, it's nice that the service executable itself is called `sv`, rather than `systemctl`. It's easier to type, and fits in with the other traditional UNIX utilities.
There's a lot of good things to be said for the AUR, but speed isn't one of them. Wait a week before updating a reasonably chonky system, and you could be waiting an hour for things to compile. Add a web browser or two in there (e.g. Librewolf) and you'll be waiting longer.
The compiled packages occasionally require manual intervention, and while it's not a great hassle to see that something's gone wrong, then compile it cleanly, it also doesn't seem to have any use for the average user. The binary packages just download and run - no hassle.
Arch's AUR packages also tend to break more often than Void packages. Currently, the various `radicle` packages don't compile on my machine. Void, in comparison, simply has no `radicle` packages, which is much better than offering a broken package.
Void doesn't have huge numbers of packages, but there's something comforting about the fact that it has all the packages I care about. Things like `sc-im` (the terminal spreadsheet editor), `typst`, and `i3-gaps` suggest that the people maintaining Void Linux have a similar workflow to me.
I've never used Void's proprietary repositories, but I appreciate that they're there in case I need one. However, while I *don't* need any, it's nice to feel the separation. When proprietary packages sit next to the others, the only way to know what you're getting is to enquire about the licence for each package, which nobody wants to do.
When you first fire up Void, a lot of packages which you might consider basic aren't there. However, the name of the package is typically the name of the program, so a simple `xbps-install ifconfig iw` sorts the problem immediately. Installing some 'basic' packages serves as a nice reminder that there are plenty of other 'basic' packages which you don't need and aren't on your system.
The x-binary packaging system also has lots of sensible defaults built into the commands. On Arch, if you want to remove orphaned packages, you need to type `sudo pacman -Rsn "$(pacman -Qdtq)"` - an unreasonable mouthful by any benchmark. On Void, it's just `sudo xbps-remove -O`.
If you still use X for display, it has `xorg-minimal` - a meta-package to make sure you get all the X you need, and no more.
Going even smaller, you can see small package splits. `w3m` comes in two parts - `w3m` browser, and `w3m-img` (for those that don't need pictures in their terminal).
And instead of `lolcat`, Void carries `lolcat-c`. It works the same, but it's 23KB instead of the standard 134KB.
There's a time and a place for musl, but when people are using systemd, there's no option to try out different compilers. Void is agnostic towards architectures and compilers, so you can make any selection, and find broadly the same packages in the repositories.
This also means the community is less fractured. On Ubuntu, you'll be running Ubuntu on the main machine, and Raspbian on your raspberry pi. With Arch, you'll be on Arch Arm, and woe betide anyone who goes onto the Arch Linux.org forums and requests help for Arch Arm because it is 'a totally different operating system'. Despite this, Arch Arm uses the standard AUR, and just tries to build packages in the normal x86 way. For most packages, this succeeds, but for others (e.g. `gitlab-cli`, it fails). Void may often just fails, but I think I prefer hit or miss to guess-work.
Then we have the alternative flavours of Arch, which have their own default desktops, along with Ubuntu derivatives, such as Kubuntu, Xubuntu, et c., each with their own communities. Void's a lot easier; it's just Void. If you want a Void ISO with a pre-installed desktop, one is available, and if anyone wants to build something on top of Void, they could add another version with a few things preloaded.
I have very little idea why this is the case, but I get far fewer problems on the Void Linux distro than on Arch. No random X problems, no little glitches, it just works.
This is after running both for about five years.
Void and Arch have roughly the same idling RAM and CPU usage, but Void is just a tad faster. It doesn't come with automatic logging, has fewer binaries installed from the outset.
When running a Void Linux server on a Raspberry pi, the start-up RAM was 35MB.
Getting used to the audio took some time. You need to add your user to the audio group, then install pulse, and you have two more groups associated with pulse. I don't know the difference, so I just added myself to both.
Documentation is also rubbish. This hasn't been a real problem, since one can usually just use the developer's documentation for non-obvious items, like `lxc` or `nginx`. Still, it'd be nice to get something similar to the Arch wiki, but for Void.
My raspberry pi won't switch over to Void until there's a pihole package, and every so often I'll find something else nifty in the AUR, which isn't available, such as `peerflix`, or `gtop`.
I can't imagine recommending Void to anyone, given the obscurity, and the fact that most people don't really care about losing 2-seconds start-up time, and 10 MB RAM. But I'll be sticking with it, as it's been comfy as all heck.