My 2 cents. I have been using Alpine Linux as my main Linux distro for... I don't know how long, but probably more than 5 years at this point.
My only issues have been:
* Nvidia proprietary drivers (when I was building a PC with an old GPU).
* DRM (Netflix).
* I think I also had problems with SQLite3 while trying to install the Twitch test server thingy inside an Alpine container.
Other than that it's just minor things, just like every distro has some things that are different but no big deal.
> I think that, if you have a very consistent usage of Alpine, where you are mostly doing the same thing and using the same tools, you could find a comfy workflow there.
Yeah, or in my case it's because I try to keep the host minimalist and clean, and do most of the dirty/experimentation stuff in Docker, just to be able to nuke it from orbit once I'm done.
It's also dumbproof to make your own native packages if you want, for example if you want to use fonts but you can't just `git clone` because they require a build step (!).
Apparently some people have had issues with DNS, but I've never had any. I don't know if it's because I always point to my Unbound instance for DNS, or if it's just been a coincidence.
Agreed. I find it quite rare to find something that does not build on MUSL. When I do, it is software that goes out of its way to abuse GNU specific stuff.
The most common problem for me is software distributed as binary that links to Glibc. That shows up on surprise places. For example, building the Ladybird browser uses vcpkg which needs Glibc. In these cases, I reach for Distrobox.
Pretty sure the DNs behaviour in MUSL was changed and is no longer an issue.
But I think it all began with disliking systemd and at the same time being obsessed with ricing and minimalism. Tiling window managers, simple terminals, LuaKit as a web browser (!), stuff like that.
Back then I was young and had very strong opinions, and also had the time to be switching OS whenever I wanted, and apparently I didn't mind setting up stuff again and again (ugh). My first choice was actually Artix Linux, but it broke at some point. I was already using Alpine Linux and FreeBSD in VPSs (Linode and Digital Ocean respectively), and they were still working fine so they seemed stable enough, so I started experimenting with installing FreeBSD locally and just setting up i3wm on it (also Poudriere got me curious about compiling packages by myself with only the flags I needed). Then when I got a laptop I went with Alpine Linux there, it was already a minimal distro that I was familiar with, so if I could get i3wm working there it should be good enough.
And I have survived with them so far with no reason to change, so it's probably just coincidence that I was using Alpine Linux (and FreeBSD) when I decided to "settle down".
But like I said, today it's mostly inertia, just a personal preference thing like buying Ketchup from a specific brand whenever possible because I'm most used to how this one tastes but no big deal if it's not available. It hasn't given me any surprises or any annoyances big enough for me to seriously consider switching.
I do have Linux Mint on a third[1] computer tho, mostly for Steam, but ready to be quickly repurposed in case of any surprises.
I still have some leftover dislike of systemd and its scope creep, but it's not a religious dislike like back then; today it's similar to a "why does this website have 20MB of JavaScript just to show text and why does it ask for my location"-kind of dislike, but back then was like "the GNU Project declaring war against any software that doesn't use specifically a GNU license even if that software has an OSI-approved license"-kind of dislike. Recently when I used Hetzner for some stuff and found out they don't have Alpine Linux or FreeBSD as (easy) choices, I was like "oh well, Fedora it is".
So yeah, there you have it.
[1]: Why a third computer? Well, you can thank two spicy pillow incidents for that. Don't buy Medion laptops.
> I really wish, though, that package managers were more capable of differentiating between security and feature upgrades. If they were, we could run a rolling distro in “Debian mode” at will.
This is exactly the sweet spot that Gentoo hits for me. The default configuration will install only "stable" packages, which are bumped ASAP for security reasons, but you're always free to switch a selection of (or all packages) to their "unstable" variants. Thanks to its source compiled nature, doing this is never a "partial upgrade", and is very well supported. Even if you use Gentoo as a binary distribution, portage is extremely meticulous in ensuring version compatibility.
And Gentoo can also be based on musl (experimental). I tried it for a while on a SBC, but arm (32bit) is not well supported in Gentoo and musl on arm is almost unusable, like ... completely abandoned.
I think it could be worthwhile to fork Alpine and maintain a glibc variant. That way we would keep nearly all of Alpine’s advantages while avoiding the drawbacks of musl.
I think that I am using something which is essentially https://zapps.app where I can just give it a glibc app and it would give me a folder structure with all the dependencies which I feel like might be similar to nix in only that sense (and not reproducibility or language)
I recently tried to run it in alpine after seeing this blog post and here's what I can say. If you lets say have debian or something or any system where any binary might work, run the script and then it would output a folder/tar and then you can move it anywhere and run it including alpine.
I am thinking of creating an article. But in the meanwhile I have created an asciinema gif to show you guys what I mean. Open to feedback as always.
Very interesting. Thank you. I run Chimera Linux which is also MUSL based, so I have the same issue raised in this article.
I mostly consider it a non-issue because I use Distrobox. An Arch Distrobox gives me access to all the Arch software including the AUR. Graphical apps can even be exported to my desktop launcher. They are technically running on a container but I just click on them like anything else and they show up in their own Wayland window just like everything else. Or, I can run from the command line, including compiling on top of Glibc if I want/need to. And keeping everything up to day just means running yay or pacman.
I can see the advantage of Zapps in some cases though, especially for CLI stuff. Very cool.
What are the disadvantages of musl? It is really just compatibility with Glibc. But the only reason we say that instead of saying that Glibc is incompatible with musl is because of popularity.
If POSIX compliance and Glibc compatibility were the same thing, it would not be a problem.
I use a different MUSL-based distro and do not find it an issue. A bigger problem on Alpine for me would be the limited package selection. In both cases, the solution for me would be Distrobox.
I tend to install an Arch Distrobox but Debian would work too. Both have massive software repos all running on Glibc. Anything not natively in the Alpine repos can be installed from the Distrobox repo instead. If it is a command-line app, it is just opening a terminal and typing. And GUI apps can be exported to the host app launcher where they launch and run normally.
I guess there is some “friction” but it is very minor. And if you like the distro otherwise, the overall experience is net positive.
Personally, I dislike Glibc. I am happier without it. And, when I have to use it, I can easily.
I find the "overly detailed rundown" laying out the decision process great!
I think I have similar feelings about tweaking my own machines vs setting one up for others, but I do not share the sentiment about systemd and especially Arch.
> I really wish, though, that package managers were more capable of differentiating between security and feature upgrades. If they were, we could run a rolling distro in “Debian mode” at will.
I missed his point here. Isn’t that what Debian Stable is? It is not like you do not get any updates in Debian. It is just that they are all security updates that do mot often bring new features. How is that different from what he is asking for?
I've generally seen it for embedded systems due to smaller size and you can statically link it.
But there are some compatibility drawbacks for non musl binaries as well as source that intentionally or unintentionally relies on glibc behavior or non standard functionality.
You don't want to mix and match your libc's on a running system.
Buildroot may be a good way to start to play with musl (or uClibc, another small c library).
Binary executable format is the same. But libc and dl (dynamic loader) libraries are different. You can install musl-specific versions of both on Debian, for example, like so:
apt install musl
Binaries that don't use libraries, i.e. complied with "-static" option on GNU/Linux run just fine on musl/Linux (and vice versa).
"Alpine Linux is good candidate, as Glibc static compilation is broken for political purposes, and Musl Libc allows static compilation."
"The GCC/Linux developer community is sold on shared library executables. They like shared libraries due to the reduced memory and disk footprints, as well as the concept that upgrading one shared library eventually automatically upgrades all applications which use that library. Consequently, information on statically linked programs is rather sparse."
I wasn't trying to copy binaries over but I found a very specific thing that doesn't work with musl and libnss. System Services Security Daemon (sssd) which coupled with authentik would have made automated ssh logins on remote servers a manageable thing cannot work on alpine. It does work on Void which made me think they must have solved the musl situation but no, apparently Void has a glibc variant and it only works there.
https://github.com/rustadopt/uzers-rs/issues/20 ("Now the bad news: I poked around a bit and believe the problem is that MUSL does not support sideloading the NSS plugins needed to retrieve things from SSSD like GLIBC does and thus does only ever read users from /etc/passwd, see: SSSD/sssd#6586")
This is really interesting as I have been looking at a way of going GUI free on an MNT Pocket Reform but still able to use the things I need; markdown,python and julia editing, plus uploading to dropbox using maestral, and the occasional diagram creation. It is the latter that is letting me down at the moment as I would prefer to not have to ssh in.
My 2 cents. I have been using Alpine Linux as my main Linux distro for... I don't know how long, but probably more than 5 years at this point.
My only issues have been:
* Nvidia proprietary drivers (when I was building a PC with an old GPU).
* DRM (Netflix).
* I think I also had problems with SQLite3 while trying to install the Twitch test server thingy inside an Alpine container.
Other than that it's just minor things, just like every distro has some things that are different but no big deal.
> I think that, if you have a very consistent usage of Alpine, where you are mostly doing the same thing and using the same tools, you could find a comfy workflow there.
Yeah, or in my case it's because I try to keep the host minimalist and clean, and do most of the dirty/experimentation stuff in Docker, just to be able to nuke it from orbit once I'm done.
It's also dumbproof to make your own native packages if you want, for example if you want to use fonts but you can't just `git clone` because they require a build step (!).
Apparently some people have had issues with DNS, but I've never had any. I don't know if it's because I always point to my Unbound instance for DNS, or if it's just been a coincidence.
Agreed. I find it quite rare to find something that does not build on MUSL. When I do, it is software that goes out of its way to abuse GNU specific stuff.
The most common problem for me is software distributed as binary that links to Glibc. That shows up on surprise places. For example, building the Ladybird browser uses vcpkg which needs Glibc. In these cases, I reach for Distrobox.
Pretty sure the DNs behaviour in MUSL was changed and is no longer an issue.
and I thought arch was minimalist.
You're like a long-term classic-era-john-deere minimalist.
Personally I use it in multistage dockerfiles for when I do things like wget or file manipulation.
Out of curiosity, what are the reasons for using Alpine as opposed to something more mainstream like say Ubuntu?
Nowadays it's mostly inertia.
But I think it all began with disliking systemd and at the same time being obsessed with ricing and minimalism. Tiling window managers, simple terminals, LuaKit as a web browser (!), stuff like that.
Back then I was young and had very strong opinions, and also had the time to be switching OS whenever I wanted, and apparently I didn't mind setting up stuff again and again (ugh). My first choice was actually Artix Linux, but it broke at some point. I was already using Alpine Linux and FreeBSD in VPSs (Linode and Digital Ocean respectively), and they were still working fine so they seemed stable enough, so I started experimenting with installing FreeBSD locally and just setting up i3wm on it (also Poudriere got me curious about compiling packages by myself with only the flags I needed). Then when I got a laptop I went with Alpine Linux there, it was already a minimal distro that I was familiar with, so if I could get i3wm working there it should be good enough.
And I have survived with them so far with no reason to change, so it's probably just coincidence that I was using Alpine Linux (and FreeBSD) when I decided to "settle down".
But like I said, today it's mostly inertia, just a personal preference thing like buying Ketchup from a specific brand whenever possible because I'm most used to how this one tastes but no big deal if it's not available. It hasn't given me any surprises or any annoyances big enough for me to seriously consider switching.
I do have Linux Mint on a third[1] computer tho, mostly for Steam, but ready to be quickly repurposed in case of any surprises.
I still have some leftover dislike of systemd and its scope creep, but it's not a religious dislike like back then; today it's similar to a "why does this website have 20MB of JavaScript just to show text and why does it ask for my location"-kind of dislike, but back then was like "the GNU Project declaring war against any software that doesn't use specifically a GNU license even if that software has an OSI-approved license"-kind of dislike. Recently when I used Hetzner for some stuff and found out they don't have Alpine Linux or FreeBSD as (easy) choices, I was like "oh well, Fedora it is".
So yeah, there you have it.
[1]: Why a third computer? Well, you can thank two spicy pillow incidents for that. Don't buy Medion laptops.
> I really wish, though, that package managers were more capable of differentiating between security and feature upgrades. If they were, we could run a rolling distro in “Debian mode” at will.
This is exactly the sweet spot that Gentoo hits for me. The default configuration will install only "stable" packages, which are bumped ASAP for security reasons, but you're always free to switch a selection of (or all packages) to their "unstable" variants. Thanks to its source compiled nature, doing this is never a "partial upgrade", and is very well supported. Even if you use Gentoo as a binary distribution, portage is extremely meticulous in ensuring version compatibility.
And Gentoo can also be based on musl (experimental). I tried it for a while on a SBC, but arm (32bit) is not well supported in Gentoo and musl on arm is almost unusable, like ... completely abandoned.
I think it could be worthwhile to fork Alpine and maintain a glibc variant. That way we would keep nearly all of Alpine’s advantages while avoiding the drawbacks of musl.
I think that I am using something which is essentially https://zapps.app where I can just give it a glibc app and it would give me a folder structure with all the dependencies which I feel like might be similar to nix in only that sense (and not reproducibility or language)
I recently tried to run it in alpine after seeing this blog post and here's what I can say. If you lets say have debian or something or any system where any binary might work, run the script and then it would output a folder/tar and then you can move it anywhere and run it including alpine.
I am thinking of creating an article. But in the meanwhile I have created an asciinema gif to show you guys what I mean. Open to feedback as always.
https://asciinema.org/a/qHGHlU0o4V7VgyyWxtHY2PG5Y
Very interesting. Thank you. I run Chimera Linux which is also MUSL based, so I have the same issue raised in this article.
I mostly consider it a non-issue because I use Distrobox. An Arch Distrobox gives me access to all the Arch software including the AUR. Graphical apps can even be exported to my desktop launcher. They are technically running on a container but I just click on them like anything else and they show up in their own Wayland window just like everything else. Or, I can run from the command line, including compiling on top of Glibc if I want/need to. And keeping everything up to day just means running yay or pacman.
I can see the advantage of Zapps in some cases though, especially for CLI stuff. Very cool.
What are the disadvantages of musl? It is really just compatibility with Glibc. But the only reason we say that instead of saying that Glibc is incompatible with musl is because of popularity.
If POSIX compliance and Glibc compatibility were the same thing, it would not be a problem.
I use a different MUSL-based distro and do not find it an issue. A bigger problem on Alpine for me would be the limited package selection. In both cases, the solution for me would be Distrobox.
I tend to install an Arch Distrobox but Debian would work too. Both have massive software repos all running on Glibc. Anything not natively in the Alpine repos can be installed from the Distrobox repo instead. If it is a command-line app, it is just opening a terminal and typing. And GUI apps can be exported to the host app launcher where they launch and run normally.
I guess there is some “friction” but it is very minor. And if you like the distro otherwise, the overall experience is net positive.
Personally, I dislike Glibc. I am happier without it. And, when I have to use it, I can easily.
I find the "overly detailed rundown" laying out the decision process great!
I think I have similar feelings about tweaking my own machines vs setting one up for others, but I do not share the sentiment about systemd and especially Arch.
What cultural issues could there be?
Minor correction: if you like DRM, Firefox has recently been patched to run widevine with gcompat (although it remains disabled by default).
A little rambling, I wasn't able to take away anything tangible. I wish them a lot of fun exploring though.
> I really wish, though, that package managers were more capable of differentiating between security and feature upgrades. If they were, we could run a rolling distro in “Debian mode” at will.
I missed his point here. Isn’t that what Debian Stable is? It is not like you do not get any updates in Debian. It is just that they are all security updates that do mot often bring new features. How is that different from what he is asking for?
He wants the option of switching out of Debian mode in order to get new packages that aren't just security updates.
What's "musl"? This article doesn't seem to define it, unless I missed it.
Its an alternative libc instead of gnu.
I've generally seen it for embedded systems due to smaller size and you can statically link it.
But there are some compatibility drawbacks for non musl binaries as well as source that intentionally or unintentionally relies on glibc behavior or non standard functionality.
You don't want to mix and match your libc's on a running system.
Buildroot may be a good way to start to play with musl (or uClibc, another small c library).
I found building musl easier than uClibc, Xephyr, newlib, or (especially) glibc. Glibc is an Ouroboros of hacks at build time.
Also a good example of what happens when trying to write portable C code, even when constrained to UNIX/POSIX platforms.
https://wikipedia.org/wiki/Musl
In practice it means that the executable format is different, that binaries from GNU/Linux won't run on Alpine normally and reverse.
Binary executable format is the same. But libc and dl (dynamic loader) libraries are different. You can install musl-specific versions of both on Debian, for example, like so:
Binaries that don't use libraries, i.e. complied with "-static" option on GNU/Linux run just fine on musl/Linux (and vice versa).I did not feel to do a lecture about vdso's, dynamic linking and interpreters to a person who had to ask about musl.
If you like to copy statically linked binaries between musl and glibc systems, some day you will learn about libnss.
http://stalinux.wikidot.com/
"Alpine Linux is good candidate, as Glibc static compilation is broken for political purposes, and Musl Libc allows static compilation."
"The GCC/Linux developer community is sold on shared library executables. They like shared libraries due to the reduced memory and disk footprints, as well as the concept that upgrading one shared library eventually automatically upgrades all applications which use that library. Consequently, information on statically linked programs is rather sparse."
https://web.archive.org/web/20170306062400/http://www.static...
I wasn't trying to copy binaries over but I found a very specific thing that doesn't work with musl and libnss. System Services Security Daemon (sssd) which coupled with authentik would have made automated ssh logins on remote servers a manageable thing cannot work on alpine. It does work on Void which made me think they must have solved the musl situation but no, apparently Void has a glibc variant and it only works there.
Interestingly there is an sssd package in alpine but it cannot work. https://gitlab.alpinelinux.org/alpine/aports/-/issues/16969
https://github.com/rustadopt/uzers-rs/issues/20 ("Now the bad news: I poked around a bit and believe the problem is that MUSL does not support sideloading the NSS plugins needed to retrieve things from SSSD like GLIBC does and thus does only ever read users from /etc/passwd, see: SSSD/sssd#6586")
This is really interesting as I have been looking at a way of going GUI free on an MNT Pocket Reform but still able to use the things I need; markdown,python and julia editing, plus uploading to dropbox using maestral, and the occasional diagram creation. It is the latter that is letting me down at the moment as I would prefer to not have to ssh in.
The MNT SoC (etc) drivers are still not up upstreamed, so think you're stuck on debian for a while
Yes, but you could also build a custom kernel. This mastodon post talks about alpine on the mnt reform [0].
[0] https://hj.9fs.net/khm/p/1750378257.144987
[dead]