Support us on Patreon to keep GamingOnLinux alive. This ensures all of our main content remains free for everyone. Just good, fresh content! Alternatively, you can donate through PayPal. You can also buy games using our partner links for GOG and Humble Store.
We do often include affiliate links to earn us some pennies. See more here.

The Solus distribution [Official Site] developers are a clever bunch, with their Linux Steam Integration [GitHub] software package and snaps, they are hoping to "relieve the pressure on distributions for supporting gaming".

When I say snaps, I'm talking the snap package system, specifically from version 2.28 onwards which supports something called "base" snaps. You can read more about the idea behind base snaps here.

Here's why they're doing it:

It's time to relieve the pressure on distributions for supporting gaming, by doing so through a single point of entry. A snapped LSI will ensure that the Steam/LSI combo would work identically on every distribution, *even if they don't support multilib*. It also ensures we can provide a "perfect" runtime, but ensure its up to date, optimised, and configured explicitly to support LSI & Steam.

If you're after an explanation in the most simple of terms, they have you covered:

TLDR: Single Steam/LSI image that takes all of the Solus gaming/Steam work, and provides it for everyone, on any distro.

They're also building a tool to debug the runtime, so they can ensure "ABI compatibility" with Steam and games themselves.

I certainly appreciate what they're doing, so it will be interesting to see what becomes of this. Perhaps in future this might help Valve directly with Steam, who knows what will happen.

On top of that, they recently released a new version of their Linux Steam Integration, which includes a new "vendor offender" mode, which can help games on open source drivers.

You can see the full post on G+ here. What do you think to this?

Article taken from GamingOnLinux.com.
Tags: Misc, Steam
20 Likes
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly. Find me on Mastodon.
See more from me
The comments on this article are closed.
48 comments
Page: «3/5»
  Go to:

ikey Oct 14, 2017
Quoting: dvdI don't get why i should be excited about this, seems like all these flatpaks/whatever other name this runs on increase complexity and solve nothing, if i wanted paranoid level security i believe cubes os does a far better job at isolation. Based on what i read about these so far, i don't get why the status quo is so bad.

This has very little to do with security, although the way security critical libraries are vendored with games, its not a point to ignore. This is more about providing a complete runtime, instead of a mixed runtime, to ensure all games work properly.
mcphail Oct 14, 2017
For everyone who doubts why we need a Steam snap, please remember:

https://github.com/ValveSoftware/steam-for-linux/issues/4768 - a longstanding ABI incompatibility with Mesa

https://github.com/ValveSoftware/steam-for-linux/issues/3671 - a badly written Steam shell script could delete everything in the home directory

A combination of ikey's core snap and a carefully confined Steam snap could prevent similar problems in the future.
soulsource Oct 14, 2017
This does not solve any issues, just creates more. Using a Flatpak or Snap package is basically the same thing as the Steam Runtime (which by itself was a bad idea already...).
The ABI incompatibility with Mesa is a prime example of issues caused by such an approach, as it was actually an error on the side of the Steam Runtime, and if one would make the same mistake within a Flatpak/Snap package, one would see exactly the same issue.
If people would just rtfm... It is clearly stated, that "The reverse (backwards compatibility) is not true. It is not possible to take program binaries linked with the latest version of a library binary in a release series (with additional symbols added), substitute in the initial release of the library binary, and remain link compatible."
slaapliedje Oct 15, 2017
Quoting: appetrosyan
Quoting: ZlopezAs far as I know the snap is only supported by Ubuntu, other distributions wants to use Flatpak. And the Flatpak package for Steam is already worked on GitHub

The rpm family don't contribute to the development, but they do put effort into snap compatibility. Debian family is far more extensive, so they have equal footing on "neutral territory" (e.g. Arch or Gentoo).

QuoteI wonder why Canonical always wants to have something special that is not used in nowhere else (See: Unity, Mir ...)

It's natural.

If you have a piece of software, you like the idea, but want to make a few tweaks - go for it. You could ask in the same way, why do different distributions have different package managers. Arch wouldn't be arch if it ran on rpm or deb, which is why it has pacman. Gentoo has need for clever update scheduling, so it has emerge.

Snaps serve to replace two features of the rpm family - flatpak (for desktop app distribution) and Atomic updates (for rigid system management). SSo it makes sense to fork and create something.

Not to mention Snap and Flatpak are only two of about ten "universal" package formats.

But I get why you ask. The two distro families have different strategies:

Red Hat makes sure everyone in the Linux world uses their software, even if it isn't that great (e.g. Gnome).

Canonical, makes sure as few distros as possible can support their work, even if there's no need to couple their code so tightly.

As a result, Unity, runs almost exclusively on Ubuntu, and Gnome Shell runs on everything else, so we get the feeling that the latter is better. In reality, Unity is a great DE, it just happens to be tied to Ubuntu. Which is why Canonical were alone in developing it, went all in, and eventually killed the project off.

