Now Ubuntu 20.04 is out the door there’s a ton more users installing and using some flagship desktop snaps. Startup speed is still being cited as a common complaint when using some of the popuplar snaps such as Chromium, Firefox and LibreOffice.
Where are we with these? What wins can we get? What further analysis is needed either in snapd or desktop launchers, fontconfig - or indeed any other part of the stack :D.
Regarding some of my investigative work, we will be working on towards this is allowing snaps to use lzo as compression format, but more work on this has fallen to the wayside a bit on my end due to the impending UC20 release (specifically we want to do a thorough check of cross-arch and cross-distro compression of lzo snaps to ensure it’s deterministic). I hope to get back to this work soon, which will unblock snaps from being uploaded to the store using lzo compression.
I’d like to say that I appreciate the open communication and general approach regarding domain-crossing issues shown here and in the “snap universe” in general. This is one of the most engaging, yet competent communities around a complex software I’ve experienced so far.
Makes you really feel like the stakeholders care for the bigger picture and are looking to improve the product and the process all the time.
Another thing publishers can already do is reduce the size of their snap. This has a significant effect on startup time; the DBeaver snap startup went from 6 seconds to 3 seconds, simply by reducing its size. I have had similar success with other snaps such as Foliate and Minecraft Installer.
I took this opportunity to start a page in the docs about reducing the size of desktop snaps. Let me know if you have more tips. Feel free to add them to the page; it should be editable by anyone.
You might want to also add an interface hook so you can update when the gnome-3-28-1804 plug is connected. That’s assuming it fires when the other end is upgraded.
how well does that work on embedded devices (i.e. single core armhf with low ram) … specifically decompressing … note that snaps are used a lot in the IoT and cloud space (where they initially got developed for). It is important that improving snaps on desktops does not degrade performance in these setups …
This is covered specifically in my post, but mainly that zstd is not well supported in older distros we would like to support, bionic for instance does not support zstd compression (last I checked, perhaps the 18.04.4 update now supports it, but it did not originally).
We hope to some day be able to move to zstd for compression, but we want to be sure it is maximally compatible, or barring that we have a fallback mechanism for users who install a snap that their machine can’t decompress they will get an alternative snap file which is just compressed with something they support. That requires even more change than just allowing upload of lzo however.
I think it landed in snapcraft 4.1, however I am a bit confused, what I as a developer need to change to “enable” that for my snaps. Can anyone help with that please ?
It landed indeed. However there was an issue which means we’re waiting for snapd 2.47.1 to roll out everywhere (via core & snapd snaps, and importantly the deb in the Ubuntu archive) first. Everyone is a little slammed with the release of Ubuntu this week. Look out for more information on this topic next week, once we’ve all recovered and the 2.47.1 roll out is complete
That was my question. I was wondering when would be available. I already have the latest version:
snap 2.47.1+20.10.1
snapd 2.47.1+20.10.1
series 16
ubuntu 20.10
kernel 5.8.0-25-generic
I think will be released via feature toggle?
Why not to make snap supporting different package formats? I mean servers could store and provide xz, lzo, zstd, non-squashfs, etc. All this without altering snapcraft.yml, as it shouldn’t be a developer’s concern. When a client asks for a package:
if it’s a new client, it specifies supported formats and chooses the best option.
if it’s an old client, just serve a good old xz version.
One current property of our design is that when a developer builds their package, those bits (the .snap file that is) are cryptographically signed by Canonical and delivered exactly bit for bit to users (along with assertions in order for folks who care to manually verify that the bits are the same, as well as automated systems within snapd which verify these assertions, but folks who care about this kind of thing can do it themselves too).
What you propose to repack the snap with different formats is something we would like to implement because as you mention it would actually be the best of all worlds, new clients can get the best, while old clients can still work with new snaps uploaded to the store, but this would require some re-architecting of our whole flow which will take some time.
Note that I have updated the scripts from 