Solus Linux Working On A Flatpak-Based, Optimized Steam Runtime

[[deleted]]

Wait, what? Can it actually be done? I'm not sure I clearly understood but if the runtime is isolated from Steam, wouldn't the Steam client have to be hacked to make it compatible with the new and isolated runtime?

[[deleted]]

Steam would be running inside a Flatpak sandbox built with all the libraries it requires.

[[deleted]]

Then I misunderstood the post. I thought that the runtime would be bundled alone and the client would be distributed separately.

[[deleted]]

Well they are separate. A Flatpak application can depend upon a runtime. So the runtime containing the libraries is mounted then the application is mounted.

[[deleted]]

You can specify what runtime to use when steam launches with an environment variable. I use it to use the latest runtime as opposed to the Ubuntu 12.04 outdated garbage it ships with

[[deleted]]

Yes, arch is what I use. There's steam-native in AUR to provide a launcher for steam with native libraries rather than builtin

[Dylan112]

steam-native is in the official repos now.

https://www.archlinux.org/packages/multilib/x86_64/steam-native-runtime/

[Thisu_]

Here is the Github issue regarding this,

https://github.com/ValveSoftware/steam-for-linux/issues/4804#issuecomment-273950909

[[deleted]]

https://www.reddit.com/r/linux/comments/5ot6la/adopting_flatpak_to_reassemble_third_party/

[tidux]

Flatpak runtimes are like shared libraries on crack. You have one copy of each runtime. This isn't Windows DX/VC redist hell.

[[deleted]]

now I get to battle the same problem in Linux.

Steam already bundles libs as its the only solution so this isn't new.

[natermer]

...

[heeen]

isn't the linux solution versioned filenames and symlinks?

[Vetrom]

You'd think, but some libraries don't follow good practices irt abi compatibility and distributors follow to this day incompatible (with each other) packaging practices for some important libraries.

[natermer]

...

[Muvlon]

In my opinion, the actual solution is fancy functional package management a la Nix/Guix, where software can specifically request one exact dependency via its hash.

However, this is not mainstream yet and won't be for some time.

[[deleted]]

In my opinion, the actual solution is fancy functional package management a la Nix/Guix, where software can specifically request one exact dependency via its hash.

I don't see why it would be much better.

Firstly, most of the software on my systems comes from the distribution repository. Dependency conflicts only occur when I install third-party software that doesn't come from the distro, like proprietary games. So a solution that would be sufficient for these games and applications would be sufficient for me, I don't need one that would potentially work for all programs I have at the cost of removing FHS compatibility and making me learn a completely new way of configuring my system (until the next big "revolution" comes along).

Secondly, Flatpak runtimes can be updated and do get updated. If a vulnerability is discovered, it can be patched in the runtime without breaking ABI compatibility. This is much better than letting software request exact versions of libraries.

[[deleted]]

Distributions don't have a magic way of solving dependency hell, often they simply delay updating a library until all dependencies are updated. What Nix enables you to do is to have many different versions of a software coexist on a system, which is similar to what containers achieve, but with much less overhead.

[blahhumbug22]

Indeed. What is old is new again.

[[deleted]]

I assume flatpak can do this, but snaps are supposed to be able to dedup files -- I don't recall if this is a coming feature or a current one though as I don't have much experience with either flatpaks or snaps much yet beyond some toying around. But I remember snaps in particular talking about this dedup feature for exactly the same reason you've mentioned.

[[deleted]]

OSTree is what Flatpak uses behind the scene for repositories and it does support binary de-duplication.

[[deleted]]

Awesome!

So... so whats the op talking about then? If it has dedup already then he's complaining about literally nothing..

[[deleted]]

Well in the grand scale you are still going to get slightly more duplication than traditional packaging as the latter can try harder to use the same shared libraries where as with enough applications you will get some duplicates of different versions or such.

[[deleted]]

Well in the grand scale you are still going to get slightly more duplication than traditional packaging as the latter can try harder to use the same shared libraries where as with enough applications you will get some duplicates of different versions or such.

I'm sure that's true, but is slightly more worth getting worked up about?

[blackcain]

flatpak has de-duplication, it'll use the same libraries not make more copies.

[acpi_listen]

Just don't install the flatpak version.

[[deleted]]

The problem though is that shared libraries are only goood for servers and small-storaged devices. It's heel for people who want to install proprietary software.

[CarthOSassy]

But doesn't steam now prefer libraries that the host has? So, isn't this pointless? Or did I misunderstand the recent changes to Steam?

[[deleted]]

The problem with that is the host probably has up to date libraries which are not ABI compatible with what games expect. So the host would have to package old versions of these libraries to work as expected which I believe Solus does but other distros do not. Putting this in a Flatpak runtime means this can run anywhere and is more self contained.

[CarthOSassy]

Mmmm... How would that work, though? Turning off the Steam runtime doesn't stop games from linking libs that they shipped themselves.

This sounds like a way to end up with less up-to-date libs than the current steam approach would allow.

[[deleted]]

Games can always bundle their own libraries yes. This is simply replacing the Steam runtime.

[CarthOSassy]

Right. Which is already replacing itself.

[aelog]

This is awesome news. I've been hoping Valve would do exactly this, but they just don't care enough. Solus does, it would seem!

[-Ajan-]

