First and foremost, Steam is a cross-platform proprietary code base that uses an in-house developed UI framework. You are effectively asking for Steam's UI to be reimplemented from scratch on all target OSes, not only Linux. It is at their discretion what design choices are implemented in their software. If you don't like it, make your own software distribution platform and compete.
This type of rant is actively disruptive to issue trackers. There are multiple unrelated issues, all which need to be addressed separately. While you have a claim to the contrary, you make thinly veiled insults to the devs involved and you have setup the grounds of a PR nightmare to any dev that would attempt to close out this issue report. This is simply unacceptable behavior in my opinion.
Beyond that, I personally gave warning that the steam runtime was going to become a problem over time and have happily chosen not use it for several years. Valve has never claimed cross-platform compatibility and has for the most part been receptive to concise and actionable issue reports.
Note: In the interest of keeping this civil, I will not be making any further responses.
You don't seem to quite have a grasp on Valve, software development on Linux, or this tracker. Could they do better, yes? This is not a bug, and should be on SteamCommunity, not here. Valve has their own bug tracker, internally. Valve is Valve, e.g. Valve Time. They only officially support Ubuntu, and yes I know even then there are issues. I use Steam on Arch Linux, Debian, SteamOS, and Ubuntu with no issues. That is not saying I wouldn't have any or just don't have a use-case like others that make an issue apparent, but it's not this "chicken little" situation this post implies.
Steam is not open source, so there isn't much distro maintainers can do to help things, beyond working around the runtime (if needed), and tweaking any scripts around the Steam client. Your other suggestions move more into the Steam Client being rewritten not just for Linux, but other platforms, a huge task. The Steam runtime does need tweaking, but rant posts like this here don't do much to help a situation. It doesn't help that there are many, many duplicate posts because no one bothers to search for their issue first. As I said above, GitHub is not the primary tracker for them, as they (as i've heard) use their own internal tracker. Thank Zeus folks actually use the issue template fields I submitted as a PR for this and SteamOS trackers.
We're aware of the issues with the runtime and are exploring alternative ways to set it up that would limit issues. Beyond that, folks are correct that the broader philosophical discussion has no place here and the forums would be a better place for it.
I can see your points, and I realize that this is not meant to be a channel for people to rant about. But I feel you are completely missing mine, and people have been dodging the issue because things were “good enough.” I wouldn’t be getting anywhere by posting this in one of the actual community channels. Signal-to-noise ratio is simply too bad in those places. This is not about the runtime. It’s not about Valve spending a huge amount of effort just to make me happy. It’s about moving things forward and staying on the ball in the long term.
I realize Steam is using an in-house proprietary UI framework, but I’m also saying this is a mistake, whether it is still there for historical reasons or not. But, as you’ve said (and as I’ve explained), it takes a mammoth effort to fix this, and only Linux is affected in any way, hence I can see that it’s not realistic for Valve to do so. That’s exactly why I suggest making the Linux community, which is full of experienced developers, fix it instead. For free. The only part Valve has to do for that is to release documentation and an API with the bare minimum of functionality to provide Steam services; the UI is completely out of the picture, as is most platform-specific code. That is not nearly as much effort as maintaining Steam in its current form on another platform, especially long-term. It however means losing absolute control over the user experience. Sounds bad, but maybe it really isn’t.
I accept your response, and I will avoid such posts in the future. Sorry about wasting your time.
Nothing extracted yet.
This is the only real problem with Steam on Linux. It’s not the software, it’s how Valve is treating Linux users. The software being barely usable is merely one of the end results.
There are many issues on this tracker alone (i.e. someone bothered to report them) that could be fixed within minutes (some only require recompiling Steam with no changes to the code!), but that’s impossible for the community because it does not have access to the source code. This is unlikely to change because that’s not how the real world works, so it’s up to Valve to fix these—which is clearly not happening. The way Steam works on Linux (it really doesn’t), it’s unsurprising that it never took off even within the small Linux community. I often find myself not playing, let alone buying games because I’d have to run Steam, and that has nothing to do with it being proprietary—it’s simply a frustrating experience, even compared to Wine!
Judging by the amount of time its port took and its behavior alone, it is very apparent that the Steam client is a horrible mess of badly maintained code that was never meant to run cross-platform. I do not wish to insult anyone here; I am simply stating an obvious fact. Since Valve does not appear to be interested in maintaining this beast on a tiny, insignificant and also very fragmented platform such as the Linux desktop (and I really don’t blame them), here’s my suggestion, or in other words, how Valve should have done things from the beginning:
First of all, porting a real desktop application like Steam may be much harder than porting a game. It has to interact with many parts of the system which can be different from user to user (proven by the fact that Steam does not work with less popular window managers, for example), whereas for games you generally only have a few stable, cross-platform APIs/ABIs to care about (mainly SDL, OpenAL, OpenGL, libc). It’s like consoles vs. Windows PCs, except you’re playing on Hard Mode. Linux is often called a moving target because of that, and it makes maintaining a proprietary application properly extremely difficult if you want to retain cross-distro compatibility. But it could be so easy if you stopped treating Linux like just another platform!
The key to supporting modern Linux is not supporting Linux. You have to support the community because that’s what Linux is: a community effort. They’re not just consumers; they’ll work for it if you give them the tools. I would call everything else wrong and inefficient. Didn’t Valve claim several times in bold letters that it’s all about enabling the gaming community to create new content? Well what about the Linux community? I’m sure they don’t really mind not getting official “support” if they get to fix it themselves.
Valve attempts to provide “the same” experience to users of all platforms. This however is less than optimal even when it works, since the Steam client is very unresponsive and sticks out like a sore thumb. I think it’s safe to say Linux users have very different views on UX/UI than whoever came up with this (and I bet many of them just want to play their damn games and don’t actually care for any of Steam’s features), so, in my opinion, coming up with a client that integrates well with their favorite environment should be left to them.
Hence, Valve should isolate the parts of Steam that are necessary to write a functional client into a set of libraries, publish API documentation for it, and explicitly allow third parties to redistribute it in order to make packaging easier. To be clear, the code in this SDK may be proprietary. If possible, things like filesystem access should not be part of it (see ValveSoftware/Source-1-Games#1685 for example); it should be as platform-independent as possible. Use open-source glue code if necessary. I can’t say how much effort is required to achieve this, but if it is too much, that just proves Valve’s greed, lack of commitment and inability to handle cross-platform development.
Then, the community should use the SDK to write a new cross-platform Steam client from scratch (please, dear community, don’t start a dozen different projects with different goals—make one that works first, preferably using Qt Quick). This way, Valve will only have to maintain the proprietary magic (which can be shared with other platforms and the official clients) and maybe respond to feedback on its API. The official client should be phased out once there is a reasonably mature replacement (it doesn’t have to be feature-complete).
The Steam Runtime should be retired, and games should stop bundling libraries like libstdc++. It may be an attempt at making Linux easier to target, but if you ask me (and the issue tracker), it causes more problems than it solves. It should be up to distributions to package library versions that are compatible with Steam and its games. For the reasons outlined above, games are usually far less problematic than the Steam client itself, so this issue will be much smaller than it appears. In fact, maybe that will give upstream some incentive to fix their ABI mess?
Who knows, maybe the open-source client actually ends up implementing all the official functionality on all supported platforms so that it could be adopted by Valve? Maybe I’m overly optimistic, but I think it’s possible.
TL;DR Valve should enable the Linux community to take care of things by itself, and reap the benefits.