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?
There are folks using Alpine in the desktop (or laptops). Several of us are lurking in #alpine-linux.
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.
> 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.
In the early days, when the bandwidth of the install CD was vastly higher than that of my internet connection, I routinely clicked "Everything" in the package selection of the RedHat install CD (yes CD, not DVD). Simpler times.
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"
Returns 15 as of right now, so that's what it ships with by default (for their images at least). I tried `apk list -I -q | apk del -r -f` just for fun to remove them, but doesn't seem like it's possible, so 15 might be the least amount of packages possible, unless you build your own dist from alpine.
And it runs great on real iron too, desktop included. The amount of applications that have been ported to musl is amazingly large, to the point it becomes among the best options to give new life to slow/old systems.
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 :)
I think you can install 100 % of Nix packages at once if you forget to provide a package name to `nix-env -i` (please stop using `nix-env`). [1]
About 3 times more packages than Alpine. [2] RIP!
____
[1]: https://github.com/NixOS/nix/issues/308
[2]: https://repology.org/repositories/graphs
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.
Hey, I sorta did this. Lazy substitution, at least, not lazy build. Plus a bunch of tricks to speed up downloads.
https://github.com/dnr/styx/
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).
AppFS (my project) and CERN VMFS do this, if I understand you correctly.
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.
Does it even work at all for the installation to be finished without error? Just curious.
You urge me to not install all of them?
But I might need that program later and not have internet. /s
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.
for containerization??? what security feature they ship???
I use distroless for shipping the code (low mem traces)
> for containerization???
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]
[0] https://fosstodon.org/@musl/112711796005712271
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?
There are folks using Alpine in the desktop (or laptops). Several of us are lurking in #alpine-linux.
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.
> 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.
That's probably it.
> Not rolling release, possible to stick to a version and just get security updates
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.
In the early days, when the bandwidth of the install CD was vastly higher than that of my internet connection, I routinely clicked "Everything" in the package selection of the RedHat install CD (yes CD, not DVD). Simpler times.
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.
I wonder how large of a container that world create. Sounds like a good exercise for the reader :D
The ultimate monorepo.
I'm much more interested in how few packages I could install
I love alpine. They make a great base for small and efficient docker containers.
And it runs great on real iron too, desktop included. The amount of applications that have been ported to musl is amazingly large, to the point it becomes among the best options to give new life to slow/old systems.
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?
Who's taking the nerd-snipe bait? ;)
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.
Awesome, thanks :D Didn't think it'd be so little. I'd have guessed 4x that.
> How large might those containers (with/without community) get?
Thrown together awk summing alpine main repository as of v3.21:
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 :)
Only twice as large as the "minimal" dev images I have to work with.
How big would it be for Debian?
Dalai Lama walks up to a package manager and said "Make me one with everything"
Proceeds to have zero packages