I’ve been against snaps and flatpaks for a long time. But I thought to at least try snaps while I was using Kubuntu 22.04 for a short period.
The installation process feels no different to apt. And tools that I need (kubectl, krdc/remmina, datagrip, codium) are there. In some cases, I had to pass –classic to install the snap, which seemingly removes the restrictions snap otherwise places on the application.
Snap seems to be focusing on an area that flatpak doesn’t, which is services. This is good. I’m much less interested in a packaging solution that is really only targetting graphical applications - the applications I use are generally things I don’t want feature updates for. I want them to be the same every time I open them. With that said, I’m hesitant to run services as snaps.
Snap /appears/ to have a lot of Canonical’s weight behind it. MAAS, for example, is now packaged as a snap (more on that later). A lot of people focus on the dead canonical projects (bzr, unity, ubuntu phone, /mir/). But ignore the projects that survive, but are actually very useful (netplan, launchpad, cloud-init, multipass). My bitter feeling around Debian adopting systemd remain - I’m still very much of the view Upstart was killed by external force.
They’re slower to start. Everything feels like it’s running on the JVM. This is well known, so I won’t beleaguer the point.
Permissions are finnicky when it comes to filesystem access outside of the default, hard-coded locations mounted inside snap’s enclave. This is why I suspect so many snaps require installation with –classic. The directories a non-classic-contained app are given can be found here [1].
[1] https://github.com/snapcore/snapd/blob/master/cmd/snap-confine/mount-support.c#L951
I use nagsatmon [2]. Which is a Python+Qt application. Building a snap for nagstamon wasn’t terribly difficult. But my biggest problem was the relationship the build process has with git. Aside from a /soft/ requirement to use github (which is where Canonical are focusing their documentation on building snaps - it isn’t really required), I found myself unable to build a snap from a specific git branch. Maybe through incompetence. Perhaps using github’s CI/CD would be a solution? I dislike that. It doesn’t help /branch/ is a noun for both snaps and git repositories.
Arguably I didn’t need a branch, I expect github would have me fork, change my master, and then submit a PR of the differences. I don’t use github. But it makes for more sense to me to clone the repo, make my own branch containing snap build code, and then submit a merge request.
Nevertheless, getting over /how/ I’d get my code into (real) master. It was easy enough to build. Installation with –dev-mode seemed to allow me to ignore any and all permission issues the application might have had, and things, for the most part, worked.
Of course, nagstamon is free software. So I could have just installed it the same way as everything else. So I also build one of our internal (proprietary) electron applications. That also just worked, although electron-builder’s snap-building-spec seems to be changing each release. Again, without applying the permissions-side of snap.
Probably not. The kubernetes snaps are /interesting/. But given shifting processes in the cluster (let alone in the control plane) is something to be done with care, I’m not clear why I’d want to do that with snap instead of apt.
Proprietary software seems to be one reason. But Jetbrains already provide their own management solution for versions of their applications, and given they all seem to require –classic, I’ve yet to see an example where security promises are realised.