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

View this comment - View article - View full comments

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.

View this comment - View article - View full comments

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
Valve itself might be less of an issue, but the games themselves rely on 32 bit support.

View this comment - View article - View full comments

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.

View this comment - View article - View full comments

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.

View this comment - View article - View full comments

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

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
And I get this result in Chromium on the same system: https://i.ibb.co/9vkMVg6/Screenshot-2022-03-25-10-38-48.png

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

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 there are still bleak.

View this comment - View article - View full comments

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.

View this comment - View article - View full comments

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.

View this comment - View article - View full comments

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/

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.

QuoteBut, 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).

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

View this comment - View article - View full comments

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

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

View this comment - View article - View full comments