Steam Survey Reports The Latest Linux Gaming Marketshare For October

[Weasel]

Attempt to tell this to anyone interested in their application performing the best.

You don't get it. The user can always "hack" it, but it should not be by default. Not a default feature.

Why Appinit_DLL is a disaster is those specialised hooks and DLL injections don't have a global. Yes user has to go out of his way to-do it under windows and it also path to failures. So windows users are not use to being able to tweak performance. Please note with blender this tweak can be a 20 percent difference in performance resulting being able to-do 5 days work in 4.

I'm not sure why you bring up AppInit_DLL at all, I never said anything about it. It's still much safer than LD_PRELOAD, but it's also horrible and I do agree.

Sorry no Appinit_DLL is implement in user32 is correct. Appinit_DLL has been deprecated but has been written in the Windows API documentation as required feature of NT 3.5. First bug on AppInit_DLLs was in Windows 95. Yes Appinit is a clear example why DLL injection idea is highly limited and path to failure.

WTF is your point? LD_PRELOAD has *much* worse bugs than AppInit_DLLs and is much more unsafe. If AppInit_DLLs are path to failure (as they are), then LD_PRELOAD is path to insanity.

Windows API is also a C runtime just not to C standard.

It's not. For a long time, msvcrt wasn't even a system DLL. Stop making claims you can't back up.

The Windows API in fact goes out of it way to inverse arguments so you cannot simple one to one the Windows API C functions contained with C standard.

Wat?

Windows people want to make out that C runtime is just another library so they can ignore the elephant in room that you are needing c run-time as a library because windows was made intentionally non conforming. This non conformance leads to a lot of problems.

Non-conforming to what? The C language never specified the std library as a SYSTEM LIBRARY.

If you make the C runtime as a system library, then why not C++ too? Why not other languages? POSIX is clearly biased and wrong approach.

[ssokolow]

The Win API is a mess in MANY other ways but for those there's no POSIX equivalent so let's leave those out since it's unfair to compare. (for example, COM is a monstrosity; message handling is semi-elegant, since it's riddled with redundancy due to historical reasons, but there's no equivalent in POSIX, so again we leave it out)

I think it's very unfair to not give POSIX credit for stopping rather than standardizing even more bad decisions.

We always seem to undervalue the wisdom necessary to not do something.

But you know what's the best thing about the Windows API compared to POSIX? Win API doesn't claim itself as the "one sole truth of how computing should be done" unlike POSIX fanboys who think POSIX is a gift from God and its word is law.

I don't like fanboys any more than you do.

That said, POSIX is the one API that every major platform other than Windows has managed to agree on... and that in itself has a great deal of value.

[oiaohm]

Changing the runtime of an application to what it doesn't expect as a DEFAULT FEATURE is simply insanity, the purest definition of it.

Attempt to tell this to anyone interested in their application performing the best.

I mean, you can STILL do it even without this insane feature, by going out of your way and hooking all the imports. This is possible on Windows also. You have specialized hooks and DLL injections that do the job. That's sane because the user has to go out of his way to do it; it's not THE DEFAULT. It's not built into the loader. It's something the user has to do (or a malware behind his back) so it makes it SANE.

Why Appinit_DLL is a disaster is those specialised hooks and DLL injections don't have a global. Yes user has to go out of his way to-do it under windows and it also path to failures. So windows users are not use to being able to tweak performance. Please note with blender this tweak can be a 20 percent difference in performance resulting being able to-do 5 days work in 4.

https://lwn.net/Articles/691932/ This is only tip of a very big iceberg. If you are using clear os from intel the path you application loads libraries from alters based on cpu. Yes clear in fact depends on the ability to stack libraries.

The default loader contains more than just LD_PRELOAD since Clear from intel added the means to provide override libraries for performance reasons. Yes the ability to force a particular version to be loaded is useful. Its not like when make a program you can make it with the existing run-time to perform the best on all future cpus.

Every platform you listed that adheres to POSIX is because of common history in Unix.

beos/haiku does not have common history of Unix yet has still obeyed the rule of provide 1 set of malloc/realloc/free. Beos documentation simple says use the system provided malloc if you don't and you application breaks your problem.

But AppInit_DLLs are not part of any API or loader, they were part of user32, and now don't even work anymore. That's not the kind of injection I was thinking of (also to change those keys AFAIK you needed root/admin access as well, LD_PRELOAD not so much)..

Sorry no Appinit_DLL is implement in user32 is correct. Appinit_DLL has been deprecated but has been written in the Windows API documentation as required feature of NT 3.5. First bug on AppInit_DLLs was in Windows 95. Yes Appinit is a clear example why DLL injection idea is highly limited and path to failure.

