Check out our Monthly Survey Page to see what our users are running.
We do often include affiliate links to earn us some pennies. See more here.

Windows 10 S might alarm Valve into boosting SteamOS again

By - | Views: 77,808

You might have heard of Microsoft's latest plans (source) to keep people on their own store, with a locked down Windows 10 S mode to be available on all versions of Windows. This is easily a first step towards Windows 10 S being the first version of Windows that users see.

Windows 10 S is essentially a version of Windows 10 that's locked into the Windows Store with Universal Windows Platform (UWP) apps, so you can't really run traditional applications like Steam and so on.

This goes directly back to how Gabe Newell of Valve and plenty of other developers felt about Windows 8. With Newell saying "I think Windows 8 is a catastrophe for everyone in the PC space.". There's also Croteam CTO Alen Ladavac who wasn't too pleased with it either, he's now tweeted about this latest issue from Microsoft to say " 'I told you so' doesn't quite cut it. :P". Ladavac also said in a reply "Think about it - if apps need to be adapted for UWP, it might be wiser to just adapt them for OSX/Linux instead.".

It makes sense too, if Microsoft is determined to make Windows more locked-down over time, that's not really good for anyone. Actually investing into Linux gaming, where you have far more control opens you up to many more opportunities.

Apparently, Windows 10 S can be upgraded to a "normal" version of Windows 10 Home for free, but the problem is that Microsoft has said around 60% don't even bother to do the upgrade keeping them locked into the Windows Store.

I hope Valve is keeping an eye on this, and it should certainly make Linux and SteamOS quite attractive again for them. There's good reasons why Valve has kept SteamOS around and plans like this from Microsoft (even if they fall through) will happen again and again. If Microsoft fail, they will wait a while and try it another way.

How long will it be until you have to pay to upgrade to Windows 10 Home, how long before the Home edition doesn't exist? Many questions—questions which should probably alarm people.

Thanks for the tip kellerkindt. Note: Article intro updated after publishing to better reflect my own point.

Article taken from GamingOnLinux.com.
35 Likes
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly. Find me on Mastodon.
See more from me
The comments on this article are closed.
124 comments
Page: «13/13
  Go to:

appetrosyan Feb 11, 2018
Quoting: Samsai
Quoting: appetrosyan
Quoting: tuubi
Quoting: appetrosyanRight now the biggest one I face, is the fact that in a complex scene, the rendering speed drops. this all due to the way in which frames are buffered in X.org, and is one of the main reasons why the switch is being made.
OpenGL and Vulkan drivers on Linux make use of direct rendering, communicating directly with the hardware. Frames are not presented through an X.org buffer. What you said is mostly true, but it doesn't affect gaming that much.

Last I checked Vulkan was supported by Croteam (who are doing a great job an away) and Bethesda, (who make great games, and don't support Linux). When we get native support that circumvents the issues of X.org and the common ways of porting games (e.g. SDL) start making use of Vulkan, we're in business.
SDL doesn't really "make use of Vulkan" (unless you use just SDL's built-in graphics routines and even then I think it might just use OpenGL). What you do with SDL is make a window, load up Vulkan and create a Vulkan context/surface/whatever onto that window and start pushing data and commands to the GPU to do things with that surface. The support for doing this was released in last September.

Vulkan and Wayland are quite probably not going to be some kind of silver bullets that will solve the performance issues. Vulkan will allow devs to possibly tweak their games more and parallelize their rendering more than OpenGL allows but that'll largely depend on the devs' ability to make efficient code. As for Wayland, it's not really much of a performance boost. I've used it for a couple of months now and the only real difference between X.org and Wayland is that window movement is a bit smoother, 3D performance is more or less equal between the two.

I would suggest you read my comment a bit more carefully. You are completely right, but I feel that I need to point out a few things.

First of all, when game development shifts towards Vulkan in lieu of DirectX we will not have a distinct disadvantage, as porting a game will no longer involve porting the most difficult part of the rendering pipeline. It will bring Linux and Windows onto the same footing in terms of graphical optimisations. It's not a silver bullet, but it's sure going to help us make a good case for linux gaming. It will definitely help out with the emulation: wine gives you Windows level performance on Doom and Wolfenstein using Vulkan, meaning that we can shrug off - "But you don't have as many games" by saying "Yeah we do. You can run everything you could on windows".

Secondly, Wayland's improved performance stems from a few factors. Most of the applications and games still use X.org, which means that you couldn't detect a performance increase, mostly because you were running it through the same graphical pipeline. If you don't have Wayland running in the background, you will see the difference. Also, Wayland decouples some of the hardware from the software, which (if the developers listen to reason) will allow us to do Windows level customisation to Gaming peripherals. Right now, the only way of creating keyboard macros is bound to x.org. Once we have enough people running wayland full time, we will be able to convince them to let us do some of those things: pass keypresses to specific applications (in gamer world terms 'tis a must).
Samsai Feb 11, 2018
Quoting: appetrosyan
Quoting: Samsai
Quoting: appetrosyan
Quoting: tuubi
Quoting: appetrosyanRight now the biggest one I face, is the fact that in a complex scene, the rendering speed drops. this all due to the way in which frames are buffered in X.org, and is one of the main reasons why the switch is being made.
OpenGL and Vulkan drivers on Linux make use of direct rendering, communicating directly with the hardware. Frames are not presented through an X.org buffer. What you said is mostly true, but it doesn't affect gaming that much.

