In Praise of Alpine and APK

https://whynothugo.nl/journal/2023/02/18/in-praise-of-alpine-and-apk/

by zdw • 3 years ago

159 46 3 years ago

I agree with the author about /etc/APK/world.

APK has become my favorite package manager - so far I've had zero breakage with it, unlike apt and pacman which have lots of sharp corners. The same can be said about Alpine Linux in general.

For the last 6 months I have been experimenting with running a zero-maintenance weekly upgrade+reboot cronjob on my Alpine server. Obviously a bad idea but I just want to see how long it takes for something to break.

yjftsjthsd-h4• 3 years ago

Obviously a bad idea but I just want to see how long it takes for something to break.

That's not quite so obvious to me. First, I don't immediately recall ever having any problems resulting from upgrading within a release (i.e. if I'm on 3.16, I don't remember `apk upgrade` ever causing a problem, but going to 3.17 might). Second, it works on other distros - the Debian family treats https://wiki.debian.org/UnattendedUpgrades as a totally normal supported thing to do, and I don't think Alpine is noticeably less stable than them.

PhilipRoman4• 3 years ago

Oh yeah I should have clarified - I use the edge branch for this.

pxc2• 3 years ago

/etc/APK/world

[FTA:]

I was very pleased to learn about apk’s /etc/apk/world.
In essence, this file is a list of desired packages, and apk will install and uninstall packages so that the system state converges to the list. Exactly what I’d been looking for, but built right into the package manager. Actually it’s not just built into the package manager: it’s the very foundation of how it works. apk add actually adds a package to that list, and then installs any that are not present. apk del removes a package from that list, and only uninstalls it if it’s not a dependency for anything else.

This is fairly standard for how package managers work, afaik. From memory, Debian-based systems (in /var/lib/dpkg/status, IIRC) and Gentoo systems both work that way: constraints for the dependency solver (desired versions) are written to a persistent file in a plaintext format before the depsolver runs. In Gentoo's case, the language is also the same— the file is 'the world file' and it lives at /var/lib/portage/world.

I don't have an Arch system in front of me but I imagine it also stores its package selection database in a (perhaps compressed) plaintext format like this.

The novelty here is actually in encouraging users to edit the file directly by directing attention to it in the docs and by storing it under /etc, where one expects admin-facing configuration files.

Definitely an improvement over the norm on Linux, imo.

apt and pacman which have lots of sharp corners

I'd love to hear more about these!

mid-kid• 3 years ago

I'm not sure arch stores it in an explicit file, but pacman -Qe lists all explicitly installed packages, and anything not required will be listed in pacman -Qdt

Now, it is nice that "apk del" and such automatically takes care of removing unused packages, such that you never need an "autoremove" step or similar.

signa11• 3 years ago

> In essence, this file is a list of desired packages, and apk will install and uninstall packages so that the system state converges to the list. Exactly what I’d been looking for, but built right into the package manager. Actually it’s not just built into the package manager: it’s the very foundation of how it works. apk add actually adds a package to that list, and then installs any that are not present. apk del removes a package from that list, and only uninstalls it if it’s not a dependency for anything else.
This is fairly standard for how package managers work, afaik.

i don't think there is a similar concept as that of `/etc/apk/world` in archlinux. from the article it seems that it is a list of packages that i want, and then you let `apk` run its course, installing everything (and its dependencies) mentioned therein.

not sure about debian, but for gentoo `/var/lib/portage/world` see this: https://wiki.gentoo.org/wiki/Selected-packages_set_(Portage)... regarding editing that file by hand. it will be overwritten (and _aggresively_ at that)

nrclark• 3 years ago

Alpine is great, and I have nothing bad to say about it. I'm curious though: what sharp corners have you found with apt? I've been a Debian user for 20 years and I've never had any problems relating to apt/dpkg.

PhilipRoman4• 3 years ago

Never used pure Debian so I don't know how much of this is Ubuntu's fault but just today I had to fix a similar issue as described here: https://askubuntu.com/questions/1097066 Also the solution somehow ended up uninstalling the desktop environment. Still scratching my head over that one. It wasn't my own system though.

hawski• 3 years ago

For me personally apt is just annoyingly slow, but dnf is much worse. I've seen how fast APK is and I feel, that my distro of choice (Void) has a package manager (XBPS) that is maybe slightly slower than it.

I sometimes wonder if it is like that, because XBPS and APK were designed and built by C hackers while apt where done by system administrators maybe. With dnf/rpm I attribute it to this quirkiness I often feel diving into some of Red Hat's tech. Not trying to offend, just wondering and I acknowledge that I am biased.

zhala• 3 years ago

We do this regularly in production. We do biweekly container rebuilds, many running alpine and installing version unpinned packages. So far very few (if any) actual issues with that. We do of course do smoketests prior to promoting to production.

ed25519FUUU• 3 years ago

The first is that using a different libc helps finds bugs in programs that assume that every system uses glibc.

I praise the author for taking this work upon himself. As for me I don’t want anything to do with being a bug canary for other developers. I’ll take time tested and stable thank you.

sudobash12• 3 years ago

