About 3 times more packages than Alpine. [2] RIP!
____
It doesn't really make that much sense, but I've always wanted a sort-of hybrid lazy Nix store. Rebuilding my NixOS machines take a long time since I like to have my preferred software configured and installed at the system level mostly, but there's some stuff that isn't so essential that it needs to block the upgrade. So I've thought about a hybrid solution where the packages would get built in the background and you could have some kind of magic FUSE system to block while the derivations are built or pulled from Hydra.
If you wanted to, you could combine this with the idea of installing every Nixpkgs package. It might even sort of make sense, as long as you ditch the "also work on them in the background" part... although it makes the surface area of your system absurd.
Lazy build sounds tricky: you don't know the contents of the package before you build it, so you don't even know what to symlink into /run/current-system/sw. I guess you'd have to have some kind of wrapper. Maybe similar to comma.
I just solved that part by setting up CI for most of my system config (integrated with the above).
Like OneDrive in Windows
But I might need that program later and not have internet. /s
Those were the only *n?x boxen at the place that I did my best to avoid touching. It was ... I don't recall that it ever caused a problem (a buggy RH kernel that made fork() only work statistically did once, but that was orthogonal) but it just bothered me as a matter of principle.
I use distroless for shipping the code (low mem traces)
No, as my main OS on my laptop and any other computers. I had better luck and a better experience over Void and Artix, and I'm not interested in systemd based distros.
> what security feature they ship???
The focus on minimization is a security feature given it reduces attack surface area. I'd say embrace musl wholeheartedly is another (as an example, Alpine sshd wasn't vulnerable to that big remote root vuln from last year). They have a general commitment to security as a priority that I don't think most distros share, which I appreciate.
I think there is value in a cleaner, newer, more minimal c library. Pretty much everything just works, and for what doesn't I either compile statically in a devuan container or use a flatpak.
Using Void on my main desktop has been fun and I've learned a lot about how modern Linux systems fit together whether I liked it or not, because the instructions for using ZFS root at that time involved starting mostly from scratch.
But I feel like a lot of people who use Void are using it mostly-headless, and that this means when something does go wrong then I'm in mostly uncharted territory.
How does Alpine compare in the day-to-day business of using a computer, do you suppose?
This is why I used Slackware 20 years ago. Slackware then tried to compete with Ubuntu and Fedora and IMO lost its way.
> How does Alpine compare in the day-to-day business of using a computer, do you suppose?
For day to day usage I think there are similairities, but I can share some reasons I prefer Alpine:
- Not rolling release, possible to stick to a version and just get security updates
- Focus on minimization. A minimal Alpine install is about 500mb, 700 after I install X and my WM and a few other core things. A void install was something like 1.2gb even trying to keep it minimal.
- Because Alpine, IMO is more dedicated to musl, the ports to musl have more care behind them and seem to work better, just anecdotal maybe biased experience.
- I prefer apk over xbps, one thing xbps can't do afaik is search files in packages, e.g. apk search library.h will return a result if it exists.
- I still feel void gets in the way more than it needs to. Installing or overriding a bootloader and custom kernel was easier in Alpine then void, only barely, but enough I noticed.
That's probably it.
If you do prefer rolling release, you can use the edge channel instead.
That’s a nice thing about Alpine; you can pick between stable releases or rolling release depending on what fits best.
postmarketOS is a downstream of Alpine, and they focus on shipping ready to use GUI images. They also count as Alpine users in terms of testing and fixing packages related to a GUI session.
Who's taking the nerd-snipe bait? ;)
Maximising the number of packages gives 5492/5536 packages (99.2%) for just main, with a total install size of 17.03GiB. Including community gives 25026/25383 packages (98.6%) with a total install size of 107.85GiB.
If we instead maximise the total installed size directly, we install 5428/5536 (98.0%) packages from main, with a total install size of 17.06GiB. Including community gives 24711/25383 packages (97.4%) with a total install size of 110.36GiB.
Of course, if you're building a container, it would be redundant to install a kernel, so these numbers are somewhat inflated.
Depends what the container is for; I've used containers to build bootable OS images and had to explicitly install kernel and associated packages. Obviously that's a weird edge case, but if we're discussing installing as many packages as possible we're already off the beaten trail.
Thrown together awk summing alpine main repository as of v3.21:
awk -F ':' '/^I:/ { sum += $2 } END { print sum }' APKINDEX | numfmt --to=iec --suffix=B
Probably not even the largest image out there, but large enough to be too large :)
These days when I set up a Linux machine - I don't do in-place updates; an occasional everything-from-scratch restart helps clear out legacy clutter - between the "update" and the packages I actually use (I have a post-install script for my preferred environment), over a gigabyte gets downloaded.
docker run -it alpine:latest sh -c "apk list -I | wc -l"