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.
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.
> 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.
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'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.
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
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 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.
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."
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
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.
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)
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.
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.
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.