Last I checked Vulkan was supported by Croteam (who are doing a great job an away) and Bethesda, (who make great games, and don't support Linux). When we get native support that circumvents the issues of X.org and the common ways of porting games (e.g. SDL) start making use of Vulkan, we're in business.
SDL doesn't really "make use of Vulkan" (unless you use just SDL's built-in graphics routines and even then I think it might just use OpenGL). What you do with SDL is make a window, load up Vulkan and create a Vulkan context/surface/whatever onto that window and start pushing data and commands to the GPU to do things with that surface. The support for doing this was released in last September.

Vulkan and Wayland are quite probably not going to be some kind of silver bullets that will solve the performance issues. Vulkan will allow devs to possibly tweak their games more and parallelize their rendering more than OpenGL allows but that'll largely depend on the devs' ability to make efficient code. As for Wayland, it's not really much of a performance boost. I've used it for a couple of months now and the only real difference between X.org and Wayland is that window movement is a bit smoother, 3D performance is more or less equal between the two.
Secondly, Wayland's improved performance stems from a few factors. Most of the applications and games still use X.org, which means that you couldn't detect a performance increase, mostly because you were running it through the same graphical pipeline. If you don't have Wayland running in the background, you will see the difference. Also, Wayland decouples some of the hardware from the software, which (if the developers listen to reason) will allow us to do Windows level customisation to Gaming peripherals. Right now, the only way of creating keyboard macros is bound to x.org. Once we have enough people running wayland full time, we will be able to convince them to let us do some of those things: pass keypresses to specific applications (in gamer world terms 'tis a must).
3D applications that use system SDL already have access to native Wayland and I've also built some games from source so that they utilize system SDL and thus shouldn't be running through XWayland. In both cases I have seen no noticeable performance benefits. X.org just isn't the bottleneck with game performance, sub-optimal OpenGL is.
Shmerl Feb 11, 2018
Did SDL solve relative mouse cursor positioning issue on Wayland?
appetrosyan Feb 12, 2018
Quoting: Samsai
Quoting: appetrosyan
Quoting: Samsai
Quoting: appetrosyan
Quoting: tuubi
Quoting: appetrosyanRight now the biggest one I face, is the fact that in a complex scene, the rendering speed drops. this all due to the way in which frames are buffered in X.org, and is one of the main reasons why the switch is being made.
OpenGL and Vulkan drivers on Linux make use of direct rendering, communicating directly with the hardware. Frames are not presented through an X.org buffer. What you said is mostly true, but it doesn't affect gaming that much.

Last I checked Vulkan was supported by Croteam (who are doing a great job an away) and Bethesda, (who make great games, and don't support Linux). When we get native support that circumvents the issues of X.org and the common ways of porting games (e.g. SDL) start making use of Vulkan, we're in business.
SDL doesn't really "make use of Vulkan" (unless you use just SDL's built-in graphics routines and even then I think it might just use OpenGL). What you do with SDL is make a window, load up Vulkan and create a Vulkan context/surface/whatever onto that window and start pushing data and commands to the GPU to do things with that surface. The support for doing this was released in last September.

Vulkan and Wayland are quite probably not going to be some kind of silver bullets that will solve the performance issues. Vulkan will allow devs to possibly tweak their games more and parallelize their rendering more than OpenGL allows but that'll largely depend on the devs' ability to make efficient code. As for Wayland, it's not really much of a performance boost. I've used it for a couple of months now and the only real difference between X.org and Wayland is that window movement is a bit smoother, 3D performance is more or less equal between the two.
Secondly, Wayland's improved performance stems from a few factors. Most of the applications and games still use X.org, which means that you couldn't detect a performance increase, mostly because you were running it through the same graphical pipeline. If you don't have Wayland running in the background, you will see the difference. Also, Wayland decouples some of the hardware from the software, which (if the developers listen to reason) will allow us to do Windows level customisation to Gaming peripherals. Right now, the only way of creating keyboard macros is bound to x.org. Once we have enough people running wayland full time, we will be able to convince them to let us do some of those things: pass keypresses to specific applications (in gamer world terms 'tis a must).
3D applications that use system SDL already have access to native Wayland and I've also built some games from source so that they utilize system SDL and thus shouldn't be running through XWayland. In both cases I have seen no noticeable performance benefits. X.org just isn't the bottleneck with game performance, sub-optimal OpenGL is.

Fair.

What games?
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.