5 ms·

I don't get it. There's a docker image called alpine-ruby. I presume that isn't supported by the alpine team either, but, honestly speaking, I'm doubtful that's

by d3nj4l 5y ago

I don't get it. There's a docker image called alpine-ruby. I presume that isn't supported by the alpine team either, but, honestly speaking, I'm doubtful that's causing enough of a support load on them. If it is, I would assume the reasonable solution to that is to close any support requests with "We are not responsible for that image" or something of that variant, or even requesting the creator of the image to mention that in the docs, but preventing users from installing ruby on alpine (!!!), not just images?

sascha_sl 5y ago
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.
- 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.
dijit 5y ago
> There's a docker image called alpine-ruby. There may be, but that seems dangerous. Frankly you can name a dockerhub entry anything you like as long as it's not taken. But you probably wanted ruby:alpine anyway.
- d3nj4l 5y ago
  > Frankly you can name a dockerhub entry anything you like as long as it's not taken. Yeah, definitely, just like you can name a library like Vue vue.js. Does that mean Vue is an official project of the JS Committee? No, of course not! It's bizarre to think otherwise, and that doesn't mean Vue should avoid using js in its name because somebody could get confused. Putting something like ".js" or "rb" (like in "dry-rb") in a name is a signal for a target, and not always trademark infringement.
cormacrelf 5y ago
There’s a solution to all of these problems, tried and tested, and older than the concept of package registry namespacing called “registering a trademark and sending a cease and desist letter”. Works great.

by d3nj4l 5y ago

sascha_sl 5y ago

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

dijit 5y ago

> There's a docker image called alpine-ruby. There may be, but that seems dangerous. Frankly you can name a dockerhub entry anything you like as long as it's not taken. But you probably wanted ruby:alpine anyway.

d3nj4l 5y ago
> Frankly you can name a dockerhub entry anything you like as long as it's not taken. Yeah, definitely, just like you can name a library like Vue vue.js. Does that mean Vue is an official project of the JS Committee? No, of course not! It's bizarre to think otherwise, and that doesn't mean Vue should avoid using js in its name because somebody could get confused. Putting something like ".js" or "rb" (like in "dry-rb") in a name is a signal for a target, and not always trademark infringement.

cormacrelf 5y ago

There’s a solution to all of these problems, tried and tested, and older than the concept of package registry namespacing called “registering a trademark and sending a cease and desist letter”. Works great.