Hacker News Reader

Comment by futune | Hacker News Reader

For me, boot environments are the killer feature. I think it's the only mainstream OS to really support the concept. Void linux (which is great) and (probably?) the Illumos distributions are the other open source choices, but those are much more niche. Or you could bolt it on to another linux distro using ZBM, but then you're on your own.

Every update I clone the current boot environment, execute it as a jail, run upgrades in there, and then once upgrades finish I set it to "boot just once", all using the built in bectl. At no point during an upgrade is the running OS in an inconsistent state. Powerloss during upgrade? no problem, since it wasn't activated yet your server comes up with the previous version. And you can either junk the partial upgraded env and start over, or jail it again and continue.

I only wish laptop support was a bit better. But since my laptop is more of a pet, at least it can have Void.

View on HN

That's a really compelling workflow. On the Linux side I've heard of openSUSE's MicroOS doing something conceptually similar with BTRFS snapshots and atomic transactional updates, though I haven't actually run it. Different mechanism but it sounds like the same instinct. Never let the running system get into an inconsistent state during an upgrade. The "boot just once" plus jail-the-clone-to-upgrade combo you described sounds genuinely clever, hadn't realised the bectl integration was that smooth. Void Linux is just a name to me at this point, might be time to actually look it up.

> On the Linux side I've heard of openSUSE's MicroOS doing something conceptually similar with BTRFS snapshots and atomic transactional updates, though I haven't actually run it. Different mechanism but it sounds like the same instinct.

I have run the Kalpa Desktop, which is basically MicroOS + KDE, and yes that's almost exactly the same setup; updates/changes are done using transactional-update, which AIUI performs the change in a new root snapshot/filesystem and then you reboot to make it take effect. Honestly a very nice system, although I eventually abandoned it because I was ultimately unwilling to run on BTRFS (which I absolutely do not trust).

> For me, boot environments are the killer feature. I think it's the only mainstream OS to really support the concept. Void linux (which is great) and (probably?) the Illumos distributions are the other open source choices, but those are much more niche. Or you could bolt it on to another linux distro using ZBM, but then you're on your own.

I think (Open)SUSE does something similar using BTRFS snapshots. But yes, ZFS-backed BEs are the best IMHO:) OpenIndiana still does them, of course, but yeah that's sadly niche.

A Brief Word About Btrfs A fair-minded reader will point out that Linux has its own copy-on-write filesystem: Btrfs. And openSUSE's integration of Btrfs with Snapper deserves genuine credit. Snapper, developed by Arvin Schnell at SUSE and first shipped with openSUSE 12.1 in November 2011, creates automatic snapshots in pre/post pairs around every zypper transaction. GRUB is patched to offer a submenu for booting from snap‐ shots. The rollback workflow is coherent: reboot, select the snapshot, verify, run snapper rollback , reboot again. On openSUSE, this works out of the box. The caveats are worth mentioning. Btrfs's RAID5 and RAID6 implementations still carry an official data loss warning in the documentation, a caveat that has per‐ sisted for years. ZFS's equivalent (RAIDZ, RAIDZ2, RAIDZ3) has been production- ready since 2005. Btrfs has no equivalent to zfs send and zfs receive for efficient incremental replication between hosts. And while Btrfs reached general production readiness around 2015, ZFS had a decade's head start. None of this makes Btrfs a bad filesystem. It makes it a younger one. And the openSUSE team deserves genuine credit for building what they have built. But even in the best case, the Btrfs workflow on openSUSE is a distribution-level achievement. It is SUSE's integration work on top of a filesystem, a bootloader, and a snapshot manager that are all developed separately. The GRUB integration is openSUSE-specific; other distributions using Snapper do not get the boot-from- snapshot feature without additional patching. The whole edifice is one team's excel‐ lent work within the assembled model. On FreeBSD, it is one team, one repository, one design, one release.

ublue and alike accomplish similar on Linux, it looks a bit wonky on the first glance, but is pretty good day to day

openSUSE with snapper does this automatically. It's far more mainstream than FreeBSD.

Reply on news.ycombinator.com