Steam Link now available on Linux

[slouken]

The Steam Link app is now available for 64-bit x86 Linux systems. A wired network is strongly recommended.

You can get it here from Flathub:
https://flathub.org/apps/details/com.valvesoftware.SteamLink
Make sure you follow the setup guide on that page before you install, if you have never used flatpak before.

Special thanks to Collabora[www.collabora.com], for helping make this possible.

[🐭]

Nguyên văn bởi Savvy:

Awesome that this is available for such a common arch finally. I just wish folks would use more common package mangers - deb/rpm packages or snap distribution would be nice. Never even heard of flatpak, and it sounds like yet more fragmentation to me; snap is annoying enough with how it globs onto things.

From what I understand, flatpak basically is just another snap/appimage thing.

I still don't understand what problems these things are supposed to solve. Something about distributing your software to Linux systems?

[Maximum Napkin]

Snap, Flatpack, and AppImage basically all exist to try to solve the fragmentation issues caused by differences between distributions and deb/rpm ecosystems, with Snap and Flatpack also trying to address security issues by introducing better sandboxing features. With traditional deb/rpm packages, each package file will usually only work on one or maybe a couple of specific distributions (and specific version of those distros), and when system packages are updated the package maintainer will have to go and build a new version of the package and push it to the repo. This works well enough for open source software, but for proprietary software like games where you can't just have a community of maintainers go and re-compile it for dependency changes or when new distros pop up it doesn't work so well. Imagine trying to keep packages for, say, Fortnite, up to date for every incompatible distro. Epic might be able to afford it, but it's a lot of work for a (relatively) tiny benefit, and smaller teams have a harder time keeping up to date.

AppImage is the oldest of the three and probably the simplest. It basically just bundles all the dependencies into one file, and doesn't really do any sandboxing. In my experience it's been the easiest and most reliable, but you lose the ability to automatically apply security updates to dependencies.

Snap is controlled by Cannonical and seems to add a lot of startup overhead (see complaints about the new Gnome Calculator taking several seconds to start up in a recent Ubuntu release when they switched it to a Snap app a while back). It's also difficult/impossible to disable automatic updates if you wanted that. Snap tends to be a little controversial since it requires interaction with the centralized Snap Store run by Cannonical, and it's not really feasible to maintain a 3rd party store/repo.

Flatpack is a little lighter, is less centralized than Snap, and has some different policy specifics around the sandboxing features, but is otherwise pretty similar in goals and features (though I understand Snap wants to support packaging core system services/features, while Flatpack focuses just on end-user facing applications).

In theory, if a developer releases a game in any of the three formats, that one file should run on pretty much any recent version of linux, in any distro or desktop environment, and continue to work fine even when the OS updates change the system libraries that a deb/rpm app would have been depending on.

[🐭]

Nguyên văn bởi Maximum Napkin:

Snap, Flatpack, and AppImage basically all exist to try to solve the fragmentation issues caused by differences between distributions and deb/rpm ecosystems, with Snap and Flatpack also trying to address security issues by introducing better sandboxing features. With traditional deb/rpm packages, each package file will usually only work on one or maybe a couple of specific distributions (and specific version of those distros), and when system packages are updated the package maintainer will have to go and build a new version of the package and push it to the repo. This works well enough for open source software, but for proprietary software like games where you can't just have a community of maintainers go and re-compile it for dependency changes or when new distros pop up it doesn't work so well. Imagine trying to keep packages for, say, Fortnite, up to date for every incompatible distro. Epic might be able to afford it, but it's a lot of work for a (relatively) tiny benefit, and smaller teams have a harder time keeping up to date.

AppImage is the oldest of the three and probably the simplest. It basically just bundles all the dependencies into one file, and doesn't really do any sandboxing. In my experience it's been the easiest and most reliable, but you lose the ability to automatically apply security updates to dependencies.

