Alpine Linux 3.8.0 released | Hacker News Reader

Alpine Linux 3.8.0 released

alpinelinux.org

73 pointsjbergstroem48 comments

I have used Alpine Linux for a long time even before they switched to musl libc, and I really liked it. However, I have now stopped using it because of the situation with security updates.

Very often critical security issues will not be patched for weeks and desktop software like Firefox can go months without being updated.

I would really love to use Alpine Linux again for my servers and desktops if the situation improves, but now it's simply too dangerous to depend on it.

You might check out Void Linux (just in case you haven't already): they have a musl variant and it's more desktop-oriented than Alpine.

I actually switched to Void Linux after having used Debian on the desktops for some time last year and I will say it's a near perfect Linux distro.

They seem to be understaffed, and would probably benefit from having additional maintainers.. You could always volunteer.

Yes this is probably the problem, and I think the maintainers do everything they can.

I was not writing the post to criticise Alpine as I really like it, but people need to take the missing security updates into consideration before they start to depend on Alpine for important things.

Arch is another good option to consider that receives frequent updates. However, Alpine package contribution isn't that challenging; but I'd like to see more CI integrations to automate the heck out of package updates.

I often look at the wiki pages for Arch as they are really good, but I will not use systemd so Arch is not for me.

Switching Arch over to OpenRC isn't overly difficult. [0] (A package and a kernel parameter).

Or there's the fork [1] where that is the default.

[0] https://wiki.archlinux.org/index.php/OpenRC

[1] https://artixlinux.org/faq.php

In addition to the others mentioned, I shall mention Thomas Caravia's Archnosh.

* http://repo.or.cz/archnosh.git

> I was not writing the post to criticise Alpine as I really like it, but people need to take the missing security updates into consideration before they start to depend on Alpine for important things.

I tried Alpine Linux and was very impressed, but have always resisted using it for container images because they do not publish CVEs or seem to have much process around security.

I've been using Alpine recently on my X200, and while it does require an arch linux chroot for some applications (due to some slight musllibc/gnulibc interop problems), overall it's one of the most pleasant, and stable distributions I've ever worked with.

As a regular user of systemd (I use arch linux as my main and therefore was one of the first adopters of systemd) I am subjected to irregular and weird irreplicable bootup bugs and timing problems. Alpine reminds me of a simpler time when my computer's bootup was deterministic, and a hang at boot was only ever caused by a disk problem, rather than something trivial like having to wait 3 minutes because it can't connect to the network.

I totally understand the reason for there to be 'bloat' in projects like systemd, GNU libc, etc. And I understand that often that bloat is needed, to cover the edge cases in the thousands of use cases for which they are deployed. However, it's only really when I moved to Alpine that I understood just how much of it there was, and how much of an impact it had on not only my interactions with the computer, but other concerns like my energy usage, etc. It was a like a breath of fresh air for me, and it reminded me that computing could be good, again.

I personally would like to see Arch support OpenRC equally, but I have grown accustomed to systemd.

See https://news.ycombinator.com/item?id=17405804 .

Interesting, last I heard a lot of packages 'depend' on SystemD (Notably DBus/GNOME programs), so it becomes quite the task to stop those packages from replacing your init system

At least the GNU "bloat" is a legacy of trying to be compatible with all the commercial _nix variants that sprouted.

I would really love to see Alpine as a default image on hosting providers like Digital Ocean and Vultr. A lot of people use it as a base for docker containers, but I think it'd also be great to use it as a lightweight docker host for running containers.

I'm working on this very thing. Albeit only on AWS currently https://github.com/massivekube/massivekube

Edit: Forgot url -_-

I deployed my own Alpine Linux image on GCE that included preconfigured nginx+mariadb+zabbix for monitoring my various services. Works well.

There is an Alpine image on Vultr, it's the first option if you click on ISO library.

I personally love alpine, I’ve been exploring it outside of docker and has proven to be a great canvas for deploying apps. Hope to see more cloud providers support alpine as an option.

What makes it more appealing than say arch, gentoo, debian, etc...?

Lightweight, simple, no systemd, quite a big selection of up to date packages, like Arch.

Yeah pretty much. What he said, up-to-date packages mean I don’t need to build my own ruby / elixir / python / node, I just reference them when building my application package, and it’s done. The way I’m using it now is I just build alpine packages and host a private repository. When I get a fresh alpine install I install my package and I’m done.

For me it's that the things I install are deliberate. I have to opt into installing every extra package, so I am more thoughtful in expanding the base image.

I liken it more to my fond days with FreeBSD and OpenBSD. A narrowly scoped base image and userland, but easy access to a vast array of packages/ports, but each explicitly listed and installed.

It's "batteries included" but "pick your batteries" vs "here's a kitchen sink full of batteries."

Running applications on Alpine feels like very deliberately building an environment, whether inside a container or directly on a host.

(Just be aware of the differences between glibc and musl... DNS resolution in particular will bite you if you don't understand the implementation)

Have any details about the DNS resolution stuff?

TL;DR musl attempts to query every resolver in parallel. This can cause problems if:

- If your resolvers are VIPs for the same process or machine, you can triple you DNS load and overload some crappy DNS dispatchers

- If you try to use multiple resolvers that resolve the same names with different records, you can kind of make it work with glibc but you will have severe problems with musl. This is a bad idea in the first place though

.Alpine Linux is a security-oriented, lightweight Linux distribution based on musl libc and busybox.

.End of support for hardened kernel (unofficial Grsecurity)

doesn't that contradict?

No. With updated licensing, there are no big distros supporting grsec anymore. You pretty much have to pay now. (And there's more to security than grsec)

The hardened kernel was more or less unusable on the desktop anyway. There was quite a bit of software that’s just completely incompatible with it.

It’s still better than selinux though haha.

In large part because grsec would opt to break backwards compatibility whenever it had to be weighed against further hardening.

In addition to licensing issues, Grsecurity's patches have been described by Linus as "garbage" (in terms of code quality).

They also invariably opted towards security when there was a trade-off between security and backwards compatibility, a big red flag when trying to get anything past Torvalds.

Clean, tight, sensible distro, the way the world ought to be. All my stuff on the web runs on Alpine. Images are tiny and easily manages. I use no Docker at all.

I'm a bit hazy on the practical difference between PIC/PIE and ASLR binaries, in terms of both security and what is required to build. Would anyone care to remark on this?

Whether you can get ASLR depends on the system. Whether your app can be randomised in load depends on if it (and libraries) have been compiled with PIC. Whether you're main binary address gets randomised depends on PIE.

While I love using Alpine Linux, it would be awesome if Alpine made options for contributing a bit more visible/approachable.

Note: doesn't seem to be available on docker hub as of yet.

It has been worked on in the Alpine image repo: https://github.com/gliderlabs/docker-alpine/commits/master

The submission of it to the official images repo: https://github.com/docker-library/official-images/pull/4501

I love Alpine. Its Linux without the bloat and systemd cancer.

systemd has made packaging easier, and it's good at full process management, but still, it is nice to have alternatives in major distros.

Even though I'm a Gentoo user, I still prefer void's runit or openbsd's rc.d system when it comes to simplicity, over OpenRC.

Also, dinit looks really promising as well:

https://davmac.wordpress.com/category/dinit/

I don't have enough long-term Linux experience to understand why systemd is so hated... All of my recent experience has been with Debian Stretch which I think uses systemd by default, and I don't see any obvious issues with it.

systemd is fine until it isn't. On my systems with systemd inits, whenever there's a problem, systemd is always involved somehow.

[I had a cute one where a daemon (emacs, actually) set to start-up on boot with systemd ended up failing, which somehow caused the rest of the systemd modules to fail, with all of the modules failing silently (so the systemd tools themselves didn't tell me anything about failed units).]

The original SystemV init was ugly and hairy. Systemd managed to replace it with something more counter-intuitive and obtuse. That took effort.

"systemctl list-units"

What's wrong with?

"systemctl list" or "systemctl units" or "systemctl ls" ?

Then there's the output, which is borderline unreadable. The entire systemd design is like this. It seems like it's designed by people who enjoy arcane hard to read and hard to type stuff.

I can never, ever remember the magic incantations required to get it to load a new unit file. I can also never recall where they go without Googling and it seems to vary across distributions. People always joke that the first step to doing anything with git is to Google it. Systemd is worse since its commands are bizarre and non-memorable.

Over the years I've grown to hate intentionally arcane software. It wastes your time to no benefit. I tolerate git because it's powerful and it does have rational reasons for how it does things, but systemd is just annoying.

I think "systemd came and replaced sysvinit" is a winner-written history. There are/were other strong alternatives to sysvinit and eg in Debian it was a close race.

It's one of the fallacies called out by the Uselessd Guy.

* http://uselessd.darknedgy.net/ProSystemdAntiSystemd/

It's also an outright ahistorical falsehood in the case of Fedora and Ubuntu.

Why do we have ulimit and systemd?

When should I use which to control system resouces?

And on that note it was booted off the front page within 5 hours of being posted...

Reply on news.ycombinator.com