Steam on Linux Gaming Marketshare Steady For April

[blacknova]

birdie

I'd say it's debatable at the very least. Android shows that oem installation can make all the difference.
Of course there should be two distinct arguments for Linux as a kernel and Linux as a platform or an ecosystem composed by so many distributions, maybe too many.

The constant influx of major new features is a good thing! Bugs and regressions are just part of the development process.
Then again, users who need stability should never jump on the newly released kernel...

BTW I read your posts more than once and I think that if you look close enough I don't think any of the major desktop OSes is stable enough to meet your criteria

What I'd like to see from some linux distro is - layered structure where user can interchange each layer to their own needs.
Layers like:
1. Kernel
2. Drivers
3. Base OS (including UI env)
4. User's software

Right now most popular distroes tied everything to distro release. And if you want something new, you need to upgrade. Flatpak introduction somethat solves layer 4. Or user can just install that they need into their home dir and be done.
But it still leave you without ability to update your UI env, kernel and drivers separately from each other.

Don't get me wrong Linux distroes as they are an excelent server, and very good task oriented workstation. But it is very mediocry end user desktop IMHO.

[birdie]

birdie

I'd say it's debatable at the very least. Android shows that oem installation can make all the difference.
Of course there should be two distinct arguments for Linux as a kernel and Linux as a platform or an ecosystem composed by so many distributions, maybe too many.

The constant influx of major new features is a good thing! Bugs and regressions are just part of the development process.
Then again, users who need stability should never jump on the newly released kernel...

BTW I read your posts more than once and I think that if you look close enough I don't think any of the major desktop OSes is stable enough to meet your criteria

I am certainly not a fan of Windows in its default state but I've found solutions to make it near 100% rock solid, for instance, I extensively use SandBoxie+ which allows to install and delete applications without a trace. I even sometimes run malware under it for fun (it's near 100% safe). Yes, Microsoft sometimes releases updates which break stuff but normally fewer than 1% of users are affected and then those users have a ton of software/drivers installed, so naturally Microsoft cannot test all the permutations of their changes in regard to what users are running. There are utilities like e.g. DriverStoreExplorer which allow to safely delete old versions of drivers.

And Windows 10 LTSC is just a joy to use: no Microsoft store or worthless crap related to it, telemetry which you can disable pretty much completely, quite calm updates which don't break stuff unlike the standard Windows 10 which sees major updates/reinstallations each six months.

And then there are tons of free, fast and useful utilities, like e.g. IrfanView which I even use in Linux instead of all brain-damaged half-assed Linux image viewers. Far File Manager is miles ahead (faster, a lot more features, proper code highlighting using Colorer) of Midnight Commander.

[leech]

1. Steam also had very little incentive to do so, if they had more incentive, it would have been faster. steam is a company not a nonprofit.

2. It wouldn't take all that much to port the steam client to arm. especially not when there is so much potential for the arm ecosystem (ChromeOS is working on getting steam working on x86 devices, and also hopefully arm devices anyway)

3. Would mac allow it? Yes. Steam exists on mac.

4. Valve supports linux, because Lord Gaben thought that linux has a brighter future than windows long term. and judging about cloud streaming and the overall direction of windows, looks like they are right. But the users are the issue, windows would never lock itself down to that degree. that would be equivalent to trying to suck start 12ga buck shot.

5.Wine works fine on arm cpu's. Box86 is great for 32bit systems. which is full translation. M1 wine works fairly performant too. as for 64bit full emulation, its still fairly new, but someone is working on Box86_64, and FEX emulator is supposedly good, But I have no arm devices to test it.

1. Well, Valve is a company, Steam is their product. And being that reaching the most users possible vs cost makes me think if emulation is good enough, then it isn't likely they will bother with an ARM port. As you say in your later points.

2. It isn't the Steam client that matters, it is the games.

3. Yes, I know Steam exists on Macs, this was back when Apple was more open and didn't try to make sure they got a cut of every bit of software sold on their platform, in a call for security! They do application verification across the board these days, even bash scripts call home...

4. Ever hear of Windows S-mode? It literally will not let you install anything outside of the Windows App Store. You can turn it off... now anyhow, until they decide you can't.

5. Awesome, so much like developers not releasing native Linux games, and instead support Proton, why would Valve need to port to ARM when Wine+Box86 is good enough?

