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?
Kalpa is great and hits way above its alpha status; I've been running it on my laptop for months now with zero issues. It's been really nice to not have to worry about updates, just gotta reboot it every now and then and most things just work.
I wanted to try an Atomic Linux, I think I tried the Fedora flavor, nothing really worked for me for some reason, I gave in to Arch and tried it a la EndeavourOS. Have not looked back since.
I've installed https://getaurora.dev/en/, another atomic Linux distro, for a non technical user and find it really good. I've read arguments that its architecture was better than kalpa, but I don't find it back and I have no sufficient knowledge or experience of both to have an opinion.
I am not sure I fully understand the usability trade-offs when it comes to these "atomic" distros. One the one hand, security seems to improve markedly, since the root filesystem is largely immutable. On the other hand, it does seem that a lot of straightforward things become harder. I generally dislike flatpaks and favor a low-level, bare-metal approach to things and atomic distros seem to go against that. Maybe I should just run some experiments in a VM.
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.
> dislike flatpaks and favor a low-level, bare-metal approach
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.
since flatpacks/snaps/appimages are containerized-ish, i see no point in these immutable distros any more. also, cosmic is where the focus of linux desktop should be, not kde or gnome.
Been running Aeon, the Gnome version of Kalpa, on my personal laptop for about six months now. I came from Tumbleweed so the learning curve wasn't steep. Overall the experience has been good!
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.
I've been using Aeon for about 8 months now and while I appreciate the intent and feel its well engineered, in practice I run into all sorts of edge cases where I'm fighting the system to do what I want to do. I'm sticking with it because I do learn interesting things in the process, and sunk cost fallacy, but I find it hard to recommend. I probably am too opinionated on my system to be the best target user though
25 comments
[ 3.1 ms ] story [ 34.4 ms ] threadI 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?
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.
"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.
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.
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.
[1]: https://github.com/containers/bubblewrap
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.