Praise for Alpine Linux | Hacker News Reader

Praise for Alpine Linux

portal.drewdevault.com

134 pointsTomte90 comments

> In terms of simplicity, Alpine Linux is unpeered. Alpine is the only Linux distribution that fits in my head. The pieces from which it is built from are simple, easily understood, and few in number, and I can usually predict how it will behave in production. The software choices, such as musl libc, are highly appreciated in this respect as well, lending a greater degree of simplicity to the system as a whole.

Is there a guide to how Alpine is architected and put together? From this description it sounds like it could be a pretty interesting intro to how a basic Linux distro operates.

It depends on the level of familiarity you have with Linux distros. Alpine is simple, but it might be a bit hard to understand without first understand what each component does (e.g., initramfs, GRUB). In that case, installing a Linux distro via chroot method and get it up running as a desktop might be a better place to start. Alpine simplicity would makes sense after then.

Otherwise, I'd recommend installing Alpine in a VM and play with it for a week. On a lower level, alpine-base[1], alpha-baselayout[2], and alpine-conf[3] might be a point of interest. alpine-conf contains several scripts for bootstrapping the entire system (e.g. setup-disk/setup-bootable/update-kernel). Following what these scripts does can get very far into understanding how a distro is put together.

[1]: https://git.alpinelinux.org/aports/tree/main/alpine-base/APK...

[2]: https://git.alpinelinux.org/aports/tree/main/alpine-baselayo...

[3]: https://git.alpinelinux.org/alpine-conf/tree/

As much as I like Alpine Linux, I think Void Linux is similar in its simplicity, but having Glibc/coreutils flavor is making things easy. In principle I would prefer to run Alpine, but Void is more practical for my use-cases.

Do they publish an image thats suitable for a docker base?

I wonder why alpine became he defacto super slim base image over void?

I'm not that much into docker other than a user of an image for work, so I'm not sure what constitutes an image suitable for a docker base. They do publish a couple of images on docker hub: https://hub.docker.com/r/voidlinux/voidlinux/tags (latest is 41.52MB) and https://hub.docker.com/r/voidlinux/voidlinux-musl/tags (latest is 26.55MB).

Latest Alpine for comparison is 10 times smaller then void-musl. From what I remember Alpine by default is just smaller and more granular. If you really want to cut things down I'm sure Alpine is the best choice. Other notable difference would be with init system. Alpine with OpenRC is probably more conventional with many service scripts written for it. Void-Linux with runit is just a different blend. It is not hard to write service scripts for runit, but probably there are more scripts written for OpenRC so it's a win.

For me a big plus of Void is its build system, but I can't comment on how it compares to Alpine, because I don't know the latter. It is quite easy to add more packages all with proper cross-compilation support and builds are thinly isolated by default with unshare (but it can use bubblewrap). I am slowly implementing my own distribution based on Void, that will have ChromeOS-like updates (AB partition scheme). I want it to replace ChromeOS on my chromebooks and also have it as the OS for computers I manage for my family.

EDIT: Also as sibling commenter noted it is rolling only. It is a problem for my project that I would like to address by issuing updates only when critical software has newer versions (i.e. Firefox) and check packages against CVE database. I have seen this CVE checking on Gentoo, I'm not sure if it is cvechecker or something around eselect. Other possibility for me would be to freeze versions in step with some other stable distribution.

EDIT2: It was glsa-check tool from Gentoo.

A big factor might be void is rolling only.

Be careful, it using musl instead of glibc can be a headache, especially if you ever use any pre-compiled software.

This, from what I can see, makes Alpine rather less suitable to being a desktop OS than an embedded OS. I don't want to compile everything from source, and sometimes I can't (e.g. Steam, Dropbox).

Not sure where compiling comes in, either it's proprietary or it's in the repo the same as any other distro.

Another point for flatpak/snap style proprietary apps distribution though - they don't assume anything about the distro will be there.

I think compiling usually comes in when it's not in the repo or proprietary.

Specifically in container space, when I chatted with other developers regarding reasons of choosing Alpine, the top one answer is the size of the base image comparing to other popular Linux distro images like Ubuntu or Debian. Smaller size => faster rollout + minimal CVE exposure, right? What I feel fundamentally wrong about this is, in many cases they probably shouldn't put a full OS in a container in the first place. Take Google's distroless as an example, if you only put necessary stuff in your container, even a debian based image can be reasonably small enough that you never need to worry about image size.

