Check out our Monthly Survey Page to see what our users are running.

While there's a huge focus on Flatpak and Flathub thanks to the Steam Deck shipping with it out of the box, Canonical on the other hand continue with their own Snap packaging and they have a Steam Snap in testing for Ubuntu (and other distros, since Snap also works elsewhere).

In a fresh introduction post on the Ubuntu Linux Discourse forum (thanks OMGUbuntu), it outlines how they're now actually "going all in on the gaming experience on Ubuntu and we’ve started building out a team dedicated to working on just that". Part of that is reducing the need for PPAs and other solutions, and their focus now is on Steam.

The call for testing has now begun on their Steam Snap package which gives you everything you need for Native Linux gaming and for Proton too. It's early days for the Steam Snap so expect issues but they said they will "iterate quickly, and respond to this feedback" on it.

On top of that we can expect more gaming on Ubuntu Linux improvements to come "such as providing easy ways to get more bleeding edge components like Mesa drivers, and even newer kernels and proprietary drivers" — that all sounds great to me.

It's not actually live yet but once it will be, I'll update the post here with instructions they give, which they will also post in the link above. Update: Canonical has now done an additional blog post, going over the instructions. Either install it from the website / Snap Store or via terminal: snap install steam --beta

With the blog post, Canonical once again reiterated their plan to improve Ubuntu gaming mentioning that "the Ubuntu Desktop team is getting down to work planning for the future, and improving the gaming experience features heavily in our priorities (and hiring plan!)". They go on to mention how "serious gamers" continue using Windows primarily, which we all know as Steam puts Linux at about 1% currently (see our Steam Tracker) but they hope by "improving the gaming experience, and the Steam experience in particular, we can ensure that Ubuntu can become a genuine daily driver for gamers".

Article taken from GamingOnLinux.com.
Tags: Meta, Steam, Ubuntu
25 Likes
We do often include affiliate links to earn us some pennies. We are currently affiliated with GOG and Humble Store. See more here.
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.
See more from me
65 comments
Page: «5/7»
  Go to:

F.Ultra 30 Apr
View PC info
  • Supporter
Quoting: Samsai
Quoting: RichardYao
Quoting: damarrinI'd be happier with snaps if at least they started faster. 10 secs for FF from an NVMe drive, 40 seconds from a spinning drive in a recent Ubunt is a joke.

The downside of duplicating shared libraries is that it does not take advantage of the system page cache (or ARC for ZFS), so load times are higher. :/
From what I heard, the main problem with load times is that a cold Snap package first needs to be decompressed (fully, I guess?) before it is launched. But I guess duplicated libraries would also affect page cache.

However, that doesn't need to be the case. If the runtime uses similar shared libraries with other packages, it would be possible to deduplicate that stuff either on the package technology level (like Flatpak runtimes) or on the filesystem level with online or offline dedupe and reflinks. I don't know enough about Snap to make strong claims about how effectively or ineffectively it uses these methods. Considering Flatpaks seemingly don't have the same cold start delays, I am guessing at least not very effectively.

By all likelihood it's the decompression. Shared libs and cache sounds very implausible, for one it does not take 10s+ to load some shared libs and secondly Firefox as a deb/rpm already bundled special versions of the libs anyway so it loaded only a limited number of shared libs.

The old deb contained these bundled libs for Firefox:
 
/usr/lib/firefox/gmp-clearkey/0.1/libclearkey.so
/usr/lib/firefox/gtk2/libmozgtk.so
/usr/lib/firefox/libfreeblpriv3.chk
/usr/lib/firefox/libfreeblpriv3.so
/usr/lib/firefox/liblgpllibs.so
/usr/lib/firefox/libmozavcodec.so
/usr/lib/firefox/libmozavutil.so
/usr/lib/firefox/libmozgtk.so
/usr/lib/firefox/libmozsandbox.so
/usr/lib/firefox/libmozsqlite3.so
/usr/lib/firefox/libmozwayland.so
/usr/lib/firefox/libnspr4.so
/usr/lib/firefox/libnss3.so
/usr/lib/firefox/libnssckbi.so
/usr/lib/firefox/libnssutil3.so
/usr/lib/firefox/libplc4.so
/usr/lib/firefox/libplds4.so
/usr/lib/firefox/libsmime3.so
/usr/lib/firefox/libsoftokn3.chk
/usr/lib/firefox/libsoftokn3.so
/usr/lib/firefox/libssl3.so
/usr/lib/firefox/libxul.so
/usr/lib/firefox/minidump-analyzer
/usr/lib/firefox/omni.ja
/usr/lib/firefox/plugin-container


