Steam On Linux Usage Climbs Higher Thanks To The Steam Deck

[drakonas777]

I don't think that using microkernel instead monolithic one would change a thing regarding Linux desktop market share. In fact, in most cases it would have no difference at all, except perhaps in device drivers area where potentially easier maintainability would contribute to bit better support from the vendors.

"The problem" of linux desktop actually is not a technical one. It's organizational/economical one. As long as there is no a single and clear industry standard linux distribution, linux desktop won't be a thing, because nobody wants to deal with a vortex of distribution segmentation. Simple as that, but of course, there are a lot of details to unpack in this topic and I won't go through them.

I have no recipe for linux desktop to get better, but IMHO we need at least one or preferable both of these two:
a) All major parent/mainstream distros (debian/ubuntu, RHEL/CentOS/Fedora, Arch and SuSE) should at least agree on using the same packet manager, init system, desktop environment/display server and container tech. That alone would help packaging shit a lot, because at least you could expect some fundamental components to be there and dealing with different versions of expected components is a lot easier than dealing with different components. Same shell, default python version, core tools etc. would help too. That will never happen of course, because it's open source and everyone has to demonstrate it's fucking ego by forking shit and reinventing wheels, which are 0.0005% faster, cause it's cool.
b) Some megacorp should create and push linux-based os with centralized and tightly controlled structure and developing model while at the same time being as much open source friendly as possible. For example, Google buys canonical, merges Ubuntu with Chrome OS, calls it Pixel OS and pushes to be full featured OS to compete with MacOS, perhaps in combination with powerful ARM-based Pixel books as well. This is quite unlikely considering Google long term plan is most likely to drop Linux kernel. Furthermore, it would not be an actual "linux desktop", more like "linux based desktop", but you know, i'd rather take that than virtually nothing we have now (from the market share point of view).

To be honest, I don't see other way, unless everything goes into cloud and we use only browser and browser engines for the userspace (which kind of is already happening). However, we are basically talking thin client in this case, not a desktop as such.

[ezst036]

You're gravely mistaken.

In the past we had Loki, Linux Game Publishing, Feral Interactive which ported Windows games to Linux/MacOS. The first two have long been dead/bankrupt/defunct, the latter stopped doing Linux ports years ago.

It's easier to test your game compatibility with DXVK than to have a native Linux port which can break spectacularly at any time.

Loki? Good grief, you're living in the 2000s here. You know that ProtonDB is really easy to use right? While I didn't find a way to exclusively only look at "NATIVE" games, the "most compatible" list is peppered with games listed that are Linux binaries.

It took me less than 5 minutes to find these:
https://en.wikipedia.org/wiki/Payday_2 - 505 Games is porting to Linux
https://en.wikipedia.org/wiki/Euro_Truck_Simulator_2 = SCS is Linux porting
https://en.wikipedia.org/wiki/Civilization_VI = Firaxis ported to Linux
https://en.wikipedia.org/wiki/Terraria = Linux port by Re-Logic
https://en.wikipedia.org/wiki/Factorio = Linux Port by Wube

And then there's Valve themselves, who started porting their games after the days of Loki software. Some of you guys, I think, might be shook by ARK: Survival Evolved who had a native Linux port and went backward to the Proton layer. That's bound to happen but that doesn't mean the sky is falling. And I did take a quick look at timing, at least for Factorio. That was ported to Linux in late 2020, which is fairly recent.

Perhaps your interpretation of my comment is flawed. Perhaps I was not more specific originally. I didn't mean there would be more LGPs, more Loki's, and more Ferals. I meant there would be more of the actual game publishers themselves who wouldn't need some third party maker, they would simply be doing it themselves.

I'm not gravely mistaken, you have this huge problem to contend with, it's called Proton DB. There are tons of these ported/native games.

Citation needed.

My citation is ProtonDB.

[blackiwid]

Here is another clue.

Dude you said just wait a day then you would tell, then do that, shut up yourself a day use your time to get your reasoning correct and then say it, instead of keep going with that "clue" game you absolutely know nobody will figure out if it's not just random text you put out.

The question is does games run much faster, yes no, if no then nothing significantly can chance, or do proton games become through micro kernels more compatible? No. You could argue with driver support but as much as I hate Nvidia for it's licensing if you can see behind the blob shit it's probably pretty good.

So everything that matters most for gamers is close to perfection or needs to be fixed in the proton layer or with native ports so NOT in the kernel.

[AmericanLocomotive]

To get back on the most important question of how can Linux break into the consumer desktop market.

Simple. All of the ugly stuff that makes nerds and geeks love Linux so much needs to be hidden away and abstracted.

