Steam Survey Reports The Latest Linux Gaming Marketshare For October

[Weasel]

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.

I'm not sure what your point is. There's plenty of ways to debug "debug built" apps, function relays etc. Because, since they are debug builds, they are MADE to be debugged. You do *NOT* need a built-in DEFAULT FEATURE for that. Your excuse is that ELF helps with debugging. Remind me why the FUCK is a debug-only feature the god damn DEFAULT for NON-DEBUG BUILDS. It shouldn't even be part of the loader.

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

This has nothing to do with DLLs, then. But with a shit library design. You can make a library that calls ExitProcess or exit doesn't mean that DLL/ELF crash instantly and suck.

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.

And yet I'm talking about symbol conflicts here.

You realize gtk was just an example, right? Why are you arguing about gtk's library design itself?!?

BTW I still haven't had problems with gtk apps on Windows so idk maybe it doesn't always trigger. I don't care about this topic to continue it though, it has nothing to do with the thread and you fixate on an EXAMPLE (which happened to be gtk).

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.

There is no global and shouldn't be a global.

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.

There's literally no guarantee they are a simple wrapper over malloc/free, not in the language standard nor anywhere else.

Stop treating malloc/free as special. You have a fucking fixation on them. Symbol conflicts are more than just your fucking libc which you consider "global" and "special". It is EVERYWHERE. Global namespace is EVERYWHERE not just glibc.

[Weasel]

"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.)

Well, I wasn't talking about browsers tho. Most apps aren't even online nor need online access, but of course, that's on the desktop not some shitty mobile environment.

[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 [email protected] 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.

[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.)

[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.

[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]

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.

[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]

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]

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.