Real-time and Core editions of Ubuntu arrive Canonical has followed up the latest LTS release of Ubuntu with real-time and IoT editions, while ushering the last interim release into retirement. The latest long-term support release of Ubuntu, 24.04 "Noble Numbat," appeared in late April along with a raft of other distro releases. Nearly a month later, Canonical opened the …
[Author here]
Indeed it is. It's what lots of Internet-enabled kit does.
Core is about doing that with Ubuntu, on devices with no user-facing settings, where you can just pull the plug without shutting down and it will work fine next time.
There are other tools aimed at this sort of embedded use, such as Yocto or Tizen, but this is trying to do it with more mainstream OSes. A few years ago, a £20 gadget might only have a few hundred megs of RAM and a gig of disk, and then Linux became viable but it had to be specially hand-made to fit. Now, a £20 gadget could have 8GB RAM and 32GB of flash, and a normal desktop type distro can usefully run on it.
I don't need it myself, but if someone came to me and asked me to build a bespoke distro to run on something considerably lower-end than a Raspberry Pi 1, and make it fully remotely manageble and self-provisioning, I'd struggle. I would barely know where to begin and it would be a tonne of work. Now, thanks to things like Core, it's getting more doable.
And on the whole that's good, not just for system builders, but for users too -- because if the manufacturer goes TITSUP a few years later, you have a fighting chance of replacing or updating the OS yourself and keeping your gadget working.
you get things like SNAP using up CPU cycles and memory when there is IMHO no need for it at all.
Sorry Canonical, you have jumped on the 'systemd' lunacy bandwagon with 'snap'.
I've rebuilt all my servers without any of your lunacy. They now all run either Rocky Linux or Alma Linux.
> using up CPU cycles and memory
How exactly?
You know how it works, right?
Snaps are just compressed filesystems, made with the same `squashfs` tool as every distro's initrd or rootfs. It mounts them -- once, during boot, parallelised -- and then they just sit there. They're not in memory and use no CPU. Mountpoints use a tiny tiny fraction of your memory, 0.01 of a rounding error.
Unlike flatpaks, they are compressed, so they take less disk space than flatpaks.
To run they are decompressed into the cache. That takes a tiny bit of CPU but only during launch. With gigahertz-class multicore CPUs, compression and decompression almost come for free, and some distros (Fedora, Asmi) enable it by default because there's no visible impact. The days of Stacker are over 25 years ago.
So what is the overhead you are claiming?
They take more disk space than native packages, yes. But less than flatpak and their compression works on any and every filesystem, unlike flatpak. And unlike native packages, you can undo, cleanly and 100% safely, or revert to a previous version, or lots of previous versions if you want to keep them. .DEB can't do those things. If an install goes wrong, you're screwed and your system is probably irreparable.
Cheers Liam, that’s actually useful to know. If your system has hundreds of these they’re going to be an issue in terms of space, but if you’re rolling an embedded system with only one or two, it sounds like they make a lot of sense. Filed away for the next time I design an appliance.
You know what, that surprised me so I checked and you're right.
Almost all phone OSes are immutable, so that's nothing unusual. But both Ubuntu Touch and Snap itself grew out of the Ubuntu Phone project, so I am surprised one does not include the other. They are working on it, though.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
