Steam Survey Reports The Latest Linux Gaming Marketshare For October

[Weasel]

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.

I don't know what you're arguing for since that's what I said, pretty much. So I guess we agree.

Though making a simple shim is quite the challenge with ELF since most binaries are built with global symbol namespace and without versioned information. Such a pain in the ass.

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.

Each ABI-incompatible version of a library should have a different filename. No exceptions. It's really that simple. If not, it's the library's fault for being designed badly.

Most applications bundle the DLLs because they aren't shipped with Windows though. Not because they are incompatible.

I have no idea why you or others keep claiming that "Windows land" means even open source DLLs. Like, seriously guys? You can make any library for ANY operating system, no matter how bad it is designed. Doesn't mean the OS is bad for having your library, that's on you (the library dev). Just because open source libraries are part of the "linux system" doesn't mean those libraries have equal importance on Windows.

You can't judge "Windows land" by the quality of "Linux libraries" either. It's 3rd party stuff.

But hey, at least DLLs let you easily bundle your library with the app and guaranteed to have zero conflicts in respect to symbol clashes, unlike ELF.

[Weasel]

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.

Yeah, with dlopen/dlsym which is a pain in the ass and requires extra code. Which kind of proves the point that... ELF sucks... since you have to go that extra mile here.

Sadly most apps don't even do that.

So there are applications that manage to-do it perfectly fine in a global name space for the majority of Linux distributions.

No those apps skip the global namespace and quite frankly that says everything.

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.

Not a problem, just copy & paste glibc from another distro.

Yes, it should easily work, if Linux userland was sane.

I know you're going to post now how it won't work, and that's exactly what I mean. It should work, and until it does, the userland is garbage. Some libraries are exceptions i suppose, x11/wayland and opengl probably, those are too low level. (same reason you exclude low level libs in Windows from this)

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.

Like? Pretty sure they fucked something up. I never had issue with gtk3/gtk2 plugins in same process FWIW.

[oiaohm]

Yeah, with dlopen/dlsym which is a pain in the ass and requires extra code. Which kind of proves the point that... ELF sucks... since you have to go that extra mile here.

blender is normal DT_NEEDED with a RPATH no dlopen/dlsym pain in ass. Dlopen/dlsym or masking DT_FILTER .so allow you to use libraries that have unstable soname and a little bit unstable ABI design.

No those apps skip the global namespace and quite frankly that says everything.

Blender used the global namespace debugging features in development like for finding memory leaks and file name leaks.

Not a problem, just copy & paste glibc from another distro.

That exactly what the steam runtime has done. This is not the most extreme example of it.

http://wikigentoo.ksiezyc.pl/HOWTO_Running_Old_Loki_Games.htm

Loki game compatibility is the most extreme example.

I know you're going to post now how it won't work, and that's exactly what I mean. It should work, and until it does, the userland is garbage.

Only recently has the Loki game stunt run into trouble. When mesa started using libstdc++ worse demanding a particular new version of libstdc++ by the global. libcapsule will restore this back.

Some libraries are exceptions i suppose, x11/wayland and opengl probably, those are too low level. (same reason you exclude low level libs in Windows from this)

Very old client side X11 libraries work perfectly based on pure libc so you can bundle those with your application if you want the security problems. Depends on what wayland libraries you mean most are pure libc no bundling problems.. Old glibc most cases this will bundle and work as long as you also bundle any library you are using that the host has updated to require newer glibc.

Yes you use a old glibc with new library you will get missing symbol problems due to global namespace effect. This is not a bad thing when you wake up way memory has been allocated/threading or something has changed as well. So you failed with missing symbol instead of fatal crash at some random time that is insanely hard to debug.

Like? Pretty sure they fucked something up. I never had issue with gtk3/gtk2 plugins in same process FWIW.

I would say you are just lucky and not have a user base of 100000+ users the issue is a race condition meaning you can be luck that is appears to work until it crashes.

Really I am not surprised that you would think there is no issue here. You said it was safe to use multi visual studio runtimes as well. Both a race condition ridden. On windows you have the luck that when programs crash users think this is normal and acceptable unless they happen to be pro audio people(or equal) who have lost a few hours of work due to random crashes then they are really unhappy.

Reality is if you are using gtk2 and gtk3 in the same application process sooner or latter its issues will come out. Gtk2 to Gtk3 documentation is very clear you should not be doing this.

