[HN Gopher] Improving Steam Client Stability on Linux
___________________________________________________________________
Improving Steam Client Stability on Linux
Author : Venn1
Score : 435 points
Date : 2024-11-11 21:41 UTC (1 days ago)
(HTM) web link (ttimo.typepad.com)
(TXT) w3m dump (ttimo.typepad.com)
| bhaney wrote:
| > If this can be addressed in glibc, it may involve a tradeoff on
| features, maybe an opt-in mechanism with a slight departure from
| the "impossible" POSIX spec. That's something we may pursue in
| the long term if we can propose something sensible.
|
| Yes please
| jeffbee wrote:
| Maybe among the best decisions Java ever made was hiding setenv.
| You simply cannot set env vars in Java.
| mschuster91 wrote:
| Java in general tends to massively dislike environment
| variables.
|
| Which is a Good Thing, but unfortunately it makes dealing with
| proxy support so much harder - especially as there are just so
| damn many HTTP libraries that people use...
| aidenn0 wrote:
| So does that also mean you can't write e.g. a POSIX shell in
| Java?
| shakna wrote:
| System.getenv exists, so getting is easy... But setting env
| vars generally involves a convoluted process.
|
| You can modify the JVM's buffer, or spawn a new
| ProcessBuilder, or a few other things. But it's a nasty place
| to be.
| MBCook wrote:
| Or make a little JNI class.
| shakna wrote:
| That doesn't work for preserving to child threads,
| unfortunately. Which is something people expect.
| bhawks wrote:
| 1) java shell starts 2) read getenv into a java hashmap 3)
| evaluate shell input - any sets update the hashmap, any gets
| read from the hashmap 4) when you get to a point where you
| need to exec a process you use the hashmap to pass envvars
| into process builder - which is going to call execvpe for
| you.
|
| So yeah you definitely could (there'd be other reasons why
| java wouldn't be a good choice).
|
| TBH reading that folks were calling setenv before an exec to
| propagate env vars to a child made me sad. I would guess that
| other use cases were leveraging environ as a poor man's
| global variable - which is also unfortunate.
| asveikau wrote:
| execve(2) and friends allow you to specify a new processes's
| environment variables. How Java may choose to expose that I
| don't know. Assuming they do, that is all a shell needs. You
| do not strictly need to call setenv(3) to change a variable
| that gets evaluated with $, etc. You _do_ need to pass the
| modified environment to a child process.
| lmm wrote:
| You can pass a new environment to a process you spawn, which
| I think is adequate? You just can't modify the environment of
| your existing process.
| sunshowers wrote:
| There are tons of reasons you can't write a POSIX shell in
| Java, starting from the lack of support for non-UTF-8 paths
| :)
| NotACracker wrote:
| I admire your courage to say something positive about java.
|
| On another note, I believe Zig does the same thing.
| o11c wrote:
| The real question is: is there _any_ case where a program calls
| `setenv` in one thread and actually _wants_ it to take effect in
| other already-existing threads?
|
| That said, GLIBC _is_ pretty good at documenting all the
| dangerous functions, so it is _possible_ to add locking /copying
| yourself.
| fweimer wrote:
| Interesting idea. I strongly suspect that there are programs
| out there that expect that setenv changes the environ array
| (and they do not treat it as an opaque pointer passed to
| posix_spawn/execve). With a per-thread setenv, we would need a
| per-thread environ variable as well. Unfortunately, that's not
| really compatible with POSIX because environ is not declared in
| a header. Instead, programmers are expected to write a
| declaration extern char **environ;
|
| into their sources, and that declaration is incompatible with
| environ being a thread-local variable.
| o11c wrote:
| Hm, in the end most of the problems do come down to stuff not
| coming from blessed headers.
|
| Regardless of anything else, how about:
|
| * deprecate direct access to `environ` and add functions to
| replace it. Have a macro that indicates this and provide a
| canonical compatibility shim for people to copy if they might
| use old libcs.
|
| * using linker magic, change the behavior of programs
| depending on whether they attempt to access `environ` or not,
| so old-API programs are still thread-unsafe but new ones are
| thread-safe.
|
| It's amazing how much you can do with the conditionally-
| linked object files from a static "library". Much of C's
| cross-TU "UB, no diagnostic required" is inexcusable since we
| can detect it quite easily with zero overhead (at least, for
| static linking) using today's linkers by deliberately causing
| multiple definition errors.
|
| Compatibility with old-ABI programs probably means fixing
| `environ` is not that simple, but you are libc and libc _is_
| in control of dynamic linking ...
| ptsneves wrote:
| All the inconsistencies you suggest sound like a trap,
| especially when you suggest ABI and API behaviour
| divergences. From what I understood of your macro idea this
| would lead to API changes that would lead to ifdefs for
| different (g)libcurl versions. Doesn't feel good especially
| for software distributors.
|
| Also the changes you mention require changes in the linker
| scripts distributed by a variety of toolchains and would
| need to check if the libc target was a blessed one. In
| effect the deprecation would never move to obsolete and
| kept around forever.
|
| To clarify the above post libc is in control of dynamic
| linking through the dl*(dlopen) family of functions.
| fweimer wrote:
| Many years ago, glibc did something along those lines for
| the _res variable (with preprocessor magic instead of
| linker magic). For the main thread, legacy _res (the actual
| global data symbol) and new thread-local _res (actually
| *__res_state()) are the same object, but they diverge for
| subsequently created threads.
|
| I don't think this would work here because it likely
| changes semantics too much, and not all binaries that need
| a thread-safe getenv/setenv combination can be rebuilt,
| especially since compatibility with both variants from the
| binaries would likely some changes to each
| application/library.
| Asooka wrote:
| Yes, I set up environment variables in a plugin that are later
| read by already started worker threads. It's not a problem for
| me because the worker threads are all sleeping on a runqueue,
| but technically I do want to set an env var in one thread and
| read it in another that is already running.
| kelnos wrote:
| > _so it is possible to add locking /copying yourself._
|
| Not if third-party dependent libraries use getenv/setenv. (The
| article mentions this as a continuing problem with the steam
| client.)
| o11c wrote:
| As a rule you should not assume third-party libraries are at
| all thread-safe.
| cryptonector wrote:
| Glibc could crib from Illumos, which has a thread-safe
| putenv()/setenv()/unsetenv()/getenv().
| jandrese wrote:
| There are so many better ways to do IPC that this hacky and
| dangerous getenv/setenv setup is never necessary.
|
| I mean what kind of threading library doesn't have shared
| memory or message passing?
|
| I'm guessing this mostly happens in situations where the main
| process can change variables like HTTPS_PROXY and a different
| thread is running a library that checks those variables before
| firing up a TCP socket.
| fweimer wrote:
| We've got patches under review:
| https://inbox.sourceware.org/libc-alpha/cover.1722193092.git...
| (triggered by https://issues.redhat.com/browse/RHEL-42410, a
| graphics stack stability issue that wasn't as visible in RHEL 9
| for some reason)
|
| At least the first one (the getenv thread safety fix) will
| hopefully make it into glibc 2.41 and it should be quite safe to
| backport. It turns out that setenv is easier to handle because
| glibc already never frees environment strings. It's concurrent
| unsetenv that is rather tricky. Without some snapshot approach,
| getenv would return null pointers instead of environment
| variables values that are actually set. I don't want to introduce
| locking into getenv because getenv without setenv has been async-
| signal-safe for so long that it would likely break applications.
|
| The environ handling fixes are a bit more controversial because
| vfork+execve make it complicated to avoid memory leaks, but these
| further fixes are less important to the stability of the graphics
| stack.
| Asooka wrote:
| What about using a linked list for variables added after the
| start of the process, which can be implemented atomically? Then
| once it gets "too long", a thread executing setenv could
| construct a new hashmap and replace the pointer to the old one
| with the pointer to the new one atomically, all without
| locking? To prevent two threads from rehashing at the same
| time, use an atomic flag for whether a thread is rehashing
| right now. That means if other threads call setenv in the
| meantime, the extra added variables would be appended to the
| list to be processed by a later setenv call (if one happens).
| That list could grow unbounded if enough threads call setenv
| quickly enough, but I think the simplicity of atomically
| swapping pointers might be worth it and setenv isn't called
| very frequently.
| jeffparsons wrote:
| I like this approach, because it lets everything Just Work
| without anyone outside of the implementation having to think
| about it at all, and only incurs meaningful overhead if
| you're doing something really silly, but crucially still
| won't break -- it'll just be slightly slow. That feels like
| the right trade-off.
| sunshowers wrote:
| As far as I'm concerned this is the only correct way to do
| it. I believe illumos does this, which is why its env
| functions are thread safe and have been for decades.
| fweimer wrote:
| POSIX requires that the environment variables can be access
| as an array, through the environ variable. This array is
| expected to be used with POSIX interfaces such as posix_spawn
| and execve. If the array already has to exist, why not use it
| in getenv?
|
| A purely hash-based implementation is not possible because
| there is putenv, and some applications expect modifications
| of environ to be visible via getenv.
| robocat wrote:
| Perhaps related: "Setenv Is Not Thread Safe and C Doesn't Want
| to Fix It" (2023) -- https://www.evanjones.ca/setenv-is-not-
| thread-safe.html and HN comments regarding how rust was
| affected: https://news.ycombinator.com/item?id=38342642
|
| Decades old footguns - aaargh!
| sumtechguy wrote:
| That has been around for a long time. I remember it in the
| early 2000s.
|
| > Decades old footguns - aaargh!
|
| Indeed...
|
| The tricky problem they have is wrapping it into some sort of
| lock could cause so many issues. Places that dont deadlock,
| suddenly could. Not a fun problem to solve. In practice it is
| usually not too bad as you are usually not changing your env
| vars much. But when you run into it, ugh.
| cryptonector wrote:
| Solaris/Illumos has a thread-safe
| setenv()/unsetenv()/putenv(). There is no reason not to have
| it be thread-safe, though it must leak (Solaris/Illumos
| retains the references to the deleted envs so as to fool
| memory debuggers into thinking they are still referenced and
| so quiet what would be essentially false positives).
| fweimer wrote:
| Fortunately, for glibc, the most controversial decision
| (setenv/unsetenv/clearenv leak) has been made decades ago. It
| does not look like something that can be changed, so it's
| actually fixable in the glibc context. But this puts pressure
| on other libcs to adopt essentially the same approach (even
| if they don't leak environment strings today), so that's not
| universally popular.
| Pannoniae wrote:
| To raise awareness: there's been a bug with the Linux Steam
| client which has been persistent for a long time.
|
| TL;DR: if you have Steam running for more than a ~day or so, you
| will run out of window handles so you won't be able to open any
| new graphical application/window until you restart Steam.
|
| Using Steam Chat appears to make the issue worse (it happens
| earlier).
|
| This has been documented under
| https://github.com/ValveSoftware/steam-for-linux/issues/9094 but
| for some reason that issue has been closed.
|
| I personally just restart Steam every day but if someone else
| encounters this issue and doesn't know why their windows are not
| opening, this is why :)
|
| I am using KDE/Wayland but I've observed this under X11 too.
| LorenDB wrote:
| KDE Wayland user here. I have never observed this issue myself,
| and I leave Steam running all the time (although I never open
| Steam Chat).
| snvzz wrote:
| Although, not albeit.
|
| You have a slave sentence there. These are incompatible with
| albeit.
| LorenDB wrote:
| Thanks, fixed! "Albeit" seemed like it would work, but
| "although" indeed fits much better.
| soulofmischief wrote:
| To put it another way, albeit shouldn't be used with
| independent clauses.
|
| 1. I leave Steam running all the time (although I never
| open Steam Chat).
|
| 2. I leave Steam running all the time (albeit never with
| Steam Chat).
|
| "I never open Steam Chat" can stand on its own as a
| sentence, but "never with Steam Chat" does not and thus
| can be appropriately modified with albeit.
| CoastalCoder wrote:
| I kinda wish HN allowed a visual indicator for subthreads
| that focus on tangents that don't hold universal appeal:
| comment grammar, humor, "why did I get downvoted?", etc.
|
| There are lots of little discussions like this that I'd
| love to have, but which sometimes lead to a lot of
| downvotes.
| nazgulsenpai wrote:
| Void Linux, xorg and never has this issue, often going many
| days without rebooting with Steam constantly open.
| GauntletWizard wrote:
| I've got several Linux gaming machines (and a couple of
| business desktops I play FTL on sometimes), and it's weirdly
| inconsistent - the best and worst machine I have both use Intel
| Graphics. It almostnever shows up on the A770 - that one stays
| awake for weeks of daily gaming and I have no problems with it.
| My laptop with integrated Intel sees it all the time. My laptop
| with Nvidia graphics sees it often, but not nearly as often.
|
| The one that's so annoying that I've actually developed habits
| around it is the tendency for the library window to freeze when
| it becomes unfocused - it's not all the time, but it's often
| enough that I now habitually close the window anytime I defocus
| it
| jandrese wrote:
| Interesting. I've left the Steam client running for weeks at a
| time and have not seen that issue. I bet it was closed because
| Valve couldn't replicate the problem.
| k4rli wrote:
| This has made Steam something to avoid for me. I tried
| switching to Flatpak version to see if that would help, but
| unfortunately not. For me it started ~1 year ago.
|
| The performance issues have made me not want to even open Steam
| anymore so I have nearly completely stopped playing. (not
| related to this issue but several games have also added kernel
| anticheats, killing off Linux versions, which also has
| contributed to this)
| snvzz wrote:
| Considering glibc's effort, I have to wonder what the other libc
| do, and whether they already implement something like this.
| electromech wrote:
| Thank you! I deeply appreciate that Steam works so well on Linux
| these days. I don't take for granted the hard work happening
| behind the scenes to make that a reality for us.
| BolexNOLA wrote:
| I really hope they drop a full steam OS release again soon. I'd
| love to build a gaming tower around it. Might settle for
| bazzite but I'd like to do steam OS tbh
| lordofgibbons wrote:
| What would that get you over any other distro with the steam
| software installed?
| shortrounddev2 wrote:
| 1st party support
| zamadatix wrote:
| There's a lot more to SteamOS than "it ran `apt install
| steam -y` for you". Even just having things like Gamescope
| running out of the box (which is more than just `apt
| install gamescope`) is a huge amount of headache set aside.
| Plus the guarantee when it doesn't work it's because of a
| bug rather than something you did or some incompatibility
| with your exact distro setup.
| BolexNOLA wrote:
| Yeah you get it lol I just want to play my damn games and
| not tinker all the damn time!
| akimbostrawman wrote:
| >guarantee when it doesn't work it's because of a bug
| rather than something you did or some incompatibility
| with your exact distro setup.
|
| Flatpak fixes this problem. You don't need gamescope
| unless for stuff like scaling. The only few times you
| need to fiddle with anything on desktop is changing
| proton version or adding a launch variable from
| protondb.com (just like on steamdeck)
| zamadatix wrote:
| Gamescope does a lot more than scaling. HDR, better
| framerate limiting, non-rgb gamut handling, isolating
| "fullscreen" games, shader effect loading, and probably
| more I'm forgetting. Flatpak let's you run the Steam app
| itself correctly, nothing more. These "you only need to
| fiddle when" are exactly what add up and create
| frustration between users on different systems just
| wanting to play a game instead of read a manual/guide to
| find which "few tweaks" they each need to do to get the
| same experience as SteamOS would give them.
| eloisant wrote:
| Bazzite has gamescope running out of the box, and other
| distributions probably have it too.
|
| It's also an immutable distribution, like SteamOS (except
| it's based on Fedora Silverblue instead of Arch) so there
| is no "incompatibility with your exact distro setup": you
| have the exact same distro setup as every single Bazzite
| user.
| zamadatix wrote:
| Yeah, Bazzite is probably the best alternative barring
| official support. It attempts to tackle most of the
| issues head on.
| BolexNOLA wrote:
| I like console gaming because it just works. I sit down on
| my couch, I turn on my controller, and I'm back in my game
| in under 10 seconds. The series S has honestly been a
| fantastic purchase for me despite the many drawbacks.
|
| PC gaming is very enticing but we all know that's simply
| not how it goes down. I would love to build a PC that is
| literally just discord and Steam. I want to run it in big
| picture mode for the most part and treat it more or less
| like a console.
|
| I have really enjoyed my steam deck and it has fit that
| desired role pretty well. But obviously it is just not that
| powerful. It's impressive for what it is, but for me it's
| basically a great indie game machine with the occasional
| AAA option that is tolerable. A well-built machine with
| that kind of UX (minus the known idiosyncrasies of the
| deck) would be fantastic.
|
| To answer your question more directly: Most Linux distros
| do not offer this either. Bazzite is the closest I've seen.
| anotherhue wrote:
| You can run gamescope as your WM and have a steam-deck-like
| experience on your desktop, ideal for a living room.
|
| https://wiki.nixos.org/wiki/Steam#Gamescope_Compositor_/_%22.
| ..
| BolexNOLA wrote:
| I honestly don't want to be tinkering all the time. The
| steamdeck is pretty much my limit for tinkering with gaming
| these days. Kids do that to you lol
| mgrandl wrote:
| Bazzite is the answer. It's basically out of the box
| SteamOS, just somehow even better.
| anotherhue wrote:
| Also https://github.com/Jovian-Experiments/Jovian-NixOS
| nineteen999 wrote:
| GGP literally said he doesn't want to be tinkering all
| the time. Nix is literally the opposite of no tinkering.
| BolexNOLA wrote:
| I imagine it is great but I just don't want to have to
| troubleshoot my operating system, games, and hardware. It
| is probably reasonable to assume that a stable steam OS
| will be more consistent for me. Maybe I'm underestimating
| bazzite but in my experience regular Linux users (I have
| some experience but hardly an expert/daily user)
| underestimate how frequently one has to tinker with their
| OS's.
| Andrex wrote:
| I use Linux every day and I never have to tinker with it,
| nor did it need any tinkering to install. An extremely
| tinker-free experience especially compared to modern
| Windows.
|
| I feel your anecdotes are at best outdated. Desktop Linux
| has come along way.
| BolexNOLA wrote:
| I get people bristle when someone says linux has a little
| friction, but as someone who does use Elementary and Mint
| from time to time I just don't get how people can say my
| view is "outdated" when all one has to do is pick up a
| console or Mac to see the difference. How many times have
| we seen folks troubleshooting wifi card drivers on
| forums? It is not some massive gap, using Linux is not
| some herculean feat, but surely we can agree that most
| people would never call it plug and play.
|
| Linux is a great experience these days but you _do_ have
| to tinker sometimes. You have to mess with drivers and
| settings and command line. It may be minimal for people
| comfortable with computers but it 's not as friction-less
| as you're claiming.
| freedomben wrote:
| I think you're both kind of wrong and right on this.
| Contemporary linux distributions really don't require
| tinkering anymore for most cases, yet it's also true that
| sometimes there is tinkering required. The reason why
| this is true, yet I don't blame Linux for it, is because
| it is hardware dependent.
|
| If you buy hardware that is compatible with Linux, then
| you won't really have to tinker (at least, any more than
| you would with any other OS, for example, tweaking
| resolutions, etc). Unfortunately, it's newer hardware
| that typically requires the tinkering. If you don't want
| to tinker, I would recommend going with generation n -1
| or even n -2. If you go with the latest and greatest,
| expect to have some tinkering required.
|
| Distro choice does of course matter a great deal. I've
| been using Fedora as primary OS now for many years and
| absolutely love it, and it's what I recommend to most
| people. Ubuntu and derivatives are good of course, though
| the older kernels do often decrement the generation of
| hardware. For example, Fedora on n-1 is going to be
| pretty good. Ubuntu might still lack some support at that
| age, so should go with n-2 or n-3 to be safe.
| BolexNOLA wrote:
| The plan is to build a modern PC and the fact that people
| have to adjust their hardware decisions in such a way
| (downgrading/using older components) to accommodate linux
| kind of reiterates my point IMO. If I was installing
| windows this wouldn't remotely be a consideration. Though
| I certainly don't want windows, it is a notable
| difference.
| talldayo wrote:
| As someone that has gamed an equal amount on Windows 10
| and Linux, I think you're blowing things a little out of
| proportion. Windows is a tinker timesink too if you want
| to uninstall Candy Crush and Xbox Game Bar, disable all
| telemetry and ads, or even just get a good version of
| Java installed for Minecraft. Windows can "just work" for
| some games, but for others it's a nightmare to get
| running. Another good example is the _Fallout_ games,
| which have a decades-old bug that crashes the game if you
| alt-tab away from it. On WINE this bug can be fixed by
| simply running the game fullscreen in a virtual window.
| The flexibility is excellent and saves me from trying to
| inject a DLL file just to get proper borderless
| fullscreen to work the way it should.
|
| My big takeaway is this; if you are comfortable using the
| Steam Deck to play games and install software, you will
| not struggle to get Linux to run games. Pretty much
| anything that isn't a gaming laptop is going to have some
| form of support, and even the famously crappy Nvidia
| drivers were recently updated to support Wayland and
| other new Linux protocols. Now more than ever before,
| using Linux to game is probably easier than getting the
| equivalent experience on Windows.
| dingnuts wrote:
| You compared Linux to Mac a few comments back -- how is
| that anything but choosing specific hardware to
| accommodate your OS?
|
| by this standard Mac OS is still a hobby OS because it
| can't be installed on random hardware.
|
| No, it isn't too much to ask that you make sure the
| hardware you buy works with the OS you intend to run. If
| you find Linux fiddly in the modern era it's solely
| because of this.
| tapoxi wrote:
| Bazzite is atomic and image-based, so it is designed to
| play your games out-of-the-box without any additional
| configuration, and instead of package updates you are
| pulling the new image that's built and tested by Bazzite.
| From a design perspective it's extremely similar to
| SteamOS.
| superkuh wrote:
| So it works until it doesn't (because your hardware is
| not their test hardware) then there's no way to debug or
| fix things.
| mrj wrote:
| Yeah same. I didn't want to install all of those i386
| library versions either. But I've found the flatpak steam
| client to be wonderfully easy and maintenance free, which
| let's me use my computer for other things, too.
|
| https://flathub.org/apps/com.valvesoftware.Steam
| pnw wrote:
| I thought Valve already said they don't plan to do that.
| Steam OS 3.0 is only for the Steam Deck isn't it?
|
| From https://repo.steampowered.com/steamos/README.txt
|
| SteamOS version 1 'alchemist' and version 2 'brewmaster' have
| been discontinued. No further updates are planned.
|
| The SteamOS 'clockwerk' prototype has also been discontinued
| and will not be released.
| CivBase wrote:
| Last I heard they were still working on a general desktop
| release but it's slow going, largely due to Nvidia support.
| nar001 wrote:
| Or not supporting them rather? Do you have a link
| somewhere they talk about it?
| BolexNOLA wrote:
| They've been pretty quiet about it yeah but last I saw
| there was some plan to do it some day
| ensignavenger wrote:
| The last I heard, they said they were planning to do it,
| for example, this article: https://9to5linux.com/valve-
| says-steamos-3-0-will-be-availab...
|
| But I haven't heard anything one way or the other in a
| while. But as it stands, they have stated that they plan to
| do a general release. Unless there is another source where
| they say they changed their mind?
| bsimpson wrote:
| The link you referenced just says that the Debian packages
| are irrelevant to the current codebase, as used on the
| Steam Deck. It doesn't say anything about the Steam Deck
| being the only hardware that will ever run it.
|
| Some of the recent SteamOS release notes have included
| references to Asus's handheld, which has reinforced the
| community expectation that it will eventually be available
| as a distribution you can install on 3rd party hardware. If
| you go read interviews from Valve employees (Lawrence Yang
| comes to mind), I believe they've publicly stated that
| after the OLED shipped, they wanted to start focusing on
| porting to other devices.
| jorvi wrote:
| > If you go read interviews from Valve employees
| (Lawrence Yang comes to mind), I believe they've publicly
| stated that after the OLED shipped, they wanted to start
| focusing on porting to other devices.
|
| If so, it is kind of bizarre they haven't reached out to
| the Bazzite maintainers at all.
|
| In general, it seems like it would save them a tonne of
| effort if they'd switch from a bespoke Arch-immutable
| spin to making a spin of Silverblue, something that has
| been meant to be immutable from the beginning.
| bsimpson wrote:
| Is it?
|
| They already have a system that works exactly how they
| want it. They already rebased from Debian to Arch to get
| it there. They have enough Linux staff on contract to
| build and maintain that system.
|
| Maybe Bazzite is closer to their goals; maybe it's not.
| It's certainly not a slam dunk that the best thing they
| could do is throw away the thing they've been building
| for years to join a community project on GitHub that's
| trying to clone that thing.
| marcthe12 wrote:
| Upstream Kde is now making an arch based immutable distro
| too. As steamOS is already using kde and arch, maybe once
| the kde distro is release, steam will rebase on that
| instead. Also Valve is now funding Archlinux so they are
| commited to arch.
| hypercube33 wrote:
| ChimeraOS is a clone or fork or something of SteamOS. Works
| great on AMD tiny PC hardware. can't really comment past
| that. I found the keyboard and mouse setup kinda jarring and
| just threw windows back on...for now.
| bsimpson wrote:
| As noted in a sibling comment, Valve has released an open-
| source compositor (`gamescope`), which is what presents
| Steam as a console-esque UI on the Steam Deck. Using
| gamescope to present Steam, you can make an arbitrary Linux
| feel indistinguishable from a Deck.
|
| There are many gaming distributions (e.g. Bazzite,
| Jovian/NixOS, Nobara, Chimera...) that take this approach.
|
| They're usually just standard desktop distributions (Fedora
| or NixOS) with gaming packages configured. There is a
| Russian teenager who's trying to cobble together a SteamOS
| clone using as many Valve packages as possible. His project
| is called HoloISO.
| jorvi wrote:
| You're talking about Big Picture, which has been a thing
| for.. 8 years? Maybe 10?
|
| The compositor is what runs two layers down, under the
| window manager.
| izacus wrote:
| No, he's talking about the compositor which has several
| gaming related features which then runs the Big Picture
| version of Steam for UI to select and manage games.
| entropicdrifter wrote:
| They're right that the compositor is gamescope, it's made
| by Valve and it has game-related features, but the person
| 3 comment-levels above me did seem to be conflating
| gamescope with the Big Picture UI. You can absolutely use
| gamescope and _not_ use Big Picture mode at all, lots of
| people using Wayland do so by wrapping their games in a
| call to gamescope.
| tombert wrote:
| For what it's worth, I have had pretty good luck with Jovian
| for NixOS. My primary game console is a little gaming PC
| running it, I like it.
| eek2121 wrote:
| Same. I have been toying with an idea that I want to turn
| into a business. I know there are 3rd party attempts to
| replicate Valve's stuff, but I would rather use something
| sanctioned by Valve.
| eloisant wrote:
| What do you want from a generic SteamOS that Bazzite doesn't
| have?
| josephcsible wrote:
| > One of my colleagues rightly dubbed setenv "the worst Linux
| API".
|
| Is setenv really a Linux API, since it's neither defined by Linux
| (it's in POSIX) nor implemented by the Linux kernel (it's
| entirely in userspace)?
| amiga386 wrote:
| Yes it is, if you program application software _for Linux_ (and
| your other two supported platforms are Windows and macOS, as is
| the case for OP and their colleague who appear to work for
| Valve, supporting Steam)
|
| And the reason the colleague dubs it the worst has nothing to
| do with its specification in POSIX (which doesn't require the
| function to be thread-safe but also doesn't prevent it from
| being made thread-safe), but rather its specific implementation
| in glibc, which is the C library in use on all the Linux
| distributions that Valve support Steam on and all are equally
| dubbed as "Linux"
| WhyNotHugo wrote:
| Technically, this is a GNU libc limitation. A libc _could_ make
| this thread-safe.
|
| Languages like go just implement this feature internally and
| don't have this limitation.
|
| The limitation is contemplated in POSIX itself; from the posix
| documentation:
|
| > The setenv() function need not be thread-safe.
| deathanatos wrote:
| I think you get thread-safety and memory leaks (the article
| alludes to macOS taking this approach), or it's unsafe but
| doesn't leak. But that _is_ inherent in the API, as specified
| by POSIX: setenv must necessarily either invalidate the
| pointer returned by getenv (which is cannot do safely) or
| leak it.
|
| Perhaps the leak is "better", in at least there won't be non-
| OOM crashes, but it still leaves a bad taste in one's mouth.
|
| For a long running program like Steam (that is for some odd
| reason calling setenv...?) ... I'm not sure which is better.
| Better would be not calling setenv, which it sounds like
| they've worked on.
| jandrese wrote:
| I would be happy if getenv() called strdup() on the value
| and returned that. It would cause loads of minor memory
| leaks and maybe a handful of serious ones, but they should
| be reasonably easy to clean up and would avoid returning
| pointers to mutable private data.
| nineteen999 wrote:
| The stability is fine for me, but the rendering performance in
| the steam client when the mouse is in the window is abysmal.
| Vilian wrote:
| Nvidia?
| yxhuvud wrote:
| Could just be really old gnome installation and higher poll
| rate than normal. There used to be issues there..
| nineteen999 wrote:
| It's AlmaLinux 9.4. Gnome 40.10.
| dpkirchner wrote:
| Nvidia in my case, and I agree, the app performance is very
| poor. The easiest way to see the lag, IMO, is to open up the
| achievements list for a game and try to scroll around. It
| takes almost a second for mouse scroll wheel movements to
| have an effect.
|
| (Up to date mint, cinnamon)
| nineteen999 wrote:
| It's a NUC with 00:02.0 VGA compatible controller: Intel
| Corporation Alder Lake-N [UHD Graphics]
|
| Integrated graphics to be sure, but i'm usually only using it
| to stream games from PC or laptop and the performance is fine
| for that in game.
| accrual wrote:
| This is really cool insight into both the Steam client and Linux
| programming. I understand why there may not be detailed release
| notes every release, but wow "Fixed some miscellaneous common
| crashes" is an understatement when you know about this work!
| vlovich123 wrote:
| Isn't best practice to read all environment variables on boot and
| never use setenv? The only place where setenv would matter is for
| spawning new processes where you should probably be creating an
| new environ cloned from the current one and update the new
| values. Using getenv/setenv as an IPC messaging mechanism seems
| to be an opportunity for lots of issues aside from it
| historically not being multithreaded-safe on Linux and having all
| sorts of potential memory leaks hiding (which is what the post
| ignores when it says that it's thread safe on MacOS).
| cryptonector wrote:
| No. Because you might end up using a library that calls
| getenv().
|
| Java does what you say, but it still presents problems for JNI
| code using libraries that want to getenv().
| Aeolun wrote:
| My only issue with Steam at this point is that it'll just
| randomly complain it has no connection, no matter which content
| server I set it to connect to.
|
| If I spam the 'retry' button it'll eventually work, but it's a
| massive PITA.
| thrdbndndn wrote:
| > We removed the majority of setenv calls. It was mostly used
| when spawning processes
|
| Could someone elaborate this for a non-developer? Why would you
| use `setenv` (which I assume is functionally similar to `export
| key=value`, but correctly me if I'm wrong) (extensively) for
| spawning processes?
| fulafel wrote:
| Environment variables are per-process, but inherited by child
| processes (not system wide). So when you start other programs
| you often set up env vars for them, or clear env vars that were
| used by your parent process to not inadvertantly perturb the
| child's behaviour.
| bhawks wrote:
| Yes the proper way to do that is execve, not by changing
| global variables in your parent process.
| https://man7.org/linux/man-pages/man2/execve.2.html
|
| Using setenv is mostly always a hack that relies on a bunch
| of assumptions that could easily change and be hard to debug.
| ptsneves wrote:
| Unless there is a fork exec family of syscalls are not
| child processes but the same process itself. Small detail
| but important because sometimes you really want a separate
| process altogether.
| gpderetta wrote:
| in that case you do not need setenv to pass values to the
| underlying process though. And if you are forking without
| immediately execv in a multithreaded program, setenv is
| the last of your problems.
|
| edit: what's probably happening is that execve is four or
| five abstraction layers deeper (possibly in a third party
| dependency) than where the env variable need to be set
| without a clean way to pass the values through.
| fulafel wrote:
| The likely scenarios I was thinking (setenv vs execve)
| would both be called in the child process after fork. But
| of course here we get to the fascinating world of fork
| interactions with threads, and you could even have one
| thread fork()ing while another thread is doing a setenv().
| thrdbndndn wrote:
| Regardless of whether it's a hack, my broader question is: is
| it common in Linux to manipulate environment variables on the
| fly for a process or program?
|
| I primarily use Windows, both as an end-user and an amateur
| programmer. From my experience, most programs on Windows
| don't do this. If parameters are needed, they're usually
| passed as arguments, while environment variables are used for
| more permanent settings, like %PATH%.
| izacus wrote:
| Yes, the fact that the original article exists shows that
| it's common :)
| johannes1234321 wrote:
| PATH is a good example why steam does this: Steam is a
| program to launch a wide variety of other programs, which
| it doesn't fully control. Those programs (games) may do
| anything including launching further programs (utilities),
| so steam may set PATH so that the game finds those
| utilities.
|
| It can also be a way to pass license information or other
| configuration settings.
| Tobu wrote:
| Looks like the Steam team moved to control spawning and
| do execvpe.
|
| I would like to see at least in-process environment
| modification discouraged. Rust is dealing with the issue
| by considering getenv unsafe when coming through C, but
| getting rid of the read side is much harder than the
| write side.
| jpk wrote:
| One thing to note about command line arguments on Linux is,
| any user can typically inspect `/proc/{pid}/cmdline` and
| get the full command line used to start the process. So if
| you pass secrets like API keys, passwords, etc, via an
| argument, they're visible to the rest of the system.
| However, if you put secrets into the environment of the
| child process, only the user that owns the child process
| can inspect `/proc/{pid}/environ`.
| vbezhenar wrote:
| https://man7.org/linux/man-
| pages/man5/proc.5.html#DESCRIPTIO...
|
| One can use `hidepid` parameter when mounting procfs to
| hide cmdlines.
|
| I don't know why this is not implemented today by default
| in most distros. Probably history reasons.
| sumtechguy wrote:
| It is decently common enough in unix. You are correct with
| my windows stuff it is fairly rare to set env vars to
| change the launching process. In the unix world though I
| have seen the pattern a decent number of times. With
| windows programs usually you see the pattern (not always)
| if it is ported from a unix system. Windows likes its
| ini/registry/cli items to do configuration. It doesnt mean
| the pattern can not be used in windows, I personally just
| have not seen it as much with native win32 apps. If you
| fire up something like 'git bash' you can see entire bash
| functions bound to env variables.
|
| I think it goes back to where windows came from. That
| environment space in DOS was not exactly huge (256 bytes at
| one point?). In unix it seems like it was much larger and
| expressive.
| bhawks wrote:
| FWIW the decision to leak memory on Mac actually goes back ~26
| years to FreeBSD -
| https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=5604 which OSX
| inherited. I would not be surprised that Windows setenv has BSD
| roots due to licensing.
|
| 26 years ago people knew this API was broken but didn't fix it
| due to inertia of breaking buggy programs further.
|
| There really shouldn't be a need to change your own process's
| envvars. For subprocesses just use the proper exec function. For
| anything else there should be a clear API to call rather than
| changing a global variable and hoping some code far away from
| yours rereads it and handles things correctly.
| jandrese wrote:
| I only partially disagree with the sentiment that it is
| "impossible to fix". For the current API that is true, but a
| fairly minor modification API would make it possible. All
| getenv() has to do is strdup() the return value before sending
| it back and leaving it on the programmer to free the memory
| when they are done with it. This does mean that the programmer
| will need to call getenv() again if they think the value might
| change, but I think that is a reasonable tradeoff.
|
| This change would make old programs leak memory every time they
| call getenv() without the subsequent free(), but since the
| current version also leaks memory that doesn't seem like a
| dealbreaker. As an added bonus the new version could be made
| thread safe by wrapping the strdup() in a mutex and doing
| similar work on the setenv() side.
| INTPenis wrote:
| The mere existence of Steam is astounding to someone who grew up
| playing nethack and chess on Linux.
|
| But the Steam client is really strange. Sometimes it works for
| months, and suddenly a game won't start, or something doesn't
| work, and I have to do weird stuff to get it working like purging
| all files or reinstalling. It doesn't make sense, it's like the
| Steam client rots.
| sunaookami wrote:
| Steam is one of the worst software, it's frankly embarassing
| for such a huge company. It's a hotchpotch of different design
| principles and new features only get tacked on with a very
| different UI + UX. The client is mostly webviews but they are
| so slow and buggy and they use a very old insecure Chromium
| version under the hood. The launcher is still a 32 bit program.
| It's sad that other launchers are even worse though.
| tapoxi wrote:
| I checked and its using Chromium 126.0.6478.183 from July,
| which isn't that old.
| sunaookami wrote:
| It's four versions behind the current one with a lot of
| CVEs. There seems to be an LTS 126 but it's only for
| ChromeOS - it's at least behind this one which fixed one
| critical and two High CVEs:
| https://chromereleases.googleblog.com/2024/11/long-term-
| supp...
|
| Even being only one version behind is dangerous for such a
| huge attack vector.
| 0x457 wrote:
| It seems like a lot of steam client issues come from weird
| desire to:
|
| 1) Keep it 32 bit
|
| 2) Have a single store-frontend
|
| At least, it came to a conclusion that it steam itself should
| be responsible for managing runtimes for games.
| VyseofArcadia wrote:
| In my experience, all of those things are also true of Steam on
| Windows. In fact, if anything I have to deal with it less
| frequently since switching exclusively to Linux.
| apatheticonion wrote:
| Would love an open source Steam client
| DanielHB wrote:
| I can't wait to ditch windows for my tower PC.
| WhyNotHugo wrote:
| I'm really curious why they're using setenv(3) so much. The main
| usages that I can think of is setting an environment variable
| before calling something like exec(3). That doesn't seem to be
| the case here.
|
| The article mentions that they use exevpe for spawning children
| processes. So what usages of setenv(3) would remain?
| Tobu wrote:
| It is possible to check for setenv/unsetenv/putenv with nm -D,
| and a quick sample of my ~/.cargo/bin/* shows far too many
| programs using those. Yeah they could be single threaded, but
| who can guarantee they will remain so? Come to think of it
| listing symbols could detect pthread_create as well.
|
| I'd be interested in a way to do static binary analysis to get
| from those symbols to a call tree, as well.
|
| I don't see a way to check for **environ usage though, the
| compiler could turn this one into anything.
| russnes wrote:
| I love the steam client on linux these days, especially the
| compatibility for non-steam games is so great and Ive been using
| it to play WoW Classic while I have covid
| matheusmoreira wrote:
| I wish they'd make it more virtualization friendly. I don't want
| to run untrustworthy proprietary software on my main system.
| Common sandboxing mechanisms are insufficient since Steam and its
| games need access to the entire device tree anyway. Nothing short
| of a real virtual machine would do it for me. Will also make
| compatibility painless since I can just install the Linux
| distribution they support.
|
| I shopped around for computer parts with complete IOMMU support
| just so I could map the discrete GPU to the virtual machine and
| achieve near native performance... Only to discover they are
| exceendingly hostile to users who do this VFIO stuff.
|
| Just yet another reminder not to "buy" games on these platforms,
| I guess.
| carlhjerpe wrote:
| > I shopped around for computer parts with complete IOMMU
| support just so I could map the discrete GPU to the virtual
| machine and achieve near native performance...
|
| So just any standard/decent motherboard bought within the last
| 3-4 years?
|
| > I wish they'd make it more virtualization friendly.
|
| Which games do you have issues with when virtualizing? I've
| only been locked out of Halo Infinite and I enable all hyperv
| flags in libvirt.
|
| > Just yet another reminder not to "buy" games on these
| platforms, I guess.
|
| If you buy a game on Steam and you're unable to play it they'll
| refund you straight away, which is why everyone loves Valve and
| Steam even when the client is crappy.
|
| I couldn't be happier with my setup, which I assume is similar
| to yours. (2 GPUs)
| matheusmoreira wrote:
| > So just any standard/decent motherboard bought within the
| last 3-4 years?
|
| It isn't at all obvious that IOMMU is supported by even
| current top of the line motherboards. I looked at a lot of
| products and have yet to see the VT-d and AMD-Vi keywords
| mentioned in technical specifications. To confirm support I
| had to read their UEFI firmware manuals and look for
| instructions on toggling the virtualization support.
|
| https://pcpartpicker.com/forums/topic/466120-ecc-ram-and-
| iom...
|
| At least ECC memory support has started to show up in
| technical specifications. Looks like IOMMU is not quite there
| yet.
|
| > Which games do you have issues with when virtualizing?
|
| From what I'm reading many games take virtualization as
| evidence of cheating and have no regard for false positives.
| I'm currently assuming any game with battleye or easy anti
| cheat will issue permanent bans on virtualization detection.
|
| > If you buy a game on Steam and you're unable to play it
| they'll refund you straight away
|
| Somehow that doesn't bring me much peace of mind.
| Dwedit wrote:
| On Windows, "Environment" is stored in the Win32 Thread
| Information Block/Thread Environment Block (TIB/TEB), so it's
| thread-local rather than process-global.
___________________________________________________________________
(page generated 2024-11-12 23:02 UTC)