Also, dealing with DNS issues in Alpine based containers (which was caused by musl implementation, iirc) was one of my biggest nightmare at work. Just search for "Alpine+DNS" on Google and you can see what a mess it had brought.

I think these points aren't really fair, since Alpine predates a lot of the work that went into making the alternatives possible. Alpine predates Distroless by over a decade, for example.

As for DNS, it's extremely unfair to blame musl for properly implementing the POSIX standards for name resolution. It's not Alpine's fault that so many people wrote software which explicitly depended on specific glibc quirks. If anything, it's a good lesson on the dangers of monocultures, and how even FOSS software is at risk.

I agree with you that it is not Alpine's fault for not being as good as today's Distroless 10 years ago. In fact it is still my favorite tool for several use cases (e.g., injecting a sidecar container for adhoc debugging).

What I was trying to say, was that many people choose it for wrong reasons without fully understanding the implications. This included us. It was a nightmare to me because at that time I didn't know it has different behavior in DNS resolution. And our developers expected their code, which ran fine on their workstations and in CI (Ubuntu/Debian environments), to behavior the same when running in an alpine container in production.

>it using musl instead of glibc

This, I remember jemalloc and musl/ Alpine issues. In the end it just isn't worth the hassle. Although that was may be two years ago.

Exactly the reason I don't recommend Alpine! It's a pain to compile a custom service with multiple dependencies for this distro.

pre-compiled software outside your distro's repos is always going to be a headache, you really shouldn't be doing that.

It's pretty popular to install Python C-extensions from packages, called wheels. Otherwise you need to compile from source, which means you need build dependencies. So Python and Alpine doesn't really go that well together. In my experience debian-slim as Docker base image is also small, and less painful.

I remember trying out and writing about Alpine vs Debian in the context of Docker images a few years ago and I remember someone commented saying with Alpine they got substantially worse performance when using Python to connect to a PostgreSQL database using the official Python pg package (it requires C dependencies) in an isolated benchmark that performed a bunch of reads.

I don't base any decisions around micro benchmarks but that example struck me as interesting because this was a case where the performance difference between using Alpine and Debian was real and affected user level applications.

For the last few years I also run Debian Slim for my base Docker images and don't worry about it.

Yes my images might be a little larger than Alpine but it's non-issue in the real world. For smaller scale deploys once the base image is pulled down initially it's there in both cases, so now it comes down to pulling app level changes (code or package deps) which is comparable in size with both distros.

And for huge scale deployments it doesn't matter because typically you'd use custom ISOs with as much pre-loaded static content as possible, so you could easily bake in a specific Debian Slim image into the ISO so when you pull down your application image at deploy time it skips having to pull the base image entirely negating any wins that Alpine might have had for pull speeds and network usage.

Sure Alpine has less attack surface since it's a smaller code base but we're comparing it to Debian here. They have a 28 year track record of being unbelievably dependable and well supported.

As I understand it, wheels support is coming to musl. I cannot remember where I read this, but it must have been on some issue related to this.

PEP: https://www.python.org/dev/peps/pep-0656/

That's cool! It is already possible to allow installation of many wheels in a hacky way: https://github.com/pypa/pip/issues/3969#issuecomment-2473819...

But that's a pretty bad idea in most cases I guess. Good to see that Musl might be supported properly.

Nearly all proprietary software is distributed that way.

There are obviously exceptions where you absolutely have to use proprietary software. But if you can possibly help it, you probably shouldn't be doing that.

Welcome to hackernews where you get down-voted for saying one should not use proprietary software...mac generation i suppose ;)

It's a thread about a Linux distro and further a thread about some complications one might run into versus others. If someone's concerned about a problem with pre-compiled proprietary software, particularly one you know they'd rather not have either, jumping in with a Har Har try not to have that problem isn't ... well it's just flat humor. Nothing mean or bad just, downvotably flat?

I don't think it's any sort of Mac generation downvoting, I think it's more the opposite: they're preaching to the choir. Yea. We Know.

The real question is, when did "don't use proprietary software" become an acceptable thing to say to people?

Since around 1975-80, when software makers stop'd giving you the source-code with the license to use it, and just gave you the compiled unchangeable product?

Not is it just acceptable, it's your obligation to tell peoples what the downside (or upside) of closed down software is. Is a closed source webserver a good idea? probably not. Is THE closed source Photo-editing program a good idea? Probably yes....if you really need it.

Mac generation? Maybe if you mean those whose first computing experience was with microcomputers in the 80s. Every single program I used for the first ~14 years (1984 to 1998, when I first used Linux) of my computing experience was proprietary.

