Alpine Linux 3.13 • Hacker News Board

Re: Alpine Linux 3.13

#41

Post by hn_acc_2 » Thu, Jan 14, 2021, 9:38 PM UTC

turminal wrote: post #19

hn_acc_2 wrote: post #9

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] [1] https://pythonspeed.com/articles/alpine-docker-python/

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

Re: Alpine Linux 3.13

#42

Post by saagarjha » Thu, Jan 14, 2021, 9:44 PM UTC

nenolod wrote: post #25

akvadrako wrote: post #21

Earlier quoted context omitted.

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.

We have started to extend musl with optimized routines like glibc does. But really, the performance difference is usually minimal.

Is this something that you are planning to upstream? Or will it be local to Alpine?

Re: Alpine Linux 3.13

#43

Post by ossusermivami » Fri, Jan 15, 2021, 12:19 AM UTC

hn_acc_2 wrote: post #40

DiabloD3 wrote: post #13

Earlier quoted context omitted.

So just use the glibc compat layer, or also install glibc. 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.

Re: Alpine Linux 3.13

#44

Post by nenolod » Fri, Jan 15, 2021, 10:06 AM UTC

hn_acc_2 wrote: post #41

turminal wrote: post #19

Earlier quoted context omitted.

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

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.

Re: Alpine Linux 3.13

#45

Post by nenolod » Fri, Jan 15, 2021, 10:08 AM UTC

saagarjha wrote: post #42

nenolod wrote: post #25

Earlier quoted context omitted.

We have started to extend musl with optimized routines like glibc does. But really, the performance difference is usually minimal.

Is this something that you are planning to upstream? Or will it be local to Alpine?

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.

Re: Alpine Linux 3.13

#46

Post by stock_toaster » Sun, Jan 17, 2021, 10:30 PM UTC

gigel82 wrote: post #2

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).

Alpine is great as a docker _host_ too.

Re: Alpine Linux 3.13

#47

Post by vinniec » Thu, Jan 21, 2021, 11:51 PM UTC

nenolod wrote: post #4

gigel82 wrote: post #2

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 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.