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 ?
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.
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)
Another sidenote: the Unity Desktop was taken over by the community
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.
Coming from embedded world I wonder what benefit really is behind snaps on the device? I see only downsides.
The main ones are:
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.
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.
My company took Foundries.io solution based on Docker. Foundries as far as I know are former Canonical people.
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:
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.
@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 
So, itās probably safe to consider Ubuntu safe, as long as Canonical has customers 
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.
Perfect start. Cheers.
Interesting you mention Red Hat re: CentOS and post-IBM acquisition and the decisions that have been made around that. Canonical may not always be the Canonical we know and love.
This is true but even documentation, as far as I kind find, about how one would even establish an open-source implementation of the store is non-existent. Thatās not to say the source code is unavailable for one side of that conversation, it of course is. But it is a complex code base one which Iām becoming very familiar with.
And you are right there is A LOT of value in what Canonical offers in terms of the store and particularly brand stores for device manufacturers. Most of which may not be necessary if I wanted to have a private store of my own, internal to my own network.
This is a big decision behind what led the company I work for to choose Ubuntu Core.
As someone who is actively reading and modifying snapd source code both as a job and a hobby (and who is no affiliated with Canonical in anyway) I can say that I am fairly impressed by the quality and level of testing that is going into the product.
I continue to think though that without an open-source implementation of a snap store or documentation about how all the parts fit together (at least for the desktop/generic model scenario) it will weaken the long-term ecosystem of Snaps. Thatās certainly an opinion and itās mine.
To that end why is there not an involvement (either existing or new) of a foundation that would contribute to that advancement. Why not have Snaps become the OCI of the desktop world?
What would Canonicalās and/or your approach and/or response be if someone wanted to do such a thing?
Opinions expressed here are my own and do not represent any entity but myself
Thanks a lot! All of that is highly appreciated, I love the answers, makes sense, and yes: that does give me confidence!
FWIW: while Iām not head of / in charge of the business side of the project/product that Omer mentioned, I am in charge of pretty much all software technology (not the hardware).
I have been promoting snaps from the very beginning, and it is now baked into our Yocto based image - Omer did contribute back, upstreamed a bunch of snapd changes, and we have a snapd Yocto layer, will continue to contribute etc etc - and Iāll continue promoting snaps and also snapstore (the Canonical) ā¦ will see ā¦ weāre just now getting to these āupper layerā things.
In any case, I am happy with the choice as I am convinced of the technical advantages of snaps=) This tech is moving things forward. Thanks Canonical!
Also: thanks Omer=)
Very happy to see snapd being useful on Yocto, itās a big part of the embedded Linux world. Thank you for driving that!
One of the things that the snapd team has invested in is multi-platform testing of every change to snapd. They run lots of VMs of different operating systems and versions of those. Admittedly, Yocto presents challenges given its meta-distribution nature, but I think we should tackle those challenges head on with any contributor who is depending on Yocto snapd.
For example, we might setup a suite of reference Yocto-snapd machines with versions/builds that cover common permutations and combinations.
