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.

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.

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.

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.

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.

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).

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...

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.

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.

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.

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.

What do you want from a generic SteamOS that Bazzite doesn't have?

What would that get you over any other distro with the steam software installed?

There exists a ton of working code that does not fiddle with setenv and now would have memory leaks if they don't change their code? Plus I would now need to test if my stdlib requires freeing memory or not because if I try to free on an older libc it is not going to work out well. I don't think the value works out.

From a hygiene perspective - freeing the return of another API is an anti pattern. If you need the caller to release objects there should provide a FooLib_bar_destory(bar) or similar.

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 ...

As a rule you should not assume third-party libraries are at all thread-safe.

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.

Exactly, Steam is very much the worst game launcher ever created, except for all the others.

I checked and its using Chromium 126.0.6478.183 from July, which isn't that old.

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.

The interesting thing is that Valve is not a "huge company". They're privately held and only had 336 employees the last time headcount was reported (2021).

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.

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%.

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.

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.

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.

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.

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 :)

Although, not albeit.

You have a slave sentence there. These are incompatible with albeit.

If you actually look at the issue you can see it was closed because Valve shipped a fix and people confirmed it was fixed. Then later some other people reply that they still have problems but without any useful information.

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)

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.

Could just be really old gnome installation and higher poll rate than normal. There used to be issues there..

> 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.