Ubuntu Core vs Yocto (and ResinOS)?


#1

Hi there,

I’m trying to choose a platform for an IoT Hub. We have thousands of IoT hubs currently running Ubuntu Server on Gigabyte Brix and Raspberry Pi. We occasionally get root filesystem corruption and need to send out a new hard drive or SD card which is a serious problem that needs to be addressed.

I’m looking at Ubuntu Core and Yocto (and ResinOS also looks great). What would you say are the advantages/differences of Ubuntu Core over Yocto (and ResinOS)?

I’m currently leaning towards Yocto as we maintain the units through OpenVPN, Ansible and Docker and it seems like Ubuntu Core would add an entirely independent cloud service to manage devices, which we don’t need. Or is this service optional?

From what I understand the key differences are:

  • ubuntu-core is more of a higher level package, trying to tie you into the cloud services and container type but easier to get started if you don’t need to build your own solution. It can be harder to customise if you need to build a custom one that will only connect to your own OpenVPN and device management, bypassing the Ubuntu cloud services.
  • Yocto is more low level, providing the tools that allow you to build exactly the image file you need. It is supported by a number of companies offering Yocto based distributions so you can still get off the ground relatively quickly.
  • ResinOS is an example of one of those Yocto based distributions, it is with a few modifications/additions, with their own optional cloud services.

Is that a fair comparison? - What are your thoughts?


#2

UbuntuCore has builtin update/rollback functionality (it will even automatically roll back to the former version if a kernel or rootfs update failed)

In UbuntuCore apps are delivered as snap packages to the system which also offers you the same upgrade/rollback features along with secure app separation (apps can only see parts of the system (or content of other snaps) through interfaces you control)

UbuntuCore gets 5 years of security support for all bits delivered in the rootfs (and if you use an official kernel snap also for the kernel), like the normal Ubuntu LTS releases.

AFAIK yocto does not have any of this (while there are upgrade solutions you can implement, there is no “standard” way of doing upgrades, nor is there any standard way for roll back etc, you’d have to pick your poison and hope for the best here), you have to bake your applications into the rootfs at build time and can not atomically update single bits of it. Apps will not be confined or separated from each other at runtime and a bug or mis-configuration in your app can allow an attacker to take over the system (this is not possible with Ubuntu Core due to the app/service confinement)

There are probably a million more differences that didnt come to my mind while typing this :slight_smile:

Note though, that getting an unbiased opinion on the snap/UbuntuCore forum for such a question is indeed rather unlikely :wink:


#3

That sounds really great, thank you for that.

I’m wondering about the dependence on a Ubuntu SSO account, etc. If I am building 2,000 systems using Ubuntu Core, are there any limits I should be aware of? - are there any license costs involved?

Also, is there any way to use Ubuntu Core without a reliance on an SSO account? - maybe some build tool where I can add a custom OpenVPN setup and my own SSH keys during the image build process?


#4

@hackeron did you end up getting any answers to your questions? i am in a similar situation as you


#5

it really depends what you do with the image, you do not need an account at all to run the image.

if you get along with using the existing gadget snap and existing kernel snap from the store for your device, you can add any additional snap to it you want … if in turn you create a snap that offers a REST api to i.e. set network cofiguration etc you can get along with whats there without any cost …

if you need your own gadget snap, kernel snap or want to make use of the snapd interface (to install snaps at runtime or manage config options of snaps on the fly etc) you will need to buy a brand store.

the SSO accounts on-device are only needed for interactive logins, which you most likely dont need for i.e. an appliance image.

if you build your own images you need exactly one SSO account for signing the model assertion (image description, and list of pre-installed snaps) but nothing else.


#6

Thank you for the info Ogra

One clarification, you said

if you need your own gadget snap, kernel snap or want to make use of the snapd interface (to install snaps at runtime or manage config options of snaps on the fly etc) you will need to buy a brand store.

Isn’t it a possibility to create a custom gadget or kernel snap and deploy it to the public store and that way you don’t need a brand store? or as soon as you need a custom image you need the brand store?


#7

the review tools would block any kernel or gadget uploads to the public store as long as they do not come from a canonical employee (this is a security/store policy atm).

there is work being done to losen this policy a bit for non-
commercial images for developer boards (i.e. beaglebone, raspberrypi, rockpi etc), but this is not final (it could be that there will actually be a public brand store for such gadgets/kernels and a community team similar to snapcrafters can do uploads there, but it could also be a completely different solution)


#8

Understood

As a summary for others:
For commercial products you have to either use an official ubuntu-core image or pay for a brand store for a custom image and (if i’m not mistaken) for a Canonical trademark license. Something to keep in mind for anyone else like me considering Ubuntu Core vs Yocto in a commercial setting

That was exactly what i was trying to find out

Thank you Ogra


#9

well, technically you can build the whole image from local snaps (except core/core18) but lose any upgradeability for kernel or gadget … (and the device wont securely register a serial to be signed)

else we wouldnt be able to do any development (or at least development would be dog slow :slight_smile: )


#10

makes total sense. i’m not complaining, just documenting it :slight_smile:


#11

Why would you lose the ability to upgrade the kernel and gadget? The image I use is built using local snaps and the kernel has been updated multiple times.


#12

you can indeed manually snap install --dangerous ... if your kernel was originally installed from a local snap … what i meant is automatic updates, security fixes from the store etc.