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.
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.
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.
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.
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.
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.
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.
You don't get to tell your users how to use your project.
That is the entire fucking point of open source software.
That said, there is not a universal mandate for how an open source project “must behave”, other than that the terms of the license (which the authors of the code are able to choose). There isn’t a single cohesive “entire fucking point” of open source. The things proposed in the blog post are permissible under the license, are able to be bypassed by the user, and are not some earthshattering affront to human decency.
We should be able to disagree about the best course of action without falling into incendiary accusations.
Sure I guess but "don't footgun yourself" is pretty different. But I guess some people just like using linux for the novelty of breaking shit and feeling smart about fixing it.
https://github.com/docker-library/official-images/pull/10779...
This is also a response to inclusion of this broken mess into official docker images, I think alpine putting their foot down is entirely justified here.
and, the conflict option is one of a few options being considered. part of what lead up to this is the fact that we have not taken any public position on mixing glibc and musl runtimes until now.
no decision has been made, and won't be made until the TSC meeting next week...
You could have, before even writing the blog post, posted an issue on their GitHub to try seeing if they can post a more noticeable disclaimer... although it doesn't really even need one and is pretty inherent, just like all the other Docker Hub images using Alpine in their name to indicate the underlying distro.
The problem is that third parties take his package and then describe the combination of Alpine with his package in such a way that people are led to believe is totally stock Alpine.
This then causes many people to complain in Alpine support channels, or on websites like this one, that Alpine is "buggy" in ways that cannot be reproduced on real Alpine.
You also assume that this is our first reaction.
Our first reaction was 6 years ago when it first came out: meh.
No, this is our first reaction to a large company trying to pass off their hackjob images combining Alpine, glibc and a glibc JDK as a certified JDK that is running on stock Alpine.
It is unfortunate that we have waited this long to put our foot down, honestly!
We need to support our friends in the Docker community who manage the Docker Library who also get to deal with the fallout of these hackjob images.
The person who makes the hackjob rarely faces the consequences of it breaking, that basically has always fallen on us, or on the Docker Library team, or on some other team in the ecosystem that has to deal with somebody who is mad because their application has failed due to some shoddy work done by somebody 2 years ago.
Stop assuming this is our "first" reaction. It isn't. I even said it wasn't to begin with -- a "first" reaction cannot logically be an escalation from a previous position, it must be an initial one.
> The problem is that third parties take his package and then describe the combination of Alpine with his package in such a way that people are led to believe is totally stock Alpine.
You were specifically trying to block the package from being installed without recompiling musl.
> This then causes many people to complain in Alpine support channels, or on websites like this one, that Alpine is "buggy" in ways that cannot be reproduced on real Alpine.
You're putting too much pressure on yourself. This is simple... if someone isn't using the official Alpine image (alpine) then they should ask for support from the image creator, as there are thousands of things that can go wrong outside of you control.
> No, this is our first reaction to a large company trying to pass off their hackjob images combining Alpine, glibc and a glibc JDK as a certified JDK that is running on stock Alpine.
Labeling other developers work as hackjob images is condescending. Your whole post was condescending. Just because someone has alpine in an image tag doesn't mean that they are trying to indicate that it uses stock Alpine as the base image, but instead that it uses Alpine as the underlying distro. Who knows what software or changes they've added to it that may cause issues outside of Alpine's control.
> It is unfortunate that we have waited this long to put our foot down, honestly!
> We need to support our friends in the Docker community who manage the Docker Library who also get to deal with the fallout of these hackjob images.
> The person who makes the hackjob rarely faces the consequences of it breaking, that basically has always fallen on us, or on the Docker Library team, or on some other team in the ecosystem that has to deal with somebody who is mad because their application has failed due to some shoddy work done by somebody 2 years ago.
Seriously, these comments only show that this is more about control for you than anything. I can't say for sure, but I have a feeling that eventually other people in the community will either leave or ask you to leave for toxic behavior like this.
You ignore the point I am making: people are already fighting this issue for years, and Alpine has not taken a position on it until now.
We should have done so sooner, but unfortunately we did not, so a more theatric approach is sometimes needed to make a point.
We want to discourage bad practices in the creation of alpine-based images, so that our partners (such as the Docker library team) do not have to deal with user complaints with images, or feel like companies are bullying them into accepting images they know are built with bad practices.
If you call taking action to provide assistance requested by our ecosystem partners (who have been thrilled that we are putting our foot down by the way) toxic behavior I wouldn’t want to know what your idea of a party is to be blunt.
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.
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.