It will never happen, but my dream is for the Asahi devs, Valve, and Apple to all get together to build out a cross-platform Proton to emulate and play games built for Windows on both x86 and ARM hardware running Linux.
A Steam Deck with the performance and power efficiency of an M-series ARM chip and the entire library of games that run on Proton is just...dreamy.
Her output is incredible.
The real reason Apple is ahead is because they're paying for more expensive more advanced nodes for their CPUs. I you compare CPUs on similar node sizes, you'll see that AMD and Intel are basically caught up architecturally in perf/W metrics.
https://www.notebookcheck.net/Intel-Lunar-Lake-CPU-analysis-...
But I guess there was never a time when an open graphics standard stood as the leader. Maybe during a brief stint in the Windows Vista era at best.
Intel was losing badly to one or the other at all TDPs. I don’t get the impression that’s changed much. (Even if it has, I can’t remember the last time I encountered a non-xeon intel machine with working hardware and drivers (for any OS, and I tried Windows, Linux and macs).
I recognize it’s a hell of an ask, but I think Alyssa could pull it off.
The end game for Valve isn't Steam Deck 2 or 3 (which is statistically impossible for Valve to produce), but for Steam to be on everything.
And the root of the whole browser wars thing was microsoft making an absolute dog of a browser for Mac OS X when it came out and then refusing to support it. lmao.
Most of the studios that own those games, and target POSIX like OSes on mobile phones and game consoles, are yet to bother with GNU/Linux versions for SteamOS.
It was the file manager as well as the browser and it was incredibly capable. By far the most advanced GUI file manager of its time. And a pretty fast and pleasant browser, although the compatibility was hit and miss. (Those were Flash and IE-dominated days as I recall them.)
A lot of what I loved about Konqueror is captured in Dolphin. I don't think I need my web browser to be a file manager... maybe that concept was just a 90s fever dream. But I miss Rekonq. Maybe I should revisit Konqueror.
What Valve want is the dissolution between platform/architecture and store. By my eye, it's the driving force of their efforts, more so than them selling hardware or being the open source good guys. Not to undervalue their work in helping make Linux a first class citizen for gaming, but the core of their business model is getting people to engage with their store, full stop, and being able to sell their games on Android (and elsewhere) would massively extend their reach.
This may go both ways too, there's also been indications that Valve have been tinkering with Waydroid, meaning Steam could also become a store for Android-native games.
I also remember Safari on Windows, which was convenient for many reasons.
I empathize if you don't like any version of Windows newer than 7 or XP, but it's time to let the dream of running them forever go. It's not weird when software doesn't support the 2009 version of an operating system anymore in 2024. If they never dropped support, it would be difficult to take advantage of improvements that occurred in the last 10 years, because we'd forever be stuck in baggage.
Of course when it's feasible everybody loves software that really never does drop support, like 7-zip, which I think happily still works on Win9x without KernelEx... but I'd rather 7-zip stopped having serious security issues than continued to work on old Windows versions.
Also a quick correction, there was no IE5.5 for OSX. That was for Windows and used a diff rendering engine.
Sure it's a great design, but I believe x86-64 will catch up once again now with everyone using TSMC.
AIUI, if you want the most flops per die, you'll buy x86 - probably the 128-core Xeon for enterprise money. But that's not what's best for hand-held gaming.
AAA titles are typically GPU-bound anyway. More CPU flops may not offer much benefit.
Half life 1, 2… hm.
Ok we’ll make three HL2 episodes to follow that up.
Ep I. Ep II. Uhhhh… and let’s stop there, just like forever I guess.
Portal 1. Portal 2.
Left4dead. L4D2.
Team Fortress. TF2.
Counterstrike. CS2. Oh shit we’re releasing a third one, we might have to use the number three finally, oh no… I’ve got it: CS:Go!
I don't think Valve wants to be at the mercy of Microsoft and their policy & technical decisions.
However, it is Microsoft more than anyone else that has decided to stop supporting those operating systems. Windows XP does not have support for any modern version of TLS (only TLS 1.0). There's no good way to support a browser-based app like Steam on a platform that cannot natively provide a secure connection to a modern web server.
There is not such a hard reason to drop Windows 7 support (again, except that Microsoft no longer supports it) but there are security-relevant APIs that are only available starting in Windows 10 which means special patches would have to be maintained just for Steam on Windows 7 to continue working securely.
https://raw.githubusercontent.com/apple/homebrew-apple/refs/...
0 chance they upstream anything. So in a way they are already benefitting from valves work.
Yes, but actually no. The Steam Deck is playing at extremely low resolutions. Rendering at 720p and 30fps is (on paper) 8x less demanding on the GPU than rendering a native 1440p60 experience. You can fully get by without having a powerful dGPU, which is why the Steam Deck is really able to play so many titles on a weak iGPU.
The problem is translation. Cyberpunk 2077 runs fine on a 25 watt mobile chip that uses x86, which is why the Deck even costs less than $1000 in the first place. If you try to put a mobile ARM CPU in that same position and wattage, it's not going to translate game code fast enough unless you have custom silicon speeding it up. There's really no reason for Valve to charge extra for a custom ARM design when COTS x86 chips like AMD's would outperform it.
For x86 PC games (which pretty much all games are, today), ARM is at a substantial disadvantage, period. The IPC and efficiency advantages are entirely lost when you have to spend extra CPU cycles emulating AVX with NEON constantly. If there were ARM-native games on Windows then things might be different, but for today's landscape I just don't see how ISA translation is better than native.
Regardless, point stands: they hate the number 3.
By supporting Proton, they are guaranteeing that modern and retro Windows games will be playable on Linux far into the future. Trying to get the next Call of Duty to support Linux natively is, quite literally, a waste of everyone's time that could possibly be involved in the process. I cannot see a single salient reason why Linux users would want developers to release a proprietary, undersupported and easily broken native build when translation can be updated and modified to support practically any runtime.
In order for Microsoft to rug-pull the technology (which is quite different from rug-pulling the business model), they'd have to break compatibility on Windows itself. Video games remain a major reason for home users to run Windows. Making ABI-breaking changes to Win32 or DirectX is just not very likely to happen. And if it did happen, it would be a boon to Valve and not a harm.
The biggest risk (and this would be a classic Microsoft move, to be fair) I can foresee is aggressive API changes that make it hard for Valve/Wine/Proton to keep up but also make it hard for game developers not to. I'm not exactly sure what this would look like, and a lot of the core technologies are pretty stable by now, but it's a possibility. It's not, however, going to harm anything that already exists.
Making SteamDeck use windows wouldn't impact prices much, Microsoft is really friendly for putting windows by OEMs. Could even run modified to act like current steam deck.
Instead, SteamDeck is there to drive up testing on Proton or straight forward porting to Linux, which just availability on Linux and the previous steam machine didn't drive up
The steam deck is 100% usable without leaving 'game mode' even a single time. Something that is genuinely impossible using Windows as a base. That's the important part
Also when it comes to breaking proton support (Which does happen) Valve + GloriousEggroll give you access to plenty of older and special versions. Surely that's better than rolling back entire software?
My game doesn't work -> I go to protonDB -> Users saying use X Proton Version or Y ProtonGE version -> I switch the layer used in steam
Hard to imagine a simpler process than that
- CD Projekt Red: released Witcher 2 on Linux, didn't for Witcher 3.
- iD Software: released Doom 3 on Linux, didn't for Doom (2016) or Doom Eternal.
- Epic Games: released Unreal Tournament 2004 on Linux, but didn't for Unreal Tournament 3 or Fortnite. (A Linux port was being worked on for UT3, but it ended up getting cancelled.)
- Larian Studios: released Linux version of Divinity: Original Sin, didn't for Divinity: Original Sin 2 or Baldur's Gate 3
Many studios over the years have made native Linux versions, and many studios stopped because the cost of porting exceeded the revenue it generated. Proton didn't exist when Unreal Tournament 3, Witcher 3, Doom (2016), or Divinity: Original Sin 2 released, so Proton wasn't the reason those studios stopped developing Linux titles -- they stopped because it made no financial sense to continue to make them.
Now, with Proton, 79% of the top 1000 games on Steam are gold or platinum rated on ProtonDB. If you're fine with minor issues, 88% are silver rated or better. For the Steam Deck in particular, there are 5,500 verified games, and 16,526 verified or playable games. So I'd argue Proton is doing quite a lot for people gaming on GNU/Linux machines, since they now have access to a solid majority of the top 1000 games on Steam, both on a Linux desktop and on a handheld.
If future versions of Proton break compatibility with older Windows apps, you can use different old versions of Proton for individual games. Steam makes this very easy on Linux, but rarely is it necessary.
I don't foresee many Linux distros breaking compatibility with Wine, which is good, as some devs argue Win32 is the only stable ABI on Linux. [1]
I don't foresee legal issues either, as Wine has been around for 31 years, and its corporate sponsors have included Google in the past. I've seen no indication that the project is on shaky legal grounds.
Microsoft could always create a new API that Wine doesn't yet support, but good luck getting developers to use it -- they've tried many times, but not much has stuck, and most devs just stick with Win32. [2]
1. https://blog.hiler.eu/win32-the-only-stable-abi/
2. >>36060678
Then again, all kinds of companies take liberties with naming including numbers. Look at Windows 7 (12th major release), Windows 10 (successor to Windows 8), the game Battlefield 2 (third in the series), Battlefield 3 (three games after BF2), Battlefield 1 (after the release of BF4), etc.
1) everything standardized, like it or not (note: I do not), on the Windows API, and it has remained relatively stable, which is important because
2) Linux-native games I've had, have become un-executable over time without semi-regular maintenance, and Windows games running on whatever version of Proton they best work with do not have that drawback
We aren't in the 90s anymore. Win32 has stalled, Microsoft has a regulatory gun to their head and Wine's compatibility (at least in the domain of games) is extremely good, good enough to allow for a commercial product to be a success while being entirely reliant on it. In what way is any of this comparable to what happened with OS/2 outside of "it runs Windows applications"?
'Default' KDE apps are often so well thought-out and complete that I never feel the need to deviate from them, and it's not unusual for me to install them on other operating systems when possible. I feel this way about Dolphin, Okular, Ark, Kate, Gwenview, Klipper, and Konsole/Yakuake, too (even though there are several great new terminal emulators out nowadays). And KWin! God, KWin's configurability is so good and it has some really killer compositor effects for productivity that are still unmatched.
CodeWeavers released an annoucement when Gaming Portal Toolkit was announced.
https://www.codeweavers.com/blog/mjohnson/2023/6/6/wine-come...
You sure there was any kind of commercial agreement? Doesn’t look like it.
On top of that, Apple's DX to Metal code is not re-distributable. So yes, this sounds like more of the same from Apple.