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.