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.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
soulsource Oct 16, 2017
Quoting: ikeyQuoting: 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.
1 Likes, Who?
GoLBuzzkill Oct 16, 2017
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
---
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
0 Likes
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"..
3 Likes, Who?
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 ofyearsmonths 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!
0 Likes
slaapliedje Oct 16, 2017
Quoting: jensQuoting: 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 +0200Drop 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
1 Likes, Who?
slaapliedje Oct 16, 2017
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.
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.
0 Likes
Quoting: slaapliedjeDrop d/p/09_default_session.patch: Start the "gnome" session by default,Thanks for the confirmation. How very progressive of Debian ;)
"default" is always starting a X11 session but we want to start a Wayland
one starting from now.
0 Likes
GoLBuzzkill Oct 16, 2017
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)
0 Likes
Quoting: slaapliedjeQuoting: jensQuoting: 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.
0 Likes
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
0 Likes
Patreon
PayPal
See more from me