https://developer.gnome.org/gtk3/stable/ch26s02.html#id-1.6.3.4.18

Linking against GTK+ 2.x and GTK+ 3 in the same process is problematic and can lead to hard-to-diagnose crashes.
The documentation is insanely clear. The hard to diagnose crashes are race conditions. So gtk2 and gtk3 in one application will annoying appear to work except its only appearing to work its a matter of time until it race conditions and randomly crashes. Having different versions of cairo giving conflicting directions to your opengl drivers due to using GTK2 and GTK3 in one application does not work out great for some reason.

Yes they altered the gtk_init in gtk2 and gtk3 to attempt to stop this developer mistake early. Gtk2 2.22 and newer attempts to detected gtk3 and if it find it abort. Yes gtk3 attempt to detect gtk2 and abort. To test gtk2 with gtk3 without getting aborts from gtk_init from time to time you have to use prior to 2.22 gtk2 and patch gtk3. You will find out they did not add this detection for no reason if you are tracing the race conditions that come up on Windows, OS X and Linux. GTK2 and GTK3 simply does not get along.

gtk2 to gtk3 is major breakage point. To use gtk2 plugin in a gtk3 program safely will require someone to make a shim to make gtk2 part use gtk3 or Rebuild gtk2 plugin as gtk3 or use process separation. Any other idea is being a foolish idiot ignoring the libraries usage instructions and causing random crashes for you end users.

[Weasel]

Blender used the global namespace debugging features in development like for finding memory leaks and file name leaks.

Nobody cares about debug or development since this is about distribution. You don't distribute debug versions.

That exactly what the steam runtime has done. This is not the most extreme example of it.
http://wikigentoo.ksiezyc.pl/HOWTO_R...Loki_Games.htm
Loki game compatibility is the most extreme example.

No you need to supply the entire runtime, that is NOT good.

I'm talking about supplying ONLY ONE missing library and have it work as long as all dependencies are met.

Point being: libraries should be stand-alone; swapping them should work just fine. Building "the whole environment with same compiler settings" to ensure "compatibility" is such a retarded idea and a spaghettification of the environment. That's exactly what has to be avoided.

Libraries should be swappable between distros. Modular. As long as all dependencies are met, that is. Not have random breakage or symbol conflicts or whatever. This is exactly how Windows non-system DLLs are, that's why they can be bundled with apps in the first place.

Very old client side X11 libraries work perfectly based on pure libc so you can bundle those with your application if you want the security problems. Depends on what wayland libraries you mean most are pure libc no bundling problems.. Old glibc most cases this will bundle and work as long as you also bundle any library you are using that the host has updated to require newer glibc.

Yes you use a old glibc with new library you will get missing symbol problems due to global namespace effect. This is not a bad thing when you wake up way memory has been allocated/threading or something has changed as well. So you failed with missing symbol instead of fatal crash at some random time that is insanely hard to debug.

No that's just stupid. If an app was designed for old glibc then there's no "random time crash". Computers don't work on magic.

race condition

You keep using that word. I don't think it means what you think it means.

Really I am not surprised that you would think there is no issue here. You said it was safe to use multi visual studio runtimes as well. Both a race condition ridden.

It is perfectly safe, as long as you aren't a moron in YOUR own code to mix & match, and I proved it 3 months ago. There's no inherent flaws of DLLs here (the format) just idiots with shit code.

Only your brain is race condition ridden.

Reality is if you are using gtk2 and gtk3 in the same application process sooner or latter its issues will come out. Gtk2 to Gtk3 documentation is very clear you should not be doing this.
https://developer.gnome.org/gtk3/sta...#id-1.6.3.4.18
Linking against GTK+ 2.x and GTK+ 3 in the same process is problematic and can lead to hard-to-diagnose crashes.

I don't see anything about Windows there.

In fact it talks about "distribution". Yep, you know what that means. ELF.

[oiaohm]

Nobody cares about debug or development since this is about distribution. You don't distribute debug versions.

That is wrong. Open source programs like Blender that do distribute to many distributions also do distribute debugging versions even for Windows. Why is that if there is something hardware related diagnostics can be done on it. A developer cannot own every bit of hardware ever made and testing on every bit of hardware ever made would be a waste of time because you customers most likely will not be using every bit of hardware ever made.

So don't try to artificially narrow the requirements. Yes with Visual studio compiler it does not allow you to legally ship the debugging versions. Yes why you see a lot of open source projects and some closed using mingw compiler so they can ship debugging versions on windows to there users in case of problems.