POSIX specifies special rules for C language runtimes, instead of having them as "just another library" (exceptions always suck and are less elegant, not to mention the fact they favor a specific language's runtime here, C). Meanwhile on Windows land, the runtimes are "just another library", nothing special.

Posix has rules of the C runtime that is to C standard. Windows API is also a C runtime just not to C standard. The Windows API in fact goes out of it way to inverse arguments so you cannot simple one to one the Windows API C functions contained with C standard. Windows people want to make out that C runtime is just another library so they can ignore the elephant in room that you are needing c run-time as a library because windows was made intentionally non conforming. This non conformance leads to a lot of problems.

Just compare the mess that is pthreads with the elegance of Windows APIs dealing with threads and other objects; you don't even need specialized functions for each, since they're all objects in Windows.

Does this break the Unix motto "everything is a file" yes it does. When posix did platform neutral things then come back and bother us.

There is work at the moment to alter signals to file handles instead of PID under Linux. Every time you say object on Windows on a Unix system you should say file and if posix not using a file for that at some point someone will have to redesign it at some point.

[Weasel]

Funny. Usually I hear people talking about how POSIX got it right compared to Windows... though they're usually talking about how AppInit_DLLs is a global setting, defined in the registry, while LD_PRELOAD is something you can set in wrapper scripts and which integrates well with existing best practices for preventing problems caused by environment variables.

(There are quite a few environment variables on Windows or POSIX which can cause crazy breakages if you muck with them willy-nilly. LD_PRELOAD isn't special in that regard.)

But AppInit_DLLs are not part of any API or loader, they were part of user32, and now don't even work anymore. That's not the kind of injection I was thinking of (also to change those keys AFAIK you needed root/admin access as well, LD_PRELOAD not so much).

But what I was referring more to API design. POSIX is simply worse in many aspects compared to Win32 environment, here are a few:

• POSIX specifies special rules for C language runtimes, instead of having them as "just another library" (exceptions always suck and are less elegant, not to mention the fact they favor a specific language's runtime here, C). Meanwhile on Windows land, the runtimes are "just another library", nothing special.
• Just compare the mess that is pthreads with the elegance of Windows APIs dealing with threads and other objects; you don't even need specialized functions for each, since they're all objects in Windows.

The Win API is a mess in MANY other ways but for those there's no POSIX equivalent so let's leave those out since it's unfair to compare. (for example, COM is a monstrosity; message handling is semi-elegant, since it's riddled with redundancy due to historical reasons, but there's no equivalent in POSIX, so again we leave it out)

But you know what's the best thing about the Windows API compared to POSIX? Win API doesn't claim itself as the "one sole truth of how computing should be done" unlike POSIX fanboys who think POSIX is a gift from God and its word is law.

[ssokolow]

I mean, you can STILL do it even without this insane feature, by going out of your way and hooking all the imports. This is possible on Windows also. You have specialized hooks and DLL injections that do the job. That's sane because the user has to go out of his way to do it; it's not THE DEFAULT. It's not built into the loader. It's something the user has to do (or a malware behind his back) so it makes it SANE.

But... loading differently based on an environment variable... that the app wasn't designed for... seriously, no words.

Funny. Usually I hear people talking about how POSIX got it right compared to Windows... though they're usually talking about how AppInit_DLLs is a global setting, defined in the registry, while LD_PRELOAD is something you can set in wrapper scripts and which integrates well with existing best practices for preventing problems caused by environment variables.

(There are quite a few environment variables on Windows or POSIX which can cause crazy breakages if you muck with them willy-nilly. LD_PRELOAD isn't special in that regard.)

[ssokolow]

On the contrary it flopped because it was too restrictive. It literally disables even hardware acceleration of any kind (so that apps don't exploit some GPU bugs or do a denial of service). It's beyond retarded. So this only strengthens my point.

Such security is better served by unplugging your internet or not turning your PC on at all IMO.

There are a lot of applications that don't use hardware acceleration, yet almost nobody runs them under X11 SECURITY because it's a bunch of extra hassle that only pays off in an unlikely case.

That's why security has to be by-default. Otherwise, the cost-benefit trade-off prompts a lot of people to procrastinate or gamble on not needing it.

If you don't trust an application then don't install it on your machine it's really that simple.

That's what services like virustotal are for, and if you don't trust those either (because they often miss new malware) then install in a Virtual Machine. That's what they are for.

You and I think that way... but a growing segment of the population does not. That was fine when it was just phones but, with Microsoft and Apple working to bring the same paradigm to desktop OSes, Linux needs to have a competitive offering if it doesn't want to become even more niche in the desktop space.

[Weasel]

If your program wants to run a optimised malloc/realloc/free combination is another reason why having the default global functions is good.

http://engineering.appfolio.com/appf...alloc-jemalloc

This kind of stuff you don't need to change the binaries you are depending on globals. The reasons why visual studio runtimes have different malloc/free... is that they went after performance. Yet there is no framework to plug in different versions across all versions visual studio.

Yeah, that's exactly what I mean with insanity.

When an application is built, it should be perfectly known what the target environment should be like.

Changing the runtime of an application to what it doesn't expect as a DEFAULT FEATURE is simply insanity, the purest definition of it.

I mean, you can STILL do it even without this insane feature, by going out of your way and hooking all the imports. This is possible on Windows also. You have specialized hooks and DLL injections that do the job. That's sane because the user has to go out of his way to do it; it's not THE DEFAULT. It's not built into the loader. It's something the user has to do (or a malware behind his back) so it makes it SANE.

But... loading differently based on an environment variable... that the app wasn't designed for... seriously, no words.

That is the catch. It is in standard. Posix platform standard.

Nobody gives a shit about POSIX.

Most of POSIX is insane and riddled with trash design, much worse than the Win API is.

Every platform you listed that adheres to POSIX is because of common history in Unix.

[Weasel]

Wayland's restrictions came about because the X11 SECURITY extension flopped for being opt-in (eg. Chrome won't run with it enabled) while Microsoft and Apple are trying to extend the Android and iOS security model to desktop applications. (That's why Wayland is a key component of Flatpak's security model.)

On the contrary it flopped because it was too restrictive. It literally disables even hardware acceleration of any kind (so that apps don't exploit some GPU bugs or do a denial of service). It's beyond retarded. So this only strengthens my point.

Such security is better served by unplugging your internet or not turning your PC on at all IMO.

TL;DR: Wayland is part of a push to remain relevant as the rest of the ecosystem changes people's expectations for how easy and safe it should be to install an application. (Do you want Linux to be the Bugzilla of platforms, scaring off potential bug-reporters by offering up user account e-mails in completely un-protected mailto: links as if it's still 1999?)

If you don't trust an application then don't install it on your machine it's really that simple.

That's what services like virustotal are for, and if you don't trust those either (because they often miss new malware) then install in a Virtual Machine. That's what they are for.

[ssokolow]

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.

Same with Android and iOS (it doesn't count if the app only "needs" online access to try to monetize you), but they're still shifting the average user's expectations for how safe and easy it should be to install arbitrary desktop applications. (Not to mention, look at how much of a competitive advantage web apps have when it's so easy and un-scary for people to test them out compared to desktop apps.)

Wayland's restrictions came about because the X11 SECURITY extension flopped for being opt-in (eg. Chrome won't run with it enabled) while Microsoft and Apple are trying to extend the Android and iOS security model to desktop applications. (That's why Wayland is a key component of Flatpak's security model.)

The shift from X11's "enable everything and let the clients sort it out" model to Wayland's "only add new APIs after we're confident that they're safe" approach is basically the same thing as the shift from Mozilla's old XUL-based APIs to Chrome's APIs. (With Firefox being KDE and working hard to extend the design with new APIs everyone wants that GNOME/Chrome isn't interested in offering.)

TL;DR: Wayland is part of a push to remain relevant as the rest of the ecosystem changes people's expectations for how easy and safe it should be to install an application. (Do you want Linux to be the Bugzilla of platforms, scaring off potential bug-reporters by offering up user account e-mails in completely un-protected mailto: links as if it's still 1999?)

[oiaohm]

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.

If your program wants to run a optimised malloc/realloc/free combination is another reason why having the default global functions is good.

http://engineering.appfolio.com/appf...alloc-jemalloc

This kind of stuff you don't need to change the binaries you are depending on globals. The reasons why visual studio runtimes have different malloc/free... is that they went after performance. Yet there is no framework to plug in different versions across all versions visual studio.

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.

Yet you don't have to use one like this as example.

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

There are tones of other explains without being defective choice.

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

Yes the release notes tell you the detection is unstable. Same with the race conditions. The documentation on GTK tells you that you can have stuff work by luck. You have being ignoring parts of the GTK documentation or never read it and have been living in a works for me world. That lasts until the defect catches up with you..

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

That is the catch. It is in standard. Posix platform standard. This is why when you are talking about OS X, Linux and most other operating systems it is that way.

So your "nor anywhere" is wrong. You would have a Posix non conforming C++ runtime if you don't use normal malloc, realloc and free. This is one of the differences you have to be aware about when you talk about Linux or Unix or OS X... Most platforms follow the posix standard guidance on memory to have memory sanity.