There’s more, but not many exclusives

Fingerprint sensors are intentionally always gated behind hardware which uses a cryptographic key to prove validation. The reason is malware, something needs to be done to prove the fingerprint input wasn’t faked.

But this TEE/TPM API should be available to 3rd party operating system (although using a different key than the OEM OS kernel)

All the RISC-V chips I see in the wild so far are stationary or tiny (like some new ESP wifi chips now run on RISC-V)

Mobile / laptop grade performance chips seems a few years away still, tons of optimizations needed (especially fast performance scaling and idle modes) for that

Valve even has a docker container target that includes Wine for future proofed porting

https://github.com/ValveSoftware/steam-runtime

A newer approach to cross-distribution compatibility is to use Linux namespace (container) technology, to run games in a more predictable environment, even when running on an arbitrary Linux distribution which might be old, new or unusually set up.

The Steam Runtime is also used by the Proton Steam Play compatibility tools, which run Windows games on Linux systems. Current versions of Proton (8.0 or newer) use the Steam Runtime 3 ‘sniper’ container runtime.

You target a version of the runtime when porting, and then ALL software ported to a given runtime will work on any host environment where you can support that runtime version

In fact, you can even run this on Windows if you want to avoid potentially messing up dependencies on the host OS, or avoid compatibility problems

Phrasing

I don’t know a single port that looks so janky. It’s like a knockoff USB3

While we’re sleeping different parts of our brain is essentially idle and unresponsive. During the dream phase (REM sleep) there’s still multiple parts that are unresponsive even as the dreaming part is active. And everything we do that’s almost fully handled by a certain part of our brain won’t work in dreams when that part is idling.

The things that works but acts weird in our dreams is partially controlled by an idling part of our brain, but our dreaming part of the brain has a separate redundant model of that thing, but it isn’t complete (see: complex movement, etc)

No, the container environment uses default open source libraries. You don’t add any Steam dependencies to make software run in that environment. You can run it without Steam too. It’s just that Valve are the ones maintaining and updating this particular packaging of containers. When Valve releases new versions of their container (including updated default system libraries), you have to test compatibility with it or stick to using an older one. Similar to how Windows software versions would work best with different Proton versions.

You can use the Steam SDK when using it, and you can also choose not to.

Flatpack is a separate thing, which only handles Linux software within the regular desktop environment (a different method for packing software dependencies, managing system permissions, etc). The main difference is that Flatpack software can integrate with the regular Linux desktop environment, but the container based solution is fully separate from it (runs in gaming mode).

No, Wine (and Proton) is a compatibility layer (API translation, etc). Containers is an isolation method which hides the details of the OS from the software and gives it a standardized environment.

https://github.com/ValveSoftware/steam-runtime

No matter what Linux distribution you run Steam on, the only thing you need to do is to get the container system up and running. Once that runs, all software that runs in these containers will run on that device.

There’s a lot of similarities and differences - the Steam Deck’s gaming mode is able to run a very barebones OS, similar to the very basic OS that the Nintendo Switch runs, with the game running in comparable sandboxes with stable software interfaces.

But Nintendo worked with Nvidia specifically to develop a variant of their hardware dedicated for gaming, while Valve essentially put a Linux laptop in a handheld console format (IIRC they did get help from AMD, but it wasn’t the same kind of deep collaboration), which notably may have different components between different hardware revisions.

When you try to maximize game performance that makes a difference, because on the Switch you can reliably push the hardware to the limits and expect it to keep working and on a Deck you have to test the hardware before pushing it. And if you find a trick that depends on architectural quirks you have to special-case it to not break on other hardware. There’s no guarantee that rarely used hardware features (both physical, and CPU/GPU instructions, etc) will stick around on a future revision of a Deck, while Nintendo guarantees forward compatibility (with help from Nvidia).

Nintendo even worked with Nvidia to emulate the Switch 1 GPU when running games for the first Switch on a Switch 2! They’re even going so far that they’re patching the emulation layer on a per-game basis to fix games where the default emulation method fails! And the ability to do this depends on knowing the exact properties of the hardware revisions of both the original and new GPU! (there’s architectural differences in the GPU that would break some games unless it was emulated)

Now Lenovo also has devices running SteamOS on different hardware, so games that runs on both either needs special cased optimizations for both, or only generic optimizations, or they simply have to decide to support one specific model better than others (which could end up with a game looking worse on better hardware because the dev didn’t try as hard with that hardware)

The only part they could realistically charge for is the Steam store access. Everything else is open source and portable

Steam on Linux defaults to providing a container based standard Linux environment which is independent of the underlying OS, providing access to all the expected software libraries and OS calls that games need to run.

This is integrated into SteamOS. It’s also available via Steam on any other Linux distro. (And if you wanted to you could cut that part out and run it without Steam.)

When running Windows games it even runs Proton within this container environment.

That gives you a single very predictable and version controlled software environment.

Meanwhile Windows randomly deprecates stuff that somebody might have invested tons of development effort into (silverlight, mixed reality, etc)

Passable cotton candy stick, if you’re careful

Mixed rain and snowfall

Even humans can absorb oxygen through the intestines

https://scienceblog.cincinnatichildrens.org/ig-nobel-prize-awarded-to-takanori-takebe-for-butt-breathing-study/

Only tastes ok

What, isn’t that what OP posted

There’s clearly no cat

Found the alt for swiftonsecurity