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.
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
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.
It seems to just be re-exposing existing lua runtimes, which makes the naming very unfortunate IMO. The underlying runtime Luau, for example, details its performance here https://luau.org/performance . Luajit is already popular and has plenty of benchmarks online.
Throwing in my support for kde connect. It's just super convenient and it's FOSS + cross platform too. kde should honestly advertise it aggressively. There's nothing like it anywhere else.
You absolutely can just transpile any language into any language. You just need to be willing to give up on performance, and fil-c is more or less doing just that.
Local reasoning is the foundation of everything formal (this includes type systems) and anyone in the type-system-design space would know that. Graydon Hoare (ex-rust dev) wrote a post about it too (which links to another great without-boat's post in the very first line): https://graydon2.dreamwidth.org/312681.html
The entire point of having a static-type-system, is to enable local reasoning. Otherwise, we would just do whole program analysis on JS instead of inventing typescript.
We have the basic primitives like signed and unsigned integers of various sizes, floating point numbers, bools and chars.
Remember that wasm components are like shared libraries (dll/so objects). Shared libraries themselves have dependencies (eg: vlc needs qt, which needs mesa, which needs x11/wayland etc..). Each component/shared library has a set of imports from other shared libraries and exports items to other shared libraries or apps.
For example, lets say that I want give a vector/array as an argument or receive it as the return type. On native libs, we just give a pointer + len as arguments, and the function can simply read/write using that pointer.
Except, wasm components are isolated (shared-nothing model). So, I can't just allocate the bytes and give a "pointer" to the jpeg decoder. Because both of us don't share the memory. This has a few reasons:
1. security: separate memories make sure that a component can't read/write another component's memory.
2. safety: If we don't have higher level types, then people will just pass around blobs and cast those bytes into types. Imagine one component thinks of rect as `Rect { x, y, w, h: f32 }` and another component thinks `Rect { x1, y1, x2, y2: f32}`. Without "record" types, we can't find that error.
3. flexibility: Lets say we want to pass around a list of strings between components. how would you do it between rust and js? To let each language feel natural, we need to "copy" these higher level types across the boundary (and wasm needs to understand these higher level types) into the respective suitable types.
This is why we have records (structs), strings, list<T>, variants (tagged unions), Option<T> and such types to allow for a feature-rich API. These are all passed by copy at the boundary with proper validation by the runtime in advance, so you get both performance, safety and ergonomics.
Finally, we also need to talk about "ownership", because some objects (like files via file descriptors) need to be passed across component boundary and we need to wasm let somehow know that we are passing on ownership of the file. We do this with "resource" (object with an ownership like a file descriptor or host native object or socket etc..). And wasm must also ensure that the object will be alive for the duration of the borrow.
The rest of the WIT is simple.
Interface is literally just a group of type signatures or objects. just like a module in python, rust. In C world, we usually just prefix the library/type name for all the function that belong to a certain library/type. In WASI, we just place the related fns inside an interface.
Similarly, a world is just a group of imports and exports that represent a component. world = component. world can import/export types/interfaces/fns/data. You can have multiple 'worlds' and interfaces within a wit file.
And a package is a group of wit files. similar to a java or go package that a file belongs to.
Its not really hard to understand. Most of the terminology directly translates to what we all see in any modern language like js, py, java, rust, go etc..
And the docs are not accessible at the moment, because its still a WIP and unstable. They are experimenting with rust and js to see how well this model works in practice.
# Terminology
1. Immutable: The core OS (/usr directory) is kept in "pristine" condition by disallowing modifications.
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.
- 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.