Ubuntu flavours to drop Flatpak by default and stick to Snaps

Quoting: Boldos

Quoting: ZlopezI'm not sure why Canonical doesn't want to have flatpak installed out of the box, but they sometimes do strange decisions, like Mir or Unity. Not bad projects but they were the only one using them and dropped them after some time.

I'm not sure why people keep bashing Canonical of doing "bad" or "strange" decisions/projects all the time.
Upstart was there before anyone even heard about that second weird thing called systemd. But it is Canonical who is the bad guy yet again for choosing their own path?

Oh c'mon...

Honestly for upstart their bad path could more logically have been ditching it in favor of systemd. But then again, the 'mothership' of Debian never adopted upstart, so they went with the path of least resistance there. Mir is a valid complaint though, as instead of spending developer time on Wayland, they wasted it on trying to make their own thing... which would have ultimately caused a huge amount of fragmentation. But you are correct, upstart isn't really in the list of 'wtf, Canonical?

I really don't care about what package format Ubuntu uses. I didn't care about package formats when I used Windows, I didn't care when I ran Mac OS X, and I don't care now. As long as it's easy to find apps, install and update then I'm happy. I do understand the reasoning for all Ubuntu flavors to use Snap as that is a core technology for the project. I hope they do more in the future do make the flavors be more aligned, for example through theming, using the same installer or whatever. An Ubuntu flavor should "feel Ubuntu" in some ways regardless of desktop environment.

I'm very happy with Kubuntu on my main machine. It's stable, updates are regular and performance is good. For people who somehow find snaps controversial there are many, many other distros to use. Currently I use both snaps and flatpaks and it works good but I care about that in much the same way as I care about what package format Steam uses. I don't even know what format Steam uses :)

Quoting: sarmadThis is not necessarily true. Snaps are independent from Ubuntu. If you go to the snap store you'll see no Ubuntu branding there. Canonical is marketing snap as a Linux store, not as an Ubuntu store, much like Steam is a Linux gaming store regardless of which distro you're using. So, if people have no problem installing Steam, which is proprietary and tightly controlled by Valve, why would they have problem installing snap, which at least has an open source client?

Because there's no real alternative to Steam, but there is for Snap. And if you want to know what's wrong with Snap from the view of all other distributions, just ask Ubuntu:

Canonical does have total and complete control over the Ubuntu archive that apt uses. And Canonical has total and complete control over the Snap repository. If something goes wrong and Canonical must step it, they can.

Well, majority of the discussion so far is about the technology itself: how open or not open it is, how slow/fast it is, what can/cannot be run with it etc...

But I'm missing another typical use case topic in the discussion:
The "security/trust" level of "let me install the app I need for work" things. Especially when used "professionally" as a daily workload driver within a company.

And even if not necessarily directly visible, the >security< question of things is always floating somewhere around when OS and apps are installed and run inside a company network.

And - with regards to installing apps from external stores - this usually translates into certain level of "trust": When installing the app, I do/do not trust the source that it will most probably e.g. not install malware packed with it (unless intentional -> looking at you Google & Micro$oft... ). This applies especially when installing 3rd party apps, which are not usually generally available in standard official repos elsewhere (.NET SDK, Rider, Pycharm, Teams, Spotify, ...)

With Snaps, I *can* have that certain level of trust, because there is a trusted (by me) publisher verification authority (Canonical) working behind the scenes, so if the package is marked as *Verified developer* e.g. Microsoft, or JetBrains or Spotify, I trust it is really them and not that proverbial "some anonymous person somewhere in Nebraska" who packaged it on his/her PC and then published it to the store with whatever hacks attached inside.

In my opinion this critical topic is totally omitted with Flatpacks/Flathub.


Last edited by Boldos on 25 February 2023 at 10:33 am UTC

Quoting: dziadulewiczPlease read this response from a developer to understand this decision better. It makes perfect sense and no need to raise pitchforks yet again: https://discourse.ubuntu.com/t/ubuntu-flavor-packaging-defaults/34061/9

"As a developer, it might help to see a bit of the standpoint I have on this issue, as I actually agree with the decision to not include Flatpak by default. I may simply be reiterating what @kewisch has already said, but I don’t have to talk in “official language” so it might be a bit easier to swallow.

It may be easily overlooked, but one of the core features of Ubuntu is that package versions change very, very rarely. If at all possible, bug fixes are taken from the (openly viewable) source code of an application, carefully tweaked to make them compatible with an older version of the software, patched in, tested, and only then deployed. There are a few packages where this is impractical (Firefox for instance), and there are some closed-source packages in the Restricted repo that we can’t backport patches into since we don’t have the code. But for the most part, if you install an app into Ubuntu, that’s the app you get, and that will be the app you continue to use for the rest of that release’s lifespan.

This is a powerful feature since it makes Ubuntu unlikely to randomly break your important data as often as that other OS that you hear get a lot of grief from Linux geeks, but it also requires that Canonical and the Ubuntu community have near-total control over the software repository.

That’s only possible if Canonical actually has the necessary control.