That this is acceptable in any way is ridiculous

I find your and nix23's responses to be precious. Acceptable? It's free software! Take it for what it is, appreciate it, and adopt it if it suits you?

To contradict myself: I do find myself frustrated when 'obvious thing that should work' doesn't but I save that ire for things that break between versions!

> It's free software! Take it for what it is, appreciate it, and adopt it if it suits you?

I am really against the idea that just because something is "free", it is exempt of any judgment. We should always strive to improve everything, free or not.

Yeah but the other way around, it should not be acceptable that you have to use pre-compiled proprietary software.

Stockholm syndrome.

I love Alpine as well, albeit I usually use it in VMs. It's just so "out of the way" without being "not there at all" and the miniscule size and small set of default packages is just great.

I've got 2 installer setups I use: a pretty much stock base install and a "replace all of the BusyBox versions with real versions" install that is still quite tiny. I used to have a 3rd "desktop" setup for my laptops but I found too many issues compared to running e.g. arch at that point so I stopped using it.

Once in a while I'll still install Ubuntu server when dealing with proprietary stuff or whatnot buy beyond that Alpine has been my go to for years now.

Drew mentions his workstations and laptops run Alpine, i don’t have much experience with the system outside of using it as a base for some docker containers.

I wonder what the pitfalls and corner cases he encountered are when he set it up. I envisage an Arch style process of configuring and tweaking the system.

I think that could be a worthwhile project documenting the setup for my personal use case.

I ran Alpine on many of my computers for years and currently run it (PMOS really) on my phone.

Documentation is a separate package so unless you're careful to always install it you tend to not have it.

Busybox is definitely not 100% compatible with coreutils, lots of sloppy scripts tend to break.

For a while the default kernel was the grsec one which breaks pretty much everything. Thankfully that seems to have changed.

musl libc lacks some of the new instrumentation and bounds checking features in glibc, also the subtle differences can change how often bugs in incorrect programs get triggered. Of course musl libc is not binary compatible so closed source software won't work. (no widevine or chrome)

Some larger packages are missing, I don't know if they ever managed to package Gnome (I certainly don't blame them, it's a beast.)

OpenRC is not systemd, I prefer it though.

They have an an installation option that lets you run from tmpfs but back up /etc and automatically reinstall packages from a disk cache on reboot. This is great for that generation of macbook pro with the bad harddisk cable, mine had 8gb of ram which is plenty with a small distro like alpine as long as you're used to keeping everything in git and pushing often to branches on other machines.

> Documentation is a separate package so unless you're careful to always install it you tend to not have it.

Install the "docs" (meta)package and it'll automatically install documentation packages. My greatest annoyance is actually the (absent) documentation to find this; IIRC I had to find out about this via IRC.

Thanks! I'm glad you pointed that out.

Thanks for the reply, it looks like there’s a lot of avenues and differences of value which are worth exploring here.

Personally, I’m happy with a little excess on my personal systems, documentation is a must for me, but it’s a great reminder that I’d need to pull it in separately.

I’m very interested in exploring the “home directory as a git repository” metaphor I’ve seen written up here from time to time, perhaps a minimal system like Alpine is a good opportunity to explore it further.

I’ll play around with it. Thanks!

What do you use for automatically restarting failed services? IIRC OpenRC doesn't do that.

There is supervise-daemon(8) for this.

I don't run buggy software as a service so I don't have this problem.

Same. It's one thing to design for an embedded system with a small set of requirements. It's another altogether for desktops, where extreme compatibility and an excess of features is required to support all the different end-user cases. I love Alpine for containers, but I'm sure it wouldn't work out of the box as my desktop. The Linux GUI environment has added an order of magnitude more complexity since I dug into it as a teen, and hardware support is non-trivial. Heck, just doing encrypted LVM root and swap with hibernation still seems to give most distros trouble.

There's an interesting side comment that "OpenRC is not as good". That's exactly the sort of area that you'll only run into if you're doing things outside the container ecosystem, because you (typically) don't want to muck about with init systems. It makes perfect sense that that's where the rough edges are, if only because fewer people are walking those paths.

The size of Alpine and its package manager are brilliant. What gets me, and my team, is the support policy for “older” packages.

For a while we would pin library versions (e.g. libvips) only to have the pin break the build because the package was no longer provided. That’s only a few months later, not years. It seriously impacts the repeatability of Docker builds.

Now we don’t pin to the same extent and lack some confidence, but at least it doesn’t break the build.

