Ubuntu flavours to drop Flatpak by default and stick to Snaps

Quoting: BoldosWell, 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 normally available in standard official repos (.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.

The problem with snaps is that only Canonical has access to what goes there. And they don't have the manpower to curate everything like Apple does. Which is how things like that 2048 game slipped in that had a bitcoin miner attached to it.

The beauty if flathub is you can see on each app page whether or not it is a trusted upload by the developer, for example; Firefox is, but Discord is not.

But this isn't even the problem to me. The problem is that Ubuntu pretty much is a fork / rebuild of Debian. And people who are basing their builds off of Ubuntu because of their more frequent release schedules are now being mandated to not being able to give their users choice. What constitutes a 'flavor' in their mind? Is that Kubuntu, or is it things like Linux Mint / PopOS. Some of them still use the Ubuntu repos. This just seems like early shots to try to eliminate competition.

Quoting: Tuxee

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.

Right, this is about them forcing derivatives to not be able to have it there by default. Let's say SteamOS had been built upon Ubuntu. None of those awesome utilities would be available without some nonsense. I'm betting most of them are not there as snaps.

Quoting: Boldosthe package is marked as *Verified developer* e.g. Microsoft, or JetBrains or Spotify

Coming Soon(TM) to Flathub, the about page of beta website now mentions "verified apps"
https://beta.flathub.org/about

Quoting: mr-victory

Quoting: Boldosthe package is marked as *Verified developer* e.g. Microsoft, or JetBrains or Spotify

Coming Soon(TM) to Flathub, the about page of beta website now mentions "verified apps"
https://beta.flathub.org/about

Yes.
And this is great news; I'm glad that Flahub will have this too. Getting a bit closer to be on par with Snaps, so one more step for flatpaks to be more usable for me.

Anyway, we have this (basic, crucial) functionality with Snaps for how many years now?
Observe: They are following Canonical's footsteps. Yet again....


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

Quoting: slaapliedjeAnd people who are basing their builds off of Ubuntu because of their more frequent release schedules are now being mandated to not being able to give their users choice. What constitutes a 'flavor' in their mind? Is that Kubuntu, or is it things like Linux Mint / PopOS. Some of them still use the Ubuntu repos. This just seems like early shots to try to eliminate competition.

Well, you could ofc inform yourself. (But I assume that's "work" and just less fun than ranting.) Well, you would have learned that distros named *ubuntu are flavors. Mint, Pop_OS!, Zorin, elementary, KDE Neon and a gazillion other ones are separate distros which can ship whatever they want.

Quoting: slaapliedjeLet's say SteamOS had been built upon Ubuntu. None of those awesome utilities would be available without some nonsense. I'm betting most of them are not there as snaps.

That's one stupid "argument"...
What utilities are we talking about? Steam Deck specific ones, I suppose. Why should I have them on my Ubuntu desktop? Anyway, if the Deck was Ubuntu-based it still could provide flatpak support, because why not (IT'S NOT AN UBUNTU BRAND for chrissake) or the tools would have appeared in the snap store. Because again: Why not?

Quoting: TuxeeWhat utilities are we talking about?

The original argument falls flat even in comparison what Steam OS does that Arch does not – e.g. read-only root file system and preinstalled Steam client. Arch comes without preinstalled flatpak as well.

Quoting: BoldosWell, 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 normally available in standard official repos (.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.

You're mostly correct. As it stands, it's difficult to be sure of who uploaded said Flatpak and what they have put into it, that's a problem. In fact, in the early days this is why I was hesitant with Flatpak, I liked the idea of having centralized repositories from my distribution of choice for trustworthiness and peace of mind (if you can't trust your distro packagers? Well.. good luck to ya!).

There's three potential existing solutions for this that can offer peace of mind:

1) After installing an application, manually adjust its sandbox permissions, remove any overly broad permissions such as "access all home files" and restrict its permissions to strictly what it needs. Doesn't need network access? Turn it off. Naturally you do this before launching the application for the first time.

This can be done in two ways, in KDE 5.27: System Settings -> Applications -> Flatpak Permission Settings

Without KDE or an older version of it: Flatseal

Honestly, changing these settings is always the first thing I do with new applications from Flathub.

2) Use a more trustworthy repository. Now you might be thinking "well who can you trust?". Well some distributions, such as Fedora offer their own flatpak repositories, which are curated and compiled by the project. Naturally however, being Fedora, that repository only includes FOSS software.

Honestly, if you can't trust Fedora / Redhat Developers? You might as well just give up trying to secure your Linux from them as their code is in almost every core component.

3) Don't go installing things you've never heard of, or things you're not sure if you can trust. Research it before you install it. I once knew someone who wasn't sure what dd did in detail and somehow managed to overwrite their operating system disk with an ISO file.