If Canonical were a little more giving, and Red Hat were more reserved, we'd have a much more balanced ecosystem.

You have that a bit wrong. The reason that other distributions don't adopt things Canonical creates is because they have their own form of licensing they attach to their projects that people don't agree with. Someone managed to get Unity to work on Arch for example. But Canonical seems to want to take Linux their own way instead of contributing to the "greater good". Like instead of giving resources to Wayland, they wasted time creating Mir..
t3g Oct 15, 2017
Thanks Ikey!
appetrosyan Oct 15, 2017
Quoting: slaapliedje
Quoting: appetrosyan
Quoting: ZlopezAs far as I know the snap is only supported by Ubuntu, other distributions wants to use Flatpak. And the Flatpak package for Steam is already worked on GitHub

The rpm family don't contribute to the development, but they do put effort into snap compatibility. Debian family is far more extensive, so they have equal footing on "neutral territory" (e.g. Arch or Gentoo).

QuoteI wonder why Canonical always wants to have something special that is not used in nowhere else (See: Unity, Mir ...)

It's natural.

If you have a piece of software, you like the idea, but want to make a few tweaks - go for it. You could ask in the same way, why do different distributions have different package managers. Arch wouldn't be arch if it ran on rpm or deb, which is why it has pacman. Gentoo has need for clever update scheduling, so it has emerge.

Snaps serve to replace two features of the rpm family - flatpak (for desktop app distribution) and Atomic updates (for rigid system management). SSo it makes sense to fork and create something.

Not to mention Snap and Flatpak are only two of about ten "universal" package formats.

But I get why you ask. The two distro families have different strategies:

Red Hat makes sure everyone in the Linux world uses their software, even if it isn't that great (e.g. Gnome).

Canonical, makes sure as few distros as possible can support their work, even if there's no need to couple their code so tightly.

As a result, Unity, runs almost exclusively on Ubuntu, and Gnome Shell runs on everything else, so we get the feeling that the latter is better. In reality, Unity is a great DE, it just happens to be tied to Ubuntu. Which is why Canonical were alone in developing it, went all in, and eventually killed the project off.

If Canonical were a little more giving, and Red Hat were more reserved, we'd have a much more balanced ecosystem.

You have that a bit wrong. The reason that other distributions don't adopt things Canonical creates is because they have their own form of licensing they attach to their projects that people don't agree with. Someone managed to get Unity to work on Arch for example. But Canonical seems to want to take Linux their own way instead of contributing to the "greater good". Like instead of giving resources to Wayland, they wasted time creating Mir..

True, I completely forgot about the licensing. Ubuntu have of course joined forces, and maybe that's a good thing.

I would say that maybe Wayland is a huge mistake that we're going to regret, but time will tell. I don't like where it's going. I've spent an entire day, trying to figure out, how to get the active window's title under Wayland. Turns out, There isn't any. It's deprecated, as a security measure.

Of course cybersecuirty is important. It's just that a system's overall security is given by its weakest point, and keylogging on (of all things) Linux, is the least of my concerns. It's like prescribing exercise to a burn victim. And they didn't seem to be interested in exposing an API to do what is perfectly possible on X.org.

What I hope is that Canonical would be the voice of reason.
ikey Oct 15, 2017
Quoting: soulsourceThis does not solve any issues, just creates more. Using a Flatpak or Snap package is basically the same thing as the Steam Runtime (which by itself was a bad idea already...).
The ABI incompatibility with Mesa is a prime example of issues caused by such an approach, as it was actually an error on the side of the Steam Runtime, and if one would make the same mistake within a Flatpak/Snap package, one would see exactly the same issue.
If people would just rtfm... It is clearly stated, that "The reverse (backwards compatibility) is not true. It is not possible to take program binaries linked with the latest version of a library binary in a release series (with additional symbols added), substitute in the initial release of the library binary, and remain link compatible."

It solves the issues specifically because it does away with the current problem we have of **mixed** runtimes, and instead provides a single consistent runtime with full ABI consistency, without being affected or influenced by host libraries. At that point Steam would be running in an environment specifically created to run Steam and the Steam games.

You're also looking at it from the wrong angle, we're not trying to put the older ones in, we're putting the **newer** ones in and ensuring they remain consistent. We then also have fine grained control over what can and cannot be vendored by games via LSI, and disable use of the binary runtime provided by Steam themselves.
slaapliedje Oct 15, 2017
Quoting: appetrosyan
Quoting: slaapliedje
Quoting: appetrosyan
Quoting: ZlopezAs far as I know the snap is only supported by Ubuntu, other distributions wants to use Flatpak. And the Flatpak package for Steam is already worked on GitHub