[Xaero_Vincent]

KDE 1.1 was heavily patched to support modern Linux'es, right: https://github.com/KDE/kde1-kdebase

"Historical copy of the base applications module of KDE 1, adapted to compile on modern systems (circa. 2016) " - your fanboyism doesn't allow you to even follow the news.

Good luck compiling and using the original unmodified sources. Good luck compiling and using the software which no one cares fixing/porting to moder Linux'es.

Even relatively recent KDE 3.5.10 requires a large number of patches to fix GCC compatibility and huge patches to properly support modern software stack because many features the DE relied on were completely deprecated and removed, e.g. HAL.

And that's only for OpenSUSE where some folds keep it alive and spend their time and lives on making it work. In many other distros KDE 3.5 has been either fully or almost completely been removed.

I thought your point was that KDE 1 and 2 apps won't work despite being open-source? They certainly do work and it's because they are open-source that patches have been made to support modern distros. KDE 3.5 desktop and applications live on as the Trinity desktop environment and older Qt3 apps can still work too:

https://www.trinitydesktop.org/

https://aur.archlinux.org/packages/qt3/

There are plenty of ancient applications that no longer work properly or at all on Windows 10, even in compatibility mode. Windows doesn't have perfect backwards compatibility and it shouldn't, as major API breaking changes are sometimes necessary to advance the operating system functionality. In some cases, people use Wine on Linux to run old Windows applications that no longer behave properly under Windows 10.

The bigger question is why you would want to use ancient proprietary binary-only apps on Linux in the first place. Is there a specific application that comes to mind that is of value? The only type of ancient binaries that seem of any value in my mind are games.

For running ancient games on modern Linux, you can use Asgard:

https://github.com/lutris/asgard/

[birdie]

I thought your point was that KDE 1 and 2 apps won't work despite being open-source? They certainly do work and it's because they are open-source that patches have been made to support modern distros. KDE 3.5 desktop and applications live on as the Trinity desktop environment and older Qt3 apps can still work too:

https://www.trinitydesktop.org/

https://aur.archlinux.org/packages/qt3/

There are plenty of ancient applications that no longer work properly or at all on Windows 10, even in compatibility mode. Windows doesn't have perfect backwards compatibility and it shouldn't, as major API breaking changes are sometimes necessary to advance the operating system functionality. In some cases, people use Wine on Linux to run old Windows applications that no longer behave properly under Windows 10.

The bigger question is why you would want to use ancient proprietary binary-only apps on Linux in the first place. Is there a specific application that comes to mind that is of value? The only type of ancient binaries that seem of any value in my mind are games.

For running ancient games on modern Linux, you can use Asgard:

https://github.com/lutris/asgard/

They work only because someone actually went ahead, patched them and made them work. There are literally thousands of other packages no one interested in - what are you propositing to do for the average user? Learn C/C++/cpp/make/cmake/autotools and then learn deprecated and modern Linux APIs because you need to make both work? Are you fucking serious?

Speaking of these KDE 1/2 "fixed" releases - how can I install them in an average distro like e.g. Fedora? Compile them from sources? Just like that? How many users do you think out there are capable of compiling, installing and setting up software. Lastly KDE 1/2 won't just magically work if you compile them from sources for fuck's sake, you'll need to add them to /usr/share/xsessions which again most users are not capable of.

Under bloody Windows 10 I just run Windows 95 32bit applications without any mental gymnastics. Wake me up when Linux features the same level of compatibility with old software. Binary compatibility has been the cornerstone of any successful OS which respects its users. Desktop Linux is not one of them.

And magical TDE - how many distros even include it? What about all the KDE packages not included in TDE? TDE developers, because they needed a moment of glory, rewrote Qt3 and KDE3 APIs and made all the unported KDE3 applications totally incompatible with TDE. That's why I'm not going to touch this asinine product ever. They didn't need to do that, they didn't have to do that, in fact there's been zero justification to that other than to show off.

I don't need Asgard or any of this crap. I need near 100% perfect backwards compatibility thank you very much. Too bad, compatibility and stability are two swear words in Linux. The Linux kernel is project number one in terms of breaking compatibility (under the pretense that it makes development faster and better) and introducing mission critical bugs which sometimes even lead to ... data loss.

