Canonical going 'all in' on gaming for Ubuntu, new Steam Snap package in testing

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

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.

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.

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.

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.

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

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!

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.

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