It depends on your usage. If you use software from the stable releases (not edge), then the testing should already be done for you. And with the rise of Docker/Podman containers, Alpine sees a lot of testing. Because of the simplicity and compactness mentioned in this article, it is very popular in Docker containers. So it has a very wide deployment and tons of testing going into it.

Personally, I value a lean and simple OS enough that I am willing to risk finding these bugs.

Alternatively, you can try Void Linux. It is similar, except that you can choose between a glibc or a musl install. I've not used it yet because it is rolling-release only and that doesn't fit with what I need it for currently.

zamadatix• 3 years ago

In the end many packages just aren't in the stable (or any) repo for that reason. If it's there you're golden, if it's not you're just kind of left hanging.

majou• 3 years ago

Here you're electing to remain on the happy but bloated path.

However sometimes it may be worth to venture out a bit in exchange for reducing code, or for using code that aligns more with your philosophies.

sudobash12• 3 years ago

Since Alpine uses musl and busybox, can we just call it "Linux" without the "Gnu/Linux" advocates contradicting? (I think we can all agree that calling it "Musl/Busybox/Linux" is too verbose for general conversation)

atahanacar3• 3 years ago

You can call any distro "Linux". Just because you're using GNU software doesn't mean you have to specify it every time you want to talk about your system. Although the best way in my opinion is using the distro's name + Linux.

moralestapia• 3 years ago

Maybe you're out of the loop but GNU fanatics always make a fuss about "Linux" without the GNU part.

maxloh• 3 years ago

It is hard to dodge GNU completely. Bash is developed by them.

from• 3 years ago

Default Alpine install uses ash, not bash. But they compile everything with gcc although they probably could substitute with clang at this point.

shaunsingh0207• 3 years ago

uutils or busybox instead of coreutils, musl, ash instead of bash (or really any non-gnu posix compliant shell, theres lots) and clang instead of gcc.

gray_-_wolf• 3 years ago

It is still built with gcc afaik. But in general you are free to call it whatever you want I guess.

zvr• 3 years ago

Does anyone have any news on the effort for a new APK format that includes license texts and copyright information? This is sorely needed to produce any re-distributable software, legally compliant with the open source licenses of the components.

A comment here last year (https://news.ycombinator.com/item?id=27113914) mentioned that the information would be available "in apk3", but I don't follow development to know whether this has been implemented already.

nathants• 3 years ago

the only real issue with alpine is there aren’t nvidia drivers yet.

i run alpine on my laptop and arch on my desktop. i wish it was alpine on both.

while there are minor differences moving from glibc to musl, and the odd failure to compile, it’s vastly overblown.

nektro• 3 years ago

trying to use anything nvidia on linux distros is gonna land you a bad time. it saves you too much headache not to use amd or intel for graphics

timw4mail• 3 years ago

Unless it's Arc (at least right now)

ryan_lane• 3 years ago

Does alpine have a proper security vulnerability reporting mechanism yet? One of the biggest issues with Alpine and APK is the general lack of security in the distro, which is especially painful given that one of the biggest reasons proponents say to use alpine is for security due to the smaller surface size. Surface size alone doesn't make you secure.

From what I can see, there still isn't any security contact listed. There's at least now a CVE tracker, but there's no stable package versions in alpine, which means you have to choose between upgrading everything and breaking, or keeping insecure packages around.

Debian may lead to larger images, but overall it's considerably more secure.

lonjil• 3 years ago

The regular stable Alpine releases sound like exactly what you're asking for? Packages in the main repo get 2 years of support.

kdeldycke• 3 years ago

I also tried having a meta-package, which has my “list of wanted packages” as dependencies, and then remove anything no required my it. Again, I needed extra scripts and complexity on top of the package manager itself.

I have something similar for my dotfiles, a list of packages, their manager and version in a TOML file: https://github.com/kdeldycke/dotfiles/blob/main/packages.tom...

I then feed this to meta-package-manager[1] to install:

    $ mpm restore ./packages.toml

[1] https://github.com/kdeldycke/meta-package-manager

majewsky• 3 years ago

I have a similar toolchain, fully using native system packages, built around Holo [1] as a config management tool and holo-build [2] as a distro-independent package building tool. In the intended state, the root configuration package (e.g. [3] for my desktop PC) is the only explicitly installed package on the system.

[1] https://holocm.org [2] https://github.com/holocm/holo-build [3] https://github.com/majewsky/system-configuration/blob/master...

dottedmag• 3 years ago

The general gist of "yes, but" comments in this thread and in the post itself is that not every application works.

This is true and real, and we as a community should stop saying "yeah, it's a weird distro". We should look at it and say "Alpine (and Gentoo, and Nix, and Arch, ...) is a separate OS". Closely related to the OSes of other Linux distributions, but still separate, because of a different ABI and API.

I have written about it here: https://dottedmag.net/blog/linux-is-not-os/

blueflow• 3 years ago

According due to the uname(1) manpages and the results of the -s and -r commands, i'm pretty sure that Linux IS the OS, and the rest of userspace isn't.

forty• 3 years ago

This /etc/apt/world system is pretty cool, I often wished apt would work this way.

With that said, I got some random DNS issues with alpine docker images apparently due limitations of musl, so I now avoid it, as saving a little disk space is not worth the hassle.

In Praise of Alpine and APK

Related Stories