As dictatorships go, Valve is a mostly benevolent one. Steam is probably the least abusive and most social-good-increasing walled garden out there. Which admittedly isn’t saying too much, but their track record for violating the trust people put in them, while far from flawless, is remarkably clean compared to literally everyone else.
Conflict of interest disclaimer: I’ve been playing Baldur’s Gate 3 on linux and it runs better than on Windows, which is frankly black magic. I can think of a few different reasons this might be, most of which aren’t due to Proton, but I’ve been too busy enjoying the game to try to dig into the details.
For the record, complaints of BG3 Act 3 game performance (and struggling hardware does lead to more crashes) have been orthogonal to the platform the game is running on- Windows people complain about it just as much- I’m still just at the beginning of Act 2 myself due to having a 2 year old and also experiencing “character restart-itis” a few times after “irreconcilable” screwups, but my main gaming machine is a NixOS Linux machine (I can’t play Starfield yet, but that’s Starfield’s fault, it’s incompatible with the NVIDIA 535+ driver and I refuse to downgrade just for that game)
I just want to point our that Valve NEEDS to contribute/upstream. They don’t have the manpower and capacity to fork the Linux kernel and KDE (for example), make their SteamOS updates and then maintain & support everything. So they might look like good guys for doing this but it’s just good business to upstream.
At scale, if the public commons is larger than any one corporation’s pool of coders, then this could prevent corporations from entering into public spaces which are broadly populated by people.
We should try to replicate this interaction with other companies, forcing them to participate in a commons which outscales their internal engineering capabilities.
Arguably, most, most-significant open-source contributions actually come from paid employees of private companies: just look at the linux kernel, chromium/firefox, most big PL ecosystems.
This “lone wolf hacker” behind all of open-source hasn’t been true for decades, if ever.
I didn’t say that, though. Indeed, the ideal Free Software author would be supported by a commune, a communal fund, a co-op, or a commons (e.g. a hackerspace).
Based on how a former employer made it basically impossible to upstream patches, I suspect this behaviour is less common than you might expect. Managers don’t see the ongoing maintenance nightmare of trying to keep their patches on top of upstream, and some naively think their patches are assets rather than liabilities. And some, my former employer included, do even worse and just hold back their entire custom distro for a decade because nobody is tasked with keeping things up to date.
… by being funded via a heavy store tax from an eternally buggy mess of a proprietary app store whose main value add is their network effect, set of sketchy engagement APIs, DRM (as in ‘Digital Rights Management’ or ‘corporate sanctioned malware’ depending on your optics) mainly selling proprietary software.
Its main reasons for ‘contributing’ being part of a risk management strategy for breaking away and more directly competing with Microsoft, empowering specifically those FOSS projects that fits their narrative and promoting an architecture that is close to a carbon copy of its eventual end-game competitor. This time with more anti-cheat making its way should there be sufficient traction.
It is the Android story again on a smaller scale. How did that turn out last time, how many of the ‘contributions’ failed to generalise? or is it different this time because Valve is good because games? Colour me sceptic.
I think Valve as a company has a lot of problems (though the DRM is pretty mild and one of their lesser problems tbh) and the Steam Deck iffier of a product than people make it out to be, but they’re actually being a good citizen here. Yes, they’re funding the things relevant to them out of self-interest (i.e. case-insensitive FS, WaitForMultipleObjects API clone, HDR, Mesa work, etc.), but they’re working with upstreams like the kernel, Mesa, and freedesktop.org to get the work merged upstream, be properly reviewed by the people that work on it, and be usable for everyone else. Android never worked with upstreams until maintaining their own things in an opaquely developed fork became unsustainable.
(Sometimes I think they might be using a bit too much commodity - the Arch base of SteamOS 3 seems weird to me, especially since they’re throwing A/B root at it and using Flatpak for anything user visible…)
You only need mild DRM and DHCP for the intended barrier to entry, suppressive effect and legal instruments, anything more exotic is just to keep the hired blackhats happy.
If I’m going to be a bit more cynical - they are not going the FreeDesktop/Linux instead of Android/Linux route out of the goodness of their hearts as much as they simply lack access to enough capable system engineers of their own and the numbers left after Google then ODMs then Facebook/Meta then all the other embedded shops have had their fill aren’t enough to cover even the configuration management needs.
Take their ‘contributions’ in VR. Did we get even specs for the positioning system? activation / calibration for the HMD? or was that a multi-year expensive reversing effort trying to catch up and never actually being able to just to be able to freely tinker with hardware we payed for? that was for hardware they produced and sold in a time where open source wasn’t a hard sell by any means.
Did we get source code for the ‘Open’VR project that killed off others actually open ones? Nope, binary blob .so:s and headers. Ok, at least they followed the ID software beaten path of providing copyleft version of the iterations of the source engine so people can play around with ports, exploring rendering tech etc? Nope. If you have spotted the source on the ’hubs its because its a version that was stolen/leaked.
Surely the lauded SteamDeck was sufficiently opened and upstreamed into the kernel? Well not if you include the gamepad portions. It’s almost as if the contributions hit exactly that which fit their business case and happens to feed into the intended stack and little to nothing else. Don’t anthropomorphise the lawnmower and all that.
To me, it looks like Valve wanted to make a gaming console, and used Linux as a way to pull that off. If you’d told me 25 years ago that you’d be able to play Windows games on a Linux machine that was handheld, I’d have been blown away. To me it still seems almost miraculous. And they doing this while (as far as I know) fulfilling their obligations to the various licenses used in the Linux ecosystem.
Does the fact they’re doing this for commercial gain invalidate that?
I don’t know what you expected. They’re almost certainly not going to give you the crown jewels used to make the headset, but all the infrastructure work is far more useful as it benefits everyone, not just the people with a niche headset.
They patented and own the hardware, the binary blobs and sold the hardware devices at a hefty price tag. I’d expect for an average FOSS participant to integrate and enforce existing infrastructure and not vertically integrate a side band that locks you into their other products.
I own a Steamdeck for about a year now. No what idea why do people have problem with the size. My kids play on it and don’t complain, and we do have a Nintendo Switch (smaller) to compare. Sure it’s bigger, but I don’t think it’s a big deal. On top of it - with a dock, it works perfectly as a home console system, so the size matters even less.
I really enjoy it and recommend getting it if you’re thinking about it.
I don’t like the size and ergonomics. But I’m in the minority on that one; people with big hands especially seen to love it.
There are more abstract concerns regarding its place as a product (is it a PC or a console? whichever is more convenient to excuse a fault), but otherwise the device is a pretty good value. I just don’t game that much, and when I do, it’s a social thing.
It might have a problem depending on what input method you use. I have average sized hands and I like to use the trackpad for FPSes and strategy games. For the FPS case, reaching the trackpads and reaching the face buttons gets really annoying. You can map the grip buttons to the face buttons, but then you’re losing out there.
Even with big piano friendly hands the steamdeck ergonomics are hard. If you don’t have a big toy budget, testing someone else’s is highly recommended. I mostly use my three steamdecks for various debugging / UI / … experiments (nreal air glasses + dactyls and the deck tucked away somewhere). If Asus would be able to not be Asus for 5 minutes the ROG Ally would’ve been an easy winner for me.
I hacked mine to run Linux as I’ve done with all other devices I’ve used throughout the years, it didn’t boot WIndows once. As far as their ‘intentions’ - whatever laptops I have scattered, all of them came bundled with Windows ‘intended’ for that to be the used OS.
DSDT fixes and kernel config to get the Ally working was less effort than I had to do to get actual access to the controllers and sensors on the Steam Deck.
Fair enough. I admin RHEL for dayjob, and use Arch on my laptop, when getting SD I knew I’ll keep it more appliance-y than getting into fully custom OS. I just wanted something to play Persona 5 in bed.
It’s heavy. Significantly heavy. It took me a while to figure out how to use it in a way that didn’t quickly give me wrist fatigue/pain, and even now it’s not perfect.
Also Valve’s Deck Verified program is very flawed. It’s quite a bit better than nothing, but it’s flawed. The biggest (but not only) problem IMO is that a game that has a control scheme not optimized for controllers - but still fully supports controllers - can be marked Verified. As an example, Civ V and Civ VI both basically just use the trackpad like a mouse, and the other buttons have some random keybinds that are helpful. Now, those are basically keyboard-and-mouse games… so to a certain extent I totally get it. But I should be able to click into a list of things and use the joysticks or D-pad to scroll down the list. I can’t. Instead, I have to use the trackpad to position the cursor over the scroll bar, then hold right trigger, then scroll with my thumb. This is extremely unergonomic.
It’s heavy. Significantly heavy. It took me a while to figure out how to use it in a way that didn’t quickly give me wrist fatigue/pain, and even now it’s not perfect.
Right, it’s really chunky - I might use it more if they had a mini version. The only use for the portability is at home (i.e. on the porch). It’s not small enough I’d want to carry it in a bag if I commute, around town, or waiting for someone, and if I’m on vacation, the last thing I want to do is play video games instead of touch grass or spend time or people. If I really want to play a game, I’ll probably use the laptop I have (even if that restricts choice of game - because I have a Mac…). Again, not that much of a gamer, so it’s different values I guess.
I have normal sized male hands and my girlfriend has relatively small hands and both work very well. She was actually surprised how ergonomic the Steam Deck is given the size. Other than that I only got positive reactions to the ergonomics.
Right now you can install Steam on your regular desktop Linux system, throw in Lutris to get games from other stores and you are good to go. This has been so far the best year to turn your family into Linux users yet.
It is far from ideal, but still a great improvement. And if we manage to get up to – let’s say – 10% penetration in EU, this is going to help immensely to combat mandatory remote attestation and other totalitarian crap we are going to end up with if Microsoft, Apple and Google keep their almost absolute dominance.
I appreciate that both this comment and its parent make good points that are not necessarily in conflict. I would distill this as a call for “critical support” for Valve, to borrow a term from leftist politics.
I have to say that I have had far more luck managing non-Steam game installs within Steam (you can add an entry to it, with a path, and it will manage it as a Proton install if you’d like; you basically just use Steam as a launcher and Proton prefix manager) than via Lutris.
My opinion of Lutris is that it is a janky pile of hacked-together non-determinism which was developed over a long period of time over many, many versions of Wine, and over many, many GPU architectures and standards, and long before Proton existed… which miraculously may work for you, although often will require expert hand-holding. Avoid if you are new to Linux.
Their improvements to proton/wine have made it so I could go from loading windows once a day to play games to loading it once a month to play specific games. Like all other for-profit companies their motives are profit driven, but so far they are contributing in ways that are beneficial and compatible with the broader Linux ecosystem. Unlike Microsoft, Oracle, Google, and Amazon they don’t have incentive to take over a FOSS project, they just don’t want to rely on Windows. But we should always keep an eye out.
Getting games to work by default on Linux also makes it much easier for people interested in Linux to try it out and people not interested to use it when convenient, which is a win in my book.
Did you look at the slides or watch the video of the talk? All their contributions are upstreamed and applicable to more than just their usecase. Everything is available on Arch as well (before SteamOS was released they actually recommend Manjaro, because they are so similar). You can use Proton for the Epic games store or other Windows apps. Of course they are doing this in self interest, but according to Greg Kroah Hartman and a lot of other kernel maintainers this isn’t a bad thing.
The Steam Deck is first „real“ consumer Linux computer which has been sold over a million times. I hope more Linux handhelds are being released in the coming years :)
The obvious irony here is that is in Valve’s best interest for their stuff to be upstreamed. It’s not like they can fork KDE (for example since it’s used by SteamOS) and maintain & support their own fork.
I’m not sure about making ext4 filesystems case-insensitive. Seems like it would break a lot of things. The LWN article https://lwn.net/Articles/784041/ linked from that slide has a comment I can relate to: “I’ve yet to see a legitimate use case for putting this brain damage in the kernel. Does anyone actually have one?”
The use case is “run software that was written for a case-insensitive world, that you can’t recompile”. Android has a similar issue because it started off initially with FAT “external storage” (SD cards), and then it moved the external storage internal, but a lot of apps already existed that assumed that storage would behave like FAT.
First they mitigated the problem by putting a FUSE layer on top of ext4 or F2FS to give case-insensitive semantics to a directory tree — which works but it sucks. Bad enough that you get the overhead of FUSE on everything, but whenever an open or stat or anything would return “not found”, the driver has to do an opendir on the containing directory, read the entire contents, and check whether something would match case-insensitively. That can kill performance fast.
Their next approach was something called SDCardFS, which was basically the same thing except in-kernel. Most of the same problems, except faster because it didn’t have to speak the FUSE protocol and didn’t have so much user->kernel->user->kernel bouncing.
SDCardFS was also subject to TOCTOU races that might let you, say, create two files with names that differ only by case (I’m not clear on whether the FUSE implementation did or didn’t have the same issue — it may have serialized things enough to avoid the problem “by accident” just by having crap performance).
Finally, they just got per-directory case-insensitivity added to F2FS and moved everything over to that. Implementing it in the filesystem itself means you can have efficient access (just case-fold before you do your btree lookup or whatever) and no races.
Valve’s use-case is, of course, running Windows games, which almost universally assume case-insensitivty.
There is another option for case-insensitivity, which is to just make sure that all files on the native filesystem are casefolded (e.g. all lower case). Then you don’t need extra directory searches. But it breaks the “case-insensitive, case-preserving” assumption, and it also breaks down if the user has any way to get direct access to the underlying filesystem and create non-casefolded files.
Case insensitivity opens up a whole lot of bizarre bugs, not-bugs, and, potentially, avenues for attack, where ‘not-bugs’ are surprising results which are completely correct per the specifications and languages involved but which can cause errors nonetheless.
Not sure. He didn’t seem to say much more than what was written in the slide how adding it to ext4 is the fast solution compared to implementing it in Wine.
Knowing nothing about Wine, I wonder if maybe the Windows application would get its own isolated ext4 file system with the case-insensitivity property? That way there’s less chance of collateral damage to the rest of the system trying to enhance compatibility for the Windows application.
The case-insensitivity property is set on a directory and affects everything under that directory. It’s not filesystem-wide (unless you set it at the root of a filesystem, of course).
Also it can only be set on a directory while it’s empty, so that there’s no question of what to do if there are pre-existing files that would clash.
The case sensitive filesystem problem is serious IMHO. Every modern OS should decide on one or the other (I vote for case sensitivity) and work to get to it. This is much worse than the line-ending-difference problem because it’s fundamentally not mitigatable:
Moving a file from a case insensitive filesystem to a case sensitive one will fail to collide with a file that it should collide with (from the base assumptions of the insensitive filesystem).
Moving a file from a case sensitive filesystem to a case insensitive one will cause file collisions that didn’t exist on the source filesystem.
Short of mapping all uppercase characters to an equivalently looking (but different) UTF-8 glyph, thus forcing an uppercased filename to look the same (to us) but be different (to the filesystem) even on a case insensitive filesystem, I can’t think of a good workaround here that doesn’t result in lopsided work by the “losing” filesystem design (and even this assumes UTF-8 is a supported character set in the relevant filesystem(s)).
As dictatorships go, Valve is a mostly benevolent one. Steam is probably the least abusive and most social-good-increasing walled garden out there. Which admittedly isn’t saying too much, but their track record for violating the trust people put in them, while far from flawless, is remarkably clean compared to literally everyone else.
Conflict of interest disclaimer: I’ve been playing Baldur’s Gate 3 on linux and it runs better than on Windows, which is frankly black magic. I can think of a few different reasons this might be, most of which aren’t due to Proton, but I’ve been too busy enjoying the game to try to dig into the details.
[Comment removed by author]
For the record, complaints of BG3 Act 3 game performance (and struggling hardware does lead to more crashes) have been orthogonal to the platform the game is running on- Windows people complain about it just as much- I’m still just at the beginning of Act 2 myself due to having a 2 year old and also experiencing “character restart-itis” a few times after “irreconcilable” screwups, but my main gaming machine is a NixOS Linux machine (I can’t play Starfield yet, but that’s Starfield’s fault, it’s incompatible with the NVIDIA 535+ driver and I refuse to downgrade just for that game)
can confirm that BG3 is also janky as all hell on windows
I fail to see what Steam has to do with BG3 crashes.
I just want to point our that Valve NEEDS to contribute/upstream. They don’t have the manpower and capacity to fork the Linux kernel and KDE (for example), make their SteamOS updates and then maintain & support everything. So they might look like good guys for doing this but it’s just good business to upstream.
Previously, on Lobsters, I said:
We should try to replicate this interaction with other companies, forcing them to participate in a commons which outscales their internal engineering capabilities.
Arguably, most, most-significant open-source contributions actually come from paid employees of private companies: just look at the linux kernel, chromium/firefox, most big PL ecosystems.
This “lone wolf hacker” behind all of open-source hasn’t been true for decades, if ever.
I didn’t say that, though. Indeed, the ideal Free Software author would be supported by a commune, a communal fund, a co-op, or a commons (e.g. a hackerspace).
Concur. In an earlier talk at the same event, Jonathan Corbet said something I interpreted as much the same, albeit couched very democratically.
I wrote about his talk, explicating this somewhat in the comments.
FWIW I also wrote about the talk this thread is about:
Linux interop is maturing fast… thanks to a games console.
That’s where I found about this. But El Reg links are banned from submission here.
yeah, i tried to submit to lobsters before i submitted to hackernews and got the banned sign so i gave up. good on you for submitting an alt link :)
Based on how a former employer made it basically impossible to upstream patches, I suspect this behaviour is less common than you might expect. Managers don’t see the ongoing maintenance nightmare of trying to keep their patches on top of upstream, and some naively think their patches are assets rather than liabilities. And some, my former employer included, do even worse and just hold back their entire custom distro for a decade because nobody is tasked with keeping things up to date.
… by being funded via a heavy store tax from an eternally buggy mess of a proprietary app store whose main value add is their network effect, set of sketchy engagement APIs, DRM (as in ‘Digital Rights Management’ or ‘corporate sanctioned malware’ depending on your optics) mainly selling proprietary software.
Its main reasons for ‘contributing’ being part of a risk management strategy for breaking away and more directly competing with Microsoft, empowering specifically those FOSS projects that fits their narrative and promoting an architecture that is close to a carbon copy of its eventual end-game competitor. This time with more anti-cheat making its way should there be sufficient traction.
It is the Android story again on a smaller scale. How did that turn out last time, how many of the ‘contributions’ failed to generalise? or is it different this time because Valve is good because games? Colour me sceptic.
I think Valve as a company has a lot of problems (though the DRM is pretty mild and one of their lesser problems tbh) and the Steam Deck iffier of a product than people make it out to be, but they’re actually being a good citizen here. Yes, they’re funding the things relevant to them out of self-interest (i.e. case-insensitive FS, WaitForMultipleObjects API clone, HDR, Mesa work, etc.), but they’re working with upstreams like the kernel, Mesa, and freedesktop.org to get the work merged upstream, be properly reviewed by the people that work on it, and be usable for everyone else. Android never worked with upstreams until maintaining their own things in an opaquely developed fork became unsustainable.
(Sometimes I think they might be using a bit too much commodity - the Arch base of SteamOS 3 seems weird to me, especially since they’re throwing A/B root at it and using Flatpak for anything user visible…)
You only need mild DRM and DHCP for the intended barrier to entry, suppressive effect and legal instruments, anything more exotic is just to keep the hired blackhats happy.
If I’m going to be a bit more cynical - they are not going the FreeDesktop/Linux instead of Android/Linux route out of the goodness of their hearts as much as they simply lack access to enough capable system engineers of their own and the numbers left after Google then ODMs then Facebook/Meta then all the other embedded shops have had their fill aren’t enough to cover even the configuration management needs.
Take their ‘contributions’ in VR. Did we get even specs for the positioning system? activation / calibration for the HMD? or was that a multi-year expensive reversing effort trying to catch up and never actually being able to just to be able to freely tinker with hardware we payed for? that was for hardware they produced and sold in a time where open source wasn’t a hard sell by any means.
Did we get source code for the ‘Open’VR project that killed off others actually open ones? Nope, binary blob .so:s and headers. Ok, at least they followed the ID software beaten path of providing copyleft version of the iterations of the source engine so people can play around with ports, exploring rendering tech etc? Nope. If you have spotted the source on the ’hubs its because its a version that was stolen/leaked.
Surely the lauded SteamDeck was sufficiently opened and upstreamed into the kernel? Well not if you include the gamepad portions. It’s almost as if the contributions hit exactly that which fit their business case and happens to feed into the intended stack and little to nothing else. Don’t anthropomorphise the lawnmower and all that.
To me, it looks like Valve wanted to make a gaming console, and used Linux as a way to pull that off. If you’d told me 25 years ago that you’d be able to play Windows games on a Linux machine that was handheld, I’d have been blown away. To me it still seems almost miraculous. And they doing this while (as far as I know) fulfilling their obligations to the various licenses used in the Linux ecosystem.
Does the fact they’re doing this for commercial gain invalidate that?
I don’t know what you expected. They’re almost certainly not going to give you the crown jewels used to make the headset, but all the infrastructure work is far more useful as it benefits everyone, not just the people with a niche headset.
They patented and own the hardware, the binary blobs and sold the hardware devices at a hefty price tag. I’d expect for an average FOSS participant to integrate and enforce existing infrastructure and not vertically integrate a side band that locks you into their other products.
What’s iffy about the Steamdeck? I’ve considered buying it but haven’t pulled the trigger yet.
I own a Steamdeck for about a year now. No what idea why do people have problem with the size. My kids play on it and don’t complain, and we do have a Nintendo Switch (smaller) to compare. Sure it’s bigger, but I don’t think it’s a big deal. On top of it - with a dock, it works perfectly as a home console system, so the size matters even less.
I really enjoy it and recommend getting it if you’re thinking about it.
As an owner of both, Steam Deck is quite heavier than Switch, and could have used an OLED screen.
I don’t like the size and ergonomics. But I’m in the minority on that one; people with big hands especially seen to love it.
There are more abstract concerns regarding its place as a product (is it a PC or a console? whichever is more convenient to excuse a fault), but otherwise the device is a pretty good value. I just don’t game that much, and when I do, it’s a social thing.
Thanks. Now I have to consider the size of my hands in relation to other people’s, something I understand can be fraught.
FWIW, I have small hands (I joke they are “surgeon’s hands”) and I don’t have a problem with the SD.
It might have a problem depending on what input method you use. I have average sized hands and I like to use the trackpad for FPSes and strategy games. For the FPS case, reaching the trackpads and reaching the face buttons gets really annoying. You can map the grip buttons to the face buttons, but then you’re losing out there.
Even with big piano friendly hands the steamdeck ergonomics are hard. If you don’t have a big toy budget, testing someone else’s is highly recommended. I mostly use my three steamdecks for various debugging / UI / … experiments (nreal air glasses + dactyls and the deck tucked away somewhere). If Asus would be able to not be Asus for 5 minutes the ROG Ally would’ve been an easy winner for me.
And you wouldn’t consider Ally’s intended OS a problem?
I hacked mine to run Linux as I’ve done with all other devices I’ve used throughout the years, it didn’t boot WIndows once. As far as their ‘intentions’ - whatever laptops I have scattered, all of them came bundled with Windows ‘intended’ for that to be the used OS.
DSDT fixes and kernel config to get the Ally working was less effort than I had to do to get actual access to the controllers and sensors on the Steam Deck.
Fair enough. I admin RHEL for dayjob, and use Arch on my laptop, when getting SD I knew I’ll keep it more appliance-y than getting into fully custom OS. I just wanted something to play Persona 5 in bed.
It’s heavy. Significantly heavy. It took me a while to figure out how to use it in a way that didn’t quickly give me wrist fatigue/pain, and even now it’s not perfect.
Also Valve’s Deck Verified program is very flawed. It’s quite a bit better than nothing, but it’s flawed. The biggest (but not only) problem IMO is that a game that has a control scheme not optimized for controllers - but still fully supports controllers - can be marked Verified. As an example, Civ V and Civ VI both basically just use the trackpad like a mouse, and the other buttons have some random keybinds that are helpful. Now, those are basically keyboard-and-mouse games… so to a certain extent I totally get it. But I should be able to click into a list of things and use the joysticks or D-pad to scroll down the list. I can’t. Instead, I have to use the trackpad to position the cursor over the scroll bar, then hold right trigger, then scroll with my thumb. This is extremely unergonomic.
Right, it’s really chunky - I might use it more if they had a mini version. The only use for the portability is at home (i.e. on the porch). It’s not small enough I’d want to carry it in a bag if I commute, around town, or waiting for someone, and if I’m on vacation, the last thing I want to do is play video games instead of touch grass or spend time or people. If I really want to play a game, I’ll probably use the laptop I have (even if that restricts choice of game - because I have a Mac…). Again, not that much of a gamer, so it’s different values I guess.
I have normal sized male hands and my girlfriend has relatively small hands and both work very well. She was actually surprised how ergonomic the Steam Deck is given the size. Other than that I only got positive reactions to the ergonomics.
Right now you can install Steam on your regular desktop Linux system, throw in Lutris to get games from other stores and you are good to go. This has been so far the best year to turn your family into Linux users yet.
It is far from ideal, but still a great improvement. And if we manage to get up to – let’s say – 10% penetration in EU, this is going to help immensely to combat mandatory remote attestation and other totalitarian crap we are going to end up with if Microsoft, Apple and Google keep their almost absolute dominance.
I appreciate that both this comment and its parent make good points that are not necessarily in conflict. I would distill this as a call for “critical support” for Valve, to borrow a term from leftist politics.
I have to say that I have had far more luck managing non-Steam game installs within Steam (you can add an entry to it, with a path, and it will manage it as a Proton install if you’d like; you basically just use Steam as a launcher and Proton prefix manager) than via Lutris.
My opinion of Lutris is that it is a janky pile of hacked-together non-determinism which was developed over a long period of time over many, many versions of Wine, and over many, many GPU architectures and standards, and long before Proton existed… which miraculously may work for you, although often will require expert hand-holding. Avoid if you are new to Linux.
There is also the Heroic Games Launcher, which I would also recommend over Lutris: https://heroicgameslauncher.com/
Noted. But I have personally had zero issues and the ability to download and install GOG games is hard to replicate in Steam.
Their improvements to proton/wine have made it so I could go from loading windows once a day to play games to loading it once a month to play specific games. Like all other for-profit companies their motives are profit driven, but so far they are contributing in ways that are beneficial and compatible with the broader Linux ecosystem. Unlike Microsoft, Oracle, Google, and Amazon they don’t have incentive to take over a FOSS project, they just don’t want to rely on Windows. But we should always keep an eye out.
Getting games to work by default on Linux also makes it much easier for people interested in Linux to try it out and people not interested to use it when convenient, which is a win in my book.
Did you look at the slides or watch the video of the talk? All their contributions are upstreamed and applicable to more than just their usecase. Everything is available on Arch as well (before SteamOS was released they actually recommend Manjaro, because they are so similar). You can use Proton for the Epic games store or other Windows apps. Of course they are doing this in self interest, but according to Greg Kroah Hartman and a lot of other kernel maintainers this isn’t a bad thing. The Steam Deck is first „real“ consumer Linux computer which has been sold over a million times. I hope more Linux handhelds are being released in the coming years :)
How dare they upstream improvements because of their malicious profit driven motivations!
The obvious irony here is that is in Valve’s best interest for their stuff to be upstreamed. It’s not like they can fork KDE (for example since it’s used by SteamOS) and maintain & support their own fork.
I don’t see why they couldn’t fork KDE? I see many reasons why they’d prefer not to.
Video of the talk.
I’m not sure about making ext4 filesystems case-insensitive. Seems like it would break a lot of things. The LWN article https://lwn.net/Articles/784041/ linked from that slide has a comment I can relate to: “I’ve yet to see a legitimate use case for putting this brain damage in the kernel. Does anyone actually have one?”
The use case is “run software that was written for a case-insensitive world, that you can’t recompile”. Android has a similar issue because it started off initially with FAT “external storage” (SD cards), and then it moved the external storage internal, but a lot of apps already existed that assumed that storage would behave like FAT.
First they mitigated the problem by putting a FUSE layer on top of ext4 or F2FS to give case-insensitive semantics to a directory tree — which works but it sucks. Bad enough that you get the overhead of FUSE on everything, but whenever an
openorstator anything would return “not found”, the driver has to do anopendiron the containing directory, read the entire contents, and check whether something would match case-insensitively. That can kill performance fast.Their next approach was something called SDCardFS, which was basically the same thing except in-kernel. Most of the same problems, except faster because it didn’t have to speak the FUSE protocol and didn’t have so much user->kernel->user->kernel bouncing.
SDCardFS was also subject to TOCTOU races that might let you, say, create two files with names that differ only by case (I’m not clear on whether the FUSE implementation did or didn’t have the same issue — it may have serialized things enough to avoid the problem “by accident” just by having crap performance).
Finally, they just got per-directory case-insensitivity added to F2FS and moved everything over to that. Implementing it in the filesystem itself means you can have efficient access (just case-fold before you do your btree lookup or whatever) and no races.
Followups:
Valve’s use-case is, of course, running Windows games, which almost universally assume case-insensitivty.
There is another option for case-insensitivity, which is to just make sure that all files on the native filesystem are casefolded (e.g. all lower case). Then you don’t need extra directory searches. But it breaks the “case-insensitive, case-preserving” assumption, and it also breaks down if the user has any way to get direct access to the underlying filesystem and create non-casefolded files.
Case insensitivity opens up a whole lot of bizarre bugs, not-bugs, and, potentially, avenues for attack, where ‘not-bugs’ are surprising results which are completely correct per the specifications and languages involved but which can cause errors nonetheless.
Not sure. He didn’t seem to say much more than what was written in the slide how adding it to ext4 is the fast solution compared to implementing it in Wine.
Knowing nothing about Wine, I wonder if maybe the Windows application would get its own isolated ext4 file system with the case-insensitivity property? That way there’s less chance of collateral damage to the rest of the system trying to enhance compatibility for the Windows application.
The case-insensitivity property is set on a directory and affects everything under that directory. It’s not filesystem-wide (unless you set it at the root of a filesystem, of course).
Also it can only be set on a directory while it’s empty, so that there’s no question of what to do if there are pre-existing files that would clash.
The case sensitive filesystem problem is serious IMHO. Every modern OS should decide on one or the other (I vote for case sensitivity) and work to get to it. This is much worse than the line-ending-difference problem because it’s fundamentally not mitigatable:
Moving a file from a case insensitive filesystem to a case sensitive one will fail to collide with a file that it should collide with (from the base assumptions of the insensitive filesystem).
Moving a file from a case sensitive filesystem to a case insensitive one will cause file collisions that didn’t exist on the source filesystem.
Short of mapping all uppercase characters to an equivalently looking (but different) UTF-8 glyph, thus forcing an uppercased filename to look the same (to us) but be different (to the filesystem) even on a case insensitive filesystem, I can’t think of a good workaround here that doesn’t result in lopsided work by the “losing” filesystem design (and even this assumes UTF-8 is a supported character set in the relevant filesystem(s)).