đž Archived View for splint.rs âş void.gmi captured on 2024-07-09 at 00:16:50. Gemini links have been rewritten to link to archived content
âŹ ď¸ Previous capture (2024-05-26)
-=-=-=-=-=-=-
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:
exec atd -f
And the network time protocol daemon, running as the ntpd user:
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.