Granted the snap Firefox contains those (which is about 256MB) and an additional 65M of libs that otherwise would be shared.


Last edited by F.Ultra on 30 April 2022 at 9:03 pm UTC
F.Ultra 30 Apr
View PC info
  • Supporter
Quoting: slaapliedje
Quoting: user1
Quoting: scaineThat's a great turnaround from a few years ago, when the threatened removal of 32-bit libraries would have crippled the O/S from a gaming perspective.

A better gaming experience in what is still an incredibly popular "entry" distro is superb news.

You know what I think? Making a SNAP Steam is exactly the first step towards removal of the last few remaining 32 bit libraries in Ubuntu (the original plan was to remove ALL 32 bit libraries, but because of backlash, the final decision was to keep a few 32 bit libraries used by popular software). I mean think about it, Steam and Wine are the 2 most popular pieces of software that still require 32 bit dependencies. By making a SNAP Steam, Canonical will then be able to proceed removing those remaining 32 bit libraries (and also removing .deb Steam in the process). Regarding Wine, I heard it's also available as a Snap.

I'm surprised nobody here is asking himself the question what is even the benefit of having a SNAP Steam, when .deb Steam is working perfectly?
So to me it seems that in the case of creating a SNAP Steam, Canonical is just masquerading itself as "caring about gamers", but under the hood it's just part of the plan to remove the final remaining 32 bit libraries and push their SNAP garbage.

I'm so tired of Canonical's bull**** and so glad I've switched to Fedora after a few years of mainly using Ubuntu based distros.
I stopped using Ubuntu before it was cool to do so.

Ha, they stopped being relevant to me when the changed their 'let's be Debian, with the latest Gnome and 6 month release cycles to match Gnome's purpose they had at the beginning.

I am positive their push for ditching 32bit support was because they figured if Apple could do it, why can't they? There is no technical reason for Ubuntu to do so, unlike for Apple as they knew they were moving toward ARM... pretty sad to see the amount of native mac games that won't run after Mojave.

Someone mentioned Arch ditching 32bit support? Pretty sure they have always had the separate multi architecture repo, similar to Debian needing to add it in.

There are actual programs that simply can't be ported to 64bit (or it would take some significant effort" so dropping it is the equivalent of trashing all that past work. Part of why there are software preservation groups these days.

