This web page doesn't do a good job of motivating the reader.

I understand what the Plasma Desktop Environment is. But what is "atomic and transactional Linux"? What are the advantages to the alternatives? What other projects are similar? What is the motivation for this project in particular? Most importantly, why should I want to use it?

>But what is "atomic and transactional Linux"?

It's a glorified Live CD, with added "persistence" for user data. Updates are done by replacing the system install (which is readonly during normal operation, just like a Live CD) and rebooting, with an A+B mechanism enabling seamless updates during operation, as well as rollback if the new install fails. It's the modern "cattle not pets" approach to system administration: every system is running a well-defined ("atomic") Live CD equivalent, not something bespoke that's the unpredictable result of partial updates and/or edits on the running system.

No, updates are done by creating a snapshot of the read only mounted root, and applying the packages via the usual package manager in there. The snapshot only becomes active at reboot, and if starting fails it'll revert automatically back to the last known working snapshot for the next boot.

Things like /etc are writeable, so you don't need to reboot for simple configuration changes.

You can run it just like always with all packages installed - it's just not recommended as the additional complexity on updates increases the risk that manual intervention is needed, and tooling is good enough that for a lot of stuff you don't really need it there. Like, toolbox or distrobox as podman based containers running in the host namespace (either as user or root), allowing persistent installation of debug tools, without having to reboot.

Really well explained - I use fedora kinoite, and have had hard time grasping how the immutability exactly works when compared to traditional setup.

I would add to this that homebrew is a nice tool for being able to install software that are not in flatpaks and if you do not want to add too many layers to the "os-tree".

The fact that home is shared between all the distro- and toolboxes is a bit annoying, because I would like to have stronger isolation from the host in some projects.

Also doing basic polyglot stuff is a bit messy, if you have toolboxes like "node" and "php". But if you have project based boxes, then you end up with billion copies of node.

But what a pleasure it is to just update the base image and have things work, or rollback if something fails. Hell, you can even rebase the base image to some other setup, and most likely have your system work.

> what is "atomic and transactional Linux"?

Linux distros that are updated with full system snapshots instead of package by package, similar to Android. The key difference is most of / is mounted read-only[0] and is only changed by distribution provided updates so you and the distro team always know exactly what's running.

> What are the advantages to the alternatives?

Greater control and stability since its essentially always running in a supported configuration. Easy roll-backs to a previous update if something goes wrong. You always know exactly what your system is running if you want to keep it in sync across machines (more useful in a server setting).

> What other projects are similar

