4 ms·

This is inherently broken, and its brokenness is not obvious or clearly attributable to the hacky glibc. Imagine debugging an app on this (and possibly not eve

This is inherently broken, and its brokenness is not obvious or clearly attributable to the hacky glibc. Imagine debugging an app on this (and possibly not even knowing it's based on an unofficial base image) not knowing this very specific behavior for hours with no results, you'd probably have a very bad impression of alpine.

akerl_ 5y ago
I don’t think anybody is arguing that shoving glibc into an Alpine image is a great idea. But if I decided to make an “alpine-goofy” image where I started with “FROM alpine” and then renamed all the binaries so cp was rm and rm was ls and so on, it would be a stupid idea but not trademark infringement. Could this project do everybody a favor by adding a banner saying “Hey y’all just FYSA we are not affiliated w/ Alpine upstream, please don’t send them glibc support requests”? Totally. But I’m shocked that Alpine’s approach here is to start by trying to implement a technical blocker for what I can install on my Alpine image, with an offhand remark that maybe they could try talking to the image owner first.
- sascha_sl 5y ago
  These are completely different situations. Wanting glibc compat on Alpine is not an unusual requirement, unlike your "alpine-goofy" image, and the bugs it introduces are subtle and may not show up at all in some use-cases. Believe it or not, a lot of developers aren't aware we have different libc implementations at all, the "exec format error" or "file not found" errors alpine spits out already create a lot of support burden.
  - akerl_ 5y ago
    The fact that a downstream image is popular doesn’t make it sane for upstream to want to literally block its existence via code changes.
    - ariadneconill 5y ago
      the only thing the proposed change does is encode something that is already factual: if you install that glibc package, you have a high likelihood of breaking your system. it's not like we are blocking it in apk-tools, and you can roll your own musl package with the conflict removed by simply building it with the `ALLOW_GLIBC_PKG` option.
      - akerl_ 5y ago
        It feels like you’re splitting hairs. No, you’re not blocking it in apk-tools, and yes, a user can work around the change you’re making to continue doing what they want. But your post directly says “I have also proposed an update to Alpine which will block the installation of the glibc packages produced by the alpine-glibc project”. So I’m not sure how describing it as “blocking this downstream project” could possibly be inaccurate.
        ariadneconill 5y ago
        I am proposing that we encode something that is already factually accurate: glibc and musl generally do not mix in any way that results in a stable system. Do you not think that distributions should make even a little bit of effort to introduce friction toward scenarios known to break systems? If apk-tools had a soft conflict option, where it printed a warning and required the user to acknowledge that warning somehow before continuing, that would also solve the issue as far as I am concerned, but it does not have such an option at this time, and we need to put our foot down sooner rather than later. Edit: besides, nothing has been implemented. This is just one proposal, the point of having a conversation is to determine what the best option for solving this issue is.
        MrStonedOne 5y ago
        alpine exists in the open source space and must behave like an open source project. You don't get to tell your users how to use your project. That is the entire fucking point of open source software.
d3nj4l 5y ago
> Imagine debugging an app on this (and possibly not even knowing it's based on an unofficial base image) not knowing this very specific behavior for hours with no results, you'd probably have a very bad impression of alpine. That's fine! I've seen this happen with Rails all the time: newbies do something in Rails behaves differently in Rails than in vanilla Ruby, because Rails redefines core Ruby classes in ActiveSupport, and they get frustrated and angry when the thing they've copied from elsewhere doesn't work as they expect. Whether that's good or not is another matter, but that doesn't mean Ruby should prevent people from running Rails! You really shouldn't be obsessed with people liking your project to the point where you prevent anybody from doing anything with it that you haven't personally authorized.
- riwsky 5y ago
  That’s a bad analogy. Use of Rails isn’t broken on a technical level; use of glibc on alpine is.
- ariadneconill 5y ago
  Not the same argument. Combining musl and glibc runtimes into a single system is known to result in instability. Whether it gets documented as part of a "don't do weird things" system or this update gets accepted, it needs to be addressed, as people have erroneously expected this configuration to have the same stability guarantees as stock Alpine.

akerl_ 5y ago

I don’t think anybody is arguing that shoving glibc into an Alpine image is a great idea. But if I decided to make an “alpine-goofy” image where I started with “FROM alpine” and then renamed all the binaries so cp was rm and rm was ls and so on, it would be a stupid idea but not trademark infringement. Could this project do everybody a favor by adding a banner saying “Hey y’all just FYSA we are not affiliated w/ Alpine upstream, please don’t send them glibc support requests”? Totally. But I’m shocked that Alpine’s approach here is to start by trying to implement a technical blocker for what I can install on my Alpine image, with an offhand remark that maybe they could try talking to the image owner first.

sascha_sl 5y ago
These are completely different situations. Wanting glibc compat on Alpine is not an unusual requirement, unlike your "alpine-goofy" image, and the bugs it introduces are subtle and may not show up at all in some use-cases. Believe it or not, a lot of developers aren't aware we have different libc implementations at all, the "exec format error" or "file not found" errors alpine spits out already create a lot of support burden.
- akerl_ 5y ago
  The fact that a downstream image is popular doesn’t make it sane for upstream to want to literally block its existence via code changes.
  - ariadneconill 5y ago
    the only thing the proposed change does is encode something that is already factual: if you install that glibc package, you have a high likelihood of breaking your system. it's not like we are blocking it in apk-tools, and you can roll your own musl package with the conflict removed by simply building it with the `ALLOW_GLIBC_PKG` option.
    - akerl_ 5y ago
      It feels like you’re splitting hairs. No, you’re not blocking it in apk-tools, and yes, a user can work around the change you’re making to continue doing what they want. But your post directly says “I have also proposed an update to Alpine which will block the installation of the glibc packages produced by the alpine-glibc project”. So I’m not sure how describing it as “blocking this downstream project” could possibly be inaccurate.
      - ariadneconill 5y ago
        I am proposing that we encode something that is already factually accurate: glibc and musl generally do not mix in any way that results in a stable system. Do you not think that distributions should make even a little bit of effort to introduce friction toward scenarios known to break systems? If apk-tools had a soft conflict option, where it printed a warning and required the user to acknowledge that warning somehow before continuing, that would also solve the issue as far as I am concerned, but it does not have such an option at this time, and we need to put our foot down sooner rather than later. Edit: besides, nothing has been implemented. This is just one proposal, the point of having a conversation is to determine what the best option for solving this issue is.
        MrStonedOne 5y ago
        alpine exists in the open source space and must behave like an open source project. You don't get to tell your users how to use your project. That is the entire fucking point of open source software.

d3nj4l 5y ago

> Imagine debugging an app on this (and possibly not even knowing it's based on an unofficial base image) not knowing this very specific behavior for hours with no results, you'd probably have a very bad impression of alpine. That's fine! I've seen this happen with Rails all the time: newbies do something in Rails behaves differently in Rails than in vanilla Ruby, because Rails redefines core Ruby classes in ActiveSupport, and they get frustrated and angry when the thing they've copied from elsewhere doesn't work as they expect. Whether that's good or not is another matter, but that doesn't mean Ruby should prevent people from running Rails! You really shouldn't be obsessed with people liking your project to the point where you prevent anybody from doing anything with it that you haven't personally authorized.

riwsky 5y ago
That’s a bad analogy. Use of Rails isn’t broken on a technical level; use of glibc on alpine is.
ariadneconill 5y ago
Not the same argument. Combining musl and glibc runtimes into a single system is known to result in instability. Whether it gets documented as part of a "don't do weird things" system or this update gets accepted, it needs to be addressed, as people have erroneously expected this configuration to have the same stability guarantees as stock Alpine.