0.9.3 Beta release notes

Release date: May 2026 Previous release: 0.9 Beta (31 December 2024)

This is the largest release in Ditana’s history. Almost every subsystem has been touched, and the architecture has been fundamentally reorganised around the principle of configuration as data. This page covers the highlights; the full diff lives in the Git history of ditana-installer and ditana-config.

The big change: configuration as data

The biggest single shift since 0.9.0 is architectural. In 0.9.0, Ditana’s customisations lived in monolithic Arch packages — anything the installer wanted to set up had to be baked into a PKGBUILD. That made desktop customisation, browser choice, terminal selection, and dozens of other touch points difficult to compose.

In 0.9.3, all of this lives in a new, separately-versioned repository — ditana-config — as structured data in KDL v2. Every setting, every dependency, every lifecycle script is declarative. The installer code is small; the knowledge base is the brain.

Two consequences worth noting:

• Improvements ship without re-spinning an ISO. The installer downloads the latest configuration archive at runtime (with the ISO-bundled version as fallback). A bug fix merged into ditana-config on a Monday reaches new installs on Tuesday.
• Contributing is dramatically easier. Most contributions touch a single KDL file. The README.md of ditana-config walks through the data model in detail.

Four desktops, equal billing

0.9.0 shipped XFCE only. 0.9.3 ships four desktop environments — XFCE (X11), Wayfire, Niri, and COSMIC (all Wayland) — installable individually or in parallel. The greeter shows whichever ones you installed.

Wayfire and Niri are sometimes dismissed as incomplete environments. Ditana addresses the gap directly: a polished waybar configuration with theme-matched icons, nwg-launcher and nwgbar for app launching and power actions, sensible defaults across all four — so all four are first-class options, not technology demos.

lightdm has been replaced by greetd with tuigreet, which integrates cleanly with uwsm for session lifecycle management on Wayland.

Hardware-aware installation

Two detection passes are new or substantially extended:

• NVIDIA detection now cross-references both the open-gpu-kernel-modules PCI ID list and the NVIDIA legacy GPU page at install time, then recommends one of four options: nvidia-open-dkms (the new default for Turing+), nvidia-580xx-dkms (Maxwell/Pascal/Volta), nvidia-470xx-dkms (Kepler), or nouveau. DKMS-incompatible kernel choices are refused with an explanation.

• Virtual machine detection drives a number of follow-up choices (software-rendering fallbacks, disabled fstrim.timer).

CPU vulnerability detection and mitigation — already a Ditana hallmark in 0.9.0 — remain unchanged. See the CPU mitigations page for the full per-vulnerability rationale.

Console keymap, generated precisely

A small but visible improvement: vconsole.conf is now generated by ckbcomp from the user’s selected X11 keymap. The previous approach approximated; this one is exact, which matters during installation (passwords are typed into the Linux VT) and for VT use post-install. This resolves a complaint from a 0.9.0 DistroWatch comment.

System hardening — a new dialog

This is genuinely new in 0.9.3. The 0.9.0 installer covered CPU vulnerability mitigations but had no general-purpose hardening dialog. 0.9.3 adds a full System Hardening section under Expert Settings with documented sysctl-based options:

• Disabled unprivileged user namespaces (unprivileged_userns_clone=0) by default, with the browser/Flatpak trade-off spelled out.
• Restricted ptrace (yama.ptrace_scope=2 by default, =0 for the developer profile).
• Hidden kernel pointers, restricted dmesg, disabled kexec.
• Protected FIFOs and regular files in sticky directories (beyond Linux’s default hardlink/symlink protection).
• Hardened network stack (SYN cookies, no ICMP redirects, no source routing, reverse-path filtering).
• Restricted BPF JIT, optional perf_event_paranoid relaxation for developers.
• Optional hardened_malloc in full or light variants, plus optional mimalloc for performance-oriented setups.

Each option is presented as a checklist with full documentation — including which trade-offs you’re accepting when you check or uncheck it.

Flatpak support, integrated end-to-end

Flatpaks can now be declared alongside arch-packages and aur-packages in the configuration. Installation happens at first boot via a dedicated ditana-flatpak-finalize.service (blocking the greeter until completion, so the user isn’t surprised by mid-session installs).

Flatpaks are preferred over AUR-only equivalents where they exist — except where a Flatpak’s sandbox cannot work with Ditana’s default hardening. Brave Browser is the documented example: its Flatpak requires unprivileged_userns_clone=1, so Ditana ships brave-bin from AUR instead. The trade-offs are spelled out in the AUR vs Flatpak best-practice page.

Dynamic MIME defaults

Default applications for MIME types are now computed from the installed components rather than hardcoded. Install LibreOffice → LibreOffice handles .docx. Install ONLYOFFICE instead → ONLYOFFICE handles it. Install Thunar → Thunar opens directories. Install COSMIC Files → COSMIC Files opens them. All composed from the KDL declarations.

Terminal emulator, made first-class

The installer now offers six terminal emulators with a curated decision matrix: kitty (default, X11+Wayland), foot (Wayland-only, lightweight), Alacritty (GPU, minimalist), WezTerm (full-featured, multiplexer), Ghostty (modern, needs OpenGL 4.3+), and COSMIC Terminal. The xdg-terminal-exec standard is used consistently. Wayland-only terminals automatically get kitty installed as the X11 fallback if XFCE is also selected — no manual juggling.

AUR helper: pikaur → paru

pikaur has been replaced by paru. The trigger was pachub (the GUI Arch package browser, pinned in every desktop panel alongside bazaar for Flatpak) which only supports yay or paru. Going with paru was the better fit for Ditana’s other needs as well.

Password handling

You can now override the strict pwscore password check for the user account if you have a good reason to. The check stays mandatory when full-disk encryption is enabled — there, a weak password actively reduces security.

This addresses several 0.9.0 user reports of installations being aborted because users couldn’t pass the default pwscore minimum.

GitHub issues closed

Ten user-reported issues from 0.9.0 are implemented in 0.9.3 — bug fixes and feature requests. The list is available on the installer issue tracker.

Behind the scenes

• Ansible → Sparrow6. The configuration management logic that customises files like mkinitcpio.conf has migrated from Ansible to Sparrow6, with substantial contributions from Alexey Melezhik. Sparrow6 is also used for testing the automated configurations themselves. The migration eliminates a Python runtime dependency and produces more readable test output.

• Acknowledgements. Thanks to Alexey Melezhik for the Sparrow6 work and continued collaboration. Thanks to Thomas Zipproth for ongoing testing and feedback. Thanks to everyone who filed an issue on 0.9.0 — every one of them was reviewed, and most are now closed.

A small piece of history

When Ralf Hersel interviewed me for gnulinux.ch in early 2025 about Ditana 0.9.0, his opening note was that he’d won a bet — he’d predicted a Linux distribution with built-in AI would ship before the end of 2024, and 0.9.0 (31 December 2024) made it on the deadline.

Ditana does ship the optional Ditana Assistant, which uses a local Ollama model (or any OpenAI-compatible endpoint) to generate shell commands. It’s useful, but I’d be the first to say “AI distribution” is overselling it — the assistant has limited system context, and a genuinely AI-integrated distro is a separate project I might explore later (automated log analysis being the most realistic direction). For now: it’s a handy tool, pinned in the panel if you enable it.

Upgrading from 0.9.0

There is no in-place upgrade. The architecture has changed too much. A fresh install on top of a Timeshift / ZFS snapshot of your /home (or whatever your data partition is) is the supported path.