Ubuntu Talks Up Faster KDE Snaps, But Still Takes A While For Cold Apps To Launch

[ssokolow]

My Linux distro would be hardcoded to verify my signature as a distributor as well.

Then I'm just replacing one single upstream with another... meaning that I still have to either loosen security or use an alternative mechanism when I want PPA analogues.

How many times in this thread alone have stated explicitly that Flatpak cannot be used as a replacement for Snapd?

Many times... just as I keep saying that Flatpak has features that snappy omits by design which I consider non-negotiable.

because as a user of my distro, you trust me. If I tell you that I have certified that a given package comes from Canonical, then why would that be different from you trusting that the kernel I give you was compiled from the source I say it was compiled from?

Simple. I don't want to be stuck badgering a single signing authority for every package I want to install with signature enforcement enabled.

Do you want me to repeat it over again, that Flatpak is irrelevant in this context precisely because it is a totally different thing?

Fine. sed s/Flatpak/OSTree/g then. The arguments about things like allowing users to add additional remotes still apply, even if Canonical tries to muddy the waters by smushing two different scopes of functionality into a single tool.

[jo-erlend]

Then I'm just replacing one single upstream with another... meaning that I still have to either loosen security or use an alternative mechanism when I want PPA analogues.

The PPA system was designed to let people easily test their own software. That is why they are called Personal Packages. I loved it. I would write some code on my old laptop, then commit it, and moments later, I would receive an update through my package manager, fully compiled, packaged and ready to use. It wasn't designed to be the extremely serious attack vector that it became when people started using it to share software with others.

But it is wrong to say that Canonical's Snap Store is single upstream. In fact, for packages that can be automatically verified, you can send in packages for sharing or personal use just as easily as you ever could with PPAs, but in a safe way and you can run as many different versions of the package you want without conflicts. Users will not have to subscribe to your PPA and give you root access on their systems. The packages will just be available to all users at once.

For packages that could be dangerous somehow, your package will have to be vetted by the Snapcraft community, which could be easy or difficult depending on the software.

Many times... just as I keep saying that Flatpak has features that snappy omits by design which I consider non-negotiable.

But what is your point? Snapd deliberately does not prevent the use of Flatpaks. If you want to, you can use snaps for your core system and all server stuff and use Flatpaks for all desktop applications. You could not do it the other way around. So the only way I can see your side of things, is that you want Canonical to impose an artificial ban packaging desktop applications as snaps. Your job would then be to explain to me why that would be beneficial to me as a snap user.

If Snapd had somehow made it difficult to use Flatpak, then I would've been on your side, because I want more collaboration and less conflict.

Simple. I don't want to be stuck badgering a single signing authority for every package I want to install with signature enforcement enabled.

But I don't want to give you the right to tamper with my kernel just because I want to use your Angry Birds package.

Fine. sed s/Flatpak/OSTree/g then. The arguments about things like allowing users to add additional remotes still apply, even if Canonical tries to muddy the waters by smushing two different scopes of functionality into a single tool.

Most of the functionality provided by OSTree, should in my opinion, be provided by the Linux kernel, using modern filesystems. I don't see the advantage in adding complex secondary layers to recreate the inate features of the underlying filesystem. Whether they end up using ZFS or Btrfs, I think that using their snapshot capabilities along with their send/receive functionalities, is far superior. For now, they're sticking to SquashFS files for their simplicity, enabling them to work on other aspects of the system. That is an implementation detail that I expect to go away in the future.

You seem to be under the impression that I'm advocating the perfection of the status quo. I'm not at all doing that. I'm quite aware of the bugs and limitations in the snap system. That is why I support the developers. What I do like very much, is the system design and the visions that it enables, including the use of the most advanced features and powers of the Linux kernel, while keeping the system simple and user-friendly.

But you will notice that I am not in any way opposed to Flatpak and OSTree. If it means anything to anyone, then Fedora has my absolute and total support in designing their system the way they want to design it. I just don't see this as a source for conflict at all. Why would we ever need freedom if everyone has to agree on everything all the time?

[ssokolow]

The PPA system was designed to let people easily test their own software. That is why they are called Personal Packages. I loved it. I would write some code on my old laptop, then commit it, and moments later, I would receive an update through my package manager, fully compiled, packaged and ready to use. It wasn't designed to be the extremely serious attack vector that it became when people started using it to share software with others.

But it is wrong to say that Canonical's Snap Store is single upstream. In fact, for packages that can be automatically verified, you can send in packages for sharing or personal use just as easily as you ever could with PPAs, but in a safe way and you can run as many different versions of the package you want without conflicts. Users will not have to subscribe to your PPA and give you root access on their systems. The packages will just be available to all users at once.

