Not being familiar with the subject matter, reading this made almost no sense to me
this post was submitted on 20 Mar 2024
106 points (94.9% liked)
Linux
47929 readers
1147 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
Essentially, an updated dependency requirement in Mesa (updated Zlib) broke an important benchmarking tool (SPECViewPerf) used by hardware vendors. Subsequently, this change was reverted. This caused a debate in the Mesa dev community, with some devs claiming it's not Mesa's fault, it should be treated as a bug in SPECViewPerf instead. In response, AMD's Mesa dev said this isn't a technical issue, but rather a political/strategic issue - you don't want to anger important workstation vendors and other high-level parties who use this tool, especially since they contribute so much to the Linux ecosystem. That would make the Mesa project seem very immature/unreliable.
As an example, imagine if this change broke something more popular like Steam - Valve and all Linux gamers would be out for blood and you bet the Mesa change would be reverted without debate - even if they were technically in the right (that it's not a bug).
So this incident serves as an important reminder for those who work on big opensource projects like this - just because your actions are technically correct, it doesn't mean it's okay to break everyone else's stuff, expecting they'll fix it. This is in fact something Linus preaches when it comes to kernel dev - "don't break userspace".
Thanks for commenting!
It sounds like the devs didn't read Linus' rant
I very much agree with, "don't break userspace", and this was a wise choice.
On the other hand, if capital becomes the developers' core objective and they would not have made the same action for plebeian users, this would be an outrage.
You're right, but only to the extent that the capital coming from your users is disproportionate. Some spaces have money coming from mostly those plebeian users.
This is the best summary I could come up with:
The most recent example is a now-merged merge request to revert an earlier change bumping the Zlib dependency for Mesa.
Ultimately it's an issue with how SPECViewPerf is setup as an application bug but it could also be argued that Mesa could statically link it or better handle its dependencies.
In any event some notable messages were raised by well known AMD Mesa developer Marek Olšák: "I don't know [about being able to update Zlib or other solutions].
Expecting SPEC to suddenly adjust SPECViewPerf or similar is unlikely and failure to fix this would have been poorly reflected on the open-source Mesa OpenGL drivers... Hell the AMD Mesa drivers with SPECViewPerf are extremely competitive to the proprietary AMD alternatives or the NVIDIA competition on consumer cards.
Just imagine the screams if this wasn't a SPECViewPerf issue but rather a similar change breaking Steam support... Gamers would be protesting, Valve would be rightfully upset and surely having their developers working on an immediate revert, and would have further potential reverberations if it wasn't immediately addressed.
Mesa these days has a significant corporate presence from the developers involved and increased customer demand more than ever, but ultimately it's a good thing for the benefit of the ecosystem.
The original article contains 826 words, the summary contains 205 words. Saved 75%. I'm a bot and I'm open source!
Honestly we need to work on making sure Mesa can't break something by removing a dependency
As somebody using CAD in the corporate world a shared object dependecy issue was solved by making a new symbolic link to the alternate older file. Software came looking for libX.so4, but needed .so3 info to work. so a link name 4 pointing to 3 solved issues. Can the same be done for zlib?
SPECViewPerf breaks the teapot?