HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
ValveSoftware
steam-for-linux
Systems & Infrastructure2012–2026
ValveSoftware / steam-for-linux

steam-for-linux

Issue tracking for the Steam for Linux beta client

63Distinct people
71Mentions
2Explicit recommenders
4.9KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Issue tracking for the Steam for Linux beta client

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

This is cool, I've used curses UIs to build various small things that need to be a) vaguely easy to use (so, complicated CLIs are out. oncalls need to be able to use this at…

atomicnumber3 used a recommendation phrase. 2 indexed comments match. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 3:30:57 AM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year71 dated mentions

Observed mentions: 2012-12-20 00:27:43 UTC to 2026-04-16 20:26:26 UTC.

0369122012-01-01 00:00:00 UTC to 2013-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20122013-01-01 00:00:00 UTC to 2014-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 8 mentions; 1 submissions, 7 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 7 mentions; 0 submissions, 7 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 7 mentions; 2 submissions, 5 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 8 mentions; 3 submissions, 5 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 12 mentions; 0 submissions, 12 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 6 mentions; 0 submissions, 6 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 7 mentions; 0 submissions, 7 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 4 mentions; 1 submissions, 3 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20122012-01-01 00:00:00 UTC2013-01-01 00:00:00 UTC101
20132013-01-01 00:00:00 UTC2014-01-01 00:00:00 UTC101
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC000
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC817
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC707
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC725
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC202
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC835
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC12012
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC606
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC707
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC413
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC404
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC312
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC101

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
Steam for Linux Client This is the README for the Steam for Linux client. Hardware and Software Requirements Steam for Linux stable client requirements are as follows: OS: Latest Ubuntu or Ubuntu LTS with a 64-bit (x86_64, AMD64) Linux kernel Older Ubuntu LTS branches are not supported and may stop working in a future Steam release, especially the branches in ESM status (Ubuntu 18.04 or older). Processor: 1GHz Pentium 4 or AMD Opteron equivalent or better Any x86_64 / AMD64 CPU with support for the CMPXCHG16B and SSE3 instruction sets Memory: 512 MB RAM Graphics: Any NVIDIA / AMD / Intel Requires latest 64-bit (x86_64, AMD64) and 32-bit (i386, IA32) graphics drivers. Install them using sudo ubuntu-drivers autoinstall. Storage: 5 GB available space Additional Notes: Requires internet connection for initial installation Requires 64-bit (x86_64, AMD64) and 32-bit (i386, IA32) glibc Starting from 2025-08-15, glibc 2.31 or newer will be required. This affects users of older distributions such as Debian 10, RHEL/CentOS 8, Slackware 14.x, Ubuntu 18.04. For a list of requirements for the current beta client, please see README.beta.md Getting Started Install Steam for Linux client: Download the steam_latest.deb package from this location. Navigate to the directory containing steam_latest.deb and double-click it. This launches Ubuntu Software Center and installs the package. If you prefer to install from the command-line, use gdebi. Install the gdebi-core package (apt install gdebi-core) and then install the Steam for Linux package (gdebi steam_latest.deb). For a list of games supported by Steam for Linux either visit this page or click Store (from the client) and then the Linux tab on the far-right. We recommend that you join the Steam for Linux official game group, located here. You will find future beta announcements and other information posted here as well as an active discussion forum. Reporting Issues If you encounter an issue with Steam for Linux, first search the issue list to see if it has already been reported. Include closed issues in your search. For issues with: Source-based games (HL2:DM, HL2, HL2:EP1, HL2:EP2, TF2, DoD:S, CS:S), visit our Source Issue List GoldSrc-based games (HL, HL:BS, HL:OF, TFC, DoD, DMC, CS, CS:CZ or Ricochet), visit our Half-Life Issue List Portal 2, visit our Portal 2 Issue List CS:GO, visit our CS:GO Issue List Games using Proton, visit our Proton Issue List If it has not been reported, create a new issue with the following information: a short, descriptive title; a detailed description of the issue, including any output from the command line; steps for reproducing the issue; and your system information. Please place logs either in a code block (go here for a GFM cheat sheet) or a gist. When possible, please include a differential between a working configuration and the reported issue. If a crash is involved, please include any CrashIDs or minidumps related to the issue in an archive. Archives can be drag and dropped into the text box of github. For tracking purposes, there should be one issue per issue report. System Information System information can be gathered from within steam (Help -> System Information). Once your information appears: right-click within the dialog, choose Select All, right-click again, and then choose Copy. Paste this information into a gist and include a link to it from your bug report. Conduct There are basic rules of conduct that should be followed at all times by everyone participating in the discussions. While this is generally a relaxed environment, please remember the following: Do not insult, harass, or demean anyone. Do not intentionally multi-post an issue. Do not use ALL CAPS when creating an issue report. Do not repeatedly update an open issue remarking that the issue persists. Remember: Just because the issue you reported was reported here does not mean that it is an issue with Steam. Also, should your issue not be resolved immediately, it does not mean that a resolution is not being researched or tested. Patience is always appreciated.
Read the full README on GitHub

What Hacker News says

