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

Quoting: ikey

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.

Wait a second, you are saying, you ship a complete runtime inside the Snap, without a single dependency on the outside system? That then indeed solves the linking inconsistency, at the cost of size and possible security issues.

OMFG Flatpacks, Snaps, Dockers, containers... Developers should know what does their application use and ship it together with application in this case game, with a option for a user to overide it and use system libs, and when couple of years months passes and developers dont give a shit about updating, something breaks, user can still use outdated libs that are shipped with a game. No fucking need for snappy, flappy, dockyy and other in this scenario useless stuff.
---
And if devs really want to be hardcore, they can ACTUALLY SUPPORT LINUX/FLOSS, and update their game with new version of libs if something breaks or if there is security issue, in 99.99% of cases they just need to ship updated version of lib in 0.01% of cases recompilation will be required and in insignificant number of cases they may actually need to change their code; WOW it is so hard to support Linux.
---
Valve really fucked things up with Steam runtime, SteamOS and 32bit client and it is a proof that they dont know what they are doing, it is fine on Windows where M$ does all the work to be backward compatible; on FLOSS if you keep your source closed you need to do that work and if you open it up users/packagers/community will do that work, it is soo simple i dont know why noone gets it.


Last edited by GoLBuzzkill on 16 October 2017 at 9:21 am UTC

Quoting: soulsourceWait a second, you are saying, you ship a complete runtime inside the Snap, without a single dependency on the outside system? That then indeed solves the linking inconsistency, at the cost of size and possible security issues.

That's the plan, but refreshed as part of CI processes to tie in with Solus syncs. In theory LSI actually makes
the games more secure, you should look at this blacklist we have in place for vendored libraries.. https://github.com/solus-project/linux-steam-integration/blob/master/src/intercept/main.c#L122 (due to bundling mechanisms, not strictly the fault of the games)

At that point, perhaps sandboxing from snapd doesn't seem such a bad idea. I am hitting a fly with a bazooka here, but my influence with the relevant projects is no bigger than anyone elses, so I'm offering a way out and a more readily available solution, instead of us relying on good will for things to improve "in time"..

Quoting: GoLBuzzkillOMFG Flatpacks, Snaps, Dockers, containers... Developers should know what does their application use and ship it together with application in this case game, with a option for a user to overide it and use system libs, and when couple of years months passes and developers dont give a shit about updating, something breaks, user can still use outdated libs that are shipped with a game. No fucking need for snappy, flappy, dockyy and other in this scenario useless stuff.
---
And if devs really want to be hardcore, they can ACTUALLY SUPPORT LINUX/FLOSS, and update their game with new version of libs if something breaks or if there is security issue, in 99.99% of cases they just need to ship updated version of lib in 0.01% of cases recompilation will be required and in insignificant number of cases they may actually need to change their code; WOW it is so hard to support Linux.
---
Valve really fucked things up with Steam runtime, SteamOS and 32bit client and it is a proof that they dont know what they are doing, it is fine on Windows where M$ does all the work to be backward compatible; on FLOSS if you keep your source closed you need to do that work and if you open it up users/packagers/community will do that work, it is soo simple i dont know why noone gets it.

Please start your own company and show them all. I'm sure you got what it takes!

Quoting: jens

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.

It was in Debian Sid, they'd never do it in Stable of course. From the gdm3 changelog

gdm3 (3.24.2-2) experimental; urgency=medium

  * Drop d/p/Hack-D-Bus-messages-from-Debian-8-libgdm-to-work-wit.patch now
    that debian Stretch has been released
  * Drop d/p/09_default_session.patch: Start the "gnome" session by default,
    "default" is always starting a X11 session but we want to start a Wayland
    one starting from now.
  * debian/patches/92_systemd_unit.patch: Uncomment the BusName= directive,
    gdm doesn't seem to be killed on reload anymore

 -- Laurent Bigonville <[email protected]>  Thu, 06 Jul 2017 01:30:35 +0200

Drop d/p/09_default_session.patch: Start the "gnome" session by default,
"default" is always starting a X11 session but we want to start a Wayland
one starting from now.


