Confused on Steam Play and Proton? Be sure to check out our guide.

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
67 comments
Page: «4/7»
  Go to:

elmapul 30 Apr
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.
what a plot twist
mr-victory 30 Apr
Quoting: KelvinhboToo late Ubuntu. Arch is the new Linux gaming king now, you had your chance and you blew it.
Wait till Fedora steals the crown from Arch
user1 30 Apr
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.
Samsai 30 Apr
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.
slaapliedje 30 Apr
View PC info
  • Supporter Plus
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.
elmapul 30 Apr
Quoting: jp
Quoting: SchattenspiegelRemember the time basically every major application had a .deb package available and most the disk space was available for games and data and stuff, because applications where small and started nearly instantly and... actually...worked...?

I mean seriously, what is the goal of this? To accelerate climate change by being intentionally wasteful? To incite social unrest by creating an atmosphere comparable to a traffic jam whenever one opens an application?
There is no goal, it's just laziness and illiteracy of developers, who for the most part don't know how to write pure code, they have flooded Linux devcommunity.
that is like saying, rust is useless because an good programer can check the code to make sure its safe to run, sure, in an ideal world we would have perfect programers in enough quantity to make big projects without massive security holes, meanwhile in the real wolrd, we have code writen by humans, so the more you can take away their capabilities of making mistakes, the less security holes you will have.



Quoting: jpAt the same time, all these snaps/flatpaks etc (shhh, systemd) are complicated and unsafe, although it is useful for someone to have legitimate backdoors.
Welcome to World with New order created by corporations and approved by new Linux generation.

old games wont be mantained no matter how much we wish then too.
if i have an small risk of someone actually developing an malware for linux and i geting this malware, end up not being able to run my games on my computer (among other things), and i could chose to run saffer code at the cost of being 100% sure that i wont be able to play my games, then the choice is obvious.

that is like saying, give all your money to thiefs arround the world, they cant rob you if you have nothing.
Boldos 30 Apr
Quoting: gradyvuckovic...One consistent issue with Ubuntu and Ubuntu based distros has been, while it's a great basis for a distro and very stable, it takes far far too long for updates for things such as drivers and kernels to reach Ubuntu. It's probably the only real major downside of Ubuntu based distros, so addressing that would definitely make Ubuntu far more competitive to Arch based distros again.
Well, but isn't *exactly this* the point of having an LTS distro?

In office use, you really want a long-term stable (thus non-changing) distro for all your 50+ workstations. In server, you really want a long-term stable (thus non-changing) distro that is tested and confirmed compatible & without issues for your server hardware and software.

So no, this is definitely not and issue. This is a very wanted feature of this distro.

And if this does not suite anyone, they are free to jump on countless other rolling-release distros out there...


Last edited by Boldos on 30 April 2022 at 3:24 pm UTC
Boldos 30 Apr
Quoting: TuxeeProbably those days, when games occupied megabytes. Not 50+ gigabytes. I agree that for small applications the overhead of flatpaks or snaps is sometimes ginormous - OTOH something like KiCad is huge already and the flatpak overhead is no longer relevant, same goes for the blender snap.
I quite disagree. The flatpack thing, with just a couple of small basic packages installed, takes GBs of root space. This drives me totally nuts.

Moreover, flatpacks have rarely any integration with the desktop environment, which drives me nuts even more.

And on top of that, is there any mechanism of having "certified/confirmed" developer/distributor of packages (like Snaps have)? This is very much needed in security driven, corporate environment!
Tuxee 30 Apr
Quoting: Boldos
Quoting: TuxeeProbably those days, when games occupied megabytes. Not 50+ gigabytes. I agree that for small applications the overhead of flatpaks or snaps is sometimes ginormous - OTOH something like KiCad is huge already and the flatpak overhead is no longer relevant, same goes for the blender snap.
I quite disagree. The flatpack thing, with just a couple of small basic packages installed, takes GBs of root space. This drives me totally nuts.

That's pretty much what I said, no?

Right now I have only one small tool installed as flatpak: the Gnome Extension Manager - which is only half the size of the .deb install (which pulls in two dependencies) BUT relies on the Gnome Platform which eats up a measly 750MB. OTOH KiCad itself already takes 600+ MB and its libraries around 6GB. The 500MB of runtime barely matter - even less so since it is shared with Hugin. Consequentially the more flatpaks (or snaps for that matter) you'd install the less this overhead would be.
I recently moved from Kubuntu to Manjora. This doesn't exactly entice me to move back.
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.