It's why the Steamdeck has been successful. Valve worked very hard to make the "Gaming Mode" version of Steam hide all of the ugly stuff. It's easy to use, manages all of the necessary dependencies and they made it difficult to brick the device. The Steamdeck would have not have been successful if it was just a handheld PC that dumped you onto a standard Arch desktop when you turned it on.

It just needs to work. The "consumer" doesn't want to fiddle with stuff. They don't want to have to mess around with a command line, they don't want to have to wait for kernel updates for their new accessory to work and they certainly don't want to spend hours searching for solutions for simple problems.

[Weasel]

What you are saying is a fair argument, but you could have worded it much more politely.

I have already explained why I am forced to do the argumentation in this manner, whether you like it or not. I would prefer that I don't need to repeat this another 1000 times.

Here is a problem with your reasoning: what you are saying is made irrelevant, partially by the first issue, but mostly by the second issue. The whole argument "Is Wine/Proton good enough", or anything similar, is irrelevant in the light of the first two issues. So, I propose that the people here should stop bickering here about Wine/Proton, and concentrate on figuring out the three issues.

Try to figure out the three issues by guesses or by posting questions here; write something constructive. Please stop wasting time and energy on irrelevant issues.

Games on microkernels run at the same speed as on monolithic kernels, for all practical purposes. A monolithic kernel would possibly have a more pronounced advantage over a microkernel for some tasks like massive buffered file I/O (or, maybe not if some IPC mechanism similar to io_uring is added to a microkernel).

An easy way to find out where a monolithic kernel could be faster then a microkernel: look at Phoronix benchmarks for SPECTRE. Whenever there is no pronounced difference in a benchmark, it can also be assumed that no pronounced difference would appear in the microkernel vs. monolithic kernel comparison.

I don't understand why do you care so much about microkernels. All they offer compared to a monolithic kernel is security for bugs in kernel-mode modules/drivers. That's all. And that's simply because each driver/module runs in its own process, same as with userland applications.

ABI compatibility has nothing to do with microkernel vs monolithic kernel. The Linux kernel does support modules and loading them on-the-fly, and if it wanted, it would have a stable ABI for kernel mode just as much as for user mode.

But modules in Linux are loaded as libraries instead of executed as a different process. That's the difference between monolithic and microkernel: loading a library versus executing it as a separate process. The latter has overhead, but is more secure since it can't crash the entire system if it hits a bug, because it's not loaded into the same address space. Note that it can still corrupt arbitrary memory if it wants to, since it's kernel mode, so it has nothing to do with protecting against malware.

What you want is a stable ABI on Linux for kernel mode and modules. We all want it.

Microkernels are objectively inferior to monolithic kernels, because a monolithic module could create its own separate process itself, if it wanted to, and offer the same security and overhead as a microkernel module.

Microkernels modules can't load themselves as libraries though, so they objectively suck compared to monolithic kernels, offering less options.

[Weasel]

I said it already two times: I believe that the microkernel way is the only way for Linux to break into the consumer desktop market, because microkernels could have a direct impact on the Linux desktop experience.

I already said why you don't need a microkernel for a stable ABI.

Completely wrong.

Nope, completely right. Something tells me you have no idea what Linux kernel modules are to begin with.

This is either a misrepresentation or it is too ambigous to make any sense.

??? What is ambiguous and what is misrepresentation? Are you even a developer? Otherwise it's clearly pointless to talk further.

Kernel modules are loaded by the kernel and are executed without any special privilege boundaries, in the same address space (the kernel address space), so they are literally the same as "on-the-fly" loaded kernel code.

Do you know what else has the same characteristics? Shared libraries for usermode. You know what happens if a library causes a crash? Your entire process that loaded it will crash. Same with kernel modules crashing the entire monolithic kernel.

A shared library can spawn a new process, and execute all relevant code in it, using IPC to pass information. This means that if the shared library's process crashes, the library itself won't and the process that loaded the library won't either. Wow, you just have a "microkernel" now! Well it's userspace still...

Now back to kernel modules, which are kernel space. Are you saying a kernel module which has vastly more privileges than a userspace shared library can't do it? If so, why exactly? Legit you have no idea what you're talking about.

Incorrect.

Nope, completely correct. See above. Kernel modules are loaded as libraries into the same address space of the kernel. This literally means they have the same privileges and everything as the kernel itself. And the kernel itself can create another process and execute code there, since it has full privileges. So a kernel module could create a microkernel process to do its stuff with IPC after that.

Someone could even write a (static) library for this.

You can't have it the other way around, ergo microkernels are objectively inferior.

[blackiwid]

What you are saying is a fair argument, but you could have worded it much more politely.