Canonical does have total and complete control over the Ubuntu archive that apt uses. And Canonical has total and complete control over the Snap repository. If something goes wrong and Canonical must step it, they can.

But Canonical has zero control over the Flatpak repositories. They do not host a Flatpak repo of their own (Snap does the near-equivalent job), nor do they control Flathub or any of the other Flatpak repos (at least as far as I know). This means that if something goes awry with a Flatpak, the user is pretty much left to figure it out for themselves.

What’s worse, most of the Ubuntu flavors (and Ubuntu itself) provide free technical support via forums and IRC channels. Most of our users are using software from the Ubuntu repos or Snap Store and we are equipped to help them. We know what to expect from the software our users run and can give targeted and efficient advice on how to resolve issues. Some of us can even kick things into shape in the archives if there’s a legitimate problem with our packages, or we know who to talk to.

With Flatpaks, the situation is much more dismal from a technical support perspective. We have little-to-no clue what quirks the software vendor(s) will have introduced since we don’t work closely with them. We have no way to reach in and fix legitimate bugs aside from filing bug reports and hoping that they will be answered. We’re going to end up with frustrated support staff and even more frustrated users. And all because they didn’t know that if they clicked a particular button in their flavor’s app store, they would be downloading unsupported software.

Yuck. No thanks.

Ubuntu provides plenty enough software for most people in the apt archives and in the Snap Store. In the rare instances that someone needs a Flatpak, they have to go out of their way to enable Flatpak support, which gives them a clue that what they’re doing might not end well. If they enable Flatpak, install an app, it fails, and then they come ask for help, they’ll at least expect it when we say “sorry, we don’t support Flatpaks, that’s why they require extra steps to enable”. They’re exactly like PPAs from an Ubuntu support perspective. And I’m sure we can agree that providing official support for arbitrary PPAs is a bad idea.

That, in a nutshell, is why Canonical and the Ubuntu flavors have gone ahead and agreed to not include Flatpak on the default ISOs, at least as I understand it. As a regular supporter in the IRC channels and many of the Ubuntu-related forums, I heartily agree with this decision.

(For the record, I don’t hate Flatpaks, just like I don’t hate PPAs. In fact I have Flatpak enabled on my personal system and have nn app installed from Flathub that I use. I just don’t expect that the official Ubuntu support venues are going to help me if that app goes berzerk.)"

Not sure about all this, but would this mean that Canonical may want to get rid of PPAs as well, one day, because they don't have near-total control over it ?

Quoting: furaxhornyxNot sure about all this, but would this mean that Canonical may want to get rid of PPAs as well, one day, because they don't have near-total control over it ?

They already have or actually won't have to since PPAs were never installed by default. It's precisely the same situation as here: You actively have to add PPAs and you actively have to add flatpak support. (Even Google doesn't actively prevent you from installing alternative stores on your Android phone - it just has to be an explicit decision by the user.)

Quoting: Tuxee

Quoting: furaxhornyxNot sure about all this, but would this mean that Canonical may want to get rid of PPAs as well, one day, because they don't have near-total control over it ?

They already have or actually won't have to since PPAs were never installed by default. It's precisely the same situation as here: You actively have to add PPAs and you actively have to add flatpak support. (Even Google doesn't actively prevent you from installing alternative stores on your Android phone - it just has to be an explicit decision by the user.)

I'd absolutely agree if Ubuntu just deactivated all flatpak repos by default. No issue with that. But the software needs to be there and when a user clicks a .flatpak or .flatpakref in their browser, it should work - maybe with a warning, yet without searching the internet for a solution.

Quoting: BoldosI trust it is really them and not that proverbial "some anonymous person somewhere in Nebraska" who packaged it on his/her PC and then published it to the store with whatever hacks attached inside.

I understand your argument, but there are snaps which fall into 2nd category as well. Example: https://snapcraft.io/publisher/mmtrt
AFAIK with Flatpak you need to provide build instructions if you want to get the Flatpak published to Flathub unless you can't because the source is not available.


Last edited by mr-victory on 24 February 2023 at 2:13 pm UTC

Quoting: sprocketIf Flatpak supports CLI software, that would be welcome news to me.

Like this? https://flathub.org/apps/details/io.github.paledega.alpine-rootfs

Quoting: const

Quoting: Tuxee

Quoting: furaxhornyxNot sure about all this, but would this mean that Canonical may want to get rid of PPAs as well, one day, because they don't have near-total control over it ?

They already have or actually won't have to since PPAs were never installed by default. It's precisely the same situation as here: You actively have to add PPAs and you actively have to add flatpak support. (Even Google doesn't actively prevent you from installing alternative stores on your Android phone - it just has to be an explicit decision by the user.)

I'd absolutely agree if Ubuntu just deactivated all flatpak repos by default. No issue with that. But the software needs to be there and when a user clicks a .flatpak or .flatpakref in their browser, it should work - maybe with a warning, yet without searching the internet for a solution.

But IT HAS NEVER BEEN THERE. Using standard Ubuntu you always had to install flatpak support explicitly.