Point being: libraries should be stand-alone; swapping them should work just fine. Building "the whole environment with same compiler settings" to ensure "compatibility" is such a retarded idea and a spaghettification of the environment. That's exactly what has to be avoided.

That is the requirement visual studio default setting drop on you. I do agree totally retard.

Libraries should be swappable between distros. Modular. As long as all dependencies are met, that is. Not have random breakage or symbol conflicts or whatever. This is exactly how Windows non-system DLLs are, that's why they can be bundled with apps in the first place.

Does blender ship with libraries in it portable form on Linux Distributions. The answer is yes. RPATH/RUNPATH .so files are no very much different.

With careful selection of dependencies third party application on Linux behave the same as windows. Thing is a lot of those starting out shipping applications for Linux attempt to make binaries with no libraries shipped with the binary and then use items that are not cross distribution stable.

No that's just stupid. If an app was designed for old glibc then there's no "random time crash". Computers don't work on magic.

The catch here is just because something was built with a old glibc does not mean in all cases it will not work with the newest version of particular libraries on Linux.

This fails with a missing symbol error when it not going to. Of course this would not be able to be attempted if version was solid set by file name.

Yes that newer version of a library you drop in can be the same library you use with the latest version of glibc on the system.

From security you want to use the newest libraries an application will work with. Global symbols system work quite well for this most of the time.

It is perfectly safe, as long as you aren't a moron in YOUR own code to mix & match, and I proved it 3 months ago. There's no inherent flaws of DLLs here (the format) just idiots with shit code.

That means you cannot use Visual studio runtime.

What you don't want to get it is a format problem. For your example to work you must restrict you self fairly much to C and pure win32 api. No C++ on windows or visual studio runtimes(this even takes out using mingw malloc/free).

This is because you don't have global symbols. You cannot say in your program this is malloc when you load the libraries solve out to the newest one and use that. Instead you have a stack of different libraries on windows providing different implementations of malloc that don't get along.

https://en.wikipedia.org/wiki/Singleton_pattern

Basically Weasel you are missing why Singleton are required feature. Yes it useful lots of times to have each dll/so provide it own symbols. Fully implemented ELF can have each .so provide duplicate symbols.

Memory allocation and few other operations are pure singleton. If you have more than 1 of them you have issues waiting to happen due to the different incompatible methods that can be chosen to implement them.

ELF started like DLL with STT_FILE run into the singleton problem with memory allocations went to the global symbols everywhere with the DT_NEEDED. Revised this back with DT_FILTER and DT_AUXILIARY then added versioned. Then versioned grew filter and auxiliary as well.

So fully implemented ELF has all the features of DLL plus GLobal symbol space with default symbols. That global symbol space allows easy syncing of functions that to an application should be singletons.

Its really easy to say drop global symbols while complete missing the history to of where the global symbols were added intentionally to deal with a particular problem that visual studio run-times on Windows suffers from.

Think of this as the normal human problem of over reaction. Symbols per DLL/soname have a downside. As with all things a lot of correct answers are shades of grey. Yes I agree it need to be able to say this symbol comes from X. You also need the means to say this symbol can come from X Y and Z libraries use what ever one is loaded and you need the means as well to say use this symbol out of global defaults so that across the complete program for this function we are using exactly the same one.

I don't see anything about Windows there.

In fact it talks about "distribution". Yep, you know what that means. ELF.

No read it again.

https://developer.gnome.org/gtk3/stable/ch26s02.html#id-1.6.3.4.18

If you are using packages provided by a distributor
They don't in fact say distribution. In fact Mac OS and Windows are done by Distribution as well with GTK check out the download pages for gtk.
https://github.com/msys2/msys2/wiki/...age-management Yes this is third party windows package management.
Funny enough that the windows version of GTK is also provided by a third party distributor same with the Mac OS one.

So no that does not mean ELF Platforms only those instructions are about all platforms GTK supports. The simple reality is GTK2 and GTK3 is like mixing visual studio run-times under windows it can appear work until it explodes in your face.

Weasel you are being excuse maker the reality is your claim that you are using GTK 2 and 3 with each other is either bold face lie under windows is either a bold face lie because the software is designed to fail if you attempt that. Or the method you are using is missing the GTK2 and GTK3 init detection of each other and will race condition at some point.

[Weasel]

That is wrong. Open source programs like Blender that do distribute to many distributions also do distribute debugging versions even for Windows.

