>Google Stadia will use Linux for it's OS
Either all those games have working Linux versions and devs are not releasing them or Valve fucked itself by pushing WINE and DXVK development.
Google Stadia will use Linux for it's OS
Other urls found in this thread:
windows 10 is unusable for server side things
even microsoft itself gave up shilling windows server
what you're imagining as a "linux os" is so abstracted when you get into how google even handles high performance computing that it's nearly irrelevant
do explain
>all those games
basically the kind of hyperconverged infrastructure that google uses that comprises a stadia "unit" (not a single instance, the entire DC more or less) is almost certainly completely custom shit. It's not 500 computers running red hat or fedora. It's some very custom operating system derived from the linux kernel. It has very little to do with "the year of the linux desktop"
Well AC:O was already working, some of you fucks even got your hands on it.
Doom Eternal is also going to be there
Those tech demos that you saware most likely just per-rendered marketing, but other tech demos and indie games were also likely to have been used when developing the platfom
>all those games have working Linux versions and devs are not releasing them
Wouldn't be a first. World of Warcraft and Doom 2016 are confirmed to have Linux builds that were never released to the public. I'm guessing games being made for Stadia will also never be released for Linux in any official capacity.
I completely agree with you
Don't recall saying this will make Linux gaming any better.
The one that can contribute to the development of Linux gaming across all platforms is still you
Google makes Android, they were already big Linux fags, you can't use DirectX on Linux, what did you expect to happen? them to make their own graphics library api from scratch?
the problem with linux gaming is that Wine and other solutions such as Proton are dabbing at natively run linux games in terms of convenience and even performance (some lazy developers are using shitty wrappers applied to game source instead of proper ports), not to mention you have to maintain the linux binary whenever linux developers decide to make huge changes in the architecture that can be remedied only by recompiling the program (which is not a problem for primarly linux or multiplatform apps but we're talking about games where developers don't give a flying shit about year after release).
the real shitshow will start when ReactOS gets real driver support and they will figure out all the kinks. this will make linux truly obsolete in terms of being a real desktop solution since ReactOS just reimplements Wine and the only thing stopping it from having full windows software support is that kernel itself is just isn't there right now (linux has it's own trustworthy kernel so it doesn't have problems with drivers and hardware)
>them to make their own graphics library api from scratch?
They actually could if they wanted, they have enough resources.
But no. As points out, some game devs either made native Linuv versions of their games by themselves or got enough shekels from Google to make a native port.
It's probably more cost effective for Google to bribe devs into making Linux (and therefore Stadia) native games than to run translation layers for each instance of the game.
>Google makes Android, they were already big Linux fags
...which is why they are switching from Android (with GNU/Linux) to Fuchsia (no GNU/Linux), right?
>the real shitshow will start when ReactOS gets real driver support
After keeping an eye on that shit for 10 years I have no hope of seeing that happen.
Devs will most likely die of old age before ReactOS gets to the level of Windows XP
They could but what would be the point when OpenGL and Vulkain are both available and already widely supported
>All google projects must go in the exact same direction
I will spell it out for you, Google Fuchsia isn't finished yet, they want to announce Stadia asap, Stadia will be ready before Fuchsia if they use a linux backend for now because that is what they know
My point exactly. They would not do anything useful by making another API.
More logical choices are to pay devs to make their games fully optimised for their platform or in worse case use stuff that Valve threw resources into.
LearnMore is a big contributor. I have confidence that react will do great things.
>Valve fucked itself by pushing WINE and DXVK development.
How the fuck is making older windows games playable on Linux fucking yourself over? Also proton was made to make windows users switch to Linux so more devs will support Linux natively.
>My point exactly. They would not do anything useful by making another API.
I agree
>Valve fucked itself by pushing WINE and DXVK development.
I disagree with this, Valve isn't google, Valve wouldn't be able to pay Ubisoft to build Ass Creed for Linux for example because Uplay doesn't have Linux support so it would only be available on Steam, which Ubi already doesn't want to do.
Valve worked on Proton and supported Wine probably because they want the entire industry to move away from Windows, or at least DirectX, more than they care about getting exclusives to their platform. If they cared about exclusives so much they would moneyhat, wouldn't allow 3rd party keys, nor allow you to launch non-steam games from the client for no reason
fpbp and /thread
These games will be running headless there - meaning they will not be displayed on these computers. This avoids the problem of drivers mostly.
Animation rendering software had capability of running like that on Linux for years while it had no desktop option.
in case Google is using translation layer to run games on their streaming thing, they are using software that Valve helped develop.
That is what Valve wanted, people to adopt their software
It is opensource and easily available on Github
github.com
You're wrong, the systems may be headless, but they're rendering server-side. There are patches out there indicating they're using the RadV driver that Valve also backs.
The overhead from Wine is minimal, comparable to Windows 10's overhead running the same software with its own compatibility layer. DXVK is heavier where games are using D3D11, but its still small enough to not matter in most cases.