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

[yoshi314]

flatpak is definitely how proprietary software ought to be packaged. i hope it becomes a standard, and if not something just as good takes over.

[leipero]

Very interesting, but I'm not sure if flatpak is aplicable to programs like Steam. One of potential problems with it is for games using shared libraries. I remmember playing Trine 2, at the time using fglrx, and performance was just terrible, after replacing some libraries (can't recall names now), I've got perfect gameplay and about 4 times the performance, granted this was likely a problem with fglrx not libs, but still, just one example how things can go wrong with such approach.

For that reason,a s mentioned in article, it needs a lot of work and testing, still very nice and interesting thing, looking forward to it .

[ikey_solus]

Very interesting, but I'm not sure if flatpak is aplicable to programs like Steam. One of potential problems with it is for games using shared libraries. I remmember playing Trine 2, at the time using fglrx, and performance was just terrible, after replacing some libraries (can't recall names now), I've got perfect gameplay and about 4 times the performance, granted this was likely a problem with fglrx not libs, but still, just one example how things can go wrong with such approach.

For that reason,a s mentioned in article, it needs a lot of work and testing, still very nice and interesting thing, looking forward to it .

You've just explained exactly why it *is* applicable. So in Solus we've spent a great deal of time and effort in making sure we provide our own Steam runtime through our own repositories, with the complete emul32 suite available too. We nabbed Clear Linux optimisations and added some in too, enabling per package control of applied optimisations in hot spots. We also went the extra step to provide ABI compatibility through some stub packages (can't build against them), and created LSI to solve the startup linker issues and enforce use of the native runtime.

That's great and all, but only Solus truly benefits. Now the time comes to bring this proof of concept to the next level and share it with the Linux world at large, solving the ABI problems, providing a fully robust ABI compatible runtime for Steam that everyone benefits from. We can also be more aggressive about optimising this as there is no host fallout to consider. Work is being done by others to solve the issue of using host side libGL with a bit of magic to solve the final part of the puzzle. This basically means supporting distributions only need to support a multilib mesa or multilib NVIDIA for example, without the full suite. Then they leverage the new runtime as a dependency of the Steam flatpak.

https://plus.google.com/+IkeyDoherty/posts/iydBbbHA5ge?sfc=false

Obviously we'll work with as many as we can here to perfect and test this, and it's already creating quite the buzz of conversation, centralising the discussion, which is what we've needed for some time.

[Jumbotron]

You've just explained exactly why it *is* applicable. So in Solus we've spent a great deal of time and effort in making sure we provide our own Steam runtime through our own repositories, with the complete emul32 suite available too. We nabbed Clear Linux optimisations and added some in too, enabling per package control of applied optimisations in hot spots. We also went the extra step to provide ABI compatibility through some stub packages (can't build against them), and created LSI to solve the startup linker issues and enforce use of the native runtime.

That's great and all, but only Solus truly benefits. Now the time comes to bring this proof of concept to the next level and share it with the Linux world at large, solving the ABI problems, providing a fully robust ABI compatible runtime for Steam that everyone benefits from. We can also be more aggressive about optimising this as there is no host fallout to consider. Work is being done by others to solve the issue of using host side libGL with a bit of magic to solve the final part of the puzzle. This basically means supporting distributions only need to support a multilib mesa or multilib NVIDIA for example, without the full suite. Then they leverage the new runtime as a dependency of the Steam flatpak.

https://plus.google.com/+IkeyDoherty/posts/iydBbbHA5ge?sfc=false

Obviously we'll work with as many as we can here to perfect and test this, and it's already creating quite the buzz of conversation, centralising the discussion, which is what we've needed for some time.

As a long time Linux Mint user.....I think I know what I am about to burn some of my data plan for. Firing up download in 3...2...1....

[LEW21]

The Right Way, actually, is not to use host GL library, but to put Mesa + nvidia's library inside the runtime, and rely on the kernel's userspace API stability.

Mesa's libGL requires libstdc++, and potentially other libs that can conflict with the libs from the runtime - and that's why Steam Runtime breaks constantly on ArchLinux.

[ikey_solus]

The Right Way, actually, is not to use host GL library, but to put Mesa + nvidia's library inside the runtime, and rely on the kernel's userspace API stability.

Mesa's libGL requires libstdc++, and potentially other libs that can conflict with the libs from the runtime - and that's why Steam Runtime breaks constantly on ArchLinux.

And doesn't in Solus. Which has used the new C++ ABI for a long time and we're on GCC 6.3.0 with constant rebuilds. I've been doing this kind of stuff for a while now

[Sethox]

Most of what I've read about it looks good. It's hard to switch distros (since you're essentially installing from scratch) but I'm going to give it a try soon maybe in a VM or on a blank disk. Only things up in the air for me would be repos / software and the DE. (I'm not a fan of Unity or G3 myself so maybe Budgie is an improvement.)

A bit complicated but at least it's an idea to ease up on another distro. Install the distro on a physical harddrive, and on the OS you are in (standard) run a VM on that harddrive you want to test your distro on.
It's a stupid way to go but then again it's to ease up to another distro, well after you actually tested the distro in a VM (in the regular way).

[M@yeulC]

The Right Way, actually, is not to use host GL library, but to put Mesa + nvidia's library inside the runtime, and rely on the kernel's userspace API stability.

Mesa's libGL requires libstdc++, and potentially other libs that can conflict with the libs from the runtime - and that's why Steam Runtime breaks constantly on ArchLinux.

Oh, no, I want to be able to update my driver for the new goodies.
An interfacing library can maintain ABI, that's a nice solution.

[zoomblab]

I don't understand the fuss with solus. From what I have seen it is a huge waste of time reinventing the wheels that have already been reinvented so many times in the Linux space. It is supposed to be independent, however in the worst possible ways. First and foremost they have choosen to use yet another package format and their own package repositories. Like we hadn't already too many centralized silos of software repositories. Secondly bungie. It is yet another environment based on Gnome technology but different. I can sympathize how and why this needs to exist. Personally I have criticized Gnome 3 a lot. It is the worst desktop environment ever in every aspect and that has left the room for all the countless attempts that seem to believe they can provide better user workflows and experience. However, unless they also have a big financial backing, all such efforts are doomed to fail IMO. That includes elementary, cinamon, whatever.

These are the reasons I think that Valve won't and shouldn't become involved efforts like Solus. Not because they are bad, but because it is a waste of energy. Instead, I think that the best Valve could do is make a strategic alliance with a dominant desktop distributor, like Canonical, work together in alignment and create synergies that can drive the adoption of desktop linux to the masses. They are already so close, since both efforts are based on Debian roots, that I believe it will be a shame if they don't.

[nanonyme]

Pseudo-WinSxS almost 20 years after WinSxS. It'll work, it's proven itself, it's still being used today.

Microsoft recommends against using side-by-side assemblies where alternatives exist though