Alpine Linux 3.13(alpinelinux.org)
alpinelinux.org
Alpine Linux 3.13
https://alpinelinux.org/posts/Alpine-3.13.0-released.html
46 comments
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.
Unfortunately the Python package ecosystem is enough of a headache.
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
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
The good news is that there is work in progress to untangle the mess with PyPI wheels and musl. But it is easy enough to just not use wheels.
They do work, though.
So just use the glibc compat layer, or also install glibc.
https://wiki.alpinelinux.org/wiki/Running_glibc_programs
https://wiki.alpinelinux.org/wiki/Running_glibc_programs
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 use UBI minimal docker image from redhat which is based on RHEL but free from license :
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.
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.
this page really should be updated, at this point all you basically have to do is `apk add gcompat`.
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.
thanks!
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).
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).
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 :)
VScode as a piece of software is profoundly incompatible with the philosophy of Alpine so this isn't too surprising.
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 use Vim as my editor, and yes, programmers who value bloated, un-Unixy tools like VSCode will not find the system accomodating.
The gcompat project, which provides a wine-like compatibility layer for glibc applications, is pretty close to having vscode working out of the box.
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.
I run Alpine on bare metal as my home server, very happy with it. I do run Ubuntu on my laptop/desktop.
Alpine works quite well as a desktop OS.
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.
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.
You can install Alpine on the host and then use Alpine images in Docker on Alpine. :D (that's how I do it)
But yeah I would like to use it on the desktop as well..
But yeah I would like to use it on the desktop as well..
For me the best alternative is Void Linux. It is still very
lightweight and without unnecessary clutter, but more pleasant
to use on a desktop.
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.
When performance doesn't matter I think it's great though.
We have started to extend musl with optimized routines like glibc does. But really, the performance difference is usually minimal.
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.
Off the top of my head, Tiny Core Linux uses glibc and has desktop users as a primary goal.
Alpine is great as a docker _host_ too.
Recently, I migrated my personal dev laptop from Ubuntu to Alpine Linux. It took a day, but everything works now, including hidpi stuff.
No big issues so far and I am in the process of migrating my home server to Alpine.
No big issues so far and I am in the process of migrating my home server to Alpine.
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.
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 had to install glibc last time I tried Alpine as desktop distribution, so
What is it missing that makes you feel it is unrealistic?
I am thinking more about adoption - and things that come with adoption - than functionality.
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'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.
On desktop, we support KDE, GNOME and Xfce, which are the big ones, but yes, we could use more work there.
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.
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'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.
https://github.com/mcrute/alpine-ec2-ami/issues/99
https://github.com/mcrute/alpine-ec2-ami/issues/99
Thanks for your response!
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.
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.
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.
I feel I am far from enough Linux knowledge to contribute, but I am inspired to get there.
If you don't mind using IRC, there's a lot of people willing to help you get started with this adventure in #alpine-devel on freenode.
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.
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.
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.
Who stays behind Alpine?
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...
[1] https://newreleases.io
[1] https://newreleases.io
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/