Last edited by BlackBloodRum on 24 February 2023 at 4:45 pm UTC

Quoting: pleasereadthemanual

Quoting: Purple Library GuyIs it really a "competitor option"? I don't think Flathub is maintained by some specific other distro company. My understanding of Flatpaks is that they are just an independent piece of software, like LibreOffice or something. If Canonical were to start considering the whole open source ecosystem to be "competition" they would have problems.

On the other hand, for every other distro, Snaps really are a "competitor option" since they're created and maintained by not just a particular distro, but by a for-profit corporation, and Snap as currently written works with just one repository, Canonical's.

I think there is a disconnect between your two arguments here.

I don't think there is. At most, I think you're greatly overstating it.

Quoting: pleasereadthemanualLibreoffice is shepherded by Collabora; they sell support/development services for it, so I don't think that's a great example. But also, businesses can sell services for free software (and sell free software on its own as Ardour does, though this is rarer), so doesn't it make sense that anybody who offers a service which competes for their market is a competitor, regardless of whether they're earning money from it? I mean, Amazon lost money for years so they could service more of the market than competing companies.

And businesses can also sell competing services for the same software. Mumble is a great example of this. You'll see a lot of businesses offering Mumble servers.

All that is all very fine, but the motivation you're sketching is for most software pretty vague and attenuated. You could say that for any distro, or at least any distro with a for-profit company at its centre, they have a motivation to never use any software they didn't write in-house. But for most things it's a very small motivation compared to the motivation of not wanting to write the damn software.

(As to LibreOffice, I didn't remember it being run by a distro, and I just looked it up, and it is not. They've got this "The Document Foundation" thing which as far as I can tell isn't even associated with any distro in particular. I dunno, maybe Collabora contribute more code than others, but that is not the same thing. And let's not forget that Libreoffice is Libreoffice precisely because people got sick of OpenOffice being tightly controlled by a corporation. So my example was fine, even excellent)

But packaging is infrastructure at the core of what makes a distro, a distro. So, I'm running a distribution. I have a choice: A package system which is not controlled by any particular other distro, and which has a significant "reference" hub for packages, but not an exclusive one--I could do my own packages, host a hub of my own and so on. Or, a package system which is controlled by a large distro which is fairly explicitly a competitor for my "market share", and which does not allow me to make or host any of my own packages unless I rewrite it first--I would have to use my competitor's hub and go with their choice of what should be available. Who on earth would make the second choice?

Well, apparently nobody because I don't know of any non-Ubuntu distro that has adopted Snaps, not even distros that are derivatives of Ubuntu. So I'd say there is some empirical confirmation of my theory.

Now, again, I don't think this is actually some kind of mistake on Canonical's part. I don't think they're doing Snaps for the purpose of having anyone outside Ubuntu + "flavours" use them. They're doing Snaps so they can control the user experience, and they would totally understand if other distros, also wanting some control over the user experience, wouldn't want to give that control to Canonical. But I think if other people believe there's a real chance of Snaps spreading outside Ubuntu, they are mistaken.


Last edited by Purple Library Guy on 24 February 2023 at 7:11 pm UTC

Quoting: Eike

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.

For a lot of apps there is no alternative to snap store either, since a lot of third party providers only publish their apps in snap store. Most people don't put too much emphasis on the what-if like you do, they just think the store is available now and it serves their purpose so they use it, if something goes wrong with Canonical they'll look for an alternative. Canonical owns the store, but not the apps. If something goes wrong with the store, the publishers will publish their apps somewhere else.