Steam Survey Reports The Latest Linux Gaming Marketshare For October

[Weasel]

One of these days you must show us all those magic 3:d party user space libs on Windows that never change API/ABIs (would be interesting considering that the vast majority of 3:d party libraries are cross platform). Yes the OS bundled libraries like WIN32 is mostly stable (but far from 100%) but the fact is that very single non trivial application and game on Windows either bundles tons of libraries or links statically, that is just the name of the game.

Because they don't?

For the love of God or whoever you believe in, can you guys seriously start treating major versions as completely SEPARATE libraries? Please? They ARE even part of the name, especially on Windows where it's literally called libgtk2.dll or whatever.

zlib is called zlib1.dll (for eventual zlib2 maybe in the future). The difference between zlib1 and zlib2 is the same as the difference between kernel32 and user32 -- i.e. totally separate libraries.

All of the libraries that apps bundle are stable though. Going from gtk2 to gtk3 is a change in the LIBRARY itself, like going from GDI to Direct2D. Once you use this mindset you realize why it's retarded to drop "old versions" of a library.

And obviously, most of those DLLs are shipped by apps because they aren't part of Windows, not necessarily that they are unstable.

[bnolsen]

i bought several licenses of torchlight 2 but unfortunately i get fontconfig symbol errors. i was able to play the torchlight 2 demo a couple of weeks ago...

[oiaohm]

Because they don't?

For the love of God or whoever you believe in, can you guys seriously start treating major versions as completely SEPARATE libraries? Please? They ARE even part of the name, especially on Windows where it's literally called libgtk2.dll or whatever.

zlib is called zlib1.dll (for eventual zlib2 maybe in the future). The difference between zlib1 and zlib2 is the same as the difference between kernel32 and user32 -- i.e. totally separate libraries.

Distributions make it clear they will drop old versions of libraries. Because the libraries are no longer maintained and they no longer have any applications using those libraries any more.

Using DT_FILTER on elf zlib1 could be a redirect to zlib2 in future. Every extra old library is something extra to back port security patches to.

Its perfect sense to drop old versions of libraries completely off cliff. The problem is not having shim libraries created in the old library place.

All of the libraries that apps bundle are stable though. Going from gtk2 to gtk3 is a change in the LIBRARY itself, like going from GDI to Direct2D. Once you use this mindset you realize why it's retarded to drop "old versions" of a library.

Is Gtk2 to Gtk3 really like GDI to Direct2D.

https://developer.gnome.org/gtk3/stable/gtk-migrating-2-to-3.html

The answer is absolutely no. There is a 90%+ ABI match between Gtk2 to Gtk3. If a shim was made from Gtk2 to latest Gtk3 this would sync up theme system this would reduce maintenance because fixing flaw in newer gtk would be fixing them all. There is insane amount of duplication here.

Really its retarded to be keeping old libraries around when they should have been converted into shims a long time ago. Distributions don't need shims because the rebuild their applications using the newer versions of libraries. Third parties are the ones who wants shims but they are not putting up the resources to have them.

Solution is easy to anyone with half a brain: take away the global namespace or whatever else that distros use. Make it impossible to be used, literally.

This will not do anything for the library problems. In fact dig you deeper into whole.

[Weasel]

Distributions make it clear they will drop old versions of libraries.

And I will make it clear that they are retarded and deserve a special place in hell.

Because the libraries are no longer maintained and they no longer have any applications using those libraries any more.

Don't distribute the distributions then. Sounds like an oxymoron. They are not the ones who use the distros, the users are. You don't know what binary app the user has.

These piece of shit maintainers need to realize that THEIR USE CASES are not the users' and nobody gives a shit about THEIR systems or workloads or whatever.

They won't realize it tho, that's why we need a new sane desktop distro, catered completely to users' needs (which can happen to be for maintainers too if they become users instead of ego-centric piles of excrement).

Using DT_FILTER on elf zlib1 could be a redirect to zlib2 in future. Every extra old library is something extra to back port security patches to.

This has nothing to do with DT_FILTER or ELF, but the fact that the two libraries are incompatible and "separate" libraries (by design, happens on Windows too), and yet one of them is dropped.

