I want to like Alpine because it's so light, but realistically you can only ever use it in Docker / VMs or for very specific locked-down needs.
The musl libc makes it a bad choice for general purpose desktop use (look at the number of hacks required to get some version of VSCode running on it for example).
After this message from you, I proceeded to update alpine to have a more recent version of gcompat available and to try to start some programs compiled with glibc.
I haven't tried many things, but all the tests failed except with "powder" ( http://www.zincland.com/powder/release/powder118_linux.tar.g... ) which actually starts after installing the gcompat package.
The thing is very interesting because actually I would like to try to use vscode on alpine, I wanted to try the "appimage" version (https://github.com/VSCodium/vscodium/releases/download/1.52..... glibc2.16-x86_64.AppImage) but I could not start any appimage in my tests.
If you have more information, I'm curious, even if I'm quite noob.
On the contrary, we ship Alpine with iSH because it’s so small by default. This keeps our app size down to just a few MB-which is not bad, IMO, for something that gives you most of POSIX on your iPhone :)
I think it totally makes sense that a minimal distro optimized for containers should be a different project from a minimal distro optimized for desktop use.
Off the top of my head, Tiny Core Linux uses glibc and has desktop users as a primary goal.
musl is also sometimes much slower than glib, for example with some scripting languages. Even when your workload is compatible it's usually a good idea to use another distro in your docker container.
When performance doesn't matter I think it's great though.
That activity is being driven in musl directly. 1.2 has introduced optimizations for arm, aarch64, x86 and x86_64. there's more to optimize, but some are already there.
I use Alpine as my daily driver on desktops, and in production on bare metal servers (and in production VMs). musl libc is much easier to debug and understand, which pays off in spades regardless of compatibility with broken (i.e. non-portable) programs. The system is exceptionally stable and reliable, which I care about very much. It's also simple, in that it does everything I ask it to, and nothing I don't ask it to. I can fit the entire system in my head.
I use Vim as my editor, and yes, programmers who value bloated, un-Unixy tools like VSCode will not find the system accomodating.
I would love for Alpine to progress to the point where it's a realistic desktop or server OS, rather than the OS for the containers that run on an Ubuntu or Debian server.
Edit: Just got inspired and went to the contributing page.
Think I'll start using it to develop with Vim in a VM locally and see where things go from there.
I'm one of the maintainers of the cloud images and I can confirm that our goal is to release at least GCP and Azure images in addition to the AWS ones for the 3.14 release cycle. We're also looking for suggestions on other cloud providers for which people would like to see official Alpine images built.
An important philosophy to adopt as a user of Alpine is to take responsibility for the software you want to use on it. If you need a particular window manager or desktop environment, take responsibility for packaging it and making it available. The value of Alpine has little to do with package availability, and it's easy enough to package up anything you need yourself.
Alpine Linux is a system which appeals to those who want to know how their system works (and to be responsible for it as such). If you don't want to know how your system works, and don't want to be responsible for it, then much of Alpine's value proposition is lost compared to other distros.
Building up to a usable desktop in Alpine is a good way to start gaining some of that knowledge.
I had a laptop for a while that I built up from alpine-extended to a pretty nice side machine, complete with Sway, vim, Rust, Firefox, and a couple others.
Another "I want to love Alpine but can't" user here.
Their use of musl libc makes it a very poor choice for running python in a container, because it forces a lot of manual rebuilding since the PyPi wheels don't work on Alpine, among other issues [1]
If you ask me, installing glibc / compat layers defeats the purpose of using Alpine, especially since Alpine ultimately only saved me ~50 MB on image size versus a similarly configured debian:slim-buster image
I believe Alpine isn't meant to be used with pip, npm, and the like. Instead you are encouraged to create alpine packages out of your dependecies and submit them upstream. Writing a new package is completely trivial in Alpine, that's one of the things that made me switch to it.
Given the popularity of Alpine it is important to update images as soon as possible given how many significant updates are there. Services like [1] help a lot for that...
Just a heads up to anyone using wireguard on Alpine: wireguard is now included in the kernel, so you'll want to uninstall the wireguard-lts package when you update to 3.13. Otherwise your kernel won't be upgraded and any other packages with modules (e.g. zfs) will break.
46 comments
[ 2.8 ms ] story [ 107 ms ] threadThe musl libc makes it a bad choice for general purpose desktop use (look at the number of hacks required to get some version of VSCode running on it for example).
But yeah I would like to use it on the desktop as well..
Off the top of my head, Tiny Core Linux uses glibc and has desktop users as a primary goal.
When performance doesn't matter I think it's great though.
I use Vim as my editor, and yes, programmers who value bloated, un-Unixy tools like VSCode will not find the system accomodating.
Using pre-built proprietary applications is the only thing that requires a little trickery.
I imagine vscode could be built and packaged just fine if someone wanted to.
Edit: Just got inspired and went to the contributing page.
Think I'll start using it to develop with Vim in a VM locally and see where things go from there.
It's not an option for which OS to flash onto my DigitalOcean VM. Getting it going on Raspberry Pi is largely undocumented.
For desktop, it doesn't (officially) support many window managers or desktops.
It is hoped that the cloud images project will get Alpine available in all of the main platforms, we've done AWS already starting with 3.13.
I am tempted to go try it on AWS, but I am sticking to DigitalOcean for personal projects for reasons. I will be very happy when it shows up on DO.
https://github.com/mcrute/alpine-ec2-ami/issues/99
I had a laptop for a while that I built up from alpine-extended to a pretty nice side machine, complete with Sway, vim, Rust, Firefox, and a couple others.
Their use of musl libc makes it a very poor choice for running python in a container, because it forces a lot of manual rebuilding since the PyPi wheels don't work on Alpine, among other issues [1]
[1] https://pythonspeed.com/articles/alpine-docker-python/
https://wiki.alpinelinux.org/wiki/Running_glibc_programs
https://access.redhat.com/documentation/en-us/red_hat_enterp...
Pretty small and has most of the things i need :
Minimal images are about 92M on disk and 32M compressed. This makes it less than half the size of the standard images.
Now we add additional complication "OK, these pip package authors have upstreamed Alpine packages, and these other ones are only on PyPi".
Maybe this approach would work if you can keep your Python dependencies to a small list of well-maintained packages
[1] https://newreleases.io
No big issues so far and I am in the process of migrating my home server to Alpine.