6 sources
Personally I've had no end of problems using an nvidia GPU on Linux. For example, some driver packages support Steam but not CUDA, while others support CUDA but not Steam [1, 2]. And I found some instructions online that let me "fix" it to work with both - but thereafter, any time I used CUDA I would lose audio when I next resumed from suspend. [1] https://www.reddit.com/r/linux_gaming/comments/ocuqtm/can_i_... [2] https://github.com/ValveSoftware/steam-for-linux/issues/5778
In Steam survey shows Linux marketshare hitting 1.0%
I think your mistake was that you failed to account for the cultural differences between Windows and Linux users. For most Linux users and Developers a bug report is a positive thing rather than just a cost. Linux users are used to being more involved in the bug reporting process, and that includes reporting issues early and with more details - often even things they already figured out how to fix for themselves. If you are being overwhelmed by bug reports from Linux users the Solution is to let those users triage, categorize and maybe even fix issues amongst themselves by having a publicly acessible tracker. Just like with forums for your game, you might even find people that will moderate those bug trackers for you. Valve realized this early in the Steam for Linux beta and have been using GitHub issues [0] for all of their Linux ports.
Read the rest
As for the differences between Linux distributions, I think the concerns are greatly overblown. The biggest difference between Desktop Linux distributions boils down in the versions of various libraries that they ship. For most of those you don't need to care at all and should ship your own version (or use the Steam Linux Runtime [1]). Base system libraries (glibc, OpenGL, Vulkan, audio) that you can't ship (because they contain hardware specific code that needs to get updates even after your game is EOL, or for other reasons) tend to provide strong backwards compatibility so you only need to target an old enough version to cover all the Linux distributions you want to support. A complicated one is the C++ standard library since some graphics drivers will depend on that - I recomment statically linkingyour own version and not exporting/importing any C++ symbols in your program. I agree with others here that it is fine to only guarantee support for a limited set of Linux distributions (e.g. current Ubuntu LTS). However you should not consider reports from other distributions as a nuisance but rather as an early warning system or "linter" that will let you know about potential problems that users on your supported distribution (or even your users on other operating systems) may encounter in the future. Next you can have various windowing systems, window managers and audio systems (even on one Distribution). Just ignore those: Don't interface directly with Xlib or pulseaudio but instead use a proven abstraction that takes care of the different quirks for you: SDL. That is, assuming you are not already using an engine with mature Linux support. Even if there is a quirk not handled in SDL, your users now are empowered to debug SDL themselves and fix the issue there, benefitting everyone. SDL will also make it easier to support future systems: if you never talk to Xlib and GLX directly, SDL can give you Wayland support for free. Finally you have drivers. This isn't really much different than under Windows. Like with Linux distributions, issues with one driver often point towards things that just happen to work correctly in another vendor's driver but could break in the future. Having testing on more drivers is a good thing. Compared to Windows however, there is one big advantage: With the exception of Nvidia (and the proprietary AMD driver, but no need to care about that one) you (and savy users) have full source access to those which makes debugging some issues a lot more feasible. But further than that, they are also developed in the open with a public bug tracker [3] which gives you direct access to the developers. You can even chat with them on IRC if you like - just make sure that you are not wasting their time any more than you consider your users are wasting your time by reporting bugs. I have also seen many concerns in this thread that bad reviews from Linux users will tarnish their score. First, realize that Steam reviews are always relative compared to expectations. If you manage those expectations, you can limit negative reviews - that goes for Linux users just as for anyone else. But Linux users can also help your game by recommending it to others. While the same is true for Windows users, those initial Linux users are easier to reach because there is less market saturation (especially in some genres). Using just the raw Linux sales percentage does not necessarily give you a full view of what sales you have gained by releasing a Linux port. To be fair, there will also be Linux customers that would have bought the Windows version, but either way % sales and revenue impact is not a 1:1 relation. In conclusion, I think the main problem Windows developers face when targetting Linux are not technical issues (which there are of course) but one of cultural differences. Once you overcome those and learn how the Linux ecosystem works, you can use it to your advantage. [0] https://github.com/ValveSoftware/steam-for-linux/issues [1] https://github.com/ValveSoftware/steam-runtime [2] http://libsdl.org/ [3] https://gitlab.freedesktop.org/groups/mesa/-/issues
In Developing Games on Linux: An Interview with Little Red Dog Games
I do agree - There are some specific pitfalls with curl|bash: (A) the web server may serve different code for curl's user-agent than what you audited by clicking the link in a browser, leading to a false sense of security; (B) if the network transfer is interrupted, bash will partially execute an incomplete script; and (C) the recurring prevalence of high-profile bugs like https://github.com/valvesoftware/steam-for-linux/issues/3671 You can mitigate (B) by wrapping the whole script in a function, and you can mitigate (C) with `set -euo pipefail` and `trap`, but that doesn't seem to be the kind of bash scripts that people write in practice. MSI (and deb/rpm) definitely can arbitrary bad things at install time too, but at least their built-in file extraction features are entirely declarative, and they always have an entrypoint for the syste
Read the rest
m uninstaller.
In Using CMake and Managing Dependencies
I already run Steam in Docker for this reason, with its own home directory mounted as a subdirectory of my real one. Even before games swiping my homedir I was worried about Steam wiping my homedir, as it's already done once in the past. [1] Though ironically that means I can't use the new Proton runtime thing ("Soldier runtime" I think?) that sandboxes games via user namespaces, because my distro doesn't build the kernel with userns support so it would require me to give the Docker container more privileges. [1]: https://github.com/valvesoftware/steam-for-linux/issues/3671
In Valve's Proton Has Enabled 7000 Windows Games on Linux

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.