Alpine is very popular in the Docker community, due to the distro's minimal footprint. So I imagine at least some of the intrest may stem from those who create Docker images.
It's an actively-developed, secure, professionally-usable distro that uses musl libc and doesn't have systemd. It's not super easy to configure as a desktop system, but it's very small and I like to keep it around for VMs and such.
While not super easy to configure, the base install + modify then choose to commit changes workflow is pretty cool. I can try all sorts and when I (immediately) get stuck just reboot and have another go.
As far as I understand, most people use alpine in docker containers due to it's being quite lightweight with a decently large number of packages.
I personally use it directly on the hardware on my personal server and I love it. It's all the fun and flexibility of a minimal system like arch, with all the simplicity of upstart.
Also it takes about 2 minutes to install, which is helpful for setting up testing environments.
Same here (home server on bare metal). The simplicity, hardening and lack of unnecessary cruft means a much smaller attack surface than, say, Ubuntu. It reminds me of OpenBSD that way.
As others said its useful for containers and vms, but also other network equipment like firewalls and routers. Its easy to let it run completely in ram and offers a hardened linux kernel.
I used it as a base for docker containers, but depending on project Ive found that sometimes the lack of locale support is making it a non-viable option. I read there are ways to get it working, but I never did.
One good example would be containers used for CI jobs, which get downloaded hundreds/thousands of times a day. They benefit from being based off as tiny an image as possible.
Interesting that they still had a truecrypt package. It looks like they've had the veracrypt package for a while (The currently maintained major fork).
I really like Alpine. Last time I tried using it on a bare metal system, it still had some missing EFI packages (I can't remember if it was the grub UEFI stuff or efibootmgr) and I ended up going Void, but I should take a look at it again. I use it as a base for a lot of my containers.
I'm using alpine with docker (https://hub.docker.com/r/_/alpine), and one of the thing that bothers me the most is NOT having the ability to just say "alpine:3". This is not an available tag (for reasons unknown to me).
If you look at many other similar official docker images like python or golang, you can just say python:3, or golang:1 so that I don't have to worry about tracking non-breaking version updates.
Not having the ability to specify "alpine:3" and not having the time to track such versions might be also why people do alpine:latest in their Dockerfiles, cross their fingers, and hope for the best.
You should also be able to pull 'latest' as well, correct?
I think the problem with specifying just 'apline:3' is that it is an ambiguous statement. Do you want alpine:3.0? Or do you want the latest in the alpine:3.x line?
I think either using 'latest' or specifying a particular point release is what you'd expect.
Edit:
> [... ]people do alpine:latest in their Dockerfiles, cross their fingers, and hope for the best.
What are you crossing your fingers for? alpine:latest should be the latest stable, and should work as intended.
Latest of anything is RARELY stable. It's stable until someone hits a critical bug in the new release, then there's a new version, but your image is still running the older version. That's why we invented the concept of LTS tracks.
> I think the problem with specifying just 'apline:3' is that it is an ambiguous statement.
It is not ambiguous in Docker Hub land. It's a very widely used convention that means "give me the highest 3.x.y"
It's not ambiguous. As noted by the parent of the comment you're replying to, this is standard practice with Docker images/tags.
Personally, I prefer to specify even the patch level to avoid any kind of surprise, but I can understand why some people would want to be able to specify just the major release.
I know this wasn't really what you were saying, but just to clear something up in case someone takes the wrong thing away from this: "python:3" definitely isn't just "non-breaking version updates" - Python 3 has and will break compatibility between versions (e.g: 3.7 turns "await" and "async" into keywords).
I guess the only thing I can say is "way to go Python"? https://semver.org defines what how breaking changes are supposed to be made, obviously for those following suit.
38 comments
[ 5.1 ms ] story [ 104 ms ] threadTruecrypt and Qt4 I sort of understand, but MongoDB is still actively developed, so there seem to be a story there...
Update: I guess thats the reaction to the not OSI approved licence they switched to late 2018.
> community/mongodb: expunge nonfree software
* https://news.ycombinator.com/item?id=18229452
* https://news.ycombinator.com/item?id=18919543
Does anyone know the meaning of "late", if any, in this context?
I really like Alpine. Last time I tried using it on a bare metal system, it still had some missing EFI packages (I can't remember if it was the grub UEFI stuff or efibootmgr) and I ended up going Void, but I should take a look at it again. I use it as a base for a lot of my containers.
If you look at many other similar official docker images like python or golang, you can just say python:3, or golang:1 so that I don't have to worry about tracking non-breaking version updates.
Not having the ability to specify "alpine:3" and not having the time to track such versions might be also why people do alpine:latest in their Dockerfiles, cross their fingers, and hope for the best.
I think the problem with specifying just 'apline:3' is that it is an ambiguous statement. Do you want alpine:3.0? Or do you want the latest in the alpine:3.x line?
I think either using 'latest' or specifying a particular point release is what you'd expect.
Edit:
> [... ]people do alpine:latest in their Dockerfiles, cross their fingers, and hope for the best.
What are you crossing your fingers for? alpine:latest should be the latest stable, and should work as intended.
> I think the problem with specifying just 'apline:3' is that it is an ambiguous statement.
It is not ambiguous in Docker Hub land. It's a very widely used convention that means "give me the highest 3.x.y"
Personally, I prefer to specify even the patch level to avoid any kind of surprise, but I can understand why some people would want to be able to specify just the major release.
Easy answer:
1. :3.9.4 will be deleted the moment there's a security vulnerability in it == all your builds broken in O(weeks)
2. :3.9 probably will be deleted in a year or two == your builds will be broken in 1-2 years.
> What are you crossing your fingers for? alpine:latest should be the latest stable, and should work as intended.