Is Gtk2 to Gtk3 really like GDI to Direct2D.
https://developer.gnome.org/gtk3/sta...ng-2-to-3.html
The answer is absolutely no. There is a 90%+ ABI match between Gtk2 to Gtk3. If a shim was made from Gtk2 to latest Gtk3 this would sync up theme system this would reduce maintenance because fixing flaw in newer gtk would be fixing them all. There is insane amount of duplication here.

Really its retarded to be keeping old libraries around when they should have been converted into shims a long time ago. Distributions don't need shims because the rebuild their applications using the newer versions of libraries. Third parties are the ones who wants shims but they are not putting up the resources to have them.

Dude why are you ALWAYS ARGUING about stuff I already SOLVED. I already said i have no problems with shims.

Removing to me means LITERALLY that the file is NOT FOUND ANYMORE or that its symbols can't be found anymore.

I don't care about the internal implementation of the library. If it's a shim, but still works with same interface for existing apps dependent on it, then it's PERFECTLY OKAY. If it wraps around gtk3, even better.

Removing it means this: "The application failed to load because libgtk2.so was not found." (using Windows message for analogy).

This will not do anything for the library problems. In fact dig you deeper into whole.

Nah, it's unrelated to the above, but it will easily solve half the problems. Considering it's only global namespace-based ELF environments that suffer from it...

[srakitnican]

Weasel, maintainers are just that, maintainers. If the library is not maintained anymore, maintainer can't do much about it except to drop it, especially if there are security issues. There is in fact Enterprise Linux where there developers are paid to maintain old libraries. But other then that it seems there is not that mentality of maintaining interface stability especially since most of the stuff can be compiled from source. For that reason no one is motivated to work on that since it already works for them as is. As oiaohm says the help would really need to come from third parties.

[Weasel]

Weasel, maintainers are just that, maintainers. If the library is not maintained anymore, maintainer can't do much about it except to drop it, especially if there are security issues. There is in fact Enterprise Linux where there developers are paid to maintain old libraries. But other then that it seems there is not that mentality of maintaining interface stability especially since most of the stuff can be compiled from source. For that reason no one is motivated to work on that since it already works for them as is. As oiaohm says the help would really need to come from third parties.

The thing is, "maintaining" a library or a package shouldn't even be a thing in the first place.

The only "maintainers" of it should be the developers themselves. The fact that you need 3rd party maintainers proves just how broken the entire model is. You do *not* need that on Windows or Mac or virtually any other OS in existence: only the developer maintains his work.

Of course, then it should be the job of the developer to provide shims or wrappers for his old interface to his newer one. The fact is that "package maintainers" shouldn't even be a thing. You need them because you cannot do the sane alternative: go to dev's website, download, install or run directly, on any distro.

[oiaohm]

[QUOTE=Weasel;n1058967]I don't care about the internal implementation of the library. If it's a shim, but still works with same interface for existing apps dependent on it, then it's PERFECTLY OKAY. If it wraps around gtk3, even better.

Removing it means this: "The application failed to load because libgtk2.so was not found." (using Windows message for analogy).

Nah, it's unrelated to the above, but it will easily solve half the problems. Considering it's only global namespace-based ELF environments that suffer from it...

Why solve half the problem when partitioning with items like libcapsule can solve close to 98% of the problems.

Symbol conflict or dllname conflict are both global namespace problems. Correction solution to global namespace problems is not transform from 1 type of global name space to another. But create partitioning. Libcapsule partitions the global namespace. So creating global namespaces to like host and for application makes 98 percent of all the problems disappear.

There are exceptions like gtk2 and gtk3 that you have locking hell.

The only "maintainers" of it should be the developers themselves. The fact that you need 3rd party maintainers proves just how broken the entire model is. You do *not* need that on Windows or Mac or virtually any other OS in existence: only the developer maintains his work.

Pull you head out where the sun don't shine. Microsoft ships a lot of MIT or equal licensed libraries as part of windows that are made by third parties. Yes libraries they are 3rd party maintainers to.

OS X is the same. So the developer makes the final binary and sends to customer is large amounts of garbage. Sorry to say virtually all OS in existence have third party maintainers.