Snap is controlled by Cannonical and seems to add a lot of startup overhead (see complaints about the new Gnome Calculator taking several seconds to start up in a recent Ubuntu release when they switched it to a Snap app a while back). It's also difficult/impossible to disable automatic updates if you wanted that. Snap tends to be a little controversial since it requires interaction with the centralized Snap Store run by Cannonical, and it's not really feasible to maintain a 3rd party store/repo.

Flatpack is a little lighter, is less centralized than Snap, and has some different policy specifics around the sandboxing features, but is otherwise pretty similar in goals and features (though I understand Snap wants to support packaging core system services/features, while Flatpack focuses just on end-user facing applications).

In theory, if a developer releases a game in any of the three formats, that one file should run on pretty much any recent version of linux, in any distro or desktop environment, and continue to work fine even when the OS updates change the system libraries that a deb/rpm app would have been depending on.

I feel like I'm going to be scorned and flamed for asking the most painfully obvious question, but here goes anyways...

Why don't they just ship the required dependencies with the game? Isn't that what they do with windows?

[Maximum Napkin]

Nguyên văn bởi 🐭:

I feel like I'm going to be scorned and flamed for asking the most painfully obvious question, but here goes anyways...

Why don't they just ship the required dependencies with the game? Isn't that what they do with windows?

That's pretty much exactly what these new packaging formats do, everything the program needs can be bundled together in one file.

The older approach based on "dynamic linking"[en.wikipedia.org] is useful for a few reasons: any time two or more programs need to use the same libraries (say for drawing graphics or UI widgets, making network connections, file management, etc) the OS only needs to have one copy of the library installed, instead of each program having its own duplicate taking up space on the drive. This also means that if a security issue is discovered in one of those libraries, it can be upgraded in one place by the system package manager, and every application that uses it automatically gets the security fix without the users or developers having to change anything.

Static linking[en.wikipedia.org] is when those dependency libraries are compiled directly into the application executable. This way the OS doesn't need to have a shared copy installed separately, which is useful if the application and OS have conflicting requirements (version A of the library doesn't work for apps that were built for version B), but you don't get the convenient security upgrades and have to live with potentially redundant copies of the libraries taking up disk space.

These days disk space is a lot cheaper than it used to be so the redundancy is less of an issue, and unlike the open source software in linux distros, games tend to reach a point where they don't get updated anymore (or can't be, if the source is lost), so if the version of the library they were written for stops being supported/gets replaced by an incompatible newer version, the game stops working unless they did ship *everything* they needed with the game.

Most games that have linux versions will typically ship with *most* of what they need, but there are some things are usually left out and are assumed to be present as part of the standard OS install, think basic stuff like the file picker widget or low level like the library for opening a window on the screen to render into, or handling raw gamepad inputs. The devs might target a specific version of a distribution, say Ubuntu 16.04, and not bother to ship with those system libraries.

Windows has never (until recently anyway) had a real framework for managing applications and their shared library dependencies in manner as structured and widely adopted as the deb/rpm packaging ecosystems, so the usual approach is always to target some minimum version of Windows and then ship every other library with the application. This is part of why it's so common to see apps installing their own versions of Microsoft Visual C++ Redistributable packages instead of just recognizing that a compatible version is already available (I think this specific case might've gotten smarter, but it's been a while since I looked at it).

The new formats, Snap and Flatpack a little more than AppImage, try to give us a way to strike a balance that works better for devs and users both. A dev can package absolutely everything into one package and users can have more confidence that it'll continue to work when they upgrade their system, and with only a little more effort (but still less than a traditional rpm/deb package for every distro would be) they can specify that they need a standard "runtime" that can be shared between several apps and safely updated. For example that 16.04 app can specify that it expects to have the standard libraries from Ubuntu 16.04, and even if I'm on 20.04 I can have a Flatpack package with just those 16.04 compatible versions for my old games, and all the newer apps can use the new versions.

[Kasiandra]

@slouken isn't there a way to build it on my own, a documentation, something that I don't need to install flatpak, which need 10x more disk space?

[slouken]

Nguyên văn bởi ETA Elekontroll:

