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.
LeFantome 5 hours ago [-]
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.
m463 1 hours ago [-]
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.
jfim 5 hours ago [-]
Out of curiosity, what are the reasons for using Alpine as opposed to something more mainstream like say Ubuntu?
LeFantome 5 hours ago [-]
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.
rthnbgrredf 9 hours ago [-]
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.
Imustaskforhelp 6 hours ago [-]
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.
2 hours ago [-]
LeFantome 5 hours ago [-]
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.
taid9iK- 4 hours ago [-]
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?
WhyNotHugo 15 hours ago [-]
Minor correction: if you like DRM, Firefox has recently been patched to run widevine with gcompat (although it remains disabled by default).
ysleepy 16 hours ago [-]
A little rambling, I wasn't able to take away anything tangible.
I wish them a lot of fun exploring though.
LeFantome 5 hours ago [-]
> 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?
mvdtnz 15 hours ago [-]
What's "musl"? This article doesn't seem to define it, unless I missed it.
TheAdamist 13 hours ago [-]
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).
hoosieree 12 hours ago [-]
I found building musl easier than uClibc, Xephyr, newlib, or (especially) glibc. Glibc is an Ouroboros of hacks at build time.
pjmlp 12 hours ago [-]
Also a good example of what happens when trying to write portable C code, even when constrained to UNIX/POSIX platforms.
In practice it means that the executable format is different, that binaries from GNU/Linux won't run on Alpine normally and reverse.
kees99 14 hours ago [-]
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).
blueflow 13 hours ago [-]
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.
"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")
ktallett 17 hours ago [-]
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.
casparvitch 16 hours ago [-]
The MNT SoC (etc) drivers are still not up upstreamed, so think you're stuck on debian for a while
pinsl 15 hours ago [-]
Yes, but you could also build a custom kernel. This mastodon post talks about alpine on the mnt reform [0].
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.
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.
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.
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 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
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.
If POSIX compliance and Glibc compatibility were the same thing, it would not be a problem.
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?
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).
If you like to copy statically linked binaries between musl and glibc systems, some day you will learn about libnss.
"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...
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")
[0] https://hj.9fs.net/khm/p/1750378257.144987