openSUSE News

> Debian was the last major system to discard sysvinit

This is partially incorrect and partially misleading.

Incorrect in that openSUSE and Arch are major distros and migrated from sysvinit to systemd.

https://news.opensuse.org/2011/12/22/systemd-e2-80-93-boot-faster-and-cleaner-with-opensuse-12-1/

https://www.reddit.com/r/archlinux/comments/4lzxs3/why_did_archlinux_embrace_systemd/d3rhxlc/

Misleading in that Ubuntu and Fedora did use Upstart but not in its native mode, they used it in its sysvinit compatibility mode. This is almost identical to sysvinit, so from the point of view of a user or a package maintainer it was functionally barely distinguishable from sysvinit.

OpenRC was considered by Debian, but 7 out of 8 members of the technical committee preferred both systemd and Upstart to OpenRC (Ian Jackson preferred sysvinit over OpenRC and "further discussion" over every other option).

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708;msg=6729

Big disclaimer, I work for SUSE on the team for this product (though I actually work on upstream projects more than the product itself).

SUSE's "Container as a Service Platform"[1] has a one-page install for each node with an admin panel that does auto-provisioning. It also has transactional updates and a few other nice features similar to CoreOS's "Container Linux". In addition, we're working on openSUSE Kubic[2] which will be the community-developed base for CaaSP in the future.

I believe most if not all of the code is available on GitHub[3] under a free software license (because that's how we do things). Not to mention that you could very easily fork openSUSE Kubic, once it's ready.

[1]: https://www.suse.com/communities/blog/introducing-suse-containers-service-platform/
[2]: https://news.opensuse.org/2017/05/29/introducing-kubic-project-a-new-open-source-project/
[3]: https://github.com/kubic-project

Some time ago they did add systemd-boot as a supported option and apparently it also generates one entry per snapshot.

https://news.opensuse.org/2024/03/05/systemd-boot-integration-in-os/

https://en.opensuse.org/Systemd-boot#Installation_with_full_BTRFS_snapshot_and_secure_boot_support

https://github.com/openSUSE/sdbootutil

I haven't tried it though so I don't know for sure. (I have my own custom systemd-boot setup that predates theirs, and since my setup uses signed UKIs and theirs doesn't, I don't care to switch to theirs. I can still switch snapshots manually with `btrfs subvol` anyway; it just might require a live CD in case the default snapshot doesn't boot.)

I believe that's the same in FreeBSD as well. I also think it's a solved problem in the Linux world - OpenSuse Tumbleweed sometimes rebuilds every package because they've changed libc. Apart from watching 2000+ packages get updated, there's really no impact when this happens.

To solve this, the updater could create a new boot environment[0], install everything in that boot environment using as many passes as required, then reboot into that environment. OpenSuse already does a similar thing[1], though I don't know how well it works.

[0] https://www.freebsd.org/cgi/man.cgi?beadm

[1] https://news.opensuse.org/2018/05/15/transactional-updates-in-opensuse-leap-15/

The read-only system volume really seems like a neat idea. It reminds me of the Transactional Server role in openSUSE where they make system upgrades as atomic as possible: https://news.opensuse.org/2018/05/15/transactional-updates-in-opensuse-leap-15/

That said, I don't understand the use case for firm links. Seems like the problem it's trying to solve can just be solved with simple mount points: mounting read-write /Users and /usr/local. Am I missing something?