Of course there are technical reasons for ditching 32-bit support (I'm a maintainer for the software my company distributes and I decided to ditch 32-bit support due to technical reasons). It takes time and resources to build an entire arch of your distribution, on top of which you have to provide actual support, for an arch where you have very few users. That Canonical reversed their decision when there was a backlash indicates to me that they simply didn't understand the need for 32-bit libs to support games, they obviously only thought that it was about running Ubuntu on 32-bit hardware.
sobkas 30 Apr
Or you can do:
 
apt install steam

on any sane operating system without Ubuntu-only cruft.
View PC info
  • Supporter Plus
Quoting: F.Ultra
Quoting: slaapliedje
Quoting: user1
Quoting: scaineThat's a great turnaround from a few years ago, when the threatened removal of 32-bit libraries would have crippled the O/S from a gaming perspective.

A better gaming experience in what is still an incredibly popular "entry" distro is superb news.

You know what I think? Making a SNAP Steam is exactly the first step towards removal of the last few remaining 32 bit libraries in Ubuntu (the original plan was to remove ALL 32 bit libraries, but because of backlash, the final decision was to keep a few 32 bit libraries used by popular software). I mean think about it, Steam and Wine are the 2 most popular pieces of software that still require 32 bit dependencies. By making a SNAP Steam, Canonical will then be able to proceed removing those remaining 32 bit libraries (and also removing .deb Steam in the process). Regarding Wine, I heard it's also available as a Snap.

I'm surprised nobody here is asking himself the question what is even the benefit of having a SNAP Steam, when .deb Steam is working perfectly?
So to me it seems that in the case of creating a SNAP Steam, Canonical is just masquerading itself as "caring about gamers", but under the hood it's just part of the plan to remove the final remaining 32 bit libraries and push their SNAP garbage.

I'm so tired of Canonical's bull**** and so glad I've switched to Fedora after a few years of mainly using Ubuntu based distros.
I stopped using Ubuntu before it was cool to do so.

Ha, they stopped being relevant to me when the changed their 'let's be Debian, with the latest Gnome and 6 month release cycles to match Gnome's purpose they had at the beginning.

I am positive their push for ditching 32bit support was because they figured if Apple could do it, why can't they? There is no technical reason for Ubuntu to do so, unlike for Apple as they knew they were moving toward ARM... pretty sad to see the amount of native mac games that won't run after Mojave.

Someone mentioned Arch ditching 32bit support? Pretty sure they have always had the separate multi architecture repo, similar to Debian needing to add it in.

There are actual programs that simply can't be ported to 64bit (or it would take some significant effort" so dropping it is the equivalent of trashing all that past work. Part of why there are software preservation groups these days.

Of course there are technical reasons for ditching 32-bit support (I'm a maintainer for the software my company distributes and I decided to ditch 32-bit support due to technical reasons). It takes time and resources to build an entire arch of your distribution, on top of which you have to provide actual support, for an arch where you have very few users. That Canonical reversed their decision when there was a backlash indicates to me that they simply didn't understand the need for 32-bit libs to support games, they obviously only thought that it was about running Ubuntu on 32-bit hardware.
Those aren't technical reasons. Those are resource reasons.
Same shit every 5-10 gear of any good linux distro
Once Upon a time there was mandrake then it evolved mandriva company start to work with Microsoft money flowed very fluidly
Then the magic of success and beauty expires now there is no mandriva nor connectiva neither mandrake left as good as old.
And now same shit happening as cannonical and my lovely Ubuntu. First unity gone then gnome-shell pop and ruin my life and cooperating with Microsoft cannonical and Ubuntu fades of with stupid desicions and money oriented bullshidos.
So here we go again as looking New daily gaming driver while playing on Windows.
View PC info
  • Supporter Plus
Quoting: KuduzkehpanSame shit every 5-10 gear of any good linux distro
Once Upon a time there was mandrake then it evolved mandriva company start to work with Microsoft money flowed very fluidly
Then the magic of success and beauty expires now there is no mandriva nor connectiva neither mandrake left as good as old.
And now same shit happening as cannonical and my lovely Ubuntu. First unity gone then gnome-shell pop and ruin my life and cooperating with Microsoft cannonical and Ubuntu fades of with stupid desicions and money oriented bullshidos.
So here we go again as looking New daily gaming driver while playing on Windows.

Well... so I'm not sure how much Microsoft working with Canonical has much to do about any of it. Sure they were the first ones with official support for WSL. But there are quite a few official distribution supported versions for WSL now, including AlmaLinux.

Canonical has been going down their road of 'NIH' for a long time. And for a long time they've failed at it (the aforementioned Unity was originally a fork of gnome anyhow).

Pretty sure Ubuntu has decided their Bug #1 no longer matters, and they should concentrate on the server and OpenStack. That is where the money is at.
3zekiel 1 May
  • Supporter
Why, oh why ... The flatpak'd steam has been around for a couple years already, with flatpak 1.11 and up it is now fully usable, so why would they go and add their snap now ? Why not just update their flatpak in base distro, and use that ? SteamOS/Steam deck is also going all in on flatpak. So why can´t they just learn to give up ? They iterated over and over again in that canonical cycle (upstart, unity ...)
 
while(is_alive(canonical))
{
    do_somthing_on_our_own(rand());
    try_to_shove_it_everywhere();
    see_that_everyone_else_is_using_smthg_else();
    push_on();
    give_up();
    leave_an_ugly_mess_for_others_to_clean_up();
}

Maybe it would be time to break out of that loop.
Tuxee 1 May
Quoting: 3zekielWhy, oh why ... The flatpak'd steam has been around for a couple years already, with flatpak 1.11 and up it is now fully usable, so why would they go and add their snap now ? Why not just update their flatpak in base distro, and use that ? SteamOS/Steam deck is also going all in on flatpak. So why can´t they just learn to give up ? They iterated over and over again in that canonical cycle (upstart, unity ...)
 
while(is_alive(canonical))
{
    do_somthing_on_our_own(rand());
    try_to_shove_it_everywhere();
    see_that_everyone_else_is_using_smthg_else();
    push_on();
    give_up();
    leave_an_ugly_mess_for_others_to_clean_up();
}

Maybe it would be time to break out of that loop.

You should be more precise: upstart was introduced by Canonical in 2006 - years before systemd was even a thing. At some point even Fedora used it.
Snap intends to do (quite) the same thing as flatpak but has its advantages and disadvantages. And snap is Canonical's thing. Just as quite a few other technologies are Red Hat's thing (though Lennart Poettering frequently takes the blame and not his employee). Snap was introduced in 2015/2016 pretty much at exactly the same time as flatpak. The situation is NOT that there was flatpak and THEN Canonical decided to do their own thing. It has been pretty much the same situation with Mir vs. Wayland or Unity vs. Gnome Shell. (Also I am not aware who these others are, who have to clean up the mess - when they ditched Unity... there was nothing to "clean up".) Also: These decisions are obviously not rand(), but they seem to address pressing problems. Because otherwise there wouldn't be competing solutions emerging at pretty much the same time.

I wonder how ppl would have dealt with the deb-vs-rpm situation if social media would have been a thing back in the days...
3zekiel 1 May
  • Supporter
Quoting: Tuxee
Quoting: 3zekielWhy, oh why ... The flatpak'd steam has been around for a couple years already, with flatpak 1.11 and up it is now fully usable, so why would they go and add their snap now ? Why not just update their flatpak in base distro, and use that ? SteamOS/Steam deck is also going all in on flatpak. So why can´t they just learn to give up ? They iterated over and over again in that canonical cycle (upstart, unity ...)
 
while(is_alive(canonical))
{
    do_somthing_on_our_own(rand());
    try_to_shove_it_everywhere();
    see_that_everyone_else_is_using_smthg_else();
    push_on();
    give_up();
    leave_an_ugly_mess_for_others_to_clean_up();
}

Maybe it would be time to break out of that loop.

You should be more precise: upstart was introduced by Canonical in 2006 - years before systemd was even a thing. At some point even Fedora used it.
Snap intends to do (quite) the same thing as flatpak but has its advantages and disadvantages. And snap is Canonical's thing. Just as quite a few other technologies are Red Hat's thing (though Lennart Poettering frequently takes the blame and not his employee). Snap was introduced in 2015/2016 pretty much at exactly the same time as flatpak. The situation is NOT that there was flatpak and THEN Canonical decided to do their own thing. It has been pretty much the same situation with Mir vs. Wayland or Unity vs. Gnome Shell. (Also I am not aware who these others are, who have to clean up the mess - when they ditched Unity... there was nothing to "clean up".) Also: These decisions are obviously not rand(), but they seem to address pressing problems. Because otherwise there wouldn't be competing solutions emerging at pretty much the same time.

I wonder how ppl would have dealt with the deb-vs-rpm situation if social media would have been a thing back in the days...

For the "do_something_on_your_own" I indeed do not imply that there is already a competitor in itself. Indeed, upstart came first, and snap more or less at the same time.
My meaning is more that they always do it on their own, there's hardly ever a community going around, they rarely, if ever, involve other distributions, and so on and so forth. Snap is the pinnacle of that, where the server side is even proprietary and fully centralized to them - I think they alleviated some of that, but not sure at all, and it clearly wasn't used by anyone -.
For Unity, indeed it was fairly clean. For upstart, you still have to support their service model, and/or skim through tutorials proposing their solutions, with the compatibility in the hand of others. For Ubuntu phone it's now community maintained. So is the original Mir for those that actually still need it. I agree it might not be the absolute worst. For snap though, I expect we'll lose a lot of apps once they close the service.
For upstart, even when systemd clearly came out as the winner, both technically and community wise, they still tried to shove it for quite some time. Mir ? same. For snap, they are doing the same now too. Flatpak is more widely adopted (in distros), is getting pushed by Valve too, has quite a few technical advantages (better deduplication, fully open, clearer source and runtime management) for it relevant purpose (i.e. installing a kernel via snap is not an advantage, as it's by definition fully unconfined, if anything having grey areas in term of what's sandboxed and what is not is more disadvantage to me) and is overall gaining traction. But no, instead of contributing to the already existing solution - steam flatpak here - they decided to shove their own stuff once again.

As for RPM vs deb, well it was a heated topic at that time already...
Boldos 1 May
Quoting: F.Ultra
Quoting: PikoloSteam as a snap package? That is very unwelcome - I hate applications updating behind my back. Mozilla provide an official Firefox PPA, but I hope Canonical don't mess with the Steam APT package.

The Mozilla Team PPA is not by Mozilla, it's by a voluntary group inside Canonical (or at least they where some years ago). Mozilla are the ones that build the snap for Ubuntu.
Hmm... Interesting development...
https://twitter.com/kenvandine/status/1520787381770727427?s=20&t=gShwlPo355NEHNW6p8U2nw
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: Liberapay or PayPal.

This ensures all of our main content remains totally free for everyone with no article paywalls. We also don't have tons of adverts, there's also no tracking and we respect your privacy. Just 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!
Login / Register

Or login with...
Sign in with Steam Sign in with Twitter Sign in with Google
Social logins require cookies to stay logged in.