Also think how many third party developers bundle their application with visual studio runtime. Those application developers did not make visual studio runtime right. Not everything in the visual studio runtime is in fact by Microsoft.

Stop pretending Windows and Mac and every other OS in existence is not using 3rd party maintainers. Its too complex to rewrite everything from scratch all the time.

Of course, then it should be the job of the developer to provide shims or wrappers for his old interface to his newer one. The fact is that "package maintainers" shouldn't even be a thing. You need them because you cannot do the sane alternative: go to dev's website, download, install or run directly, on any distro.

Exactly the problem lot of up-streams are not creating shims/wrappers/versioning for old interface to new interface.

GTK does not prove the shims/wrappers for windows or os x either. Same with a lot of the other problem child libraries. Yes problem child library have a habit of being cross platform problem child.

Problem here is download gtk2 and gtk3 install on windows then attempt to use gtk2 plugin in gtk3 application watch everything go south. So going to the developers website and downloading has not completely got you out the problem.

Weasel http://www.win7dll.info/ Do take note of the "ApiSet Stub DLL" here. These appeared in Vista. Job is to provide versioned symbols. If Microsoft is willing to have stubs to mask over platform differences. Exactly why could not the Linux Distribution differences not be stubbed over as well.

Remember Microsoft is not just selling and OS. Microsoft is selling visual studio. Application developers buy visual studio and so pay for compatibility.

My problem how is the people required to make Linux cross distribution developer friendly going to get paid. I know this is kind of horrible but Redhat for example selling point is that it has support with a particular list of commercial applications that other distributions don't. There is a limitation on how cross distribution friendly a distribution in encouraged to be.

[Weasel]

Why solve half the problem when partitioning with items like libcapsule can solve close to 98% of the problems.

Symbol conflict or dllname conflict are both global namespace problems.

No, only symbol conflict is. I'm specifically talking about the global namespace FOR SYMBOLS, for fuck's sake. But you're never going to get it, so stay ignorant all you want.

Pull you head out where the sun don't shine. Microsoft ships a lot of MIT or equal licensed libraries as part of windows that are made by third parties. Yes libraries they are 3rd party maintainers to.

OS X is the same. So the developer makes the final binary and sends to customer is large amounts of garbage. Sorry to say virtually all OS in existence have third party maintainers.

Also think how many third party developers bundle their application with visual studio runtime. Those application developers did not make visual studio runtime right. Not everything in the visual studio runtime is in fact by Microsoft.

Stop pretending Windows and Mac and every other OS in existence is not using 3rd party maintainers. Its too complex to rewrite everything from scratch all the time.

This has nothing to do with what the point was, which was about distributing the libraries. You really have a way with words.

"Maintaining" can mean a lot of different things. In this case, it was clearly about distributing the libraries, you damn dummy.

So the "visual studio runtime" (your shitty example) is NOT maintained by Microsoft because, well, in the context of DISTRIBUTING it, the app can distribute it itself. Sure, you can also get it from Microsoft but that's optional.

I don't give a FUCK about your walls of text and your plays with words. Until you can literally get ****ALL**** dependencies of an application on Linux by just downloading the application itself, you have ZERO POINT. And it has to work on ***ALL*** distros, with a minimum requirement obviously. This means you DO NOT download an entire runtime with the app. So flatpak is out. In fact, flatpak even requires to be installed, so it's completely out.

Stop wasting time with bullshit.

Exactly the problem lot of up-streams are not creating shims/wrappers/versioning for old interface to new interface.

Yeah so why the fuck are you arguing then? Good you admit the problem with Linux userland.

GTK does not prove the shims/wrappers for windows or os x either.

But you can just bundle it with the application since it has no shitty ELF global symbol namespace conflicts.

Same with a lot of the other problem child libraries. Yes problem child library have a habit of being cross platform problem child.

No issue with DLLs so it's simply not an issue on Windows or Wine.

Problem here is download gtk2 and gtk3 install on windows then attempt to use gtk2 plugin in gtk3 application watch everything go south. So going to the developers website and downloading has not completely got you out the problem.

