That video is five years old and starts out with a question about why the Snap Store is not open source. I just showed you the open source code for the Snap Store. You can even go there and look at the rather permissive license used. So I’m going to go ahead and say that is outdated and not relevant.
Do you have anything recent that suggests otherwise and doesn’t refer to old information as its source?
23s to load firefox???
Whats your detailed machine specs?
If you have HDD and/or low RAM of course you won’t notice a difference.
The repositories you indicated also exist for more than 5 years, and yet Popey said that “The benefits aren’t significant enough to make it worth opensourcing”, which means that there are or were components that are not opensource.
I don’t know exactly what these components are, nor have I collected all the links that say there are closed source components. If that’s no longer a fact and it’s completely opensource, then it’s news to me. Perhaps the snap developers could clarify this matter further.
But perhaps this subject is straying too far from the topic…
Those repositories may have existed for more than 5 years, but that doesn’t mean they were public that long. That’s what I’m not sure of.
I would not say that this is straying from the topic. I do think that what you and @James-Carroll both said is true: that some of the problems we face with advocating for Snaps is that there are some issues we have with the image of Snaps. Some of this is, like James said, based on old stuff. This is more of the same. We have to understand these issues clearly so we can develop ways to confront them. This is kind of why I suggested a big announcement above that describes a whole new era of Snaps. Kind of wiping the slate clean.
In any case, maybe we should go straight to the source. @popey in that ancient interview with you, when you were referring to these closed source components of the Snap Store, are those still a thing? Any chance you could shed light on what they are, or at least how necessary they are? Like someone could just set up their own store with the existing codebase, no?
Hello friends! I’ve been afk for the weekend in a lovely shepherds hut. I also visited Ludlow Castle and Worcester Cathedral. I highly recommend going to either of those locations if you’re ever holidaying/vacationing in the UK.
Anyway, catching up a little…
Yes, the backend to the snap store is still closed source, so what I said in previous interviews almost certainly all still stands. However, I wouldn’t claim any superiority of Flathub in this regard, given their 100% reliance on (the very non-free backend) GitHub.
(Be cautious of anyone doing the slight of hand saying “But flatpak doesn’t need GitHub, even if flathub uses it”, because we’re all very aware flathub has become the de-facto, high profile, and popular repository that flakpaks are published to). 
While snapcraft, snapd, and the web frontend to the store are all indeed fully free software, the bit that hosts the blobs you download with snap install and snap download, confusingly called “Snap Store Server” is non-free.
As an aside, and personal opinion, I don’t think this is the “gotcha” that people think it is, to be honest. Sure, if people want to make a principled view of the backend snap store, while downloading non-free apps on their non-free Android device, or playing non-free video games from their non-free steam store, so be it…
Making demands in 2025 about what Canonical (or indeed, volunteer developers) should spend their time doing is a mission in futility. It didn’t work in 2016 when snaps were first developed, and won’t work now.
Also, if anyone says “If this isn’t changed, I’ll go and use Mint” or whatever the distro-du-jour is, the answer should be “Ok”. This isn’t a competition. If you would like to use a different distro than the one you’re using now, by all means go ahead. It will not affect anyone here, nor will it motivate anyone to change anything, by you saying it or doing it.
On the subject of performance testing, the simple “time /usr/bin/firefox” is a great first step. It’s what we did when we were trying to prove poor performance. Some people have done much deeper analysis of performance testing application startup, and it’s quite daunting. I’m working on a system which makes this a lot easier for “normals” to prove/disprove their points. I’ll share it online once I have something useful.
Software packaging is hard. Making perfect software packaging is even harder. Cut our developer friends some slack, and lets listen to the users who complain, but listen harder to those who come bearing gifts - actionable data.
<3
Snaps can’t seem to handle uploading from a webdav share. Doesn’t trigger the desktop security center, too.
I guess binding isn’t an option for webdav?
One sandbox issue not mentioned here yet is usage of non-system graphics drivers. Steam containers have some (complicated) solution for that. But both Snap and Flatpak containers use graphics drivers from application. That leads to issues like Firefox Snap issue on Raspi. Firefox used old drivers from core22 instead of fixed drivers from Ubuntu 24.04 . It would be great to find solution for that.
In core24; snaps using extensions will use a content interface for their MESA/graphics stack (e.g., Install mesa-2404 on Linux | Snap Store) , like Gnome/Kde are themselves; capable of recieving updates independantly of the application alongside the core/base.
This interface can be nice and independant so my expectation would be that it’s capable of recieving updates well beyond the previous LTS’ freeze date. I.E., for longer than 2 years.
But if not, by being a content snap, you can swap it out. There’s interest long term in having several different releases so you could track Mesa closer to upstream; or instead stick with more widely deployed Ubuntu archive stacks, etc.
So; a lot of this will hopefully alleviate if/when they rebase on Core24; it also doesn’t apply to the proprietary NVidia drivers at all, which always use the host.
To avoid possible confusion, the 2404 in Mesa above doesn’t mean it’s stuck to Mesa libraries from 2404. It’s free to backport from Ubuntu 26.04, 28.04, 30.04; etc - the 2404 relates to ABI compatibility guarantees not library versions.