Ditana GNU/Linux distinguishes itself from other distributions by providing a clean, JSON-driven configuration approach and a modern installer written in Raku. In this post, we’ll show you how Ditana uses JSON-based hardware detection and handles complex settings—such as the ZFS filesystem—through a concise, maintainable system that’s easy to extend. We’re also actively seeking developers and contributors who want to help shape Ditana’s future!
Hardware Detection in JSON
Instead of scattering detection logic across multiple scripts, Ditana manages everything in JSON files. Each entry describes a specific hardware or system feature, along with the Raku code that runs at install time. For example:
{
"name": "uefi",
"detect": "'/sys/firmware/efi'.IO.e",
"required-by-chroot": true
},
{
"name": "total-ram-gib",
"detect": "('/proc/meminfo'.IO.lines.grep(/MemTotal/).first.words[1] / 1024 / 1024).ceiling"
},
{
"name": "avx2-available",
"detect": "'/proc/cpuinfo'.IO.lines.first(*.contains('flags')).contains('avx2').so"
}
The detect property contains Raku expressions that run at install time, making the logic straightforward and modular.
Advanced Configuration with settings.json
Beyond hardware detection, settings.json also handles user-configurable options like filesystems or kernel selections. Here’s an example entry for ZFS:
{
"name": "zfs-filesystem",
"dialog-name": "File System",
"short-description": "ZFS - Snapshots, Self-Healing Storage & RAID-Z Support",
"long-description": "ZFS: Supports atomic snapshots with a pre-configured snapshot solution instead of Timeshift. Designed for high data integrity with automatic self-healing. The installer will switch to the recommended Long-Term Support Kernel automatically, because ZFS requires DKMS modules (see Expert Settings → Kernel Selection menu available for selection later).",
"arch-packages": [
"zfs-utils"
],
"spdx-identifiers": "CDDL",
"required-by-chroot": true,
"available": "`install-standard-lts-kernel OR install-standard-stable-kernel OR install-zen-kernel`",
"default-value": "`install-standard-lts-kernel`"
}
Tristate
Ditana utilizes a custom Tristate class—capable of True, False, and Any (undefined)—to manage values that are unknown or not yet defined. This flexibility is crucial for Ditana’s highly adaptable installer, which responds to both hardware attributes (like BIOS or UEFI, or drivers that may restrict kernel choice) and a wide range of user preferences.
Tristate Logic Explained Through Its Unit Test
In Raku, you can embed unit tests directly in the class, and they’ll run at compile time without requiring a dedicated test framework. For example:
CHECK
my $t = Tristate.new(True);
my $f = Tristate.new(False);
my $u = Tristate.new(Any);
my @tests = (
[$f AND $u, 'False', 'False and Any'],
[$u AND $f, 'False', 'Any and False'],
[$t AND $u, '(Any)', 'True and Any'],
[$u AND $t, '(Any)', 'Any and True'],
[$t OR $u, 'True', 'True or Any'],
[$u OR $t, 'True', 'Any or True'],
[$f OR $u, '(Any)', 'False or Any'],
[$u OR $f, '(Any)', 'Any or False'],
[NOT $u, '(Any)', 'not Any'],
[NOT ($u OR $u OR $t or $u), 'False', 'not (Any or Any or True or Any)']
);
for @tests -> [$result, $expected, $description] {
unless $result.Str eq $expected {
die "Test '$description' failed:\n Expected: $expected\n Got: $result.Str()";
}
}
This demonstrates how Tristate gracefully handles undefined conditions.
Why This is Relevant for Ditana
Ditana’s flexible configuration possibilities require a way to resolve dependencies between settings. For example, with ZFS, the right boot manager (GRUB or ZFSBootMenu), kernel, and optional encryption settings all need to align. Things can get especially complex if you require special drivers or rely on a legacy BIOS. Thanks to this JSON-based configuration and the Tristate logic, Ditana ensures that any combination of user choices leads to a valid, bootable system. If something isn’t available, the installer won’t let you pick it—and it will explain why.
CPU Vulnerability Mitigation Options
In line with Ditana’s design philosophy, our distribution enables CPU vulnerability mitigations in High Security Mode by default. During installation, Ditana’s installer allows you to configure each detected CPU vulnerability individually, offering the option to maintain these enhanced security settings or revert to the default kernel configurations.
Default Kernel Settings vs. Ditana’s Mitigations
The default kernel settings provided by the Linux kernel developers aim to balance security and performance. However, certain security vulnerabilities remain if you rely solely on these defaults. Ditana prioritises robust security by enabling mitigations that address these vulnerabilities via the officially documented kernel parameters. For most users, the performance implications of Ditana’s mitigations are negligible, while the security benefits are substantial.
Customization and Flexibility
We understand that some users may prefer to optimize their systems for maximum performance, even if it means accepting potential security trade-offs. Ditana’s installer framework therefore empowers you to adjust CPU vulnerability mitigation settings according to your preferences. Comprehensive explanations for each mitigation option are available through the installer’s Help button and detailed in the documentation.
Hardware-Specific Configuration
Ditana's hardware detection system ensures that mitigation options are only presented for the specific vulnerabilities your CPU actually faces—and only for those where the Linux kernel itself does not use the maximum possible mitigation by default. For more details on which vulnerabilities are detected and which are not, see our documentation.
By choosing Ditana’s default mitigation settings, you ensure that your system maintains a high level of security against known CPU vulnerabilities. We recommend keeping these settings enabled unless you have specific requirements that justify loosening them for performance considerations.
{
"name": "is-spectre-v2-vulnerable",
"detect": "given '/sys/devices/system/cpu/vulnerabilities/spectre_v2'.IO { .e && .slurp.chomp ne 'Not affected' }"
}
Example from settings.json to detect whether your CPU is vulnerable to Spectre V2.
Above: A preview of Ditana’s installation summary dialogue, showing the High Security Mitigations that would be configured in this example. You can decide to adopt Ditana’s mitigations or stick to the Linux kernel defaults.
Dynamic NVIDIA Driver Detection
When it comes to NVIDIA graphics cards, Ditana employs a novel approach to identify whether a legacy driver is needed or if the current proprietary driver is more appropriate. During installation, the installer downloads and parses the official NVIDIA legacy GPU page at https://www.nvidia.com/en-us/drivers/unix/legacy-gpu. If this page is unavailable or the parser requires updates (we run tests to validate the downloaded data), a cached and filtered version from our repository is used instead. By comparing the detected GPU against the data in this page, the installer can determine if the user’s GPU necessitates a legacy driver. In cases where the required driver version is older than 470, the open-source Nouveau driver is recommended.
The default installation always uses the proprietary DKMS version of the NVIDIA driver, and the user can override the driver selection in the installer, for example to use the NVIDIA open-source driver. However, impossible combinations are automatically disallowed. Ultimately, this system ensures that each NVIDIA card is matched with the safest and most compatible option available, while still preserving user choice where it makes sense.
A Raku-Based Installer
The Ditana installer is written in Raku, combining the succinct feel of shell scripting with modern error handling and concurrency features. Together with JSON-based detection and user-configurable settings, this approach keeps the code organized yet powerful—proving that advanced installation logic doesn’t require massive shell scripts.
Give Ditana a Spin!
If you’re looking for an Arch-based distro that dares to think differently, Ditana might be your new best friend. From hardware detection to advanced filesystem setups, it even offers a local or cloud-based AI assistant that can execute commands after confirmation (computer use). For ZFS, an optional auto-snapshot mechanism for easier maintenance is provided. Overall, currently there are 21 packages we developed for Ditana in its dedicated Arch repository (either mandatory or optional).
And if you’re interested in shaping Ditana’s future, we’d love your help! Whether you’re a developer, documentation enthusiast, or just passionate about Linux, your contribution will be greatly appreciated. The project is split into multiple Arch packages, allowing you to pick the components you want. Plus, we have thorough documentation (both inside the installer and on the website) so you’ll always understand the why behind each setting.
Questions or Feedback? You are welcome to drop a comment below! Ditana is constantly evolving, and we’re eager to hear your thoughts on improving our JSON-based detection, Tristate logic, or Raku-driven installer. We’re actively seeking collaborators who share our vision—come join us on this journey!
Join the conversation on our dedicated Ditana Discord Server, where we discuss features, share updates, and brainstorm ideas together.
Top comments (0)