I think I’d disagree it won’t work for the majority of normal users, it won’t work for all users certainly, but majority being the key word would be more than 50%. To be less pedantic and choose rougher and more realistic numbers, I imagine we’d like to say that was 90+, 95 maybe? As close as 99?
Ultimately the very concept of a sandbox is to deny something being possible, so as a thought experiment its impossible to ever both have a sandbox and also have “everything” available, the key is to what degree can we implement a sandbox that’s transparent, letting the majority of things get through whilst not being rendered unusable, and I think the technologies still have momentum to improve on that over time and would likely get to the point the layman wouldn’t be able to tell a difference. (Arguably, they already are at that point, and it’s people slightly above the layman who do things like symlink $HOME/documents to /media/ssd/documents who end up having the majority of issues, it’s a common example, and the correct solution is to use a bind mount, yet plenty of people will say it’s an insurmountable problem, and won’t ever stop popping up in support tickets).
– More Generally–
Personally my thoughts having being in the Snap community 6-7 years now is that a lot of this comes down to the community as much as the technology, at various levels.
E.G., Users keep repeating old news or half truths in social media. This is then repeated by more people elsewhere, until eventually you have more people reporting things don’t work than people who’ve actually seen those things not work. Some of that happens on Snapcraft owns forums, where you might e.g., have a thread with 100+ responses saying “This feature is lacking”, a response 80 posts down 3 years later saying “it’s added”, and posts 20 down beyond that several years later saying “How is this still not implemented?” (they didn’t read the update!).
We can see that to some degree here, there were 3 blogs posted in Snapcraft itself on the Firefox speed improvements (Firefox snap performance Part 3: significant startup improvements | Snapcraft) - that was 3 years ago now, and people still percieve Firefox to be how it was before any of this was ever done. The work on Firefox also impacted a lot of other snaps (E.G., it was related to Firefox that the Gnome/Kde extensions changed compression to LZO too, benefitting loads more snaps than just Firefox itself).
Of course, community is more than just the end users, another gripe to me personally is that the Snap Store is accumulating what politely sums up as “no-op bloat”, or less politely, garbage. The model of being open in allowing people to submit snaps results in 500+ “Hello World” snaps on the store (Hello world - you can make these invisible in 2 clicks, please do) or apps that historically would have worked decently but haven’t seen any updates in several years. To me, we’ve a problem of people being keen to upload snaps and a lack of people being keen to actually maintain them, it’s understandable when there’s been years between creation and retirement, but to me there needs to be a harder mantra establishing a person as responsible, both in the sense of that they’re technically competent and also that they’re making good faith efforts for the community in maintaining that package long term.
I say that as someone who’s had my own snaps re-uploaded by other users, then promptly abandoned, and now have to keep in mind 5 years later that there’s STILL broken duplicates of otherwise functional and maintained packages, and can peek at some of the usage logs to prove there’s still people using them. That’s a terrible position for us to be in as a software repository, why are we providing people with broken versions of existing packages? And generally broken packages at all. This is an awful user experience and isn’t insurmountable but IMO there’s very little being done about the consistently growing list of unmaintained snaps and they outgrow the list of well designed and functional ones.
To me, I think there’s a long term future for snaps to co-exist alongside traditional packaging (as other people have said, they wouldn’t exist without them) - and to use snaps selectively to bolster the existing classical distribution. Separately I think idea’s like Core Desktop are worth pursuing because going back to “Normal” users, I’ve absolutely installed Linux in past for ChromeOS-like user experiences and I think Ubuntu Core Desktop would be able to punch harder than ChromeOS in that area. I could easily imagine myself daily-driving a fully Snap powered desktop using LXD container workflows, other distributions are already enjoying fans.
Ultimately, it makes me upset that snap is both significantly more popular (in terms of absolute numbers of users, although naturally mostly Ubuntu inclined…) and less popular (in appeal), which in my experience as a packager leads to weird situations like having 3x the users of say equivilent Flatpaks, but 1% of the bug reports. That’s not to say I don’t have bugs, it’s more my snaps have bugs fixed that are identified in the Flatpak repositories first, after I include the Flatpak in my daily trawls, because for whatever reason the Flatpak community although smaller in absolute terms seems to have a much more successful interaction between each part of its overall community going on.
(To be fair, I do see a lot of feedback on "WHERE do I submit Snap bug reports?, so maybe there’s work to be done there, although frankly even as an Ubuntu user on and off for 20 years, it’s still not in my nature to use ubuntu-bug - it’s not obvious enough, that said, why doesn’t it work with Snaps? We’ve bug report meta data in snap.yaml and the store API’s now).
This is a bit wordy, and possibly going off tangeant, but hopefully someone found it interesting. In tl;dr fashion, my personal opinion now is that Snap has accidentally ended up in a position of quantity over quality and IMO it’s worth at a project level deciding that after 10 years it’s not an upstart project anymore, and begin transitioning to a more curated (but not overly so) model. That’s not to say I don’t want people to find it easy to begin working with and publishing snaps. But actually, it does need to be harder than it currently is with more ongoing curation, because the amount of damage that a person can do in ten minutes isn’t limited to the ten minutes they upload a snap and never come back, but the ten years its “yet another broken snap” still being shown to users; which isn’t going to stop unless intervention happens.
Final Thoughts
From the snap side, we should keep up with blogs, we should increase the blogs! We have things being repeated that aren’t true, and we have innovations happening that people don’t pick up on. Stuff like James Henstridge implementing an XDG Portal to benefit Flatpaks and Snaps regarding Web Browser Extensions - why do people see the world as Snap vs Flatpak? That’s literally a win for both and a great example of FOSS collaborating even with differences. Comments like “KeepassXC doesn’t work with snap Firefox” doesn’t have to be true and also isn’t in Ubuntu 22.04+ as of a few weeks ago. (It’ll still be true in some places and there’s work to be done, but it’s progress).
Things like the AppArmor patches being upstreamed in 6.15. Do the Arch Users now know they kave SNAPD_REEXEC enabled like Debian relatively recently now? And that with kernel 6.15, they would have fully confined sandbox like it was Ubuntu itself, technically able to use e.g., prompting-clients too (have we told people Prompting Client exists yet?)
Do people know about the ongoing work for LSM Security Stacking with SELinux, so we can have a world where a Fedora user with snapd gets AppArmor without having to disable SELinux from their base services? Because it’s a work in progress, and it shows that whilst the problems might not be easy to fix, they’re at least acknowledged.
We’ve a weirdly sticky stigma and whilst there are still valid technical problems, I think there’d be huge gains to be made in a better handle on the community side too, which is probably a bigger problem to long term adoption than the technical side alone.
