Patreon Logo Support us on Patreon to keep GamingOnLinux alive. This ensures all of our main content remains free for everyone. Just good, fresh content! Alternatively, you can donate through PayPal Logo PayPal. You can also buy games using our partner links for GOG and Humble Store.
Latest Comments by Tuxee
Canonical going 'all in' on gaming for Ubuntu, new Steam Snap package in testing
29 Apr 2022 at 7:45 pm UTC

Quoting: Breizh
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.
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 [External Link]
Valve itself might be less of an issue, but the games themselves rely on 32 bit support.

Canonical going 'all in' on gaming for Ubuntu, new Steam Snap package in testing
29 Apr 2022 at 7:42 pm UTC Likes: 4

Quoting: jpThere 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.

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.
Care to elaborate? We are really short on conspiracy theories round here.

Canonical going 'all in' on gaming for Ubuntu, new Steam Snap package in testing
29 Apr 2022 at 7:37 pm UTC Likes: 2

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...?
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.

Sorry Arch (EndeavourOS), it's not working out any more and hello Fedora
11 Apr 2022 at 9:30 am UTC

Quoting: Guest
Quoting: TuxeeI did a benchmark. But you claimed it to "be fake", because it didn't meet your... well, expectations. But indeed I do few benchmarks, I prefer to work (or game) on my machine. And if "absolute browser speed" would be my thing, I'd probably use Chromium. Even the snap version is faster by quite a margin in these benchmarks than any version of Firefox.
I just have a hard time believing your result, because it doesn't match the motionmark result of the two articles, where motionmark is getting significantly slower on the Snap packages.
Sigh. Whatever...

Quoting: GuestI have already given three links where people talk about incredibly bad results of the Snap packages. Here are two other
If I have time, I'm going to do some extensive benchmarks myself and compare these Snap apps on Ubuntu with the performance of the exact same apps in Debian and Arch Linux. I'm probably going to make some unprecedented discoveries.
Don Quixote rides again...
Just a heads up: Comparing the same browser on different distributions will be completely pointless.

https://www.phoronix.com/scan.php?page=article&item=linux-distros-50cpu&num=2 [External Link]

Quoting: GuestRegarding Firefox, this is my result in Speedometer 2.0 with a very old i3-3240 and without a dedicated GPU on FreeBSD: https://i.ibb.co/tJTnbZq/Screenshot-2022-03-25-14-57-10.png [External Link]
And I get this result in Chromium on the same system: https://i.ibb.co/9vkMVg6/Screenshot-2022-03-25-10-38-48.png [External Link]

So the difference is 4.94% in FreeBSD. Speedometer is seen by both the Firefox team and the Chromium development team as the benchmark that has the most relevance in reality.

I can probably make Firefox go as fast as Chromium on FreeBSD: https://firefox-source-docs.mozilla.org/build/buildsystem/pgo.html [External Link]

You can ask yourself, why is Firefox on my Linux system so much slower than Chromium, when Firefox is almost as fast as Chromium for people who use FreeBSD, and why is Chromium also faster on FreeBSD than on my Linux system?
No. I won't. I am definitely not inclined to choose FreeBSD as my OS of choice because some random dude on a mission suggested that Firefox might then run just as fast as Chromium. It has been said before: This site is about gaming on Linux.
Why not head over to Phoronix, where benchmarking is king and FreeBSD gets its fair share of attention. However, the results [External Link] there are still bleak.

Sorry Arch (EndeavourOS), it's not working out any more and hello Fedora
10 Apr 2022 at 8:27 pm UTC

Quoting: GuestIt is telling that Ubuntu users do so few benchmarks, that they do not yet have the slightest knowledge whether it is 15%-10%-5% slower or faster than deb packages in the current implementation.
I did a benchmark. But you claimed it to "be fake", because it didn't meet your... well, expectations. But indeed I do few benchmarks, I prefer to work (or game) on my machine. And if "absolute browser speed" would be my thing, I'd probably use Chromium. Even the snap version is faster by quite a margin in these benchmarks than any version of Firefox.

