Snaps & Ubuntu Core Desktop Talked Up At FOSDEM 2024

[Artim]

I read the comments a bit... are they different ways of packaging the packages or do you trust the dev. of the application and you should otherwise you have no reason to use it or you trust your distribution, you have to trust someone... but if you buy bread you should trust whoever sells it to you and does it. The problem with distributions is that they often lag behind in versions with unresolved security bugs, furthermore if you install many system applications you risk weighing down the system and creating regressions in the convoluted management of dependencies, the applications tested by the distributions are only the default ones , don't think that Ubuntu, Debian etc. I test the 1000+ applications available and if they create regressions, they don't, it would be impossible. Personally I prefer flatpak and you can manage sandbox permissions as you like, with KDE you can do it from the system settings.

Wow. Welcome to the 90s. That is some decades old outdated bs you're spewing here with comparisons that are no longer limping, but crawling...Yes, for the sake of stability, some distributions like Debian lag behind in feature updates. But that's the point. You can have up-to-date software or thoroughly tested software. Never both. But that never means lagging behind security update wise, as those are patched independent of feature updates. So the only thing reporting such nonsense would be software (or stupid humans) only checking the version number of a program. Spoiler alert, just because you have a version in theory susceptible to security issues doesn't mean nobody has patched either way. That's the beautiful thing only possible with the classical distribution system. With either Flatpak, Snap or AppImage you're damned to hope the dev fixes it at some point, especially if the issue is inside a dependency. And no, these dependencies do never create any alleged regressions in a working distribution. That might happen in something highly unstable as Arch, but that's it. And there's absolutely nothing convoluted about it, just ignorant people that only learned the outdated Windows ways of things and that refuse to understand concepts that just work.

And yes, especially Debian tests all over 70.000 packages for every platform they offer. That's the whole point of it. And it's very easy, it's called automation. Also, with Debian you have 2 years of development for each version, including litterally 6 months of continuously harder freezes where less feature updates are allowed in so all testing users and all developers can concentrate on finding as many bugs as possible beforehand and hopefully fix them before release. Or at least have them well documented so users can decide on their own when they'll upgrade. On the other hand, with Flatpaks and Snapd you aren't getting even close to this degree of testing. So these packages need to be isolated from the rest of the system to keep damage to a lower level than Arch does. But if you need stability - and that's pretty much the one and only reason you run Debian, only the packages from the official repos are the way to go as nothing else has been scrutinized that much.

You can like Flatpak all you want, but that's no excuse for spreading blatant lies. Of course if you have any proof for the nonsense that hasn't been true in recent decades, go ahead, present it. But until then your comment is just a very sad try of make distros look bad because that's the only way you can make Flatpak look good. Very pathetic.

[TiCPU]

I still prefer something that's well integrated and tested to work as a whole than another layer of abstraction to satisfy having hundreds of different package managers. Sure, updating a system library like libc for a security update that could cause every package to break is not always fun but sure better than having to wait an arbitrary number of days for each upstreams to do so.
I understand the secure aspect of it and am saddened that not any many packages are secured by apparmor and system's security by default on Ubuntu and even worse on Debian. But then, maybe it's better this way and makes for even tighter case by case security profiles.

[Daktyl198]

You are hillarious. Find a single piece of software without any bugs, I dare you. And also, if you can prove that "95% of applications distributed as Flatpaks break out of the sandbox by default because of point 1: bugs", then go ahead. Right now you are only spreading lies and misinformation. Canonical must have paid you a lot for that.

You’re exactly the type of fanboy I’m talking about. Nobody can say anything bad about flatpak or else they’re paid by Canonical. For the record, I hate snaps more than I hate flatpaks, and haven’t touched an Ubuntu based distro in over a decade. I only call out the hypocrisy of fanboying over flatpaks but shitting on snaps every chance you get.

As for breaking out of the sandbox, just go to flat hub and look at the default permissions for the most popular software. If any of that software gets file system access to the /home directory, it’s breaking out of the sandbox. And that’s just the most common way. Most applications require far too lax permissions to work properly so the sandbox is basically nonfunctional unless you go in after the fact and lock it down (at the cost of application features and stability).

[ssokolow]

And yet, benchmark’s consistently show that in many cases, Flatpaks run slower than standard packages. In many cases, they do run at similar speeds, but not every time which means that there’s still improvements to be made a decade later.

Every year for the last 6 years has been “the year we all switch to flatpak”, but not even Fedora (owned and operated by the makers of flatpak) default to it as far as I know. Only security nuts (who actually modify and take advantage of the flatpak sandbox) and fanboys go out of their way to use Flatpaks for more than a couple apps that aren’t available in the standard repos.

Depending on what you mean by "run slower", that may be the seccomp system call filter. Try running a program from a standard package inside Firejail to do fine-grained experiments into what effect various sandboxing constructs have on performance.

[ssokolow]

I've never liked either Flatpaks or Snaps, as they encourage incompatibility by essentially packaging a partial mini-distro along with an application. This just seems ludicrous, wasteful, and counterproductive to me.

However during experimentation with them I was never able to get a Snap to work at all, while Flatpaks were mostly, if not completely, functional. But as I said, neither really seems suitable for permanent installation, and I wish the goal were still set on Linux distribution compatibility, like the now failed LSB idea. But just because LSB failed doesn't mean everyone should just throw up their hands and go with distro within a distro ideas like Flatpak and Snap.

Flatpak is a shot across the bow. It's "Don't like it? Stop squabbling and compete with us. We're tired of waiting." in the form of runnable code. (Same as systemd. "Don't like it? Then prove you can meet our needs 'the proper way'.")

[intelfx]

there's a reason why a patch doesn't get merged

More often than not, it's because the upstream doesn't care about the problems that do not happen on the upstream developer's machine.

Remember, a packager will never be smarter than the developer

That's where you are dead wrong.

[Artim]

You’re exactly the type of fanboy I’m talking about. Nobody can say anything bad about flatpak or else they’re paid by Canonical. For the record, I hate snaps more than I hate flatpaks, and haven’t touched an Ubuntu based distro in over a decade. I only call out the hypocrisy of fanboying over flatpaks but shitting on snaps every chance you get.

As for breaking out of the sandbox, just go to flat hub and look at the default permissions for the most popular software. If any of that software gets file system access to the /home directory, it’s breaking out of the sandbox. And that’s just the most common way. Most applications require far too lax permissions to work properly so the sandbox is basically nonfunctional unless you go in after the fact and lock it down (at the cost of application features and stability).

The point is that you are writing utter bs. You aren't saying "anything bad about Flatpak", you are incapable of sticking to the truth, which immediately invalidates your arguments. If you need to lie, you must be desperate because you have no real arguments.

[Artim]

Flatpak is a shot across the bow. It's "Don't like it? Stop squabbling and compete with us. We're tired of waiting." in the form of runnable code. (Same as systemd. "Don't like it? Then prove you can meet our needs 'the proper way'.")

...that's not how anything works.

[ssokolow]

...that's not how anything works.

That's exactly how things work in a free market. They made a competing product and people are choosing to use it... they just wish they didn't have to be the providers of a competing product and see it as a position they've been pushed into by the incumbents' refusal to cater to un-served demand.

[Artim]

That's exactly how things work in a free market. They made a competing product and people are choosing to use it... they just wish they didn't have to be the providers of a competing product and see it as a position they've been pushed into by the incumbents' refusal to cater to un-served demand.

Solely your opinion that they don't want to be. My understanding is they are the only ones interested in having an actual product for the masses, not just a very quick-and-dirty solution for a problem that doesn't exist - besides sheer laziness.