Alpine 3.10 Released | Hacker News Reader

Alpine 3.10 Released

alpinelinux.org

73 points_ikke_36 comments

Open articleView on HN

I am a bit curious of the MongoDB removal.

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

https://git.alpinelinux.org/aports/commit/testing?id=8a901de...

> community/mongodb: expunge nonfree software

Good riddance

* https://news.ycombinator.com/item?id=18229452

* https://news.ycombinator.com/item?id=18919543

Their new license is considered non-free, even though I think nobody has yet certified it as such from a legal point of view.

This is being upvoted so there is interest. Who uses Alpine and for what solutions?

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.

Almost all the popular or official docker repos offer an Alpine distribution. And Alpine by itself is about 5mb as a container.

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.

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.

Thank you and other posters for your answers. Will try it out.

I use it in my main VM template. Very lightweight, not much to get in the way of what you want to run.

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.

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.

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.

I use it as a container base (docker / lxc) for containers that have very few dependencies and small footprints.

It's very popular for minimal/tiny Docker images.

https://bugs.alpinelinux.org/versions/133 49 days late?

Does anyone know the meaning of "late", if any, in this context?

Probably just the difference between their planned release date/roadmap and when the ticket actually got closed.

The milestone there targets a completion date of 05/01/2019 for all the attached issues, but they still haven't resolved all of them.

For some reason Alpine in Docker can never resolve the names of other containers.

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.

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.

Lots of projects don't follow semver, unfortunately.

Python spells its major version with two integers separated with a dot; done.

AFAIK you can specify alpine:3.9.4 and alpine:3.9 for example. So I don't really understand your point.

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.

I think semvar would say `3` means the latest of the major version 3, no matter the minor version.

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.

> AFAIK you can specify alpine:3.9.4 and alpine:3.9 for example. So I don't really understand your point.

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.

The last update from 3.8 to 3.9 broke on the transition from libressl to openssl 1.1. I'm not sure such a huge version specifier would be helpful.

Reply on news.ycombinator.com