6 ms·

Be careful, it using musl instead of glibc can be a headache, especially if you ever use any pre-compiled software.

by boardwaalk 5y ago

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.
- 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.
ksec 5y ago
>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.
wizzardy 5y ago
Exactly the reason I don't recommend Alpine! It's a pain to compile a custom service with multiple dependencies for this distro.
fouric 5y ago
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).
- zamadatix 5y ago
  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.
  - container 5y ago
    I think compiling usually comes in when it's not in the repo or proprietary.
zzyzxd 5y ago
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.
- stonogo 5y ago
  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.
  - zzyzxd 5y ago
    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.

Be careful, it using musl instead of glibc can be a headache, especially if you ever use any pre-compiled software.

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.

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.

ksec 5y ago

>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.

wizzardy 5y ago

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

fouric 5y ago

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

zamadatix 5y ago
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.
- container 5y ago
  I think compiling usually comes in when it's not in the repo or proprietary.

zzyzxd 5y ago

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.

stonogo 5y ago
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.
- zzyzxd 5y ago
  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.