Except it works just fine, so stay ignorant all you want. Sorry that DLL is not ELF and it's simply superior.

[oiaohm]

I don't give a FUCK about your walls of text and your plays with words. Until you can literally get ****ALL**** dependencies of an application on Linux by just downloading the application itself, you have ZERO POINT. And it has to work on ***ALL*** distros, with a minimum requirement obviously. This means you DO NOT download an entire runtime with the app. So flatpak is out. In fact, flatpak even requires to be installed, so it's completely out.

I have pointed to functional examples like xonotic before. There are applications out there like it or not that work on all distributions with minimum requirements.

https://www.blender.org/download/

Blender Is another.

So there are applications that manage to-do it perfectly fine in a global name space for the majority of Linux distributions. What is more shocking is how many out there are not doing any tricks other than correct bundling.

Please note all distros is impossible unless you static link or bundle a complete run-time. There are static linked distributions and distributions without glibc out there.

I would guess having x11/wayland, glibc and opengl you would class as acceptable min requirements.

But you can just bundle it with the application since it has no shitty ELF global symbol namespace conflicts.

You can bundle what ever libraries you like with your application on Linux as well and avoid ELF global symbol namespace conflicts. As long as you know what you are doing in versioned.
Then there is using DT_FILTER or symbol versions. And not suffer from global symbol namespace conflicts. Some third party applications in fact do this. But items like blender don't and still work. Blender sticks strictly to the libraries and parts with solid defined ABI and soname and ships anything else.

Global namespace is not in fact a barrier to making third party applications to many distributions. Biggest barrier is libraries breaking ABI or are regularly renamed and developers using those and deciding not to ship those libraries with their application.

Except it works just fine, so stay ignorant all you want. Sorry that DLL is not ELF and it's simply superior.

Fib all you like those making cross platform gtk2 applications migrating to gtk3 found out it does not in fact work on DLL due to other issues. Result was telling everyone to rebuild their windows plugins as well.

[F.Ultra]

Because they don't?

For the love of God or whoever you believe in, can you guys seriously start treating major versions as completely SEPARATE libraries? Please? They ARE even part of the name, especially on Windows where it's literally called libgtk2.dll or whatever.

zlib is called zlib1.dll (for eventual zlib2 maybe in the future). The difference between zlib1 and zlib2 is the same as the difference between kernel32 and user32 -- i.e. totally separate libraries.

All of the libraries that apps bundle are stable though. Going from gtk2 to gtk3 is a change in the LIBRARY itself, like going from GDI to Direct2D. Once you use this mindset you realize why it's retarded to drop "old versions" of a library.

And obviously, most of those DLLs are shipped by apps because they aren't part of Windows, not necessarily that they are unstable.

None of which is a problem if the library writers would maintain forward compatibility by either providing both the old symbols via versioned symbols and the new ones (this is how glibc does it) or do it like oiaohm proposes and create a shim between the old and the new. Unfortunately very few do this, the reason of course is that for many years all the software was distributed with each distribution so this was not a problem.

The only "maintainers" of it should be the developers themselves. The fact that you need 3rd party maintainers proves just how broken the entire model is. You do *not* need that on Windows or Mac or virtually any other OS in existence: only the developer maintains his work.

That proper maintainers does not exist for Windows is the reason why you will find ten million different incompatible versions of openssl, zlib and so on that each application have to bundle since each and every single application developer have to compile them themselves leading to C:\Windows\system32 sometimes having a libssley32.lib with the 0.9.x, 1.0.x or 1.1x ABI forcing every single application to store their own version inside their local Program FIles directory.

And even if the ABI version is the same it might be linked or changed (I've stumbled upon big name softwares that install a completely custom libssley32dll into system32) in such a way that you cannot use them anyway.

So do not pretend that Windows is this magically land or that maintainers does not do a meaningful job (thanks to the work of the various maintainers I do not have to bundle a single 3:d party library on Linux [which I must on Windows] as long as I supply a proper build for each system [which is easy since I don't supply abandon-ware like most games are]).

Does that means that Linux is without problems? Hell no, but that there are things to fix is no reason to go around frothing at the mouth spewing insults as you go along because that is not helping anyone, including you.