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.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
All posts need to follow our rules. For users logged in: please hit the Report Flag icon on any post that breaks the rules or contains illegal / harmful content. Guest readers can email us for any issues.
Remember 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...?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.
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?
At 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.
Last edited by jp on 29 April 2022 at 7:24 pm UTC
4 Likes, Who?
Remember 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...?
Probably 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.
Few years ago a fair bunch of my proprietary/commercial software came as archives - compared to that appimages and snaps are a blessing.
2 Likes, Who?
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.
And you are...? You have to be some serious developer for such... bold statements.
At 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.
Care to elaborate? We are really short on conspiracy theories round here.
4 Likes, Who?
That'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.
When was it? Even Arch, who was one of the first distro to drop 32-bits support, still have 32-bits libraries (but in a repository that have to be activated explicitly), and is really good for gaming (well, even Valve is using it for SteamOS…).
About 3 years ago. https://www.omgubuntu.co.uk/2019/06/ubuntu-is-dropping-all-32-bit-support-going-forward
Valve itself might be less of an issue, but the games themselves rely on 32 bit support.
0 Likes
snaps are so slow...i never felt that flatpaks were slow on Fedora but snaps are certainly slow on Kubuntu
Last edited by seven on 29 April 2022 at 8:02 pm UTC
Last edited by seven on 29 April 2022 at 8:02 pm UTC
0 Likes
Going all in on gaming.
Steam Snap.
Pick one.
Steam Snap.
Pick one.
8 Likes, Who?
ElectricPrism Apr 29, 2022
I'm emotionally conflicted.
On the one hand Ubuntu is * shivers * adequate for noobs. On the other hand Canonical has a LONG history of devoting huge amounts of energy into things against the grain of the FOSS community only to abandon it later.
Canonical are SerialAbandoners™
Canonical MissedTheSteamBoat™
Steam has been on Linux for nearly 10 years now. Canonical giving gamedevs & Valve the finger over the 32-bit thing a while ago and Canonical's business relationship with Microsoft making WSL & WSL2 just makes me not trust them as they are a Microsoft-shill proxy.
Money is one thing, I give money to hundreds of Linux Game Devs, but Microsoft has decades of history, and it's in their interest to inhibit Linux Gaming growth in favor of promoting Xbox and Windows 11. Why would they shoot themselves in the balls & bank when they could just sabotage other platforms through a existing business partner?
Despite what people say about Microsoft being a "Service Company" (SaaS) lately, they still are very much interested in enhancing their Quarterly Earnings and bottom line to please their stock owners and enhancing their Power & central importance in the world of computing -- that will never change.
All of their recent company purchases achieve those enhancements (1) GitHub (2) MineCraft (3) BlizzardActivision etc...
Last edited by ElectricPrism on 29 April 2022 at 11:03 pm UTC
On the one hand Ubuntu is * shivers * adequate for noobs. On the other hand Canonical has a LONG history of devoting huge amounts of energy into things against the grain of the FOSS community only to abandon it later.
Canonical are SerialAbandoners™
Canonical MissedTheSteamBoat™
Steam has been on Linux for nearly 10 years now. Canonical giving gamedevs & Valve the finger over the 32-bit thing a while ago and Canonical's business relationship with Microsoft making WSL & WSL2 just makes me not trust them as they are a Microsoft-shill proxy.
Money is one thing, I give money to hundreds of Linux Game Devs, but Microsoft has decades of history, and it's in their interest to inhibit Linux Gaming growth in favor of promoting Xbox and Windows 11. Why would they shoot themselves in the balls & bank when they could just sabotage other platforms through a existing business partner?
Despite what people say about Microsoft being a "Service Company" (SaaS) lately, they still are very much interested in enhancing their Quarterly Earnings and bottom line to please their stock owners and enhancing their Power & central importance in the world of computing -- that will never change.
All of their recent company purchases achieve those enhancements (1) GitHub (2) MineCraft (3) BlizzardActivision etc...
Last edited by ElectricPrism on 29 April 2022 at 11:03 pm UTC
14 Likes, Who?
Too late Ubuntu. Arch is the new Linux gaming king now, you had your chance and you blew it.
4 Likes, Who?
UnixOutlaw Apr 30, 2022
looks like my switch from Ubuntu to Fedora was very VERY timely! :D
Recently had a heap of dramas trying to get Alderon Game Launcher to "launch" as both Snap and AppImage - on Fedora 35 (I might wait a few updates before going to Fedora 36).
Finally managed to get the AppImage one to run by simply adding "--no-sandbox"... Goodbye SNAP!
Recently had a heap of dramas trying to get Alderon Game Launcher to "launch" as both Snap and AppImage - on Fedora 35 (I might wait a few updates before going to Fedora 36).
Finally managed to get the AppImage one to run by simply adding "--no-sandbox"... Goodbye SNAP!
0 Likes
what a plot twistSteam 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.
2 Likes, Who?
mr-victory Apr 30, 2022
Too 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
1 Likes, Who?
That'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.
2 Likes, Who?
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.I'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. :/
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.
1 Likes, Who?
slaapliedje Apr 30, 2022
I stopped using Ubuntu before it was cool to do so.That'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.
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.
0 Likes
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.Remember 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...?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.
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?
At 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.
0 Likes
...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
3 Likes, Who?
Probably 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!
0 Likes
Probably 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.
0 Likes
Mountain Man Apr 30, 2022
I recently moved from Kubuntu to Manjora. This doesn't exactly entice me to move back.
0 Likes
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.I'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. :/
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-containerGranted 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
2 Likes, Who?
Patreon
PayPal
See more from me