[HN Gopher] There is no such thing as a "glibc based alpine image"
___________________________________________________________________
There is no such thing as a "glibc based alpine image"
Author : Tomte
Score : 277 points
Date : 2021-08-26 07:49 UTC (15 hours ago)
(HTM) web link (ariadne.space)
(TXT) w3m dump (ariadne.space)
| hygh wrote:
| musl's thread stack size is too low (128K), so many open source
| test suites segfault.
|
| I do not understand why musl doesn't move to at least 512K like
| OSX.
|
| The generous 8192K glibc thread stack size isn't _actually used_
| on Linux with overallocation, so I fail to see why musl chose
| that small default in the first place.
| temac wrote:
| > The generous 8192K glibc thread stack size isn't actually
| used on Linux with overallocation
|
| Is it even (over)committed? The main reason for having a max
| stack size is multithreading, but I'm not sure why it should be
| committed at all. Surely, an unbounded single thread stack is
| not precommitted to infinity?
| synergy20 wrote:
| maybe, musl by design, is for resource limited embedded boxes.
| multiple threads with large stack size will eat up RAM. If you
| need larger thread stack I believe you can set it in the code.
|
| "Since 1.1.21, musl supports increasing the default thread
| stack size via the PT_GNU_STACK program header, which can be
| set at link time via -Wl,-z,stack-size=N." Of course you can
| always use pthread_attr_setstacksize
| glb100 wrote:
| > Of course you can always use pthread_attr_setstacksize.
|
| No you can't, not with std::thread, which makes std::thread
| nearly unusable with musl.
| masklinn wrote:
| > maybe, musl by design, is for resource limited embedded
| boxes. multiple threads with large stack size will eat up
| RAM.
|
| It won't really: that's vmem, it'll only need a bit of memory
| for the accounting of the mappings in the kernel.
| wwarner wrote:
| The post correctly argues that linking across systems is unwise
| and unsound, but in making the argument it shows how valuable a
| consistent ABI is.
| rurban wrote:
| It should be called atlas-glibc or even himalaya-glibc, not
| related to alpine at all.
| encryptluks2 wrote:
| Why? This is a package, not a fork of the project.
| croes wrote:
| And if I need glibc for alpine how do I search for it?
| WesolyKubeczek wrote:
| If you want glibc, why use Alpine? Mainstream distributions are
| for glibc. Alpine exists specifically as a musl-based thing.
| IshKebab wrote:
| Yeah I thought the whole point of Alpine was that it abandoned
| the insanity of glibc for the relative sanity of musl.
|
| My only guess is that they like Alpine but want to run some
| binary software that links with glibc.
| hibikir wrote:
| An unfortunate reality of development today is that we have
| developers with little to no systems experience having to
| decide on base images, even though they haven't built any
| expertise on OSs. It makes perfect sense for this to happen:
| A different OS is a line away in a docker file, and they have
| to pick something!
|
| Among this rather large crowd, Alpine is popular for just one
| reason: it's small, and dealing with large images is more
| annoying, everything else being equal. But alpine and, say,
| ubuntu, aren't always equal. Those people then find one of
| the ugliest differences, often related to musl, or something
| they are using relying on glibc-like behavior, and then get
| to choose between a hack like this, or much larger images.
|
| As an example my organization was moving everything to
| alpine, but as part of the switch we found out that some
| computationally heavy tasks were getting significantly worse
| performance under alpine than with a glibc-based distro,
| mainly due to the relatively well documented issues with
| memory allocation performance. It'd not be surprising that
| someone finding themselves in this kind of situation ends up
| just adding glibc to alpine, instead of switching back, or
| figuring out how to tweak the memory allocator.
| branneman wrote:
| Yes. Exactly this.
| mattbnr32 wrote:
| 100%
| jart wrote:
| This is one of the reasons why I've been building
| Cosmopolitan Libc. https://github.com/jart/cosmopolitan
| Alpine and Musl aren't radical enough on the bloat-free
| angle (since they don't fix root problem which is dynamic
| shared objects) and their definition of portability is
| supporting architectures like sega saturn but do nothing to
| support intel/amd microarchitectural dispatching, which is
| likely why you encountered performance issues. It's like, I
| love Musl so much, but I just didn't see the value in being
| able to port my apps to Sega Saturn if my C Library only
| runs on Linux and has suboptimal performance on x86.
|
| [side note] I seem to recall there being something about
| the the way the musl header files are written that
| basically throws a wrench into any scientific computing
| code that's compiled with it. Might have something to do
| with security like those checks intended to prevent people
| from overlapping memcpy so someone should totally fix that.
| yjftsjthsd-h wrote:
| > My only guess is that they like Alpine but want to run some
| binary software that links with glibc.
|
| There's also gcompat for that, although I don't know how
| comprehensive that is
| stu2010 wrote:
| musl is definitely more developer-friendly than glibc, which
| may lead to a brighter future for it, but right now at this
| time there's significant downsides to choosing musl.
|
| Performance in real world applications is worse on musl vs
| glibc, at a level that can result in higher latencies and
| needing to spend more on compute resources to serve a given
| level of load.
| ekimekim wrote:
| I want to use alpine for my containers because it's a
| minimalist distro with a nice package manager with up-to-date
| packages. Reasons I don't like common alternatives:
|
| * ubuntu - Increasingly hostile to container usage (I tried to
| install a package recently, the install "succeeded" but at
| runtime the installed binary simply printed 'oh actually this
| is a stub, use snap instead' and exited), along with all the
| other downsides of debian (see below)
|
| * debian - Very old packages if you're running a supported
| version. There's a ton of boilerplate to make apt behave itself
| in a container environment, something like "apt-get update &&
| DEBIAN_FRONTEND=non-interactive apt-get install --assume-yes
| --no-install-recommends PACKAGE", compare to "apk --update add
| PACKAGE".
|
| * distroless - More work to create and manage, can't install
| things ad-hoc in a running container for debugging purposes
|
| As it is, I use debian and put up with the annoyances and need
| to occasionally install things from source to get a modern
| version. But there's really no good options. Alpine would be
| amazing, except I've hit too many problems with musl (though
| I'm sure it's not actually musl's fault). If someone was
| advertising "alpine but with glibc" and it actually WAS that
| (not "alpine with glibc tacked on top"), I'd use it in a
| heartbeat.
| WesolyKubeczek wrote:
| > ubuntu - Increasingly hostile to container usage (I tried
| to install a package recently, the install "succeeded" but at
| runtime the installed binary simply printed 'oh actually this
| is a stub, use snap instead' and exited)
|
| Was it chromium?
| vbezhenar wrote:
| What about RedHat or CentOS images? Check out
| redhat/ubi8-minimal for example.
| ariadneconill wrote:
| +1 for a glibc-based Alpine-ish distribution. a few Alpine
| folks have made them over the years, but they never gained
| traction.
| WesolyKubeczek wrote:
| Have you ever heard of Fedora? They have a base container
| image.
| jleahy wrote:
| Arch?
| eckesicle wrote:
| I've not used this particular image myself but I have installed
| glibc in an alpine image, then compiled some code and copied that
| over to run on the scratch image as part of a multi-stage build.
|
| Super useful as alpine is a small image and with none of the
| drawbacks mentioned in the blog post.
| sgerrand wrote:
| Maintainer of the Alpine glibc package referenced here. For some
| background context, this package was originally created to solve
| a specific problem long before Alpine provided glibc
| compatibility packages like `libc6-compat` and others. I agree
| that this package shouldn't be considered "blessed" or an
| official Alpine package or a default solution for running
| programs originally compiled against the GNU C library on Alpine
| Linux, far from it. The source control repository uses `alpine-
| pkg-` as a prefix to denote what it's used for--not as a means of
| assumed official status or such like.
|
| What I find saddening is to see passive aggressive statements
| like
|
| > I have additionally suggested that the TSC may wish to have the
| Alpine Council reach out to the alpine-glibc project to find a
| solution which appropriately communicates that the project is not
| supported in any way by Alpine.
|
| To the Alpine Linux TSC: please get in contact with me about any
| and all disclaimers you want to add to this package! I'd love to
| have these discussions faster and in the open, rather than
| discovering this disquiet tangentially. Let's get these issues
| resolved as soon as possible in a way that everyone concerned
| finds acceptable.
| eqvinox wrote:
| You have a communication issue in that people assume you're
| providing something Alpine "official".
|
| They have a communication issue in this escalation
| (TSC/Council) before trying to simply talk to you.
|
| I'm not gonna blame either of you.
| ariadneconill wrote:
| We did not communicate with Sasha because bluntly, we have no
| objection to the existence of this package itself, but rather
| third parties distributing the combination to others without
| disclosing the many caveats about it.
|
| Sasha's package is not the problem, it is the third-party
| distributors who distribute the final result as an "alpine"
| image, which leads people to believe that everything is legit
| about it.
| t0mas88 wrote:
| The whole blog post reads a bit hot headed, even more so if
| this is step one instead of first reaching out to a fellow
| open source community member.
| fao_ wrote:
| A comment you're next to written by the post author 20
| minutes before you wrote this one, suggests that is not the
| case.
| elzbardico wrote:
| What a load of bs! If they have any issue with your project why
| not just open an issue?
| pxc wrote:
| j/w: What use cases do you have or have in mind for your glibc
| package? Do you see it as a temporary step for adding pre-built
| things to Alpine images during development, before you have
| time to rebuild them against musl? Do you feel some prod use
| cases are 'safe enough'?
|
| Or nowadays do you generally prefer the upstream compatibility
| packages you mentioned?
| sgerrand wrote:
| I don't compile my own software against glibc and run it in
| Alpine. As mentioned previously, this package was created ~ 6
| years ago to run software compiled against glibc (that didn't
| have the source code available) in Alpine Linux. I don't
| recommend that anyone uses it over the equivalent Alpine
| package or compiling your software against musl-c.
| pxc wrote:
| Gotcha. Sorry your obsolete workaround is being painted as
| new and borderline malicious. :-\
| [deleted]
| peter_l_downs wrote:
| And it's been very useful for exactly that purpose -- thank
| you for providing it (happy user here!)
| ricardobeat wrote:
| This post would have done fine without the whole "we do not
| approve" / "we need to take them down" attitude.
|
| Call it a terrible idea, explain why, recommend against it, and
| be done with it; one shouldn't need approval to maintain a fork,
| and they are not misrepresenting what it is. I find the animosity
| a little off-putting.
| lalaithion wrote:
| The only reason to have the "we need to take them down"
| attitude would be if they are violating your license or glibc's
| license.
| lalaithio-glibc wrote:
| Using the same name can also be considered inapproriate.
| sgerrand wrote:
| Maintainer of the Alpine package referenced here. The same
| name for what? The package name is `glibc`. I think you're
| confusing/conflating the source control repository's name
| with the package when they are different things.
| r1ch wrote:
| I think this comes from them using "Alpine" in the name for
| something that is not from the Alpine Linux team nor desired /
| supported by them. Users could be confused into thinking it's
| something officially supported and clog up official support
| channels with unrelated issues.
| sgerrand wrote:
| Maintainer of the Alpine package you referenced here. I'm not
| a "them". ;)
|
| I don't see where "Alpine" is used in the package name,
| unless you're referring to the source repository name. In
| case it isn't clear, `alpine-pkg-` is a prefix which denotes
| that the repository contains an Alpine Linux package manifest
| and configuration. There's nothing in the repo itself which
| states that this package is published and/or endorsed by
| Alpine Linux.
| gnud wrote:
| I think they're talking about things like
| https://hub.docker.com/r/frolvlad/alpine-glibc or
| https://hub.docker.com/r/jeanblanchard/alpine-glibc
| sgerrand wrote:
| Ah, thanks for the pointer. The blog post referenced the
| Alpine package I maintain but was obviously implicitly
| referencing those Docker images.
| ariadneconill wrote:
| Yes, there's several of them. The problem isn't your
| package, but the distribution of "alpine" images that
| integrate the package. Those images should describe
| themselves more appropriately.
| MrStonedOne wrote:
| Alpine is free to provide a _solution_ to the problem then.
|
| Complaining about the problem isn't going to be productive,
| and until they publicize a way to convey you are a fork of
| the alpine project they will have this issue.
|
| Welcome to FOSS.
|
| xchat solved this with ychat.
| undecisive wrote:
| > Alpine is free to provide a solution to the problem then.
|
| Alpine is also free to _not_ provide a solution to the
| problem.
|
| Alpine is free to say "This is not an approved use of our
| name"
|
| As you point out, the way to convey that you are a fork is
| to change your name in a non-confusing way, and provide
| attribution to the original in your readme or licenses.
| encryptluks2 wrote:
| This isn't a fork. I seriously wonder how many people
| here are commenting without having any clue as to what
| they are talking about. It is simply a package that you
| install with apk in Alpine.
| hvs wrote:
| The post has a section called "Alternatives to alpine-
| glibc"
| dralley wrote:
| > Alpine is free to provide a solution to the problem then.
|
| This entire post is about how there isn't a solution to
| that problem. It's a fundamentally flawed idea.
| MrStonedOne wrote:
| The solution is to seperate the branding from the idea.
| There is no way for somebody to suggest in the name of
| their product that they are a downstream of alpine
| without using the word alpine. alpine linux can fix this
| by creating and providing a generic word for their
| flawed-opinionated-mini-linux whatever
| deadbunny wrote:
| > alpine linux can fix this by creating and providing a
| generic word for their flawed-opinionated-mini-linux
| whatever
|
| Why is it on the Alpine Devs to name a downstream
| project? Would you ask the Debian devs to name Ubuntu?
| encryptluks2 wrote:
| It isn't even really a downstream project. This is like
| saying that third party Deb packages are downstream
| projects of Debian. They are just third-party packages
| you can install in Debian.
| MrStonedOne wrote:
| they are the ones who have an issue with alpine-glibc's
| name
| stonemetal12 wrote:
| It uses "glibc" in the name, should we assume it is an
| official glibc project? Perhaps by using both in the name we
| should assume it is an official announcement that glibc and
| alpine Linux have merged and are now one and the same thing!
|
| Or perhaps we should not be dumb and see that it doesn't come
| from the official channels of either. Therefore we should
| assume it is some random project that tries to use both,
| however poor an idea that maybe.
| minxomat wrote:
| The proposed solution here is to prevent installation of the
| package, which is a valid solution. You can still set it up if
| you want, but Alpine isn't going to let you footgun yourself so
| easily.
|
| Homebrew does the same:
| https://github.com/Homebrew/brew/blob/3476ca7b8ff889ef61e657...
|
| Exclusions for compatibility and security reasons are not the
| same as "taking them down". It's linux after all.
| traceroute66 wrote:
| Conceptually there is a lot to like about Alpine.
|
| But the problem is, as much as I want to like it and use it,
| there have always been rough edges to it. By and far, the biggest
| beef I kept on returning to with Alpine is the whole musl libc
| thing.
|
| Not because that's what they ship with, because well, "my house
| my rules" as the saying goes.
|
| But because the maintainers insisted on building various packages
| where the original external code developers stated quite clearly
| in their build guides that they didn't support anything other
| than glibc .... and yet Alpine would build and ship packages
| built against musl. Bit of a dangerous game to play if you ask me
| !
|
| This was not random small external code bases either, we're
| talking about some quite well known open source projects here.
|
| I'm not sure if they still have the same "musl or bust" package
| building policy these days as its been a few years since I quit
| using Alpine for good. Hopefully they've changed their ways since
| then.
| captainmuon wrote:
| A side-note about glibc: I have only ever had problems with glibc
| versioned symbols. The only thing they more or less do is to pin
| an old executable to old library versions, and you can supposedly
| install a newer version of the library. You then save a little
| bit of disk space.
|
| - It doesn't allow you to install minor versions of the same
| library at the same time (thats how you end up with all these
| 1.so, 2.so)
|
| - So if you want a binary to work across multiple distributions,
| you can build it on a really old CentOS and if you are lucky it
| will work, but I have no trust in this.
|
| - Forward-compatibility is not really considered, where you
| update your libraries and your existing app becomes more
| powerful.
|
| - The dynamic linker doesn't allow you to load two different
| library versions at the same time (without a lot of contortions).
| You would think you could do `dlopen` and `dlsym` on two
| different `.so` files, and then just have separate function
| pointers to each version's functions. But the linker loves to
| load all the symbols into a global namespace for some reason.
|
| I'm sure there are ways to overcome all of this, but I feel too
| young to understand how it got this way and to old to learn it
| propertly :-P. If I were to design a new system today, I'd
| probably do something like .NET's global assembly cache: Just
| dump all library versions in /lib, and have the linker pick the
| best one at runtime. And make it easy to detect and react to a
| missing lib at runtime.
| sambe wrote:
| Would you not just have more subtle, harder to debug problems
| if it were not for versioned symbols?
| captainmuon wrote:
| I'm not at all against _versioning_ , but found glibc's
| implementation a source of frustration.
|
| It would be great if you could install Qt 5.9, 5.12, 1.14 in
| parallel and have apps use the latest version (except for
| that one app that triggers a bug where you fix it to 5.9).
| This is an actual problem that occurred at work, I had to
| statically compile Qt in that case. Glibc's idea of lib
| versions doesn't help here at all if I understand correctly.
| dwheeler wrote:
| > It would be great if you could install Qt 5.9, 5.12, 1.14
| in parallel and have apps use the latest version (except
| for that one app that triggers a bug where you fix it to
| 5.9).
|
| The underlying library-loading system on Linux handles this
| just fine, and has for decades (look up "soname" for
| details).
|
| The problem is that system package managers want to load
| "just the latest" & maintainers have to take extra steps to
| enable loading of multiple versions.
| colejohnson66 wrote:
| That's not so much glibc's fault, but the Unix philosophy
| of /lib, right? Windows' "solution" to this is to basically
| require applications to provide their own runtime (such as
| Qt, GTK, etc.).
| int_19h wrote:
| Windows has many solutions to this. It is entirely
| possible for the apps to use a shared dynamically linked
| runtime, and the OS provides mechanisms to have several
| versions installed globally side by side, loading the
| correct one as needed for each app.
|
| https://en.wikipedia.org/wiki/Side-by-side_assembly
| gunapologist99 wrote:
| Disk space is cheap, particularly when we're talking
| about libs that consume a few hundred kb each.
|
| On the other hand, software _distributions_ should
| continue to rely on shared libraries, _for their own
| software_ , but third-party _compiled_ apps that are
| intended to be cross-distro /cross-arch should try to
| bundle as much as possible.
|
| This is why I prefer /opt over /usr/local for third-party
| _compiled_ apps.
| ludocode wrote:
| Maybe. Apps wouldn't have to bundle their own versions of
| libraries if those libraries actually cared about
| backwards compatibility. Bundling is just an unfortunate
| workaround for libraries continually breaking their ABI.
|
| Windows 10 can run virtually all apps compiled against
| Windows 2000 just fine, and those apps did not have to
| bundle their own graphical toolkits. Windows has gone
| through several new toolkits but they always preserve the
| old ones so that old programs continue to work.
|
| By contrast GTK has regularly broken things between even
| minor version updates. Distributions also drop the old
| major versions of toolkits much more quickly. GTK3 was
| first released in 2011, but by 2018 most distributions no
| longer provided GTK2 pre-installed.
|
| Is it any wonder that no one can ship and maintain a
| binary app that targets GTK without bundling it? Of
| course bundling sure looks like an attractive solution in
| this environment, but it's the environment that's the
| problem.
| binarybanana wrote:
| >Windows 10 can run virtually all apps compiled against
| Windows 2000 just fine, and those apps did not have to
| bundle their own graphical toolkits.
|
| They do if they're buildtusing Qt, GTK, WxWidgets, etc.
| Also shipping DirectX and VC++ runtime libraries, .NET
| runtimes, etc. was and still is (for whatever reason)
| still common and stuff just doesn't work without it. Plus
| whatever else the program needs, like a whole python
| runtime or something.
|
| >Is it any wonder that no one can ship and maintain a
| binary app that targets GTK without bundling it?
|
| Distributions have no problem doing it. If you're
| shipping something outside the distribution why would you
| ever expect that shipping only half your program would be
| feasible? There is no OS where that works.
| snovv_crash wrote:
| There are many distributions. Packaging your app for all
| of them isn't feasible. Including all the dependencies
| right down to glibc is.
| wahern wrote:
| More relevant to the question of libc, the traditional
| Windows solution was to require applications to
| distribute or statically compile their own _C_ _runtime_.
| Every release of Visual Studio had its own C runtime. To
| make matters worse, there _was_ a system C runtime, but
| most applications didn 't link against it, MinGW being a
| notable exception. AFAIU, this was one of the root
| culprits for the origin of the notorious DLL Hell.
| Applications would often crash because libA malloc'd a
| pointer, which was free'd by libB. That is, there was no
| shared, global heap. This was a far less obvious pitfall
| than mixing objects between libA and libB or even libA-v1
| and libA-v2. Even if libA-v2 was otherwise backward ABI
| compatible with libA-v1, if they were built by different
| versions of Visual Studio you could still end up with
| heap corruption. Indeed, this could happen if two vendors
| compiled the exact same source code. If an application
| install overwrote a library in the shared system folder,
| _boom_ , applications could begin crashing for no obvious
| reason.
|
| AFAIU, over the years Windows tried to mitigate this with
| various hacks for detecting cross-heap pointer freeing.
| But last time I checked their final approach was to
| guarantee backward compatibility (including backward heap
| compatibility) for all future Visual Studio C runtimes;
| ditto for the system C runtime. IOW, Microsoft committed
| themselves to maintaining a lot of internal runtime magic
| to preserve binary compatibility across time, which is
| _functionally_ what glibc has done using version symbols.
| Of course, it also became less common on Windows to keep
| DLLs in shared folders.
| int_19h wrote:
| The system and the app C runtimes are one and the same in
| Win10+.
|
| As far as cross-DLL interop: the usual solution was to
| avoid the C stdlib altogether, and just use the
| underlying Win32 API functions to manage memory that has
| to cross the boundary. Or, in the COM land, every object
| manages its own heap memory, exposing it via the ABI-
| standard IUnknown::Release.
| arthur2e5 wrote:
| The "compile in an old version" thing was IIRC more properly
| done with linker scripts telling the linker to use an older
| symbol. I think lsb-gcc does it for you -- not that the Linux
| Standard Base is still widely respected at all.
| throw0101a wrote:
| > _The only thing they more or less do is to pin an old
| executable to old library versions, and you can supposedly
| install a newer version of the library. You then save a little
| bit of disk space._
|
| You also then can remove the old library file and only have to
| maintain one for security purposes.
|
| If you have old library versions around, especially in a
| packaged environment like most Linux distros, then the old code
| will sit there and potentially no one will be paying attention
| to it anymore. If you're lucky you'll have some security
| software (e.g., Nessus, OpenVAS) tell you there's a bug/exploit
| in it.
|
| If you have only one _maintained_ version of the library
| installed, with the old symbols embedded, then it 's more
| likely to be paid attention to.
| account42 wrote:
| > It doesn't allow you to install minor versions of the same
| library at the same time (thats how you end up with all these
| 1.so, 2.so)
|
| Minor versions should be ABI-compatible so you should only need
| the newer of the two. For ABI-incompatible changes, a different
| SONAME _is_ appropriate, though the convention would be .so.0 -
| > .so.1 etc.
|
| > So if you want a binary to work across multiple
| distributions, you can build it on a really old CentOS and if
| you are lucky it will work, but I have no trust in this.
|
| As far as glibc or other libraries that take ABI stability
| seriously go, this does work.
|
| > Forward-compatibility is not really considered, where you
| update your libraries and your existing app becomes more
| powerful.
|
| Symbol versioning does not prevent you from updating the
| implementation of old symbol versions in a compatible way.
|
| > The dynamic linker doesn't allow you to load two different
| library versions at the same time (without a lot of
| contortions). You would think you could do `dlopen` and `dlsym`
| on two different `.so` files, and then just have separate
| function pointers to each version's functions. But the linker
| loves to load all the symbols into a global namespace for some
| reason.
|
| Having an option to use a separate linking table for specific
| dlopen calls would be useful, yes.
| en4bz wrote:
| So `dlmopen`?
| rkeene2 wrote:
| I'm always hesitant to use dlmopen() because of the really
| low limit on number of namespaces your process gets (IIRC,
| 16).
| lukeh wrote:
| RTLD_LOCAL?
| account42 wrote:
| Libraries loaded with RTLD_LOCAL will still have their
| symbols resolved against those from already loaded
| libraries as well as the main executable. Looks like there
| is dlmopen() in glibc since ~2005 though and there is
| libcapsule [0] which makes it actually usabel - neat.
|
| [0] https://github.com/dezgeg/libcapsule
| lukeh wrote:
| Plus also linking with groups, from memory, -Wl,-Bgroup
| although this may be a Solaris ism.
| zokier wrote:
| > Symbol versioning does not prevent you from updating the
| implementation of old symbol versions in a compatible way.
|
| As I understand the problem is that if application is
| compatible with both version X and X+1, then there is no way
| to compile binary that would preferentially use X+1 when
| available but also work with X.
|
| So applications can not reap the benefits of new version
| without dropping support with old version.
| kevincox wrote:
| What benefits are you talking about. In general benefits
| not related to the ABI _will_ be gained when updating
| glibc. For benefits related to the ABI the gains are
| probably so small that conditionally using the new ABI is
| likely not worth it in almost all cases.
| rrdharan wrote:
| > So if you want a binary to work across multiple
| distributions, you can build it on a really old CentOS and if
| you are lucky it will work, but I have no trust in this.
|
| For a very long time (decades?) VMware's Linux build system
| relied on exactly this ability, and managed to ship and support
| a binary package on many different Linux distributions using
| this approach.
|
| Not sure if it still works this way, but I'd say I have trust
| in it.
| int_19h wrote:
| This is the standard way of building binary packages for
| Python that run across many distros. They even provide the
| "official" containers to build in.
|
| https://www.python.org/dev/peps/pep-0600/
| nyanpasu64 wrote:
| Is the libstdc++ (whether static or dynamic) ABI stable
| enough for one C++ binary to run across many Linux
| distributions?
| paulddraper wrote:
| > I have additionally suggested that the TSC may wish to have the
| Alpine Council reach out to the alpine-glibc project to find a
| solution which appropriately communicates that the project is not
| supported in any way by Alpine.
|
| Eye roll.
|
| Should glibc reach out as well?
| encryptluks2 wrote:
| This is seriously the saddest and dumbest post I've seen in a
| long time. Someone decides to build an Alpine package without
| ever claiming it is part of the official Alpine distro, you can't
| even install it using the default Alpine repos, and then they
| created a Docker image with it already installed... and somehow
| someone wants to complain and threaten to block the package from
| even being installed. This is like Microsoft levels of bad for
| FOSS, maybe even worse. No where are they claiming to represent
| the official Alpine image. I have plenty of Docker images that
| use Alpine as a base image. Am I somehow representing that they
| represent the official Alpine image? No. I wonder if this person
| is just bored, or mad in general and wanted to find something
| pointless to complain about.
| fisherjeff wrote:
| Semi off-topic: While I like the idea of symbolic versioning in
| theory, in practice it has only ever caused me pain and never
| shown any benefit whatsoever: I really don't care that cosf
| changed ever so slightly in 2.xx! Just use the cosf I have!
|
| At the very least, a simple, non-hacky way to force that linkage
| would be great but I have found no such thing. Anyone here had
| any better luck?
| dbt00 wrote:
| I've definitely had my share of annoyances with musl-libc and
| would probably consider building my base images around distroless
| if that were something I were dealing with right now.
|
| In the meantime, it's kinda shitty of someone to casually squat
| on the alpine linux namespace. If you want to make a small
| distribution that also ships glibc, then it's not alpine. Don't
| call it that.
| hhsbz wrote:
| If it's alpine with glibc I don't see what's wrong with calling
| it that
| faho wrote:
| What's wrong with that is the reason trademarks exist:
| Confusion.
|
| If something is called "alpine-glibc", it's reasonable to
| expect that it's by the alpine people and supported like
| alpine.
|
| This, as we see here, annoys the alpine people because they
| now get bug reports and support requests from people using
| it, and have to direct people elsewhere. And when it doesn't
| work, they get the hit to their image even tho they've had
| nothing to do with it.
| jcelerier wrote:
| It's the old Iceweasel story all over again. Sadly open-
| source is ill-equipped to handle naming issues.
| hhsbz wrote:
| I think it's clear from the website that this is based on
| Alpine and not part of the project
| https://hub.docker.com/r/frolvlad/alpine-glibc/
|
| Without context, I think what this guy is pissed off about
| is that this project enables people to use alpine to run
| proprietary software.
| faho wrote:
| It doesn't outright state anywhere that it's not an
| official alpine product, and I don't know if everyone
| reads the site - many people will just copy the "FROM
| frolvlad/alpine-glibc" from elsewhere.
|
| In any case, the Alpine people would know, and they
| apparently think it's a problem.
|
| >Without context,
|
| But you have context here! It has issues with symbol
| versioning! There is "strange behavior and possible
| crashes, ". This makes _alpine_ look bad, because people
| think it 's the alpine project's fault!
|
| > what this guy is pissed off
|
| Please don't assume everyone is a "guy". In this case,
| Ariadne is not a "he" (she uses "she"), so a male-coded
| word like "guy" is ill-fitting.
| im3w1l wrote:
| FROM frolvlad/alpine-glibc
|
| That namespacing does make it look pretty unofficial to
| my eyes.
| faho wrote:
| But do you know if alpine does official docker images
| namespaced as e.g. alpine/?
|
| Is "alpine-glibc" an official project and someone just
| helpfully made the image (or an image including an
| official glibc package)? Or is this a prerelease?
|
| Without a deep knowledge of alpine (or now reading this
| post) I couldn't answer any of these questions and I'm
| not sure I wouldn't try to go to alpine for bug reports.
| I think there's a reasonable potential for confusion,
| even with the namespace. (but granted, I don't use docker
| either, so maybe this is a common thing)
|
| And I assume the alpine people (like the author) know
| that they get bug reports for it and that the issues with
| it cause bad publicity, and that that's the context for
| the post and the proposal to block the package.
| Karunamon wrote:
| The answer to the first question is an _obvious_ yes, and
| it 's obvious to anyone that uses Docker. No deep
| knowledge required.
|
| If you want Alpine, you do FROM alpine:(version).
|
| https://hub.docker.com/_/alpine
| ariadneconill wrote:
| The problem is the people who use Docker but don't know
| anything about it. Or don't know that mixing libcs is a
| problem. They use this glibc package, break their
| containers and then blame Alpine for the breakage.
| faho wrote:
| Ah, that's good to know, thanks!
| MrStonedOne wrote:
| > > what this guy is pissed off
|
| >Please don't assume everyone is a "guy". In this case,
| Ariadne is not a "he" (she uses "she"), so a male-coded
| word like "guy" is ill-fitting.
|
| Please do not mince words, people have a tenancy to refer
| to their own gender identity when referring to people
| who's gender identity they do not know. You knew what
| they meant.
|
| from the hn guidelines:
|
| > Please respond to the strongest plausible
| interpretation of what someone says, not a weaker one
| that's easier to criticize. Assume good faith.
| burnished wrote:
| There Are No Women On The Internet, so they got
| corrected. It isn't a bad faith interpretation, more like
| a gentle correction.
| MrStonedOne wrote:
| "somebody using a generic is really suggesting that women
| don't exist on the internet" sounds exactly like a bad
| faith interpretation.
| burnished wrote:
| I'm having a hard time here - do you really not see the
| connection between what I'm saying, what you're saying,
| and the use of a default masculine pronoun?
| MrStonedOne wrote:
| I see the connection, what I'm suggesting is that you
| knew what they meant when they said guy, meaning you did
| not need to suggest that they thought women didn't exist
| on the internet, nor did you need to suggest that they
| were assuming everybody on the internet is a man.
|
| Both of those statements are bad faith.
| diegocg wrote:
| It makes it look like an "official" project.
|
| Just give it a different name and explain that it's Alpine
| with glibc somewhere
| encryptluks2 wrote:
| It does not. They use Alpine in the name so people can find
| the image. Searching for Alpine on Docker Hub has 49,530
| results. This image doesn't even show up on the first page
| of results. I think whoever wrote this needs to rethink how
| ridiculous they are being.
| op00to wrote:
| I assumed it did.
| [deleted]
| creshal wrote:
| Except it's not, as it mixes glibc with musl in ways that
| induce undefined behaviour you don't expect. If it was
| recompiling _all_ packages to use glibc, the name would be
| more appropriate... but also still a trademark violation.
| encryptluks2 wrote:
| So, of the 49,530 images that show up with several using
| Alpine somewhere in the name or description... you think
| this is a trademark violation how? Alpine is synonymous
| with lightweight images. Several people and vendors use it
| in their image names.
| lolc wrote:
| I do expect images with "alpine" in the name to be based
| on the Alpine distro. And not some weird bastard of
| Alpine. And I see no problem with them asserting their
| trademark here.
| encryptluks2 wrote:
| This is merely a package you install on Alpine so it
| isn't a fork. Did you not do any independent research and
| just assume? Want to move the goalposts?
| linkdd wrote:
| There is a difference between "python:3.10-alpine" and
| "alpine-glibc".
|
| One stands for: "we use alpine" (not a trademark
| violation)
|
| The other one stands for "this is alpine" (a trademark
| violation)
| encryptluks2 wrote:
| First, the repo name is alpine-pkg-glibc because it is
| merely a package you install on Alpine. The container
| name, created by a different individual is
| frolvlad/alpine-glibc, and they make it clear that it is
| based off Alpine with the glibc package installed. In
| fact, you can even look at the source code. This is
| ridiculous, and if Alpine starts going after people for
| using alpine in the container image name or tag then I
| now know what distro to avoid entirely.
| Aissen wrote:
| I've had to battle quite a few portability issues, but
| everytime it was a program incorrectly assuming some sort of
| behaviour from glibc and not really musl's fault.
| faho wrote:
| I mean, okay, it's the program's fault. But it _is_ part of
| the trade-off you make using musl, and one that I,
| personally, wouldn 't decide in its favor.
|
| As the user, you have the choice to use musl and "battle
| quite a few portability issues" (whether that's the program's
| fault or not!) or to use glibc and not have to battle. If the
| benefits of musl outweigh that in your opinion, then go
| ahead. I don't see it.
| Aissen wrote:
| Agreed. People knowingly using musl usually know the
| benefits.
| p2t2p wrote:
| We had to stop using alpine because we have to resolve a DNS
| name that resolved in a 100 hosts. Musl fails to resolve that
| because it does not support "upgrade to TCP" and the response
| does not fit into single UDP packet so it gets truncated, so
| node fails to resolve the name. And not only node, normal
| Linux tools as well. And the author says it's a feature, not
| a bug so for me it is kinda hard to take that thing seriously
| when parts of standard are unsupported.
| synergy20 wrote:
| "For what it's worth, musl's DNS resolver is slated to gain
| support for TCP responses in the near future" from
| https://www.linkedin.com/pulse/musl-libc-alpines-greatest-
| we...
| geocar wrote:
| If someone on my team had built an application and put 100
| hosts into a DNS server, I would suggest they upload their
| hosts file to a webserver someplace. 100 hosts just doesn't
| do anything useful with most applications using
| gethostbyname() even in glibc, it's going to be slow, and
| the bug reports you get are going to be really confusing.
| Custom applications that are prepared to deal with all 100
| hosts will be easier to implement using the output from a
| webserver.
|
| What are you doing?
| Spivak wrote:
| Service-Discovery-Over-DNS is typically the use-case.
| It's used as a compatibility layer for software where you
| either can't or don't want to integrate the native
| discovery APIs. Consul is a good example of this. You
| don't actually have to know how to speak Consul to get
| automatic service discovery, all you have to do is query
| a DNS name to get the hosts registered for a particular
| service.
| geocar wrote:
| That doesn't answer my question at all, unless you mean
| that people make bad engineering decisions because they
| like using cute things.
|
| dig is not affected by alpine's decision here because dig
| does not use gethostbybame.
|
| No DNS client would be.
|
| This affects gethostbyname which very few programs in my
| experience even support robustly, so any "use-case" where
| someone is using 100 results would surprise me.
|
| It seems if you need to write something custom, a www
| client is better (which consul also supports).
|
| I think if you insist on writing gethostbyname instead of
| the res_* calls in bind, and robustly handle all results
| in a sensible way, then that's silly, and if you have an
| existing application that works great with ~70 addresses
| but not 100 I would be curious to know what it is.
| wyager wrote:
| Ha, I ran into that one at work one time in our custom DNS
| resolver and had to add TCP upgrade. I was very confused
| why the tool worked when I shelled out to dig but not when
| I did the "correct" thing and used a resolver library. I'm
| very surprised that a project as big as musl would not have
| support for this.
| ntauthority wrote:
| Why is DNS resolution even part of the libc and not, say,
| the base OS, a service on the base OS, or if need be, an
| external library like c-ares?
|
| In fact, I thought Node already depended on c-ares, why is
| it failing on this?
| Denvercoder9 wrote:
| I certainly don't want DNS resolution inside the kernel,
| and outside the kernel, libc is as "base OS" as "base OS"
| comes, imo.
| Spivak wrote:
| The Linux kernel can actually resolve names but it farms
| out the actual work to userspace using the request-key(8)
| machinery.
|
| I personally it should be renamed because it's just a
| generic way for the kernel to ask for data from
| userspace, not just keys but still.
| devit wrote:
| Someone added it to libc and now it needs to be provided
| forever for compatibility.
| p2t2p wrote:
| Adding to the other responder.
|
| Traditionally, in Unix libc is part of the OS. This
| situation is different in Linux but Linux is an outlier
| here, if we look at various BSDs they keep libc in the
| same tree as kernel.
| WJW wrote:
| If the outlier has >100x as much market share as the rest
| of the other unixes combined, is Linux really still the
| outlier?
| WastingMyTime89 wrote:
| Historically speaking? Yes.
|
| C and Unix are considerably older than Linux after all.
| nyrikki wrote:
| Remember "Linux" is just the kernel, it is not an
| operating system itself.
|
| Alpine or Debian including libC is more equivalent to the
| BSDs including it.
| masklinn wrote:
| Yes. It explains why things work the way they do, and
| have since long before linux was a thing.
| Spivak wrote:
| Because people treat libraries differently today than 30
| years ago. We're used to the integration points for
| things being some form of blocking IPC (like dbus on
| GNU/Linux, COM, or syscalls) but libc is different.
|
| libc is that service on the base OS. But rather than
| connecting to an OS service and passing messages back and
| forth you dlopen and setjmp to do the same thing. On
| GNU/Linux libc isn't an interface to the NSS service,
| libc is the NSS service. That fact that you access it via
| your linker is just an implementation thing.
|
| The kernel itself actually exposes integration points
| this way too with lib-vdso! The kernel will actually just
| stick it's own routines in your programs memory space so
| that you can avoid the syscall overhead for certain
| calls.
| tyingq wrote:
| It has certainly evolved to be pretty complicated. You
| have whatever libc chooses to do with getaddrinfo(),
| nsswitch.conf, resolv.conf, systemd-resolved, various
| pieces of software (docker, vpns, wsl), and so on, all
| trying to control the local resolver.
| fanf2 wrote:
| libc provides the standard POSIX sockets APIs, which
| include DNS functions such as gethostbyname() and
| getaddrinfo()
| sharikone wrote:
| Linux as a system is very ill-defined. I'd argue that
| GNU/Linux by definition contains glibc even if they are
| not in the same tree and musl based distributions are a
| variation which you could call "musl/Linux".
| wahern wrote:
| GNU formalized a system of tuple definitions for
| identifying build, host, and target environments, which
| was popularized by Autotools. See https://autotools.io/au
| toconf/canonical.html#autoconf.canoni... and
| https://www.gnu.org/savannah-
| checkouts/gnu/autoconf/manual/a... Even if you don't use
| Autotools, this is the canonical way to specify
| environments in the Unix world, though often a simplified
| version is employed. (By canonical I mean the one
| project-agnostic system that everybody at least nominally
| acknowledges. It's hardly the only system out there. Even
| Debian has their own alternative:
| https://wiki.debian.org/Multiarch/Tuples .)
|
| The tuples historically had 3 components--cpu, vendor and
| operating system. But especially as uclibc and musl
| became more widespread the last component is commonly
| split into kernel-libc. (I think this was originally
| extended for the benefit of Debian GNU/kFreeBSD.) The
| formal OS identifier for glibc-based Linux systems is
| "linux-gnu" (e.g. x86_64-pc-linux-gnu), and for musl
| "linux-musl" (e.g. aarch64-alpine-linux-musl).
|
| Vendor is not very useful these days. It's common to see
| 3-tuples of cpu-kernel-libc, as opposed to 4-tuples or
| traditional 3-tuples. Sometimes the system is extended
| into, e.g., 5-tuples like cpu-vendor-kernel-libc-
| compiler. Autotools projects commonly have a bit of
| generated shell code for parsing tuples; it's quite
| complex owing to ~30 years of accumulated idiosyncrasies.
| silon42 wrote:
| Typically, on a modern Linux system, DNS queries from
| libc (and everything else) will always query a local
| resolver (example: systemd-resolved).
| Spivak wrote:
| That's up to your distro technically. DNS queries that
| use glibc (so everything basically) parse
| /etc/nsswitch.conf and follow the path of NSS modules
| which can do whatever they want to produce a name.
|
| The resolve module provided by systemd talks to systemd-
| resolved but the dns module parses /etc/resolv.conf and
| does the resolution itself.
| trissylegs wrote:
| It probably made sense in 1983.
|
| https://github.com/dank101/4.2BSD/blob/master/include/net
| db....
| fanf2 wrote:
| I think back then libresolv was separate from libc since
| many programs didn't need it, and memory was tight
| [deleted]
| tyingq wrote:
| https://twitter.com/RichFelker/status/994629795551031296
|
| Yikes.
| throwthere wrote:
| Oh wow. There's a big contrast between Linus screaming
| "don't break userspace," and that sort of crusade against
| the spec.
| Aissen wrote:
| It's not the same because this is not an ABI, but an API
| needing a recompilation. It's actually explained in the
| article why it is not an ABI.
| fanf2 wrote:
| That thread from 2018 refers to RFC 5966 which was
| obsoleted by RFC 7766 in 2016. RFC 7766 is much stricter
| saying TCP support is required.
| https://datatracker.ietf.org/doc/html/rfc7766#section-5
| mwcampbell wrote:
| Does it matter whose fault it is when one just needs to ship
| a product and keep it running reliably?
|
| I'm conflicted on this. I'm currently running an Alpine-based
| container in production but am thinking about revisiting the
| choice of base image.
|
| On the one hand, using a smaller base system and (especially)
| a simpler libc translates to a smaller attack surface, and
| less noise in static scans for vulnerabilities. So I could
| argue that using Alpine is the responsible choice from a
| security perspective.
|
| But maybe I'm just rationalizing a desire to pursue the kind
| of software quality (simplicity, minimization of bloat) that
| only we developers appreciate and that often has hidden
| downsides. Then I read about such downsides, like the sibling
| comment about DNS resolution, and I wonder if the responsible
| thing to do as a pragmatic product developer (and future
| manager of such developers) is to banish Alpine from the
| stack, tolerate the relative bloat of something like Debian,
| and throw more (and more complex) tools at the problem of the
| larger attack surface and more noise in vulnerability scans.
| ariadneconill wrote:
| alternatively you could just use a dedicated local resolver
| fanf2 wrote:
| unfortunately that will not solve the problem: DNS RRsets
| cannot be split up, so if the answer is too big for UDP,
| it will still be too big when requested via a local
| resolver
| ariadneconill wrote:
| The `dnsfunnel` resolver has been added to Alpine to
| solve that issue. Additionally, musl will gain TCP
| support for situations like DANE where individual records
| may be very large.
| wyldfire wrote:
| For a very long time glibc was the only game in town. so to
| some extent glibc was Linux. you can forgive people for not
| testing with other libcs if none was available to test
| against.
| sgerrand wrote:
| Maintainer of the Alpine package referenced here. It's called
| `glibc`, makes no claims on Alpine Linux and certainly isn't a
| Linux distribution. You install the package in Alpine Linux,
| nothing else.
| deadbunny wrote:
| Most people's experience with alpin is through containers.
| Given you provide `alpine-glibc` containers is likely where
| the confusion comes from. If you don't know the backstory one
| would easily assume this is an Alpine endorsed container.
| sgerrand wrote:
| I don't provide "alpine-glibc" Docker images or containers,
| so I don't really know what you're referencing here. I
| maintain an Alpine package called `glibc`. Please enlighten
| me!
| tadfisher wrote:
| Try nix sometime! When I'm forced to use Docker as a container
| runtime, nix has made building lightweight images fairly
| painless without the manual dependency management I see in so
| many dockerfiles.
|
| https://nix.dev/tutorials/building-and-running-docker-images
| TheJoeMan wrote:
| I would like to point out the GitHub linked to in the article
| says "glibc alpine based image" as in based on the alpine-glibc
| image. It seems adriadne has misread it as glibc based alpine?
| emilfihlman wrote:
| "I don't like you exercising your right to foss, so we are going
| to make using foss harder for you".
|
| Foss shouldn't be about us going out on our way to block others.
| jsiepkes wrote:
| > Foss shouldn't be about us going out on our way to block
| others.
|
| Sure, but this is about the Alpine project getting tired of
| being mistaken for the maintainers of a fork of their project.
|
| How would you feel if the power company would call you every
| week because they think your someone else and you had to
| explain the same thing every week?
| encryptluks2 wrote:
| How are they being mistaken? No where do they claim to be the
| official Alpine image. This is like saying anyone who uploads
| an Alpine image with a few self-built packages installed is
| somehow conflating themselves with representing Alpine Linux,
| when in fact there is nothing the creator of this image has
| done to indicate that they are in any way considered the
| official Alpine project. In fact, Docker Hub has a place for
| official images. If someone is mistaking this package as
| being supported by Alpine Linux as a whole, then they also
| the same people that would mistake Google for any app
| installed from the Google Play Store.
| Sohcahtoa82 wrote:
| > How are they being mistaken?
|
| Because the image is named "alpine-glibc", but the "how" is
| irrelevant. People are getting confused and that's a
| problem.
|
| > No where do they claim to be the official Alpine image.
|
| Doesn't stop people from being mistaken.
|
| > If someone is mistaking this package as being supported
| by Alpine Linux as a whole, then they also the same people
| that would mistake Google for any app installed from the
| Google Play Store.
|
| Agreed.
| nightowl_games wrote:
| > People are getting confused and that's a problem.
|
| Let's see the data.
| deathanatos wrote:
| > _is like trying to run Windows programs on OS /2: both
| understand .EXE files to some extent, but they are otherwise very
| different._
|
| But you _could_ run Windows programs on OS /2. They'd even render
| with the Windows window borders, and not the OS/2 ones.
| encryptluks2 wrote:
| Just checked out the GitHub repo. Apparently the author can't
| even be bothered with posting an issue seeing if there may be a
| more appropriate name for the GH repo, although I personally see
| nothing wrong with the name as it is merely a package that you
| have to manually install.
| ordx wrote:
| I think the majority of people resort to this hack because
| security folks in their infinite wisdom require to use alpine and
| nothing else. Unfortunately, a lot of libraries don't support
| musl and have no plans to support it in the future, so you have
| to be creative.
| herf wrote:
| I think we need more well-maintained "parts" that can be used as
| alternatives to libc. For instance, string operations can be 5x
| faster on AVX2, but not every distro provides this code.
|
| I recently upgraded some Centos 6 machines (glibc 2.17) to Debian
| 10 (glibc 2.28) and system-provided strstr got about 5x faster,
| which was really important to my binary. I imagine similar
| differences exist between musl and glibc, due to lack of AVX2 or
| some other Intel optimizations in musl.
|
| But meanwhile, everyday functions like strstr or memcmp (that
| don't even allocate memory) are totally glued to the system libc
| (often with a slow version for your architecture). There is no
| broken-out "fast intel string ops" library that you can link with
| to ensure great+consistent performance on your target CPU (though
| I guess you could roll your own with nasm).
|
| Are big shared libc libraries good for security or other reasons?
| Maybe. But it does not make performance consistent across
| distros. It's fine for different distros to be 10% different in
| speed, but it's really not okay for them to be 500% apart.
| nonameiguess wrote:
| Some things like this do exist. Some programs or even entire
| customized distros will LD_PRELOAD jemalloc for size or
| hardened malloc for security (I'm sure there's a performance-
| optimized version out there I don't know about). There's
| nothing at all stopping developers from providing optimized
| subsets of libc intended for more specific use cases than the
| fully-general system-wide libc.
|
| Note that when you're comparing Centos 6 to Debian 10, you're
| comparing a system released in 2011 that went end of life last
| November to a system released in 2019. I don't think it's that
| surprising that 8 years of development brought a 500%
| performance increase. Presumably, Centos 8 (released 17 days
| after Debian 10) would have had the newer glibc.
| herf wrote:
| I benchmarked an Alpine's musl doing strstr with a 200-byte
| "haystack" with a 10-byte "needle" and it's _8x slower_ than
| Debian 10 's glibc.
| erk__ wrote:
| It could be interesting to see how BSDs compare here
| dralley wrote:
| > It's fine for different distros to be 10% different in speed,
| but it's really not okay for them to be 500% apart.
|
| Debian 10 release date: 6 July 2019
|
| Centos 6 release date: 10 July 2011
|
| This is hardly an apples-to-apples comparison.
| d3nj4l wrote:
| 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?
| cormacrelf wrote:
| 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.
| dijit wrote:
| > 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 wrote:
| > 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.
| sascha_sl wrote:
| 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.
| d3nj4l wrote:
| > 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.
| ariadneconill wrote:
| 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.
| riwsky wrote:
| That's a bad analogy. Use of Rails isn't broken on a
| technical level; use of glibc on alpine is.
| akerl_ wrote:
| 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 wrote:
| 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_ wrote:
| 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.
| puffyvolvo wrote:
| It does when it's causing excessive load on upstream from
| users who think what is effectively an outright broken
| configuration is supported. Preventing footguns and
| providing users the ability to continue using it if they
| _really really want to_ seems like a sane option?
| ariadneconill wrote:
| 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_ wrote:
| 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 wrote:
| 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.
| yjftsjthsd-h wrote:
| The user already had to go out of their way to install
| it; I'm not sure adding an extra flag is a huge
| difference.
| MrStonedOne wrote:
| 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.
| ariadneconill wrote:
| I'm glad to know that free software maintainers exist to
| do whatever _you_ want us to do, and that we don 't get
| to set our own boundaries. Cool, cool.
| akerl_ wrote:
| As visible upthread, I think starting w/ the block in
| code is a bad move, and am sad that reaching out to the
| maintainer of alpine-glibc seems like an afterthought.
|
| 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.
| puffyvolvo wrote:
| > You don't get to tell your users how to use your
| project.
|
| 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.
| sascha_sl wrote:
| It doesn't block it, it requires recompiling musl.
|
| 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.
| ariadneconill wrote:
| correct: we do not want to get stuck with having to deal
| with angry people who have unstable environments caused
| by this.
|
| 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...
| encryptluks2 wrote:
| Can it also get brought up there that you come across as
| a fascist?
| ariadneconill wrote:
| I was not aware that publicly setting boundaries on what
| is a supportable configuration and what wasn't one was
| somehow equivalent to white nationalist syndicalism, but
| thanks for letting me know.
| encryptluks2 wrote:
| When your first reaction in all this was to figure out a
| way to try to block a third-party package from being
| installed, and then you make comments like... "we feel it
| appropriate to signal our position more forcefully." And
| then you lock comments on GitLab from people commenting..
|
| 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 base image.
| ariadneconill wrote:
| The issue is not the package. Obviously Sasha is allowed
| to publish whatever packages he wishes.
|
| 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.
| kazinator wrote:
| This should just call itself _glibc-kludge-4-alpine_. Most of the
| problem solved, I think.
| dec0dedab0de wrote:
| I think this is a perfect example of why the Open Source
| Definition has "Integrity of The Author's Source Code" If they
| care about being associated with other people's projects, then
| they should add a bit to the license that they have to change the
| name of the project when modifying.
___________________________________________________________________
(page generated 2021-08-26 23:01 UTC)