The developers of Solus are hoping to improve Linux gaming with snaps and their Linux Steam Integration

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.

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.

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."

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..

Thanks Ikey!

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.

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.

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!

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

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