Hacker News Reader

Comment by ilaksh | Hacker News Reader

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.

View on HN

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.

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

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.

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.

I was doing some very similar things (gRPC with Alpine containers) and also had the segfault things. `gcompat` solved all of them.

ooh good to know in a pinch

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

Many people use it on desktops. Also many people use postmarketOS (phone-specific packages on top of Alpine repos) on phones.

It’s probably a bad idea to use this for your desktop, since Alpine isn’t particularly performance-focused.

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.

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

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 (not numpy yet, though: 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/

Ugh dynamic linking claims a few more victims

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.

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.

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?

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

Why does a minimal nodejs 19 distro need python3 ?

My understanding is that it’s because of node-gyp, used to build native addon modules for Node.js.

Yeah, I looked again and it looks like they're actually only pulling those packages in when they need to build node for the current ARCH. (that's what I get for just scanning to the first call to apk add)

They also appear to be cleaning them up, so I'm not actually sure where all that extra weight is coming from.

Node itself is fairly trimmed down in the packages for alpine (40MB installed), but they're not using that package, they're pulling in their own version from their download sources - so it's possible they're including a lot of extra junk there. They also add yarn which is another 10mb.

But in general - I agree, there's about 100mb of weight I can't actually explain in that image from a very quick look.

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

Of course one could argue that's mostly Go's fault...

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.

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

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

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.

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

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.

Reply on news.ycombinator.com