That's just disgusting, unless the user specifically opts for it. It's user abuse.

That is the requirement visual studio default setting drop on you. I do agree totally retard.

What? If you are talking about visual studio runtimes, they are perfectly swappable, but obviously same names (so you don't use different versions, cause different names).

Does blender ship with libraries in it portable form on Linux Distributions. The answer is yes. RPATH/RUNPATH .so files are no very much different.

With careful selection of dependencies third party application on Linux behave the same as windows. Thing is a lot of those starting out shipping applications for Linux attempt to make binaries with no libraries shipped with the binary and then use items that are not cross distribution stable.

Sigh. -> means "loads" below. Your app supplies only gtk2 with it.

Windows app->gtk2->libfoo->gtk3->no symbol conflict.
Linux app->gtk2->libfoo->gtk3->conflict and crash.

Because of ELF and the fact that everything is compiled with global namespace, of course. You don't control the entire dependency chain unless you supply the entire runtime which is what flatpak does.

And that's retarded.

That means you cannot use Visual studio runtime.

What you don't want to get it is a format problem. For your example to work you must restrict you self fairly much to C and pure win32 api. No C++ on windows or visual studio runtimes(this even takes out using mingw malloc/free).

This is because you don't have global symbols. You cannot say in your program this is malloc when you load the libraries solve out to the newest one and use that. Instead you have a stack of different libraries on windows providing different implementations of malloc that don't get along.

https://en.wikipedia.org/wiki/Singleton_pattern

Basically Weasel you are missing why Singleton are required feature. Yes it useful lots of times to have each dll/so provide it own symbols. Fully implemented ELF can have each .so provide duplicate symbols.

Stop linking random shit that has nothing to do with anything, just to seem like you have a point.

The funny thing is: you said C++ you can replace "malloc" with global namespace. Laughable how desperate you are. C++ runtime doesn't even use malloc.

Cool story bro, do that with C++'s name mangling where even changing a field of a class changes the mangling and thus name in a function prototype that takes it as arg (or implicit this pointer).

Memory allocation and few other operations are pure singleton. If you have more than 1 of them you have issues waiting to happen due to the different incompatible methods that can be chosen to implement them.

So where is the CLASS of the memory allocation? And the object?

You really love learning new buzzwords to throw around randomly, makes you think you're really smart.


This post has a hidden race condition, go spot it.

[0Yg7pQpFGiwcw]

Someone who actually knows what he's talking about.

Yeah, Artem S. Tashkinov, the anti-Linux troll who in 2018 actually thinks that you can compare security of different software just by counting the CVEs published.

So if anyone mentions servers 1 more time I will kill a kitten every time that word is used. Feel responsible for it.

SERVERS!

Well, you seem to be a totally sane and emotionally stable person...not.

[Weasel]

Yeah, Artem S. Tashkinov, the anti-Linux troll who in 2018 actually thinks that you can compare security of different software just by counting the CVEs published.

Someone can be wrong in one topic and right in another, what's so special there? (I don't even know who he is btw)

I consider "security" one of the most blown out hysteria in today's world along with "privacy" to be honest. (and no, Windows 10 is absolutely awful in both security & privacy, but that's REAL privacy there, not dumb shit like "can't query position of windows", WTF? that's intentional crippling, not privacy)

SERVERS!

Well, you seem to be a totally sane and emotionally stable person...not.

It's just a meme, don't take it so seriously.

But yes, it's damn annoying to see people justify servers when the topic is about desktop or gaming. Nobody cares. That's the problem with Linux community: people can't think outside of servers, that's why the year of the Linux *DESKTOP* will never come.

[ssokolow]

Someone can be wrong in one topic and right in another, what's so special there? (I don't even know who he is btw)

I consider "security" one of the most blown out hysteria in today's world along with "privacy" to be honest. (and no, Windows 10 is absolutely awful in both security & privacy, but that's REAL privacy there, not dumb shit like "can't query position of windows", WTF? that's intentional crippling, not privacy)

"Can't query position of windows" is part of a package of decisions taken from browsers to protect against things like clickjacking and the trick one Windows download manager did using a shaped window to make it look like Firefox's "Someone tried to auto-install this extension. Allow it to be enabled?" prompt was instructing users to click "Yes".

