Valve is paying open-source developers to work on Proton, Mesa, and more
old.reddit.com
old.reddit.com
>I’m on a record saying, that maybe Valve will actually save the Linux desktop. And it’s actually not because I think games are important! I don't care, I don't play games. I think some people do, so games maybe important. But the really important issue is I guarantee you Valve will not make 15 different binaries. And I also guarantee you that every single desktop distribution will care about Valve binaries. The problem is Valve though build everything statically linked and it creates huge binaries. And that's kind of sad but that's what you have to do right now.
Arch is pretty good at making the native packages work, so that's always ideal. The community is generally pretty good at competently packaging AURs, and they'll do it for slightly less free things, so that fills a lot of gaps. AppImages and Flatpaks are great when they work, but opaque and difficult to diagnose when they don't :/ And snap is just... unpleasant. It's insistence to auto update separately from my package manager has really turned me off of it's whole ecosystem. No thanks.
Running a big infra to run a single binary once in a while feels like a burden to some of us.
They might not be triggered and launched all the time, but this mode of operation is different from .appimage files, which are just ordinary binary files you directly run.
https://forum.snapcraft.io/t/limitations-in-snapd/9718
This actually means that at some point I will have to move away from Ubuntu.
I have great sympathy though, I am also using Ubuntu on Jetson and resent snap, especially since the new releases are 20.04 which have it more tightly integrated.
Or reconfigure U-Boot to load extlinux.conf (and the kernel image, initrd, etc) entirely from other type of media. IIRC NVMe, USB and external SDs are all supported
I'm not sure why you'd need to symlink /home/ to another filesystem instead of just mounting that on /home/ directly, that's what I'm doing with root on ZFS and a separate dataset for /home/ with it's own mountpoint.
Anyway, now I'm working around limitations in Snap instead of Snap working around its own limitations in certain circumstances. The fact that Snap shows weird behavior and illogical error messages in these cases tells me that Snap is not (yet) up to the task of fulfilling this rather fundamental role in my OS.
Sounds like something a bindmount might fix.
Back in the olden days before simple and convenient packaging systems like snap had been invented, we had to get pretty creative so that stuff didn't freak out because it was split across filesystems.
And if you really want a single redistributable binary, any existing package can easily be bundled into one without recompiling it.
Traditional static linking is strictly worse.
Anyone disagree?
I think this is true, because with Nix and Guix, you actually have an end result with the positive characteristics of both kinds of linking.
His talk, based on his work on shrinkwrap² and nix-harden-needed², called for the creation of a new executable format for the Nix world. Seems apropos as a reminder that there are other possibilities!
(I think these kinds of solutions are definitely within reach for Valve from a technical perspective. Other tools are using them today.)
--
1a: https://youtu.be/HZKFe4mCkr4
1b: https://youtu.be/lzk4sldexX4
2: https://fzakaria.com/2022/03/15/shrinkwrap-taming-dynamic-sh...
3: https://fzakaria.com/2022/09/12/making-runpath-redundant-for...
But multiple derivations can share dependencies, which does save space and also makes it easy to identify dependencies of a given derivation, where statically linking would make that opaque.
Also, the story goes way beyond binaries, as dependencies often carry additional resources not bundled into the binary.
Wasn’t the reason to separate binaries and libraries in the first place to conserve disk space? They are then clearly versioned to signal that you can’t expect just any version of the library to work with the program you wrote.
The trade-off in using more disk to contain “an application” to “a binary” seems fine to me, if you’re not sacrificing anything else.
The only drawback I can think of is that it makes very minor patches, like security fixes, to the library impossible, which is a nice thing to have I guess, but on the other hand you’re now giving the library maintainer the capability to crash your application, and since that would presumably go through some kind of review and rebuild of the application in the first place to avoid crashes against the new library code, why does it matter if the lib is a part of the actual binary or not?
Is it really down to nothing but bandwidth and disk usage, or am I missing something here? Because if it is, and “blob binaries” becomes the norm, I’m sure you could still figure out partial patches somehow to conserve bandwidth and IO, while still keeping the binary essentially a built monolith.
Maybe one argument is that abandoned programs can still be “patched” in a way because a library it depends on fixes an issue that library was responsible for, but doesn’t that seem pretty risky to begin with to run software that is no longer being patched?
Indeed what constitutes “software” just seems to be multiple pieces in one case, and one piece in the other, no?
The biggest case against “vendoring”, which in my mind is similar to “huge” binaries, that I can think of at least is that it gives developers a false sense of security to not have to think about keeping libraries up to date: but aren’t they already equally able to be sloppy about this when the libs are separate?
Typical games I have experience with were in the 5-20Mb range for executables, with tens of GB for assets. Most titles I looked at the performance of were terrible at scheduling I/O, often leaving 80% of their available disk bandwidth unused.
On the other side, link time optimization on static libraries allows deletion of unused functions and more aggressive inlining, so you might get that performance back and more.
The whole debate is just stupid. If it inconveniences even one fewer user, then static linking is the way to go, because of the sheer number of drawbacks that shared libraries bring. Nobody cares how big the executable is. If you do, well... the best time to stop caring was 10 years ago, and the second best time is now.
Also there is value in being able to fix a library without having to recompile everything.
Number of times I have benefited from this process: 0 (AFAIK)
Number of times this process has hosed previously-working applications and components: too many to count
On Windows, this "feature" was called "DLL Hell," and was generally considered a bad thing. Nothing has fundamentally changed since it was a common practice for every installer to have its way with c:\windows, IMHO. (Admittedly shared MSVC runtimes aren't as big a problem as the Winsock-provider-du-jour was, but still... there is simply no point.)
Every day on my distribution, when I have to download 5kb of library instead of 3GB of everything recompiled…
Source? I know when stuff on my distribution gets recompiled because then I have to download and unpack it, so I notice.
I can assure you that it isn't as you say.
> with FreeBSD
Despite the monorepo thing, I assure you that most FreeBSD users do use software coming from other places as well.
The functional package management/build system design instantiated by Guix and Nix shows that you can have the best of both worlds when it comes to static and dynamic linking, even without any form of containerization. Guix in particular has a feature called 'grafts' which implements a kind of hot patching for libraries in programs which are nominally dynamically linked but which in fact never search for libraries other than the exact versions they were built with.
So there's no need to choose between the portability of static linking or the efficiency and flexibility of dynamic linking. You can get all of those things together, today, for many thousands of packages.
If you're not familiar with the basic outline of these build systems, the idea is basically this:
- every package gets installed to a unique, quasi-content-addressed location
- each such location has its own FHS-like tree which gets treated as a prefix for that package at build time
- every package gets manually pointed to each of it's dependencies' unique, full paths at build time
this ensures that each package always tries to load the libraries it was built with, and allows multiple versions of libraries to safely exist side-by-side, even when everything is dynamically linked.To ship a package, you then just ship the whole dependency closure, which gives you the portability that motivates people to distribute static binaries.
Here's some info on Guix grafts, for an idea of how security updates can still be managed in such a system.
The official docs for grafts: https://guix.gnu.org/manual/en/html_node/Security-Updates.ht...
Original blog post/announcement for the feature: https://guix.gnu.org/blog/2016/timely-delivery-of-security-u...
Detailed writeup of further implementation details: https://guix.gnu.org/en/blog/2020/grafts-continued/
The problem isn’t size. The problem is that with static linking it gets significantly more difficult to patch security vulnerabilities, because with dynamic linking, the vuln is gone once the underlying library is updated, however this wouldn’t happen with static linking.
In contrast, on (for example) Debian, I know that the Debian Security Team is looking after the libraries and that gives me a lot of peace of mind. Instead, I'd be wondering if every single third-party apt repository package owner is doing a professional job. At least if they're shipping binaries that are dynamically linked to Debian packages, I can have confidence that those library issues are being handled. (XML parser update, anybody?)
That said, if the library changes the API or functionality at all, dynamic linking is going to break the game, and that's not good either. So gamedevs are going to opt for static linking and call it a day rather than deal with support requests.
Many programming models (e.g. monomorphization as done in C++ and Rust) are fundamentally incompatible with dynamic linking. The tooling needs to handle those cases anyway.
The amount of popups, nags, helpful hints, setup your system (which is nothing more than an interstitial to reset your browser to Edge+Bing) and other bullshit I get when logging in is mindbendingly infuriating.
This is after only being mostly away from Windows for a year. It's a shit product. I was merely a happy toad in some hot water. Things are much nicer once you actually climb out of the pot.
It's free (along with everything in the "app store"), it's stable, it isn't infested with ads, and the browser and word processor work exactly the same for all normal users. The OS shouldn't matter much to regular people who just want a web browser and maybe a word processor.
It's really easy to use now. The installation process is far less arduous than Windows and you don't have to sign up for a Microsoft account or get nagged about not doing so.
I would really struggle to imagine someone having trouble doing all their normally-Windows-based (filesystem, office suite, web browser) work on a mainstream distro now, even for the most technically illiterate user.
If you're a power user though, it's like moving from a Corolla to an F-35.
For example it doesn't keep installing "apps" that are just ads for netflix/spotify/tiktok/whatever without me ever having wanted them to appear.
Is that what you expect to get as replies to your question?
I haven’t played much multiplayer anything (a little MTGa, among us, tabletop simulator and beat saber) but none of the single player games I’ve tried on Ubuntu have had any issues; just open steam and press play.
Windows started pushing f2p games in the start menu, changed UI toolkits twice in two generations, etc; it’s become unpleasant for me to use. Apple have similarly dropped the ball on UX in the past 5 years. IMO Linux UX has caught up thanks to those companies failures.
I3bar to indicate which workspaces have new chat messages etc.
Default black background, all non-critical notifications disabled; I get distracted easily, so I craft an environment that avoids distractions.
In general, I'd prefer to have something both simple and easy, but in most cases that's not an option.
A basic Windows install had some basic tools and utilities, but they largely didn't push things on you - and once you had set preferences, that was that.
Then Windows 8/10/11 came around.
Ads through the UI. A half-dozen or more sponsored bits (both 3rd party and their own other products). You'd log in one day and find they'd installed some other piece of crap. Features were disappearing behind the Microsoft Store. You'd try and set up a machine, and it'd play stupid games about "Oh, you need a Microsoft Account to log in", hiding/removing options to skip if it detected an internet connection.
You'd install Chrome or Firefox, and it would beg and whine. They changed up how you set browser preferences twice, to deliberately make it harder to switch. It would "helpfully" reset browser preferences back to Edge "for security".
Updates were force-installed, regardless of whether you wanted to. I remember being at a conference and hearing from maybe a half-dozen presenters who'd all had Windows push an update during the conference. Some it was just before they were about to present. Some had their machine sitting in it's various phases of Updating for an hour or more. Some had Windows reset a bunch of other preferences/configuration, and fuck up demos they had planed.
For me, the security and privacy benefits are secondary to "Let me use the machine that I'm paying for".
Ubuntu/Pop_OS might prompt me to install updates, but I've never had it tell me I have 15 minutes before it is going to force applying updates, 5 minutes before I'm supposed to join a meeting. Ubuntu might have some sponsored bits, but they're gone when you remove them.
The end of Windows 7 was the end of me using Windows, because I just can't trust the OS to do what I want, when I want.
This isn't just me, either - I've converted three other non-techie folks over to Ubuntu, too - all they did was stuff in Chrome and the occasional bit of printing. They had similar issues with Windows forcing changes on them that they didn't want. Multiple times I'd had to reset browser settings, because Windows decided that Edge was better. So Edge imported their contacts, but not the Chrome apps and couldn't sync passwords to the Google Passwords service.
Multi-billion dollar industry raking in higher profits than Hollywood and that at this point is an unregulated online casino for teens.
Yeah, some people do...
Maybe I have been reading too many of his emails.
Given the variety of the projects you've mentioned it could seem that you have some degree of freedom, but I might be mistaken.
Unfortunately my skillset as a senior full stack dev seems rather irrelevant for jobs in and around OSS. It appears those jobs are mostly C and C++.
It's really only the (crucial) segment of big, trendy multiplayer titles where support is still really hit-and-miss. If gaming is essential to your social network, Linux may not be ready for you to entirely switch over.
But if you're someone whose social hobbies lie elsewhere who enjoys solo gaming, there are way more excellent Linux games ready for you to enjoy than there is time for you to play them.
I was disappointed when post-purchase Psyonix dropped official Linux support for Rocket League. However, the Proton support has been rock solid, and I'm yet to encounter any crashes, even after updates. The Linux binaries occasionally had regressions after an update.
From memory, Valve has also been supporting anti-cheat providers to port to Linux (or perhaps I have misunderstood and they will also run under Proton?), so there’s always a chance this will be solved in the next couple of years. The Steam Deck has been a great catalyst for that within Valve, it seems.
I think if, over time, it looks like those fears are unfounded and there are few practical problems with anti-cheat for competitive games on Linux, then probably some currently-hesitant publishers will relent and enable their games on Linux. But only time will tell, I suppose.
Not really a gamer. Cyberpunk is probably my high water mark at 90 hours. It's so nice to not to have to make major concessions to run Linux.
Valve you have earned a customer with me.
Please keep it up! you're the heroes we need in this fight.
P.S. I'll be buying games from your store also as my kids are gamers
Which makes sense since the hardware is similar.
So I have no idea what you're talking about, it can easily replace Xbox.
- God of War
- Elden Ring
- Final Fantasy VII Remake
- Forza Horizon 5
- Jedi: Fallen Order
- Spider-Man Remastered
Xbox, PS and Nintendo won't die, but there will be a fourth player, and if anyone has to die first, it'll be Xbox, due to shrinking mind share and lack of third party titles.
Full KDE desktop based on Arch (/ is read-only by default, but this can be disabled)
it Really shines when plugged into external monitors/dock. In particular, I have a couple USB-C displays that provide usb-hubs - I plug a single usb-c cable into the top of the thing and have a great little mini-workstation machine.
Does 4k displays just fine and is very responsive for the size. It's basically replaced the linux laptop I would drag along on trips. If I need a workstation it suffices, and I can plug it into hotel room tvs really easily to watch whatever I want.
Basically - hard to argue with the value proposition given it only costs $500 and I get a great little portable workstation. That fact that it does an excellent job with games is just cream on top.
But the dockability makes it pretty damn awesome. you can code in first class style by docking it with a monitor and keyboard, and then when you leave you can take it with you and get a great portable game player or movie watcher or web browser with good battery life. the built in screen is pretty good. I was impressed
But it's pretty lightweight and handles games well, so if I go on trips somewhere, sometimes I just bring the Deck + small keyboard to do emergency fixes on, and for that, it works very well.
Honestly a laptop makes a lot more sense in general for that still. You just pull it out and everything you need is there. But if the versatility of the device is appealing to you then it might make more sense. I have used it for traditional computing with a keyboard/mouse and portable monitor, but it is quite cumbersome to do so. But I value it much more and primarily as a portable games system. As an aside, the trackpads are great and for me the thing that sets it apart from any of the similar systems, but in desktop mode they aren't nearly as good or useful by comparison. Though it might be possible to change the way they work in desktop mode but the basic way it hooks input by default makes them pretty dumb trackpads.
My ONLY beef is that the AMD drivers do not work 100% with Blender so you don't get the accelerated Cycles rendering. Otherwise, it is great.
In any case, ROCm works with the completely open source stack, and is open source itself. amdgpu, the kernel component, is the only thing needed for that, and modern upstream works fine. The integrated steam deck gpu simply can't work with it, though.
The issue that has recently been resolved was that only the amdgpu-pro userspace had working OpenCL 2.0+ support. Mesa 22.3 has better OpenCL now, but that's actually become less relevant with the new HIP/ROCm stuff.
That's a shame. I was hoping it was something I could help with, but that's a bit beyond the scope of what I can fix myself.
the open source kernel driver is the only one in use and sits under both the open source and closed source userland driver stacks.
i'm pretty sure what they're saying is that rocm doesn't support running on the apu in the steam deck at all -- i'm dealing with a similar issue in bringing up a product on a different amd apu that has a beefy enough gpu for my application
It's an RDNA2 GPU and AFAIK, all the RDNA2 GPUs can be coerced into working with ROCm (even if they are not 'supported'). Maybe the Steam Deck is an exception. I don't know. I'll give it a spin over the holidays. Win, lose or draw, it sounds like I'll learn something interesting.
When I check rocminfo, the hardware is reported as gfx1033, which is an identical instruction set to gfx1030, so export HSA_OVERRIDE_GFX_VERSION=10.3.0 should work perfectly if you're using the AMD binaries. Or you can build from source for gfx1033, but that's probably more painful than necessary.
The one catch is that the Steam Deck is currently using Linux 5.13, which predates a lot of bug fixes. I was noticing bugs while using the upstream kernel when packaging ROCm for Debian until something like Linux 5.19. My test case for the Steam Deck was rocRAND, which passed most of its tests. I would expect the rest to pass with a newer kernel, though I haven't verified that.
tl;dr: ROCm is not packaged for easy installation on all the platforms you might want to use it on, but it appears that the hardware works and the software exists.
I can't speak for steam deck though, just my experience on a self build.
Unfortunately, some of AMD's GP-compute infrastructure is only supported on Linux through the proprietary driver. I believe these are ROCm and HIP. I'm not sure about OpenCL. I'm not 100% sure what Blender uses for AMD acceleration, but if it's ROCm, you'd need the AMDGPU driver instead of Mesa.
Could have some of these details wrong, but I believe that's the gist of it.
You can, of course, install other OS on the Deck.
amdgpu is the underlying open source kernel module -- it's in the mainline kernel.
mesa is the open source userland driver, and runs atop the amdgpu kernel driver
amdgpu pro is the closed source userland driver, which also runs atop the open amdgpu kernel driver.
what's really nice about this is that you can run a fully open source stack in your host os while running amdgpu pro/rocm inside a container.
Apple has made a bunch of decisions that really hurt gaming on macOS, which is frustrating. Starting with the $99/year fee just for app notarization, which deters tiny indie games from being released on macOS. This has a persistent long-term effect as those same developers make bigger games.
And on the other end of the scale, they're still using Metal as their own modern graphics API, so everyone has to either use a third party compatibility layer (MoltenVK), or use their engine's least-mature, least-well-tested rendering backend. Either way performance is pretty much guaranteed to be worse than it could be.
I’d say Valve comes close to being universally loved here, though, and that is pretty unique.
If you work for a shop in Omaha Nebraska making software for surrounding businesses, you probably use Windows.
HN and Reddit aren't hive minds and both hold a lot of diverse opinions. Nothing is universally loved on either. Today's society can longer agree on agree on fundamentals like if the earth is round or if democracy is good. So it isn't a huge surprise that not everyone has accepted The Infallible Glory that is the Jetbrains product roster (A little joking in that last bit.... but just a little. All praise CLion)
I am very curious about this tbh. Has anyone here gone to that site? I read that they just report publicly available info that people have voluenteered online. While I understand that doxxing is terrible and so is targeted harassment, are they that much worse than the daily mail or any other gossip magazine?
- gossip magazines usually target "public figures". many jurisdictions have relaxed privacy rules around those. KF targeted whom they found... "interesting"
- haven't really read gossip magazines, but i assume they have a higher bar. for example, did any of those print the hunter biden dick pics requested to be deleted in the "twitter files"? cause you could be sure of them to have been on KF, if they had thread on him
- "publicly available info" is stretching it quite a bit. In the case of @elonjet, we that is info required by law/court to be public. KF, on the other side, is more like "stuff that was ever published somewhere" (as opposed to getting new stuff), so again your nudes are fair game for them, no matter any distribution rights
I'm glad they "cracked" and wish they'd initially dropped KF.
Personally I don't care, they are free to have whatever policy they want, but doing exactly what they did one week after writing up a blog post and explicitly stating that they most likely won't drop any websites like that anymore was a bit disappointing.
- Young male angst has no shortage of outlets. Sports, both extreme and normal, tons of existing media, pirated media, blowing stuff up, etc. Taking away Steam accounts likely isn't going to turn them into revolutionaries.
- In response the existing comments from Russians, that could be selection bias. Many of them could be commenting normally or not at all. After all, most of what you read on the internet is written by insane people.
- Part of the problem in Russia is extreme media bias/propaganda. Further isolating them from foreign contact and influences can only make that worse and reinforce the narrative that everyone else is out to get them.
Wow man cool it with the antisemitic remarks.
Whatever there is, there will be abuses of it, so yeah, many would just use the "opium" part of Steam. But there's another aspect of it that would still get imported, and that's any of the narratives that differ from the propaganda they are subjected to. With Steam specifically, they'd be exposed to titles like This War of Mine, and international communities where they'd experience that nobody gives a fuck about them being Russian, or even find it cool, despite the prevalent anti-Western propaganda in their own media.
And that all, I think, is worth more than sanctioning it.
Also, you know what really provides bread and circuses? Populist bullshit such as "Putin banning LGBT propaganda". Nothing better to take the minds off of pressing issues like further harming a marginalized group.
https://news.yahoo.com/vladimir-putin-bans-lgbt-propaganda-1...
The world is moving to regional blocks -- a Western block of North America and Europe, a Eurasian block of Russia/India/Iran/Middle-East/China, and the loyalties of Africa/Latin America are where the wars for influence will be fought, with Africa tilting toward Eurasia and Latin America tilting toward the West. Other battle grounds would be marginal areas like Southeast Asia/Pacific Islands and in Europe the balkans. In that context, it makes no sense for the Eurasian block to allow a business to operate domestically from an enemy block. Why on earth would you let them influence your population? For the same reason, Eurasian influence operations are being banned in the West, from Confucian Institutes to Sputnik News.
The main entrypoints to a block will be those nations that have sufficiently rigid control over their domestic populations to feel free with enemy dependencies -- that would be the US and China, both with impressive soft power and sophisticated information control regimes. That is why US made films that are shown in China often have to have different scenes in them - sometimes shot with different endings -- and there are strict limits. China has their own system of deboosting content and their own troll farms. Same for any kind of internet presence and also video games and other media. Likewise, the US has a sophisticated system of banning and other soft "deboosting" of views that run counter to official regime narratives. There is a whole industry to identify counter-narrative views and brand them as "misinformation" that must be rooted out. Russia has a much less sophisticated information space defense system for this, and much less soft power, so for them outright bans and blocks are the only viable option, and this was given to them by the West on a platter. Amazing self-own.
Seems the field of people that could get this stuff working (some really awesome hacking) is so small... or rather, breakthroughs come from a few individuals.
(100% biased :D)
Clang not supporting new C++ features actually have some quite far-reaching consequences, since editors nowadays heavily rely on clangd for autocompletion and static analysis, and they too will be stuck past in time.
Also it isn't even proprietary[1]
1. https://github.com/carbon-language/carbon-lang/blob/trunk/LI...
I think the possibility is that the Google engineers will do bugfixes for up to C++17 features but will minimize work on catching up to the latest standards (since it really takes up too much engineering effort, and Google seems to be conservative in using newer C++ features anyway and have opinions that differ from the standards.)
https://en.cppreference.com/w/cpp/compiler_support#cpp20 begs to differ. The heck, even C++23 core language support is almost fully done.
Don’t judge a book by the literal interpretation of its title?
So, at least from personal experience yes, it makes absolutely no sense to port to Linux, if the result is still worse than proton.
Regularly test under proton during development, and you got a Linux Version of your game for free. From my experience, epic already took good care to make sure unreal engine works well under proton, so if you just pick that and don't add a ton of additional stuff that uses esoteric winapi stuff, you're already set.
(In that sense, developers (or Linux porting studios) switching from their in-house compatibility layers to Proton isn't really a change in terms of those ports being 'truly native' or whatever.)
I wonder if what we're starting to see, rather than the inferiority of source ports, is actually that some of these alternative compatibility layers are just no longer keeping up with Proton, since Proton/WINE has such wide use/testing and rapid development these days.
We all know how that ended.
Another comparison that I think is more apt: "IBM PC Compatibles run IBM PC software better"
My fucking linux machine runs on intel hardware that is targeting an arch made by AMD (x86_64).
There is no problem with sharing stable interfaces. The idea that we should not treat these as linux games because they consume an interface developed by MS, that is implemented just fine by proton on linux is... very very backwards.
Who gives a flying fuck who made the interface, as it can be implemented across platforms, I'm a-ok with the result.
You don't have a compelling argument here - step back, pause, and consider whether you're having an emotional reaction.
Your argument is basically "Developers should do things I want, for my benefit, with no regards to the success or consequences of those actions".
And that's a pretty fucked up argument.
A much better argument is: Proton makes linux a compelling platform for gaming. There is a decent chunk of market segment that keeps Windows around only for gaming. Allowing those users to move entirely to linux increases the appeal of developing native gnu/linux games, because there is a much larger native market.
This is how interfaces work - they allow you to develop new products that are compatible with the existing userbase. It's why they're incredibly important as stepping stones.
---
Side note - Proton came out of codeweavers, codeweavers develop a custom version of Wine. Do you happen to know what Wine fucking stands for? hint:
Wine Is Not an Emulator.
These days they check both builds if available and suggest the devs which one to use by default; often the Windows builds over Proton are simply better than mediocre Linux support.
Shipping something on Android does not guarantee functional builds for regular Linux, and PlayStation uses a heavily customized FreeBSD fork. Neither of which are helpful for much of anything.
Android even more so, assuming those that rely only on AGK/NDK.
The magical thing is that they've done so much work with Proton that a device like the Steam Deck is more than a curiosity. It is a viable product. It is viable to play games on Linux in a way it has never been before. Even better, they aren't keeping it to themselves.
A purist ideology about linux isn't going to change reality. But Proton is. The Deck is a wildly popular device and the knock-on effect is going to be more systems running linux for regular people. The games may not be native but if they're indistinguishable from native games, then who cares? Meanwhile adoption of linux as a viable platform still goes up. Maybe on a long enough timeline things swing around, though I still very much doubt that.
The Year of Linux on the Desktop is still a fantasy, but reading the steam hardware survey, it is more true than it has ever been before, thanks to the Deck and Proton.
1. Make wine really really good.
2. Start adding Linux-only features.
hehehe
If Valve gets gaming studios to target proton and guarantee compatibility, is a win.
If that's equivalent to gaming studios explicitly targeting MAME and QAing it, I'll take it.
Anyway it hardly matches Switch sales, for which studios do actually bother to actively support.
Idk what the transition plan could look like, but eventually we should hope to see the Steam Deck treated like any other console with highly optimized, native ports, and then hopefully some of that can be reused for 'more native' general Linux ports.
Not to say the current implementation is secure though, only that the use of Wine/Proton makes no difference.