4 ms·

I have heard that Alpine is really light on resources. Would it be practical for Rust, Node, Python projects in general? Or am I better off sticking with Ubuntu

by ilaksh 4y ago

I have heard that Alpine is really light on resources. Would it be practical for Rust, Node, Python projects in general? Or am I better off sticking with Ubuntu? I know that projects often have extra dependencies and I believe Ubuntu is still very good as far as those being easily available with the package manager. Or maybe about the same thing goes for Debian.

zitterbewegung 4y ago
You can also run Python in the browser https://www.anaconda.com/blog/pyscript-python-in-the-browser https://www.anaconda.com/blog/pyscript-python-in-the-browser
tyingq 4y ago
Aside from packaging, do also look into any potential issues with musl libc. It's fixed now, but the malloc in musl made Python noticably slower for some real world tasks roughly three years ago and earlier. This fixed it: https://git.musl-libc.org/cgit/musl/commit/?id=ea6d7847ac128f02d1f01ffd01e68341df34ac6e https://git.musl-libc.org/cgit/musl/commit/?id=ea6d7847ac128...
hardwaregeek 4y ago
I'd run it mostly for cloud projects that need to be lightweight. I just ran into a quite unpleasant issue with Alpine and Go where Go compiled as a shared library with musl cannot work in Alpine. In fact it segfaults and doesn't give any indication as to why it segfaults (the stack is even corrupted if you try to use gdb). You can read about it here: https://github.com/golang/go/issues/13492 https://github.com/golang/go/issues/13492 Of course one could argue that's mostly Go's fault...
minimaxir 4y ago
For code that compiles into a binary like Rust, distroless is another option for a minimal image that doesn't run into the compiling issues of Alpine. (Python and Node are supported but lose benefits rapidly depending on any added dependencies) https://github.com/GoogleContainerTools/distroless https://github.com/GoogleContainerTools/distroless
- mikepurvis 4y ago
  Just to clarify for anyone who isn't aware, the "compiling issues", at least historically, have been that Alpine uses musl, and PyPI's manylinux wheels are built against old glibc versions. So stuff like numpy that would trivially and quickly install from whl on glibc distros (like a bare-bones Ubuntu image) trigger compilations and the installation of build-only dependencies/toolchains on Alpine. That said, it looks like as of late-2021, at least some projects are offering musllinux wheels as well, per the discussion here: https://github.com/pypa/manylinux/issues/37 https://github.com/pypa/manylinux/issues/37 (not numpy yet, though: https://pypi.org/project/numpy/#files https://pypi.org/project/numpy/#files) Here's a longer version of the above, originally published in 2020, but with an update regarding PEP 656: https://pythonspeed.com/articles/alpine-docker-python/ https://pythonspeed.com/articles/alpine-docker-python/
  - NavinF 4y ago
    Ugh dynamic linking claims a few more victims
davidhay 4y ago
I've only used Alpine when creating containers with docker and has worked for me. Not sure about it being a daily driver though, prob best to stick with Ubuntu.
FinalBriefing 4y ago
I use it for Node all the time. There are published docker images with Alpine as the base and just Node and any required packages installed. I've had to manually install a handful of libraries to support image processing, or anything else that NPM might not install itself.
- horsawlarway 4y ago
  Same here. It's a great base image for node projects. the Node 19 release alpine image is ~175mb, the same release on debian (bullseye) is roughly 1gb (998mb). Still ~80MB smaller than the bullseye-slim release (247mb). --- That said - if the ask was for using it as a daily driver on a machine (primary OS), I'd probably still pick a more fully featured distro (ex: my daily driver is Arch, not Alpine). The available packages and tooling in Alpine aren't really geared towards daily use as an OS, although some folks definitely do it.
  - lxgr 4y ago
    Is it just me, or does this still seem about an order of magnitude larger than it reasonably needs to be? Given the size of Alpine itself (less than 10 MB, last time I checked), is it node that pulls in so much extra stuff, or something else?
    - horsawlarway 4y ago
      Node is about 60mb on it's own. Taking a peak at the official dockerfile for alpine node (https://github.com/nodejs/docker-node/blob/28ad5e0e5d0e80df44d897c9057ffd6419a3c7a5/19/alpine3.16/Dockerfile https://github.com/nodejs/docker-node/blob/28ad5e0e5d0e80df4...), they're also pulling in the following packages && apk add --no-cache --virtual .build-deps-full \ binutils-gold \ g++ \ gcc \ gnupg \ libgcc \ linux-headers \ make \ python3 My guess is the most weight is probably coming from linux-headers (~10mb), python3 (~50mb), and nodejs (~60mb). Plus 1 to 10 mb for each of the other pacakges, and you end up right there around 175mb.
