Games run faster on SteamOS than Windows 11, Ars testing finds

When SteamOS and Ganoo/L00nockz become first-class gaming citizens, that's when I'm building a gaming PC for the first time since 2012.

I'm a Mac guy now mainly because of my job and I like UNIX-y stuff now, but of course, gaming is even more lacking than Linux.

We're so close. Once AAA releases and GPU drivers get there, it's over the cliff, and I could see that being in the next five years.

I have always wanted Windows to move to Unix so that I can have the best of both worlds(software development and video games). Glad that we are close to that reality.

You'd also need a sane filesystem.

AAA releases have worked for years with the exception being about 60% of online games with anti cheat. Linux has been a first class gaming citizen for years if you use steam client and AMD gpus.

And that online part is the part that really matters. That's where the games make their money.

Windows has NTFS and ReFS. Both are quite sane and performant.

We've been there since the release of the Steam deck. Really, the only things I can't run on my Linux machine are the games that intentionally break the game with anticheat mechanisms. And it's not all anticheat - there are plenty of titles with anticheat that run just fine.

Check whatever you want to play at https://www.protondb.com/ - chances are, if it isn't intentionally borked with anticheat, it runs just fine. Looking at the top 300 games by Steam player count, 17 don't work, and probably 5 of those are utilities (like Crosshair X and Lossless Scaling).

I know. Neither are either. git is noticeably slower, the locking is untenable, the case-insensitivity is a source of bugs.

Both file systems support case sensitivity.

Use DevDrive in a virtual disk or secondary volume, there are significant performance gains for things like git, nodejs modules, etc.

It helps to know the system. The perf would be an issue with any file system on Windows due to the file system filter architecture.

Locking is a function of the NT executive and not of the file system. It was a design decision. I’ll see if I can dig up the reasoning later.

From the NT Design Workbook, oplocks.

> Because the NT OS/2 I/O system is asynchronous by nature, the ability to make a request and then have it completed at a later time makes it natural for implementing oplocks. Further, because synchronization is required by the file system to determine when the caller has completed its oplock update transfers, the file system can use this feature to block open requests to a file by queueing the I/O Request Packet (IRP) to its internal file control structure until the oplock owner lets it know that it is finished.