We had a fun bug in production with our timezones going haywire due to a similar issue: https://stackoverflow.com/questions/64581249/rails-activesup...

No broken builds but all times displayed from our alpine based services were off by an hour.

The best bit was that users started entering times for scheduled events that were off by an hour to "compensate" for our brokenly displayed times.

This is an issue you'll have with any distribution though. That's where you start having your own repository from which your docker builds will pull packages

> This is an issue you'll have with any distribution though

This is (almost self-evidently) true in theory, but not really in practice. It's about finding the sweet spot between LTS and maintainability. As the commenter said:

> only a few months later, not years

The lifecycle is usually longer with other distros.

This got me thinking. If one want to start an open source project which requires a lot of manpower like this, where to get the funding to start the project? Starting without funding means you'll have to gather a team of unpaid contributors, and for big projects like Alpine, you'll probably need to gather a lot of them. How these big open source projects got bootstrapped?

You get what you pay for, which is to say, if you're relying on pinned versions of dependencies, store them yourself.

Easy enough to throw a your pinned packages into s3, or anywhere else that's convenient.

Alpine has started doing point releases to help address some of these pains. However, as with most things it is usually best to have a testing strategy in place before doing upgrades.

Alpine has been incredible for some of my more esoteric use cases.

On amd64 desktop/server I still default to Ubuntu. For Docker my image base is usually Alpine.

But what’s really amazing is that recently I’ve transferred more and more functionality to my Nvidia Jetson AGX.

While the CPU could certainly be newer the 32GB of shared memory, NVMe storage, and CUDA GPU support is just killer for my use cases.

Docker images and LXC containers for Home Assistant, my broadcastify scanner feed, my ADSB feed, my Plex server, my FreeSWITCH instance, and my various NLP/TTS/STT applications (with CUDA) make the Jetson AGX perfect for me.

Where Alpine comes into play is the amazing package selection for aarch64. My life would be much more difficult without Alpine on this hardware.

With the push towards aarch64 everywhere this will get easier over time but for now Alpine is saving me a lot of headaches!

We used to use Alpine Linux but the build times are a real drag. We are a Python shop, so we just switched to python-slim for most of our builds. This writeup explains in detail the problem: https://pythonspeed.com/articles/alpine-docker-python/

Alpine is indeed a fantastic experience for many use cases. But for me, it falls just short of being totally usable as a desktop/laptop OS because of the lack of package support for important things that require glibc. I'd love if I could use musl, truly, but there are a few things that just won't work and I need them daily. And every time I've tried using flatpak to fill in the gaps, I've been disappointed by broken installs or packages that just didn't work once installed.

As much as I hate to say it, I'd take a glibc flavor of Alpine as a daily driver in a heartbeat.

Is it reasonable to expect one distro of Linux to be good at everything? There are a number of comments about Alpine as a desktop OS... sure you can probably make it work but it seems Alpine's sweet spot is when it's used as an embedded OS or as a base for Docker containers. Isn't that good enough?

I am also curious about the "apk is seriously robust" comment: does this mean fast, stable, intuitive... or something else? If the package manager achieves it's goal I don't care about "robustness" as long as I'm not losing 10+ hours a week trying to debug something about it.

Sure, specializing is fine, but why not use it on the desktop? I've run it on a laptop and then desktop and it's been perfectly fine.

It isn't probably can make it work, you can make it work. It has window managers and desktop software in the default repos.

Robustness has never meant speed or intuitiveness. It means resilience to breaking.

Intuitiveness can lead to a type robustness with sharp tools though; if it's either easy to undo destructive operations, or hard to accidentally do destructive operations, it makes for a more robust system overall (even if it doesn't specifically affect the robustness of the component in question)

This is stopping me from installing me on my laptop:

> OpenRC is not as good, but thankfully it's slated to be replaced in the foreseeable future.

I am really curious and couldn't find information on the web. Change to what?

https://skarnet.com/projects/service-manager.html

I like s6 software but it's written in djb style c which is painful to read imo

After using systemd with Arch, I'm conflicted on whether I like it or hate it.

I really like Alpine but it is sometimes a bit harder to work with. I found Debian to be absolutely amazing in recent releases. The new release (11) just works on all platforms (AWS, RPI) I use it. It works for data science (CUDA) as well as running databases or big data workloads. With Alpine some of these tasks would be hard to achieve.

I love how simple Alpine for Docker is. Also, converting it to a micro VM has also been very easy with https://ignite.readthedocs.io/en/stable/

Or with https://github.com/combust-labs/firebuild, I’m the author.