Last edited by slaapliedje on 16 October 2017 at 6:53 pm UTC

So... the whole docker/flatpak/snap thing... Isn't this in essence what .dmg files are on a Mac? The container itself has lots of files in it, but the user only sees the executable file.

Yes this makes re-using system libraries annoying. But unless it's a gtk/qt based launcher, and the SDL libraries themselves, what all shared libraries are used? The OS should be handling input, etc.

The 'oh my god, it's hard to distribute/package software for Linux!' has been debunked years ago, there are automation tools around now that does pretty much all the work.

Quoting: slaapliedjeDrop d/p/09_default_session.patch: Start the "gnome" session by default,
"default" is always starting a X11 session but we want to start a Wayland
one starting from now.

Thanks for the confirmation. How very progressive of Debian ;)

Quoting: slaapliedjeThe 'oh my god, it's hard to distribute/package software for Linux!' has been debunked years ago, there are automation tools around now that does pretty much all the work.

Years ago there where .rpm, .dep and .tgz, now you have clusterfuck. Containerization/virtualization/sandboxing fanatics have a hammer in their hands and they are looking for nails.
(https://en.wikipedia.org/wiki/Law_of_the_instrument#Computer_programming)

Quoting: slaapliedje

Quoting: jens

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.

It was in Debian Sid, they'd never do it in Stable of course. From the gdm3 changelog

gdm3 (3.24.2-2) experimental; urgency=medium

  * Drop d/p/Hack-D-Bus-messages-from-Debian-8-libgdm-to-work-wit.patch now
    that debian Stretch has been released
  * Drop d/p/09_default_session.patch: Start the "gnome" session by default,
    "default" is always starting a X11 session but we want to start a Wayland
    one starting from now.
  * debian/patches/92_systemd_unit.patch: Uncomment the BusName= directive,
    gdm doesn't seem to be killed on reload anymore

 -- Laurent Bigonville <[email protected]>  Thu, 06 Jul 2017 01:30:35 +0200

Drop d/p/09_default_session.patch: Start the "gnome" session by default,
"default" is always starting a X11 session but we want to start a Wayland
one starting from now.

And what's the big deal? Why get upset? It's Debian Sid after all, which is aimed at tech savvy folks who want to participate in development. Upstream GNOME has been doing Wayland as default for ages. Fedora has been doing it for quite a while. Ubuntu 17.10 does it. Arch does it etc... Also, X.org is still provided out of the box and it's incredibly easy to switch back, but if Wayland is ever going to shape up it needs to be pushed by bleeding edge distros.

Quoting: slaapliedjeSo... the whole docker/flatpak/snap thing... Isn't this in essence what .dmg files are on a Mac? The container itself has lots of files in it, but the user only sees the executable file

Remark: I have a lot of experience with Docker, have played a little bit with flatpack and no experience at all wit snap.

Well, you shouldn't compare containers with package formats. While they both serve a similar purpose, bringing software to your machine, the concepts are differently. It is not just about how packaging works, but mostly how it behaves. Isolation and layers are the keywords. Looking at Docker from a functional perspective you'll see more similarities with Virtual Machines, but without the guest OS overhead. Every container runs natively on the host machine, but has its own runtime, own file system and its own network adapter. You are able to run e.g. multiple mariadb/database server containers in different version on the same host with just a few commands (very useful for development when you need to simulate a bigger cluster on a single machine). I strongly advise to play a little bit with docker, it's very easy and once you got the difference between image and container the penny will drop. Flatpack is similar but with focus on UI applications. Same with docker, isolation makes the difference. You can run e.g. run Gnome-MPV on a Gnome 3.26 Runtime and Gnome Twitch on a Gnome 3.24 Runtime without any interference between the flatpaks.

All container solution seems overkill at the beginning, but once you got the gist they aren't. I certainly see the benefits, for both background processes via docker and UI applications via flatpaks.

See also: https://docs.docker.com/get-started/


Last edited by jens on 16 October 2017 at 8:43 pm UTC