@slouken isn't there a way to build it on my own, a documentation, something that I don't need to install flatpak, which need 10x more disk space?

The archive the flatpak is built from is documented here:
https://github.com/flathub/com.valvesoftware.SteamLink/blob/master/com.valvesoftware.SteamLink.yml

For the current release, you can see that it's built from:
https://repo.steampowered.com/steamlink/1.1.80.197/steamlink-1.1.80.197.tgz

You'll have to build your own Qt, including the patches referenced in the yml file, but it's possible to set it up on your own system for personal use.

[Mechanical]

It should be possible to set up a small ubuntu(linux) VM and play some games over LAN while in Offline Mode.

The way it works is both the Host Machine and the VM install Steam and log into the same Account. The VM Downloads the desired Game while the HOST OS goes Offline Mode.

Then after Initialisation and confirmation (run the game one time to check) that the Game runs on your VM switch it to Offline mode as well.

With both your Offline Mode devices you can still use Steam Link App via Android since its directed through your LAN/WLAN.

Connect one Tablet/Phone to the Host machine. Connect a second device to your VM.

You could play most games that require a PC on multiple VMs if your System can handle it.
Old games dont even require a good resolution, so you can minimize the graphical effort while Installing a clean VM only containing the Linux OS and Steam as well as the Game.

Then you could technically use the Touch screen Device to render the VMs Window.
Setting the resolution to low even improves visibility on smaller screens so that is completely fine.

Did anyone tinker around with VMs to run a SteamOS? What would be the minimium requirements to have it run smoothly?

[jayjr1105]

Just curious and excuse the ignorance but can't you just stream to your linux machine using the regular steam app in big picture mode?

[Rohaq]

Nguyên văn bởi jayjr1105:

Just curious and excuse the ignorance but can't you just stream to your linux machine using the regular steam app in big picture mode?

Not everybody wants to run the full-fat Steam client just to stream games from their main machine.

[Mechanical]

The way I meant was setting up a small enough VM that has got enough dedicated resources to run that just stable enough. Im not talking about GPU igniting software.

[Abu Bakr Al-Swagdadi]

+1 to the aarch64 Flatpak and +1 to the AMD hardware encoding on Linux

[FesterJester]

I am having some difficulty installing this Flatpak.
Running Raspberry Pi OS 64-bit released Jan 28 2022.
I have done all updates and installed Flatpak per the directions on the Flatpak website, but when I run the command to install it I get the following error "error: No remote refs found similar to ‘com.valvesoftware.SteamLink’"

I tried the older method of installing SteamLink on Raspberry Pi OS using APT, but it appears that the current version of Raspberry Pi OS uses Wayland instead of X11.

[Adil3tr]

I tried this on the steam deck to control a PC but there was a very strange issue where pressing any button would double press it. So moving through the UI for example would jump two items at a time, and clicking the UI for shutdown/options just shut down big picture and streaming.

[slouken]

Nguyên văn bởi Adil3tr:

I tried this on the steam deck to control a PC but there was a very strange issue where pressing any button would double press it. So moving through the UI for example would jump two items at a time, and clicking the UI for shutdown/options just shut down big picture and streaming.

That's because Steam is providing a duplicate controller on Steam Deck for games that don't support the Steam Controller. If you shut down Steam it'll work the way you'd expect.

[Adil3tr]

Nguyên văn bởi slouken:

Nguyên văn bởi Adil3tr:

I tried this on the steam deck to control a PC but there was a very strange issue where pressing any button would double press it. So moving through the UI for example would jump two items at a time, and clicking the UI for shutdown/options just shut down big picture and streaming.

That's because Steam is providing a duplicate controller on Steam Deck for games that don't support the Steam Controller. If you shut down Steam it'll work the way you'd expect.

I'm sorry, I don't understand what you mean. I added Steam Link to my steam library, I open it and start streaming my PC to my deck, and it has this double controller issue. If I close steam on my PC then streaming ends. if you mean close steam on my deck in game mode, how do I do that?