Ubuntu releases Core 22: Its IoT and edge distro Canonical's Linux distro for edge devices and the Internet of Things, Ubuntu Core 22, is out. This is the fourth release of Ubuntu Core, and as you might guess from the version number, it's based on the current Long Term Support release of Ubuntu, version 22.04. Ubuntu Core is quite a different product from normal Ubuntu, …
I think the points are:
* to make everything easy, because even the people building embedded systems are not gurus;
* to make the OS robust, resilient, and safe;
* to make it amenable to automation;
* to minimize the amount of extra work that the integrator needs to do.
In the classic xNix model, apps sort of merge into the OS. Some bits go in /usr/bin and some bits in /usr/lib and some elsewhere and they become another command. This is even worse than the Windows model, where most of the app is in /Program Files/%AppsOwnFolder% but some bits are under /WINDOWS somewhere.
The idea of making apps self-contained so they don't touch the core OS has been demonstrated now. NeXT did it first, Mac OS X polished it and took it mainstream, iOS and Android put it in billions of people's pockets.
It doesn't matter if it's inelegant or inefficient. It works.
The basic model of an immutable OS and self-contained additional apps is demonstrated now. Counting all the replaced phones, there are tens of billions sold, and not a single big failure yet.
Ubuntu is trying to bring that to all those billions of little self-contained boxes driving your TV and fridge and microwave.
Someone has to build 'em.
And this is not an area where Red Hat or SUSE are strong.
-> In the classic xNix model, apps sort of merge into the OS. Some bits go in /usr/bin and some bits in /usr/lib and some elsewhere...
I feel a solemn duty to point you towards the hier man page on FreeBSD. In the Solaris world, at places where I worked, non-OS binaries were installed under /opt (occasionally I saw /usr/local). While it is possible to ignore the recommended layout, most packages and ports install under /usr/local rather than all over /etc /bin /lib /usr/lib and so on. This latter way of doing things, what I call to dumping on the OS, is something that first surprised me about Linux then surprised me even more. In the end it irritated me, this mixing up of core OS binaries and non-core.
How many Linux packages are available? Tens of thousands. Quite a few of them will be different spins on the same thing, e.g. Postfix with/without SASL/LMBD/BDB/MySQL/LDAP/etc. If we just go for a basic package and not try to install every version with slightly different options toggled on, it's still probably tens of thousands of packages. If I was to do something really stupid and install everything, How many files will be in /bin and /usr/bin after this? I imagine I would need the hundreds of gigs for the root partition as you recently suggested when using btrfs.
If you take a lot of source tarballs at random, and do what beginner developers do and run ./configure && make && make install, very often those installations will occur under /usr/local. So where does this using / as the root rather than /usr/local come from?
-> Mac OS X polished it and took it mainstream
Mac does have some foibles. It is true that the core OS does not usually get touched (unless perhaps there is a kernel module in a software package). But completely uninstalling a piece of software from a Mac requires excavating in ~/Library and sometimes /Library. I recently removed Google Drive from a Mac, that had chunks of code all over the place.
-> It doesn't matter if it's inelegant or inefficient. It works.
I would argue that it is simple and efficient for the end user. Some people tend to forget that computers are tools to make our lives easier, not for us to serve them building everything from source.
I enjoy building code from source, but sometimes I have to ask myself why I am doing this if either of two conditions are not being met: 1. Am I reviewing this code for security purposes? 2. Am I modifying the code to suit me? I would say that the number of times I have really reviewed a large chunk of source code for security purposes is zero. I may have looked at it, but that is not the same thing. I have certainly modified code to suit me.
Snaps are not just apps installed under their own directory such as /opt/myapp/v1.2.3/ (which I have no problem with).
Snaps are semi-containers. They run in their own namespaces which restrict them from accessing other applications.
This might be fine for straightforward user applications like a web browser, but in more complex scenarios it breaks down in unexpected ways.
Case in point: lxd is now only supplied as a snap. lxd can use zfs for its storage. However, because the snap is constrained to mounting and unmounting within its own namespace, then when zfs breaks, it becomes extremely difficult to fix (the snap thinks that the zfs dataset is mounted when it isn't, or vice versa). Poking around with nsenter may or may not help; a reboot may be required.
In the end, snap treats all packaged software as an adversary which needs to be sandboxed. Does this make sense for end-user apps? Maybe. For system tools? Not so much.
Most Linux users have probably never built a package from source in their entire life, and many wouldn't know how. Most use pre-built packages from their distro's repositories.
There are source based distros, but the user base is small. If you like building packages as a hobby that's fine, but not many people do.
Snaps are well suited for the market that Ubuntu Core is addressing, which is dedicated "appliances" which do one thing and need regular completely automated atomic updates with no user interaction.
"You can only install additional software in the form of Snap packages, but this is simple, and you don't even need root privileges to do it – as an experiment, we installed htop and bashtop in seconds."
Does it at least require sudo? If not, then _anybody_ with SSH access can install additional software. To my mind that violates least privilege. I tried to look it up on ubuntu.com, but the "IoT app store" link is the same broken link as the "Full disk encryption" link. s/featrues/features/
From ubuntu.com/core : "Imagine a world where every device is trustworthy."
What we get instead is a world where every device is trusted.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