(As I understand it, that trick, coupled with the rise of successful attacks involving talking users into pasting/typing things into the browser console (which is not unlike about:config) was actually the prime example that motivated Firefox developers to force signing enforcement on the branded builds they advertise to "lowest common denominator" users and direct developers and other people who want to disable signing enforcement to completely separate builds, offered from a different URL, and with a visibly different icon.)

[oiaohm]

That's just disgusting, unless the user specifically opts for it. It's user abuse.

Sorry user cannot opt in if you do not provide the file. I did not say that user did not opt in for it. But when you are making up your package that you are going to offer to the user as options you can be intentionally building a debugging packages to ship to users who wish to opt in to solve their problems.

Sigh. -> means "loads" below. Your app supplies only gtk2 with it.

Windows app->gtk2->libfoo->gtk3->no symbol conflict.

No symbol conflict but still fails to run correctly and still crashes. gtk3_init will ball out.

Linux app->gtk2->libfoo->gtk3->conflict and crash.

Have not considered there might be a coding error here.

What a correct should look like one of the following.
1)Linux app->libgtk2-filter->gtk2->libfoo->gtk3
2)Linux app->gtk2(versioned)->libfoo->gtk3
no symbol conflit but still crash like windows.

What would you have libgtk2-filter using DT_FILTER do that right shove versioned symbols on gtk2 and removed all default status from gtk2. But to do this when you build the application you need to have done this.

DT_FILTER file can do 3 things to so important things.
1| version all symbols imported and exported.
2|make no symbol have a default value. Yes versioned func@version does not replace func@@version. Double @@ or left as base says set this function as default both you can remove with DT_FILTER.
3| assign exact .so file to load.

Now this DT_FILTER fix need to be done when the application is made.
3)Linux app->gtk2->stublibfoo->libfoo->gtk3
stublibfoo is libcapsule. But this still will not stop gtk3 detecting and bailing out. And still will not stop gtk2 and gtk3 cat fighting with clipboard, opengl.....

If gtk2 and gtk3 was not such ass of problem libcapsule could be used to fix the developer mistake of not versioning without needing to rebuild the binary.

DT_FILTER/versioned is if developer makes the application correctly so the problem you are talking about should not happen and libcapsule is cover up application developer not doing their job well.

Cases like gtk2 and gtk3 where 1 designed detect and fail 2 get into locking fights over shared resources there is not much you can do except run them as independent processes or turn one into a shim on the other.

Because of ELF and the fact that everything is compiled with global namespace, of course. You don't control the entire dependency chain unless you supply the entire runtime which is what flatpak does.

Not true. This is not know ELF DT_FILTER allows you to have quite detailed control of the dependency chain but you have to make DT_FILTER stub .so files or build libraries you ship with program versioned the right way.

There is a extra step required on ELF platforms making your stub libraries. These stub libraries where you force versioning and then everything you do from you program is versioned causes a lot of problems to go away.

Of course this does not help with the gtk3 issue of gtk_init detecting another gtk in use and committing suicide. The gtk3 release notes to developers would not have had to include not about gtk_init if there was not a method to load gtk2 and gtk3 at the same time. Yes developers who where using the DT_FILTER method on Linux opened issues on the gtk bugzilla about random crashes due to gtk2 and gtk3 fighting over things like the x11 clipboard.

The fact that distribution has not versioned library does not mean as an application developer you cannot use those libraries as if they are versioned this is the magic of DT_FILTER.

Of course filter in versioned is more friendly again.

The funny thing is: you said C++ you can replace "malloc" with global namespace. Laughable how desperate you are. C++ runtime doesn't even use malloc.

objdump -T /usr/lib/x86_64-linux-gnu/libstdc++.so.6 |grep malloc
0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 malloc
If you check libc++ from LLVM project you will also find it uses malloc.

Really C++ runtime does use malloc on fairly much every platform that is not Windows. Yes C++ runtime on OS X, Linux, AIX, BSD, Most unixs all use malloc.

So when you perform a new in C++ you are performing a wrapper over malloc on those platforms. C++ delete is just a wrapper over free.

Weasel as I said using the global namespace I can replace malloc in the C++ runtime on Linux. Because it really does using the platform libc malloc and free or what ever the current global is. So you have libc++ and libstdc++ in one program and they will be using the same memory allocation system so when you share pointers they work. Yes if you allocation something not a class libstdc++ using new on can use delete in libc++ under Linux no problems. This is using two different c++ runtimes by two completely different developers. Yes you do see libc++ static linked into some libraries.

Its laughable how little you know weasel.