Although that is true, it'll presumably be hard to use them all since some of them will trample each other's symlinks.
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).
i have a system level and a user config, so the system is always the basic stuff like emacs and chrome, while the user config will pull in things like vlc, evince, etc. plus it's not like you have to log out to rebuild, it just fills up your bandwidth.
Reminded of back in '02 or so when the networking spods at $ISP would just install everything off every Red Hat Linux 9 CD when they built a machine so they "didn't have to worry about anything being missing."
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.
It bothers me as well. I love the focus Alpine has on minimalism and security, it's been my main desktop distro for years. It's easily the best distro I've ever used.
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'm still dealing with figuring out how to dodge regreSSHion on Windows so this piqued my interest, I haven't had the occasion to compare glibc and musl, but this post is illuminating [0]
Honestly, I have had very few issues with it. Generally for the big issues there compatibly layer packages available, e.g. you can install a musl-fts package since musl doesn't implement fts.
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.
Perhaps off-topic, but as someone who shares dissatisfaction with all things Poettering:
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?
> 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.
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.
My kind of nerd humor but I read the article only to find that the question I had going into it is not answered: How large might those containers (with/without community) get?
Author here. I did run these numbers, I guess I just didn't think to write them up. I've recomputed them for Alpine 3.21 here.
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.
> 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.
> How large might those containers (with/without community) get?
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
Returns 18GB. Author landed on 98.5% of packages being installable together, ~17.7GB in total, once installed. Community ends up being 100GB with 97.8%, so 97.8GB and final size ends up being ~115GB.
Probably not even the largest image out there, but large enough to be too large :)
About 3 times more packages than Alpine. [2] RIP!
____
[1]: https://github.com/NixOS/nix/issues/308
[2]: https://repology.org/repositories/graphs
reply