[Xaero_Vincent]

They work only because someone actually went ahead, patched them and made them work. There are literally thousands of other packages no one interested in - what are you propositing to do for the average user? Learn C/C++/cpp/make/cmake/autotools and then learn deprecated and modern Linux APIs because you need to make both work? Are you fucking serious?

Speaking of these KDE 1/2 "fixed" releases - how can I install them in an average distro like e.g. Fedora? Compile them from sources? Just like that? How many users do you think out there are capable of compiling, installing and setting up software. Lastly KDE 1/2 won't just magically work if you compile them from sources for fuck's sake, you'll need to add them to /usr/share/xsessions which again most users are not capable of.

Under bloody Windows 10 I just run Windows 95 32bit applications without any mental gymnastics. Wake me up when Linux features the same level of compatibility with old software. Binary compatibility has been the cornerstone of any successful OS which respects its users. Desktop Linux is not one of them.

And magical TDE - how many distros even include it? What about all the KDE packages not included in TDE? TDE developers, because they needed a moment of glory, rewrote Qt3 and KDE3 APIs and made all the unported KDE3 applications totally incompatible with TDE. That's why I'm not going to touch this asinine product ever. They didn't need to do that, they didn't have to do that, in fact there's been zero justification to that other than to show off.

I don't need Asgard or any of this crap. I need near 100% perfect backwards compatibility thank you very much. Too bad, compatibility and stability are two swear words in Linux.

Care to name a few of these "thousands of packages"? Also care to share how the user wouldn't be better served using a modern application with equivalent functionality? I'd honestly like to know about some old FOSS or proprietary Linux applications (besides games) that don't have a decent modern equivalent or fork under current Linux distros.
Even with old games and not using something like Asgard docker images, many games have open-source engine re-implementations that can play the original games with enhanced features on modern distros without any extra hassle.

For instance, Luxtorpeda helps with that:

https://luxtorpeda-dev.github.io/packages.html

When I installed KDE 1 from AUR last night, it compiled automatically with the "yay" AUR helper and automatically put a KDE 1 entry in GDM, so I just signed out and selected KDE 1 and it started right up. I don't know how it's done on Fedora but I imagine someone could just make a 3rd party repository and host binaries packages for it.

What KDE 3.5 applications are missing from Trinity? Standard Qt3 applications don't require the KDE 3 or Trinity desktop environment to run. I also had no problem running KDE 1 apps in Gnome Shell 40 when I tested it yesterday.

[Quackdoc]

Why would people install Linux in the first place when a) Windows 10 is preinstalled on > 95% of PCs and laptops, it works just fine for most use cases and has a great backwards compatibility b) Even if it's not preinstalled, an OEM licence can be bought for as low as $10 or even less c) Windows 10 now supports the entire Linux software stack at near native speeds (WSL2) with no need for "real"/full virtualization?

Because people that hate windows are increasing. windows breaks something for a good chunk of people on a seemingly monthly basis. Shaddy telemetry practices, and who knows what other reasons, I've been requested by old customers to install operating systems other than windows, at an alarming rate, and that's just me. Many computer savvy people are only sticking with windows because their specific app, or environment needs windows. usually corporate or multiplayer games. once those are resolved, I would not be supervised to see a large immigration to linux, purely on the basis, that it's not windows.

[Quackdoc]

1. Well, Valve is a company, Steam is their product. And being that reaching the most users possible vs cost makes me think if emulation is good enough, then it isn't likely they will bother with an ARM port. As you say in your later points.

2. It isn't the Steam client that matters, it is the games.

3. Yes, I know Steam exists on Macs, this was back when Apple was more open and didn't try to make sure they got a cut of every bit of software sold on their platform, in a call for security! They do application verification across the board these days, even bash scripts call home...

4. Ever hear of Windows S-mode? It literally will not let you install anything outside of the Windows App Store. You can turn it off... now anyhow, until they decide you can't.

5. Awesome, so much like developers not releasing native Linux games, and instead support Proton, why would Valve need to port to ARM when Wine+Box86 is good enough?

They will bother, because it won't be just mac, and emulating can cause security issues, since it is another layer you could potentially exploit. if performance was the only factor, valve wouldn't bother porting to linux anything, and just focus on proton/wine. considering it works nearly as performant, enough to any meaningful degree in the vast majority of cases. when optimized.

