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?
The performance in game can be increase ?
Quoting: berillionsWhat is the difference between Steam Snap and Steam native (runtime disabled) ?
The performance in game can be increase ?
Improved performance? No. Snap does however run apps in a sandboxed environment, so snap would be more secure than running steam-native.
Quoting: PublicNuisanceBeen using Solus for my main system for a week or so now. Liking it so far.
Absolutely a distro to watch. I think they've said they want to tackle dedicated GPU/Intel dynamic switching at some point, which would be quite awesome...
If it works like Docker, then you don't have to worry about space as much as you'd think. Images are in chunks and they share data (deduplication). So, if you have 20 games that rely on 50% the same base data, you will be saving 50% x 20 images.
That said, there is a little disk price to pay with containers. It is worth it a lot of times. Want to make your own Wordpress website on your own server with ease? Load up a Docker container for the site and another container for the DB and you are done in minutes.
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.
See more from me