thewataccount 4y ago
It's great for packaging a project in containers. The package management is actually pretty good specifically for anything server/service related, you just have to be a bit more hands on since it doesn't come with all of the bells and whistle dependencies. The only issue I've really had is libc vs musl for some of my dependencies. Its _tiny_ compared to ubuntu. I haven't looked at daily driving it because it doesn't feel like it's really meant for desktop use (although I'm sure it'll work), Something like arch makes more sense if you want something more lightweight while also having decent documentation and support for desktop use, and better packaging for things like chrome, vscode, etc. Especially because of musl I suspect you'll run into a lot of issues in general. EDIT: Also most images like python have alpine variants now which is really nice.
- KMnO4 4y ago
  > Also most images like python have alpine variants now which is really nice. You probably don’t want to use Alpine for Python containers. Many packages don’t provide wheels for Alpine (the Python version of prebuilt binaries), so you’ll have to build them from source, countering the space savings. You’re often better just using something like Debian-slim or something.
  - throwawaaarrgh 4y ago
    I would use whatever Alpine-y containers the official Python docker hub has, and switch to a Debian-based one if there are bugs. Building extra wheels isn't necessarily an issue, you can squash layers with a multistage build from scratch.
- rezonant 4y ago
  I hit some nasty segfaults in musl, with gRPC above it in the stack trace while doing some rather heavy YouTube API operations-- opted to switch to a glibc distribution rather than track down that mess. The segfaults were gone after that.
  - spyremeown 4y ago
guilhas 4y ago
Alpine is strong in package availability, but needs some manual work for a usable desktop. Also I did some browser benchmarks, uses less RAM but it's not noticeably faster and some situations slower You would be better trying Xubuntu, MX linux, NixOS...
- nazgulsenpai 4y ago
  Void Linux is also worth trying. It's lightweight, fast boot times with runit, stable rolling release, and a unique packaging system xbps. Comes with either glibc or musl.
qbasic_forever 4y ago
The big issue with alpine is that it uses musl libc instead of glibc. Python and other languages work just fine on it but the problem is when you install packages from pip, conda or other package managers, if those packages have binaries they're likely not compatible with musl libc and won't work. You have to find alpine-specific packages which can be difficult or annoying.
gtk40 4y ago
It doesn't use GNU at all which can break compatibility with a lot of software but is no big deal if the packages are available.
deleted 4y ago
[deleted]

by ilaksh 4y ago

zitterbewegung 4y ago

You can also run Python in the browser https://www.anaconda.com/blog/pyscript-python-in-the-browser https://www.anaconda.com/blog/pyscript-python-in-the-browser

tyingq 4y ago

Aside from packaging, do also look into any potential issues with musl libc. It's fixed now, but the malloc in musl made Python noticably slower for some real world tasks roughly three years ago and earlier. This fixed it: https://git.musl-libc.org/cgit/musl/commit/?id=ea6d7847ac128f02d1f01ffd01e68341df34ac6e https://git.musl-libc.org/cgit/musl/commit/?id=ea6d7847ac128...

hardwaregeek 4y ago

I'd run it mostly for cloud projects that need to be lightweight. I just ran into a quite unpleasant issue with Alpine and Go where Go compiled as a shared library with musl cannot work in Alpine. In fact it segfaults and doesn't give any indication as to why it segfaults (the stack is even corrupted if you try to use gdb). You can read about it here: https://github.com/golang/go/issues/13492 https://github.com/golang/go/issues/13492 Of course one could argue that's mostly Go's fault...

minimaxir 4y ago

For code that compiles into a binary like Rust, distroless is another option for a minimal image that doesn't run into the compiling issues of Alpine. (Python and Node are supported but lose benefits rapidly depending on any added dependencies) https://github.com/GoogleContainerTools/distroless https://github.com/GoogleContainerTools/distroless

mikepurvis 4y ago
Just to clarify for anyone who isn't aware, the "compiling issues", at least historically, have been that Alpine uses musl, and PyPI's manylinux wheels are built against old glibc versions. So stuff like numpy that would trivially and quickly install from whl on glibc distros (like a bare-bones Ubuntu image) trigger compilations and the installation of build-only dependencies/toolchains on Alpine. That said, it looks like as of late-2021, at least some projects are offering musllinux wheels as well, per the discussion here: https://github.com/pypa/manylinux/issues/37 https://github.com/pypa/manylinux/issues/37 (not numpy yet, though: https://pypi.org/project/numpy/#files https://pypi.org/project/numpy/#files) Here's a longer version of the above, originally published in 2020, but with an update regarding PEP 656: https://pythonspeed.com/articles/alpine-docker-python/ https://pythonspeed.com/articles/alpine-docker-python/
- NavinF 4y ago
  Ugh dynamic linking claims a few more victims

