5 ms·

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

by swiley 5y ago

horstmeyer 5y ago
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.
- nickjj 5y ago
  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.
- bassdropvroom 5y ago
  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.
  - d18g 5y ago
    PEP: https://www.python.org/dev/peps/pep-0656/ https://www.python.org/dev/peps/pep-0656/
    - horstmeyer 5y ago
      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-247381915 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.
  - deleted 5y ago
    [deleted]
aidenn0 5y ago
Nearly all proprietary software is distributed that way.
- nicoburns 5y ago
  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.
  - nix23 5y ago
    Welcome to hackernews where you get down-voted for saying one should not use proprietary software...mac generation i suppose ;)
    - kjeetgill 5y ago
      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.
    - phendrenad2 5y ago
      The real question is, when did "don't use proprietary software" become an acceptable thing to say to people?
      - nix23 5y ago
        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.
jcelerier 5y ago
That this is acceptable in any way is ridiculous
- oblio 5y ago
  Stockholm syndrome.
- nix23 5y ago
  Yeah but the other way around, it should not be acceptable that you have to use pre-compiled proprietary software.
- kjeetgill 5y ago
  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!
  - jcelerier 5y ago
    > 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.

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

by swiley 5y ago

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.

nickjj 5y ago
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.
bassdropvroom 5y ago
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.
- d18g 5y ago
  PEP: https://www.python.org/dev/peps/pep-0656/ https://www.python.org/dev/peps/pep-0656/
  - horstmeyer 5y ago
    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-247381915 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.
- deleted 5y ago
  [deleted]

aidenn0 5y ago

Nearly all proprietary software is distributed that way.

nicoburns 5y ago
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.
- nix23 5y ago
  Welcome to hackernews where you get down-voted for saying one should not use proprietary software...mac generation i suppose ;)
  - kjeetgill 5y ago
    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.
  - phendrenad2 5y ago
    The real question is, when did "don't use proprietary software" become an acceptable thing to say to people?
    - nix23 5y ago
      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.

jcelerier 5y ago

That this is acceptable in any way is ridiculous

oblio 5y ago
Stockholm syndrome.
nix23 5y ago
Yeah but the other way around, it should not be acceptable that you have to use pre-compiled proprietary software.
kjeetgill 5y ago
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!
- jcelerier 5y ago
  > 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.