Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Alpine Linux 3.15

alpinelinux.org

Post reply on HN
Print view View original

21–30 of 91 posts

Re: Alpine Linux 3.15

#21

Post by qwertox »

pionar wrote: post #3
petercooper wrote: post #2

I'm familiar with Alpine in container scenarios, but is there any mileage to using it as a day-to-day desktop distro?

Not really. It's not designed for that. It's designed to be as lightweight as possible. also, instead of Glibc, it uses musl, which although is supposed to be binary-compatible, does have some gotchas, so the larger the system, with more apps and libraries running on it expecting glibc, will have issues.

musl really becomes a pain if you work a lot with Python. You can't use wheels, which means you will have to compile everything yourself, which sometimes takes ages, and you're not guaranteed that it won't have unnoticeable errors.

My biggest issue was with the 3.12 -> 3.13 transition, when musl got upgraded to 1.2 and with it "musl 1.2 uses new time64-compatible system calls". This broke so many things for me without me knowing, like nginx having as the datetime in the logs the unix epoch. All continued to work, but everything related to timestamps was completely messed up, on 32 bit OS due to running on Raspberry Pis.

This was the moment where I decided to stick to debian-slim, and only very specific containers will continue running on Alpine. Before that it was my default container OS.

Also there is no reliability in packages getting updated, sometimes they just disappear in the next version. But these things are rare occurrences, which only are then nerve wracking when you are confronted with them. For 90% of the cases Alpine is one of the most awesome container OSs.

Re: Alpine Linux 3.15

#22

Post by spyremeown »

xxpor wrote: post #20
yjftsjthsd-h wrote: post #16

Earlier quoted context omitted.

I use it on my desktop:) It's a nice experience after a slight learning curve; I'm particularly fond of it supporting ZFS well without being Ubuntu. Musl libc is a potential pain point; I get most software from official repos or build from source, but ex. to run Steam I resorted to flatpak (which just shoves glibc in the container with the application).

For an average user, I'd guess they'd hit more issues with busybox than musl.

I hate how many incredibly useful and sane options and most of the time missing from busybox binutils... drivers me crazy.

Re: Alpine Linux 3.15

#23

Post by mikece »

xxpor wrote: post #20
yjftsjthsd-h wrote: post #16

Earlier quoted context omitted.

I use it on my desktop:) It's a nice experience after a slight learning curve; I'm particularly fond of it supporting ZFS well without being Ubuntu. Musl libc is a potential pain point; I get most software from official repos or build from source, but ex. to run Steam I resorted to flatpak (which just shoves glibc in the container with the application).

For an average user, I'd guess they'd hit more issues with busybox than musl.

Are there any (lightweight?) desktop distros built atop Alpine as a base?

Re: Alpine Linux 3.15

#24

Post by yjftsjthsd-h »

xxpor wrote: post #20
yjftsjthsd-h wrote: post #16

Earlier quoted context omitted.

I use it on my desktop:) It's a nice experience after a slight learning curve; I'm particularly fond of it supporting ZFS well without being Ubuntu. Musl libc is a potential pain point; I get most software from official repos or build from source, but ex. to run Steam I resorted to flatpak (which just shoves glibc in the container with the application).

For an average user, I'd guess they'd hit more issues with busybox than musl.

If you care, just install the `coreutils` package and it'll overwrite the default symlinks and you'll get GNU coreutils by default.

Re: Alpine Linux 3.15

#26

Post by scandinavian »

qwertox wrote: post #21
pionar wrote: post #3

Earlier quoted context omitted.

Not really. It's not designed for that. It's designed to be as lightweight as possible. also, instead of Glibc, it uses musl, which although is supposed to be binary-compatible, does have some gotchas, so the larger the system, with more apps and libraries running on it expecting glibc, will have issues.

musl really becomes a pain if you work a lot with Python. You can't use wheels, which means you will have to compile everything yourself, which sometimes takes ages, and you're not guaranteed that it won't have unnoticeable errors. My biggest issue was with the 3.12 -> 3.13 transition, when musl got upgraded to 1.2 and with it "musl 1.2 uses new time64-compatible system calls". This broke so many things for me withou…

> You can't use wheels

musl wheel support was added some time ago:

https://github.com/pypa/packaging/releases/tag/21.0

No idea how many packages actually build musl wheels though. From a quick glance at least cryptography and lxml has musl wheels.

Re: Alpine Linux 3.15

#27

Post by wahern »

qwertox wrote: post #21
pionar wrote: post #3

Earlier quoted context omitted.

Not really. It's not designed for that. It's designed to be as lightweight as possible. also, instead of Glibc, it uses musl, which although is supposed to be binary-compatible, does have some gotchas, so the larger the system, with more apps and libraries running on it expecting glibc, will have issues.

musl really becomes a pain if you work a lot with Python. You can't use wheels, which means you will have to compile everything yourself, which sometimes takes ages, and you're not guaranteed that it won't have unnoticeable errors. My biggest issue was with the 3.12 -> 3.13 transition, when musl got upgraded to 1.2 and with it "musl 1.2 uses new time64-compatible system calls". This broke so many things for me withou…

OpenBSD went through a similar transition, except they didn't even try to maintain ABI compatibility. See https://www.openbsd.org/55.html and https://www.openbsd.org/faq/upgrade55.html, the latter describing the rare "flag day" event. Long term this was good for OpenBSD as it saved a ton of unnecessary cruft and complexity that would have haunted OpenBSD for years if not decades, endlessly taxing developers' time, especially of core developers. And it was an inducement for all developers, those working on OpenBSD (core and ports teams) as well as those targeting OpenBSD, to carefully review code for 64-bit time_t safety. But it necessarily required that the broader community shoulder a large part of the transition burden.

Sometimes it's better to power through with a massive labor effort than to try to use fancy hacks to shield people from latent problems. All things considered, it doesn't sound like the Alpine transition was that bad. But it's the type of thing that most Linux users and developers are not accustomed to, at least those who don't remember the very early years. Ironically, musl libc might not exist if glibc hadn't accumulated so much complexity trying to maintain strong ABI compatibility.

IMO, small prices to pay for free software and Free Software.

Re: Alpine Linux 3.15

#28

Post by xxpor »

yjftsjthsd-h wrote: post #24
xxpor wrote: post #20

Earlier quoted context omitted.

For an average user, I'd guess they'd hit more issues with busybox than musl.

If you care, just install the `coreutils` package and it'll overwrite the default symlinks and you'll get GNU coreutils by default.

Oh thanks, that's good to know they're available.

Re: Alpine Linux 3.15

#30

Post by frankjr »

I've just upgraded from 3.14 and everything seems to be running well. I'm always amazed how incredibly fast the package manager is (apk). If you think Arch's pacman is fast, this is still on another level.
Post reply on HN