davidhay 4y ago

I've only used Alpine when creating containers with docker and has worked for me. Not sure about it being a daily driver though, prob best to stick with Ubuntu.

FinalBriefing 4y ago

I use it for Node all the time. There are published docker images with Alpine as the base and just Node and any required packages installed. I've had to manually install a handful of libraries to support image processing, or anything else that NPM might not install itself.

horsawlarway 4y ago
Same here. It's a great base image for node projects. the Node 19 release alpine image is ~175mb, the same release on debian (bullseye) is roughly 1gb (998mb). Still ~80MB smaller than the bullseye-slim release (247mb). --- That said - if the ask was for using it as a daily driver on a machine (primary OS), I'd probably still pick a more fully featured distro (ex: my daily driver is Arch, not Alpine). The available packages and tooling in Alpine aren't really geared towards daily use as an OS, although some folks definitely do it.
- lxgr 4y ago
  Is it just me, or does this still seem about an order of magnitude larger than it reasonably needs to be? Given the size of Alpine itself (less than 10 MB, last time I checked), is it node that pulls in so much extra stuff, or something else?
  - horsawlarway 4y ago
    Node is about 60mb on it's own. Taking a peak at the official dockerfile for alpine node (https://github.com/nodejs/docker-node/blob/28ad5e0e5d0e80df44d897c9057ffd6419a3c7a5/19/alpine3.16/Dockerfile https://github.com/nodejs/docker-node/blob/28ad5e0e5d0e80df4...), they're also pulling in the following packages && apk add --no-cache --virtual .build-deps-full \ binutils-gold \ g++ \ gcc \ gnupg \ libgcc \ linux-headers \ make \ python3 My guess is the most weight is probably coming from linux-headers (~10mb), python3 (~50mb), and nodejs (~60mb). Plus 1 to 10 mb for each of the other pacakges, and you end up right there around 175mb.

thewataccount 4y ago

It's great for packaging a project in containers. The package management is actually pretty good specifically for anything server/service related, you just have to be a bit more hands on since it doesn't come with all of the bells and whistle dependencies. The only issue I've really had is libc vs musl for some of my dependencies. Its _tiny_ compared to ubuntu. I haven't looked at daily driving it because it doesn't feel like it's really meant for desktop use (although I'm sure it'll work), Something like arch makes more sense if you want something more lightweight while also having decent documentation and support for desktop use, and better packaging for things like chrome, vscode, etc. Especially because of musl I suspect you'll run into a lot of issues in general. EDIT: Also most images like python have alpine variants now which is really nice.

KMnO4 4y ago
> Also most images like python have alpine variants now which is really nice. You probably don’t want to use Alpine for Python containers. Many packages don’t provide wheels for Alpine (the Python version of prebuilt binaries), so you’ll have to build them from source, countering the space savings. You’re often better just using something like Debian-slim or something.
- throwawaaarrgh 4y ago
  I would use whatever Alpine-y containers the official Python docker hub has, and switch to a Debian-based one if there are bugs. Building extra wheels isn't necessarily an issue, you can squash layers with a multistage build from scratch.
rezonant 4y ago
I hit some nasty segfaults in musl, with gRPC above it in the stack trace while doing some rather heavy YouTube API operations-- opted to switch to a glibc distribution rather than track down that mess. The segfaults were gone after that.
- spyremeown 4y ago

guilhas 4y ago

Alpine is strong in package availability, but needs some manual work for a usable desktop. Also I did some browser benchmarks, uses less RAM but it's not noticeably faster and some situations slower You would be better trying Xubuntu, MX linux, NixOS...

nazgulsenpai 4y ago
Void Linux is also worth trying. It's lightweight, fast boot times with runit, stable rolling release, and a unique packaging system xbps. Comes with either glibc or musl.

qbasic_forever 4y ago

The big issue with alpine is that it uses musl libc instead of glibc. Python and other languages work just fine on it but the problem is when you install packages from pip, conda or other package managers, if those packages have binaries they're likely not compatible with musl libc and won't work. You have to find alpine-specific packages which can be difficult or annoying.

gtk40 4y ago

It doesn't use GNU at all which can break compatibility with a lot of software but is no big deal if the packages are available.

deleted 4y ago

[deleted]