I have already explained why I am forced to do the argumentation in this manner, whether you like it or not. I would prefer that I don't need to repeat this another 1000 times.

That is what I just even thought about when I heard your statements and was not surprised to find it in your double bind thing:

a theory on the origins of schizophrenia and post-traumatic stress disorder.

You use the word "forced" so what extreme hurt do you get if you don't do this unproductive and hyper annoying way of doing nothing? Is holding somebody a gun to your head, or do you use the word "force" by some minor subjective bad, that is no real force? Are you forced because you believe you could not win the argument or convince people otherwise? How is that a force, is your existence threatened when you loose that argument?
Also why do you lie that people only have to wait 1 day to get real answers, and then you don't wait the 1 day but instead start again with this useless "clue" stuff?

Here is a problem with your reasoning: what you are saying is made irrelevant, partially by the first issue, but mostly by the second issue. The whole argument "Is Wine/Proton good enough", or anything similar, is irrelevant in the light of the first two issues.

You can't use secret "issues" and say, because of this secret, you are wrong... Should I do it again, because of a argument I know my 5. argument that I don't tell you all you say is wrong!

My 5. argument is so good that it disproves all your argument, proof me wrong!

Games on microkernels run at the same speed as on monolithic kernels, for all practical purposes. A monolithic kernel would possibly have a more pronounced advantage over a microkernel for some tasks like massive buffered file I/O (or, maybe not if some IPC mechanism similar to io_uring is added to a microkernel).

Are you now mention a argument that is against your theory?

[sinepgib]

Oh, and by the way, in a world where we want our voice chat system to use less than 3% of our CPU so that we can use it while doing Other Important Stuff, following a world where we wanted our MP3 player to use less than 3% of our CPU so that our desktop was still responsive, to a world where we are trying to undo the micro-impact of handling IRQs in order to limite system latencies because we want to have a smooth desktop experience, I can alreasy tell you that lossing 5% of your CPU time in context switches in just absolutely insane, and no, you won't be able to completely optimize that out. That it would make the whole plateform insufferable. That's the consumer desktop use case.

Eh, I see a huge double standard in the software world wrt perf. We expect our kernel and drivers to do all that hard work to optimize away that 1-3% of overhead and then we ship Electron apps to thoroughly shit all over the place, add some Snap* on top to waste just a little bit of paper cuts on top and make low-end hardware unusable. But we OBVIOUSLY care about perf when someone suggests something that may add actual reliability but comes with a perf cost that is an order of magnitude tinier than all this nonsense.

*I know, I know, I complain about Snap/Flatpak/pack-a-distro-solutions but simply the fragmentation and lack of stable interfaces makes it unavoidable, and the only alternative will never be doable with the bazaar model nerds seem to love.

[Gps4life]

There are more companies today that make native Linux ports than there were 4 years ago.

4 years from now, that number will be even larger. It's a growing market, that's why they would both need and want to.

I see progress too. Now when I ask for a Linux version, I do not have to explain what Linux is.
I try to vote with my wallet, buy only games that run native on Linux.

[birdie]

Loki? Good grief, you're living in the 2000s here. You know that ProtonDB is really easy to use right? While I didn't find a way to exclusively only look at "NATIVE" games, the "most compatible" list is peppered with games listed that are Linux binaries.

It took me less than 5 minutes to find these:
https://en.wikipedia.org/wiki/Payday_2 - 505 Games is porting to Linux
https://en.wikipedia.org/wiki/Euro_Truck_Simulator_2 = SCS is Linux porting
https://en.wikipedia.org/wiki/Civilization_VI = Firaxis ported to Linux
https://en.wikipedia.org/wiki/Terraria = Linux port by Re-Logic
https://en.wikipedia.org/wiki/Factorio = Linux Port by Wube

And then there's Valve themselves, who started porting their games after the days of Loki software. Some of you guys, I think, might be shook by ARK: Survival Evolved who had a native Linux port and went backward to the Proton layer. That's bound to happen but that doesn't mean the sky is falling. And I did take a quick look at timing, at least for Factorio. That was ported to Linux in late 2020, which is fairly recent.

Perhaps your interpretation of my comment is flawed. Perhaps I was not more specific originally. I didn't mean there would be more LGPs, more Loki's, and more Ferals. I meant there would be more of the actual game publishers themselves who wouldn't need some third party maker, they would simply be doing it themselves.

I'm not gravely mistaken, you have this huge problem to contend with, it's called Proton DB. There are tons of these ported/native games.



My citation is ProtonDB.

I don't see Ubisoft, EA, Microsoft, Activision porting anything to Linux. I haven't seen any modern AAA titles ported to Linux in the past three years. Again, Proton makes porting redundant.