10 ms·
Alpine Linux: Brilliant Linux Distro
- DrBenCarson 5y agoWhy don't more people use distroless? Based on debian so no musl headaches but even lighter than alpine https://github.com/GoogleContainerTools/distroless https://github.com/GoogleContainerTools/distroless
- frafra 5y agoBecause you cannot just jump in your container to debug. There are ephemeral containers for Kubernetes to add an image on top of a running container, for troubleshooting, but I haven't found something like that for Docker or Podman. You would need some kind of patchwork script where you untar an image and copy it inside the running container I guess.
- thesorrow 5y agopostmarketOS is based on Alpine Linux and it's the perfect choice for a lightweight mobile OS.
- lastdong 5y agoIt’s used to build pretty much every Docker image around us. Works extremely well as WSL. Super lightweight, performant, and the number of packages is growing strong. Pair it with xcfe (or gnome or kde) and you have a super desktop, no more worries about RAM or background processes eating up CPU (looking at you Windows). Yes, there’s a Blender package! and many other good stuff. Alpine made Linux fresh again, and yes I have 32GB of RAM and a fast CPU and SSD, using Alpine will make sure it stays fast It needs much less than that to run, of course, it’s brilliantly focused.
- synergy20 5y agodepends on what you do, it's musl-based, some glibc software might not run well, and if you use linux for daily development work, it might not fit.
- lastdong 5y agoI usually (mostly) use containers for dev, and deployment, which abstracts things a bit
- SahAssar 5y ago> performant Isn't musl generally less performant than glibc?
- imachine1980_ 5y agoI think busybox is lighter, maybe not faster, but make alpine probably the cleanest modern distro, make it efficient and fast in the process.
- SahAssar 5y agoI don't think busybox has anything to do with the question of musl performance.
- Tehchops 5y agoI seem to recall some pretty poor performance regressions in Docker containers versus equivalent Debian-based container configs.
- Rebelgecko 5y agoUsing musl instead of glibc leads to enough surprises that I've migrated my alpine containers over to Debian-slim based ones. If you have a bunch of containers built on the same base, the storage of Alpine vs Debian becomes less substantial, and you avoid a lot of weird bugs and a surprisingly large performance hit (at least for python)
- bcl 5y agoWARNING: Blatant self promotion follows :) I've recently switched to using Alpine on my laptop, and have written a bit about setting it up using ansible here: https://www.brianlane.com/post/alpine-laptop/ https://www.brianlane.com/post/alpine-laptop/ And when you can't find the apps you need in the distribution there's always podman: https://www.brianlane.com/post/prusa-slicer/ https://www.brianlane.com/post/prusa-slicer/
- deleted 5y ago[deleted]
- moltke 5y agoI ran Alpine on my laptop during the last half of college. It's a great little distro if you don't mind occasionally compiling things.
- djbusby 5y agoI've been on Gentoo since 2005. It's a great distro if don't mind compiling everything ;)
- maffblaster 5y agoFun fact: Gentoo actually uses Alpine docker containers as a base to build their Docker containers.
- boondaburrah 5y agoI got hazed by an upperclassmen with gentoo around that time and it's ruined me ever since. It's just not Linux if I can't edit a text file and rebuild the world.
- mkdirp 5y agoInstead of using podman directly, and potentially messing with X11 permissions, you could use x11docker (despite the name, it podman support). It attempts to safely share X11 into a container.
- trillic 5y agoGreat for containers, embedded devices, and servers. Not quite ready for desktop development use yet despite my best efforts. I use Arch btw.
- jka 5y agoA nice feature of Alpine Linux is that the package repository is a relatively straightforwardly-structured git repository containing build scripts for each package: https://gitlab.alpinelinux.org/alpine/aports/ https://gitlab.alpinelinux.org/alpine/aports/ It's worth reading the contributor guide[1] before signing up and providing any fixes and improvements - and from there, hopefully it's a relatively familiar workflow for many developers. [1] - https://wiki.alpinelinux.org/wiki/Alpine_Linux:Contribute https://wiki.alpinelinux.org/wiki/Alpine_Linux:Contribute
- uzername 5y agoWe use alpine based images extensively where possible. Most popular language ecosystems and tools have an alpine option. Alpine as a base image is nice because it's nearly blank, but easy to customize unlike distroless. Recently one tool did drop Alpine, most based on it's reduced performance, and that was envoyproxy.
- pid-1 5y agoThat used to be huge a few years ago. But with both Ubuntu and Debian shipping much smaller images, I almost always find the hassle of using Alpine not worth it.
- Tenoke 5y agoSame currently. Unless I'm just modifying a simple trusted image (which does happen often enough) I just start from Ubuntu during development and only attempt to move the image to Alpine if I'm really trying to improve resource usage down the line.
- andai 5y agoTIL there is a 29MB Minimal Ubuntu! https://ubuntu.com/blog/minimal-ubuntu-released https://ubuntu.com/blog/minimal-ubuntu-released
- ethanpil 5y agoWow, wish there was a Debian version!. I miss JeOS!
- Tenoke 5y ago>due to the great popularity of Docker, Alpine Linux is one of the most deployed operating systems currently in use Wow, that's impressive! However, when I check on Distrowatch it's only in the 30s. Is there a better statistic? Something more representative of actual amounts of installs on anything at all?
- silisili 5y agoI've been down this path before and I can say for sure two things - 1 - Distrowatch stats are both gamed and useless 2 - There's no easy way to see which distro is most popular on the whole.
- yumiris 5y agoDistroWatch counts by clicks to the distro's page from what I remember. Its statistics represent the "interest", rather than install count. With regard to Alpine Linux on Docker, the install count[0] of the base image should give an idea (over 1 billion!). [0] https://hub.docker.com/_/alpine https://hub.docker.com/_/alpine Edit: clarity
- teawrecks 5y agoiirc every intel cpu runs minix on its management engine. Might be a contender.
- bobobob420 5y agoI saw a thread the other day on docker command pull alpine:latest is not good. Im pretty sure like every enterprise docker container is running this command. Anyone see anyone change this or bring this up at work?
- yjftsjthsd-h 5y agoWhat do you mean, "docker command pull alpine:latest is not good"? Was there a specific breakage?
- phphphphp 5y agoThey’re probably referring to the “latest” tag. The “latest” tag is a terrible idea to be anywhere near anything that matters but I’d be very surprised if any enterprise is depending on a latest tag. Digest pinning is what should be used in any system that matters.
- yumiris 5y agoAbsolutely beautiful little OS - I love that it manages to balance well between being light, secure and rather versatile for server environments. I run it as a WireGuard & Docker server on a low-end VPS, and it just works without any problems at all thus far. Its wiki does a fine job at being a pretty good resource for documentation, too, and both ArchWiki & Gentoo Wiki work well as fallbacks.
- laurencerowe 5y agoDoesn't Alpine have a noticeable performance penalty due to being based on musl libc instead of glibc? This seems to be born out in multiple people's micro benchmarks though how much of an issue it is for larger applications probably depends on the workload. https://superuser.com/questions/1219609/why-is-the-alpine-docker-image-over-50-slower-than-the-ubuntu-image https://superuser.com/questions/1219609/why-is-the-alpine-do... https://nickjanetakis.com/blog/benchmarking-debian-vs-alpine-as-a-base-docker-image https://nickjanetakis.com/blog/benchmarking-debian-vs-alpine...
- ghotli 5y agoAnecdotal but I work on a performance oriented application and there is no such measured performance penalty from musl. For that particular use-case, like all benchmark caveats. Older musl, perhaps. Musl in other domains that bottleneck on something less performant, perhaps. Ymmv, measure twice cut once. :)
- stabbles 5y agoI've tried alpine's gcc before and it was about 50% slower to compile a bunch of packages. That said, if you compile llvm with MinSize/-Os on glibc distro's it runs 50% slower too, so it's unclear if slowdown is due to musl libc or rather that they optimize for size instead of performance.
- marcan_42 5y agoCompiling is CPU-bound and doesn't really bottleneck on anything that libc is involved with other than the allocator, so unless musl's allocator is comically slower than glib's, chances are it's just -Os.
- lmarcos 5y agoWhat are the chances of encountering performance issues and/or incompatibilities when using Alpine Linux as Docker image for Go apps in production?
- kobalsky 5y agoAren't go apps statically linked? You could theoretically build it and put the binary on a "FROM scratch" docker and run it. I mean, what I'm trying to say is that the base image doesn't matter, it would be basically just a debugging environment for you to exec into.
- jupp0r 5y agoI use it mostly as a build image in order to produce completely static binaries which isn't possible with most other distros because the glibc maintainers at some point in the distant past decided to impose their opinion on the matter upon you by making it impossible to statically link against glibc.
- stabbles 5y agoIt seems though that glibc was inspired by musl to move away from many small shared libraries to a single one, namely the dynamic linker executable also being lib{c,m,...}. It's not at the same level, but it's progress...
- klysm 5y agoI really like statically linking everything. I think the trade off space is a lot different now though. But I still agree they shouldn’t have done that
- ghotli 5y agoI've done the same alpine trick for static binaries but may I introduce you to musl-cross-make? https://github.com/richfelker/musl-cross-make https://github.com/richfelker/musl-cross-make Just burned out static toolchains that make me static binaries for all architectures gcc supports. Much like musl.cc but they suggest building your own and I do. I use these toolchains on debian (/ anywhere a non-ancient linux kernel runs) to make static binaries, you can too!
- electroly 5y agoWhen I looked into this, I decided against musl-cross-make because all the tools in there are way out of date. Due to its use of custom patches, you can't easily update it yourself; you must use their specific outdated versions. They're a full major version behind on gcc (it was two major versions behind at the time), and they're two minor versions behind on musl itself. Binutils is five minor versions behind. It was much easier to just fire up an Alpine build container with the latest versions of everything, and I'm actually capable of keeping it up to date. The Alpine folks seem to have more manpower at their disposal for keeping the packages up to date with upstream.
- zrail 5y agoI recently deployed a small fleet of Dell thin clients around my house to run zwavejs2mqtt[1] via docker. I decided to use Alpine because the machines have 2GB of ram and 8GB of eMMC storage and I figured Alpine would minimize resource usage. They're working great so far! [1]: https://github.com/zwave-js/zwavejs2mqtt https://github.com/zwave-js/zwavejs2mqtt
- zalebz 5y agoQuestion, we're a long time Windows shop and just recently have been spinning up some linux containers (redis, rabbitmq). The decision fell to me and I went with Ubuntu. (I'm confident in our networking team that everything is firewalled well and not externally accessible so these are local LAN only.) Should I instead be using Alpine? If someone is isn't distro aficionado and is utilizing "mainstream" docker images, what's the recommendation?
- singlow 5y agoUbuntu will likely be more compatible and easier to work with. The version you get in docker is very minimal as well, although maybe not quite as tiny as alpine.
- Zhyl 5y agoMy understanding of Alpine is that it is a minimal distro more suited to embedded systems and similar (happy to be corrected on that). If you're using headless boxes for servers then Ubuntu or the house variety of the cloud platform of your choice is almost certainly best. If you're looking for employee workstations I would go for something that looks and feels like Windows like Linux Mint or Kubuntu.
- zalebz 5y ago"local LAN" = local Local .... For shame, but I'm leaving my comment as is
- phphphphp 5y agoThe maturity of your organisation’s use of containers is quite important: Alpine is a fantastic platform to build very lightweight images, but there’s organisations where people want containers that have everything. I’d say, as your usage of and experience with containers grows, aim to build more lightweight images and eventually you’ll get to the point where Alpine is the logical next step, rather than being the right choice because people on HN love it.
- Cymen 5y agoI think Ubuntu server is a fine choice for your needs. I tend to use it on small VPSes as it's easy to setup and get running, relatively up to date and in wide usage.
- tus666 5y agoWorrying about linux distros seems so antiquated in this serverless cloud computing world. Or at least so last decade.
- Zhyl 5y agoWhile the difference between some distros is almost academic, other distros have very strong principles that lead them to having very different forms and functions. Alpine falls into that category - if one were to not 'worry' about distros as you seem to be suggesting and downloaded Alpine without reading up on it, you would likely be put out by what you find. Alpine is a distro with a purpose, and that is worth 'worrying' about.
- boondaburrah 5y agoYou say that but there's other reasons to use linux (on the desktop!), and serverless itself is an old concept in which I never used to care which flavour of unix/linux my host was running my php or cgi scripts on.
- Macha 5y ago> Keep in mind that today due to the great popularity of Docker, Alpine Linux is one of the most deployed operating systems currently in use, because within every other operating system that uses docker, the docker image it uses is almost always Alpine Linux. Isn't this a little overstated? I'm willing to accept it has a majority, especially once you get into custom images, but e.g. docker's library images are usually debian based, with a -slim or -alpine variant available, and of developer provided images on my network, debian + derived images have a majority, while Alpine's statement leads you to expect some kind of 90% share.
- deleted 5y ago[deleted]
- DiabloD3 5y agoDocker images used to be entirely Debian-based but have slowly become almost entirely Alpine based. A lot of Debian users have become Alpine users, and I've been mulling over if I should join as well (since I've used Debian for 20+ years but are friends with Alpine devs and users).
- Macha 5y agoSo I surveyed docker images in my personal use: Postgres (Docker provided - https://hub.docker.com/_/postgres https://hub.docker.com/_/postgres): Debian (with alternates for alpine or other debian versions) Jellyfin (Developer provided - https://github.com/jellyfin/jellyfin/blob/master/Dockerfile https://github.com/jellyfin/jellyfin/blob/master/Dockerfile): They use an alpine build step but the final distributed image is debian Calibre-Web (Linuxserver provided - https://github.com/linuxserver/docker-calibre-web/blob/master/Dockerfile https://github.com/linuxserver/docker-calibre-web/blob/maste...): Ubuntu Graylog (Developer provided - https://github.com/Graylog2/graylog-docker/blob/4.2/docker/oss/Dockerfile https://github.com/Graylog2/graylog-docker/blob/4.2/docker/o...): Debian Vaultwarden (Developer provided - https://github.com/dani-garcia/vaultwarden/blob/main/docker/amd64/Dockerfile https://github.com/dani-garcia/vaultwarden/blob/main/docker/...): Debian (with alpine alternate available) I'm finding it hard to reconcile "Some of the software has secondary alpine images available" with "Almost all software uses alpine images" For professional use, our company mandates all images used are built off a common base image, which is Ubuntu based (my previous employer was similar, but used a Red Hat based image).
- sattar1 5y ago
- sattar1 5y ago
- mountainriver 5y agoAlpine was the first of its kind but there are better minimal distributions now. I’d rather not tip toe around the oddities that alpine introduces and just use a Debian based image.
- bbotond 5y agoWhat are those better distros and why are they better?
- sgarland 5y agodebian-slim and its downstream, because fighting with musl libc isn't worth the time.
- gurjeet 5y agoI'm working on a personal project where musl is the foundation of my project. So I'm interested in learning about all the downsides, corner cases, and footguns of using musl. Can you please share some pointers (search phrases, mailing list/forum posts, etc.) for me to read more.
- systems_glitch 5y agoStarted using Alpine as a curiosity for embedded/high security development a while ago, probably 2011-2012. I've of course used it a fair bit in $day_job containerization of services. Nowadays personally I find myself using it for the bare metal OS on servers running minimal services: things like VM hosts, purpose-built fileservers, etc. It's a fine distro, you can typically go a good bit of time between updates without worrying about fragging your install, which is especially important to me on personal projects, which are often more like pets than livestock :P
- michaeldwan 5y agoI really want to like Alpine, but we (Fly.io) have seen so many DNS issues with customer images that we’re now recommending Ubuntu or Debian slim. The extra ~50mb is a worthwhile trade off to avoid hard to debug musl-libc issues. eg https://www.linkedin.com/pulse/musl-libc-alpines-greatest-weakness-rogan-lynch/ https://www.linkedin.com/pulse/musl-libc-alpines-greatest-we...
- leetrout 5y agoWhat about busybox? It still has a glibc version doesnt it?
- sk5t 5y agoYep. I had an (immutable) JVM ECS service that worked fine for a year, then started failing DNS in just one of several AWS AZs and for just one of various host names--one with something like 24 A records, a few but not an outrageous number. Occasionally forking a process to run 'dig' on the same name made it work for a little while. AWS support's only advice was "don't use Alpine"; annoyingly, switching the containers to a Debian base cured it, even though this would appear to make absolutely no sense with respect to it failing in just one AZ.
- michaeldwan 5y agoFailing in one AZ probably means they changed something with DNS servers for that region. We had a similar issue recently when we rolled out a new DNS server that returned longer SOA records which broke python's mysql driver in only some regions during the rollout. Debugging nightmare fuel.
- sk5t 5y agoYes, my theory was also some DNS variance in the AZ, but AWS stolidly refused to supply any information to that effect. Adding 'dig +trace' to the equation only deepened the mystery.
- sylvain_kerkour 5y ago
- clay-dreidels 5y agoI'm a big fan of Alpine Linux, and use it as a daily driver. Here is my Alpine Linux minimalist desktop setup. https://github.com/git-sgmoore/AlpineLinux-DailyDriverDesktop https://github.com/git-sgmoore/AlpineLinux-DailyDriverDeskto...
- ste- 5y agoAbout musl and performance: I have noticed that ram usage is noticeably lower.
- throwaway984393 5y agoI'm typing this from an Alpine laptop. It still has a ways to go in terms of being as user-friendly as Slackware, but it's getting there. Some trouble at the moment is figuring out all the packages you need to install (and how to configure them) to get an actual working desktop as you'd expect it. There are also bugs in things like Bluetooth support and some other things. But overall it's quite usable, and very fast. You end up using Flatpak for any proprietary apps once dealing with glibc compatibility problems becomes too annoying. Some apps on Flatpak don't really work, like Slack (maybe it's possible to get it to work, but after a few days I gave up). Electron apps in general are a huge pain. I've gotten 1Password to work in Docker after over a week of futzing around. You really learn how much of a nightmare the Linux desktop today is. You also learn how much of the desktop (and non-desktop) apps actually require systemd to run at all, and how people have had to come up with fake systemd components. You definitely learn a lot about Linux!
- nunez 5y agobrilliant except for weird edge case failure modes that aren’t obvious, like random dns lookup failures or random network dropouts.