For packages that could be dangerous somehow, your package will have to be vetted by the Snapcraft community, which could be easy or difficult depending on the software.

Sorry but having a single privileged upstream source and requiring you to rebuild the package tool to grant those privileges to another source just isn't sufficiently in the Linux ethos for me. If I wanted that, I'd be using macOS or iOS or Android.

Every Linux packaging system except snappy supports supplementary sources from third parties, if that's what you so choose.

But what is your point? Snapd deliberately does not prevent the use of Flatpaks. If you want to, you can use snaps for your core system and all server stuff and use Flatpaks for all desktop applications. You could not do it the other way around. So the only way I can see your side of things, is that you want Canonical to impose an artificial ban packaging desktop applications as snaps. Your job would then be to explain to me why that would be beneficial to me as a snap user.

If Snapd had somehow made it difficult to use Flatpak, then I would've been on your side, because I want more collaboration and less conflict.

1. But why would I bother with the architecturally inferior, slower system (snappy) in the first place?
2. That's like saying "You can't distribute systemd as a constrained snap"... No shit. Flatpak is, by design, a layer on top of OSTree to constrain non-infrastructural packages such that they can work equally well on all distros.
3. I don't feel much trust for an upstream who are willing to replace APT packages with dummy packages that reinstall snappy and then proxy over to it if you've removed it.

But I don't want to give you the right to tamper with my kernel just because I want to use your Angry Birds package.

...which is why you use Flatpak... so that, if you're determined to get that Angry Birds package...

1. You can still trust that any malicious behaviour the sandbox must constrain has to come from the package maintainer, because you haven't opted out of signature verification to install your third-party package.
2. The system is fundamentally built around progressing toward having infrastructure sufficient that things like filesystem=host (the closest you can get to unconstrained snaps, and it still blacklists various vulnerable things) are unnecessary. (eg. I'm currently giving feedback on proposed UI designs for a "This program wants to access files adjacent to the ones you open (such as subtitle files for videos)" XDG portal.)

Most of the functionality provided by OSTree, should in my opinion, be provided by the Linux kernel, using modern filesystems. I don't see the advantage in adding complex secondary layers to recreate the inate features of the underlying filesystem.Whether they end up using ZFS or Btrfs, I think that using their snapshot capabilities along with their send/receive functionalities, is far superior. For now, they're sticking to SquashFS files for their simplicity, enabling them to work on other aspects of the system. That is an implementation detail that I expect to go away in the future.

From where I'm standing, your position seems to be "I'm in favour of this flawed system from a vendor with suspect intents because they're the only ones with the vision to break things for long-term gains". I think we're going to have to disagree on that.

But you will notice that I am not in any way opposed to Flatpak and OSTree. If it means anything to anyone, then Fedora has my absolute and total support in designing their system the way they want to design it. I just don't see this as a source for conflict at all. Why would we ever need freedom if everyone has to agree on everything all the time?

If that were the only problem, I'd be fine with it. You don't see me railing against Appimages, do you?

My opposition to snappy is due to Canonical's efforts to promote it as a Flatpak/OSTree killer.

[jo-erlend]

Sorry but having a single privileged upstream source and requiring you to rebuild the package tool to grant those privileges to another source just isn't sufficiently in the Linux ethos for me. If I wanted that, I'd be using macOS or iOS or Android.

Yeah, I want a centralized GNU+Linux distro. I've wanted that since RH5. What's new to me is that people don't.

[ssokolow]

Yeah, I want a centralized GNU+Linux distro. I've wanted that since RH5. What's new to me is that people don't.

I'd be find with that if Canonical weren't trying to push for snappy to be the standard everyone else uses too.

[mppix]

Immutable distros, blabla? That is what Ubuntu and Fedora are doing. If you are against that, then that's perfectly fine. You can hate Ubuntu and Fedora as much as you like, ...

No!
Not sure about your universe but in this one Fedora and Fedora Silverblue or Ubuntu and Ubuntu Core are completely different beasts.

..., but it won't change the fact that no GNU+Linux distro will ever replace their distribution formats until Flatpak has been redesigned from scratch.

let me rephrase that for you : "No GNU+Linux distro will ever replace their distribution format for Flatpak or Snap."

[mppix]

Yeah, I want a centralized GNU+Linux distro. I've wanted that since RH5. What's new to me is that people don't.

You should buy Mac. That should be close enough.

Everyone else will keep rocking in the free world.