The one major issue I had from the start was non-free Bluetooth codecs like AptX. That required me to taint the base image and add a non-official repo. It was messy but that was mostly down to it being a learning process, if I had to do it again I could probably do it with a single run of `transactional-update shell`.
The installer is super minimal and surprisingly user-friendly. One thing I remember is that there was zero partitioning choice: just use the full disk for encrypted btrfs and you get no swap (but zram swap is on by default). If you use OpenSUSE with secure boot enabled (as intended) then hibernate is prevented by `kernel_lockdown` anyway.
Snapper by default is nice, but you also get that with Tumbleweed. I ran into no applications that I couldn't get from Flatpaks or export from a distrobox, the latter being mostly for obscure stuff I need to compile myself. And my main toolbox hosts my Emacs environment that I spend most of my time in besides Firefox.
It's hard to recommend a MicroOS desktop over Tumbleweed, the latter being a great all-purpose distro as it is. But I'm hoping the benefits of forcing this "rootless" paradigm on myself will appear when it's time to move to a new machine. Just copy over my home directory and distroboxes and I'm golden, I could even switch to ARM without hesitation.
The distroboxes help with migrating because if I want to compile a newer version of that obscure program from earlier, I don't have to hunt down all the arcane requirements again. They're all still there waiting for me, in a Fedora/Ubuntu/Arch/whatever distrobox, depending on what works best for that program. At least that's the theory.
Happy to answer questions.
I think Hibernate is strictly better than Sleep: Why should a computer still use power when it isn't doing anything? And if you could get a desktop to recover its state before a full reboot without using Hibernate, then why would you need Sleep anyway?
The main benefit of sleeping to RAM is of course the resume speed, which makes it more suitable for when you just left your computer inactive for 15 minutes. That goes double if you use encryption without TPM unlocking.
For leaving your computer overnight, hibernate wins on all fronts. I'm enthusiastic about sleep-then-hibernate schemes, but haven't gotten them to work on my devices yet.
I've found doing work in containers made things straightforward enough, as a developer. Though I still somewhat think that that's just moving the problem - I'm not quite keeping those containers up-to-date. `distrobox assemble` helps a bit though.
Flatpaks are sandboxed with bubblewrap[1]. I would still call that bare-metal. And flatpaks aren't particularly bloated either, there's no need for a flatpak to be any bigger than a regular binary if it only depends on the kde/gnome/freedesktop runtime.
I used to prefer installing apps via my distro directly, but I now prefer using flatpaks because of the way it sandboxes the applications. When I delete a flatpak I know for sure any configuration or cache files for that app are also gone (unless you opt to keep them).
If you want to play with atomic distro's, there's a bunch of different approaches out there. For instance GnomeOS is not package based at all. OpenSUSE works via btrfs snapshots, Fedora Atomic uses rpm-ostree currently.
If you manage enough diverse servers, then patching will break something critical fairly frequently. Back when I was a sysadmin, Windows updates would break some server every 2 months, and Redhat every 6 months.
Being able to just reboot the server back into a working state, and then fix it at a later time would have been nice.
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?
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.
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.
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..)
[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”).]
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.
> 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
# 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
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.
- 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.
No, not "most".
ChromeOS does it (and does not use Btrfs).
Valve SteamOS 3 does it, and it needed to specifically patch Btrfs to do so.
That is all I can think of.
A couple of annoyances exist. For example IDEs want to use the system's shell, so you have to make a custom entry to use your distrobox. Tools like python, node, tofu, etc are installed in a distrobox and then exported with `distrobox-export -b $(which $BINARY)` so that you can call them from the IDE.
For me, it's worth those few rough edges. When I install an OS for non-technical people who just need a web browser, I install Kalpa. It looks close enough to Windows to be easy to use, and it's never broken in a way I can't explain over the phone or a text how to fix.
It even passed the wife test in our house. It took a few years of marriage to convince her that her laptop shouldn't take 30 minutes to boot and open Chrome. She let me switch her over to Kalpa (it may have still been called MicroOS Desktop then) a few years back. That old laptop is still kicking and fast enough for her needs. Had she stuck with Windows, it'd be a brick now because of the requirements for upgrading to W10 and 11.
MicroOS and its derivatives are all based on Tumbleweed. MicroOS was intended to be used for container workloads. Aeon grew out of that with a GNOME desktop, Kalpa a KDE desktop. Because they were focused in a way Tumbleweed is not, they are a more opinionated distro. On the other hand, Tumbleweed is a rolling distro that wants to be all things for everyone.
I guess you get the atomic system, but with Tumbleweed you get snapshot backups anyway.
One of the main advantages of Tumbleweed is the extensive testing pipeline. I'm not sure how a derivative would be able to offer a similar experience
[EDIT]
Oh, and I had a lot of problems installing Kalpa (from the submission) - all which I got fixed by using ChatGPT.
If you build and install packages from AUR, or use dodgy repos like Manjaro, then risk of update woes will increase significantly.
"note: These installation instructions will be changing, with the Beta release of Kalpa"
A bit rough around the edges - so probably unfair to publicise too prominently yet.
Just works
I admittedly only used it on a 13 year old gaming computer and couldn't get the GPU drivers because... you know containers.
This is something trivial with a regular install. (Especially with LLMs to assist)
I want to like Atomic, but it feels like an Apple-like regression in computing.
The secret is that all your power is within a distrobox container. All my dev tools, Emacs are in an Arch Linux container.
Ofc the distro can be installed for free. Owning the business sets you back some $6 billion.
Perhaps ventoy doesn't like SuSE.
https://news.ycombinator.com/item?id=44810281
This was pretty wild too: https://github.com/ventoy/PXE/issues/106 that's where they installed a self-signed EV cert in the trust store.
Why would any distro want to support a tool that intentionally breaks things? Ventoy could just boot ISOs without messing with them and everything would work fine, but the developers insist on injecting garbage.
This is not true.
I use it extensively and have done for more than 4 years now. It adds nothing at all to the installed OS. It doesn't care about the installed OS: I have successfully installed Linux, FreeBSD, Windows, even FreeDOS from Ventoy.