I’ve read through the whole article, and all-in-all I think such an OS might work for “consumer devices” and even for single-purpose servers. However I doubt it will work nicely with Linux power-users. I don’t think the article describes anything too revolutionary that we haven’t seen in live-CD’s or in appliances like VyOS for example; it just tries to put the existing pieces together in a single solution.
However, I do see some major problems with this proposal:
for once, it shoves even more systemd lock-in – I like systemd for service and process management, however I think it has started (many years ago) to overstep its purpose… (also it seems a lot of the systemd tooling is already meant to support all this, but I don’t want to say “conspiracy” just yet…) :)
it goes crazy with GPT partitions – https://0pointer.net/blog/images/partitions.svg – the simplest system has 10 GPT partitions; want a “system extension”? here are 3 more GPT partitions! I don’t have much love for file-system-images, LVM, or BTRFS/ZFS sub-volumes, however going the GPT partitions way is perhaps not a solution;
But, setting systemd mania aside, I think something good can come out of this:
Linux distributions might become to resemble closer the BSD distributions – one coherent release with some interim patches; (to this day, I feel a great dread when I update and Linux distribution, let alone upgrading it to the next minor version;)
we might get closer to repeatable builds – no more crazy bash scripts part of the RPM / DEB install that perhaps work, perhaps not… (why do package install scripts still insist on source /etc/profile or source /etc/bash.bashrc?)
I’m not sure why he even defined that partition layout as gpt. I can’t see anything on the article that actually requires it. Lvm or just going btrfs for everything should work just as well. Even better, btrfs could handle the old/new systems as snapshots, saving lots of space. (And allowing more than one “previous” version) The only be problem I see is that there would have to be a good way to actually force-erase the data on factory reset.
Re. power users, there’s already Fedora Silverlight which behaves pretty close (with a bit different implementation) and there are power users who like it quite a bit. Not sure if will appeal to everyone, but it’s not universally hated at least.
And yeah… As much as I like a lot of things that come out of systemd, I wish he sometimes stopped at “this is a cool interface I came up with, can we get an existing package to implement it?”
I’m not sure why he even defined that partition layout as gpt. I can’t see anything on the article that actually requires it.
There is a practical aspect of using GPT as opposed to LVM or similar, namely it is standard and simple to use / implement.
You can find in that article various mentions to booting the OS either on bare-metal (which at the moment means either MBR, or actually GPT because UEFI doesn’t support LVM), VM (which is similar to bare-metal in this requirement), and containers (via systemd-nspawn) where GPT seems to be the simplest approach.
Even better, btrfs could handle the old/new systems as snapshots, saving lots of space.
Given that the OS image is read-only, the best candidate seems to be SquashFS or EROFS, which both (?) support compression, something that none (?) of the other mainstream file-systems support.
As with BTRFS, I’ve got bitten once by ReiserFS, I’ve seen others bitten by XFS, thus I’m 100% in the “no magic in the file-systems” camp (i.e. Ext4 for the moment)…
I’m not sure that matters. With uefi you need the EFI partition anyway, then the kernel takes over and knows what to do with lvm/btrfs. (Why would uefi care?) He already wants btrfs for homes, so we’re not avoiding it.
the best candidate seems to be SquashFS or EROFS, which both (?) support compression
Btrfs supports compression. But I mentioned snapshots for the a/b systems, because there’s going to be lots of overlap - if we use images for updates, that means 99% won’t change during the update and it can be deduplicated, giving you ~50% compression before you even start compressing.
Although it’s good to see an attempt at security against “evil maid” attacks (via the TPM2) for Linux, the proposed approach seems rather unprincipled:
the “payload” for the OS - the given example is an e-mail client - does not appear to be integrity-protected (or did I misunderstand that part?). My e-mail client holds some of my most important data (including the ability to reset passwords for many online services)!
the root filesystem seems to be designed to be integrity-protected by a TPM2-bound (i.e. hardware-bound) key, but rollbacks are not prevented (so a user could be un-locked, or a service could be un-disabled)
the root filesystem is actually encrypted, and “integrity-protected” by btrfs checksums (inside the encrypted container); that’s… not a standard cryptographic construction.
(Also, this is very much not a traditional Unix system, and I like traditional Unix systems.)
I’ve read through the whole article, and all-in-all I think such an OS might work for “consumer devices” and even for single-purpose servers. However I doubt it will work nicely with Linux power-users. I don’t think the article describes anything too revolutionary that we haven’t seen in live-CD’s or in appliances like VyOS for example; it just tries to put the existing pieces together in a single solution.
However, I do see some major problems with this proposal:
systemdlock-in – I likesystemdfor service and process management, however I think it has started (many years ago) to overstep its purpose… (also it seems a lot of thesystemdtooling is already meant to support all this, but I don’t want to say “conspiracy” just yet…) :)But, setting
systemdmania aside, I think something good can come out of this:bashscripts part of the RPM / DEB install that perhaps work, perhaps not… (why do package install scripts still insist onsource /etc/profileorsource /etc/bash.bashrc?)I’m not sure why he even defined that partition layout as gpt. I can’t see anything on the article that actually requires it. Lvm or just going btrfs for everything should work just as well. Even better, btrfs could handle the old/new systems as snapshots, saving lots of space. (And allowing more than one “previous” version) The only be problem I see is that there would have to be a good way to actually force-erase the data on factory reset.
Re. power users, there’s already Fedora Silverlight which behaves pretty close (with a bit different implementation) and there are power users who like it quite a bit. Not sure if will appeal to everyone, but it’s not universally hated at least.
And yeah… As much as I like a lot of things that come out of systemd, I wish he sometimes stopped at “this is a cool interface I came up with, can we get an existing package to implement it?”
There is a practical aspect of using GPT as opposed to LVM or similar, namely it is standard and simple to use / implement.
You can find in that article various mentions to booting the OS either on bare-metal (which at the moment means either MBR, or actually GPT because UEFI doesn’t support LVM), VM (which is similar to bare-metal in this requirement), and containers (via
systemd-nspawn) where GPT seems to be the simplest approach.Given that the OS image is read-only, the best candidate seems to be SquashFS or EROFS, which both (?) support compression, something that none (?) of the other mainstream file-systems support.
As with BTRFS, I’ve got bitten once by ReiserFS, I’ve seen others bitten by XFS, thus I’m 100% in the “no magic in the file-systems” camp (i.e. Ext4 for the moment)…
I’m not sure that matters. With uefi you need the EFI partition anyway, then the kernel takes over and knows what to do with lvm/btrfs. (Why would uefi care?) He already wants btrfs for homes, so we’re not avoiding it.
Same for VMs. Nspawn itself / machined was written with btrfs in mind so much that some functionality was only later added to support other file systems https://github.com/systemd/systemd/commit/9a50e3caab82f8406ecfac6048ac8e2ce98b0ab8
Btrfs supports compression. But I mentioned snapshots for the a/b systems, because there’s going to be lots of overlap - if we use images for updates, that means 99% won’t change during the update and it can be deduplicated, giving you ~50% compression before you even start compressing.
Also coincidentally, it seems there are already two other projects of Lennart that cater to the ideas described in the article:
mkosi– A Tool for Generating OS Images – mentioned in the article, that builds such images;casync– A tool for distributing file system images – that seems to try to replicate what OS-tree / restic are doing, but for OS image deployments;My thought while reading this was “sounds a lot like how illumos distrutions are used in data centers”
Seems like a good idea!
Although it’s good to see an attempt at security against “evil maid” attacks (via the TPM2) for Linux, the proposed approach seems rather unprincipled:
(Also, this is very much not a traditional Unix system, and I like traditional Unix systems.)