Sorry Arch (EndeavourOS), it's not working out any more and hello Fedora
10 Apr 2022 at 6:14 pm UTC Likes: 1

Quoting: GuestThink, for example, of Bill Gates, or the high number of Microsoft executives who were involved in sex traffic.
Wow. That escalated nicely. And all because of the imperfections of snaps... Let's see when Godwin's law can be applied.

Sorry Arch (EndeavourOS), it's not working out any more and hello Fedora
10 Apr 2022 at 11:04 am UTC

Quoting: Guest
Quoting: TuxeeAh I see. I am lying. Interesting approach.
There is technically no reason why snaps could be faster than deb. Maybe if the snap package has better optimization which isn't a fair comparison.
Oops. Sorry. I forgot to pick a comparison which sustains your worldview. Of course it is because of different compiler flags and/or optimizations. I am shouting it out for you: IT IS JUST THAT THE RUNNING SNAP APPLICATION DOESN'T SHOW A SEVERELY IMPACTED PERFORMANCE. THAT'S ALL. (And it is not just Firefox - my Zoom meetings over the Zoom snap client don't exhibit any "horrendous" performance issues, either.
Let that sink in. Ok? Or do I have to inform Micheal of Phoronix to leave out Clear Linux from all his benchmarks because it's obviously so well optimized that a comparison with other distros makes them look bad and is "not fair"?
And to re-iterate another point: You get a handful snap packages with a default Ubuntu install (the store, now Firefox, the daemon itself, and some library snaps) and still hundreds of deb packages.
Quoting: GuestFurthermore, snap and flatpak are also a serious security risk.
Care to elaborate? Just never get your hands on a Steam Deck - it's pretty much flatpak only
Quoting: Guesthttps://thenewstack.io/oh-snap-security-holes-found-in-linux-packaging-system/ [External Link]
And did you read the rather short article? I must assume you stopped at the headline because that's of course much more convenient and only rattling for snap aficionados. These are "normal" vulnerabilities, not something inherent to the container/sandbox concept of snap or flatpak.

But, before getting worked up at Canonical, take a closer look. While discovering the snap vulnerabilities, Qualsys also found security problems you’ll find in all Linux distributions. These are CVE-2021-3996 and CVE-2021-3995 in util-linux (libmount and umount); CVE-2021-3998 and CVE-2021-3999 in the glibc (realpath() and getcwd()), and CVE-2021-3997 in systemd (systemd-tmpfiles).
Canonical has released a patch that fixes both security holes. The patch is available in the following supported Ubuntu releases: 21.10; 20.04, and 18.04. A simple system update will fix this nicely.

Sorry Arch (EndeavourOS), it's not working out any more and hello Fedora
10 Apr 2022 at 12:12 am UTC Likes: 2

Quoting: Guest
Quoting: TuxeeSpeedometer: 78.0 (deb) vs. 77.2 (snap)
JetStream2: 63.678 (deb) vs. 67.811 (snap)
MotionMark: 48.29 (deb) vs. 65.92 (snap)

Looking at this anecdotal result the snap version is actually faster than the deb package - definitely not "measurably" slower.
If the apps are equally well optimized, Snap can never be faster than the deb package. So I'm pretty sure your result is fake. Pretty much everyone on the internet talks about heavy performance losses from snaps.
Ah I see. I am lying. Interesting approach.

Quoting: GuestSome examples:
https://youtrack.jetbrains.com/issue/IDEA-268954 [External Link]
Please... I contributed to this very bug report. Again: The above bug has nothing to do with the speed of the application itself, but the startup time - which went from "meh, it's an IDE" to literally minutes (between a minor version changes of PHPStorm).

Quoting: GuestI must say that Ubuntu users are a special species. When you hear that FreeBSD with a ten-year-old i3 processor and slow SSD opens Firefox much faster than the Snap package from Firefox on a recent i9 CPU, it should ring a bell that this isn't acceptable.
Sigh. Yes, I realize that you are just trolling. Do you really think that starting an application on a recent SSD setup will differ from a "slow" SSD with older processor? Look it up: LTT has done some "tests" on that. And let me spoil it: There is none.
And that snaps start slower than "normal" applications has never been denied by me (or pretty much anyone) - they have to be unpacked. It's that simple. Besides: Why should it "ring a bell"? So far I have not been forced to use snaps.

Quoting: GuestThat's why I'm glad Liam has switched to one of the best systems for Flatpak so that people can see that there is a much better alternative to Ubuntu and its snap apps.
That's weird. I thought FreeBSD is the alternative to strive for...

Sorry Arch (EndeavourOS), it's not working out any more and hello Fedora
9 Apr 2022 at 11:55 pm UTC

Quoting: tuubi
Quoting: TuxeeSpeedometer: 78.0 (deb) vs. 77.2 (snap)
JetStream2: 63.678 (deb) vs. 67.811 (snap)
MotionMark: 48.29 (deb) vs. 65.92 (snap)
This is completely off topic, but what's going on with your Firefox? I know my 5700 XT is slightly more powerful than your non-XT 5700, and your 5900X packs a good deal more oomph than my 3700X, but how are you getting a measly 65.92 in MotionMark when I get 876.18? That's like nowhere near comparable. JetStream2 gave me about double your result, and Speedometer way more than double (164). What's going on with Ubuntu if Mint's build of Firefox is this much faster?
The benchmark was done on my laptop which already got 22.04 - it's an AMD 4750 Pro APU. (I should have noted this somewhere.)
On my desktop SpeedoMeter gives me... wait a second... or a few... 137 and MotionMark 553.22 (which is still rather poor compared to your result).

Sorry Arch (EndeavourOS), it's not working out any more and hello Fedora
9 Apr 2022 at 7:05 pm UTC

Quoting: Guest
Quoting: TuxeeWell, the post says "Just curious if anyone else experienced this. I haven't seen any similar postings."... (And he was on Ubuntu 20.10?) Anyway, I had it up on my laptop with a 22.04 Ubuntu and didn't experience any "anomalies".
Have you done an extensive benchmark between the performance of the apps in Flatpak and Snap? As far as I know, with Snap you lose an average of 6%, and with Flatpak on average between 0 and 2%.

That means that thanks to Snap you lose an average of 5% in performance compared to Flatpak.
I did the 3 browserbench [External Link] Benchmarks and compared the deb-Version from the PPA with the snap version. Both versions with the same add-ons and same number of tabs open.

Speedometer: 78.0 (deb) vs. 77.2 (snap)
JetStream2: 63.678 (deb) vs. 67.811 (snap)
MotionMark: 48.29 (deb) vs. 65.92 (snap)

Looking at this anecdotal result the snap version is actually faster than the deb package - definitely not "measurably" slower.

Quoting: GuestThe start-up times are also a big difference.

To give an example: https://old.reddit.com/r/Ubuntu/comments/tjwsza/firefox_now_only_available_via_snap/i248zy2/ [External Link]

- Firefox snap start up performance immediately after boot (no file buffer-caching): 10 seconds, ugg
- Firefox snap start up performance with buffer-caching: 4 seconds, this is annoying since I open the browser and close often in my workflows
You can see he says 'i9-11900H and 2TB SSD'
Guess how long the latest Firefox takes to boot on my very old i3-3240 and 850 EVO 500GB SSD on my FreeBSD system? The answer: less than 2 seconds.

Is that progress?
Well, if "startup time" is your prime concern, then we peaked decades ago when I could cram a whole application written in assembler in a few kB. This is not the prime goal of either flatpak or snap.