I have been using Alpine with ZFS on bare metal as my primary home server for about 2 years now, replacing a SmartOS (Illumos/Solaris) one. My experience has been very positive so far.

The OS/distro is sane, reminds me of OpenBSD that way.

I love alpine, it's such a good fit when building rootfs for embedded devices with limited ram/rom. however I wish there can be a nixOS-like way to manage my configurations.

It seems like this is more likely to happen by getting nixos smaller than making Alpine declarative.

It isn't perfect but I just end up installing nix (the package manager) and home-manager and hacking together my configuration through that.

The majority of my NixOS configuration is written in NixOS agnostic modules so it works pretty well.

I share my NixOS configurations between one bare metal Alpine install as well as an Alpine WSL2 install.

We are actually in the design phase for a declarative variant of Alpine using OSTree.

That sounds fun; is anything public yet / where should I watch for announcements?

If all goes to plan it will be part of Alpine 3.15 as a release variant.

I like Alpine but... unfortunately, in the path to minimal disk size, they decided to simply disregard legal obligations of the open source components they use, even though most were very simple: include license text and copyright notice. They ended up producing something that violates the open source licenses of the contents... so unusable for any re-distributable product.

Although we do not yet support recording the copyright lines in the package metadata, SPDX labels are used to provide linked data references to the license text. Copyright metadata itself will be included in apk3.

Thank you; this is great news! Looking forward to it.

I'd really disagree here. Two choices that Alpine made can be really nasty to debug or work around if you are unaware of using Alpine - especially if you're extending from some Docker image that extends from another Docker image that has Alpine as core:

1. musl libc. It's not binary compatible with libc and many Docker image builders don't bother to ship the libc-compat package which means if you're adding (for example) some Java library that has native parts depending on libc, you'll get weird errors.

2. busybox as default shell instead of a real bash. Way too many external scripts depend on various degrees of bash features.

Simple doesn't mean "everything you throw at it works ootb."

Simple means "not complex."

Busybox shell and musl are both less complex than bash and glibc.

> Busybox shell and musl are both less complex than bash and glibc.

For someone developing new features for these projects, yes. For someone used to classic bash/libc as a user? The other way around, because one has to keep subtle differences in mind.

Simple means "no handholding"; if I have to hold its hand, I have to think about it, which is not simple.

I’m reminded of the KISS principle - which is held in high regard on a number of distros.

I would interpret “no handholding” to mean “easy to implement”.

As I understand it - Simple, as a term of art, doesn’t often mean easy. Simplicity is elegance in design, though not necessarily elegance in implementation.

> I would interpret “no handholding” to mean “easy to implement”.

The implementer, developer, is one person (or a handful of people). As a general rule, since there a lot more users than developers, we should lean towards making lives easier for users.

Software is used a lot more than it is written.

Does Alpine have an auto-deploy solution similar in function to Debian's Preseed ability? If Alpine can be auto-deployed, and as comments here indicate, may have a smaller installation footprint, it might have merit for some high-instance-count use-cases.

Alpine can load an overlay tarball (apkovl.tar.gz) on boot, of which it may contain a script to bootstrap a system (e.g., /etc/local.d/00_bootstrap.start) or an /etc/apk/world file that indicate a package to install on boot. The requirement is to be able to put a file named hostname.apkovl.tar.gz in one of the mounted disk(s) (can also be placed in the same disk as the boot disk itself). [1][2]

[1]: https://wiki.alpinelinux.org/wiki/Alpine_local_backup

[2]: https://wiki.alpinelinux.org/wiki/Qemu#Live_mode (would be similar to this)

Is there a hardware recommendation for cheap, tiny, alpine-friendly, every-day notebooks?

Am struggling with a x205ta and would love to have a workstation running alpine and no containers.

And be it just for the lulz.

Check out GPD P2 Max or GPD Pocket 2. Not sure about the Alpine compatibility but it seems that it can run Ubuntu.

As an OpenBSD user, Alpine is too crazy on leaving out locales apart, but it shines on tiny devices.

On similar distros, Void is great, albeit LibreSSL would be preferable to OpenSSL.

What is interesting it did use LibreSSL: https://voidlinux.org/news/2021/02/OpenSSL.html

I also use Alpine Linux as my main Linux distro. It's very good to be focused - with Alpine, I'm not tempted to try to install WINE and play games, etc.

Personally, given the sheer number of distros for Linux, my awareness of this distro was raised by my use of Docker.

Reply on news.ycombinator.com