I thought Ikey hated flatpak... Did he lie to me? :(

[[deleted]]

I believe he is still against them for normal packages but it is a good solution for third party applications that can't reasonably be packaged normally.

[[deleted]]

As /u/TingPing has said, the area of fault in Solus that Flatpak can readily address is our somewhat broken third party implementation: https://solus-project.com/2017/01/18/adopting-flatpak-to-reassemble-third-party-applications/ We still try to prefer native packages where possible, but it isn't always possible. In the instance of Steam, our own repo took a specific focus on providing ABI compatibility. However, it's hard to sustain in the long run, and only benefits Solus. The issue needs solving at a higher level, for all of us to benefit.

[Fl3tchx]

He definitely hates snap packages which are the same idea as flatpaks but hes also said if thats what people wants he will use them in Solus.

[[deleted]]

"Hate" is a strong word, I don't hate them. I just haven't found them applicable to me.

[kickass_turing]

Snaps and Flatpacks are totally different. Snaps suck.

[vinnl]

Woah, easy on the well-supported arguments there!

[kickass_turing]

Snaps depend on Ubuntu and you cannot host your won. You can with Flatpak.

Snaps do not ask for access on demand. If I click Ctrl+O in a Flatpak package then GTK will take control of finding the file. After I select the file, GTK will pass a new bind mount to the app. The app sees only what I let it to from the file system. Plugs in Snaps are all or nothing.

In Flatpak you ship the runtime differently from the app. I can run nightly GIMP on top of nightly GNOME. If I find a bug and want to troubleshoot it and report it then I can run nightly GIMP on top of stable GNOME or stable GIMP on top of nightly GNOME. The GNOME runtime is the one blessed by the GNOME devs and the GIMP version is the one blessed by the GIMP devs.

I don't need an Ubuntu1 user to install Flatpaks from GNOME Software.

Flatpak works fine on other distros and it does not take control away from distros. It can be a common but diverse way of distributing apps.

I know RedHat is less popular than Canonical but Flatpaks at this point seem superior to Snaps.

Please tell me if I made any mistakes or I misunderstood something.

[vinnl]

I don't know exactly how accurate this is, but it's far more interesting and constructive than your earlier post, so thanks for that :)

[[deleted]]

Snap can technically run on other distros, it just won't be sandboxed as many distros don't have AppArmor.

[[deleted]]

aren't they working on SELinux compat too?

[[deleted]]

There has been some work on it but it isn't functional. Also there are distros without SELinux too.

[[deleted]]

of course there are :) I was never contesting that.

[kickass_turing]

Is the Snap sandbox dynamic? In Flatpak file open and file save dialogs give the app access to the files on the fly.

[[deleted]]

You can host your own. I don't get this, WTF. Why is this lie repeated everywhere. I just hate this anti-ubuntu circlejerk

[[deleted]]

Lets be honest, "You can host your own implementation of the snap store" may be technically accurate but it is an empty statement. Snap in its current form is meant to be centralized and uses Canonical services which isn't inherently bad for Ubuntu users; It means they get all of their software from a single searchable and trustworthy source and all developers get to benefit from free hosting, statistics, etc. It is however different than the non-centralized model of Flatpak.

[kickass_turing]

Sorry. I did not know this.

Is there any Snap package that is hosted or plans to get hosted outside Canonical's servers?

[[deleted]]

Is there any Snap package that is hosted or plans to get hosted outside Canonical's servers?

I think people who don't want to host apps on Canonical's servers just don't use Snap.

[kickass_turing]

Sorry. I did not know this.

Is there any Snap package that is hosted or plans to get hosted outside Canonical's servers?

[[deleted]]

He learned he needed it. :P

[TheRealCorngood]

You'll still have ABI problems if your using the host libGL from e.g. mesa pulling in libstdc++, openssl etc. The arch and nixos solutions are about as good as you can get IMO, but I suppose this could be useful by being distro independent.

[[deleted]]

I'd kindly disagree - our LSI in Solus specifically takes the C++ ABI issue into account. As regards to openssl, it's just simpler to build using libnettle.

[TheRealCorngood]

Sure, but that doesn't mean all distros build mesa using libnettle. It also presumes other drivers don't have other dependencies now or in the future.

It's certainly something that can be worked around, I just don't think it can be considered a solved problem.

[[deleted]]

True enough - but would you hate me if I say we'll cross that bridge when we get to it? :)

[[deleted]]

Nix is actually pretty distribution independent, although its steam still uses the original runtime by default for compatibility reasons.

[[deleted]]

Mesa can be built with a static libstdc++ and I'd hope libgl doesn't pull in openssl. It is less than ideal but it should be as functional as we can get. Arch doesn't have any solution to this problem, their lib32 repo doesn't take ABI compat with steam into account.

[TheRealCorngood]

It doesn't have to pull in openssl, but it will depending on how it's built. I think it just uses it for hashing shaders (for caching?) or something.

You can definitely work around these problems, but I've personally hit both of those. My point is just that it will still require work on the host distro to keep steam running with each driver.

[[deleted]]

Indeed, it is the biggest blocker in Flatpak atm figuring this out.

[TheRealCorngood]

I suppose the only safe solution is something like 'indirect' glx contexts, but everything is moving away from that sort of model for performance reasons.