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

[phoronix]

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

It has taken many years but the Mesa 3D open-source graphics drivers have proven very successful from the open-source AMD Vulkan and OpenGL drivers proving they can be capable of competing with the closed-source drivers not only for gaming but also workstation tasks, the Windows vs. Linux graphics driver performance gap largely closed, Microsoft even leveraging Mesa for their translations to the D3D12 API, vendors like Imagination developing once unthinkable open-source drivers, etc. But with the increasing importance to corporations, so has the responsibilities and concerns of Mesa driver developers...

https://www.phoronix.com/news/Mesa-Revert-For-SPECViewPerf

[Barley9432]

It's good to see Linux developers are pressuring more and more for backwards compatibility. Just wish more like the glibc folk realized how important that is.

[Sonadow]

Finally some sense.

But in the long run, software that bundle their own libz.so should note this and provide an FAQ or KB informing people about this, and eventually update their code to work with a newer Mesa and libz.so.

And if it's not possible, the proper way for Mesa should be to do a

if
   {
      dependency('zlib', version : '> 1.2.3 && <= 1.2.5')
      foo
   }
else if
   {
      dependency('zlib', version : '>1.2.5')
      bar
   }​

Brutal truth: a lot of what the so-called FOSS developers call shitty code quality in proprietary code is actually an extremely comprehensive set of layers upon layers of dependency versioning catches to ensure the program works acceptably against a shitton of older and newer dependencies that may exist in the variety of user systems and configurations. But this is something the so-called FOSS developers bragging about their so-called code quality will never ever be able to understand.

[BwackNinja]

Easy agree. If you're not working on it (or enjoying news of its progress), Mesa should only be thought of as an implementation detail -- an implementation of libGLX.so and libEGL.so for a set of hardware. If you have to think about it more than that, then it isn't doing the job properly. If it was exposing APIs that involved zlib objects, that would be one thing, but instead it is only using it internally.

In addition, I'd argue that dependencies should be vendored as much as possible, even without Flatpak/Snap/AppImage. No program's dependencies should necessarily affect or interfere with another's. The base operating system should be small, manageable, and entirely separable from the applications that run on it.

[pWe00Iri3e7Z9lHOX2Qx]

Marek gets it. Scaling open source is extremely hard. The best result is that these corporations pay people real livable wages to contribute to important open source projects full time.

[shmerl]

With all the political points aside, what's the correct solution? Having frozen dependencies on some obsolete libs is not a solution for sure.

[Sonadow]

Easy agree. If you're not working on it (or enjoying news of its progress), Mesa should only be thought of as an implementation detail -- an implementation of libGLX.so and libEGL.so for a set of hardware. If you have to think about it more than that, then it isn't doing the job properly. If it was exposing APIs that involved zlib objects, that would be one thing, but instead it is only using it internally.

In addition, I'd argue that dependencies should be vendored as much as possible, even without Flatpak/Snap/AppImage. No program's dependencies should necessarily affect or interfere with another's. The base operating system should be small, manageable, and entirely separable from the applications that run on it.

That's why Windows, macOS and ChromeOS make up almost 100% of the end-user desktop and notebook computing share.

Microsoft gets it. Apple gets it. And as horrible as they are, Google also gets it.

[BwackNinja]

With all the political points aside, what's the correct solution? Having frozen dependencies on some obsolete libs is not a solution for sure.

Statically compiled in, hiding symbols: linker option --exclude-libs. You can use the newest version if you'd like and you won't have symbol conflicts. Unused functions won't contribute to the shared library size so the difference in filesize will be negligible.

Edit: This can also only work with compatible licenses. The combination would also be under and have to distribute the zlib license.

[ezst036]

That's why Windows, macOS and ChromeOS make up almost 100% of the end-user desktop and notebook computing share.

Microsoft gets it. Apple gets it. And as horrible as they are, Google also gets it.

They make up almost 100% because legacy. They're on top because they're on top and being on top they stay on top using shady practices. Microsoft is even building adware right into Windows itself because they've learned from Google that people will put up with data theft.

If we were all to somehow start off at the very beginning, all things being equal, Windows wouldn't get nearly what it currently has. Apple at least is able to create a cult like atmosphere and people would choose it for those reasons.

[ezst036]

What are the competitors to Mesa in the Linux or FOSS world?