What happens if Canonical decides to close the snap store?

We are building a hardware based on Snaps. I am nervous as to what would happen if after 5 years Canonical decides to scratch the Snap Store or even the whole project. Will that make our devices unable to update their software ?

For cases like this, I think having an option to have a self-hosted Snap store makes a strong case. Dustin Kirkland did a demo in 2016 but I wonder if that is even possible today ?

2 Likes

It’s a concern with any kind of centralisation for sure, but I think the open source license of all the supporting software around snap and snapd should be some comfort. We just saw what can happen recently, with Red Hat’s changes to the CentOS operating model. A lot of people in the FOSS community decided that decision didn’t serve them well, and now we have AlmaLinux and Rocky Linux already getting to the point of pushing out early releases.

I think in the event that Canonical abandoned the Snap Store, you’d find forks or rebuilds of snapd appearing very quickly in a similar fashion, pointed at alternative/replacement repositories.

1 Like

Perhaps take on how Canonical has behaved when they abandoned (ceased to use is perhaps a better term?) other projects such as Mir, Unity and Upstart. Did they just close it without much notice? Did they made all relevant parts open source and helped the community take over? Most companies abandon things from time to time. Use Canonicals history to make an educated guess on how they might do it.

And your company probably has to estimate if you have the financial resources and know-how (or can aquire it) in case you have to take over parts of the snap system. Or make a plan on how you can switch away from snaps to something else within the time limit set by your discoveries on how Canonical leaves things.

just a sidenote here … Mir is well alive and kicking (with a team of paid developers behind it and also a bunch f paying customers using it)

1 Like

Another sidenote: the Unity Desktop was taken over by the community

1 Like

And their phone OS is alive and kicking I think. And as far as I know Canonical has been very responsible when they leave a project.

But still, might be worth thinking about if a company can afford to step in and take over for Canonical (or any other company with their systems for that matter). On the other hand, not using snaps and build something else has its own cost.

1 Like

Coming from embedded world I wonder what benefit really is behind snaps on the device? I see only downsides.

The main ones are:

  1. transactional updates for both the base system, and applications. So no problems with “half installed” updates, or different update orderings giving different results.
  2. A standardised core operating system that is someone else’s job to maintain. This also means you’re not on the hook for security updates to core system libraries like glibc, OpenSSL, etc.
  3. A ready made automated updates system that covers covers everything from the kernel to the applications you deploy on top of the core.
  4. A sandboxing system to prevent the applications you deploy to devices from destabilising the core system if they malfunction.

In short, you get all the building blocks to create a device that can be a responsible citizen of the Internet, so you can focus on making your application great.

3 Likes

As long the device uses relatively standard hardware where the core OS can be easily delivered. That’s not always (I’d say usually it’s not) the case.

OK, it seems I’m missing some of snaps capabilities. Are you telling me that the device can be told to use a particular combination of snaps to guarantee the target has been given tested set of applications including the kernel?

Than can be done by containers.

The way I know for embedded systems to date was to cook and complete tested image and update it in one go, so no partial updates, but no overhead related to cook all snaps and putting them together… but maybe I’m just an old fart…

On top of what @jamesh already listed, there’s the backend (store) which has a bunch of features of its own (phased rollouts, repair assertions, gadget/kernel, some telemetry?, CDN and so on) that aren’t obvious if you only look at snaps and snapd. Some of it may be available only as part of the brand store offering, I’m not sure of the details.

At the end of the day it’s a matter of whether you are ready to roll out and support something custom, or use something like Hawkbit/Mender/whatnot instance with your favorite updaters, pay for some SaaS offerings (hosted Mender, Balena maybe?), use an end to end commercial solution if your budget allows it or go with snapd & snap store.

Disclaimer, I used to work OTA solutions, eg. CarSync which became Wind River’s Helix, and Mender before joining Canonical. It’s fun but the costs of rolling out your own with scaling and support are not always obvious.

1 Like

My company took Foundries.io solution based on Docker. Foundries as far as I know are former Canonical people.

1 Like

a 100% failsafe system due to the builtin self-tests and roll-back features of snaps … along with high compression rates (snaps are compressed, gpg signed binary images that never get unpacked on disk (only loop mounted)) … binary delta updates by default (we have a ton of customers operating over 4G/5G, even in industrial PLCs that Ubuntu Core runs on)

builtin backup/restore (snapshots) and with UC20 you also get full disk encryption and secureboot OOTB on all devices that have a hardware key storage through a very simple and standardized setup …

and last but not least central fleet management and rock solid OTA and CI processes …

it is true that foundries.io, mender.io and the like offer something similar but in UbutuCore these features are builtin by default, you dont need to maintain your own bits and pieces (ever maintained a yocto with mender stuff ? thats non trivial work) and they are very easy to handle.

The transactional updates come into play here: it means that each of your devices can be running on a bit-for-bit identical file system.

