Linux gaming is faster because Windows APIs are becoming Linux kernel features(xda-developers.com) |
Linux gaming is faster because Windows APIs are becoming Linux kernel features(xda-developers.com) |
You could be more like Plan9, Linux. You could actually innovate and create new paradigms that make people look at MacOS and Windows and think that they are no longer in the same league.
But you don’t want to do that. You want to play games faster.
Fucking children run the world today. There are no adults keeping track of things making sure that as we go forward that things make sense. There’s no adult supervision in the computing industry anymore. None. It’s all just profit margins calling all the shots. Asinine.
How did it turn out for windows, being “The OS for Games”? Not great, I’d say. Windows is quickly losing that title and will soon become more and more irrelevant for gaming. If you focus on games until you’re “The OS for Games” then decide to innovate on real things that matter outside the home, then you’ll lose that title just like Microsoft is losing it now, and it will happen a lot faster for you than it did Microsoft, because the Linux community is about as organized as an Oklahoma town recently destroyed by a tornado.
Games are fast enough for anyone and there are certainly enough games today that if 5 people lived for 500 years each, there’s not enough time for them collectively to play all games that are available today.
I don’t know what you gamers think the “end game” is for games. Graphics? When are you meant to be happy? When will you stop and say, “ok, we made it”?
Graphics. Pfft. Games do not get better with more realistic graphics, and you know it. Great games are great because they are well thought out and well tested. Great games are not great because the shadows are sharper or because the reflections are more accurate. Some of the shittiest games ever look amazing, and some of the shittiest looking games are S-tier. And you all know it.
Old man mode: off
Look at Plan 9, if you haven't. I can open a window, add/remove things from its environment (via mounting and unmounting files into that window's namespace) seal that environment to prevent changes, then launch a program.
The program can only see what is available to it via the file system. If it has no /net folder then it can't talk to the network. At all. If it has a truncated /env then it can only see a subset of the environment variables available to me, the user.
EVERYTHING being a file is ... weird. Unix has that, but Plan 9 takes about as far as it can go, which is pretty far. But that makes permissions to things quite easy, because file permissions are easy.
The other thing that Plan 9 does is that everything is a file, including your environment, mounting and unmounting things from/to your environment is how you gain/deny access to yourself and to programs.
If this permissions model was common, ransomware would have never been possible. No virus could infect your system, only its own environment (with caveats).
If you already know all of this, I apologize. If you don't, then you owe it to yourself to have a look at Plan 9. It's very weird, but once you wrap your head around it, you start seeing why some people really rave about it.
There's a channel on YouTube called "adventuresin9"[0] which has TONS of content about Plan9.
Seriously, is it really a victory if you have to adopt the architecture of your sworn enemy?
To quote Linus Torvalds from 1997: "I don't try to be a threat to Microsoft, mainly because I don't really see MS as competition. Especially not Windows - the goals of Linux and Windows are simply so different."
Let's take a simple example.. to send a network packet to a different machine, you just call into the Linux kernel, which dispatches your stuff directly to the network card, and you're done. Pretty simple. However if you want to send a message to your neighboring X11 window, you have to go into the kernel to do IPC, which then somehow dispatches your message to the server process, unblocks and schedules the message pump in X11, which finds your window, then once again you go back into the kernel... then your target process is scheduled, so on and so forth.
Wildly inefficient, yet Linux never got proper good IPC merged (until binder), low latency audio sucked, and none of this coordination logic or audio processing got in the kernel.
Why? Because servers don't need that stuff and some server engineer isn't going to know or care about your use case, you're just small fry, and none of the stuff you do is worth taking on technical risk or slowing down server workloads.
> the goals of Linux and Windows are simply so different.
So different that Windows muscle memory works on most main stream Linux UI's, Many (most?) Steam games run on Linux, and now we have Windows in the Linux kernel.
Windows copied futexes from Linux first, anyway.
It is no different from arguing how Linux is getting better GameCube games with Dolphin.
Also Valve is only as good as its current management is still around, eventually like any other company time will pass, and new warm bodies will take other decisions.
technical details or real-world outcomes?
This isn't Linux looking to destroy MS, this is mostly Valve understanding the requirement for an OS that won't be able to become predatory to them and their business model in a single system update.
https://www.collabora.com/news-and-blog/blog/2020/08/27/usin...
Compilers cost real money back then. Word got out that this was how you got a free compiler. You just wrote a linker, and you got in touch with Bill and offered it to him. (You did have to write your linker in a single huge file of assembly, because you didn't have a compiler or a linker yet. It was fine, more programmers knew assembly back then.)
Microsoft has thousands of linkers. They're the linker company now.
Most of their other products started as test cases for their linkers, that they also happen to sell separately as a side business because why not.
Excel is a notable exception, because due to a series of overengineering decisions, it actually is a linker that gradually gained spreadsheet features.
In my eyes, Windows used to be the desktop environment that "just works and can run almost everything". Lately it's becoming enshittified, with weird bugs showing up more and more frequently (a memorable one is not being able to launch Notepad from the start menu!!). I think Microsoft is losing its best attributes when it comes to consumer software. Linux may not be perfect but it's looking more and more attractive in comparison, even with its imperfections.
1 + 1 = 2
all that said, they view this as enabling the consumer by supporting their hardware better, they have an antagonist, mafia-like relationship with game developers.
Lol.
Post doesn't sound explicitly vibewritten, so probably just a non-technical person.
They stumbled into the perfect spot with the iPhone, then IAP sweetened it.
Since they found money they support it. But in the process they’ve really destroyed gaming on the platform unless you want casino games or candy crush/clash of clans things designed to extract money and show another ad every 12 seconds.
Yeah they show Resident Evil VIII and Assassins Creed Whatever but they don’t sell much. And the race to free IAPs created mean good games can’t sell even at a single $2 purchase.
Apple Arcade is the only sanctuary. I haven’t heard good things from the dev side, and it’s 80%+ old games from before things were destroyed or IAP riddled games with the IAPs removed, at times not even rebalanced.
I use it because it’s about all that’s left. But iPhone gaming is a shadow of what we had in the early years.
And at this point there is no competition left. The smart phone ate everything. And as far as I know Android games are in the same mess.
A good example of this is the Final Fantasy Pixel Remasters, which were so lazily ported that most fans advocate for pirating the originals instead. Why should anyone pay $14.99 for the bad version of FFVI?
I had to ask google, because the article fails to explain it. Google says yes, this is something else than the fsync syscall (man 2 fsync).
How do I actually see the graph?
All I see is stats for April:
- Windows 93.47% +1.14%
- Linux 4.52% -0.81%
- OSX 2.01% -0.34%
That's why Linux keeps getting better while the others keep getting worse.
Which is a weird thing to think about, and not sure very lovely.
What changed? Do game manufacturers make special versions with toned down anti-cheat specifically to run on the steam box/Linux?
https://www.kickstarter.com/projects/944362954/bapaco-the-wo...
Interesting, but I wish it was half the size folded...
It will be interesting to see how native Linux games differ in what fancy under the hood kernel or syscall features they use.
Sure it might take at least 20 years I assume.
But definitely a possibility.
> The ntsync driver creates a single char device /dev/ntsync. Each file description opened on the device represents a unique instance intended to back an individual NT virtual machine. Objects created by one ntsync instance may only be used with other objects created by the same instance.
So you need a server process that can open the char device and hold onto the fd that you can then request through a Unix domain socket.
The only thing missing is my Adobe stuff. I now run Lightroom in a VM and it's incredibly slow to unusable.
It runs super smooth, with the build in 'wayback machine' and 'curated' Arch distro (7.0 zen kernel just dropped a week ago) pretty much bullet proof for beginners or as a daily distro if you want to get stuff done w/o caring much about it - just loving it. On the other hand side you have cutting edge gaming tech like wine/proton staging versions per default, so I'm playing Blizzard games with NTSYNC (the tech from the article) for several months now :) Forgot about most of the flashy default UI though :D
It's true what Max Planck said that science advances one funeral at a time. So does the tech industry as a whole.
- occasionally an online game breaks and it's usually fixed within a day or two. for example at some point a Battle.net update broke the launcher under Wine some time last year, then for a while Overwatch would intermittently crash once every few sessions. I haven't gamed on Windows in years so I can't even compare anecdotally, but I suspect Windows is probably slightly more stable with live service games. I've never had any issues with a single player game, period. (YMMV)
- DX12 performance is 10-20% worse on Nvidia. This should be improved Soon (TM) - I think the last piece is https://github.com/HansKristian-Work/vkd3d-proton/tree/descr...
- Some anticheats block Linux - the only times I've switched over to windows in the last year have been when some friends wanted me to play Marathon with them
- Running 'sidecars' alongside your games or modding works but is generally more of a hassle with wine
things I didn't expect to work but do:
- Game streaming with Sunlight works fine to Samsung TV via the TizenOS Moonlight app
- Nvidia had suspend issues for a year but those have all been sorted out the last few months
I've only run into a few big issues. One is that gamepass doesn't work at all (of course) so I cancelled it when I switched, but between price increases and BDS I would have cancelled anyway. The other is anticheat like everyone says, but the only game I've actually run into this with is Fall Guys (I only play this every few months and it usually works with some fiddling but sometimes it doesn't). Other multiplayer games like Rocket League and all of the Valve ones have been fine.
The only issue I can remember running into on a steam game was a crash in Civ V multiplayer that had an easy to find workaround. Outside of steam I've had a few small issues with older games from gog like Arcanum and KOTOR2, but my understanding is that these are fairly buggy on windows too.
For the most part the games just work, it's more system issues that I've run into where Linux suspend mode and the audio stack can be a little flaky and required Claude to diagnose and sort out.
love linux but the audio situation has always been bad.
And I didn’t expect: VR streaming works flawless, too. I just had to buy a WiFi 6 usb dongle.
Windows API's.
> That's not "Windows in the Linux kernel".
How is that not?
That's not a bug, it's a feature.
A control panel (or cross-distro YaST) would be very welcome in the ecosystem I think.
Module-wise - once you have the F/A-18, a lot of the other modules feel like wasted money. I can wholeheartedly recommend the AJS37 Viggen when it's on sale, for $30 it's got a lot of flexibility and surprisingly simple systems for a 1970s jet. It's very easy to memorize the cold start process in the Viggen too, which makes it a joy to get off the tarmac. The JF-17 is also a barrel of fun, and much easier to fly/fight in than the F-16 if you don't have a HOTAS and don't need JHMCS. Besides that, the only other modules I can fully recommend is the Syria map, Persian Gulf map, and Flaming Cliffs for all the modded planes it unlocks. Not personally a fan of the Sinai map right now, and the Apache is very difficult to fly without a copilot/gunner in the second seat. Black Shark 3 is fun, but one of the most goddamn complex modules in the game. Even with translated cockpit labels, you'll be permanently conjoined to a YouTube guide telling you how to do the most basic flight maneuvers.
I encounter a few games with frame pacing issues, otherwise not present on Windows. Shader compile time is longer than on Windows. Occasional crash in some games, etc.
Windows has issues too. It's not perfect, although they are different issues to Linux.
Ryzen 5800x3D RTX 4080 64GB DDR4 @ 4000 M/T's
That's not "more accurately", that's just a completely different thing. When I'm on Mac, my muscle memory is thrown off. I'll be typing and my ctrl+s, alt+tab, win+4, ctrl+left* all cause wildly unpredictable (to me) things. I'm currently using Linux, and all of those things work how I expect (with a tiny asterisk on win+#). When I want a control panel, I press the windows button on my keyboard to open something functionally equivalent to the start menu, and open System Settings to get something functionally equivalent to the control panel.
I have no doubt that I could learn the deep differences between Windows and Mac over time, but the initial muscle memory causes me stress before I get to that point. When I switch to Linux I don't have that stress, and so I've been comfortably learning those differences.
* - save, switch to the previously in-focus window, switch to the 4th program on the taskbar, move the cursor one word to the left
Tbh it's not even muscle memory, how often do you edit config files?
It helped that the DOS executable format was the same as the CTOS format - because we had traded Bill Gates our linker (which produces executables) for his BASIC compiler.
Thanks for sharing, never heard about it before. What was kernel programming back then? Briefly checked the wikipedia and looks like CTOS was kinda big in the government space back in the 80s.
The kernel was in Intel ASM86 but the rest of the OS was written in PLM86. When I joined it was 2MB of code on a 128K 8086 cpu. By the time I left it was 9MB of code running on an 80386.
What does this mean? System calls?
https://www.geeksforgeeks.org/operating-systems/traps-and-sy...
Decades ago I ported some games to linux but I do think proton is the correct approach now. One underappreciated advantage is you get most of the mod environment too. In ESO for instance, there is an addon (tamriel trade center) which lets you download item prices, but it requires a windows client exe to do that. That client works on proton.
I also do some modding myself and can cross compile my rust code to windows with cargo xwin, and run it right away in proton, which is fairly amusing to behold.
I actually don't mind windows generally (been a MS user since DOS 5), but Win11 is a game changer, pun intended, and not in a good way.
If you look at Steam, and OSs like Bazzite it’s clear the consumer-side is finally shoring up. But that aside, from an economic incentive, game providers (for example Amazon Luna), don’t want to be paying the licenses for running Windows machines for Video Game Streaming on Demand. In fact, at my time there one of the major thing I worked on was figuring out how to stream the games using Linux + Proton + Vulkan so we could use the AMD machines.
Honestly the biggest hurdle was (and probably still is) Anti-Cheat and BattlEye.
At any rate, I’m personally happy to see this trend as I haven’t had a Windows OS since Windows 7.
I can't prove it, but the Steam Deck has probably torn down a lot of barriers for mainstream use among the crowd that care about the game more than the OS. Getting some of the other games (League, Vanguard, Warzone, BF6, etc.) or whatever is popular in those segments onboard might be the critical mass that justifies fixing all the rough edges that get fixed when a big pile of users are represented.
If you want statistics, Linux’s gaming market share is 2x that of MacOS.
The barriers to gaming on Linux have never been lower. They’re certainly much lower than the barriers to running windows games on windows were back in the Win 95 - XP SP2 days (when I jumped ship).
Userland anti cheats can work (and do) on Linux if the developers want to. Most of the third party ones the developer buys/licenses already do.
But reality is that only the kernel level ones seem to work to some extent. Difference in the amount cheating between counter strike and valorant is just massive (both free to play games)
It is the absolute best for backwards compatibility: it runs 16 bit apps.
Now it is getting faster for gaming.
And the reverse relation is also true: In Linux, the best backwards compatible stable API is WinAPI.
I can play 30 year old Windows games in Linux. They just work and run better than ever.
For the same project (https://www.descent2.de), I can not even install the dependencies to compile it in a modern distro, as every library is deprecated and removed from the repositories. The precompiled native Linux binaries also can't work.
This NTSync stuff is very impressive, but I haven't seen a lot of end-to-end numbers versus Windows. The last comparisons I saw showed pretty much every distribution on the order of 5-30% behind Windows, varying on the game. And Nvidia GPU support was still not great.
I WANT to swap. Please give me cause to do so. I'm sitting here with my finger on the button waiting for it to finally get good enough to make sense.
I'm just realizing that I can't play Battlefield 6 and I do wonder what the path is. I don't think it's ever going to be supported on Linux or Mac.
Fixed in Wine 11.0. Thanks to the Wine team.
Not sure if this was related to NTSYNC, but Wine's locking infrastructure definitely got an overhaul.
I recently completed Stellar Blade with zero issues.
I don’t even shutdown the machine, I just hit the power to sleep it. Instantly resumes where I left off.
Incredible to see just how far it’s come.
It's curious that they didn't do this as file descriptors that can be epolled. For example I think you could do semaphores and events with eventfd(2), which always struck me as inspired by those Win32 objects somehow. But maybe this is a simpler purpose built interface.
edit: i think so https://github.com/zfigura/wine/blob/esync/README.esync
I was pleasantly surprised at just how many of my games worked well on my new Ubuntu install. Even more so at how many games are playable on my Xubuntu Chromebook install.
I played through Miles Morales at full specs a few weeks ago, and it ran just about perfectly as far as I could tell.
That's where Valve's Frame brought huge expectations.
I also can run Windows games from the 2000s or 90s that didn't not work in Windows 7's basic compatibility options because of old video drivers and whatnot. They run just fine on Ubuntu through Steam, just add the exe or installer as non-Steam game, add Proton and voilà, also sometimes there's some headache around making it work when the exe requires the CD inserted to play, even though I have mounted the CD files in a drive in the wine/proton prefix. I wish there were scripts to do that easily, even adding the exe as non-steam game, changing the name, etc. is not very convenient, I wish there were scripts (Lutris does some of that but not the CD part).
I should also mention that I do not play competitive multiplayer games that have kernel-level anticheat anymore. Check out https://areweanticheatyet.com/
Tom's Hardware is a bit before my time, but I remember it being well regarded. I've seen a lot of similar articles under that name lately. I wonder if they've undergone similar fates.
Oh look at that, XDA and HTG are both owned by Valnet:
There is the odd decent nugget in there, but it is a shame seeing them fall like this. Unfortunately the same sentiment is true about most news sites now.
I'm about to beat Lies of P :)
Now seeing Linux just absorbing Windows APIs into the kernel to make gaming work better? That is the opposite direction. This is what PC gaming needs.
I got into PC gaming when I got my Ambra Hurdla SX25 in 1992. Back then it was the fantastic era of first for everything. We got Comanche, Alone in the Dark, Dune, Dig, etc. First of all game types, not just clones of the same concepts.
Steam+Proton makes everything I play just work: Helldivers 2, Slay the Spire 2, No Rest For The Wicked, FF7 Remake, Stardew, modded Lethal Company (using r2modman) are the main things I've been playing recently, and all worked out of the box with Proton.
My PS5 controller may have needed me to install one package or something but has been working flawlessly after that.
I keep a Windows drive around for stuff like Apex Legends, Battlefield 6, but I pretty much never boot into Windows anymore except for those.
(I probably sound like a shill at this point, having commented something like this on multiple Linux threads now, but I continue to be impressed at how well Linux performs for gaming these days!)
[0] Arch Linux, btw, because that must be mentioned.
I have been using Linux for nearly 30 years now, including running CS (HL1) via Wine with better performance and stability than Windows 9x on a LAN party. Good times.
Sometimes native ports don't get updates, while Windows port does. If you can then run it via Wine, you may have a more stable/less buggy experience.
Note I use both Wine and Proton. BG3 I run with Proton. But Proton is 'just' a fork with (neat) improvements which also partly got backported.
Oh, and I have to mention, I don't use Arch Linux.
I was playing Project: Gorgon recently, I was about to refund because it ran terribly on my machine (despite the low end graphics), when I noticed it was using the native build, switched to Proton and got a 200% FPS boost.
As long as I can play on Linux, I don't care what translation layer it goes through.
Among many game developer studios, the Steamdeck is increasingly becoming the defacto low-spec hardware target. Running their game on a Steamdeck becomes a core part of the QA process, because there's a few million Steamdecks out there actively playing games, and if your game runs on a Steamdeck you basically know it'll also run on a very wide range of hardware configs.
So while the game might be targeting a different API than the standard ones exposed on Linux machines, a lot of games now are directly designing their software to make sure they run well on a Linux handheld. Meanwhile, Linux is adopting more and more features to better support this non-standard API set.
At a certain point I think we can just call Proton/WINE a 'native' API for gaming on Linux, and say that games developed with Proton/WINE in mind are native games.
Perhaps we're not at that point yet, but we might be there soon.
I have a couple more things to figure, I need XBox authentication to work for Halo Infinite and Sea of Theives, among others, and I need to figure out some solutions for some ancient software I have to run, which will probably end up being a Windows 11 VM. But as for my daily driver OS, I am so excited to get off Windows once and for all.
I would say custom modding and online multiplayer anti-cheat systems are the last real hold outs, and even then it doesn't affect every game.
My point is, you may find the one or two games holding you back won't be missed much.
For the OSes runtime side you can depend on SteamOS / Apple's Game Porting Toolkit / Crossover / Proton / DWProton / Wine / and Android's Winlator/Gamehub/Gamenative .
For DirectX compatibility you can depends on Apple's D3DMetal , DXMT , VKD3D , DXVK and WineD3D .
I've likewise got a lifetime of experience on the Windows / MS stack, decades of custom tooling I've adapted or coded from scratch, etc. It's frustrating to see so many great advancements to core fundamentals like the kernel, tracing tools, I/O performance, etc. get completely overshadowed by such chronically user-hostile and frankly stupid business decisions.
I wish I could have the good bits without all the nasty cruft. I wish they stopped assigning junior devs who haven't even heard of Win32 to work on UI touched by millions of end users. I wish they hired back QA staff and rediscovered proper quality control methodologies like, say, regression testing. I remember a story from back in the day when they bought up one of every software title from the local tech store and had staff each pick one to dogfood on their prerelease OS. That passion to ensuring a good user experience.
I don't look forward to the time it will take to recreate all my infrastructure in Linux (including no doubt several detours tinkering into source codes to fix little issues and upstream little enhancements). But I fear Microsoft as a whole will never get their heads screwed on straight in time for me to avoid having to do so.
I would pay good money for something like ReactOS, Wine, or whatever, to offer the equivalent for business applications as Proton is for games. I applaud all the hard work done by people on those projects. I expect one day when kids have never heard of the word Microsoft, the code those heros wrote will still be in use by some grateful beneficiaries.
Anyway, that's the end of my rant. And in the meantime, just in case you haven't tried it yet... Windows 11 IoT Enterprise LTSC is the least offensive flavor I've found, and works as a daily driver.
1. An equivalent of kernel level anti-cheats. Cheating really sucks. It ruins online games. Kernel level anti-cheats aren't perfect, but they're much better than user-space or server-side anti-cheats. Maybe in the future AI solves this, but inherence-based anti-cheats are likely going to be a cat-and-mouse game. Valve have stated they are working on this problem and I think if anyone is going to solve it, it's them.
2. Immutability. Right now distributing games on Linux isn't distributing games "on Linux." It's distributing games to 12 different distros with a hundreds different configurations and a thousand customisations. This is impossible to support. When SteamOS gains traction, developers will be able to target exactly one distro with fixed configurations and limited customisations. Valve will set the standard for other distros.
3. An enforced equivalent of .exe. One of the most wonderful parts of Windows is the near universal acceptance and use of the executable installation method. You just double click the file and install it. Linux is an absolute clusterfuck of installation manuals and scripts and competing app stores with their own repos and permissions and packaging methods. If Valve were to mandate the use of, for example, flatpaks in SteamOS, that will become the universal standard. I think this is one of the most frustrating parts of using Linux for regular people.
4. Better hardware support. My Fanatec peripherals don't work well in Linux. Fanatec doesn't offer drivers and open source options are limited in functionality (and stability). There are many products for which drivers support sucks in Linux. I think AI will solve many of these issues over the next few years. Unless the manufacturer has gone out of their way to encrypt of obfuscate the communication layer with the product, you can basically point Codex at the peripheral and tell it to build an interface driver. Within a few years, I imagine operating systems will have this kind of functionality built in. If the OS encounters a peripheral it doesn't recognise, it will just build its own driver on the fly.
I am more optimistic about all of these than ever before. Linus Torvalds famously said it will take Valve to fix this fragmentation problem for us, and that looks like where we are heading. No doubt there will be Linux fans who lament the loss of diversity and competition, but I think we end up with a true competition to Windows for gaming. That's when I will make the jump.
Steam has already solved that problem. You target steam (not steamOS) and all other distros will do the work for you.
Ultimately, you can’t trust the user computer unless you go for the secure boot things backed by a hardware key. I’m sure there are multiple ways to bypass anti-cheats on Windows.
> 2. Immutability[…] It's distributing games to 12 different distros with a hundreds different configurations and a thousand customisations
Does it really matter? You can always ship a statically compiled games. There’s only one kernel that is greatly back compatible.
> 3. An enforced equivalent of .exe.
I think ELF is the official standard for executable binary. The competition is illusory. There’s nothing preventing anyone from distributing a self extracting archive that installs on /opt. Packaging on Linux is about your system consistency, not software availability.
> 4. Better hardware support
That’s not a linux issue. If the manufacturer is not keen on getting it in the kernel or making it open source, they can always create a binary blob and distribute some shim that loads it.
I think that games have been a strategic priority for Windows for a very long time. Going all the way back to DOS/4GW on Windows 95. But the impression I get from Microsoft is that they kind of don't want the hassle of maintaining a desktop OS anymore, and they would be happier if everyone went elsewhere.
On top of this, gaming used to be (and probably still is) the main reason to cycle through PCs. If you're just going to browse the web, use relatively low resource software, etc then a PC or even laptop from a decade+ ago is 100% fine. The reason consumers upgrade is going to be heavily weighted by games. And each of those upgrades often comes with new OEM software that was licensed and other economic benefits to Microsoft.
---
As for modern Microsoft, I agree with you from an outsider's perspective, but I'd bet internally it's a different game. Microsoft seems to be having major issues with labor competency, on both the implementation and management side, and it's making their entire ecosystem collapse. Anything that has major outward visibility (like desktop OS) is going to make the circus most immediately visible. I have little doubt they have the same stuff going on internally with their other offerings.
I mean Windows is still a huge cash cow for them and is THE desktop OS but the actions they are taking with it sort of makes it feel like a second class citizen.
This is the last major reason for anyone to use Windows nowadays, with the exception of legacy applications.
Windows' days are numbered.
Linux still is not a great daily driver for video games in many circumstances, unless you're on a specialized device like the steam deck that gets extra attention to smooth out the rough bits.
On my gaming PC I haven't found a single game that runs noticeably faster in Linux. Most run considerably worse often while suffering various glitches (sometimes game-breaking).
Sometimes, with work (different versions of proton, startup options, configs, or even new kernels or compositors, etc) you can get around those problems, but... it takes work. Work that you just don't have to do on Windows.
That's an interesting experience, I'd be interested to hear more. There certainly are games that do not work well, no question, but as far as I'm aware it's a pretty small minority. To my knowledge, the two biggest issues are anti-cheat and video codecs, both of which are business/legal problems, not technical issues. Are those the main problems you're seeing? If not, are you possibly running fairly niche games, or on a niche distro or specialized hardware setup?
Linux is still too bloody awful for power users, never mind the median gamer.
Most Linux usage is SteamOS which only barely counts.
It’s a great hedge that keeps Windows almost honest. But we’re a long long long long long <breathe> long long long ways from the median gaming PC being Linux.
I never installed Windows 11 on any of my PCs, there's no place for it in my work or gaming regimen. If Linux is supposed to keep Windows honest, then some dev at Microsoft must have a Pinocchio nose.
We're a long way not because Linux cannot do it. We're a long way because publishers refuse to take it serious.
Like if most linux usage is SteamOS that suggests its good for gamers right?
And that all any other distro has to do, is target SteamOS in terms of gaming usability?
The Nintendo Switch (which runs Linux) was a favorite of cheaters after jailbreaks came out.
When anyone can compile and run their own kernel with god knows what for modifications, that makes it substantially easier for cheaters and substantially harder for anti-cheat. I don't see that ever changing.
You can't rely on server-side detection either, because some of the cheats are so advanced they go to great lengths to "behave" like a highly skilled human player would with their aiming
An AI will play these games like a human but better. The AI can be totally separate from the windows box wearing anti-cheat ankle bracelets just as your brain a separate thing to the windows box when when you play. It can interact with the box via keyboard, mouse or controller.
No windows kernel module is useful in detecting and deterring chess cheating no matter how fanciful or factual the vibrating "device" stories are.
Anti-cheat by kernel module, it's day will be entirely done very soon if it isn't already.
"Any time you beat a computer at a game it let you win." Are we there yet? If not, how long?
If you're saying the Nintendo Switch system software is Linux-based, I don't think that's correct. It's a proprietary system based on a microkernel architecture.
Shouldn't that be the goal of anti cheat? That cheating is indistinguishable from expert gameplay? Seems to me like these companies are just trying to avoid implementing proper infallible server-authoritative gameplay by offloading the cheat detection to the untrustworthy client, and then trying to lock down the client to make it trustworthy.
I feel that the solution is just to have a decent ranking/level system so that users play with other people, cheaters, bots or regular users of the same level. When I was playing mario kart with my 5y old daughter, I didn't mind she had access to helps to not run out of the road as it allowed us to play together. I don't see how different it is between say, a super skilled player, and a lower skilled player with cheat/assists. If cheating/assists system becomes so efficient, cheaters will just end up playing together and non cheater will have got rid of them and play between non cheater of similar level. Prolem solved. No?
The cheating issue isn't really a matter of being able to run custom kernel code. You can do the same thing on Windows, which is why remote attestation is a thing for some games. As someone who has developed games for Linux (and Windows / Mac), it's an endless cat and mouse game. So long as the system can execute code that is not yours, you never really are getting perfect anticheat. Ease of loading custom kernel code isn't really a hurdle to that.
I find that client and server based in combination is the robust approach. I once implemented anti-cheat in which the server lied about game state, which a regular client without cheats would act predictably on. Deviation from that behavior is a useful heuristic to build a suspicion score.
EA did a big announcement about switching to kernel level Anti-Cheat for Battlefield 6 to combat cheating, yet there's still plenty of cheaters around. It's looking more and more like an excuse in order to give the appearance of combating cheating.
People say this a lot about Linux and it somewhat rubs me the wrong way - sure, the Windows binary works if you install its library dependencies (wine). Likewise (OK, ever since libc5/glibc2 changeover in 2001) the Linux binary should work if you have its library dependencies (SDLv1 it looks like?). So what's really the problem? Your distribution stopped distributing the dependencies, making them harder to find? "DLL Hell" was a thing too.
I didn't see any binary downloads for Linux on that website, only source code.
I gave it a try anyway, the dependencies were actually not a problem for me, Debian has libsdl-{net,image}1.2-dev, libglew-dev, and so on, and if your distro does not have SDLv1 there is libsdl1.2-compat. But after the dependencies, there was a problem with the source code doing something involving bitfield packing that does not compile on x86_64.
I do see the source code has lived on, i can `apt install d2x-rebirth` on Debian 13 which has a comment about https://www.dxx-rebirth.com/ ...is that helpful?
Yes but all it takes is an `apt-get install wine` or `zypper install wine` or `pacman -S wine` or your distro equivalent and if you are using a Linux distro with any sort of desktop functionality, 99% of the time wine will be there.
> Your distribution stopped distributing the dependencies, making them harder to find?
Yes, this is a big problem because these dependencies not only are harder to find but even if you track all of them (there is a chance they too have their own dependencies) you still need to figure out how to build and install them. And if they are old enough for distros to drop them, then chances are building them isn't going to be a straightforward `./configure && make && make install` ("straightforward" is very relative here :-P). And woe is you if there are conflicts with newer (yet API/ABI incompatible) versions of these libraries and/or their dependencies.
Of course since you have the source, technically you can make things work, but that doesn't make the process any less of a major PITA.
The real problem here is the tooling. New versions of automake and C++ compilers are stricter than they used to be.
Indeed, for long term conservation, you need to vendor your dependencies AND your tools to make sure that the project is sustainable without intervention. But with the magic of LLMs now, this is not a problem anymore. Claude was able to fix it in less than 10 minutes.
And having the source code beats playing the original game. You can recompile in high def and make all the modifications you want to make it feel like a modern game (or not!) and sill get you your dose of nostalgia.
(2019, from https://news.ycombinator.com/item?id=21776370)
Just do it. Swap and let go of objectivity. Let your subjective experience guide you.
For me, the subjective joy of not having to fuck around with Microsoft's bullshit was worth multiples of having to mess around with technical crap to get a game working (spoiler: I nearly never have to do that because I play single player games, Dota and CS). I couldn't give less of a damn if my FPS in some random title is 10% slower than it would be in Windows. So long as it's playable, I benefit in spades from the trade-off.
I think most of the people who really care about game performance aren't people playing games like you do. They are either playing AAA games where the graphics quality is paramount, or competitive games where performance is useful for being competitive.
If Linux was measurably 5% slower on all benchmarks, would that mean you wouldn't do it even if you wanted to? Is every single nanosecond of performance really that important to you? I switched 10 years ago when things were a lot rougher than this, and in the end everything still worked well enough that I never cared to swap back.
But the issue is that it is many multiples of that, especially on the most common PC gaming hardware (Nvidia GPUs), often more than a 25% difference in framerates. Not so important at 144fps, but very important at a 60fps baseline and for genres like fighting games.
A lot of people don't mind, say, an extra 5 frames of input delay. They don't notice it. But a lot of people do notice even an extra 2 or 3.
I do think that frame pacing issues kinda do have a critical thin threshold where it's either bearable or an unacceptable difference. And the native windows version can often already be riding right on that line. So while it's not fair to the Linux version to demand better, it is unfortunately the case that it might tip over that line.
I kept running into issues that took me time to solve. I understand that the only reason it took me time to solve these issues is because I'm new to it and that people who have been gaming on Linux for years already know how to solve them all. But what would happen was is I would sit down to play a game spend maybe an hour or two fixing issues and then after that I ran out of time to play the game. I kept this up for a couple months but honestly at some point I just gave up. Now I'm playing games on Windows again.
To be clear, I'm a huge proponent of Linux gaming. I just unfortunately am too busy these days to spend the time to get it to work.
Some of my favorite games that I play don't work on it, though, so I need to keep my PC. My issues are not performance, but inability to play at all.
For me personally, the biggest game that keeps me from only using Linux for gaming is EA FC (used to be called FIFA, it is the soccer game). It requires Windows to play online. The same for PUBG, which is another game I play with friends.
As long as I can't play those games, I have to keep my windows gaming PC.
I personally don't mind that much, honestly. It would be nice to play on Linux for everything, but I can dual boot when I am not gaming if I want to.
Absolutely not. It works, it doesn't "just work". Tuning is absolutely required for a lot of games to get them working. Random crashes, "oh multiplayer doesn't work? singleplayer does?", random glitches, random performance issues, etc.
I still prefer dealing with some issues over dealing with Windows, but it doesn't "just work".
> These old workarounds got subtle edge cases wrong in ways that produced occasional hitches, deadlocks, or weird behavior in specific games, which are bugs that don't show up on benchmark charts but can absolutely ruin individual experiences. NTSYNC fixes those at the source by matching Windows behavior exactly, and that means as soon as your favorite distro moves to the new kernel version, whether it be Bazzite, CachyOS, Fedora, or a flavor of Ubuntu, they all get this much-needed fix.
That's the crux of the article. NTSYNC isn't faster, it's more "correct". Most games are around the same level of performance, with certain outliers both ways. Right now there isn't anything performance wise that Linux has to do that would impact all games. Just tweaks and additions to the different layers [1][2][3] in the same way driver vendors do. Much of the poor performance is for API violations and other shenanigans.
1: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/uti...
2: https://github.com/doitsujin/dxvk/blob/master/src/util/confi...
3: https://github.com/HansKristian-Work/vkd3d-proton/blob/maste...
It depends on what you're using now, though. If you're just using a vanilla wine/proton install, then NTSYNC should indeed be a lot faster as well. If you're using fsync or... I forget the name of the other one... then you many not see much in the way of perf improvements.
If you have a beefy CPU and plentiful RAM, then typically one should expect Linux to be slightly behind Windows performance (though there are exceptions), because then Windows' bloat becomes a non-issue, and the impact of the translation layers start to become more significant.
This was true 4 years ago, but is outdated knowledge now. Nvidia used to disallow distributing drivers with distro images, but they have since made agreements with some popular distros. If the distro image you download includes drivers or you know how to install them, the proprietary drivers work really well.
Gamer's Nexus has a pretty extensive benchmark video: https://youtu.be/ovOx4_8ajZ8?si=Cx5Q1a-lMMm14H4i . They refuse to compare to Windows, and it kinda makes sense: if it's satisfactory on Linux for your demands then who cares what Windows can do?
Here's a less professional, but direct comparison https://youtu.be/Giois6VtLPM?si=XFaVUMbea3u0AmP. An extremely important thing to note: AMD GPU. I personally have no idea what NVIDIA is like, but it sounds like their drivers are still all over the place.
And kernel-level anti-cheat doesn't work, though some (e.g. EAC) run in user mode if the developer allows it. Make sure to check ProtonDB for the games you care about. I have personally never had a good experience with Linux builds of games, so I just always use Proton now - but maybe I'm cursed because others have passionately disagreed with my experience. Either way, if a Linux game is broken/bad, try forcing it into Proton.
I don't want to say, "switch now" because it still has rough edges in terms of gaming. Better for you to have a great experience and stick around, than hate it and leave for good. Only you can figure out if it needs more time to cook based on some very light (ProtonDB) research.
I last used a Windows machine about a year ago, and I can say with confidence that the average desktop experience is significantly superior to the barrage of bullshit that Windows puts you through.
Pretty much everyone? If bread and water is satisfactory for your demands then who cares about Beef Wellington?
If it was better than Windows they sure as hell would be comparing.
Anecdotally, I find that getting Linux on somewhat older or underpowered hardware is always a massive positive. Better performance as well as battery life. I'm not as familiar with modern hardware's relationship to either OS ("OS vs. some flavor of OS based on a similar or same kernel" - I know) with modern hardware. Worth a shot though!
Every supercomputer seems to do quite well with Linux kernels. Probably good enough for Crysis :)
I never would’ve been able to root cause it under windows (certainly not with builtin tools), but dmidecode on linux made the problem obvious.
Fixing the timings fixed crashes in amdgpu that windows users widely reported (with no diagnosis), and increased frame rates by 30-50%.
Anyway, if you really want to move, do yourself a favor and just go with straight AMD.
Software support is better than intel and nvidia, HW blows intel out of the water. The only exception is if you need cuda for AI dev work.
It's an easy weekend side project, and any numbers people give you will be ballparks anyway - the performance of Linux drivers for YOUR specific GPU running YOUR specific Steam games are all that actually matter.
Just take the two hours to do it. You won't regret it.
Got it running in less than an hour.
I ask because I feel like I can frequently play games at, say, 150fps, and losing 30% would mean almost nothing to me to switch to Linux. I worry more about general capatibility and anticheat.
Until we get something like CoD titles being Steam Console first, linux is allways going to lag behind.
That being said, I think we are on a precipice of AI being able to simply just rewrite games from concepts. Start with generic source code for an FPS or 3PS, then people can contribute changes in english language to tailor the game. So it won't be even copying source code, it would be copying concepts and then making a new game with it. There have been a lot of games that have very rudimentary graphics that people played in large numbers because the complexity and gameplay was quite good.
Anyone actually looking to make something genuinely fun will probably go the old fashioned way of spending countless hours honing their craft, which in turn gives them a good eye to make sure what they're making doesn't have the shovelware stink.
[1] https://www.notebookcheck.net/Sony-delists-700-PS4-and-PS5-s...
[2] https://www.gamesindustry.biz/shovelware-is-a-bigger-problem...
The title after the jump is "Linux gaming is getting faster because Windows APIs are becoming Linux kernel features"
Getting faster. Not at parity yet.
In my experience, CS2 plays better at 150ms ping than 19ms ping. It's not even K/D ratio bias as the far away server has better players than the matches.
19ms and everyone else is just janky-warping around. 150ms and maybe there is a rollback where yeah that whole thing 5s ago didn't happen but otherwise it is very smooth.
In the case of my machine, I haven't observed any difference. And by observe I mean with my eyes, I haven't bothered with actual benchmarks because it seems to work about the same, which is good enough for me. I haven't booted my Windows partition in months, and I'm probably just going to blow it away next time I need storage space.
Getting reliable, consistent, meaningful performance numbers is in fact, extremely complicated:
* You need a consistent way to reproduce the exact same outputs - accounting for things like the game's RNG. You can't just walk around and snap the FPS counter in the corner of the screen and call that good.
* For Windows (and occasionally Linux) you need to ensure nothing is running that will taint the results (updates, AV scans, etc)
* Sometimes individual driver versions work very poorly with a specific game. Just because it ran badly doesn't mean you got good data, it may just be a bug in that specific driver version
* You can't just run the benchmark once. You need to run it many times, establishing run-to-run variance
* There are often a good dozen-to-hundred individual OS settings which can impact performance, and in some cases run-to-run variance. You need to know which to tweak, and which to leave alone.
* Sometimes the result of individual in-game settings differs between driver versions. Just because setting X had a big impact once, doesn't mean it always did
* FPS is not a great metric - it's an average. You need to check and see if there are huge frametime spikes. If there are, the game will have a 'good' FPS but feel horrible to play due to stuttering.
* You need to decide if you're benchmarking more GPU-heavy or CPU-heavy - those types of benchmarks require drastically different settings. If you run a CPU-like benchmark you may see a wildly different gap in framerate compared to a GPU-heavy one for the same game.
Benchmarking properly means accounting for thousands of tiny variables. Only a handful actually do it right.
If you need every last bit of FPS maybe it is lagging, but 5-30% slower is roughly on par at a large sense, it's less than the difference of e.g. one NVidia GPU generation to the next, so it makes it playable.
That's why all the data matters for all of these dimensions; game performance is much more than FPS per watt over time.
When people see "linux gaming is great now, look at the fps" it comes across as potentially disengenuous because of all the other factors that matter and should be tested. Or rather, if a reviewer is talking entirely about framerate, then I just can't trust their opinion and expertise when it comes to the state of Linux gaming.
No.
> I WANT to swap. Please give me cause to do so.
If you won't put the work in, why should we help you? Just stay on Windows, and we'll enjoy our Linux gaming rigs.
There's certainly room for improvement on the netcode sometimes (Client-side hit registration is an absolute bone-headed design), but those won't prevent aim bots.
Server-side anti-cheat relies on heuristics and can easily be evaded. At the high level, a highly-skilled player may be indistinguishable from a cheater, so you could easily get false positives.
If the vendors said: Disable anticheat and we’ll block you from tournaments / matchmaking, I’d consider that a feature, not a bug.
If some IRL friend of mine wants to be an asshole and use auto aimers / see through walls to screw with me, then I have ways to deal with it outside the game.
On the other hand, if we both want to run some bullet hell mode + cheats with physics mods and a debugger attached, then what’s the problem?
It’s none of the game developer’s business.
I’m not sure if I am in the minority or majority, but I’m not the only one with this attitude. I suspect the set of people in this boat dwarfs the 5% market share Linux currently has.
They might even get some of us to buy their games if they added support for such a mode. How hard could it be?
The other 'state of the art' which is much cheaper, easier, and essentially impossible to detect on a hardware/equipment level, are the AI-based systems that examine the video and generate inputs via USB, emulating controllers or keyboards and mice. It's a huge problem on console right now and can only be detected via server-side analysis.
This broke what was otherwise a perfectly normal Battlefield experience. Battlefield 4 requires Punkbuster, although it can run on Linux with no issues. You have to downgrade to an older version though, since EA hasn't updated BF4 to the latest PB AC, which causes you to get kicked.
This is not really my area, but from a quick web search, I think they mean io_uring. Here's a blog post about it: https://mazzo.li/posts/uring-multiplex.html
[1] https://news.ycombinator.com/item?id=47513667 [2] https://lore.kernel.org/lkml/f4cc1a38-1441-62f8-47e4-0c67f5a...
What do you mean? SRWLock (or the older CRITICAL_SECTION) cannot be shared between processes. A (Win32) Mutex does work across processes, but that's its entire purpose. So Windows does have different tools for different jobs.
In fact, it's really the other way round: on Linux, a futex also works across processes, but there is no equivalent in Windows. (Sadly, WaitOnAddress can only be used in a single process.)
That seems hugely useful for interprocess communication and I can immediately think of reasons to use IPC in a game. Having a separate voice process for one.
I don't know what they could do spanner tossing wise to really screw w/ Linux gaming at this point that wouldn't just drive more frustrated customers off their platform.
They made a tactical mistake by trying to directly monetize the GamePass subscription instead of having it remain a purposefully-underpriced vendor lock-in mechanism. Whoops.
Me and all my dad friends are all signing up for XBox accounts so our kids can play Minecraft. So IDK about that.
I reckon a successful launch of the Steam box (or whatever they're calling it) with its enormous library could develop into something that really challenges what's left of Microsoft's piece of the console market (and threaten Sony a little, for that matter) though it's looking like the memory shortage is gonna kneecap that by forcing the price too high. Bad timing.
WinRT (not to be confused with Windows RT, the early ARM version of windows), UWP, GDK, xgameruntime. All of these are relatively new and require virtualization and other security features.
Put pressure on devs by gateing xbox and gamepass behind this runtime and now you have a lever to make the situation more difficult for linux.
Kinda has the opposite effect on me however, as the only reason I'm not subscribed to gamepass right now is the games wont work on my steamdeck. But if MS can get enough killer apps as exclusive to that platform then that will certainly add some pressure.
https://www.gamingonlinux.com/2026/05/further-expanded-amd-h...
That is, more people being subtly pushed to using display port is not a bad thing.
Heroic because the amdgpu driver is strangely huge, more code than the rest of the obsd kernel combined, It has something to do with gpu's having no isa stability and the generated code for each card present in the driver.
AMD is much better. Nvidia has been improving but stuff "just works" with AMD because the kernel (amdgpu) and userspace (RADV) drivers are open source. Valve is a major RADV contributor too.
I don't feel like I'm missing out on anything with my 9070 XT. Performance is great.
I particularly got fed up with Nvidia on linux playing War Thunder - I had a regular crash that Gaijin and Nvidia each blamed on each other, and I never did get it fixed.
Nvidia driver updates can also leave you stuck with no desktop environment on occasion and while fixable, it's a pain in the rear. However, when the drivers are right, Nvidia performance is second to none.
AMD has drivers built right into the kernel, and as long as you have whichever nonfree firmware repos your distro supports (I use Devuan, a Debian derivative), AMD cards 'just work'. If using xorg, install xserver-xorg-video-amdgpu for modern cards, and xserver-xorg-video-radeon for older cards. I'm currently playing on a Radeon 9070 (non-XT) on a 1440p monitor with plenty of performance. I know that it also works on wayland, but I have no experience there.
NVIDIA has apparently open-sourced the kernel drivers for their most recent couple generations of graphics cards. That's great! But they have a hell of a lot of catching up to do. Their kernel drivers aren't in the mainline Linux kernel. Their userspace drivers are proprietary, whereas AMD's are open-source. AMD's kernel drivers are built into Linux and their userspace drivers are built into Mesa.
That history of greater compatibility matters in its own right: all of the developers of Linux desktop environments, window managers, and compositors have been running AMD or Intel GPUs almost exclusively for many years.
If "voting with your wallet" means anything to you, or you want things to "just work", AMD is the clear choice and it's not even close.
If you already have NVIDIA hardware, by all means, go ahead. It's doable. But AMD is a way more rational choice on Linux for most users.
Whereas the AMD-based Steam Deck always does what it should do.
Still, if you don't absolutely need CUDA, then AMD provides better value anyway.
Its an old card so I have no idea why I'm still struggling to get it to work. Is it perhaps because I'm using Xfce? I heard that Nvidia cards play better with Wayland although I haven't tested this myself.
But their happy path hasn't included proper wayland support for a long time.
Nvidia on laptops? Insert the famous Linus Torvalds meme here
I used a recent nvidia blackwell GPU with linux, periodic crashes. Blackwell generation is shit.
Used recent builtin AMD GPU... Even worse, super reproduceable X crashes when using firefox
I don't know whether your GPU is older than mine or not but I have the RX 7700XTX. Maybe it had a software defect...
https://web.archive.org/web/20110708212436/http://www.ctosfa...
In other words, no one is going to refuse to use Linux out of loyalty to Windows, as long as all the games they want to play work.
In fact, I went with console + linux laptop for ages simply because that combo excelled at their respective roles, were cheaper together than a gaming pc, and it 'just worked'.
I did eventually cave and build another gaming pc, but that was after I acknowledged that I could push out on the price / perf curve to something less 'optimal' (and it let me play with local LLMs)
But this excludes the entire console population. This arguably excludes most Steam Deck customers, who picked it because Valve made the Linux experience seamless, so they don't have to pay attention to the details. This excludes many of the PC gamers I know, that do not care beyond whether their computer is capable of playing the games they want to. They won't even reformat their Windows to remove OEM bloat.
You don't tend to hear them online of course. They are the silent majority keeping the AAA industry alive.
I have no idea why this is not turned on by default.
You're implying that Gamers Nexus is some form of Linux outlet/content creator. They aren't, they only started doing Linux content this year/late last year (and only plan to do it rarely).
You've taking a surprisingly hostile stance on the one (at the time of writing) pro-Linux comment that suggests that it might not be ready for everyone, and to wait if it's not a good fit.
And it isn't beef wellington vs bread and water. It's 80% lean beef vs 82% lean beef, in the majority of cases (and in either direction). And "suitable for your purposes" also means that 160FPS is really fine if your screen is 144Hz - doesn't matter if Windows does 180FPS (unless you're doing something competitive or extremely latency sensitive).
I think Microsoft can do fine without people tilting at windmills for them.
To give a particular example, I started playing GTAV on Windows after building a new PC since I had no spare drives. After finally installing Linux I decided to try GTAV on Linux just to see how well it would run. And it runs amazingly well, and yes, it runs a few percent points slower than Windows, but the only tradeoff I did was slightly increase FSR4 and the game still looks amazing. I didn't really notice any graphics issues, especially not during actual gameplay (if I stayed at the same place and started to nitpick I could notice differences).
Huh.
I wonder if they're the same people who complain that they don't have enough money to live.
I don't think you'd need to block multi tasking though, but the kernel would need to prevent or tamper root access so it couldn't modify the game memory.
So if you force it to run on your Linux desktop you don't get an experience commensurate with your hardware.
[0] I still use Arch, btw. :)
Heroic is a launcher aggregate/wrapper I think? for 'Epic, GOG and Amazon Prime Games' It's either Steam, native/standalone or arr for me. for non-steam stuff I use umu.
* I should add that I am launching a steam purchased copy of SoT, not the one from Xbox store/gamepass or what have you, so the process is likely different, but maybe not cus you are likely going to see the same auth popup served via wine/proton.
It didn't use to be complicated, but an update messed stuff up a few months ago (halo infinite).
Fortunately I haven't noticed performance impacts so I'm on the hype train.
>nothing is running that will taint the results
No, running background crap IS the result, because that's real world conditions, and not some artificial lab condition.
>You need to know which to tweak, and which to leave alone.
That one is easy. You leave all of them alone. Windows tweakers do more harm than good. Besides, replicating benchmark results is impossible after you do brain surgery on the OS.
>You need to decide if you're benchmarking more GPU-heavy or CPU-heavy[...]
You benchmark the games you play. Benchmarking anything else would be completely pointless.
>Only a handful actually do it right.
Rumors say that Hattori Hanzo used to work for AnandTech. I wonder what he's up to these days.
Benchmarking is uncomplicated in the sense that you can press a button and watch the pretty things on-screen and get it to spit out a number; but is your room a little hotter than usual today? Was something downloading in the background? Did you have a transient network issue that caused some process to stall and eat some CPU time? Is one of your fans running a little slower than usual? Did you wait for the precomputed shaders to fully compile? What about the ones Steam supplies?
It's not about fun, it's tedious work. But without proper controls in place, data is just noise.
Your quoted quote.
And, assuming your are doing x86, you probably already have an EFI partition so even doing motherboard bios updates isn't much of a big deal. You just drop the update in the FAT32 EFI partition, reboot, and point the motherboard at that location. Some motherboards even support just doing that as part of an online update.
That said some Linux distros can do the same now though I've used so many the last few months I don't know which.
It's the same tool the person you were replying to was pointing at via the Arch wiki. It's pretty standard. I'd expect most distros to support it by now.
Windows power users expect their habits and instincts to be right and treat the system as broken wherever they aren't. After all, they "know computers"! So when one of them hits a snag, even if it would have been avoided by heeding a system's warnings, reading the documentation, or adhering to its norms, they declare (for others to repeat) things like "Linux isn't (ready) for power users".
--
1: Windows power users arrive to Linux with a mixture of incredible fatigue from pop-ups and blindness to all interruptions. They are used to mindlessly batting away constant notifications and distractions. They are also used to a host of familiar warnings that they know are bullshit, and reflexively ignore. But the warnings on Linux systems are not the warnings they know. They don't actually know what they mean or which are safe. To the point that their blindness to warnings becomes outright comical, as in this infamous example: https://i.imgur.com/J39WfLK.png
All the operating systems are very different but also largely the same. There are a ton of dumb little things you need to learn for each of them. It’s annoying. Most people don’t spend the time and just go back to what they and works.
I don’t think your comment is particularly insightful or interesting. It’s bias way yonder too overwhelming.
Instead of running the game in some arbitrary computer, you'd require players to buy your dedicated hardware, a black box that runs the game and nothing else.
To give you an idea of how bad it is, they slowed console manufacturing to a trickle last year to try and juice their profit margins, and are now stuck in a situation where they can't spin manufacturing back up to cash in on the inevitable rush of demand for hardware when Grand Theft Auto comes out this fall.
Part of the problem seems to be that desktop OS use as a whole is cratering as more and more folks who grew up in the smartphone era enter adulthood. Outside of tech circles, I meet a lot of folks who have a phone + tablet but no actual computer...
I personally hope they never do, because present day anticheat systems are literally closed-source rootkits. You should not let that software onto any computer you own.
But then I don't really have a horse in the race, because I don't find competitive gaming with strangers enjoyable at all.
With what stable module ABI like Windows has? There isn't one.
You can build a module that targets the current kernel Ubuntu 24.04 is using, but that module won't load on 26.04, let alone a completely different distro like Fedora.
eBPF /might/ help, but one could make a module that lies to eBPF.
FiveM, modded servers for GTAV, had anticheats before Rockstar added any which already prevented Linux players. Face IT for CS2 does the same.
I select games based on ProtonDB. There’s always constraints and I’m cool with the limitations that this brings. BF6 is a no-go due to its anticheat tool, no problem. Got lots of other choices.
Happy to not give EA any money if they're so set on shoving online play and therefore anticheat down the players throats.
Grateful that Steam allows easy refunds.
What other goal is there than maximizing your subjective enjoyment of the game?
Sure if you're a professional streamer, your feels are maybe less important than engagement metrics but if you're just a casual?
Dude just play what feels good. It's literally the best and only metric.
- Borderlands 4 was basically unplayable on my hardware (9800 X3D, 3080 TI) - though I didn't care enough to try and fix it.
- Dune Awakening was decent, but noticeably less performant, stuttery, etc. Probably fixable with some settings tweaks and other stuff, but the experience was markedly worse than windows out of the box.
- ARC Raiders runs fantastic - but even still, it had noticeable visual issues particularly with shadows
General issues:
- It seems to vary by desktop environment how confused steam and/or the games were as to which monitor to play the game on
- Steam itself required some futzing to get big picture to use hardware rendering (software rendering is very laggy)
- Multiple games seemed confused what my native resolution was
- Mouse issues with multi-monitor setup in several games (though sometimes this is an issue in windows too)
Games make a lot of assumptions based on how Windows's one-and-only window manager operates, stuff like windowing message and focus event sequences, effects of various windowing states on window sizes and chrome and mouse cursor behavior, and so on. Linux WMs don't match Windows's behavior or even other WM behaviors, so it's a nightmare trying to get every WM to align to how every game expects Windows's WM to behave. Then multi-monitor adds another layer on top of that, for things like reporting resolutions, cursor behavior, window focus, etc.
We focused on the big 2 (Gnome & KDE) on X11, and personally I use multi-monitor XFCE on X11 so I was quite motivated to get games working well there, too. Plus SteamOS's compositor/manager on Wayland, obviously. But there's so many combinations affected by so many things (I didn't even mention graphics driver behaviors on any of the above...) it's just really hard to get right as you add more little edge cases. And as you said, many games get it wrong on Windows, too. We'd often reproduce bugs on Windows just as they were reported against Proton.
All that is to say, yeah, I believe that has been your experience now that you've explained a bit more :)
Once upon a time I was a paying customer (like in the early early aughts). Glad to see them still doing their thing.
Trials in Destiny 2 were a struggle before BattlEye, and the day BattlEye was enabled everyone suddenly forgot how to click heads. I put it "good enough" category.
There's more to it than dependencies. It's a valid point.
> I think ELF is the official standard for executable binary. The competition is illusory. There’s nothing preventing anyone from distributing a self extracting archive that installs on /opt. Packaging on Linux is about your system consistency, not software availability.
I think he meant .MSI and not .exe, but the point remains and is still valid. Why are there multiple ways to skin the same cat?
However, the real issue I'm getting at is the ability to run the same statically compiled binary many years later. That requires a dedication to compatibility (in this case, protocol compatibility). X11 was a bit all over the place on this, though it is probably stable enough now by dint of not getting much attention anymore. It seems like Wayland takes protocol compatibility pretty seriously [1] but there's an important caveat:
[W]hen a protocol transitions from unstable to stable, one last breaking change is permitted.
[ ... ]
Note that many useful protocols are still unstable at the time of writing.
[1]: https://wayland-book.com/protocol-design/design-patterns.htm...
Of course, you can use DMA over Thunderbolt, but the bar is so high (cost, specialised hardware) that most people who cheat won't do it.
> Does it really matter? You can always ship a statically compiled games
This isn't completely viable, you can't statically link the graphics driver.
Part of the issue is that a large part of linux gamers are saying "linux gaming is great" and meaning "linux gaming is good enough now that it is better than putting up with microsoft and windows 11"
Some people would rather put up with slightly worse frame pacing if it means no microsoft. Some linux folks are super gung-ho pro privacy, some are just super anti-microsoft but can't game on mac. There's a whole lot of reasons to wind up on linux, so the importance of specific performance details may vary depending on WHY you would be swapping.
And some people are playing games on good enough hardware that there arent noticeable frame pacing issues, so good raw FPS numbers just reinforce their views, and they just genuinely mean they are having a good experience themselves.
The user will say 'it lags' but does not mention if they have tearing enabled in wayland, what are their 1% lows, have they set an fps cap, what vsync settings have they chosen in-game. On top of that there is an ecosystem failure as not every game supports arbitrary caps and you have to configure some mangohud thing.
Linux is only a 'just click play' experience if you have no standards because I have never had this stuff be correct out of the box on a fresh install.
I'm not saying you're wrong, but the standard you've outlined excludes Windows too.
What benchmarks are you talking about? CPU-wise the A15 Bionic just barely beats the Ryzen 3700X in single-core and gets absolutely destroyed in multi-core (Geekbench). As for the GPU, the Radeon RX 7600 (closest thing I can find to a "modern console") does >10x the TFLOPS in FP32.
The only reason why they look like they're "in a similar tier" in ported games is because the A15 Bionic is usually tested on 5-6" screens that can be upscaled from 360p without any measurable loss in visual quality, with a massive downgrade in model and texture quality for the same reason. The only modern console the Apple TV "may be" similar to is the Switch 1
Simply no, thank you.
It doesn't seem like a market they have any interest in. The real money is in mobile slop games with micro transactions.
[citation needed]
- Quickplay
- Server / Game / Match finder
- LFG - for a more detailed search
Each of these has a different use case, and a single user may make use of all of them (I include myself here). Not everyone wants to just click "play", it's very dependent on the type of game.
Helldivers 2, for example, implements the first two. Destiny/Destiny 2 has mostly the first one. Destiny on Xbox has a XBL-provided LFG functionality (but prior to that external sites were used). You really needed LFG for finding a raid group.
https://www.nxp.com/docs/en/reference-manual/M68000PRM.pdf see page 292, also see page 629 for the table of "exception vectors" (addresses for code to handle each specific trap/exception/interrupt)
Most processors support both "interrupts" (an external peripheral is banging on the CPU's interrupt pins... but also invocable from software; software interrupts; SWIs; INT instruction on x86) and "exceptions" (e.g. divide by zero, bus error, illegal instruction). Depending on the processor, accessing the "privileged" mode can be done either by software interrupts, exceptions, or both. An operating system should pick one and stick with it.
Other uses for interrupt/exception/trap vectors include hardware breakpoints: don't try and single-step the CPU, overwrite the code with an illegal instruction and control will flow to the illegal instruction handler where you can see all the registers then execute the real instruction that was meant to be there and return to where you left off. Some CPUs have a formal "BKPT" type instruction for that.
One other use on the 68000 is that any unrecognised instruction that started $Fxxx triggered the F-line handler; all the floating point instructions were in the form $Fxxx, so if you didn't have an FPU, you could put a software emulator for the FPU instructions in the F-line handler and software wouldn't know the difference. Traps/exceptions don't have to be a jump from unprivileged to privileged, they can just be utilitarian.
Practically most will support access via both, but for different reasons. For example, page faults (which the software cannot possibly predict) are going to be exception-mediated, but syscalls (which the software asks for) are triggered via an interrupt.
Later on the 386 Intel added virtual 8086 mode which trapped to the kernel privileged instruction exception also for certain instructions that had to be virtualized, among them INT.
We used a set of INT instructions in well-known low memory addresses that all jumped to the same place. We had an ASM file that you linked with, that had sixteen different address combinations for each.
The common entry point would look back on the stack and calculate from the return address which entry point had been called, and run the appropriate kernel call. We called it the CS:IP hack.
In the context of this post, the DOS INT10 and INTx(I forget) required the caller to load registers with the desired system call number, then perform the trap instruction in their code. Fortunately CTOS didn't need those particular software interrupts, so I could implement them for my purposes.
I don't know OG x86 (cuz, ewww) but on 68k this was generally the way. On my Atari ST a syscall was performed by filling your registers and stack as expected, then executing one of the TRAP opcodes and that would get the CPU To save PC etc & jump to the handler but in supervisor mode, where your syscall could then read state perform accordingly, and then return back to you.
I think x86_64 has just formalized this into a specific SYSCALL instruction?
ARM variants call it SVC (supervisor call).
Same difference.
Some older operating systems just implemented their syscalls as ordinary subroutine jumps, though, and everything ran in supervisor etc. I believe AmigaOS was like this, you just went through a jump table. Which, I think, shaves some cycles but also means compromises in terms of building for memory protection, etc.
Traps typically also result from exceptional conditions (like divide by zero or page fault).
An architecture may or may not provide non-trap paths for less-privileged code to invoke more-privileged subsystems (call gates, "syscall" instructions, etc.).
Traps typically need some way to preserve all userspace-accessible registers (otherwise resuming from a page fault is .. hard). Dedicated syscall instructions may only need to restore a subset of registers.
In some implementations, processors may discover that an instruction must trap after it starts irreversibly changing architecturally-visibile state; in cases like that, the processor needs to leave enough breadcrumbs for the OS to allow either a clean unwind or a resumption of the interrupted instruction. My understanding is that the original 68000 somewhat famously got this wrong.
I'm sure there's a reason why they don't, but I wonder why games don't try implementing honey pots, like rendering a fake player behind a wall and automatically banning if a player's crosshair snaps onto them, etc.
When it comes to most competitive games, you're an outlier.
I'm a gamer, and one thing I've learned in my 10+ years reading HN is that there are very few gamers here, and the gamers that are here are a different breed. Significantly less focus on competitive games, more interest in Factorio, and a strong anti-anti-cheat vibe, not to mention pro-Linux. It has certainly created an echo chamber when it comes to gaming-related topics such as anti-cheat.
I've long since decided that buying the latest top end hardware is just spending a lot of money to be upset by buggy drivers or not being able to get 5000 fps in a benchmark but has no real gains in how fun games are.
So you have very old hardware, can barely play modern AAA games (if ever), and are still happy. Good for you.
But your opinion is relevant to average gamer who enjoys playing games released in current year in the same way that someone drinking instant coffee can advise on coffee beens that it's all just caffeine in the end.
Every time I get something mid range or second hand I feel good about what a good deal I got, and how I'm getting 98% of the features for 40% of the price, and how realistically as soon as you stop pixel peeping screenshots, you won't even notice your settings are on High instead of Ultra. You just take in the story, the sound design, and the actual game.
Your definition of great performance is not mine, but it’s fantastic to watch Linux users continue to hand wave away real issues whilst continually claiming the same or better performance across the board, which is provably false.
> but has no real gains in how fun games are.
It absolutely does for me. Modern displays are absolutely dogshit. I won’t play at anything less than 144hz, as much as I can I aim for 200hz and I want that with consistent frame times.
The game story, gameplay elements, and such have become secondary to the real hobby of consumerism. If people could have fun gaming 20 years ago, there is no reason it isn't possible to have just as much fun gaming on low to mid range hardware today.
what is the source of this non-determinism?
I'm saying that extra overhead from making your lock work across processes should be very tiny. That overhead shouldn't add much more than a microsecond in either latency or CPU usage, compared to an in-process lock.
Didn't help connecting it to my Macbook, but still..
None of them ever seem to have DisplayPort.
I have an RTX 5070 (whatever the laptop variant is) and it absolutely rocks with almost everything I throw at it, running Ubuntu+Steam+Proton. I no longer worry whether a Windows game is going to run, because almost all of them do with good performance.
Or does your laptop have no other igpu?
My last Nvidia laptop was a Hybrid optimus laptop. I almost always ran it on the built in Intel igpu because of the really bad issues with the Nvidia cards. Video tearing, bad power management etc... I remember even switching the GPU wasn't easy... And performance wasn't as good either ..
Any modern distro running NVidia or AMD should be fine. I've done both. I didn't have to do anything for the NVIDIA 3000 or NVIDIA 4000 series cards but select the nvidia driver. AMD otoh is built into kernel now.
Comparatively the leading alternative was a dumpster fire of a broken mess for the longest time on Linux. All through the 2000s, ATi provided a binary blob driver known as fglrx which some people joked was a half-baked codebase from somemthing that started on HP-UX, passable enough for running sales demos and then was thrown at an intern to port it to Linux. If you went with ATi and tried to do much with foss opengl programs, you could expect daily or weekly kernel panics and performance that was <50% of that of the windows driver for an identical build. The solution was always to buy nvidia if you wanted stability.
Nothing has really changed for Nvidia on Linux, it still continues to perform adequetly. Plenty of people, including myself have used the binary blob for games and other 3D software with wine through the late 2000s, 2010s and proton in the 2020s without much comment because it works fine. The exception being that if you buy a used card, coming up on 10+ years old because your requirements are minimal - don't expect current driver support. Nvidia drop support for old cards on Windows too.
AMD is definitely night and day in terms of meeting the free software ecosystem properly, and so arguably the reason to go with a new AMD card is voting for that kind of support with your wallet.
Cheating is endemic in BR and tactical shooter type games. I remember one f2p game was deleting 50,000 cheater accounts every month.
If the developer's winning $20 per cheater detection, and puts in extra resources when there's more cheaters, the equilibrium ends up a lot better.
And even for free games, I could imagine different ways to tie a monetary stake in in exchange for skipping invasive anticheats.
Blatant cheaters are bad in some ways, but subtle cheat are far worse imo.
But here we're putting Candy Crush in the same category as GTA V, so I'm not sure we're really comparing apples to apples.
Although, everyone probably says that about whatever distro they happen to use lol.
I have no idea why people recommend this to people who aren't actually deep into tech and linux already.
Most egregious problem is that steam games start in a strange window rather than full screen and you have to press a weird key combo to fix it.
Nvidia based Acer nitro FWIW your mileage may vary
I know you framed this as a negative, but this is something I yearn for; It's the one of the best games, imo. I often wish I ran into more issues, but for the most part, things _just work_^TM.
Unfortunately the install process is always going to be at least a little bit technical. I wish it wasn't, but idk how you'd do that without making the os like an emmu chip that you can swap out, instead of a thing you write on your drive.
Gaming moved for a lot of us from 'now I have 5 hours or whole weekend to gaming if I want to' to mere blips here and there, which need to be as frictionless as poasible.
Which is great - it means we are doing something actually meaningful and more worthy in our lives. But it also means I will never have enough time for such fiddling. I am fine with it, as much as I can be, but lets be honest to ourselves here.
Where are the hordes of kids like us back then who were content with the afternoons, evenings and wee early morning hours of endless fiddling? What I realize now is those years spent fiddling sharpened our debugging senses in both ineffable and tractable ways.
A larger proportion of the juniors I see coming through the corporate halls these days than I remember from even 10 years ago do not have that knack for fiddling, nor history when it comes up. And it shows in their debugging temperament. LLM's are making this worse.
The stow approach is something that I considered but ultimately rejected for a couple of reasons around handling conflicts of game-installed files as well as how to ultimately handle the symlink lifecycle (eg wrapper to make the "non-running" state always clean or to let it always persist and then need to run manual cleanup/update steps). But if you're interested in that approach when I was applying for Nexus Mods approval I discovered https://github.com/Marc1326/Anvil-Organizer in the overall list of mod tools which I believe uses that strategy (though I haven't really looked too closely)
But basically my original idea to just install the files directly into the game directory stems from the fact that when I switched to linux for gaming and not having success with MO2 that's literally what I was doing. I would download the mod from nexus and unzip/tar it into the game directory manually. When I wanted to uninstall or update I'd find the original archive list the files in it and then delete them from my game directory. After doing this too much I realized that I was basically missing the functionality of a standard linux package manager (eg apt, pacman, etc)
So if you need to persist changes into the lower layers, I think you may need to do tricks like taking snapshots and then swapping the bind mount (maybe with some diffing logic) or some other offline methods.
I should add that it's a CLI tool only (I may add a TUI later but it probably won't ever have a GUI if that matters). Anyway if you check it out and have any feedback whether positive or negative that would be cool
I don't want to discourage you, but what's wrong with helping MO2 and Vortex get ported to Linux?
How did you install it? Maybe with a different method it would work for me better (even though now I'll probably just stick with my own tool I'm still curious)
IE: Quakebots and Fighting games have perfect reaction times and perfect combos. They can simply block perfectly and counter attack perfectly and never drop a combo.
You act like cheating is new to video games??
--------
We never wanted bot in these games. Still don't want them today, and it's a big reason that playing on public boxes (ex: at an arcade or eSports tournament) is still a thing.
Defeating an opponent in a tournament is a big thing for fighting games. The risk of cheating online is always there so online tournaments are simply never taken as seriously (ie: as much $$$$ risked as real life tournaments).
No, I think the point is that with AI the existing anti-cheat measures can simply be avoided by letting the AI play through the same interface as a human. Therefore anti-cheat kernel modules will no longer be useful, and will no longer be a reason to stay on Windows.
Fill a room at the mall with Linux boxen with midrange GPUs and fiber internet and the sort of keyboards you can clean with pressurized water. Charge an entry fee and then sell pizza, cheetos, coffee, soda and beer. Open at 11AM and close at sunrise.
Then publish the public IPs used by the arcade-owned machines at each location in the chain and use different public IPs for the customer WiFi. No DRM nonsense, just a way to know you're playing with someone at the arcade where the management doesn't allow cheats on their machines.
Great. Now we are going to get “secure cables” for mouse and keyboard and bluetooth device attestation.
Have you even played an FPS vs an aimbots before?
https://en.wikipedia.org/wiki/Real-name_system_for_online_ga...
This was to prevent children from getting addicted but also leads to real life penalties for cheating in video games.
The idea of Mao's face or Trump's face on the global reserve currency feels really off.
"Quotes" of something not said directly that you are quoting is always bad. Quotes containing a summary that is entirely false are even worse. Don't do that.
You can try to deal with cheating as chess.com and others _do_, or you can do something you know will not work. Kernel mods for chess.com would be stupid. Their anti-cheat strategy involves zero windows kernel mods. That is how it will go for all online gaming if it hasn't already. So use something else.
Windows kernel modules won't work much longer if they even still do. Pretending they will, doing nothing to stop cheating is a a nihilistic, give up, faintly ridiculous attitude.
If you disagree with my interpretation of your nihilism, please go ahead and provide a workable solution for significantly suppressing cheating without the use of kernel level anticheats. Right now you're talking about of both sides of your mouth.
I don't want to beat a computer, I want to beat another person.
https://github.com/Furglitch/modorganizer2-linux-installer
Download, run install.sh, follow the instructions given. It replaces the game effectively in Steam, which does mean you have to launch MO2 anytime you want to play the game, but I found that at worst, slightly annoying.
Not sure if I buy it, how would that even work? lower licensing fees when no display port? I suspect the real answer is that HDMI managed to capture the market for digital video links and while display port is better it is not enough better for people to want to make the incompatibility jump.
But.... Conversely it does almost make sense. because finding DP on a TV is super rare, nobody is even trying. Historically you would find all sorts of rareish connectors on TV's(component video, s-video) so.. conspiracy... perhaps.
The hobby of optimising your gaming desktop is a related but different hobby to actually playing games.
It's much harder to step back and realise you don't need the new thing most of the time. Sure if you have a 15+ year old desktop and you can't run the new games at all then an upgrade could be good, but I'd guess most hardware purchases come from people who already have great hardware.
I have very specific requirements for motion clarity in games on modern displays. Older display technologies like CRTs and plasmas achieved this naturally through the way they operated. Most modern sample-and-hold displays do not.
You may not notice or be affected by that difference, which is fine. Couldn’t be more thrilled for you, however I am affected. Anything below 120Hz on a sample-and-hold display causes noticeable discomfort for me, and for a long time I stopped gaming entirely because I couldn’t work out why playing anything had seemingly overnight become so bad to play from a comfort perspective. Eventually I realised the issue started when I moved away from CRTs and plasma TVs to modern sample and hold displays.
I was only able to comfortably return to gaming by using very fast displays at 120Hz minimum, preferably 240Hz, because that gets closer to the motion quality I was used to from years of using PC CRTs. For games locked to 60Hz or below, I still prefer playing them on a CRT for exactly that reason and I own a number of CRTs for this reason.
You’re projecting. I think I’ve got what I enjoy from my hobby figured out after 35+ years, but thanks anyway.
> The game story, gameplay elements, and such have become secondary to the real hobby of consumerism.
You’re projecting.
> If people could have fun gaming 20 years ago
I didn’t have to endure sample and hold slop 20 years ago, now I do. You may accept or tolerate it, I am under no requirement to do so, nor live in a world where I must accept a significant performance loss is “ok” in any circumstance.
If I wanted less performance, I’d buy something with less performance to begin with.
For all the issues people claim to have with iOS or Android, they really "just work" compared to the shit we had to deal with back in the day. And I don't even mean bugs, but UX just wasn't as sleek.
I can find a pdf of the TTRPG I'm playing that's hidden deep in an iCloud drive by simply opening spotlight an typing the approximate name. And the same works on my iPhone. Apps that create documents for me hide their file structure, because it's all abstracted away from me. It works, and I don't have to think about it as much.
You still have kids that start fiddling with tech, but only out of clear interest. Not as a necessity.
So the bar to clear to get to gaming is much lower now, and it makes sense fewer kids get to the point where they must tinker to get at those games.
“Something you know will NOT work” Is what is written right on the page. You quote it without the “not” wTH? Kernel mods won’t work much longer if they still work at all. Gotta find something else. What? Let’s see. Won’t be kernel mods.
Doesn’t make much sense to see this level of non comprehension of plain English. There’s no point talking against it what i say makes no difference if you read the opposite. Maybe this is convo with AI? Dunno.
Best.
The routine at 0xFFD00 could then enter protected mode and use the code segment to build the index into a table of entry points: FFD0 goes to index 0, FFCF goes to index 1, and so on. But for extra kicks, the address isn't actually pointing to valid code. It points to a random "c" character in the BIOS, which is an ARPL instruction - which in turn is invalid in v8086 mode and therefore invokes the undefined opcode exception handler. The exception handler, which handily enough is already running in protected mode, then takes care of doing the 32-bit call.
Related: https://devblogs.microsoft.com/oldnewthing/20041215-00/?p=37...
Also described here: https://news.ycombinator.com/item?id=45283085
> It so happens that on the 80386 chip of that era, the fastest way to get from V86-mode into kernel mode was to execute an invalid instruction! Consequently, Windows/386 used an invalid instruction as its syscall trap.
I also read this part but I wonder how did they benchmark back then?
> Schulman’s Unauthorized Windows 95 describes a particularly unhinged one: in the hypervisor of Windows/386 (and subsequently 386 Enhanced Mode in Windows 3.0 and 3.1, as well as the only available mode in 3.11, 95, 98, and Me), a driver could dynamically register upcalls for real-mode guests (within reason), all without either exerting control over the guest’s memory map or forcing the guest to do anything except a simple CALL to access it. The secret was that all the far addresses returned by the registration API referred to the exact same byte in memory, a protected-mode-only instruction whose attempted execution would trap into the hypervisor, and the trap handler would determine which upcall was meant by which of the redundant encodings was used.
And if that’s not unhinged enough for you: the boot code tried to locate the chosen instruction inside the firmware ROM, because that will have to be mapped into the guest memory map anyway. It did have a fallback if that did not work out, but it usually succeeded. This time, the secret (the knowledge of which will not make you happier, this is your final warning) is that the instruction chosen was ARPL, and the encoding of ARPL r/m16, AX starts with 63 hex, also known as the ASCII code of the lowercase letter C. The absolute madmen put the upcall entry point inside the BIOS copyright string.
(Incidentally, the ARPL instruction, “adjust requested privilege level”, is very specific to the 286’s weird don’t-call-it-capability-based segmented architecture... But it’s has a certain cunning to it, like CPU-enforced __user tagging of unprivileged addresses at runtime.)
mov ah, 2
mov dl,7
Ahhh.. probably my first program. Don't forget the int 20 at the end! It was beeping great. Still never unlocked the mysteries of those TSR programs though.
So, what TSRs would do is overwrite one or more interrupts to point to a routine that would check if the system call in question was one it wanted to handle (eg, to add a hotkey it would grab the keyboard handler and check for a special set of keys before passing control back to the normal handler). Once that was fine, it would call the TSR system call and control would be passed back to the OS with the hook still in place
I made a bunch of those, in TurboPascal. Just needed to save registers (including stack and heap segments) and hook some key combination. One of them was used commercially for installations by a very big company.
Testing was a little prone to spectacular failures. But once the general procedure was debugged, it was easy as pie.
What calls specifically are you talking about between windows and linux? This was started by someone talking about WaitForMultipleObjects.
But assuming reasonable implementations, the difference between those two lock styles shouldn't be more than about a microsecond, should it? So that's fine for a lock that's only used 100 times a second.
I'm not comparing windows and linux anywhere.
What are the two functions you're comparing and what is the actual difference in overhead that you're talking about?
a lock that can be shared between processes versus a lock that can't be.
This is a dramatic black and white difference, these would be used for two different things. In that case it's apple and oranges, one would be for interprocess communication and one wouldn't.
the difference between those two lock styles shouldn't be more than about a microsecond,
What are you basing this on? Do you have an examples or benchmarks of the actual calls and their timings?
fine for a lock that's only used 100 times a second.
Again, latency isn't about how many times something is called per second. That would matter for throughput.
And then monitors released during this time generally do the same too.
Also if you want to use it through a capture card, HDMI ones are way more common and cheaper
I have a dumb-ish Samsung Hotel TV / commercial TV at home. It has DP.
Then again - none of the streaming services are streaming at anything remotely close to 100Mbps so I doubt they consider it necessary to upgrade to GbE.
I've had a smart TV for over 5 years and never connected it to the Internet.
My 2020 LG CX has a USB 2.0 port and I get ~300mbps with a gigabit adapter, if the TV you ended up with has a USB port it's worth a try.
Don't all USB-C video outputs use DP alt mode too, with an HDMI adapter at the end? And they can do HDR.
HDMI goes 25'+, no problem.
Yep. That's likely because that's an active cable. Active DisplayPort cables exist, too. Here is one vendor selling active UHBR10 cables [0]. If you don't NEED UHBR, then you'll find your selection to be much, much larger. I've been using some Monoprice-branded 50 and 100 ft active fiber-optic HBR3 DisplayPort cables for years with no problem.
[0] <https://www.bhphotovideo.com/c/products/displayport-cables/c...>
and displayport 2.0, since 2019, has supported all the same variations (hdr10+, dolby vision) that HDMI does
My main monitor is 4K 240 hz HDR and it works great on my DisplayPort cable, especially the HDR.
It’s just that it doesn’t work.
It is scary how nuanced the cheating tools already here. Here is a video promoting cheat software explaining how nuanced their aimbot system can be made to mimic real play: https://www.youtube.com/watch?v=hrBohlkHMjU
Go ask this comment, because I'm continuing their comparison: https://news.ycombinator.com/item?id=48125795
> In that case it's apple and oranges, one would be for interprocess communication and one wouldn't.
The whole point of the complaint was wtallis claiming the inter-process-capable lock was being used for locks that don't need it! That's the foundation of this conversation!
> What are you basing this on?
Basic coding knowledge and an assumption of competency. There's no good reason for it to slow down more than that when it's used the same way. If you have a reason go ahead and tell me.
> Again, latency isn't about how many times something is called per second. That would matter for throughput.
I addressed both.
The extra latency for using an overly capable lock should be negligible. That's not the problem anyone is worried about.
This is just saying "I just know", but what specific function and basic timings are you going off of? If you don't know, why are you so sure of the numbers?
The whole point of the complaint was wtallis claiming the inter-process-capable lock was being used for locks that don't need it! That's the foundation of this conversation!
They were saying it's rare to need IPC lock for video games and I don't think that's true, then I gave a scenario where you would use one.
But whatever, let's focus on the actual point:
> They were saying it's rare to need IPC lock for video games and I don't think that's true, then I gave a scenario where you would use one.
And I was pointing out that a voice IPC lock is still "rare" when we use the most appropriate definition of "rare" for this context. In this context of worrying that using the wrong kind of lock will slow the game down, how often we're using the lock matters. If we go 50 million CPU cycles between uses, it's "rare".
It has not shut up asking me to update the fucking thing. Every time I turn the TV on, about twenty seconds later an update prompt will pop up, and it will not go away until I actively dismiss it. This happened even after disconnecting and forgetting the wifi. Never again.
In addition, there’s not much these things can do against subtler stuff like ESP.
1. https://www.reddit.com/r/PleX/comments/eoa03e/psa_100_mbps_i...
ARM slander was not warranted
https://github.com/blakeblackshear/frigate/discussions/18431
You can try Googling around for bespoke products but they will almost exclusively come from China and they will be very overpriced due to the soldered RAM.
No, latency is what matters.
And I was pointing out that a voice IPC lock is still "rare" when we use the most appropriate definition of "rare"
This isn't really a point with explanation, it's just you saying 'nu uh', even though that was just a single example.
There's no reason for an upgraded lock to significantly change in latency. That's not what they were worried about when criticizing the idea of using the former lock as the main lock type in a game. Your most used locks need throughput.
So no, latency is not what matters. And I've explained why I say that in multiple ways, while you haven't given any explanation for why you're focusing on latency.
When they asked "how often" in the middle of that criticism, they're not looking for an example that sprinkles in a couple calls, they're looking for something that puts serious load onto the lock. Any answer that is once per frame or less is not properly addressing the question.
No you haven't, you keep talking about doing something 100 times, but if you have a lock between processes, getting those processes to wake up and know the unlock happened with low latency is what matters. After the unlock whatever happens is going to be fast anyway, which in IPC is probably going to be copying memory.
What specific function call are you thinking of that would have high overhead but not latency and the latency wouldn't matter?
you originally responded to
I replied to someone saying "how often do you use a shared lock in games" and I said there are obvious uses.
That has not been part of all my explanations. But just so I can make it as clear as possible I will now explain it again without mentioning how many times it's called anywhere in the rest of my comment:
> if you have a lock between processes, getting those processes to wake up and know the unlock happened with low latency is what matters
Whether it matters depends on what you're benchmarking.
When the alternative to IPC is waking up another thread, your latency should be about the same either way. It's not what they were trying to compare.
The core comparison they wanted to make was about the simplicity of using a single lock type versus the overhead of using an IPC-capable lock everywhere. A better way to phrase their actual question is about how deep those IPC needs go in contrast to their downsides, not just whether there's a single call site somewhere.
> I replied to someone saying "how often do you use a shared lock in games" and I said there are obvious uses.
You gave a perfectly good answer to the half a sentence you quoted, if that half sentence was in a vacuum. But it was not in a vacuum, and your answer was not good for what they were actually asking.
Good, because that's what I meant to do, which is why that's what I quoted.
why did you argue with me???
You replied to me.
You did not answer the question they asked. You answered what would have been a reasonable interpretation of half of their sentence, if there hadn't been more text directly around it.
> You replied to me.
I did.
But if you were purposefully isolating half their sentence, there was no reason for you to argue with that reply. The way you argued implies you weren't doing that on purpose, and thought you were answering their actual question.
They did ask it because I quoted it and replied. That's how these forums work. People write text and other people reply to it.
The way you argued implies you weren't doing that on purpose, and thought you were answering their actual question.
No, that's not true, I think you made all that up.
No, you quoted half a sentence. That wasn't the whole question. You didn't answer the actual question.
The fact that you're still insisting you answered the question makes it clear why you argued with me when I was just clarifying things. You didn't answer something different on purpose, you're still stubbornly acting like you answered the right thing.
You did not answer their actual question. Period. I'm leaving now.
They asked two questions and I answered one. You hallucinated timings to imaginary functions you couldn't name.
Period. I'm leaving now.
You inserted yourself and had a meltdown. I don't know why this was so upsetting but you couldn't actually give a single technical detail, it was just "I just know" and "ask them what function I'm talking about".
And you were just as stubborn/'meltdown' when repeatedly insisting it was about latency. They never mentioned latency.
No it wasn't (I think you meant rhetorical). They might just have not expected a reply.
And you were just as stubborn/'meltdown'
I didn't reply to you.
when repeatedly insisting it was about latency. They never mentioned latency.
I mentioned it once you mentioned overhead, because that's what is actually important between processes.
I don't mean rhetorical. I mean abstract in that it wasn't about specific locks, it was about types of lock. That's why I didn't try to name any particular functions.
> I didn't reply to you.
In your future replies to me.
If you're not talking about later replies... are you implying you were calling my first comment a meltdown? Weird.
> I mentioned it once you mentioned overhead, because that's what is actually important between processes.
The main worry expressed in the original post was about the throughput of using an IPC lock in places that don't need an IPC lock. That's the overhead I was talking about.
That's what I answered.
are you implying you were calling my first comment a meltdown? Weird.
Trying to make things up that never happened?