Kalpa is a "sibling" project to AeonOS, which is atomic OpenSUSE but with Gnome (and other changes, which I'll get to). There's also the Fedora Atomic line of Fedora Kinoite and Silverblue (KDE and Gnome respectively), U-Blue, Bazzite, SteamOS, and more. I think most major distro lines have an Atomic variant at this point.

> What is the motivation for this project in particular?

For Kalpa specifically, it's to offer a KDE alternative to AeonOS. Originally there was just AeonOS, which was OpenSUSE MicroOS (an atomic version of OpenSUSE Tumbleweed) with GNOME installed. Aeon has diverged greatly from MicroOS though and I think it no longer uses it as an upstream. AeonOS also refused to support KDE[1], so Kalpa was created. Kalpa still uses MicroOS as its upstream and I'm not sure if there's any plans to change that.

> Most importantly, why should I want to use it?

I use it on my personal laptop because it lets me have all the benefits of a rolling distro (up to date packages) without the stability concerns. Updates apply automatically in the background and I know when I reboot I'll always have a working system available to me.

[0] /etc is mounted as an overlay FS so you can still make changes to it. /var, /usr/local, and /srv are also still user-writable. I think /mnt is too but I forget off hand.

[1] Aeon is generally anti-customization and does its best to only offer one way of doing things. This is to prevent configuration drift and reduce the maintenance burden per snapshot. GNOME also has a more regular release cadence, which makes it much easier to integrate than KDE (or so I've been told..)

Would the A/B filesystem approach à la Android be a good way to distribute Linux with ZFS-on-root without all the angst from DKMS modules versioning?

[Maybe unrelated, but just occurred to me (some horror stories have prevented me from trying ZFS-on-boot in linux after Ubuntu botched it with their Zsys “adventure”).]

If i understand the intention of a zfs root combined with an a/b approach — it feels like this btrfs root and immutable gives you the same benefits but with better mainline support.

Is there a relationship with concepts such as NixOS?

It's closer to the "sealed system volume" model that macOS uses. The core OS filesystem isn't (normally) writable, although you can finagle it to add drivers and such.

Yes, all projects in this sphere should communicate better.

An atomic distro is one in which the updates are swapped atomically at reboots. They also go by the name of immutable distros. Only the "system" partition is immutable.

Most popular I would say is SteamOS followed by the Fedora variants (Silverblue, Kinoite) and derivatives (Bazzite).

They are still limiting in daily use, rough around some edges.

Yeah. I use bazzite, but had to overlay like 5 apps. Flatpaks are often disappointing or just do not exist. AppImage is awesome, too bad it is used rarely.

It's buried in the About page, but it uses different terminology. They definitely have to review their copy.

> Automatic Updates: Updates never touch your running system, only taking effect on reboot.

> Resilient: Due to the atomic nature of updates, if something goes wrong, the system will automatically roll back to the last known good working state

Wait I thought being able to update without rebooting was a good thing? It was a relatively common argument against windows

It's never been a great argument. Even non-atomic Linux distros have you reboot after updates. It's just the safest way to ensure that everything is running with the updated packages. You're kind of in an untested state if you have mixed versions of applications and their dependencies running.

Plus, updates aren't the only thing that require reboots. Various config changes will need a reboot or at least require you to log out and back in. Even just adding your user to a group needs you to end your session for the change to apply.

User group can be updated within a terminal when needed.

That depend on your needs.. linux can do live update if you need that, usefull on servers..

But atomic versions as more target to desktops or containers where you need to have know working setup and when you upgrade you replace it by newer one..

So you dont update per se... You install the new version in a separated partition and boot into it the next time you restart.. Same with containers, you just destroy it and recreate with the new version..

If the new version fail you boot back to the old original version that is know to be working and have not being replaced..

The ideia is to ensure a known to be working system is always available..

Wait until Linux can run itself from the top while keeping your work intact.

See https://lwn.net/Articles/1033364/

I daily drive kalpa and also installed it on my family computer. I landed on kalpa after a long time researching, so, let me dump an overview of this new distro tech.

# Terminology

1. Immutable: The core OS (/usr directory) is kept in "pristine" condition by disallowing modifications.

  - Discourage installing packages or removing packages.
 
  - well-tested (as most users are running the same OS with same package version)

  - System upgrades are an entirely new immutable copy
2. Atomic/Transactional: Similar to atomicity in databases, where a bunch of operations are bundled into a transaction (atomic =indivisible unit), and it either succeeds completely or it fails completely. Just like that, a system upgrade succeeds or it doesn't. There's no partial package updates.

NOTE: kalpa in particular, uses suse-microos tech called Transactional-Update https://documentation.suse.com/sles/15-SP7/html/SLES-all/cha...

# Atomic styles

4 mainstream models of immutable distros:

1. declarative-config: ALL your system configuration in a config file eg: package versions, network config, user accounts and so on. eg: NixOS, BlendOS

2. OSTree-based: You use cloud/container (OCI) technology (eg: docker files) to layer upon existing layers (eg: pre-baked system images). eg: fedora's atomic spins, vanillaOS, endlessOS. So, fedora coreOS is the base layer -> atomic spins like silverblue/kinoite layer desktop packages like gnome/kde etc.. -> the infamous gaming distro "bazzite" layers gaming packages like wine/steam/drivers etc. and so on.

3. Btrfs-snapshot-based: You take a btrfs snapshot of your root partition before upgrading, so that you can boot into it if the upgrade fails. eg: suse-microos family (kalpa belongs here), chimeraOS

4. systemd-mkosi based: You essentially "curate" an entire OS filesystem in a directory using mkosi and deploy it as an immutable disk image. eg: kdelinux

NOTE: systemd-mkosi is the vision of systemd maintainers as mentioned here: https://0pointer.net/blog/fitting-everything-together.html . There's a whole bunch of system features in development to achieve this ideal.

Most of these distros (except btrfs-based) simply use the A/B root system. They just maintain two root partitions/images, put any upgrade into the "other" partition, mark that as live and the current partition as backup. If the boot into the new partition fails, they just boot into the backup partition and just wait for next upgrade.

As they don't allow usage of system package manager, you are supposed do package management at user level. For gui apps, you resort to flatpak. For other utilities, you usually pick homebrew or language-specific tools like cargo, pip/npm etc..

# The magical tool called Distrobox

This runs containers in userspace and tries to integrate them into your system as much as possible.

A lot of software development requires system level services or shell access or install dependencies etc.. You obviously can't do that on host, as system package management is essentially forbidden and half the point of immutable distros is to keep the host "clean".

So, you create a container and do all your development in there. If it gets too dirty, you just delete it and create a new one.

Personally, I use an arch container for development, as it has all the bleeding edge packages and the convenient AUR too. vscode (from flatpak) supports connecting to containers using official remote extension. I also run a media server inside it. You can also install any system packages or cmdline utilities you want inside it (eg: codecs, ollama, etc..).

# Why kalpa over others?

- Great KDE polish that suse is known for

- btrfs tech is mature and was already used in suse for years, the atomic system is very simple to understand and you can just pick the snapshot you want at boot menu.

- Despite being immutable, customizing the system (eg: installing a driver, kernel modules, firewalls etc. ) is easy too.

  - just enter a transactional update shell

  - this creates a new mutable snapshot of the current system and chroots into it

  - run all the commands you want inside the shell. eg: install/remove packages, enable services etc.

  - exit shell. This will mark the transaction as success/complete and set the snapshot as live for next boot.
- Minimal by default.

- Updates are fast/tiny, as they are just routine rolling release updates from tumbleweed repos.

There are some problems too:

- single maintainer

- less popular, compared to alternatives like fedora-based atomic spins.

- It's based on tumbleweed, so, you get lots of tiny updates (almost daily). Fedora based, for example, have weekly/bi-weekly updates.

- still in alpha stage (but once you set it up, it's rock solid).

- Immutability is still a new concept, and flatpaks are rough around the edges. Expect bugs. Mutable/traditional distros are still easier to use, as that has been "the way" forever.

Is there a linux distribution that comes with mac keybindings and make it easy for someone with muscle memory to use both?

There's https://kinto.sh/ you can install on any distro. For visual similarity, GNOME is already quite Mac-ish, but there are distros like elementaryOS that go further by e.g. moving window controls to the left side.

[deleted]