With traditional Linux package management, there’s multiple ways variation could set in:

  1. if a device is offline for a while and can’t update, there’s no guarantee that it will apply the same updates in the same order when it reconnects. If a package has received multiple updates, the device will skip the out of date one. The dependency solver might come up with a different order to install the updates. With postinst scripts, it’s quite possible that this could introduce subtle differences.
  2. Lets say you’re still deploying new devices a year later: if you install them using an image with all the updates rolled in, are you certain that’s the same as the old devices that have been incrementally updating?

In contrast, every Ubuntu Core system running a particular revision of the root file system is bit for bit identical. And if the system fails to boot after the upgrade, it will automatically revert to the previous working revision next boot.

Yes. You’d write a “model definition” that declares the kernel, gadget, and base snap to use to boot the system with, plus any application snaps that must be present on your device. You pass this model definition to the ubuntu-image tool, which will spit out a disk image you can flash to the device. When it boots, everything specified in the definition will be available.

If you don’t particularly care about the kernel and are running on fairly standard hardware, you can use one of the kernel snaps provided by Canonical.

Just my 2 cents: We are working in embedded space and made our decision to use snaps precisely based on the advantages that have been outlined by @jamesh and @ogra – However I think it would be super useful to if we were able to host our own snap store just like a Docker registery etc.

Reason being we may be shipping software that we don’t want people to install unless they are using our hardware.

1 Like

@jamesh & @ogra convinced me why this might be viable solution, however, I’d like to carry my own tour through it as so far my experience with snaps (on desktop) weren’t that smooth.

That’s the mandatory prerequisite. My company’s cybersecurity and data storage rules wouldn’t allow us to keep our proprietary software in the public store.

This is a perfectly valid question to be asking.

I think there are two failure modes you should consider. First, a failure of Canonical which takes out Ubuntu itself. And second, a failure of the snap store economics which make it difficult for Canonical to continue to operate the store.

The first is unlikely but possible, especially if there is a massive liability situation which is beyond Canonical’s reserves. Canonical is a small business by global terms, about 1/20th the size of Red Hat, but we are slightly profitable. Ubuntu’s future is basically secure thanks to Canonical customers.

A massive liability, while possible, would also not be in the interests of any significant player to engineer, and in the interests of many to prevent. Any liability that impacts on Canonical could equally well impact on community distributions too, and those have additional complications if you are really thinking through sustainability. Canonical is unusual in being sustainable and relatively open. I say ‘relatively’ only because we defend certain points vigorously, we believe in the interests of Ubuntu and its community, but of course some folks think we shouldn’t do that and still consider ourselves open :slight_smile:

So, it’s probably safe to consider Ubuntu safe, as long as Canonical has customers :wink:

The second, where the snap store turns out to be uneconomic, is more interesting.

First, the design of snapd doesn’t depend in a complex way on the snap store. It should be the case that a pretty simple store can service even modern snapd. The protocol has gotten more complex, but I would expect that most of it can be ignored. In simple form, snapd says ‘hello store I have these snaps from these channels’ and the store says ‘hello snapd you should update to these versions’.

Things like staggered release cycles and fancy channels are complex and a lot of work in the store, but you don’t have to have them, so a simple store should suffice. There used to be an open source implementation of the store protocol. I know we haven’t maintained it but I also know we haven’t actively undermined the principles of that snapd-snapstore design.

As for the basic store economics, I’d say right now the snap store requires more engineering investment than it generates revenue, so yes, there is a reasonable question mark about its sustainability. BUT I can say I love the design and engineering work we have done there, I consider it some of Canonical’s best work (both snapd and snap store, and yes I have heard the rumours to the contrary, it’s just I know how hard the problems are to do properly and I’ve seen the quality of work going into addressing those problems, my thoughts are my own blah blah :)).

I personally see a pretty straightforward path to snap store sustainability with the trajectory of customer wins we have so far. Big, serious companies who make big, serious IoT devices love the security story of snaps and the mechanisms that the snap store provides them to control updates. While those customers are not yet quite enough to cover all the costs of the snap store, as an entrepreneur I see a very healthy flow of wins, devices, growth, that makes me feel that will all be above water very easily.

It’s also important to say that we aggregate our work in PC’s, enterprise desktops, and IoT snaps. On that calculation, the whole set is economically sustainable. So Canonical is sustainable and loves the snap store, and the snap store is part of IoT and desktop which are sustainable, it’s just the snap store itself where we are currently putting a lot of work into next-gen capabilities.

To restate the opening line, this is a very valid question to be asking. What you have above is, I hope, a startling amount of transparency as to the underlying economic dynamics. I trust any thoughtful tech person would be able to understand those dynamics and feel good about betting on snaps.

Finally, to give my take on ‘why Ubuntu Core and not static images’, I would say this. Maintaining an OS properly is a LOT of work. Most companies that rolled their own OS images with Yocto three years ago, are way behind on patches today. Not because they are bad or because they are lazy, just because it’s a huge amount of work. The design of Ubuntu Core lets the device maker focus on the real image they control, which is the snaps they care about, and ride the wave of Ubuntu for everything else.

12 Likes