The Significant Corporate Importance & Pressure Around Mesa Open-Source Linux 3D Drivers

[mdedetrich]

Apple doesn't get it. They've always had a history of dropping compatibility as quickly as they believe they can get away with.[/LIST]

Oh no, Apple most definitely gets it, this is deliberate on their part but you are also not telling the whole story.

The whole point behind Apple and their devices is that they are vertically integrated inclusive of hardware and part of that (and hence their strategy) is that Apple deprecates/removes older stuff and they expect developers to play along which in stark contrast to Windows where they bend over backwards for developers. A lot of the problems you mention are a result of developers not updating their software which has its own pro's and con's.

I should also remind you that in other cases i.e. iPhones Apple has historically had much better device support than any other competitor (i.e. Android), iPhones are known for having a minimum of 5 years of updates where as most Android phones up until recently was lucky to have more than 2-3 years unless it was a Google phone.

Apple just released macOS 14.4 and it broke the JVM on Apple Silicon by turning SIGBUS and SIGSEGV conditions the JVM expects to catch (essentially the userland equivalent of how the kernel catches SIGSEGV as part of detecting when to page back in data that was swapped out) into uncatchable SIGKILL, in direct violation of what POSIX specifies, and they apparently just treated it like any other minor update, not running it through a preview channel first.

Its not as clear cut as you are painting it to be, see https://news.ycombinator.com/item?id=39726292 (and fyi I work with JVM as part of my fulltime job, I am a Scala/Java developer). It seems like Apple was expecting developers to run applications in a more privileged mode seeing as the JVM is JIT, but what is an application is less clear cut with JVM due to the concept of jars conflating libraries with executables/executable code.

This is also a pretty bad example because ironically the JVM being a virtual machine, a newer version of the JVM can be released which deals with this change in MacOS. I mean thats one of the fundamental reasons why JVM is so popular, its so it can abstract over the OS so if the OS does changes like this (its not just Mac that has broken the JVM in some way), then Oracle and/or any of the other vendors can just release a new version of the JVM and you don't need to modify the jar's/classfiles at all.

EDIT: When reading the specifics it does seem like in this case the MacOS change may have to be reverted, either that or they Apple needs to specify a way to propagate JIT executable mode all the way down to jar's being executed

[d3coder]

You can patch mesa on all machines, but you can't patch SPECViewPerf? And if you don't "fix" mesa, "industry clients" will move to another driver? To what driver? Nvidia? Maybe SPECViewPerf should be open source?

[mdedetrich]

You can patch mesa on all machines, but you can't patch SPECViewPerf? And if you don't "fix" mesa, "industry clients" will move to another driver? To what driver? Nvidia? Maybe SPECViewPerf should be open source?

Thats not how the real world works

[drakonas777]

That's not what open source is about, open source back in the early 70's was about teaching college students how operating systems

Not really. Ability to learn from the open source code was certainly a side affect but in reality it's mainly these two reasons:

a) There was a high diversity in hardware (and OSes for that matter) without some sort of established de-facto "industry standard", so open source was really the only form of software which was practical to ship;
b) There was no concept of a "software as product" (and "software company") back then, so naturally binary form of a software had no sense;

[pharmasolin]

You can patch mesa on all machines, but you can't patch SPECViewPerf? And if you don't "fix" mesa, "industry clients" will move to another driver? To what driver? Nvidia? Maybe SPECViewPerf should be open source?

To close source driver. And fire all mesa devs from and as they failed and missed a commit which introduced huge regression. And start investing more in a team who works on a closed source driver.

[hkupty]

I 100% agree with Marek. This is the right attitude and I can only wish more open source developers and maintainers had this mindset. The more trouble a dependency causes, the higher the chance it will get replaced. And although it can be forked, I don't think it necessarily means it would be replaced by another open source solution. People often think of politics as a macro subject, capitalist vs socialist, etc, etc, but they forget about real-life local context politics and this is an extremely important aspect of OS that is, again, overlooked. Many projects care only about their "philosophy", correctness or prowess and forget that, at the end of the day, people will decide whether they want to use it or not.

[mdedetrich]

b) There was no concept of a "software as product" (and "software company") back then, so naturally binary form of a software had no sense;

Indeed, in fact back then all of the money was in hardware/mainframes and the actual software wasn't seen as the place where all of the money is. Now its pretty much flipped, where almost all hardware is a commodity (i.e. the market is very saturated) and its in software where all of the $$$ lies. There are exceptions to this, i.e. NVidia datacenter GPU's but what I said is largely the case, software is IP to protect in this day and age, or we protect stuff in the cloud.

[chithanh]

So the immediate solution that's now been merged is to revert that Zlib update commit. But ultimately doesn't solve the issue at hand.

i think there are two separate issues conflated here:

1. Should we break our existing users and use cases?
2. Should our project base decisions on business interests over technical merit?

I think a good litmus test which decision is good for your FOSS project is WWLD ("What would Linus do?").

The Linux kernel has a long-standing policy of not breaking userspace (relevant xkcd). So any change that breaks your users needs to be well-reasoned, communicated long in advance, and old interfaces maintained over an extensive depreciation period.

On the other hand, any decision which impedes progress and only serves business interests, I think Linus would have some choice words for that. I'm sure many a company's operations would have been helped by a stable driver interface for Linux, but this has not happened and is not going to happen.

So in summary, the decision was right to revert the commit, but the determining factor is the compatibility to existing users..

[Serafean]

Surprise surprise, the guys discussing in the MR know what they're talking about.

Vendoring zlib would result in distros unvendoring it anyway, making the issue come back. (not to mention the CVE resolution nightmare)
Reporting the issue to viewperf: that using LD_LIBRARY_PATH in a launcher script while bundling system libraries is a good way to end up in hell. (at $dayjob I fought very hard against this approach)
While at the same time dancing around the issue that updating something shouldn't break something else.

This is a shitshow with no good solution.

[jabl]

You can patch mesa on all machines, but you can't patch SPECViewPerf? And if you don't "fix" mesa, "industry clients" will move to another driver? To what driver? Nvidia? Maybe SPECViewPerf should be open source?

Don't know about SPECViewPerf but at least SPECCPU requires the benchmark sources to be unmodified, to prevent vendors from cheating. I would guess there are similar rules for SPECViewPerf as well. If so, no you can't patch SPECViewPerf and submit scores obtained with the patched version.