This, from what I can see, makes Alpine rather less suitable to being a desktop OS than an embedded OS. I don't want to compile everything from source, and sometimes I can't (e.g. Steam, Dropbox).

Not sure where compiling comes in, either it's proprietary or it's in the repo the same as any other distro.

Another point for flatpak/snap style proprietary apps distribution though - they don't assume anything about the distro will be there.

I think compiling usually comes in when it's not in the repo or proprietary.

Specifically in container space, when I chatted with other developers regarding reasons of choosing Alpine, the top one answer is the size of the base image comparing to other popular Linux distro images like Ubuntu or Debian. Smaller size => faster rollout + minimal CVE exposure, right? What I feel fundamentally wrong about this is, in many cases they probably shouldn't put a full OS in a container in the first place. Take Google's distroless as an example, if you only put necessary stuff in your container, even a debian based image can be reasonably small enough that you never need to worry about image size.

Also, dealing with DNS issues in Alpine based containers (which was caused by musl implementation, iirc) was one of my biggest nightmare at work. Just search for "Alpine+DNS" on Google and you can see what a mess it had brought.

I think these points aren't really fair, since Alpine predates a lot of the work that went into making the alternatives possible. Alpine predates Distroless by over a decade, for example.

As for DNS, it's extremely unfair to blame musl for properly implementing the POSIX standards for name resolution. It's not Alpine's fault that so many people wrote software which explicitly depended on specific glibc quirks. If anything, it's a good lesson on the dangers of monocultures, and how even FOSS software is at risk.

I agree with you that it is not Alpine's fault for not being as good as today's Distroless 10 years ago. In fact it is still my favorite tool for several use cases (e.g., injecting a sidecar container for adhoc debugging).

What I was trying to say, was that many people choose it for wrong reasons without fully understanding the implications. This included us. It was a nightmare to me because at that time I didn't know it has different behavior in DNS resolution. And our developers expected their code, which ran fine on their workstations and in CI (Ubuntu/Debian environments), to behavior the same when running in an alpine container in production.

>it using musl instead of glibc

This, I remember jemalloc and musl/ Alpine issues. In the end it just isn't worth the hassle. Although that was may be two years ago.

Exactly the reason I don't recommend Alpine! It's a pain to compile a custom service with multiple dependencies for this distro.

pre-compiled software outside your distro's repos is always going to be a headache, you really shouldn't be doing that.

It's pretty popular to install Python C-extensions from packages, called wheels. Otherwise you need to compile from source, which means you need build dependencies. So Python and Alpine doesn't really go that well together. In my experience debian-slim as Docker base image is also small, and less painful.

I remember trying out and writing about Alpine vs Debian in the context of Docker images a few years ago and I remember someone commented saying with Alpine they got substantially worse performance when using Python to connect to a PostgreSQL database using the official Python pg package (it requires C dependencies) in an isolated benchmark that performed a bunch of reads.

I don't base any decisions around micro benchmarks but that example struck me as interesting because this was a case where the performance difference between using Alpine and Debian was real and affected user level applications.

For the last few years I also run Debian Slim for my base Docker images and don't worry about it.

Yes my images might be a little larger than Alpine but it's non-issue in the real world. For smaller scale deploys once the base image is pulled down initially it's there in both cases, so now it comes down to pulling app level changes (code or package deps) which is comparable in size with both distros.

And for huge scale deployments it doesn't matter because typically you'd use custom ISOs with as much pre-loaded static content as possible, so you could easily bake in a specific Debian Slim image into the ISO so when you pull down your application image at deploy time it skips having to pull the base image entirely negating any wins that Alpine might have had for pull speeds and network usage.

Sure Alpine has less attack surface since it's a smaller code base but we're comparing it to Debian here. They have a 28 year track record of being unbelievably dependable and well supported.

As I understand it, wheels support is coming to musl. I cannot remember where I read this, but it must have been on some issue related to this.

PEP: https://www.python.org/dev/peps/pep-0656/

That's cool! It is already possible to allow installation of many wheels in a hacky way: https://github.com/pypa/pip/issues/3969#issuecomment-2473819...

But that's a pretty bad idea in most cases I guess. Good to see that Musl might be supported properly.

Nearly all proprietary software is distributed that way.

There are obviously exceptions where you absolutely have to use proprietary software. But if you can possibly help it, you probably shouldn't be doing that.

Welcome to hackernews where you get down-voted for saying one should not use proprietary software...mac generation i suppose ;)

It's a thread about a Linux distro and further a thread about some complications one might run into versus others. If someone's concerned about a problem with pre-compiled proprietary software, particularly one you know they'd rather not have either, jumping in with a Har Har try not to have that problem isn't ... well it's just flat humor. Nothing mean or bad just, downvotably flat?

I don't think it's any sort of Mac generation downvoting, I think it's more the opposite: they're preaching to the choir. Yea. We Know.

The real question is, when did "don't use proprietary software" become an acceptable thing to say to people?

Since around 1975-80, when software makers stop'd giving you the source-code with the license to use it, and just gave you the compiled unchangeable product?

Not is it just acceptable, it's your obligation to tell peoples what the downside (or upside) of closed down software is. Is a closed source webserver a good idea? probably not. Is THE closed source Photo-editing program a good idea? Probably yes....if you really need it.

Mac generation? Maybe if you mean those whose first computing experience was with microcomputers in the 80s. Every single program I used for the first ~14 years (1984 to 1998, when I first used Linux) of my computing experience was proprietary.

That this is acceptable in any way is ridiculous

I find your and nix23's responses to be precious. Acceptable? It's free software! Take it for what it is, appreciate it, and adopt it if it suits you?

To contradict myself: I do find myself frustrated when 'obvious thing that should work' doesn't but I save that ire for things that break between versions!

> It's free software! Take it for what it is, appreciate it, and adopt it if it suits you?

I am really against the idea that just because something is "free", it is exempt of any judgment. We should always strive to improve everything, free or not.

Yeah but the other way around, it should not be acceptable that you have to use pre-compiled proprietary software.

Stockholm syndrome.