[HN Gopher] How many Alpine packages can you install at once? (2...
___________________________________________________________________
How many Alpine packages can you install at once? (2024)
Author : todsacerdoti
Score : 65 points
Date : 2025-01-21 15:47 UTC (7 hours ago)
(HTM) web link (www.naff.dev)
(TXT) w3m dump (www.naff.dev)
| linux2647 wrote:
| I wonder how large of a container that world create. Sounds like
| a good exercise for the reader :D
| kevmo314 wrote:
| The ultimate monorepo.
| danillonunes wrote:
| Dalai Lama walks up to a package manager and said "Make me one
| with everything"
| hhthrowaway1230 wrote:
| Proceeds to have zero packages
| Diti wrote:
| 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
| jchw wrote:
| 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.
| rkeene2 wrote:
| AppFS (my project) and CERN VMFS do this, if I understand you
| correctly.
| dnr wrote:
| 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).
| exe34 wrote:
| 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 wrote:
| You urge me to not install all of them?
|
| But I might need that program later and not have internet. /s
| _blk wrote:
| 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 wrote:
| > 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 wrote:
| Only twice as large as the "minimal" dev images I have to
| work with.
| chamlis wrote:
| 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.
| yjftsjthsd-h wrote:
| > 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.
| mst wrote:
| 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 wrote:
| 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 wrote:
| for containerization??? what security feature they ship???
|
| I use distroless for shipping the code (low mem traces)
| ruthmarx wrote:
| > 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 wrote:
| 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
| ruthmarx wrote:
| 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.
| ssl-3 wrote:
| 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?
| mrlonglong wrote:
| I love alpine. They make a great base for small and efficient
| docker containers.
___________________________________________________________________
(page generated 2025-01-21 23:01 UTC)