7 ms·

How many Alpine packages can you install at once? (2024)

92 points by todsacerdoti 2y ago

deleted 2y ago
[deleted]
linux2647 2y ago
I wonder how large of a container that world create. Sounds like a good exercise for the reader :D
- kevmo314 2y ago
  The ultimate monorepo.
danillonunes 2y ago
Dalai Lama walks up to a package manager and said "Make me one with everything"
- hhthrowaway1230 2y ago
  Proceeds to have zero packages
- deleted 2y ago
  [deleted]
Diti 2y ago
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 https://github.com/NixOS/nix/issues/308 [2]: https://repology.org/repositories/graphs https://repology.org/repositories/graphs
- jchw 2y ago
  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.
  - ycombinatrix 2y ago
    >some kind of magic FUSE system to block while the derivations are built or pulled Like OneDrive in Windows
  - rkeene2 2y ago
    AppFS (my project) and CERN VMFS do this, if I understand you correctly.
  - dnr 2y ago
    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/ 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).
  - exe34 2y ago
    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.
- a3w 2y ago
  You urge me to not install all of them? But I might need that program later and not have internet. /s
- iqandjoke 2y ago
  Does it even work at all for the installation to be finished without error? Just curious.
_blk 2y ago
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? ;)
- diggan 2y ago
  > 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 :)
  - AlotOfReading 2y ago
    Only twice as large as the "minimal" dev images I have to work with.
- chamlis 2y ago
  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.
  - _blk 2y ago
    Awesome, thanks :D Didn't think it'd be so little. I'd have guessed 4x that.
  - 2y ago
mst 2y ago
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.
- ruthmarx 2y ago
  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.
  - tonyhart7 2y ago
    for containerization??? what security feature they ship??? I use distroless for shipping the code (low mem traces)
    - ruthmarx 2y ago
      > 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.
      - jazzyjackson 2y ago
        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 https://fosstodon.org/@musl/112711796005712271
mrlonglong 2y ago
I love alpine. They make a great base for small and efficient docker containers.
- squarefoot 2y ago
  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.
tomcam 2y ago
I'm much more interested in how few packages I could install
- diggan 2y ago
  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.
dmd 2y ago
How big would it be for Debian?
MarkusWandel 2y ago
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.
user3939382 2y ago
idk but slightly off topic I was super annoyed to find they removed the nobody.nobody user in a point release

92 points by todsacerdoti 2y ago

deleted 2y ago

[deleted]

linux2647 2y ago

I wonder how large of a container that world create. Sounds like a good exercise for the reader :D

kevmo314 2y ago
The ultimate monorepo.

danillonunes 2y ago

Dalai Lama walks up to a package manager and said "Make me one with everything"

hhthrowaway1230 2y ago
Proceeds to have zero packages
deleted 2y ago
[deleted]

Diti 2y ago

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 https://github.com/NixOS/nix/issues/308 [2]: https://repology.org/repositories/graphs https://repology.org/repositories/graphs

jchw 2y ago
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.
- ycombinatrix 2y ago
  >some kind of magic FUSE system to block while the derivations are built or pulled Like OneDrive in Windows
- rkeene2 2y ago
  AppFS (my project) and CERN VMFS do this, if I understand you correctly.
- dnr 2y ago
  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/ 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).
- exe34 2y ago
  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.
a3w 2y ago
You urge me to not install all of them? But I might need that program later and not have internet. /s
iqandjoke 2y ago
Does it even work at all for the installation to be finished without error? Just curious.

_blk 2y ago

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? ;)

diggan 2y ago
> 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 :)
- AlotOfReading 2y ago
  Only twice as large as the "minimal" dev images I have to work with.
chamlis 2y ago
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.
- _blk 2y ago
  Awesome, thanks :D Didn't think it'd be so little. I'd have guessed 4x that.
- 2y ago

mst 2y ago

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.

ruthmarx 2y ago
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.
- tonyhart7 2y ago
  for containerization??? what security feature they ship??? I use distroless for shipping the code (low mem traces)
  - ruthmarx 2y ago
    > 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.
    - jazzyjackson 2y ago
      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 https://fosstodon.org/@musl/112711796005712271

mrlonglong 2y ago

I love alpine. They make a great base for small and efficient docker containers.

squarefoot 2y ago
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.

tomcam 2y ago

I'm much more interested in how few packages I could install

diggan 2y ago
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.

dmd 2y ago

How big would it be for Debian?

MarkusWandel 2y ago

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.

user3939382 2y ago

idk but slightly off topic I was super annoyed to find they removed the nobody.nobody user in a point release