2. We are talking specifically about the steam client, NOT games.

3.That doesn't matter, steam still exists, and is successful to a degree.

4. WIndows S mode, is not born out of a need to lock users down, but rather a security one, and quite frankly, its really good at that. Microsoft realized the increasing security threat to window's and it's users, and this is one of the steps they took.

5. Already covered that. but ill go in a bit more depth. Just like why valve ported to linux, The least steps a program needs to take, the better, unless there is a valid reason to do so, (IE. Sandboxng). but its the same as M1 rossetta, just because it works good enough, doesn't mean it's the best. emulation of anything modern should always be treated as a stop gap, or as a method of preservation. when a native port is possible. Security and performance aside. another good reason is reputation. You never want the reputation of being a lazy developer. Biases stick with people. and thats not something you want sticking to your name.

Its not hard to port steam to arm, what is hard, is making the catalogue work well with the separation of it, I suspect that would be the greatest limiting issue.

[leech]

They will bother, because it won't be just mac, and emulating can cause security issues, since it is another layer you could potentially exploit. if performance was the only factor, valve wouldn't bother porting to linux anything, and just focus on proton/wine. considering it works nearly as performant, enough to any meaningful degree in the vast majority of cases. when optimized.

2. We are talking specifically about the steam client, NOT games.

3.That doesn't matter, steam still exists, and is successful to a degree.

4. WIndows S mode, is not born out of a need to lock users down, but rather a security one, and quite frankly, its really good at that. Microsoft realized the increasing security threat to window's and it's users, and this is one of the steps they took.

5. Already covered that. but ill go in a bit more depth. Just like why valve ported to linux, The least steps a program needs to take, the better, unless there is a valid reason to do so, (IE. Sandboxng). but its the same as M1 rossetta, just because it works good enough, doesn't mean it's the best. emulation of anything modern should always be treated as a stop gap, or as a method of preservation. when a native port is possible. Security and performance aside. another good reason is reputation. You never want the reputation of being a lazy developer. Biases stick with people. and thats not something you want sticking to your name.

Its not hard to port steam to arm, what is hard, is making the catalogue work well with the separation of it, I suspect that would be the greatest limiting issue.

My point is that Steam is a store. Until there is more software or some compatibility layer in place for them to be able to sell games on ARM, there won't be a need to have an ARM version of the store. And seeing as how they haven't seen the need to upgrade the client to 64bit, and still serve 64bit games through it, I highly doubt we will see a native ARM client. There is no need for one. As you say, the 32bit one runs fine through emulation.
If native ARM games happen, I am sure they will do that.

Windows S is a power grab, nothing more. It isn't anymkre secure than normal windows. See every example around for "we lock it down to an app store for security!" And then every app store getting garbage uploaded to it that breaks security. You knkw, like a hidden cryptominer in a 2048 game uploaded to the snap store...

[Quackdoc]

My point is that Steam is a store. Until there is more software or some compatibility layer in place for them to be able to sell games on ARM, there won't be a need to have an ARM version of the store. And seeing as how they haven't seen the need to upgrade the client to 64bit, and still serve 64bit games through it, I highly doubt we will see a native ARM client. There is no need for one. As you say, the 32bit one runs fine through emulation.
If native ARM games happen, I am sure they will do that.

Windows S is a power grab, nothing more. It isn't anymkre secure than normal windows. See every example around for "we lock it down to an app store for security!" And then every app store getting garbage uploaded to it that breaks security. You knkw, like a hidden cryptominer in a 2048 game uploaded to the snap store...

The difference is that 32bit will work on 64bit, arm will not, also there is a market to sell the games to, but their is not platform to sell them from, aside from itch... and there are games being made for arm that can be sold. but I already said why emulation is NOT the answer, it's a stop gap. also as I said, we have two upcoming methods for emulating 64bit through wine. it's a matter of time on that front.

Also if you really think that about windows S, then you need to re-evaluate it, Windows S is a god send for system admins. as someone who works daily with people, Windows S has been such a time and hassle saver. I'm more worried about stupid people doing stupid things, more than bad actors in an appstore. no more GPO editing, and no more stupid people borking things in stupid ways.