In the real-world millions of people use Snaps every day… While that doesn’t mean there aren’t problems, it serves to highlight that the few people vocal about their reluctance to use the system are by far outweighed in numbers by the people who use it without issue.
2 Likes
Fair point, I just thought I’d offer a new embedded dev’s perspective and first impressions. Also, I want to be clear that just because I dislike these things, I think snap is kinda cool and I’d like to work on improving the Documentation I have issues with, and (if I ever have any freetime) I’d like to address some of the development cycle issues I have. (For example, python plugin cross compilation).
I’m not trying to win any wars here, I’m just providing some context for this discussion. I also think there are glaring issues with snaps, but I think it’s important to explain the context so both parties can understand each other. Without understanding, these discussions turn into unproductive “yes!”, “no!” shouting matches.
I don’t think anyone has to be convinced that the startup speed is still an issue for some desktop snaps. Many people are working on fixing this, both from Canonical and people in the community. The latest work on startup speed is discussed here: Application startup performance
Part of the difficulty with snap startup speed is that the issues fall into two categories: issues with individual snaps and issues with snapd itself.
- For example, reducing the size of your snap greatly improves startup speed. Simply updating your snap to use the desktop extensions will also improve the startup speed of your snap. Updating all these snaps is a long process, especially since snaps are published by thousands of different developers. Flathub has an advantage here in that they have much more oversight in who publishes Flatpaks and what build manifests these people are using, given that every app manifest is part of one GitHub org.
- On the snapd side, many performance issues have already been fixed. The remaining issues now are the compression and library caching and are currently being worked on. However, these only affect a small number of snaps. Most snaps are able to have good startup performance if they are updated to use the latest tools.
1 Like
This is a growing problem of politics, ideology, public perception.
It doesn’t matter how many people use Snaps. What matters is that Flatpaks exist and provide a good enough alternative for desktop applications, and give you 1 distribution platform with which to reach all of Linux, while Snaps are being marginalized to the point where they may become Ubuntu only.
If you were a developer trying to distribute an app on Linux, would you prefer to reach all users with 1 package, or reach all users with 1 package and then also redundantly reach 40% of users with another package?
Flatpak and Flathub make Snaps redundant, so why should developers use Snaps at all for desktop application distribution? As a developer, wouldn’t you prefer to reach everyone with minimum effort?
When Snaps are being vilified and de-legitimized it doesn’t matter how technically excellent they are. They simply won’t be used and will even be actively blocked, like what the original topic of this conversation is about.
Take nuclear energy for example: new and better and safer reactors have been designed, but they are not used. Instead we keep using old reactors way past their expiration date, like Fukushima. Why? Because nuclear energy has been turned into a boogie man and therefore regulated out of existence.
The same thing is being attempted against Snaps.
If Snaps are illegitimate than all the many interesting and useful things they can do and their technical excellence will be irrelevant. They will simply be shunned by the wider Linux community, and perhaps by over 30% of current Ubuntu users (according to your survey), who, the more you transition to delivering applications as Snaps, the more they will jump ship to another distro.
As far as secondary issues, I do have issues with the documentation. I made a little command-line game called Sparky and wanted to ship it with Gnome Terminal so that I could launch it full screen like a normal game with a .desktop file. I didn’t find any documentation that would help me. I didn’t find any documentation directly addressing what parts are, how to bundle dependencies, or how to add a launcher for my app or the file structure. So I shipped it as something that can be launched only from inside a terminal.
BTW, Sparky is a Snap exclusive. The only other way to get it is to compile it from source.
I don’t think startup times are a real issue. VS Code launches in 3 seconds. Android Studio in maybe around 10 second. Most apps that I’ve tried are around VS Code’s speed or maybe even faster. It’s not snappy, but it’s passable. If nobody pointed it out I wouldn’t have paid any attention.
I don’t think file size is important, because who cares? As long as it’s not huge users probably won’t notice, except for a few zealots of efficiency. What will kill Snap is the issue of legitimacy.
2 Likes
The captain is holding the steering wheel going on and on about how big and beautiful and majestic his ship is, and how the engines are state of the art and so powerful. One of the passengers comes screaming to the captain that there’s an iceberg right ahead. The captain then explains to the passenger that his ship is really big and state of the art and is accelerating very nicely, so everything is okay.
Yes, the ship is big and beautiful and majestic with powerful, state of the art engines, but what does that matter when there’s an iceberg in your path if you don’t turn to avoid it?
That’s the problem here. Not the technical details, but the strategic situation.
2 Likes
Might be that our documentation isnt the best here, but below is a full iteration of building/developing a snap on a core18 device … (for convenience you might want to manually add your user to the lxd group in /var/lib/extrausers/group, that saves you from needing sudo with the lxc commands)
$ grep Model /proc/cpuinfo
Model : Raspberry Pi 3 Model B Plus Rev 1.3
$ grep PRETTY /etc/os-release
PRETTY_NAME="Ubuntu Core 18"
$ snap install lxd
$ sudo lxd init --auto
$ sudo lxc launch ubuntu:18.04 bionic
Creating bionic
Starting bionic
$ sudo lxc shell bionic
root@bionic:~# snap install snapcraft --classic
...
root@bionic:~# git clone https://github.com/ogra1/htpdate-daemon-snap.git
root@bionic:~# cd htpdate-daemon-snap/
root@bionic:~/htpdate-daemon-snap# snapcraft --destructive-mode
...
Snapped 'htpdate-daemon_1.2.2_armhf.snap'
root@bionic:~/htpdate-daemon-snap# exit
logout
$ sudo lxc file pull bionic/root/htpdate-daemon-snap/htpdate-daemon_1.2.2_armhf.snap .
$ snap install --dangerous htpdate-daemon_1.2.2_armhf.snap
htpdate-daemon 1.2.2 installed
$
6 Likes
The problem is larger,
The “autoupdate” to ONLY canonical servers is a real problem in our opensource ecosystem. We are running totaly disconnected LXC containers and we don’t want that a problem who leads us to connect to internet (firmware update download etc…) leads to a castastrophic update. SNAP is ok for desktop use, but not for Server production use.
We actualy manage this actualy in deb packages with internal mirror who is running N version, there is N+1 version ready, so we start update to a locked version ecosystem who has been VALIDATED. But this INTERNAL mirror is not possible anymore with snap (only a version of “proxy” for “closed beta” are you serious ?!)
I handle this in 18.04 by removing snap and removing possibility to install it. BUT with lxd 4.x there’s a dependancy with LXD and SNAPD… So with actual SNAPD update policy AND SO LXD we don’t work on 20.04 migration (but on another solution migration) it’s a dead end.
Canonical is going to kill his server ecosystem with totaly irresponsible decision : no local mirror and no local repos AND no LXD without SNAP.
Does Linux distro needs a new package version ? Does Linux distro need a vendor locked install process ? What are you playing ? even Microsoft is comming to full open architecture.
The LXD snap supports channels and tracks; they create a new track for every major release. When you switch to the track of a major release, you will only get minor and security updates automatically. To update to a new major release, you have to manually switch te snap to the channel of the new release.
See https://snapcraft.io/docs/channels for more information.
Does this solve your use-case? You can switch a few test machines to the track of the new release and when everything works, you can switch all machines.
1 Like
Registered just to say this.
I quit ubuntu due to “snap”, and i’m not going back!
You must understand that you are humans and errare humanum est, even though you are Canonical.
Hence auto-updates will live (since you are a mini-microsoft now) until you screw up so badly that everyone realizes how bad it was in the first place. And i hope that linux users are not windows forgiving fools.
You are breaking the whole idea of the open source and this is enough for me to leave you.
p.s. GPU HPC cluster maintainer and lead admin + phd appl.math.
1 Like
Despite all the wrong points made but…you do know that there are ways to opt-out of snaps right? Like uninstall snapd and set up an APT pinning so that it won’t be re-installed due to the deb2snap dependencies.
Well this may be a workaround at home, on a personal pc.
Not when you’re in charge of dozens or hundreds machines.
I totally understand why LXD should be able to run without any dependency to snap, or why mirroring a « local » snap store is a needed thing at scale.
And I’m really not familiar with LXD… So I guess educated people at Canonical thought about that way deeper than I ever could, right ?
there isnt much to think about, maintaining a package on all possible underlying distros and their derivatives, fixing bugs with all possible combinations of userspaces and kernels costs a plethora of manpower … having to maintain a single snap instead frees up huge amounts of developer time to fix actual bugs in the packaged application instead
… if you had a team of three, would you prefer to have two of these devs working only on porting and fixing distro specific bugs of the different flavours your app runs on, or would you prefer having all three of them work on your application with one of them occasionally testing/releasing an automatially built snap ? this is simple math of not wasting developer resources.
7 Likes
I know you’re right.
But getting back to an older post : it’s not made while « walking in user’s shoes ».
Solving dev’s’ problems does not solve users’ issues.
The example about LXD is not exactly a « wide audience » matter. If there’s such a limitation when « snap’d » then it was not rightfully thought dev’ side.