The rpm family don't contribute to the development, but they do put effort into snap compatibility. Debian family is far more extensive, so they have equal footing on "neutral territory" (e.g. Arch or Gentoo).

QuoteI wonder why Canonical always wants to have something special that is not used in nowhere else (See: Unity, Mir ...)

It's natural.

If you have a piece of software, you like the idea, but want to make a few tweaks - go for it. You could ask in the same way, why do different distributions have different package managers. Arch wouldn't be arch if it ran on rpm or deb, which is why it has pacman. Gentoo has need for clever update scheduling, so it has emerge.

Snaps serve to replace two features of the rpm family - flatpak (for desktop app distribution) and Atomic updates (for rigid system management). SSo it makes sense to fork and create something.

Not to mention Snap and Flatpak are only two of about ten "universal" package formats.

But I get why you ask. The two distro families have different strategies:

Red Hat makes sure everyone in the Linux world uses their software, even if it isn't that great (e.g. Gnome).

Canonical, makes sure as few distros as possible can support their work, even if there's no need to couple their code so tightly.

As a result, Unity, runs almost exclusively on Ubuntu, and Gnome Shell runs on everything else, so we get the feeling that the latter is better. In reality, Unity is a great DE, it just happens to be tied to Ubuntu. Which is why Canonical were alone in developing it, went all in, and eventually killed the project off.

If Canonical were a little more giving, and Red Hat were more reserved, we'd have a much more balanced ecosystem.

You have that a bit wrong. The reason that other distributions don't adopt things Canonical creates is because they have their own form of licensing they attach to their projects that people don't agree with. Someone managed to get Unity to work on Arch for example. But Canonical seems to want to take Linux their own way instead of contributing to the "greater good". Like instead of giving resources to Wayland, they wasted time creating Mir..

True, I completely forgot about the licensing. Ubuntu have of course joined forces, and maybe that's a good thing.

I would say that maybe Wayland is a huge mistake that we're going to regret, but time will tell. I don't like where it's going. I've spent an entire day, trying to figure out, how to get the active window's title under Wayland. Turns out, There isn't any. It's deprecated, as a security measure.

Of course cybersecuirty is important. It's just that a system's overall security is given by its weakest point, and keylogging on (of all things) Linux, is the least of my concerns. It's like prescribing exercise to a burn victim. And they didn't seem to be interested in exposing an API to do what is perfectly possible on X.org.

What I hope is that Canonical would be the voice of reason.

My problems with Wayland are similar. That and there are unnecessary pushes to force people to use it when it clearly isn't ready. Debian a while back had changed the default session for gdm to start Gnome Shell with Wayland. Couldn't figure out why my Xorg clipboard wasn't working between a GTK and Qt app like it used to. Sure enough it was because I was using Wayland. I am all for the supposed speed increases, and security features. But it still needs compatibility and feature parity with Xorg first. I still remember the painful transistion from XFree86 to X.org, and that wasn't even protocol changes or anything, just a fork to make it more modularized!
jens Oct 15, 2017
  • Supporter
Quoting: slaapliedjeMy problems with Wayland are similar. That and there are unnecessary pushes to force people to use it when it clearly isn't ready. Debian a while back had changed the default session for gdm to start Gnome Shell with Wayland.
Are you sure Debian did this, I would not expect such move from them?
Fedora did the same a few releases back. The decision to switching default to Wayland is a tough one. At some point you need to release software and bring in into the field, otherwise it wont mature at all. For a distribution like Fedora, being bleeding edge everywhere, this seems a valid move. More stable distributions like Debian should indeed hold back for a while.


Last edited by jens on 15 October 2017 at 8:24 pm UTC
qptain Nemo Oct 15, 2017
Quoting: appetrosyanI would say that maybe Wayland is a huge mistake that we're going to regret, but time will tell. I don't like where it's going. I've spent an entire day, trying to figure out, how to get the active window's title under Wayland. Turns out, There isn't any. It's deprecated, as a security measure.

Of course cybersecuirty is important. It's just that a system's overall security is given by its weakest point, and keylogging on (of all things) Linux, is the least of my concerns. It's like prescribing exercise to a burn victim. And they didn't seem to be interested in exposing an API to do what is perfectly possible on X.org.

What I hope is that Canonical would be the voice of reason.
I have very similar concerns about Wayland after discovering that it removes some essential tools in the name of security, which is applied at the wrong level IMO. If their approaches aren't changed it could "ruin" or much more likely seriously damage the Linux desktop. What kinda desktop experience doesn't allow taking screenshots or setting global shortcuts? And forcing desktop environments to hack around this is both going against the very modularity and interoperability that Linux was built on, and undermining and rendering moot the original security concern.

I know I'm in no rush to switch to Wayland now, I can tell you this much. X can be improved too after all.


Last edited by qptain Nemo on 15 October 2017 at 11:48 pm UTC
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.