Documentation

• 1: Welcome!
• 2: Design Philosophy
• 2.1: Why Arch?
• 2.1.1: Unified Package Management
• 2.1.2: Security and Transparency in Package Management
• 2.1.3: Embracing Arch’s Unified Package Management Philosophy
• 2.1.4: Comprehensive File Tracking: The Ditana Advantage
• 2.1.5: The Confinement Dilemma: Why Snap & Similar Solutions Aren’t Always Ideal
• 2.1.6: Questioning the Myth of Stability in Traditional Release Cycles
• 2.1.6.1: Boost Library Example: Timely Updates and API Stability
• 2.1.6.2: Incidents with rolling release distributions
• 2.1.7: Rolling Release Model Minimizes the Need for AppImage
• 2.1.8: Final Thoughts
• 2.2: Why Raku?
• 2.3: Best practices
• 2.3.1: Software Installations
• 2.3.2: Automatic System Snapshots
• 2.3.3: Desktop
• 3: The Installer
• 3.1: Desktop Applications
• 3.2: Multimedia Applications
• 3.3: AI Applications
• 3.4: Kernel Configuration
• 3.4.1: General Kernel Configuration
• 3.4.2: ZRAM related kernel configuration
• 3.4.3: CPU Vulnerability Mitigation Options
• 3.5: Comparison of File Systems
• 3.6: Storage & File System Options
• 3.7: Firmware
• 3.8: Development Tools and Libraries
• 3.8.1: Diffuse
• 4: The Assistant
• 4.1: Key Features
• 4.2: Use Cases
• 4.3: Installation
• 4.4: Configuration
• 4.5: Command-line Interface
• 4.6: Introspective Contextual Augmentation (ICA)
• 4.7: Intelligent Caching
• 4.8: Ongoing and Future Development
• 4.9: Example Sessions
• 4.9.1: Computer interaction, example 1
• 4.9.2: Computer interaction, example 2
• 4.9.3: Automatic use of Wolfram|Alpha
• 4.9.4: Sophisticated calculator
• 4.9.5: Pastime mode, example 1
• 4.9.6: Pastime mode, example 2
• 4.9.7: ICA example 1
• 4.9.8: ICA example 2
• 4.9.9: ICA example 3
• 5: The Packages
• 5.1: Core Packages
• 5.2: Configuration packages
• 5.3: Ditana Desktop Enhancements
• 5.4: Packaged External Sources
• 5.5: Repackaged AUR Contributions

1 - Welcome!

Unlock a New Level of Control with Ditana GNU/Linux

Welcome to Ditana GNU/Linux, where the flexibility of Arch meets user-friendly guidance. Say goodbye to the compromises of other distributions and embrace a system that puts you in the driver’s seat.

Is Ditana Right for You?

Ditana is perfect for:

• Power Users: Take full control of your system with extensive configuration options, without constantly relying on the terminal. Thanks to our custom-developed installation wizard and a powerful framework, you can choose from multiple filesystems (ZFS, BTRFS, XFS, EXT4), initrd systems (BusyBox, systemd), and kernel parameters.

• Security Enthusiasts: Retain control over security features with customizable kernel security mitigations for CPU vulnerabilities, which are often only partially enabled by default in other distributions. Check out all documentation tagged with security for details on our pre-configured security measures and how to tweak them to meet your needs.

• Performance Seekers: Experience a system that automatically tunes your hardware for optimal performance, whether you’re running a high-end workstation or a minimalist server. Our automatic hardware tuning features can be reviewed and adjusted during installation to ensure you’re always getting the best out of your setup.

• Developers: Work in a stable, customizable environment you can tailor to fit your coding needs. Beyond optional advanced locale configurations, Ditana uses a sophisticated Raku-powered framework for system-wide Linux configuration, relying on JSON definitions and selectively using Ansible for specific tasks (like custom HOOKS). This approach means you can manage packages, dependencies, and detailed configurations more elegantly than with typical scripting methods.

• Learners: Dive into Linux system administration with abundant documentation in the installer, on the website, and across our Ditana GitHub repositories. Our built-in AI assistant (connectable to local LLMs or OpenAI’s ChatGPT) offers in-installer help dialogs and guided command suggestions, making it easier for you to grasp Linux concepts step by step.

Why Ditana Stands Out

• Smart, Unified Installation: A single ISO for everything—Ditana’s intelligent installer adapts automatically to your hardware and guides you through setup with clarity. Thanks to the transparent settings.json approach, developers can more easily troubleshoot or enhance support for uncommon hardware configurations.

• Security You Control: Ditana comes with pre-configured security features so you’re protected from the start. All security aspects, including CPU vulnerability mitigations, are transparent and fully adjustable, giving you the freedom to customize how your system handles potential threats.

• Performance Optimized for You: Through automatic hardware tuning, Ditana ensures top performance in various scenarios. Default performance settings, which are accessible during installation, can be fine-tuned to meet specific needs for gaming, productivity, or server workloads.

• Enhanced Desktop Experience: Enjoy an improved XFCE desktop setup with automatic display DPI detection, intelligent scaling, and tweaks that help avoid NVIDIA driver conflicts. Everything is designed to work seamlessly out of the box.

• Sophisticated Configuration Framework: Under the hood, a powerful Raku-based system uses JSON to declare dependencies, define package specifications, and control advanced configurations. When needed, our framework selectively relies on Ansible in the backend (e.g., for HOOKS), giving you fine-grained control without the complexity of traditional scripting.

• Simplified Package Management: Keep things straightforward by sticking to Arch’s native pacman and the AUR—no more juggling multiple package systems. Learn more in our Design Philosophy.

• Automatic System Snapshots: During pacman and AUR updates, Ditana automatically creates system snapshots. The ZFS edition is especially powerful, generating snapshots on the fly without reboots and making sure the pacman database is included as well.

• Integrated AI Assistant: A complex built-in AI assistant helps with system administration, either via its graphical interface or right in the terminal. You decide which commands to execute, maintaining full control. You can connect it to a local LLM setup or OpenAI’s ChatGPT, granting you both flexibility and privacy.

Built on Arch, Enhanced by Ditana

While maintaining full compatibility with Arch Linux, Ditana introduces:

• A user-centric installation framework with advanced options
• Enhanced security features with detailed guidance
• Unified package management using pacman and the AUR
• Intelligent performance optimizations

Your Feedback Matters

We believe in the power of community and continuous improvement. While we’ve strived to create an exceptional Linux distribution, we recognize there’s always room to grow.

Seeking Input from Advanced Users

If you’re adept at installing Arch Linux via the official installation guide using terminal commands, you might find Ditana’s installer lacking certain options, despite its extensive configurability. We’re eager to hear from users like you about any features or configurations you feel are missing. Your insights are invaluable in helping us enhance the installer to better meet the needs of advanced users.

Commitment to Arch Principles

Although Ditana is built upon Arch Linux, we acknowledge that we’re not active members of the Arch developer community. With over 25 years of professional experience poured into Ditana, it’s possible that some solutions may be unconventional or diverge from Arch’s design principles. If you notice any discrepancies or areas for improvement, we’d greatly appreciate your constructive feedback to help us align more closely with Arch’s philosophy.

A Solo Endeavor Open to Collaboration

The current state of Ditana is the result of a single developer’s dedication. Despite thorough testing on various hardware and countless bug fixes, we recognize that some issues may have been overlooked. We’re on the lookout for Linux-savvy individuals who are interested in contributing to the project. Whether it’s through code contributions, bug reports, or feature suggestions, your participation can make a significant difference.

Tested Hardware and Call for Testers

We’ve rigorously tested Ditana on a range of hardware to ensure stability and performance:

While this hardware pool provides a solid foundation, we know it’s not exhaustive. We encourage users with different systems to test Ditana and share their experiences. If you encounter any issues, please report them on GitHub. Your feedback is crucial in helping us improve compatibility and performance across a wider range of hardware.

Ditana for Servers

Rolling-release distributions like Arch Linux are uncommon choices for server environments. However, we’ve had excellent experiences using Ditana on servers due to its consistent package management and streamlined maintenance. By relying solely on pacman and the AUR, you avoid juggling multiple package systems, simplifying updates and security patches.

For integration with hosting providers, support for tools like Cloud-Init is often required—a feature we’re planning to implement. In the meantime, Ditana’s installer is well-suited for single, self-managed servers. We’ve developed an experimental systemd service to keep our servers continuously updated. While not yet publicly released, this solution has proven effective and underscores Ditana’s potential in server environments.

Join Our Community

Be part of a growing community that’s shaping the future of Ditana:

• GitHub: Contribute code, report issues, or explore our codebase.
• Discord: Connect with other users, get support, and share ideas.
• Stay Updated: Receive regular security patches and new features.

Your involvement is vital to Ditana’s evolution. Whether you’re a seasoned developer, a system administrator, or a Linux enthusiast, your contributions help us build a better, more versatile distribution.

Get Started Today

Ready to redefine your Linux experience? Download the latest Ditana ISO from our download page and let our smart installer guide you through a personalized setup.

2 - Design Philosophy

Core Philosophy

Ditana is built for users who:

• Value high configurability without the need to rely on the terminal, made accessible through a uniquely guided installation wizard.
• Believe in the importance of retaining control over security features, allowing them to decide which protections are most relevant for their own use.
• Prioritize transparency, appreciating detailed documentation of all installation steps through (1) help dialogs within the installer, (2) this website, and (3) the comprehensive READMEs across our Ditana GitHub repositories.

Our approach provides a robust security foundation without assuming which specific protections a user might deem excessive. While Ditana offers advanced security options, we trust the user to determine what is necessary and relevant for them. Unlike many systems that may silently disable or omit security options, Ditana fosters transparency and user agency by openly presenting these choices, respecting the user’s authority over their own security needs.

The project’s name derives from Ammi-Ditana, a Babylonian king known for his long, peaceful reign and focus on infrastructure improvement. This historical connection mirrors our commitment to:

• System Stability: Building upon Arch Linux’s robust foundation while ensuring long-term reliability.
• Continuous Enhancement: Regular updates and improvements without compromising system integrity.
• User Empowerment and Transparency: Providing detailed explanations for every configuration option, ensuring that users are fully informed when making decisions about their system’s behavior.
• High Security Standards: Offering secure defaults and comprehensive documentation without making assumptions about which security features may be irrelevant to users.

User Empowerment Through Informed Choices

Ditana prioritizes giving users full control over their system by providing comprehensive information and flexible options during setup. Instead of imposing static configurations without the user’s knowledge, Ditana’s installer offers detailed explanations and guidance, enabling users to make informed decisions about critical system settings. This approach not only enhances transparency but also empowers users to tailor their Linux experience according to their specific needs and preferences.

Examples

• Locale Settings: Users can choose between fully localized and partially localized setups, which is particularly beneficial for developers. Detailed explanations are provided during installation. Read more in the Locale Settings documentation.
• Optimal Logical Block Addressing Format for SSDs: Ditana detects whether the LBA format is optimal and offers an option to change it, something that traditional partition formatting doesn’t achieve. Users are guided through the benefits and consequences of this choice.
• Swap Partition, ZRAM, and SSD Longevity: Ditana offers comprehensive guidance on configuring swap, including support for ZRAM, which is enabled by default to enhance performance. For users who prefer not to use ZRAM, Ditana provides options to reduce swap usage to extend SSD lifespan. The installer transparently explains the advantages and potential impacts of each setup.
• Boot Initialization System: Users can switch from the default systemd to a BusyBox-based setup for the initramfs phase. This flexibility allows for alternative early boot strategies, while Ditana remains consistent in using systemd post-initramfs. All necessary configurations are robustly handled by the installer, with explanations provided about the differences between these systems.
• General Kernel Configuration: Users can access the General Kernel Configuration dialog to adjust kernel parameters that optimize system performance, security, and resource management.

High Security Standards

Ditana’s core design philosophy emphasizes transparency and user agency in making security-related decisions. Security features are enabled by default, and we avoid silently disabling or neglecting critical security measures. We provide users with the information and options they need to tailor their system’s security to their own requirements.

Key Security Features

• Detection of Available Security Mitigations: Ditana detects security vulnerabilities specific to your CPU and offers to activate mitigations that enhance the security of your system.
• Configurable Kernel Parameters for Security: Ditana enables specific kernel parameters such as init_on_alloc=1 (initialize newly allocated memory) and init_on_free=1 (clear deallocated memory). These measures prevent data leakage by ensuring that memory is securely wiped.
• Controlled Core Dumps: To enhance system security, Ditana disables automatic core dumps in the filesystem package. Clear instructions are provided on how to temporarily enable core dumps when needed.
• Linux Audit Daemon: Installed by default, the Linux Audit Daemon provides essential insights into system behavior and potential security issues using sudo aureport. It is specially configured to avoid queue overflow under conditions of limited CPU resources.
• Desktop Installation Security Features:
  • Arch-Audit-GTK Security Notifier: Enhances security awareness by displaying a tray indicator when security updates are missing, alerting users to take necessary actions.
  • Pikaur AUR Helper: Utilizes systemd dynamic users for building packages, enhancing security. Additionally, Pikaur leverages the AUR voting system to prioritize well-maintained and trusted packages, ensuring users install reliable software.
  • Kalu Upgrade Notifier: Informs users about available system updates and provides the latest Arch Linux News which often include security recommendations.

During the installation process, users are presented with detailed help dialogs that explain the implications of each security option. This guidance enables users to make well-informed, personalized security decisions. Whether installing a headless server or a desktop setup, Ditana ensures that security configurations are transparent and under the user’s control.

Consistent Package Management Approach

Ditana adheres strictly to using Arch Linux’s native package management system for all software installations. This approach contrasts with the increasing trend in other distributions of mixing multiple installation methods (such as Flatpak, Snap, AppImage, or executing downloaded shell scripts with elevated privileges). We believe that a unified package management strategy offers several benefits:

• System Coherence and Stability: By relying on the Arch Package Manager (pacman) and the Arch User Repository (AUR), Ditana ensures a consistent and transparent method for handling software installations, upgrades, and removals.
• Security and Integrity: A single package management system reduces the risk of conflicts, dependency issues, and unmonitored background updates, while centralizing control over software sources.
• User Empowerment: Users benefit from a simplified management experience, trusting that all software installations are handled using a well-documented, community-driven system.

For more details, see Why Arch?.

Emphasis on License Transparency

When choosing packages to install during the setup, Ditana always provides clear information about the licensing of each package. Respecting software licenses is crucial, and transparency in this regard ensures users are well aware of the legal implications. This is an area often overlooked by other distributions, which may assume that users are responsible for researching licensing information independently. We aim to provide a well-informed experience.

Avoidance of Special Configuration Tools

Ditana avoids shipping specialized configuration tools that often conflict with user-made adjustments to system configurations. Instead, all configuration options are centralized in the installer, where the system is in a well-defined state, ensuring reliable changes to settings. For more complex configurations, Ansible is utilized to maintain robustness.

No Live System Philosophy

Ditana does not provide a traditional live system, as the extensive configuration options available within the installer outweigh the limited benefits of a live environment. Instead, Ditana uses a highly customizable installation ISO to offer a comprehensive setup experience.

The installer employs text-based, pseudo-graphical dialogs (using the dialog utility) to guide users. This approach is particularly useful for headless server installations, where no graphical interface is available. Clear instructions are provided on using these dialogs with keyboard navigation, ensuring ease of use.

Final Note on Security and Usability Balance

Ditana’s overall goal is to provide users with the tools and information they need to configure their system securely and effectively. By avoiding hidden defaults and providing a wealth of documentation and context-sensitive help, we aim to offer an experience that is both user-friendly and professionally secure. Users are empowered to confidently tailor their system to their needs, with all decisions based on clear and structured information.

2.1 - Why Arch?

Disclaimer

The perspectives and opinions expressed here are those of the author, based on over 25 years of experience in various industrial sectors as an external software developer. These views are not intended to represent the Arch Linux community and should be interpreted as insights derived from personal experience.

This section aims to spark thoughtful discussion and reflection, not to impose a singular viewpoint. While I’ve incorporated elements of my professional background and technical insights into Ditana’s design philosophy, I welcome constructive input and alternate viewpoints from the community. The vision for Ditana is inherently community-driven, and I encourage engagement, dialogue, and collaboration to continuously improve and evolve this project together.

2.1.1 - Unified Package Management

Single Package Manager for All Software

Pacman, Arch’s primary package manager, along with AUR helpers like pikaur, handles all software installations, updates, and removals. This unified system manages both official repository packages and those from the Arch User Repository (AUR), including software typically installed via language-specific package managers like pip.

• Unified Updates: With a single command (pikaur -Syu), users can update all installed packages, ensuring the entire system is up-to-date without juggling multiple package managers.

• Simplified Maintenance: This approach simplifies system maintenance and reduces the complexity often associated with managing different package managers for different types of software.

Comprehensive Software Availability

One of Arch Linux’s strengths is its vast software availability:

• Official Repositories and AUR: Users can generally assume that any desired software is available as an Arch package—either in the official repositories or through the AUR.

• Wide Range of Software: This includes exotic and commercial software like Spotify, Balena Etcher, CLion, Visual Studio Code, and Synology Drive.

Integration of Proprietary Software into Arch Package Management

A significant advantage of Arch’s package management is its ability to integrate proprietary software into the system’s package management, even when such software is only officially distributed in foreign package formats like .deb. This is achieved through the AUR, where these packages are repackaged to become native Arch packages managed by pacman.

By repackaging proprietary software into Arch-compatible packages, users avoid installing software through external installers or scripts that bypass the package manager. Each individual file within these repackaged packages is explicitly tracked and managed by pacman, ensuring precise system control and preventing fragmentation. This means that every installed file can be consistently monitored, avoiding the inconsistencies that arise when software is installed outside the package manager.

Example: Visual Studio Code

The AUR package for Visual Studio Code repackages the official binaries provided by Microsoft into an Arch package:

❯ pikaur -Si visual-studio-code-bin
AUR Git URL     : https://aur.archlinux.org/visual-studio-code-bin.git
AUR Web URL     : https://aur.archlinux.org/packages/visual-studio-code-bin
Name            : visual-studio-code-bin
Version         : 1.94.2-1
Description     : Visual Studio Code (vscode): Editor for building and debugging modern web and cloud applications (official binary version)
URL             : https://code.visualstudio.com/
Licenses        : custom: commercial
Depends On      : libxkbfile  gnupg  gtk3  libsecret  nss  gcc-libs  libnotify  libxss  glibc  lsof  shared-mime-info  xdg-utils  alsa-lib
Optional Deps   : glib2  libdbusmenu-glib  org.freedesktop.secrets  icu69
Conflicts With  : code
Votes           : 1459
Popularity      : 15.285375

The PKGBUILD script specifies the official download URL and repackages it:

source_x86_64=(code_x64_${pkgver}.tar.gz::https://update.code.visualstudio.com/${pkgver}/linux-x64/stable)

Example: Synology Drive

Similarly, the AUR package for Synology Drive Client repackages the official .deb installer provided by Synology into an Arch package:

pkgname="synology-drive"
pkgver="3.5.1_16101"
pkgrel="1"
pkgdesc="Drive for PC, the desktop utility of the DSM add-on package, Drive, allows you to sync and share files owned by you or shared by others between a centralized Synology NAS and multiple client computers."
arch=('x86_64')
url="https://www.synology.com"
license=('custom')
depends=('glibc')
optdepends=('nautilus: For nautilus integration')
source_x86_64=(https://global.download.synology.com/download/Utility/SynologyDriveClient/${pkgver%-*}-${pkgver##*_}/Ubuntu/Installer/synology-drive-client-${pkgver##*_}.x86_64.deb)
sha256sums_x86_64=('55e4b96cf70c3382430921f9197925e0e8108eb3ca68d0e1e4f7d7dbcff3a9a5')

package() {
    cd "${srcdir}"
    tar -xJf data.tar.xz -C "${pkgdir}"
    install -Dm 644 "${pkgdir}/opt/Synology/SynologyDrive/LICENSE.txt" "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"
}

In both cases, the software is obtained directly from the official sources, ensuring authenticity. The key advantage is that these proprietary applications are repackaged in such a way that every individual file is monitored and managed by pacman. This allows for consistent tracking, updating, and removal using the package manager, which contrasts with other distributions where installing such software might involve using external installers or scripts that bypass the native package manager. This approach effectively prevents system fragmentation and maintains precise file tracking and management.

Open Source Projects and Building from Source

For open-source projects that might only provide packages in foreign formats (e.g., .deb or .rpm), Arch’s PKGBUILD scripts often build the software from source.

2.1.2 - Security and Transparency in Package Management

Secure Package Building Environment

The process of building and installing packages from the AUR is designed to enhance security and minimize risks:

• Controlled Build Process: Rather than executing installation scripts with administrative rights, AUR packages are built locally using PKGBUILD scripts. These scripts define the build and installation procedures, ensuring that the process is transparent and confined to a controlled environment.

• Interactive Package Management: Instead of using potentially risky options like --nodeps, --force, or --noconfirm, Ditana’s AUR helper pikaur interactively guides users through the installation process. This approach allows users to manually handle unexpected prompts from pacman, such as untrusted GPG keys or checksum mismatches. Additionally, pikaur offers features like reviewing PKGBUILD and .install files, showing AUR package diffs, and manual package selection during installation. These capabilities ensure that users remain in control, verifying each step and reducing the risk of inadvertently installing malicious code.

• Enhanced Build Features: Pikaur includes several features that contribute to a secure and efficient build environment, such as:

  • Build Local PKGBUILDs with AUR Dependencies (-P/--pkgbuild): Ensures that dependencies are correctly managed and built in a controlled manner.
  • Retrieve PKGBUILDs from AUR and ABS (-G/--getpkgbuild): Allows users to fetch and inspect build scripts before execution.
  • Review and Diff AUR Packages: Users can view differences between package versions and examine build scripts to verify their integrity.
  • Shell Completion for AUR Package Names: Supports bash, fish, and zsh, making it easier to search and install packages securely.

By integrating these interactive and review-focused features, pikaur maintains a secure package building environment, empowering users to make informed decisions throughout the installation process.

Building from Source for Open-Source Projects

When open-source software is distributed only in foreign package formats, Arch’s PKGBUILD scripts frequently compile the software directly from source, offering several key advantages:

• ABI Compatibility: Building from source ensures compatibility with the system’s Application Binary Interface (ABI), which can prevent runtime issues that may arise if precompiled binaries were built against different library versions. By compiling on the user’s system, the build process aligns with current dependencies, eliminating potential incompatibility errors.

• Integrity of Distribution: Building from source mitigates risks associated with corrupted or altered binary packages. Since the source code is downloaded and compiled locally, users can trust that the resulting executable was not tampered with and directly reflects the source.

• Customizable Build Instructions: Building from source provides flexibility to modify build instructions defined in the PKGBUILD. This allows users to customize compilation flags, optional dependencies, and other parameters, tailoring the build to their specific requirements.

Transparency and Community Trust

Arch Linux provides tools and practices that promote transparency and allow users to assess the credibility of AUR packages:

• User Votes and Maintainer Reputation: Users can evaluate packages based on votes, popularity, and maintainer activity. For example, examining the package information for spotify reveals community engagement:

  ❯ pikaur -Si spotify
  AUR Git URL     : https://aur.archlinux.org/spotify.git
  AUR Web URL     : https://aur.archlinux.org/packages/spotify
  Name            : spotify
  Version         : 1:1.2.47.364-1
  Description     : A proprietary music streaming service
  URL             : https://www.spotify.com
  Licenses        : custom
  Votes           : 171
  Popularity      : 9.882938
  

  A higher vote count and active maintenance suggest reliability and community trust.

• Inspectable PKGBUILD Scripts: Before installation, users can inspect the PKGBUILD files to verify the sources and actions of a package. This transparency ensures that the installation process is trustworthy and that all files are properly managed by the package manager.

Conclusion

By combining a secure build environment with transparent, community-driven practices, Arch Linux ensures that its package management system is both secure and trustworthy. Users have the tools and information needed to make informed decisions about the software they install, maintaining control over their systems while benefiting from the extensive software availability provided by the AUR.

2.1.3 - Embracing Arch’s Unified Package Management Philosophy

Leveraging Arch’s Unified System

As established, users can generally assume that any desired software is available through Arch’s official repositories or the AUR. This comprehensive availability eliminates the need for non-native installation methods.

Single Package Manager Philosophy

1. Intentional Design Choice: Ditana deliberately avoids installing multiple package managers or wrappers like pamac, focusing instead on pacman and the AUR helper pikaur for a consistent experience.

2. Unified Updates and Maintenance: With all software managed through a single system, users can update the entire system—including AUR packages—with a single command (pikaur -Syu), simplifying maintenance and ensuring consistency.

3. Avoiding Fragmentation: By discouraging the use of non-native installation methods (e.g., Flatpak, Snap, AppImage, shell script installers), Ditana prevents fragmentation and potential conflicts, making system administration more straightforward.

2.1.4 - Comprehensive File Tracking: The Ditana Advantage

Ditana: Unified and Transparent File Tracking

In Ditana, determining the origin of any file on your system is straightforward and consistent. With a single command, you can identify which package owns a specific file:

pacman -Qo /path/to/your/file

For example:

❯ pacman -Qo /etc/group       
/etc/group is owned by ditana-filesystem 2024.04.07-22

This command provides immediate clarity about the package responsible for any given file, ensuring accountability and ease of maintenance.

Searching for Packages Containing Specific Files with pkgfile

The pkgfile utility allows you to search for packages containing specific files—even if those packages are not installed on your system. This is especially useful when you’re looking for a command or library that isn’t currently available locally.

For instance, to find which packages include the convert command:

❯ pkgfile convert
chaotic-aur/cheat
chaotic-aur/imagemagick-full-git
extra/bash-completion
extra/gstreamer-docs
extra/imagemagick

With pkgfile, you can quickly identify relevant packages without the need to manually search or download them.

Exclusive Use of pacman and AUR: Simplified File Tracking

Ditana exclusively utilizes pacman and the Arch User Repository (AUR) for package management. This unified approach ensures that all software installations are tracked consistently, eliminating the complexities associated with multiple package managers and installation methods.

Single Package Manager

By relying solely on pacman (including the AUR), Ditana offers a single, coherent system for managing all packages. This means that every file on your system is accounted for through pacman, simplifying the tracking process and enhancing system transparency.

Avoiding Multiple Installation Methods

Unlike many other systems that employ a mixture of package managers and installation methods—such as flatpak, snap, AppImage, and shell script installers—Ditana maintains a streamlined approach. By avoiding these diverse methods, Ditana eliminates the fragmentation and inconsistency that can complicate file tracking and system maintenance.

Consistent Tracking Commands

With Ditana’s exclusive use of pacman, identifying the origin of any file is always done through the same set of commands. This consistency reduces the learning curve for users and ensures that system maintenance is straightforward.

• Determine Package Ownership:

  pacman -Qo /path/to/your/file
  

• Search for Packages Containing Specific Files:

  pkgfile <filename>
  

Enhanced System Integrity

Using a unified package management system like pacman and the AUR ensures that all installed software is tracked uniformly. This enhances system integrity by making it easier to audit installed packages, manage dependencies, and perform clean upgrades or removals.

Simplified Troubleshooting

When issues arise, Ditana’s consistent file tracking allows for quicker identification of problematic packages. Since all software is managed through pacman and the AUR, users can rely on familiar tools and commands to diagnose and resolve issues efficiently.

The Alternative: A Fragmented Package Management Landscape

In many Linux distributions, users navigate a complex ecosystem of multiple package managers and installation methods. Common alternatives include:

• Native Package Managers: Such as apt for Debian-based systems or dnf for Fedora.
• Flatpak: A system for building, distributing, and running sandboxed desktop applications.
• Snap: A package management system that allows for the installation of self-contained applications.
• AppImage: Portable applications that run without installation.
• Shell Script Installers: Custom scripts that install software, often requiring sudo privileges.

This mixture introduces several challenges:

• Fragmented Tracking: Each package manager and installation method maintains its own database, making it difficult to track the origin of files consistently.
• Inconsistent Commands: Users must learn and use different commands for each system to manage and query packages.
• Increased Complexity: Managing updates, dependencies, and troubleshooting becomes more time-consuming and error-prone due to the lack of a unified approach.

If sandboxing is required, there is no need to utilize an alternative package management system. Ditana advocates for a unified package management approach using pacman and the Arch User Repository (AUR), which offers numerous advantages over solutions that intertwine sandboxing with package management, such as Snap and Flatpak. While AppImage primarily focuses on application portability without built-in sandboxing, our approach allows for greater flexibility and control by separating package management from security measures. This distinction reduces the necessity for self-contained packages, especially on rolling release distributions like Arch Linux, as further detailed in Reduced Need for Self-Contained Packages. For effective sandboxing within our ecosystem, we recommend Bubblejail, which is installed by default.

Conclusion

Ditana’s unified and transparent file tracking system, powered exclusively by pacman and the AUR, provides clear advantages in maintaining system integrity and simplifying troubleshooting. By avoiding the fragmentation associated with multiple package managers and installation methods, Ditana ensures that all software installations are consistently tracked, making system maintenance more efficient and reliable.

2.1.5 - The Confinement Dilemma: Why Snap & Similar Solutions Aren’t Always Ideal

The Fragmented Package Management Landscape

Snap, flappak, AppImage and sh-installers contribute to a hybrid package management experience. For example, most Ubuntu systems still heavily rely on dpkg/apt, while Snap tries to confine certain apps. Consequently, users must navigate different package management paradigms. The often touted division of «system packages» (via dpkg/apt) vs. «application packages» (via Snap) is rarely clear-cut in practice and does not always meet security requirements.

The end result is a system that provides neither the promised security advantages nor a consistent user experience. Because the notion of a fully confined package ecosystem remains distant, users end up juggling multiple package managers with the associated confusion and overhead.

Arch Linux and Ditana: A Unified Approach

In contrast, Ditana pursues a deliberately unified package management strategy. As outlined in Embracing Arch’s Unified Package Management Philosophy, Ditana maintains a single, cleanly structured system, rather than mixing multiple technologies. This philosophy, closely aligned with the Rolling Release Model, results in a transparent update and maintenance process with minimal fragmentation.

While relying on one package manager alone does not automatically provide app confinement, it offers a simpler, more navigable environment that can be secured with tools like Bubblejail. Instead of distributing multiple overlapping isolation methods, Ditana recommends Bubblejail for scenarios requiring true separation.

Bubblejail: Effective Isolation Without System Fragmentation

Rather than adopting numerous package managers with inconsistent sandboxing features, Ditana installs Bubblejail by default to provide real isolation when needed. Built on bubblewrap, Bubblejail introduces an orderly approach to running applications in separate «instances.» Each instance has its own home directory and a services.toml that outlines which system resources may be accessed.

• Clear Separation: Instead of running unsandboxed apps accidentally, each application operates within its own environment, reducing the chance of misconfiguration.
• Granular Profiles: Reusable profiles let you quickly apply recurring service configurations (e.g., network access, audio).
• Consistent Control: Rights must be granted explicitly, strengthening the principle of least privilege.

Compared to AppImage, Flatpak, Snap, or shell installers, the deliberate combination of Arch’s unified package management with a dedicated sandboxing solution like Bubblejail keeps the system both clean and easy to maintain.

Conclusion

Ditana follows the philosophy of sticking to one package manager, thus avoiding solutions like Flatpak, Snap, AppImage and sh-installers. For applications that truly need segregation, Bubblejail offers a concise, trackable alternative. By focusing on a lean yet secure distribution, Ditana demonstrates how a single-package-manager model—augmented with powerful sandboxing when necessary—promotes clarity, stability, and security.

To learn more about the reasoning behind a unified package management approach, see Embracing Arch’s Unified Package Management Philosophy.

2.1.6 - Questioning the Myth of Stability in Traditional Release Cycles

Questioning the Myth of Stability in Traditional Release Cycles

A frequently cited reason to avoid rolling-release distributions such as Arch Linux (and by extension Ditana) is the assumption that traditional, fixed-release distributions ensure superior stability—especially in server environments. However, this belief often overlooks several key nuances:

1. Misinterpreting Package Issues vs. Truly “Broken” Packages
   Under Arch-based systems, certain package-related problems—often caused by neglecting to update the entire system prior to installing new software—can mistakenly be seen as outright “broken” packages in the repository.
   Ditana provides the addpkg alias, which automatically performs a system upgrade before installing new software. This approach addresses many issues that might otherwise be labeled “instability.” You can find more details and best practices in Best Practices with Software Installations.

2. Dependency Conflicts Also Exist in Traditional Release Cycles
   It is a misconception that fixed-release distributions (e.g., Ubuntu) never encounter dependency conflicts. In fact, because they lock certain package versions for a given release, users sometimes resort to snap or flatpak packages, or even maintain multiple versions of the same software. These workarounds can introduce the same complexity or confusion that rolling-release distributions supposedly have.

3. Driver and Kernel Issues Are Not Exclusive to Rolling-Release
   Conflicts involving kernel modules, drivers, or hardware support can arise in Ubuntu and similar distributions too. Ditana’s reliance on DKMS drivers (for NVIDIA, ZFS, etc.) and preference for LTS kernels is a design choice independent of whether the underlying system is rolling-release. In other words, these driver-related challenges can crop up anywhere.

4. Software Vendors Conduct Their Own Rigorous Testing
   Rolling-release distributions do not simply push untested code to end users. In most cases, the primary testing responsibility lies with the original software vendors, who typically run extensive validation before releasing their products. This is illustrated by projects like the Boost Library, which has a robust testing framework of its own. The distribution maintainers then apply any necessary patches or adjustments before pushing packages to the repository.

5. Psychological vs. Factual Concerns
   Much of the skepticism around rolling-release distributions stems from a nebulous sense of insecurity rather than documented issues. Our List of Actual Incidents provides a factual overview of serious breakdowns in various rolling-release distributions. It’s worth reviewing which of these incidents, if any, would truly affect your specific workflow or environment.

How Ditana Addresses Rolling-Release Concerns

Ditana mitigates the risks associated with rolling-release distributions by creating automatic system snapshots before each update.

• On Btrfs, XFS, and EXT4, Ditana uses Timeshift for snapshots.
• On ZFS, Ditana employs a custom-developed tool.

If a serious problem emerges after an update, simply revert to a snapshot and hold off until the software vendors provide a fix. Under ZFS, reverting is particularly straightforward: a full reboot isn’t even required. For a detailed guide on this process, see Automatic System Snapshots.

Ultimately, while fixed-release distributions may provide a comfort factor for certain use cases, rolling-release alternatives like Ditana can offer more immediate access to new software features and security patches—without compromising on reliability, as long as best practices are observed. If you remain skeptical, weigh the actual risks against the potential benefits and decide based on your specific environment and requirements.

2.1.6.1 - Boost Library Example: Timely Updates and API Stability

Boost Library Example: Timely Updates and API Stability

The Boost library releases new versions approximately every four months. In contrast, Ubuntu Long-Term Support (LTS) versions are released every 24 months. This significant difference in release cycles means that an Ubuntu LTS system can lag behind Boost’s latest releases by up to 24 months, with an average delay of about 12 months.

This delay isn’t just about missing out on new features; it also means missing critical bug fixes and security patches included in newer Boost versions. Open-source projects that depend on Boost benefit from these updates when built on rolling-release distributions like Arch Linux. By compiling projects with the most recent Boost versions, Arch ensures that users and developers have access to the most secure and efficient software available.

API Stability Through Comprehensive Testing

Boost conducts extensive regression testing for each release across numerous compiler versions and platforms, as documented on their regression testing summary page. These rigorous tests not only ensure the functionality of the library but also inherently validate the stability of its API. This means that the API remains consistent and reliable across versions, and any issues are identified and resolved by the Boost developers themselves.

Therefore, the internal release testing performed by traditional distributions like Ubuntu is unlikely to surpass the comprehensive testing already conducted by the Boost developers. Given the breadth and depth of Boost’s own quality assurance processes, additional testing by distributors may not significantly enhance stability. The API stability ensured by Boost’s regression tests means that developers can confidently upgrade to the latest versions without fearing breaking changes.

Minimizing Compatibility Issues

The concern about ABI (Application Binary Interface) compatibility primarily affects projects distributed in binary form. However, such projects typically link against Boost statically rather than dynamically, rendering ABI compatibility less of an issue. By keeping libraries like Boost up to date, rolling-release distributions minimize compatibility problems that can arise from outdated software.

This example highlights how rolling-release models can provide timely access to essential improvements and fixes without compromising stability. By closely following upstream developments and leveraging the rigorous testing performed by projects like Boost, distributions like Arch Linux ensure that both developers and users benefit from the latest advancements in software, all while maintaining a stable and secure environment.

2.1.6.2 - Incidents with rolling release distributions

This list may be incomplete. Please let us know if you are aware of further incidents.

2011–2012: Early Adoption of GNOME 3 and Incompatibilities

Start of Disruption: April 6, 2011

Duration of Disruption: Approximately 6 months

Early Adoption of GNOME 3 and Incompatibilities

Description:

Arch Linux and other rolling release distributions adopted GNOME 3 immediately upon its release. This led to significant compatibility issues and incomplete extensions, as many applications and GNOME extensions were not yet prepared for GNOME 3. Users experienced instability and a lack of functionality, while Ubuntu LTS continued to provide a stable desktop experience with GNOME 2.

Categorization: (2) The incident did not affect Ubuntu because their release cycles lagged long enough until the problem was noticed and resolved by rolling release distributions.

Measures Taken:

• Upstream Developers: GNOME developers released updates to improve compatibility and stability, accelerating the development of GNOME Shell extensions and application support.

• Arch Community: Increased communication about potential issues with major desktop environment upgrades, advising users to review release notes and consider the implications before updating.

2012: Kernel 3.5 and Network Driver Issues

Start of Disruption: July 21, 2012

Duration of Disruption: Approximately 4–5 weeks

Linux Kernel 3.5 Network Driver Issues

Description:

The release of Linux Kernel 3.5 introduced changes to network drivers, causing network interruptions and compatibility problems with certain older WLAN cards in rolling release distributions like Arch Linux. Users experienced dropped connections and unreliable network performance until patches were released.

Categorization: (2) The incident did not affect Ubuntu because their release cycles lagged long enough until the problem was noticed and resolved by rolling release distributions.

Measures Taken:

• Upstream Developers: Released patches to address driver compatibility issues in subsequent kernel updates.

• Arch Community: Advised users on how to downgrade to previous kernel versions if necessary and increased testing of kernel updates with a variety of hardware configurations.

2012–2013: Systemd Adoption and Transition Issues

Start of Disruption: Late 2012

Duration of Disruption: Several months

Systemd Adoption and Transition Issues

Description:

Arch Linux transitioned early to systemd as its init system, leading to significant problems with init services and network tools that were not fully compatible. Users faced inconsistencies and errors over several months until systemd became more stable and compatible with existing services. Ubuntu LTS continued using the Upstart init system, avoiding these issues.

Categorization: (2) The incident did not affect Ubuntu because their release cycles lagged long enough until the problem was noticed and resolved by rolling release distributions.

Measures Taken:

• Upstream Developers: Continued to develop systemd for better compatibility and stability.

• Arch Community: Provided detailed migration guides and support to help users transition to systemd, and improved documentation on handling init service issues.

2013: Early Adoption of MySQL 5.6 Leading to Incompatibilities

Start of Disruption: February 2013

Duration of Disruption: Approximately 2 months

MySQL 5.6 Incompatibilities

Description:

Rolling release distributions like Arch Linux adopted MySQL 5.6 soon after its release, which led to incompatibilities and performance issues in web applications expecting MySQL 5.5. This resulted in stability problems and crashes, particularly with older plugins or CMS systems. Ubuntu LTS remained on the stable 5.5 version, and users did not encounter these issues.

Categorization: (2) The incident did not affect Ubuntu because their release cycles lagged long enough until the problem was noticed and resolved by rolling release distributions.

Measures Taken:

• Upstream Developers: Released updates to MySQL 5.6 to improve compatibility and performance.

• Arch Community: Offered guidance on downgrading to MySQL 5.5 or applying patches, and increased testing of major database updates for compatibility with popular web applications.

2013: PulseAudio 4.0 Causing Audio Issues

Start of Disruption: May 6, 2013

Duration of Disruption: Approximately 3–4 weeks

PulseAudio 4.0 Audio Problems

Description:

The release of PulseAudio 4.0 introduced changes that caused audio problems on Arch Linux and other rolling release distributions, especially with certain applications and Bluetooth devices. Users experienced audio dropouts and device connectivity issues until a stabilizing update was released. Ubuntu LTS users, on older PulseAudio versions, did not face these problems.

Categorization: (2) The incident did not affect Ubuntu because their release cycles lagged long enough until the problem was noticed and resolved by rolling release distributions.

Measures Taken:

• Upstream Developers: Issued updates to address the compatibility and stability issues in PulseAudio.

• Arch Community: Provided temporary workarounds and increased scrutiny of audio subsystem updates, encouraging users to report issues promptly.

2014: Early Adoption of OpenSSL 1.0.1 and Heartbleed Vulnerability

Start of Disruption: April 7, 2014

Duration of Disruption: Approximately 1 week

Heartbleed Vulnerability in OpenSSL

Description:

Rolling release distributions implemented OpenSSL 1.0.1 quickly, making them more susceptible to the Heartbleed vulnerability when it was discovered. Users had to apply workarounds until a patch was released. Ubuntu LTS was using an earlier, unaffected version of OpenSSL and was less impacted.

Categorization: (2) The incident did not affect Ubuntu because their release cycles lagged long enough until the problem was noticed and resolved by rolling release distributions.

Measures Taken:

• Upstream Developers: Released OpenSSL 1.0.1g to fix the vulnerability.

• Arch Community: Promptly updated the OpenSSL package and communicated the importance of immediate patching, emphasizing security update practices.

2014: OpenSSH 6.7 Causing SFTP Issues

Start of Disruption: October 6, 2014

Duration of Disruption: Approximately 2 weeks

OpenSSH 6.7 SFTP Problems

Description:

The release of OpenSSH 6.7 led to problems with SFTP on rolling release distributions like Arch Linux, causing decreased transfer stability and speed. Ubuntu LTS users remained on older, stable versions without these issues.

Categorization: (2) The incident did not affect Ubuntu because their release cycles lagged long enough until the problem was noticed and resolved by rolling release distributions.

Measures Taken:

• Upstream Developers: Addressed the issues in subsequent OpenSSH releases.

• Arch Community: Advised users on downgrading or applying patches, and increased testing of critical network tools before rolling them out.

2014–2015: Early Adoption of KDE Plasma 5 Leading to Stability Issues

Start of Disruption: July 15, 2014

Duration of Disruption: Approximately 4–5 months

KDE Plasma 5 Stability Issues

Description:

Rolling release distributions like Arch Linux adopted KDE Plasma 5 early, resulting in instability and incompatibility with many KDE applications still developed for KDE 4. Users faced crashes and inconsistent behavior until applications were updated and Plasma became more stable. Ubuntu LTS stayed with KDE 4, providing a consistent user experience.

Categorization: (2) The incident did not affect Ubuntu because their release cycles lagged long enough until the problem was noticed and resolved by rolling release distributions.

Measures Taken:

• Upstream Developers: Worked on porting applications to KDE Frameworks 5 and improving Plasma stability.

• Arch Community: Offered both KDE 4 and Plasma 5 packages to allow users to choose, and provided guidance on potential issues with early adoption.

2015: XFCE 4.12 Update Causing Panel Crashes

Start of Disruption: February 28, 2015

Duration of Disruption: Approximately 3 weeks

XFCE 4.12 Panel Crash Issues

Description:

The update to XFCE 4.12 introduced new features but caused panel crashes on rolling release distributions like Arch Linux, especially when using specific plugins. Ubuntu LTS continued to use XFCE 4.10, ensuring a stable desktop experience.

Categorization: (2) The incident did not affect Ubuntu because their release cycles lagged long enough until the problem was noticed and resolved by rolling release distributions.

Measures Taken:

• Upstream Developers: Released patches to fix the panel crashes in subsequent updates.

• Arch Community: Advised users on troubleshooting and temporarily disabling problematic plugins, and emphasized the importance of community feedback for quick resolution.

2015: GRUB 2.02 Causing Boot Problems

Start of Disruption: December 25, 2015

Duration of Disruption: Approximately 1–2 weeks

GRUB 2.02 Boot Issues

Description:

An early version of GRUB 2.02 caused boot problems on Arch Linux and other rolling release distributions, particularly on dual-boot systems. Users often had to manually intervene to keep their systems bootable. Ubuntu LTS used a stable GRUB version and was unaffected.

Categorization: (2) The incident did not affect Ubuntu because their release cycles lagged long enough until the problem was noticed and resolved by rolling release distributions.

Measures Taken:

• Upstream Developers: Addressed the boot issues in subsequent GRUB releases.

• Arch Community: Provided instructions for manual fixes and increased testing of bootloader updates, recognizing the critical nature of boot components.

2016: Early Adoption of Wayland in Fedora 25 (Not Ubuntu LTS)

Start of Disruption: November 22, 2016

Duration of Disruption: Several months

Wayland Adoption Issues

Description:

Distributions like Fedora adopted Wayland as the default display server early on, leading to compatibility issues with certain applications that did not yet support Wayland. Problems persisted for several months until software compatibility improved. Applications like GIMP only officially stabilized Wayland support around 2020. Ubuntu LTS continued using the X.Org Server, avoiding these issues.

Categorization: (2) The incident did not affect Ubuntu because their release cycles lagged long enough until the problem was noticed and resolved by other distributions.

Measures Taken:

• Upstream Developers: Worked on adding Wayland support to applications and toolkits.

• Fedora and Arch Communities: Provided options to use X.Org Server as a fallback and assisted users in troubleshooting Wayland-related issues.

2016: LibreOffice 5.1 Bugs on Rolling Releases

Start of Disruption: February 10, 2016

Duration of Disruption: Approximately 3–4 weeks

LibreOffice 5.1 Bugs

Description:

LibreOffice 5.1 introduced bugs affecting stability and functionality on rolling release distributions. Users experienced crashes and data loss until bug fixes were implemented in later versions. Ubuntu LTS, using an earlier LibreOffice version, did not encounter these problems.

Categorization: (1) The incident did not affect Ubuntu because Ubuntu conducted integration tests that prevented the update to the new version.

Measures Taken:

• Upstream Developers: Released updates to fix critical bugs.

• Arch Community: Encouraged users to report issues and consider using the previous stable version until fixes were available.

2018: systemd 239 Bug in Arch Linux

Start of Disruption: July 3, 2018

Duration of Disruption: Approximately 2 weeks

systemd 239 Bug

Description:

A bug in systemd version 239 caused boot and service management issues on Arch Linux. Users encountered failed boots and service crashes until an update was released. Ubuntu LTS was on an earlier systemd version and did not experience these problems.

Categorization: (2) The incident did not affect Ubuntu because their release cycles lagged long enough until the problem was noticed and resolved by rolling release distributions.

Measures Taken:

• Upstream Developers: Fixed the bug in a subsequent systemd release.

• Arch Community: Provided instructions for downgrading systemd and increased testing for critical system components.

2018: Python 3.7 Compatibility Problems

Start of Disruption: June 27, 2018

Duration of Disruption: Approximately 2–3 months

Python 3.7 Compatibility Issues

Description:

The release of Python 3.7 led to compatibility problems with several packages in rolling release distributions, as many libraries and applications were not yet updated to support the new version. Users faced broken dependencies and functionality until updates were made.

Categorization: (2) The incident did not affect Ubuntu because their release cycles lagged long enough until the problem was noticed and resolved by rolling release distributions.

Measures Taken:

• Upstream Developers: Updated libraries and applications for Python 3.7 compatibility.

• Arch Community: Maintained multiple Python versions in the repositories and assisted users with virtual environments and package updates.

2019: NVIDIA Driver Updates and Kernel Compatibility Issues

Start of Disruption: September 2019

Duration of Disruption: Approximately 1 month

NVIDIA Driver and Linux Kernel Compatibility

Description:

An update to the Linux kernel in rolling release distributions led to incompatibility with existing NVIDIA drivers, causing graphical issues and system instability. Users had to wait for updated drivers from NVIDIA to resolve the problem. Ubuntu LTS, with an older kernel, did not face this issue.

Categorization: (1) The incident did not affect Ubuntu because Ubuntu conducted integration tests that prevented the update to the new version.

Measures Taken:

• NVIDIA: Released updated drivers compatible with the new kernel.

• Arch Community: Advised users on holding back kernel updates or using alternative drivers, and improved communication regarding proprietary driver dependencies.

2020: Mesa 20.0 Causing Crashes on Intel Graphics

Start of Disruption: March 2020

Duration of Disruption: Approximately 2–3 weeks

Mesa 20.0 Intel Graphics Issues

Description:

A faulty version of Mesa 20.0 led to crashes and graphical glitches on systems with Intel graphics in rolling release distributions like Arch Linux. Users experienced instability until a patched version was released. Ubuntu LTS was using an earlier Mesa version and remained stable.

Categorization: (2) The incident did not affect Ubuntu because their release cycles lagged long enough until the problem was noticed and resolved by rolling release distributions.

Measures Taken:

• Upstream Developers: Fixed the issues in subsequent Mesa releases.

• Arch Community: Provided instructions for downgrading Mesa and increased testing of graphics stack updates.

2021: Krita 4.4.2 Graphics Problems on Rolling Releases

Start of Disruption: February 2021

Duration of Disruption: Approximately 2 weeks

Krita 4.4.2 Graphics Issues

Description:

Users of rolling release distributions experienced graphics problems and crashes with Krita 4.4.2 due to compatibility issues with underlying libraries. The problems were resolved in the next version. Ubuntu LTS users, on a previous Krita version, did not face these issues.

Categorization: (1) The incident did not affect Ubuntu because Ubuntu conducted integration tests that prevented the update to the new version.

Measures Taken:

• Upstream Developers: Released Krita 4.4.3 with bug fixes.

• Arch Community: Advised users to temporarily use the previous version and improved monitoring of application stability upon updates.

2021: MariaDB 10.5 Causing Data Structure Changes on Arch

Start of Disruption: Mid-2021

Duration of Disruption: Over 1 month

MariaDB 10.5 Upgrade Issues

Description:

The upgrade to MariaDB 10.5 in Arch Linux led to undocumented changes in database structures, causing issues with plugins and dependencies. Users faced compatibility problems until documentation improved and necessary adaptations were made. Ubuntu LTS users, on an older MariaDB version, did not experience these issues.

Categorization: (1) The incident did not affect Ubuntu because Ubuntu conducted integration tests that prevented the update to the new version.

Measures Taken:

• Upstream Developers: Enhanced documentation and provided migration guides.

• Arch Community: Communicated the importance of reading release notes for major updates and offered support for troubleshooting database issues.

2021: GRUB 2.06 Causing Severe Boot Problems

Start of Disruption: June 2021

Duration of Disruption: Approximately 1 week

GRUB 2.06 Boot Issues

Description:

An update to GRUB 2.06 caused severe boot problems on Arch Linux, rendering some systems unbootable. Users had to perform manual repairs to restore system functionality. Ubuntu LTS, using a stable GRUB version, was unaffected.

Categorization: (1) The incident did not affect Ubuntu because Ubuntu conducted integration tests that prevented the update to the new version.

Measures Taken:

• Upstream Developers: Released patches to fix the boot issues.

• Arch Community: Issued alerts to users, provided detailed recovery instructions, and reinforced the critical nature of bootloader testing.

2021: PHP 8 Upgrade and Plugin Incompatibilities

Start of Disruption: November 2020 (PHP 8.0 release), issues persisted into 2021

Duration of Disruption: Approximately 1–2 months

PHP 8 Upgrade Issues

Description:

Arch Linux adopted PHP 8 soon after its release, leading to incompatibilities with many plugins and extensions for platforms like WordPress and Drupal. Users experienced broken websites and functionality until plugins were updated for PHP 8 compatibility. Ubuntu LTS continued using PHP 7.x, avoiding these issues.

Categorization: (2) The incident did not affect Ubuntu because their release cycles lagged long enough until the problem was noticed and resolved by rolling release distributions.

Measures Taken:

• Upstream Developers: Updated plugins and extensions to support PHP 8.

• Arch Community: Advised users to maintain PHP 7.x if necessary and provided guidance on managing multiple PHP versions.

2022: PipeWire and Audio Compatibility Issues

Start of Disruption: Early 2022

Duration of Disruption: Approximately 1 month

PipeWire Audio Issues

Description:

Rolling release distributions like Arch Linux adopted PipeWire as the default audio server, leading to compatibility issues with certain applications and hardware that were not yet fully supported. Users experienced audio dropouts and configuration difficulties. Ubuntu LTS continued using PulseAudio, avoiding these problems.

Categorization: (2) The incident did not affect Ubuntu because their release cycles lagged long enough until the problem was noticed and resolved by rolling release distributions.

Measures Taken:

• Upstream Developers: Continued improving PipeWire’s compatibility and stability.

• Arch Community: Provided fallback options to PulseAudio and assisted users in configuring PipeWire, emphasizing community feedback to address issues.

2023: OpenSSL 3.0 Migration Issues

Start of Disruption: Early 2023

Duration of Disruption: Approximately 2 months

OpenSSL 3.0 Migration Issues

Description:

The transition to OpenSSL 3.0 in rolling release distributions caused compatibility problems with applications not yet updated to work with the new version. Users faced broken packages and security tools until applications were patched. Ubuntu LTS remained on OpenSSL 1.1, maintaining stability.

Categorization: (2) The incident did not affect Ubuntu because their release cycles lagged long enough until the problem was noticed and resolved by rolling release distributions.

Measures Taken:

• Upstream Developers: Updated applications and libraries for OpenSSL 3.0 compatibility.

• Arch Community: Helped users identify affected applications and provided instructions for installing compatibility libraries.

2.1.7 - Rolling Release Model Minimizes the Need for AppImage

Always Up-to-Date Software

In many Linux distributions, software packages can become outdated between release cycles, prompting users to seek newer versions through formats like AppImage. Arch Linux addresses this by providing timely updates directly through its official repositories and the Arch User Repository (AUR). This means you can install the most recent software without waiting for the next distribution release or relying on external packages.

Seamless System Updates

When installing software on Arch Linux, it is recommended to perform a full system upgrade (pacman -Syu <package>) rather than installing only the specific package you desire. This practice ensures that all package versions remain synchronized, particularly concerning inter-package dependencies.

Viewed from another perspective, installing a single package without a full system upgrade can lead to partial upgrades. Since other packages are likely to have been updated since the last system update, the dependency tree of the newly installed package may require these updated packages. Relying on partial upgrades is precarious and unsupported by Arch Linux, as outlined in the System Maintenance guidelines.

While this approach may seem unconventional to users of other distributions, it guarantees that every component of your system remains compatible and up to date. Regular system updates reduce the risk of conflicts and make system maintenance more predictable and manageable. By embracing frequent updates, you maintain a secure and efficient system, adhering to the philosophy of “better early and often than later.”

Integrated Package Management

Arch Linux’s robust package management system offers several benefits over using standalone application formats:

• Dependency Handling: pacman automatically manages dependencies, ensuring all necessary libraries are present and compatible.
• System Consistency: Applications installed via the package manager integrate seamlessly with the system’s directory structure and configurations.
• Simplified Maintenance: Updates and installations are centralized, making it easier to keep track of software versions and security patches.

Reduced Need for Self-Contained Packages

Common Use of Non-Native Installation Methods: Accessing Newer Software Versions

Non-native installation methods like AppImage, Snap, Flatpak, and shell script installers are designed to run across various Linux distributions by bundling all necessary dependencies with the application. This approach is particularly beneficial for systems with outdated libraries or slower update cycles, where users seek newer software versions not yet available in their distribution’s repositories.

In Debian-based distributions, non-native installation methods are commonly used to include additional software, such as proprietary applications, or to access newer versions of software that are not or not yet available in the official repositories. This reliance arises from the stable release model of Debian-based systems. As a result, users often turn to these alternative packaging formats.

However, on a rolling release system like Arch Linux, where libraries and dependencies are frequently updated, the need for such self-contained packages is significantly reduced. Arch packages are typically updated within a few days after the provider releases a new version, ensuring that users have timely access to the latest software without relying on external package formats. This not only maintains system consistency and integrity but also simplifies software management by relying solely on the native package management system.

Less Common Use of Non-Native Installation Methods: Providing Older Software Versions

Leveraging /opt for Application-Specific Dependencies

In Linux systems, the /opt directory is designated for the installation of add-on application software packages. According to the Filesystem Hierarchy Standard (FHS), /opt is intended for software packages that are not part of the default installation and are self-contained. This allows for a clean separation between the core system files and third-party applications, facilitating easier maintenance and organization.

The Example of CLion in Arch Linux

Arch Linux utilizes the /opt directory to handle applications that require specific versions of dependencies, which might differ from the system-wide versions. An example is JetBrains CLion, an integrated development environment that relies on specific versions of certain tools, such as CMake, due to deep integration of version-specific features. As a result, CLion’s tool dependencies are often intentionally kept behind the latest releases to ensure compatibility. Below are excerpts from the Arch Linux PKGBUILD script for CLion:

package_clion-jre() {
    pkgdesc="JetBrains custom Java Runtime for CLion (Recommended)"
    url="https://github.com/JetBrains/JetBrainsRuntime"
    install -d -m755 "${pkgdir}/opt/${pkgbase}"
    rsync -rtl "${srcdir}/opt/${pkgbase}/jbr" "${pkgdir}/opt/${pkgbase}"
}

package_clion-cmake() {
    pkgdesc="JetBrains packaged CMake tools for CLion"
    install -d -m755 "${pkgdir}/opt/${pkgbase}/bin"
    rsync -rtl "${srcdir}/opt/${pkgbase}/bin/cmake" "${pkgdir}/opt/${pkgbase}/bin"
}

In these functions, specific versions of the Java Runtime Environment (JRE) and CMake tools are installed into /opt/clion, ensuring that CLion has access to the exact versions it requires. This method prevents potential conflicts with newer system-wide versions that may not be fully compatible with CLion.

Maintaining System Integrity with Arch’s Package Management

By installing application-specific dependencies in /opt, Arch Linux maintains system integrity while providing applications with the necessary environment to function correctly. This approach allows applications that lag in supporting newer versions of dependencies to continue functioning without forcing the entire system to downgrade or relying on alternative packaging formats like AppImage, Snap, or Flatpak.

This strategy aligns with the philosophy of using a unified package management system, reducing the need for multiple package managers and preventing fragmentation and potential conflicts. As explained in the section Embracing Arch’s Unified Package Management Philosophy:

“By discouraging the use of non-native installation methods (e.g., Flatpak, Snap, AppImage, shell script installers), Ditana prevents fragmentation and potential conflicts, making system administration more straightforward.”

Benefits of Using /opt for Dependency Management

• Isolation of Dependencies: Storing application-specific versions in /opt keeps them separate from system-wide libraries, minimizing the risk of version conflicts.
• Compliance with Standards: Utilizing /opt adheres to the FHS, promoting consistency and predictability in system architecture.
• Standardized Update Mechanism: There is no need to use a non-native installation method like AppImage to deploy specific older versions of dependencies. The consistent use of /opt for this case has the advantage of using the standard package system, which avoids fragmentation of the file system with different package systems and allows tracking of file associations with packages with a standardized method.
• Enhanced Compatibility: Applications that require older versions of dependencies can function correctly without impacting the rest of the system.

Summary on Providing Older Software Versions

Leveraging the /opt directory for managing application-specific dependencies exemplifies how Arch Linux addresses compatibility challenges within its rolling release model, particularly to provide older software versions that are used by a main package which is installed using the standard installation method (e.g., into /usr/bin). By utilizing the /opt directory appropriately, Arch Linux reduces the need for alternative packaging formats like AppImage, Snap, Flatpak, or shell script installers, which can introduce redundancy and potential conflicts.

This approach not only supports the seamless operation of software like CLion but also aligns with Ditana’s commitment to a unified package management philosophy. By relying exclusively on Arch’s native package management system, Ditana benefits from Arch Linux’s strategies for maintaining system integrity and reducing dependency conflicts without resorting to multiple package managers.

Conclusion

Arch Linux’s commitment to providing the latest software through its rolling release model and comprehensive package management system minimizes the need for alternative application formats like AppImage. By keeping your system regularly updated, you enjoy the benefits of the newest features and improvements within a cohesive and well-integrated environment. While AppImage can be useful in certain scenarios, the seamless integration and up-to-date nature of Arch Linux make it less necessary. This approach not only enhances your user experience but also simplifies system administration, making Arch Linux a compelling choice for those who value cutting-edge software and efficient package management.

2.1.8 - Final Thoughts

By leveraging Arch’s comprehensive software availability, Ditana eliminates the need for non-native installation methods. This focused approach ensures a clean, efficient, and easily maintainable system, ideal for users who value control, transparency, and simplicity in their Linux experience.

By consciously avoiding the trend of supporting multiple package managers, Ditana maintains a clean, efficient, and easily maintainable system. This focused approach, combined with tools like pacui, ensures that users have all the power and flexibility they need without the drawbacks of system fragmentation or conflicting package management systems.

Ditana stands out by fully utilizing the strengths of Arch Linux, offering a sophisticated yet streamlined experience. This philosophy not only simplifies system administration but also provides a coherent and reliable computing environment, catering to both experienced Linux users and those looking to deepen their understanding of system management.

2.2 - Why Raku?

Introduction

Raku serves as the foundational programming language for Ditana’s installation and configuration system. This choice was made after careful consideration of the unique requirements of a modern Linux distribution installer that needs to handle complex system configurations while maintaining code clarity and maintainability.

Raku in Ditana

The Ditana installer is driven by a comprehensive settings.json configuration file that contains all dialog definitions and system properties. What makes this approach particularly powerful is the ability to embed Raku code directly within the JSON structure. This allows for dynamic evaluation of system properties and sophisticated dependency management. For example:

{
    "name": "uefi",
    "detect": "'/sys/firmware/efi'.IO.d"
},
{
    "name": "avx2-available",
    "detect": "'/proc/cpuinfo'.IO.lines.first(*.contains('flags')).contains('avx2').so"
}

The embedded Raku expressions are evaluated at runtime, enabling dynamic system detection and configuration. More complex scenarios, such as managing dependencies between settings, are handled elegantly:

{
    "name": "kernel-option-wmsca",
    "dialog-name": "General Kernel Configuration",
    "short-description": "Maintain free memory (vm.watermark_scale_factor 10/3000 --> 125/3000)",
    "long-description": "Maintain free memory: Make the Kernel Swap Thread more aggressive in maintaining free memory...",
    "spdx-identifiers": "GPL-2.0-only",
    "default-value": "`install-zram`"
}

Why Raku for System Tools?

Raku excels in system tool development for several reasons:

1. Shell-like Power: Raku provides bash-like capabilities for system interaction but within a modern programming language framework.

2. Process Management: Superior handling of external processes and their output streams, crucial for system management tools.

3. Text Processing: Advanced string manipulation and pattern matching capabilities, essential for processing configuration files and system outputs.

4. Type Safety with Flexibility: Optional type checking provides safety where needed while maintaining flexibility for system-level operations.

5. Cross-platform Compatibility: Runs effectively on various hardware platforms, from Raspberry Pi to multi-processor systems.

6. Native Interface: Easy integration with existing system libraries through NativeCall, enabling direct interaction with system APIs.

These characteristics make Raku particularly suitable for system tools like the Ditana installer, where complex configuration management meets system-level operations.

Key Features of Raku

For a complete list of unique features, please refer to the official Raku FAQ. Here are the main aspects that make Raku an excellent choice for modern software development:

Programming Paradigm Flexibility

• Supports procedural, object-oriented, and functional programming methodologies
• Features powerful object orientation with classes and roles
• Everything can be treated as an object, supporting inheritance, subtyping, and efficient code reuse

Language Design

• Concise syntax enables shorter programs, and commonly used operations have shorter names for better readability.
• Supports hyphens and Unicode characters in identifiers
• Features rational numbers by default for precise numeric computation
• Implements both lazy and eager evaluation, supporting infinite sequences
• Offers enhanced regular expressions with named patterns
• Uses Junctions for elegant multiple-condition checking
• Maintains consistent syntax through invariable sigils

Modern Concurrency

• Provides react, whenever, and supply keywords for event-driven programming
• Supports implicit and explicit parallelism for multi-core systems
• Implements a high-level, composable concurrency model

System Integration and Performance

• Features extensible grammars for parsing
• Supports full Unicode including Annex #29
• Offers easy integration with C/C++ through NativeCall
• Provides seamless integration with Perl and Python modules via Inline::Perl5 and Inline::Python
• Includes garbage collection and phasers for resource management
• Features JIT optimization for hot code paths
• Supports introspection and metaprogramming

Comparison between Raku and other languages

For those interested in a comparison between Raku and other languages like Python, we recommend this insightful video:

Raku: The Programming Language You Didn’t Know You Needed

2.3 - Best practices

2.3.1 - Software Installations

Always perform a complete system upgrade when installing new software. While this may seem unconventional, partial upgrades are unsupported under Arch Linux. Installing software separately from the last system upgrade can lead to inconsistencies with dependent libraries on your system.

Graphical User Interface (GUI)

Installing Software

1. Click the Add/Remove Software button in the taskbar:

   

2. Select 1 Update System.

3. Then, choose 3 Install Packages.

4. Use the incremental search feature to quickly locate and install the desired software.

Updating the System

1. Double-click the blue arrow-shaped Kalu icon in the system tray:

   

2. Follow the on-screen instructions to proceed with the system updates.

Terminal

Installing Software

Utilize Ditana’s addpkg alias to install software. For example:

addpkg spotify

This command will install the specified software and perform an upgrade simultaneously. To uninstall software, use rmpkg, which ensures that no unused dependencies remain on your system.

If you are unsure of the exact package name, first upgrade your system using pikaur -Syu. Then use:

pikaur <package>

This command will offer installation candidates sorted by their vote count.

Updating the System

Execute the following command to update your system:

pikaur -Syu

2.3.2 - Automatic System Snapshots

Automatic system snapshots are configured independently of the chosen file system when the corresponding setting is enabled (see “Expert Settings” ⇒ “System Maintenance Tools” ⇒ “Configure Automatic System Snapshots”). These snapshots are created each time a complete system upgrade is performed. On ZFS and BTRFS filesystems, these snapshots are atomic, meaning they occur almost instantaneously and ensure a consistent state by capturing all files at the exact same point in time.

The initial snapshot is taken at the end of the installation process. Additionally, for XFS and EXT4 filesystems, this strategy offers the advantage that the first snapshot in a running system requires significantly less time (typically under 5 seconds), similar to subsequent snapshots.

Recovery Procedure

If your system fails to boot, you can recover by booting from the ISO, which provides access to a rescue system. Within this environment, you can use the commands below to restore a snapshot.

Note: As these are “system snapshots,” your home directory and other volumes remain unchanged. This allows you to restore a system snapshot without affecting your personal files.

Filesystem-Specific Instructions

ZFS

1. List Available Snapshots:

   zfs list -t snapshot
   

   Example output:

   ❯ zfs list -t snapshot 
   NAME                                                    USED  AVAIL  REFER  MOUNTPOINT
   ditana-root/ROOT/default@autosnap_2024-11-21_23-14-41   453K      -  3.96G  -
   ditana-root/ROOT/default@autosnap_2024-11-21_23-25-28   394K      -  3.96G  -
   ditana-root/ROOT/default@autosnap_2024-11-21_23-26-06  1.05M      -  3.96G  -
   

2. Restore a Snapshot:

   sudo zfs rollback <SNAPSHOT_NAME>
   

   Example:

   sudo zfs rollback ditana-root/ROOT/default@autosnap_2024-11-21_23-27-12
   

BTRFS, XFS, EXT4

Automatic snapshots are managed by the timeshift-autosnap package and do not require additional configuration via Timeshift. This package ensures that system snapshots are created automatically during each Arch Linux system upgrade.

1. List Available Snapshots:

   sudo timeshift --list
   

   Example output:

   > sudo timeshift --list
   Mounted '/dev/dm-0 (sda4)' at '/run/timeshift/195216/backup'
   Device : /dev/dm-0 (sda4)
   UUID : cca08543-da4e-44a0-839b-d20e6f258c9a
   Path : /run/timeshift/195216/backup
   Mode : RSYNC
   Status : OK
   1 snapshots, 14.2 GB free
   
   Num Name Tags Description
   --------------------------------------------------
   0 > 2024-12-21_18-04-37 0 after installation of Ditana GNU/Linux
   

2. Restore a Snapshot:

   sudo timeshift --restore --snapshot <SNAPSHOT_ID>
   

   Example:

   > sudo timeshift --restore --snapshot 2024-12-21_18-04-37
   Mounted '/dev/dm-0 (sda4)' at '/run/timeshift/208067/backup'
   
   **************************************************************************
   * To restore with default options, press the ENTER key for all prompts! *
   **************************************************************************
   
   Press ENTER to continue...
   
   Re-install GRUB2 bootloader? (recommended) (y/n): n
   

   Important Note 1

   Do not follow Timeshift’s recommendation to reinstall GRUB2, as Timeshift assumes an update-grub tool is available. If you need to update GRUB after restoration, execute:

   grub-mkconfig -o /boot/grub/grub.cfg
   

   Important Note 2

   Unlike ZFS snapshots, after restoring with Timeshift, you must run:

   sudo rm /var/lib/pacman/db.lck
   

   This ensures a consistent state. The necessity arises not from Timeshift itself, but from the sophisticated strategy employed by zfs-autosnap.

2.3.3 - Desktop

Window Resizing

XFCE offers an unconventional yet highly convenient and reliable method for resizing windows. Instead of dragging the window border, hold down the Alt key and right-click near the edge you wish to adjust.

Cheat Sheet

The Ditana Cheat Sheet provides numerous useful tips and is automatically overlaid on the desktop wallpaper. To display it, press Ctrl + Alt + D. Follow the on-screen instructions to customize it to your specific needs.

Ditana Assistant

The leftmost icon in the taskbar launches the Ditana Assistant. For detailed instructions on how to utilize it, please refer to the Ditana Assistant documentation.

Scaling

To adjust the font size, avoid using XFCE’s DPI scaling. Instead, use the font size settings:

DPI scaling is automatically managed by Ditana and precisely matches the connected primary display. If you switch displays, the scaling will update in real-time.

Software Installations and Updates

Kalu will notify you when system updates are available (indicated by the blue arrow-shaped icon in the system tray). Applying these updates is essential not only for new features and security but also for maintaining stability regarding package dependencies in Arch-based systems. For more information, please refer to Software Installations.

3 - The Installer

The following sub-sections describe selected components of the Ditana installer.

3.1 - Desktop Applications

This category is only available if you have chosen to install a desktop environment during the Ditana installation process. It provides a carefully curated selection of applications that enhance your desktop experience while maintaining system efficiency.

For specific configuration options and advanced features of each application, please refer to their respective documentation pages linked above.

Office and Productivity

LibreOffice

LibreOffice is a comprehensive open-source office suite (LGPL-3.0-or-later) that serves as a powerful alternative to proprietary office software. It includes:

• Writer for word processing
• Calc for spreadsheets
• Impress for presentations
• Draw for vector graphics
• Base for database management
• Math for formula editing

The appropriate language pack for your system will be automatically installed, ensuring a localized working environment. LibreOffice provides excellent file format compatibility, including Microsoft Office formats, and supports a wide range of extensions for additional functionality.

Betterbird

Betterbird (MPL-2) is an enhanced version of the Thunderbird email client that addresses various limitations of the original software. Key improvements include:

• Multi-line view for better email organization
• Vertical tabs for efficient workspace management
• Enhanced sorting options for better email management
• Improved search capabilities
• Various bug fixes and performance improvements

Like LibreOffice, Betterbird automatically includes the appropriate language pack for your system.

Back In Time

Back In Time (GPL) provides a user-friendly approach to system backups. Notable features:

• Snapshot-based backup system
• Easy restoration of previous file versions
• Automatic backup scheduling through cron integration
• Simple but powerful interface
• Support for multiple backup profiles

Document Management

PDF Arranger

PDF Arranger (GPL-3.0-or-later) is a versatile PDF manipulation tool that allows you to:

• Merge multiple PDF files
• Split PDFs into separate documents
• Rotate and crop pages
• Rearrange page order
• Extract specific pages
• Modify PDF metadata

Xournal++

Xournal++ (GPL-2.0-or-later) is a powerful application for digital note-taking and PDF annotation. It excels in:

• Stylus-based input for natural writing
• PDF annotation and form filling
• Freehand drawing and sketching
• Journal keeping with mixed text and drawings
• Layer-based editing
• Custom toolbar configurations

System Utilities

Etcher

Etcher (Apache) is a reliable imaging utility that provides:

• Safe OS image flashing to SD cards and USB drives
• Validation of written data
• Support for various image formats
• Clean, modern interface
• Cross-platform compatibility

Bitwarden

Bitwarden (GPL3) is a secure password management solution offering:

• Encrypted storage for passwords and sensitive information
• Browser integration
• Secure password generation
• Cross-platform synchronization
• Two-factor authentication support
• Secure sharing capabilities

NoMachine

NoMachine (Proprietary - NoMachine EULA) is a high-performance remote desktop solution featuring:

• NX technology for efficient remote connections
• Low-latency audio and video streaming
• USB device forwarding
• File transfer capabilities
• SSH encryption for secure connections
• Cross-platform support

ZapZap

ZapZap (GPL3) is an optimized WhatsApp desktop client that provides:

• Lower CPU usage compared to browser-based solutions
• Direct image pasting functionality
• Native desktop integration
• Improved performance for long chat sessions
• Regular updates and security patches

Variety

Variety (GPL3) is an advanced wallpaper manager offering:

• Automatic wallpaper downloading and rotation
• Support for multiple online image sources
• Random quote display capability
• Image effects and filtering
• Customizable change intervals
• Event-based wallpaper switching

The Ditana installer configures it to

• Change the background image only every 3 hours
• Use only Bing and Unsplash image sources

3.2 - Multimedia Applications

This category is only available if you have chosen to install a desktop environment during the Ditana installation process. It provides a selection of powerful multimedia tools for both creative work and entertainment.

Each application can be further customized through its respective settings interface. For detailed configuration options and usage instructions, please refer to the linked documentation pages.

Graphics and Design

Inkscape

Inkscape (GPL/LGPL) is a professional-grade vector graphics editor that offers:

• Native SVG format support
• Advanced path operations
• Marker and clone management
• Alpha blending capabilities
• Extensive filter effects
• Professional typography tools
• Extension system for additional functionality
• Comprehensive export options

Pinta

Pinta (MIT) is a user-friendly raster graphics editor modeled after Paint.NET, featuring:

• Layer-based image editing
• Multiple adjustment tools
• Effect filters
• Drawing tools
• Simple and intuitive interface
• History management
• Basic photo retouching capabilities

MyPaint

MyPaint (GPL) is a professional drawing program optimized for digital artists:

• Pressure-sensitive input support
• Natural media simulation
• Custom brush creation
• Infinite canvas
• Layer management
• Stylus and tablet optimization
• Various artistic tools and brushes

Audio Production

Audacity

Audacity (GPL3/BSD) is a comprehensive audio editing and recording solution that provides:

• Multi-track audio recording
• Professional editing tools
• Plugin support for effects and analysis
• Various audio format support
• Noise reduction capabilities
• Spectrum analysis tools
• MIDI file import
• Recording from multiple sources

Entertainment and Streaming

Spotify

Spotify (Proprietary) provides access to a vast music streaming service:

• Extensive music and podcast library
• Offline playback capability
• High-quality audio streaming
• Collaborative playlist features
• Cross-device synchronization
• Personal recommendations
• Social sharing features

Performance Testing

UNIGINE Superposition

UNIGINE Superposition (Proprietary - UNIGINE Engine) is a comprehensive hardware benchmark tool that tests:

• Graphics card performance
• Power supply stability
• Cooling system efficiency
• System stress handling
• Real-time graphics capabilities
• Hardware compatibility
• Overall system stability

3.3 - AI Applications

This category is available for both desktop and headless installations, though some options are specific to desktop environments. All AI applications require CPU AVX support and will not be available on systems lacking this capability.

Security Focus: The AI packages listed below utilize a locally running AI API, which enhances privacy and security by processing data directly on your PC. This approach minimizes reliance on external services, ensuring that your data remains secure and under your control. However, if preferred, you have the option to switch to the OpenAI API.

For detailed configuration options and optimal settings for each tool, please refer to their respective documentation pages linked below.

Desktop-Specific AI Tools

The following tools are only available when installing a desktop environment:

Ditana Assistant GUI application

Ditana Assistant (AGPL-3.0-or-later) provides AI-powered system interaction through:

• Natural language interface for common terminal commands
• File operation assistance
• System query handling
• Basic troubleshooting support
• Desktop application launching
• Internet search capabilities
• Optional Integration of Wolfram|Alpha to provide real-time data.

In its default configuration, the assistant runs locally and prioritizes privacy by requesting confirmation before executing any command. You can easily configure it to use OpenAI models, see documentation.

Example screenshot, illustrating the seamless integration of real-time data from the Wolfram|Alpha API, which is automatically accessed as needed:

Logseq

Logseq (AGPL-3.0-or-later) is a powerful knowledge management platform that offers:

• Networked thought organization
• Daily journaling capabilities
• Task and project management
• Bi-directional linking
• Graph visualization
• Markdown and Org-mode support
• Local-first architecture ensuring data privacy
• Extensible plugin system

This Ditana-specific package extends Logseq with AI capabilities through:

• Pre-configured GPT-3 OpenAI plugin to make it use the local KoboldCpp instance
• AI-assisted note-taking capabilities
• Content generation features
• Knowledge synthesis support

This integration maintains privacy by leveraging your local KoboldCpp installation while providing the power of AI-enhanced knowledge management.

Example after pressing Ctrl+G on a Logseq note:

Stable Diffusion

Stable Diffusion (easydiffusion) provides local AI image generation:

• Text-to-image generation
• High-quality output
• Local processing
• Custom model support
• Various generation parameters
• Intuitive interface
• Progress visualization

Core AI Tools

Ditana Assistant Terminal Application

Ditana Assistant (AGPL-3.0-or-later) provides AI-powered system interaction through:

• Natural language interface for common terminal commands
• Terminal-based interaction methods
• File operation assistance
• System query handling
• Basic troubleshooting support
• Desktop application launching
• Internet search capabilities

In its default configuration, the assistant runs locally and prioritizes privacy by requesting confirmation before executing any command. You can easily configure it to use OpenAI models, see documentation.

Example session:

❯ ./ditana-assistant “What are the largest files in the current directory and below?”

find . -type f -exec du -h {} + | sort -rh | head -n 10

Execute above command? (y/n) y

364K	./packaging/arch/ditana-assistant-1.036-1-any.pkg.tar.zst
284K	./src/ditana-logo.png
284K	./packaging/arch/pkg/ditana-assistant/usr/share/ditana/assistant/ditana-logo.png
284K	./packaging/arch/ditana-logo.png
276K	./.git/objects/21/e3382f3ee049d91368ce79218cb4049bae6222
248K	./myenv/lib/python3.12/site-packages/__pycache__/bottle.cpython-312.pyc
248K	./myenv/bin/__pycache__/bottle.cpython-312.pyc
204K	./myenv/lib/python3.12/site-packages/pip/_vendor/rich/__pycache__/_emoji_codes.cpython-312.pyc
160K	./myenv/lib/python3.12/site-packages/pip/_vendor/pkg_resources/__pycache__/__init__.cpython-312.pyc
156K	./myenv/lib/python3.12/site-packages/pip/_vendor/idna/__pycache__/uts46data.cpython-312.pyc

Your Message (’enter’ to quit): Which one of these are safe to delete?

It is important to exercise caution when deleting files, especially system files or files related to applications. In the list provided, the file that appears to be safe to delete without causing any major issues is:

./myenv/lib/python3.12/site-packages/pip/_vendor/idna/__pycache__/uts46data.cpython-312.pyc

This file seems to be a Python cache file and deleting it should not have a significant impact on the functionality of the application. However, it is always recommended to make a backup of the file before deleting it, in case it is needed later on.

See documentation for more examples.

KoboldCpp

KoboldCpp (AGPL-3.0-only) offers private, local AI chat functionality:

• Browser-based interface
• Pre-configured Gemma language model
• Text generation capabilities
• Code completion support
• Local web server implementation
• Privacy-focused design
• Suitable for both desktop and headless systems

Ditana installs it preconfigured with the Gemma language model. A desktop shortcut is installed to access it via its browser interface. This package is also used by the Ditana Assistant via the KoboldCpp API.

Development Tools

CodeGPT

CodeGPT is a development tool that integrates AI assistance into your workflow:

• Automated git commit message generation
• AI-powered code review capabilities
• OpenAI API integration
• Command-line interface
• Multiple model support
• Context-aware suggestions
• Integration with popular git commands

The Ditana installer configures CodeGPT to use gpt-4o-mini instead of gpt-3.5-turbo. As of October 2024, gpt-4o-mini is a factor of 20 cheaper than gpt-3.5-turbo: $0.150 / 1M input tokens. According to https://platform.openai.com/docs/models/gpt-3-5-turbo:

“As of July 2024, gpt-4o-mini should be used in place of gpt-3.5-turbo, as it is cheaper, more capable, multimodal, and just as fast. gpt-3.5-turbo is still available for use in the API.”

Note: Requires an OpenAI API key stored in ~/.shell.d/openai.sh

High-Performance Computing Libraries

A comprehensive suite of libraries optimized for AI/ML workloads and numerical computations:

Basic Libraries

• blas-openblas: Basic Linear Algebra Subprograms for matrix operations
• clblast: OpenCL BLAS library for GPU acceleration
• ocl-icd, opencl-clhpp: OpenCL standard implementations
• openmpi: High-performance message passing library

NVIDIA-Specific Components

When NVIDIA GPU is detected:

• cuda: NVIDIA’s parallel computing platform
• cudnn: Deep Neural Network library
• opencl-nvidia: NVIDIA OpenCL implementation
• lib32-opencl-nvidia: 32-bit NVIDIA OpenCL support
• nccl: Multi-GPU/node collective communication

AMD-Specific Components

For AMD GPU systems:

• hipblas: ROCm BLAS library
• hip-runtime-amd: AMD’s compute interface

System Requirements

• CPU must support AVX instructions
• Adequate RAM (varies by tool)
• Sufficient storage space

3.4 - Kernel Configuration

Ditana provides access to advanced kernel configurations during installation. These settings allow you to optimize your system’s behavior according to your specific requirements. Each option has been carefully selected to provide meaningful improvements for specific use cases.

Default Configuration

Ditana enables certain kernel optimizations by default, carefully balancing performance, security, and usability. Specific defaults include:

• Parameters meant to be used to optimize ZRAM (which is enabled in Ditana, but - as everything - you can switch it off)
• Enforcing strict mitigations depending on hardware-specific CPU vulnerabilities
• Magic SysRq keys enabled for system recovery
• Memory-related optimizations based on available RAM
• Immediate OOM-killing for better system stability
• Unprivileged container support enabled
• Enhanced device initialization ordering
• Memory zeroing on allocation and deallocation

If you prefer to use the kernel’s default settings (which might be more suitable for specific workloads or when maximum compatibility is required), you can uncheck all options during installation.

3.4.1 - General Kernel Configuration

These kernel parameters are configured to optimize system performance, security, and resource management. You may choose to adjust these settings based on your specific requirements.

List of General Kernel Configuration Settings

Enable Magic SysRq Keys

Related kernel setting: kernel.sysrq= 0 ⇨ 1

Enables the SysRq (commonly ‘Print Screen’) key for emergency recovery actions, such as Alt+SysRq+B to reboot.

Default: activated

Reduce Background Reclaiming of Filesystem Cache

Related kernel setting: vm.vfs_cache_pressure 100 ⇨ 50

Retains more filesystem metadata in memory for faster access, increasing RAM usage.

Default: activated if system as more than 24 GB RAM.

Minimize Background Memory Compaction

Related kernel setting: vm.compaction_proactiveness 20/100 ⇨ 1/100

Reduces effort spent on memory compaction in the background, which may decrease CPU load at the cost of increased RAM consumption.

Default: activated if system as more than 24 GB RAM.

Order Device Initialization & Power Tasks

Related kernel setting: fw_devlink ⇨ permissive

Facilitates the correct sequence of device initialization and power management tasks based on firmware information. This ensures stable system operation by prioritizing the initialization of supplier devices before consumers and managing power states effectively during suspend/resume cycles.

Default: activated

Allow Normal Users to Run Unprivileged Containers

Related kernel setting: kernel.unprivileged_userns_clone 0 ⇨ 1

This is crucial for running containers, such as Docker, in a more secure manner without granting users full root privileges. For example, a developer can run Docker containers for testing purposes without needing administrative access to the system.

Default: activated

Allow Normal Users to Access Performance Profiling Tools

Related kernel setting: perf_event_paranoid 0 ⇨ 1

This is particularly useful for developers who need to analyze application performance in a more secure way without needing full root privileges.

Default: activated

Automatically Fill Allocated Memory with 0

Related kernel setting: init_on_alloc 0 ⇨ 1

Increases security by zeroing out newly allocated memory.

Default: activated

Automatically Fill Deallocated Memory with 0

Related kernel setting: init_on_free 0 ⇨ 1

Aids in preventing data leakage by clearing freed memory.

Default: activated

3.4.2 - ZRAM related kernel configuration

ZRAM is enabled by default. In dialog «Storage & File System Options» you may disable it. If you modify kernel settings that would degrade ZRAM’s performance, or the performance of a system without ZRAM (in case ZRAM is disabled), a warning will be displayed when confirming such kernel settings.

List of ZRAM related settings

Optimize swap file and ZRAM usage

Related kernel setting: vm.swappiness

If you have left ZRAM enabled (default), this setting changes the swappiness from the default of 60 to the recommended value of 180. If you have ZRAM disabled, this setting changes swappiness to 1, which conserves RAM for active applications to improve system responsiveness, but leaves less RAM available for kernel operations such as caching file system metadata and managing network buffers. Unchecking the setting will use the kernel default in all cases.

Default: activated if zram is enabled, else if system as more than 24 GB RAM.

Disable Zswap Cache Layer

Related kernel parameter: zswap.enabled=0

Disables Zswap’s intermediary cache, allowing direct use of swap devices like ZRAM.

Default: activated if zram is enabled

Disable Swap Readahead

Related kernel setting: vm.page-cluster 3 ⇨ 0

The system reads only one page at a time from swap, potentially reducing initial latency when accessing swapped-out pages. This is advantageous when using ZRAM, as ZRAM provides fast access to swap space. Reading only the required pages can improve performance without the overhead of prefetching additional pages.

Default: activated if zram is enabled

Disable Extra Memory Reclaim

Related kernel setting: vm.watermark_boost_factor 15000 ⇨ 0

This reduces reclaim activity during memory fragmentation when high-order memory allocations are less critical. This can optimize memory management for systems using ZRAM. Since ZRAM reduces the need for high-order memory allocations, the extra memory reclaim becomes unnecessary, improving overall performance.

Default: activated if zram is enabled

Maintain free memory

Related kernel setting: vm.watermark_scale_factor 10/3000 ⇨ 125/3000

Make the Kernel Swap Thread more aggressive in maintaining free memory. This helps prevent applications from entering direct memory reclaim, enhancing system responsiveness under memory pressure. This is particularly beneficial for systems with ZRAM, because it allows the system to better utilize ZRAM’s fast swap capabilities by maintaining more free memory and reducing allocation stalls.

Default: activated if zram is enabled

3.4.3 - CPU Vulnerability Mitigation Options

CPU Vulnerability Mitigation Configuration

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 manage 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 strive to balance security and performance. However, these settings do introduce certain security vulnerabilities. Ditana prioritizes robust security by enabling mitigations that address these vulnerabilities without significantly impacting system performance. 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. To accommodate this, Ditana’s installer framework 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 below.

Hardware-Specific Configuration

Please note that the application of these kernel settings is tailored to your specific hardware configuration. Ditana’s hardware detection system ensures that mitigation settings are applied appropriately based on the vulnerabilities relevant to your CPU model.

By choosing to adhere to 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 to protect your system, unless you have specific needs that justify adjusting them for performance gains.

Additional sources beyond kernel.org

After Installation

Mitigations often include disabling Hyperthreading (SMT) as a fallback. Upon installation, Ditana’s custom terminal header output will display the active mitigations. Note that only enabled mitigations are shown, while any that remain disabled are simply omitted to keep the output concise. Moreover, the output contains information if Hyperthreading (SMT) is enabled or not.

In addition, you can verify applied mitigations by running:

lscpu

To compare performance with and without mitigations, reboot, press e at the boot menu (GRUB), and edit the boot parameters. Remove the parameter associated with a specific mitigation for testing. The specific parameters for each mitigation can be found in the list below under “Applied mitigation.” Reboot and run your usual tasks to evaluate any performance impact rather than using synthetic benchmarks.

If you decide to disable a mitigation permanently, open /etc/default/grub in a terminal editor:

micro /etc/default/grub

Locate the GRUB_CMDLINE_LINUX_DEFAULT line, take a photo of it as a backup, and remove the desired parameters as you did before. Save with Ctrl+S (you will be asked for your password), then run:

sudo grub-mkconfig -o /boot/grub/grub.cfg

After reboot, these settings will persist. If an error prevents booting, use the GRUB boot menu to correct the parameters, then repeat these steps to apply the fix.

Disclaimer

The guidance here relies on the official CPU vulnerability documentation and kernel command-line parameter documentation. Different Ditana-supported kernels may exhibit variations from kernel.org defaults, with occasional complex side effects. Our testing shows these parameters to be effective across kernel versions. We invite you to submit a GitHub issue or join us on Discord to discuss any topic, including kernel parameterization.

In our experience, as developers often working with 100% CPU loads, setting “High Security” across all tested hardware has shown minimal performance impact, even with hyperthreading disabled. This may not apply to all workloads. If your activities benefit from adjusting Ditana’s defaults, please let us know; we aim to refine the installation wizard to accommodate specific hardware needs.

Ditana’s handling of the specific CPU vulnerabilities

Spectre Variant 2 (Branch Target Injection)

This vulnerability allows attackers to exploit speculative execution to access sensitive data. Enabling this option forces the kernel to apply full mitigations for Spectre Variant 2, potentially enhancing security.

For example, on a 12th Gen Intel(R) Core(TM) i9-12900T CPU (which is affected), running lscpu without this mitigation enabled shows:

Spectre v2:             Mitigation; Enhanced / Automatic IBRS; IBPB conditional; RSB filling; PBRSB-eIBRS SW sequence; BHI BHI_DIS_S

With this mitigation enabled, lscpu reports:

Spectre v2:             Mitigation; Enhanced / Automatic IBRS; IBPB always-on; RSB filling; PBRSB-eIBRS SW sequence; BHI BHI_DIS_S

On this specific CPU, the difference is that the Indirect Branch Prediction Barrier (IBPB) is applied consistently (always-on), rather than conditionally. For this CPU model, Hyper-Threading (SMT) remains enabled.

L1 Terminal Fault (L1TF)

Affects Intel CPUs, allowing unauthorized access to data in the Level 1 cache. This option enforces full mitigation, which may involve more aggressive cache flushing.

Microarchitectural Data Sampling (MDS)

Allows attackers to sample data from CPU buffers. Enabling this enforces full mitigations and may disable Simultaneous Multithreading (SMT) if necessary.

TSX Asynchronous Abort (TAA)

Affects CPUs with Transactional Synchronization Extensions (TSX). This option enables full mitigation and may disable SMT if required.

Meltdown (L1D Flushing)

Exploits speculative execution to read kernel memory. Enabling this forces the kernel to flush the Level 1 data cache to mitigate Meltdown.

MMIO Stale Data Vulnerabilities

Allows leakage of data from Memory-Mapped I/O. This enforces full mitigations and may disable SMT if needed.

Retbleed (Cross-Thread Return Address Predictions)

A speculative execution attack that can leak return addresses. This option enables automatic mitigation and may disable SMT.

See Cross-Thread Return Address Predictions for the details on kernel.org.

Speculative Return Stack Overflow (SRSO)

Leads to speculative execution attacks via the return stack buffer. Enabling this applies mitigations and may impact performance.

Gather Data Sampling (GDS)

Affects AVX instructions. This option forces microcode mitigations or disables AVX if the microcode is unavailable.

Register File Data Sampling (RFDS)

Allows sampling of data from CPU registers. Enabling this activates mitigations to protect against RFDS.

See Register File Data Sampling (RFDS) for the details on kernel.org.

Not included CPU vulnerabilities

These vulnerabilities are not included in the Ditana installer, because the kernel performs maximum mitigation by default.

Spectre Side Channels: variant 1 (Bounds Check Bypass)

iTLB multihit

See iTLB multihit for the details on kernel.org.

SRBDS - Special Register Buffer Data Sampling

See SRBDS - Special Register Buffer Data Sampling for the details on kernel.org.

Speculative Store Bypass (SSB)

Mitigation Reduction Options

In addition to the specific CPU vulnerability mitigations, Ditana provides options to reduce or disable mitigations globally. Please note that using these options can significantly increase the security risks associated with your system.

Disable Intel BTI Mitigation - Security Risk! Undocumented! (ibt=off)

This option disables the Intel Branch Target Injection (BTI) mitigation. Warning: This is an undocumented kernel parameter and is generally not recommended. Despite its widespread use and often being set as a default without explicit communication, disabling BTI can expose the system to security vulnerabilities.

The primary purpose of BTI mitigation is to protect against certain speculative execution attacks by enforcing Control-flow Enforcement Technology (CET) Shadow Stack. More details can be found in the CET Shadow Stack documentation.

Usage Warning: Disabling BTI mitigation may expose your system to potential security threats. It is advised to keep this mitigation enabled unless you have a specific, justified need to disable it.

Disable All Mitigations - Security Risk! (mitigations=off)

This option differs from disabling all mitigations that Ditana offers, because it disables all mitigations that the kernel offers. Warning: Disabling all mitigations poses a high security risk and is strongly discouraged unless absolutely necessary for specific use cases.

By setting mitigations=off, the system will not apply any of the available mitigations for known CPU vulnerabilities, potentially exposing the system to various speculative execution and side-channel attacks.

For more information, refer to the Kernel Parameters Documentation.

3.5 - Comparison of File Systems

File system selection is a critical aspect of operating system design and user experience. While Windows relies on NTFS with continuous TRIM, and macOS uses APFS—often benefiting from seamless integration with Apple hardware—Ditana GNU/Linux prioritizes efficiency with ZFS or BTRFS using noatime, weekly TRIM, and zstd compression. By striking a balance between reduced write operations, optimized compression, and controlled TRIM intervals, Ditana GNU/Linux aims to minimize overall system load and extend SSD lifespan.

3.6 - Storage & File System Options

In this dialog you can configure various storage and filesystem settings to optimize your system’s performance, durability, and security. This guide provides detailed information on each available option.

1. Disable File Access Time Recording

Enable the noatime option when mounting the root file system to prevent the recording of the last access time of files. This configuration offers several benefits:

• Performance Improvement: Reduces the overhead associated with updating access times on each file read operation, leading to faster file system performance.
• Reduced Wear on Storage Devices: Minimizes write operations, which is particularly advantageous for SSDs by extending their lifespan.
• Optimized for Btrfs: Enhances snapshot performance by reducing the number of write operations required during snapshot creation and management.
• Enhanced Security: Prevents exposure of file access patterns, reducing potential information leakage.

Considerations: While noatime is beneficial for most users, it can be disabled if specific applications rely on access time information.

2. Install ZRAM

ZRAM is enabled by default to optimize memory usage by creating a compressed swap space in RAM. This setup offers several advantages:

• Memory Optimization: Efficiently uses available RAM by compressing unused memory pages, allowing more applications to run simultaneously.
• Reduced Wear on Storage Devices: Decreases the reliance on swap space located on SSDs or HDDs, thereby extending their lifespan.
• Enhanced System Responsiveness: Improves performance under memory pressure by providing a faster swap solution compared to disk-based swap.
• Automatic Management: Managed by the zram-generator, which configures and activates ZRAM without requiring manual setup.

Considerations: Only consider disabling ZRAM if you are certain that the system will not encounter high memory demand.

Additional Notes:

• With a Swap Partition:

  • If a swap partition is configured (e.g., $SWAP_PARTITION GiB), ZRAM will create an additional compressed swap layer. This compressed swap is utilized before accessing the SSD or HDD swap space to further reduce wear.

• Without a Swap Partition:

  • If no swap partition is configured, the system will rely solely on ZRAM to handle swap needs efficiently, utilizing compressed memory to manage occasional high RAM demand.

3. Make a RAM Disk Available

This option allows you to create a dedicated RAM Disk mounted within the user’s runtime directory ($XDG_RUNTIME_DIR) and symlinked to $HOME/RAMDisk. Key features include:

• User-Exclusive Temporary Storage: Provides a clean space for temporary data, separate from system files like $XDG_RUNTIME_DIR and /tmp.
• Controlled and Secure Access: Accessible only to the user, ensuring that temporary data remains private and secure.
• Easy Integration: Set up with the $RAMDISK environment variable for convenient reference in the terminal.

Ideal Use Cases:

• Fast Temporary Storage: Suitable for tasks that require quick read/write operations, such as video processing or caching.
• Automatic Cleanup: The RAM Disk integrates with the file manager on desktops and clears automatically upon logout, ensuring that temporary data does not persist unnecessarily.

Kernel Configuration Adjustments

Enabling certain options may modify kernel settings to ensure optimal performance:

• ZRAM Installation:

  • Modifies kernel settings related to swap management to ensure that ZRAM operates efficiently.
  • If ZRAM is enabled, specific kernel parameters are adjusted to balance performance and storage usage.

• Without ZRAM:

  • Kernel settings are adjusted to ensure that the system functions optimally without ZRAM, maintaining performance without the compressed swap layer.

These adjustments can be reviewed under the General Kernel Configuration section.

3.7 - Firmware

Currently, the firmware packages are hard-coded, so the user has no option to change them. The settings.json includes a component “firmware” that lists the installed packages. Firmware that requires additional logic, like b43-firmware, is placed into separate components.

Currently, these are

• b43-firmware - Firmware for Broadcom B43 wireless networking chips
• linux-atm - Drivers and tools to support ATM networking
• linux-firmware - Basic firmware packages
• linux-firmware-marvell - Firmware for Marvell devices
• sof-firmware - Sound Open Firmware
• wireless-regdb - Central Regulatory Domain Database

If you need additional packages for your system, or your system needs additional configuration, please open a GitHub issue.

3.8 - Development Tools and Libraries

3.8.1 - Diffuse

Diffuse is unfortunately not as widely used as tools like Meld, KDiff3 and P4Merge. While these alternatives offer slightly different functionalities in their diff capabilities, Diffuse excels in its merge functionality.

Diffuse supports n-way merges and displays all versions involved in the merge process. In contrast, Meld does not display the base version, which can be crucial for resolving complex merge conflicts. Additionally, Diffuse allows for manual alignment of lines, which is important when code blocks have been moved and simultaneously modified. The merge view in Diffuse may require some getting used to, as it presents four side-by-side windows:

• A: The local version
• B: The merged version (the one you work on)
• C: The remote version
• D: The base version

For comparison, KDiff3 (which also allows manual alignment) displays four windows as well. However, the result window B is positioned below the “supplier” versions of the files, similar to Meld and P4Merge. Meld does not show the base version, and in P4Merge, the controls for resolving merge conflicts can be somewhat unintuitive. Neither Meld nor P4Merge allow for manual alignment of lines.

To resolve a merge conflict in Diffuse, navigate between differences using Ctrl+Down and Ctrl+Up. In the resulting file B, you will see the text that Git itself generates in the event of a conflict (unlike other tools). For example:

<<<<<<< HEAD
`kora-yellow-icon-theme` is used by ditana-config-xfce on Ditana GNU/Linux.
=======
`kora-yellow-icon-theme` is used by [ditana-config-xfce](https://github.com/acrion/ditana-config-xfce) on Ditana Linux.
>>>>>>> 8a5933f8aba535f7265111ec806f91d6107f3ab6

In this example, a merge conflict occurs because this line was modified in two places: both in the local version A (which added “GNU/”) and in the remote version C (which added a link).

In such cases, the approach is similar to other merge tools: choose either A or C to resolve the merge conflict and manually incorporate changes from the other version in the merge editor. To do this:

1. Select the conflicting lines using Ctrl+Down or Ctrl+Up.
2. Choose “Copy Right Into Selection” (Ctrl+Left) if you want to adopt C (the remote version), which is the quicker option in the example above, or choose “Copy Left Into Selection” (Ctrl+Right) if you prefer to adopt A (the local version).
3. Double-click the area in B that you wish to edit, make the necessary changes, and then press the Escape key.
4. Close Diffuse, which will prompt you to save your changes.

Afterwards, confirm the successful merge in Git with git commit (Git message: use "git commit" to conclude merge).

Why Ditana Chooses Diffuse

While there are several merge tools available, Ditana has chosen to include Diffuse due to its superior merge capabilities, particularly its support for n-way merges and comprehensive version display. These features make Diffuse especially effective for handling complex merge conflicts that other tools may struggle with. Additionally, Diffuse’s ability to align lines manually ensures that developers can manage intricate code changes with greater precision. Although Diffuse’s merge interface may take some time to get accustomed to, its robust functionality provides significant advantages for development workflows in Ditana.

4 - The Assistant

Ditana Assistant is an innovative AI-powered application that combines a graphical user interface with terminal functionality and, optionally, introspective contextual augmentation via Wolfram|Alpha. Even without Wolfram|Alpha, the Introspective Contextual Augmentation (ICA) enhances AI responses in many cases (see Example Sessions for more details).

It leverages Large Language Models (LLMs) to provide intelligent assistance similar to the native browser interfaces of AI service providers.

The name stems from its integration into Ditana GNU/Linux, but it runs on other Linux distributions, macOS, and Windows (including PowerShell support).

Simply ask your question in natural language, for example

• What are the largest files in the current directory and below? (see sample session)
• Is the network name resolution service running stably? (see sample session)
• Which process is consuming so much CPU time?
• Replace all occurrences of the word ‘sun’ with ‘moon’ in the file ./project/test
• What’s my current audio device?

4.1 - Key Features

• AI Integration: Uses a KoboldCpp server with the Google Gemma model.
• Flexible Configuration: Can be configured to use OpenAI models through a simple YAML configuration file.
• OS Interaction: Capable of interacting with the operating system, suggesting and executing terminal commands upon user confirmation, see example sessions.
• Optional Wolfram|Alpha Integration: Automatically attempts to augment the LLM’s context via communication with the official Wolfram|Alpha Short Answers API.
• Introspective Contextual Augmentation (ICA): Enhances AI responses by automatically gathering and incorporating relevant contextual information through introspective reasoning. See Introspective Contextual Augmentation for more details.
• Multi-Platform: Runs on Linux, macOS, and Windows, adapting to each environment automatically by collecting context of the running system.
• Dual-Mode Operation: Functions both as a GUI application and a stand-alone terminal tool for quick command generation and embedding of answers in scripts.
• Pastime Mode: Engage in human-like conversations with an AI companion, optionally impersonating specific characters or personalities.
• Intelligent Caching: Implements a sophisticated request caching system for both Wolfram|Alpha and LLM queries, optimizing API usage and response times.

4.2 - Use Cases

Maximizing the Underlying AI Model’s Potential

Ditana Assistant is designed to maximize the potential of its underlying AI model, offering capabilities that surpass typical browser-based interactions:

1. Integration of Multiple Knowledge Sources: By combining the AI model’s capabilities with Wolfram|Alpha’s factual database (when enabled), Ditana Assistant offers a broader range of assistance, from creative problem-solving to mathematical calculations and up-to-date information.

2. Introspective Contextual Augmentation (ICA): By introspectively augmenting the context of queries, Ditana Assistant provides more accurate and relevant responses. This feature improves AI answers in many cases, even when used without Wolfram|Alpha.

3. System-Specific Context: The assistant automatically adds information to the LLM’s context about your specific system environment, allowing for more precise and tailored responses. This context includes details about your operating system, shell type, and running applications.

Terminal Command Generation

• Generating complex terminal commands
• Process and performance monitoring
• File and system management
• Audio device configuration
• Text manipulation in files
• System log analysis

See Example Section for demonstration.

Assistance Based on Your Specific System

Currently, the following information is collected from your system to tailor the LLM’s answers to your needs:

• The type of shell you started the Assistant from (important for terminal commands)
• The desktop type
• Running desktop applications
• Your date, time and time zone
• Your preferred language (based on your temporal locale identifier, platform-independent)
• In Terminal Mode, the current directory

Use Cases of Wolfram|Alpha

• Real-time information like statistics such as population, weather and much more (see sample session)
• Mathematics (see sample session)
• Factual, highly accurate knowledge without the occasional inconsistencies or inaccuracies that may occur with LLMs

4.3 - Installation

Ditana GNU/Linux

Ditana Assistant is integrated into the Ditana GNU/Linux distribution with native Arch packages. The corresponding package in the Ditana Arch repository is ditana-assistant.

Note that this package does not depend on the ditana-koboldcpp AUR package, because you have free choice of which AI API you want to use, including OpenAI. ditana-koboldcpp includes an optimized configuration for the Gemma language model. In KoboldCpp operation mode, the assistant makes use of Gemma’s prompt format.

Other Linux Distributions, Windows, and macOS

For other platforms, including Windows and macOS, you can install Ditana Assistant from source using Poetry:

1. Clone the repository:

   git clone https://github.com/acrion/ditana-assistant.git
   cd ditana-assistant
   

2. Install Poetry:

   pip install poetry
   

3. Install ditana-assistant’s dependencies:

   poetry install
   

   This command will create a virtual environment (if one does not already exist) and install all dependencies listed in the pyproject.toml file. To execute ditana-assistant, you need to spawn a shell within the virtual environment with this command:

   poetry shell
   

   The dependencies include either an OpenAI API key or a local KoboldCpp server. For the latter, please consider using Google’s Gemma LLM (Download), as Ditana Assistant utilizes Gemma’s Instruct Tag Format. For this, you should select the Instruct Tag Preset Gemma 2 in KoboldCpp’s Format settings.

Why no requirements.txt?

Ditana Assistant uses Poetry to manage dependencies, which eliminates the need for a requirements.txt file. Poetry provides a pyproject.toml file to define dependencies and a poetry.lock file to lock the exact versions of these dependencies for consistency across different environments. This approach simplifies dependency management by ensuring that all environments use the exact same versions, reducing potential conflicts.

For more information on how Poetry manages dependencies, visit the Poetry documentation.

Prerequisites

Ditana Assistant supports two main operating modes:

1. Local operation with KoboldCpp:

   • A running KoboldCpp server is required.
   • In KoboldCpp operation mode, the Ditana Assistant makes use of Gemma’s prompt format.
   • You can download the recommended model here: gemma-2-2b-it-GGUF.
   • Arch Linux users can get everything required by installing the ditana-koboldcpp AUR package.

2. Cloud-based operation with OpenAI API:

   • Alternatively, you can use the OpenAI API without any local model setup.
   • This requires configuration and an OpenAI API key.

Choose the mode that best fits your needs and system capabilities.

4.4 - Configuration

The Ditana Assistant configuration is stored in a YAML file located at:

• Linux: ~/.config/ditana-assistant/config.yaml
• macOS: ~/Library/Application Support/ditana-assistant/config.yaml
• Windows: C:\Users\<username>\AppData\Local\ditana-assistant\config.yaml

Available Configuration Options:

assume_english: false
enable_experimental_features: false
generate_terminal_cmd: true
koboldcpp_base_url: http://localhost:5001  # when using Gemma
model_cache_size: 20
model_cache_start_lifetime_sec: 604800
model_type: gemma # or 'openai'
offer_cmd_execution: true
openai_model: gpt-4o-mini  # when using OpenAI
show_debug_messages: false
wolfram_alpha_cache_size: 1
wolfram_alpha_cache_start_lifetime_sec: 675
wolfram_alpha_error_cache_size: 1
wolfram_alpha_error_cache_start_lifetime_sec: 604800
wolfram_alpha_short_answers_app_id: '' # https://developer.wolframalpha.com

Configuration Option Details

Core Functionality Settings

• model_type: Specifies the AI model to use. Currently, gemma for KoboldCpp and openai for OpenAI models are supported. Also see Using OpenAI. Default: gemma (requires local KoboldCpp server)

• koboldcpp_base_url: The base URL of the KoboldCpp server, used when model_type is set to gemma. Default: http://localhost:5001

• openai_model: The specific OpenAI model to use when model_type is set to openai, see Using OpenAI. Default: gpt-4o-mini

• wolfram_alpha_short_answers_app_id: The App ID for Wolfram|Alpha’s Short Answers API, see Using Wolfram|Alpha. Default: '''

• generate_terminal_cmd: If enabled, the wizard will analyse the user’s input to see if it relates to their computer and can be solved by a terminal command. The terminal command is only offered for execution if offer_cmd_execution is also enabled. Default: true.

• offer_cmd_execution: If enabled, the assistant will offer to execute detected terminal commands based on the output. This usually happens together with generate_terminal_cmd, but not necessarily. Default: true.

Advanced Configuration

• assume_english: If set to true, the assistant will assume all text is in English without performing language detection. Language detection is only used for specific use cases such as Wolfram|Alpha or internal meta-requests that need to be combined with the user prompt. Default: false.

• enable_experimental_features: Activates experimental features for development and testing purposes. This is intended for internal use to systematically test new functionalities. Use with caution as features are still in development. Default: false.

• model_cache_size: Maximum size (in MiB) of the cache used for model responses. Note that the actual cache file size will be approximately 1/3 larger due to JSON formatting overhead. Default: 20 MiB.

• model_cache_start_lifetime_sec: The initial lifetime (in seconds) for model cache entries. When this period expires, the cache entry is re-evaluated; if a new response matches the cached one, the lifetime is extended, otherwise, it is shortened. Default: 604800 seconds (1 week).

• show_debug_messages: Controls whether debug messages are displayed during the assistant’s operation. Useful for troubleshooting. Default: false.

• wolfram_alpha_cache_size: Maximum size (in MiB) of the cache used for storing responses from the Wolfram|Alpha API. The actual file size will be approximately 1/3 larger due to JSON syntax. Default: 1 MiB.

• wolfram_alpha_cache_start_lifetime_sec: The initial lifetime (in seconds) for Wolfram|Alpha cache entries. The lifetime is adjusted based on whether subsequent API responses remain consistent or change. Default: 675 seconds.

• wolfram_alpha_error_cache_size: Maximum size (in MiB) of the cache used for failed Wolfram|Alpha API requests. This helps avoid repeated requests for errors. Default: 1 MiB.

• wolfram_alpha_error_cache_start_lifetime_sec: The initial lifetime (in seconds) for entries in the error cache. Lifetimes are adjusted based on whether the error persists. Default: 604800 seconds (1 week).

Using OpenAI

Set the OPENAI_API_KEY environment variable with your OpenAI API key when configuring OpenAI models (see below config entries model_type and openai_model). As of October 2024, gpt-4o-mini is a factor of 20 cheaper than gpt-3.5-turbo: $0.150 / 1M input tokens. According to https://platform.openai.com/docs/models/gpt-3-5-turbo:

“As of July 2024, gpt-4o-mini should be used in place of gpt-3.5-turbo, as it is cheaper, more capable, multimodal, and just as fast. gpt-3.5-turbo is still available for use in the API.”

Note that the number of API accesses is reduced by Ditana Assistant’s sophisticated caching algorithm.

Using Wolfram|Alpha

Obtain an App ID by creating a “Short Answers API Key” on https://developer.wolframalpha.com and set the config entry wolfram_alpha_short_answers_app_id to its value. Make sure to select Short Answers API in the dialog:

Currently, 2000 accesses per month are free. Note that the number of API accesses is reduced by Ditana Assistant’s sophisticated caching algorithm.

4.5 - Command-line Interface

ditana-assistant [OPTIONS] [TASK]

Options:

• -h, --help: Show help message and exit.
• -v, --version: Show the version of Ditana Assistant and exit.
• -u, --gui: Display a graphical dialog.
• -a, --augmentation: Enable Introspective Contextual Augmentation (ICA) for enhanced AI responses.
• -w, --wolfram-alpha: Force use of Wolfram|Alpha for first prompt.
• -q, --quiet: Run in quiet mode. No progress output, no continuation of dialog (except confirmation of command execution).
• -p, --pastime: Activate Pastime mode for engaging in human-like conversations.
• -i IMPERSONATE, --impersonate IMPERSONATE: In Pastime mode, optionally impersonate a specified person or character.

Ditana Assistant supports specifying arbitrary tasks via command line arguments, which are then used as the initial prompt. This feature allows for versatile usage, from simple calculations to complex queries.

4.6 - Introspective Contextual Augmentation (ICA)

Introspective Contextual Augmentation is a powerful feature of Ditana Assistant that significantly enhances the quality and accuracy of AI responses. This innovative approach creates a synergy between various knowledge sources, including the AI model’s own introspective capabilities and Wolfram|Alpha (when enabled).

Note: This feature is turned off by default. Users can enable it through the UI or by using the -a command line switch when using the terminal tool.

Key Aspects of ICA

1. Dynamic Information Gathering:

   • The assistant automatically generates and processes contextual queries to supplement user inputs.
   • Adapts to each specific request, creating a more tailored response.

2. Dual-Source Augmentation:

   • With Wolfram|Alpha: Incorporates up-to-date information such as current weather, statistics, and more.
   • Without Wolfram|Alpha: Engages in self-dialogue, using the underlying LLM to answer contextual queries, enhancing response quality through introspection.

3. Adaptive Contextual Queries:

   • Dynamically generates relevant questions based on the user’s input.
   • These questions are answered either by Wolfram|Alpha or the LLM itself, creating a form of “inner monologue”.

4. Guided Introspective Reasoning:

   • Incorporates contextual queries and their answers into the message history before addressing the main user prompt.
   • Guides the LLM through a structured, introspective approach to problem-solving.
   • Allows the model to break down complex problems and approach them more systematically, even when engaging in self-dialogue.
   • The main user prompt is kept unchanged, but with additional context due to the messages automatically inserted into the dialogue.

5. Enhanced Problem-Solving:

   • Leverages additional context and guided introspective reasoning.
   • Provides more comprehensive and accurate solutions to complex problems.

6. Improved Accuracy:

   • Reduces errors and inconsistencies in AI responses.
   • Provides additional relevant information and a structured thought process before addressing the main query.

7. LLM Capability Maximization:

   • Even without external sources like Wolfram|Alpha, helps the LLM leverage its own knowledge more effectively.
   • Utilizes a guided, multi-step introspective reasoning approach.

Example of ICA in Action

To illustrate how ICA works, here’s an example from the MMLU multitask test (without using Wolfram|Alpha):

Question: A victim and a defendant both worked as longshoremen at a shipyard. After the victim
was shot to death, the defendant was tried for murder and acquitted. Following the acquittal,
the victim's estate sued the defendant in a wrongful death action. During the civil trial, the
victim's estate called a witness to testify. The witness, who worked with both men at the
shipyard, testified that two weeks before the shooting, the victim came to work with a broken
nose and said that the defendant had caused it. The attorney for the victim's estate then
asked the witness the following question, "Was the defendant present during your conversation
with the victim, and if so, did he say anything about the victim's broken nose?" The witness
replied, "Yes, the defendant was present, and after the victim told me that the defendant
broke his nose, the defendant said, And that's only the beginning." Upon objection by the
defendant's attorney, the witness's testimony is

Choices:
B. admissible, because it reports a declaration against interest.
C. admissible, because it reports the defendant's adoptive admission of the victim's assertion.
D. inadmissible, because of the principle of collateral estoppel.
E. inadmissible, because it is hearsay not within any recognized exception.

Correct answer: C

Model’s answer (without ICA feature): E

                            systematic contextual query: "What legal principle governs the admissibility of the witness's testimony regarding the defendant..."
                             answer to systematic query: "In the scenario, a victim and a defendant, both longshoremen at a shipyard, were involved in a ca..."
   Are you sure? Please answer only with "yes" or "no".: "no."
                                      critical question: "What specific hearsay exception could potentially apply to the defendant's statement, and how mig..."
                            answer to critical question: "The specific hearsay exception that could potentially apply to the defendant's statement is the "..."
Model’s answer (with ICA feature): C

This example demonstrates how ICA guides the model through a series of contextual queries, helping it arrive at the correct answer.

Please note that the additional questions and answers you see in the above log merely reflect a subset of the internal processes, and in particular, do not provide the context in which they occur. Furthermore, the generation of the questions is not logged. The objective of this log is to provide an overview of the internal processes. While additional log outputs can be enabled, they clutter the output.

Technical Implementation

1. Query Generation:

   • Utilizes meta-questions to the LLM to generate contextual queries.
   • Employs meta-meta-questions to generate the questions themselves.
   • Developed through extensive trial and error to determine effective query strategies.

2. Dialogue Structure:

   • Creates independent dialogues separate from the main conversation.
   • The main dialogue is then constructed based on the context derived from these sub-dialogues.

3. Prompt Engineering:

   • Varies the prompt structure based on the current step in the procedure.
   • Converts LLM-generated questions (initially Assistant messages) into User messages for efficient processing.
   • Sometimes repeats dialogues within a single message instead of using separate messages, depending on efficiency requirements.

4. Experimental Features:

   • Explored recursive calls with limitations to ensure prompts become progressively shorter.
   • Implemented in the generate_sub_prompts function in the text_processors_ai module.
   • Socratic method simulation (socratic_method function) attempted but not yet yielding statistically significant improvements.

Statistical Evaluation and Optimization

1. Benchmark Tests:

   • Utilized the MMLU multitask test (14,042 questions) and the ARC-Challenge test (1,172 questions).
   • Optimization primarily conducted using the ARC-Challenge test.

2. Performance Improvements:

   • MMLU test: Corrected 188 (5.6%) of 3,348 initially incorrect answers using the OpenAI model gpt-4o-mini.
   • ARC-Challenge test: Fixed 26 out of 94 initially incorrect answers.

3. Statistical Significance:

   • Employed McNemar’s statistical test to verify improvements.
   • Achieved over 99% probability of significant differences in all cases.
   • Despite optimization on ARC-Challenge potentially affecting statistical significance, MMLU results confirmed the effectiveness.

4. Methodology:

   • Conducted tests without Wolfram|Alpha to evaluate the ICA process capability independently.
   • Ran the ARC-Challenge test multiple times (4) due to potential variations in LLM API responses.

5. Documentation and Transparency:

   • Complete test logs available for download here.
   • Logged subset of internal processes to provide an overview without cluttering output.

Evaluation Methodology for Multiple-Choice Questions

The evaluation of Large Language Models (LLMs) on multiple-choice questions presents unique challenges, particularly when using pre-existing datasets. This section outlines the methodology employed in this project, discussing its rationale and comparing it to other potential approaches.

Dataset Preparation and Prompt Engineering

It’s crucial to note that many multiple-choice datasets, including those from HuggingFace like ai2_arc and cais_mmlu, provide only the question text and a list of answer choices. They do not include a pre-formatted prompt suitable for direct input to an LLM. Consequently, researchers must design an appropriate prompt structure.

In this project, the process_question function was developed to transform raw dataset entries into suitable prompts. This function constructs a prompt that clearly delineates the question and answer choices, concluding with an explicit instruction for the model to provide the letter of the correct answer.

Challenges with Standard Evaluation Metrics

Initial attempts at evaluation utilized the HuggingFace evaluate library, specifically the bertscore and Google Research rouge metrics. These metrics are widely used for various natural language processing tasks. However, manual verification of individual question evaluations revealed significant discrepancies in accurately identifying correct and incorrect responses in the multiple-choice context.

Development of a Specialized Evaluation Method

In response to these challenges, a specialized method for evaluating multiple-choice responses was developed. This method capitalizes on the structured nature of multiple-choice answers and the linguistic properties of English. Key aspects of this approach include:

1. Answer Choice Labeling: The method ensures that answer choices begin with “B” rather than “A”. This is crucial because “A” frequently appears as an article in English text, whereas “B”, “C”, “D”, etc., are less likely to appear as standalone words.

2. Response Parsing: The LLM’s response is analyzed for the presence of valid answer choice labels (e.g., “B”, “C”, “D”) as whole words. This approach significantly reduces false positives compared to more complex semantic analysis methods.

3. Validation Criteria:

   • A response is considered valid if exactly one answer choice label is present.
   • If multiple valid labels are detected, the response is deemed incorrect.
   • If no valid label is found, the response is also considered incorrect.
   • The response is correct only if the detected label matches the dataset’s provided answer.

This method has shown high reliability in manual verification, outperforming the initially tested bertscore and Google Research rouge metrics for this specific task.

Considerations and Future Work

While this specialized method has proven effective, it’s important to acknowledge that the HuggingFace evaluate library may contain other evaluation methods specifically designed for multiple-choice questions that were not explored in this project. Future work could involve a comprehensive comparison of this method against other potential evaluation techniques for multiple-choice responses.

Moreover, the necessity of prompt engineering in working with these datasets highlights an important consideration in LLM evaluation: the impact of prompt design on model performance. This aspect warrants further investigation and standardization efforts in the field of LLM evaluation.

Experimentation and Further Development

1. Modular Design:

   • Modifications can be implemented under the condition Configuration.get()['ENABLE_EXPERIMENTAL_FEATURES'].
   • Allows for easy testing and benchmarking of new features.

2. Benchmarking Process:

   • Use the -e option when running benchmarks to evaluate experimental modifications.
   • Statistical significance is calculated continuously after each question using McNemar’s statistical test, allowing for early detection of significant improvements or deteriorations.
   • Typically requires 2,000-3,000 questions to achieve robust statistical significance.
   • This approach quickly determines if changes are beneficial or detrimental, enabling efficient iteration and refinement of experimental features.

3. Ongoing Development of Experimental Features:

   • Building upon the experimental features mentioned in the Technical Implementation section, several areas are being actively explored and refined:
     • Further development of recursive techniques with result summarization, expanding on the generate_sub_prompts function.
     • Continued optimization of the Socratic method simulation, aiming to achieve statistically significant improvements.
     • Enhancement of query generation and dialogue construction methods to improve context understanding and response relevance.
   • These developments aim to push the boundaries of the ICA feature’s capabilities while maintaining efficient API usage and overall performance.

4. Open for Contributions:

   • The Python codebase allows for easy integration of new ideas and techniques.
   • Encourages experimentation within the augment_context_introspectively method in the conversation_manager module.

By leveraging these techniques and continual refinement, the ICA feature ensures that Ditana Assistant can deliver high-quality responses across a wide range of topics, maximizing the potential of the underlying AI model through structured, introspective reasoning, with or without external knowledge sources.

4.7 - Intelligent Caching

Ditana Assistant implements a sophisticated request caching system for both Wolfram|Alpha and LLM queries. This feature optimizes API usage and improves response times, especially for repeated or similar queries.

Key aspects of the caching system:

• Caches all outgoing requests to APIs.
• Implements an intelligent lifetime management for cache entries.
• Adapts cache lifetime based on the stability of responses.
• Initial cache lifetime depends on API: 1 week for LLMs, ≈ 11 minutes for Wolfram|Alpha.
• Particularly beneficial for internal queries made by Ditana Assistant, which often lack dialog history.
• Maximum cache size can be configured.

This caching mechanism significantly reduces API calls, especially for short, repetitive queries, leading to improved performance and reduced API usage.

4.8 - Ongoing and Future Development

• Installer Availability: The Ditana Assistant installer packages for macOS, Windows, and other Linux distributions (such as Debian and Fedora) are under active development. For these platforms, users are currently required to install Ditana Assistant from source using Poetry. This involves running terminal-based commands to set up a virtual environment and install dependencies as described in the Installation section. We aim to provide native installers and packages for a more seamless installation experience in future releases.

• Multimodal Integration: Future iterations of Ditana Assistant will focus on multimodal support, enabling contextual guidance by analyzing screenshots or controlling the mouse pointer for computer operation. By integrating visual recognition and advanced automation, the assistant will provide more intuitive, hands-free support. The goal of this development is to extend the capabilities of the Assistant from text-based prompts to comprehensive on-screen interaction, thereby increasing user efficiency and accuracy.

• Unit Testing: The number of unit tests in input_analyzers_ai_test.py is currently insufficient. We particularly need more tests for:

  • Cases where the assistant incorrectly identifies (or fails to identify) prompts suitable for terminal command generation.
  • Scenarios in which terminal commands are mistakenly suggested for normal prompts. We encourage users to submit pull requests with additional test cases, especially for edge cases they encounter.

• Wolfram|Alpha Integration: While basic integration is implemented for mathematical calculations and obvious real-time queries (e.g., weather information), this feature can be significantly expanded. Wolfram|Alpha offers extensive factual knowledge across various domains, which could enhance the assistant’s contextual understanding. Currently, there are no unit tests for this feature.

• Introspective Contextual Augmentation (ICA): This feature is thoroughly developed and rigorously tested. Its effectiveness has been validated through comprehensive, standardized tests for statistical significance, as detailed in the Statistical Evaluation and Optimization section. While proven effective, there are numerous ideas for further enhancements, outlined in the Experimentation and Further Development section. For a complete overview, see the Introspective Contextual Augmentation section.

We are actively working on improving cross-platform compatibility, expanding features, and enhancing overall reliability. We welcome contributions, especially in the form of testing, feedback, and pull requests for all environments and features.

Please note that while we strive for stability, Ditana Assistant is still evolving, and you may encounter bugs or unexpected behavior, particularly on less-tested platforms or with experimental features. We appreciate your patience and encourage you to report any issues you encounter.

4.9 - Example Sessions

In these sample sessions, extra informative output (mainly recarding ICA) is removed for readability. Also, the terminal output is formatted to make it more readable. The output of the AI is written in italics. Please see GitHub documentation for full output.

4.9.1 - Computer interaction, example 1

Request: “What are the largest files in the current directory and below?”

In this session, the user first inquires about the largest files in the current directory, then asks for suggestions on which of these might be deleted. This example demonstrates that:

• The assistant can provide ready-to-use terminal commands, including command chaining.
• The assistant can analyze the output of invoked tools, supported by an automatic contextual query.

❯ ./ditana-assistant -a “What are the largest files in the current directory and below?”

find . -type f -exec du -h {} + | sort -rh | head -n 10

Execute above command? (y/n) y

364K	./packaging/arch/ditana-assistant-1.036-1-any.pkg.tar.zst
284K	./src/ditana-logo.png
284K	./packaging/arch/pkg/ditana-assistant/usr/share/ditana/assistant/ditana-logo.png
284K	./packaging/arch/ditana-logo.png
276K	./.git/objects/21/e3382f3ee049d91368ce79218cb4049bae6222
248K	./myenv/lib/python3.12/site-packages/__pycache__/bottle.cpython-312.pyc
248K	./myenv/bin/__pycache__/bottle.cpython-312.pyc
204K	./myenv/lib/python3.12/site-packages/pip/_vendor/rich/__pycache__/_emoji_codes.cpython-312.pyc
160K	./myenv/lib/python3.12/site-packages/pip/_vendor/pkg_resources/__pycache__/__init__.cpython-312.pyc
156K	./myenv/lib/python3.12/site-packages/pip/_vendor/idna/__pycache__/uts46data.cpython-312.pyc

Your Message (’enter’ to quit): Which one of these are safe to delete?

          contextual query: "Which file in the list has the smallest size and can be safely deleted?"
answer to contextual query: "The file with the smallest size in the list is:  ./myenv/lib/python3.12/site-packages/pip/_vendor..."

It is important to exercise caution when deleting files, especially system files or files related to applications. In the list provided, the file that appears to be safe to delete without causing any major issues is:

./myenv/lib/python3.12/site-packages/pip/_vendor/idna/__pycache__/uts46data.cpython-312.pyc

This file seems to be a Python cache file and deleting it should not have a significant impact on the functionality of the application. However, it is always recommended to make a backup of the file before deleting it, in case it is needed later on.

4.9.2 - Computer interaction, example 2

Request: “Is the network name resolution service running stably?”

In this session, the user first inquires about the status of a service, then requests a summary. This example illustrates that:

• The assistant can deduce the specific name of the service with the help of System-Specific Context (on Windows or macOS, the answer is different).
• The assistant can analyze the output of invoked tools, supported by an automatic contextual query (see the following log).

❯ ./ditana-assistant “Is the network name resolution service running stably?”

systemctl status systemd-resolved.service

Execute above command? (y/n) y

● systemd-resolved.service - Network Name Resolution
     Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; enabled; preset: enabled)
     Active: active (running) since Mon 2024-09-23 10:16:39 CEST; 3 days ago
 Invocation: 1e937e9c439a4fed968ce8d0e976e201
       Docs: man:systemd-resolved.service(8)
             man:org.freedesktop.resolve1(5)
             https://systemd.io/WRITING_NETWORK_CONFIGURATION_MANAGERS
             https://systemd.io/WRITING_RESOLVER_CLIENTS
   Main PID: 737 (systemd-resolve)
     Status: "Processing requests..."
      Tasks: 1 (limit: 154223)
     Memory: 11.8M (peak: 15M)
        CPU: 55.832s
     CGroup: /system.slice/systemd-resolved.service
             └─737 /usr/lib/systemd/systemd-resolved

Sep 23 10:16:39 akino systemd[1]: Starting Network Name Resolution...
Sep 23 10:16:39 akino systemd-resolved[737]: Positive Trust Anchors:
Sep 23 10:16:39 akino systemd-resolved[737]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
Sep 23 10:16:39 akino systemd-resolved[737]: Negative trust anchors: home.arpa 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 19.172.in-addr.arpa 20.172.in-addr.arpa 21.172.in-addr.arpa 22.172.in-addr.arpa 23.172.in-addr.arpa 24.172.in-addr.arpa 25.172.in-addr.arpa 26.172.in-addr.arpa 27.172.in-addr.arpa 28.172.in-addr.arpa 29.172.in-addr.arpa 30.172.in-addr.arpa 31.172.in-addr.arpa 170.0.0.192.in-addr.arpa 171.0.0.192.in-addr.arpa 168.192.in-addr.arpa d.f.ip6.arpa …
Sep 23 10:16:39 akino systemd-resolved[737]: Using system hostname 'akino'.
Sep 23 10:16:39 akino systemd[1]: Started Network Name Resolution.
Sep 23 10:16:43 akino systemd-resolved[737]: enp5s0: Bus client set search domain list to: fritz.box
Sep 23 10:16:43 akino systemd-resolved[737]: enp5s0: Bus client set default route setting: yes
Sep 23 10:16:43 akino systemd-resolved[737]: enp5s0: Bus client set DNS server list to: 192.168.178.1
Hint: Some lines were ellipsized, use -l to show in full.

Your Message ('enter' to quit): Can you please summarize this?

The output shows that the systemd-resolved service is active and running stably since September 23, 2024. It is processing requests and has a main PID of 737. The service is managing network name resolution and has a positive trust anchor listed. The system hostname is 'akino' and the service has set search domain list and DNS server list for the network interface enp5s0.

4.9.3 - Automatic use of Wolfram|Alpha

This screenshot illustrates the seamless integration of real-time data from the Wolfram|Alpha API, which is automatically accessed as needed. The assistant leverages this capability to provide up-to-date and context-aware responses. The answer itself is generated by the LLM, but the additional context is automatically retrieved from Wolfram|Alpha. See Introspective Contextual Augmentation for details.

4.9.4 - Sophisticated calculator

This example demonstrates a direct output from Wolfram|Alpha’s Short Answers API, used for immediately suitable queries. Therefore, the language style of the output can be more formal than the natural style of LLMs. However, in the majority of cases, Ditana Assistant employs Wolfram|Alpha internally for Introspective Contextual Augmentation, enabling a powerful synergy between Wolfram|Alpha and the LLM to generate more comprehensive responses.

❯ ditana-assistant --quiet "solve x^2 + 2x + 5 = 0"

the 1st is x equals minus 1 minus 2 times i and the 2nd is x equals minus 1 plus 2 times i

Note 1: In this case, the assistant decided via an internal query to the LLM if to use Wolfram|Alpha or not. You may force the use of Wolfram|Alpha by adding the flag -w.

Note 2: The --quiet flag is used in this example to display only the assistant’s response without additional output.

4.9.5 - Pastime mode, example 1

This screenshot illustrates a conversion in the --pastime mode (without specific impersonation). In this case, gpt-4 has been used.

4.9.6 - Pastime mode, example 2

This terminal session illustrates impersonation of a specific character or personality (in this case, using gpt-3.5-turbo):

ditana-assistant -p -i "Detective Sherlock Holmes"

Ah, good afternoon. So you’re the one who asked me for help. Please tell me everything you know about the incident.

Your Message (‘enter’ to quit): All I know is that there was a lot of fog. I could hardly see anything. And suddenly the car was gone. Just disappeared. It was terrible.

Interesting. Can you tell me more about the car? Make, colour, registration number?

Your Message (‘enter’ to quit): It was a green VW Beetle. Licence plate number MN P-16.

Thank you for the information. Did you see any suspects or people behaving suspiciously?

Your Message (‘enter’ to quit): Precisely not, because of the fog. I only remember that, strangely enough, a parrot flew past just before the incident. That’s very strange, because parrots are not native to this area.

A parrot, you say? That is indeed unusual. Have you noticed anything else that you think is important?

4.9.7 - ICA example 1

Request: “What should I wear today for a travel to New York?”

The response without ICA lacks specific information about today’s weather. But even without ICA, if Wolfram|Alpha is configured, Ditana Assistant will always assess whether the request is directly suitable for Wolfram|Alpha (which it is not in this case). Here, Ditana Assistant’s System-Specific Context proves helpful. It provides a more informed answer than one without even knowing the current month.

The second response, with ICA enabled, automatically utilizes real-time information from Wolfram|Alpha to check the current temperature in New York.

Without ICA (default)

❯ ./ditana-assistant "What should I wear today for a travel to New York?"
                                    is English: "What should I wear today for a travel to New York?"
                  does not refer to a computer: "What should I wear today for a travel to New York?"
                not suitable for Wolfram|Alpha: "What should I wear today for a travel to New York?"

I recommend wearing comfortable and stylish clothing for your travel to New York. Since it’s September, you may want to consider layering options as the weather can be unpredictable. A light jacket or sweater, comfortable jeans or pants, and comfortable shoes for walking are good choices. Don’t forget to check the weather forecast for New York to ensure you are prepared for any conditions. Safe travels!

With ICA

❯ ./ditana-assistant -a "What should I wear today for a travel to New York?"
                                    is English: "What should I wear today for a travel to New York?"
                  does not refer to a computer: "What should I wear today for a travel to New York?"
                not suitable for Wolfram|Alpha: "What should I wear today for a travel to New York?"
                              contextual query: "What is the average temperature in New York City on September 26th, 2024?"
    Wolfram|Alpha’s answer to contextual query: "On Thursday, 26 September 2024, the mean temperature in New York City, United States, was 21 degr..."

For a trip to New York City on September 26th, 2024, you may want to wear comfortable clothing suitable for a temperature of around 21 degrees Celsius. It’s always a good idea to bring layers, as the weather can change throughout the day. Additionally, consider bringing an umbrella or rain jacket as there may be a chance of rain. Enjoy your trip!

4.9.8 - ICA example 2

Request: “A ladder leaning against a wall reaches 4 meters up the wall. The bottom of the ladder is 3 meters from the wall. What is the angle between the ladder and the ground?”

A detailed analysis by ChatGPT-o1 on the quality of the following two responses shows that Ditana Assistant’s ICA can avoid fundamental errors in the output:

• Answer 2 is correct, and it demonstrates a proper understanding and application of trigonometric functions, with all intermediate steps accurately calculated.
• Answer 1, while partially correct in its calculation, contains a fundamental error in explaining the trigonometric relationships and does not provide the final numerical value of the angle.

See public link to the comparison for the full picture.

Without ICA (default)

❯ ./ditana-assistant "A ladder leaning against a wall reaches 4 meters up the wall. The bottom of the ladder is 3 meters from the wall. What is the angle between the ladder and the ground?"
                                    is English: "A ladder leaning against a wall reaches 4 meters up the wall. The bottom of the ladder is 3 meter..."
                  does not refer to a computer: "A ladder leaning against a wall reaches 4 meters up the wall. The bottom of the ladder is 3 meter..."

Here’s how to solve this problem using trigonometry: Understanding the Problem

• We have a right triangle formed by the ladder, the wall, and the ground.
• The ladder is the hypotenuse (the longest side).
• The distance from the wall to the base of the ladder is one leg.
• The angle between the ladder and the ground is what we need to find. Using Trigonometry The trigonometric function that relates the opposite side, adjacent side, and hypotenuse is the tangent (tan).
• tan(angle) = opposite / adjacent Applying the Information

1. Opposite: The ladder reaches 4 meters up the wall, so the opposite side is 4 meters.
2. Adjacent: The base of the ladder is 3 meters from the wall, so the adjacent side is 3 meters. Calculating the Angle

• tan(angle) = 4 / 3
• angle = arctan(4/3) Using a Calculator You can use a calculator to find the arctangent of 4/3. The result will be the angle in degrees. Important Note: The angle will be an acute angle (less than 90 degrees). Let me know if you’d like me to calculate the angle using a specific calculator!

With ICA

❯ ./ditana-assistant -a "A ladder leaning against a wall reaches 4 meters up the wall. The bottom of the ladder is 3 meters from the wall. What is the angle between the ladder and the ground?"
                             is English: "A ladder leaning against a wall reaches 4 meters up the wall. The bottom of the ladder is 3 meter..."
           does not refer to a computer: "A ladder leaning against a wall reaches 4 meters up the wall. The bottom of the ladder is 3 meter..."
                       contextual query: "What is the angle between the ladder and the ground, given the ladder's height is 4 meters and it..."
Wolfram|Alpha declined contextual query: "The input cannot be interpreted or no short answer is available."
             answer to contextual query: "Here's how to solve this problem using trigonometry:  **Understanding the Problem**  * We have a ..."

Here’s how to solve this problem:

Understanding the Problem

• We have a right triangle formed by the ladder, the ground, and the wall.
• The ladder is the hypotenuse (the longest side).
• The distance from the wall to the base of the ladder is one leg.
• The height the ladder reaches on the wall is the other leg.

Using Trigonometry

We can use the sine function to find the angle:

• sin(angle) = opposite side / hypotenuse

In our case:

• Opposite side = height of the ladder = 4 meters
• Hypotenuse = length of the ladder = unknown
• We need to find the angle (angle)

Solving for the Angle

1. Substitute the values: sin(angle) = 4 meters / hypotenuse
2. Use the Pythagorean theorem: hypotenuse² = base² + height²
   • hypotenuse² = 3 meters² + 4 meters²
   • hypotenuse² = 25 meters²
   • hypotenuse = √25 meters² = 5 meters
3. Substitute the hypotenuse back into the sine equation: sin(angle) = 4 meters / 5 meters
4. Solve for the angle: angle = arcsin(4/5)
5. Calculate the angle: angle ≈ 53.13 degrees

Answer: The angle between the ladder and the ground is approximately 53.13 degrees.

Let me know if you have any other geometry problems!

4.9.9 - ICA example 3

Request: “Can you explain how the proof-of-stake consensus mechanism differs from proof-of-work in blockchain technology?”

A detailed analysis of ChatGPT-o1 on the quality of the following two responses indicates that Ditana Assistant’s ICA can better leverage the capabilities of the underlying LLM model:

Between the two answers, Answer 2 is of higher quality. It offers a more comprehensive and structured comparison of the proof-of-stake and proof-of-work consensus mechanisms. By organizing the information into key points, it enhances readability and makes it easier to understand the distinct differences. Additionally, Answer 2 covers extra dimensions such as centralization and the economic incentives that promote security in PoS, providing a more thorough explanation that directly relates to the question.

See public link to the detailed comparison for the full picture.

Without ICA (default)

❯ ./ditana-assistant "Can you explain how the proof-of-stake consensus mechanism differs from proof-of-work in blockchain technology?"
                    is English: "Can you explain how the proof-of-stake consensus mechanism differs from proof-of-work in blockcha..."
  does not refer to a computer: "Can you explain how the proof-of-stake consensus mechanism differs from proof-of-work in blockcha..."
not suitable for Wolfram|Alpha: "Can you explain how the proof-of-stake consensus mechanism differs from proof-of-work in blockcha..."

Certainly! In blockchain technology, both proof-of-stake (PoS) and proof-of-work (PoW) are consensus mechanisms used to validate transactions and secure the network.

Proof-of-work requires miners to solve complex mathematical puzzles in order to validate transactions and create new blocks. This process is energy-intensive and requires significant computational power. Miners compete to solve these puzzles, and the first one to do so is rewarded with newly minted cryptocurrency.

On the other hand, proof-of-stake does not require miners to solve complex puzzles. Instead, validators are chosen to create new blocks based on the amount of cryptocurrency they hold and are willing to “stake” as collateral. Validators are selected to create new blocks based on various factors, such as the amount of cryptocurrency they hold and how long they have been staking it.

One key difference between PoS and PoW is the energy consumption. PoW requires a significant amount of energy to solve the puzzles, leading to concerns about its environmental impact. PoS, on the other hand, is considered to be more energy-efficient since it does not require the same level of computational power.

Additionally, PoS is often seen as more secure and resistant to certain types of attacks, such as the 51% attack, where a single entity controls the majority of the network’s mining power. In PoS, an attacker would need to control the majority of the cryptocurrency supply to carry out a similar attack.

Overall, both PoW and PoS have their own advantages and disadvantages, and the choice between the two consensus mechanisms often depends on the specific goals and requirements of the blockchain network.

With ICA

❯ ./ditana-assistant -a "Can you explain how the proof-of-stake consensus mechanism differs from proof-of-work in blockchain technology?"
                             is English: "Can you explain how the proof-of-stake consensus mechanism differs from proof-of-work in blockcha..."
           does not refer to a computer: "Can you explain how the proof-of-stake consensus mechanism differs from proof-of-work in blockcha..."
         not suitable for Wolfram|Alpha: "Can you explain how the proof-of-stake consensus mechanism differs from proof-of-work in blockcha..."
                       contextual query: "How does the energy consumption of the proof-of-stake consensus mechanism compare to that of proo..."
Wolfram|Alpha declined contextual query: "The input cannot be interpreted or no short answer is available."
             answer to contextual query: "The energy consumption of the proof-of-stake consensus mechanism is significantly lower compared ..."

Certainly! Here are the key differences between the proof-of-stake (PoS) and proof-of-work (PoW) consensus mechanisms in blockchain technology:

1. Validation Process:

   • In PoW, miners compete to solve complex mathematical puzzles in order to validate transactions and create new blocks on the blockchain. The first miner to solve the puzzle gets to add the new block to the blockchain.
   • In PoS, validators are chosen to create new blocks based on the amount of cryptocurrency they hold and are willing to “stake” as collateral. Validators are selected based on various factors such as the amount of cryptocurrency they hold and how long they have been staking.

2. Energy Consumption:

   • PoW requires a significant amount of computational power and electricity to solve the mathematical puzzles, leading to high energy consumption. This has raised concerns about the environmental impact of PoW blockchains.
   • PoS is much more energy-efficient as it does not rely on mining and the energy-intensive process of solving puzzles. Validators are chosen based on their stake in the network, reducing the overall energy consumption of the blockchain.

3. Security:

   • PoW is considered to be secure due to the computational power required to solve the puzzles. The idea is that an attacker would need to control a majority of the network’s computational power to manipulate the blockchain.
   • PoS is also considered secure, as validators have a financial stake in the network. If they validate fraudulent transactions, they risk losing their stake, providing an economic incentive to act honestly.

4. Centralization:

   • PoW has been criticized for centralization tendencies, as mining pools with significant computational power can dominate the network.

• PoS is often seen as more decentralized, as validators are chosen based on their stake in the network rather than computational power.

Overall, PoS is seen as a more energy-efficient and environmentally friendly alternative to PoW, while still maintaining security and decentralization in blockchain networks.

5 - The Packages

Ditana follows a modular architecture where functionality is separated into individual Arch packages. This approach enables flexible system configuration, simplified maintenance, and clear dependency management. The packages are organized into three main categories:

5.1 - Core Packages

These packages provide the core functionality of Ditana GNU/Linux. They are carefully maintained to ensure system stability and reliability, with thorough testing of all updates before release. They integrate seamlessly with Arch Linux while providing Ditana-specific enhancements.

Mandatory packages used by the Ditana installer

• ditana-filesystem - This package replaces the standard filesystem package from Arch Linux, providing Ditana-specific customizations and core system files for Ditana GNU/Linux.
• ditana-config-shell - This package provides a common shell configuration for Ditana GNU/Linux, enabling shared configurations between bash and zsh. It is installed as a dependency of ditana-config-bash
• ditana-mirrorlist - This package contains the mirrorlist for Ditana repositories, used by the pacman package manager.

Default packages selectable via the installer’s “AI” category

• ditana-assistant - Ditana Assistant is an innovative AI-powered application that combines a graphical user interface with terminal functionality and, optionally, introspective contextual augmentation via Wolfram|Alpha. Even without Wolfram|Alpha, the Introspective Contextual Augmentation (ICA) enhances AI responses in many cases. It leverages Large Language Models (LLMs) to provide intelligent assistance similar to the native browser interfaces of AI service providers.

Default packages selectable via the installer’s “System Maintenance Tools” category

• zfs-autosnap - This package enables automatic ZFS snapshots during system updates. It automatically excludes the pacman lock file from snapshots to the state after a restrollback is as expected.

Default packages selectable via the installer’s “Network and Security Tools” category

• ditana-network - This package enables basic networking capabilities on the system. This includes configuration of DNSSEC and DNS over TLS for secure, encrypted DNS, fully integrated with systemd-resolved to ensure consistent and reliable name resolution. Additionally, it enables the Network Time Synchronization systemd service.

Default packages selectable via the installer’s “Storage & File System Options” category

• ditana-ramdisk - This package provides a user-specific RAM disk service for Ditana GNU/Linux, offering fast, temporary storage with enhanced privacy and organization.

Dependencies of ditana-config-xfce

• ditana-print-system-infos - This package provides a script to print system information in Ditana shells.

Optional packages selectable via the installer’s “Development Tools and Libraries” category

• ditana-update-from-skel - This package provides a Ditana-specific script to update a user’s home directory with files from /etc/skel.

Packages available for manual installation

• ditana-testing-mirrorlist - This package provides a testing mirrorlist for Ditana, used for development and testing purposes. It is required to use build.sh on the testing branch. In this case, an ISO will be generated the references not the default mirrorlist, but the this one.

5.2 - Configuration packages

Configuration packages handle various aspects of system setup and optimization in Ditana. These packages contain scripts, configuration files, and utilities that automate system configurations while maintaining transparency and user control. They handle tasks such as hardware detection, performance optimization, and security settings.

Each package in this category focuses on the configuration of a specific application, making the system both modular and maintainable. Users can selectively enable or disable features while maintaining system stability.

Mandatory packages used by the Ditana installer

• ditana-config-bash - This package provides bash-specific configurations for Ditana GNU/Linux, complementing the common shell configurations.

Default packages selectable via the installer’s “Terminal Tools and Utilities” category

• ditana-config-zsh - This package provides zsh-specific configurations for Ditana GNU/Linux, complementing the common shell configurations.
• ditana-config-micro - This package provides a preconfigured setup of the micro text editor for Ditana GNU/Linux, optimizing it for a seamless and efficient terminal-based editing experience.

Default packages selectable via the installer’s “AI” category

• ditana-koboldcpp - Ditana KoboldCpp is a systemd service that runs KoboldCpp with the Gemma language model locally, providing you with private AI chat capabilities on your PC.
• ditana-config-logseq - This package provides a preconfigured setup of Logseq with its GPT-3 OpenAI plugin, tailored for use with a local KoboldCpp instance.

Default packages selectable via the installer’s “System Maintenance Tools” category

• ditana-config-coredumps - This package disables coredumps for security reasons. You can temporarily allow them with ulimit -c unlimited (see details on GitHub).

Dependencies of ditana-config-xfce

• ditana-config-kitty - This package provides the Ditana’s custom configuration for the kitty terminal emulator.

Optional packages selectable via the installer’s “Development Tools and Libraries” category

• ditana-config-vscode - This package provides a preconfigured setup of the Open Source build of Visual Studio Code for Ditana GNU/Linux, optimizing it for an enhanced coding experience.

5.3 - Ditana Desktop Enhancements

Desktop enhancement packages extend the functionality of the Ditana desktop environment. These packages focus on improving user experience, productivity, and system integration when running Ditana with a graphical interface. They include customized XFCE components, system tray utilities, and various desktop tools.

Each package in this category is designed to integrate seamlessly with the base desktop environment while providing additional features and optimizations specific to Ditana’s desktop experience. These packages are installed if the user selects to install a Desktop Environment during installation.

• ditana-config-xfce - This package is installed when users select a desktop environment in the Ditana installer, providing configuration and customization for XFCE. The package manages system-wide settings and user-specific defaults to ensure an optimal experience with high-DPI displays, desktop panels, font configurations, and system behavior.
• xfce-display-config-observer - Monitors display changes to automatically adjust the font DPI to match the display DPI and adjust the height of the XFCE panel based on the display’s physical size.
• xfce-wallpaper-overlay - Automatically overlay text and images on XFCE wallpapers.
• ditana-print-system-load - This package provides a script to display system load and resource usage in the XFCE panel of Ditana GNU/Linux.

5.4 - Packaged External Sources

These packages contain external resources that are not available as official Arch packages or in the AUR. To ensure easy installation and updates through Ditana’s package management system, we maintain Arch packages for these external sources. This allows users to install and manage these resources through pacman, integrating them seamlessly into the standard package management workflow.

• kora-yellow-icon-theme - This package provides the Kora Yellow Icon Theme for Ditana GNU/Linux and other Arch-based systems. It is installed if the user selects to install a Desktop Environment during installation. Many thanks to bikass, the author of the Kora Icon Theme, for creating this beautiful and versatile icon set. We highly appreciate their work and contribution to the Linux desktop customization community.

5.5 - Repackaged AUR Contributions

Unlike the packages in other categories, the following do not have Ditana-specific GitHub repositories. These packages are built directly from the Arch User Repository (AUR) and are provided in the Ditana package repository for seamless installation via pacman. They are repackaged because they are either dependencies for other Ditana-specific packages listed in the previous categories, or for the Ditana installer.

Packages that are not installed, but the Ditana installer uses them

• rakudo-bin - The Ditana installer is written in Raku.

Optional packages selectable via the installer’s “Hardware Support Options” category

The Ditana installers offers to install these packages in case the PCI ID of the graphics card is documented by NVIDIA to require a legacy driver. For even older graphics cards, the Ditana installer recommends the use the Nouveau driver instead.

• nvidia-470xx-dkms
• nvidia-525xx-dkms

Packages required if the installer detects a B43 Wi-Fi device

• b43-firmware

Packages required if the ZFS filesystem is selected in the installer

• zfs-dkms - Kernel modules for the Zettabyte File System.
• zfs-utils - Userspace utilities for the Zettabyte File System.

Optional packages selectable via the installer’s “Desktop Applications” category

• Back In Time - A straightforward backup tool that provides an easy-to-use interface for restoring previously saved snapshots of your file system.
• ZapZap - A reliable WhatsApp desktop application that avoids heavy CPU load in browsers. It allows you to paste images directly into a chat.

Dependencies of ditana-config-xfce, which is installed if the user selects a desktop installation:

• dracula-gtk-theme - The dark theme used for Ditana’s XFCE desktop.
• kalu - Upgrade notifier with AUR support, watched (AUR) packages, news. It is a small application that will add an icon to your systray and sit there, regularly checking if there’s anything new for you to upgrade. As soon as it finds something, it’ll show a notification to let you know about it.
• lightdm-settings - A configuration tool for the LightDM display manager.
• mugshot - Program to update personal user details. This is no dependency of XFCE packages, but it is directly used by XFCE and required to avoid error message «Failed to edit profile».

Optional packages selectable via the installer’s “AI” category

Dependencies of Ditana Assistant:

• python-proxy_tools - Simple proxy implementation for Python.
• python-pywebview - pywebview is a lightweight cross-platform wrapper around a webview component that allows to display HTML content in its own native GUI window. It gives you the power of web technologies in your desktop application, hiding the fact that the GUI is browser based. Available for Windows, macOS, Linux and Android. You can use pywebview either with a 3rd party web framework or on its own with a two way bridge between Python and DOM.

Dependencies of ditana-config-logseq:

• logseq-desktop-bin. More than just a note-taking app, Logseq serves as a comprehensive platform for organizing thoughts, managing tasks, and building knowledge databases. In Ditana, Logseq is specially configured to leverage the local AI powered by KoboldCpp. This integration enables AI-assisted note-taking, content generation, and knowledge management, all while maintaining privacy and security. Ideal for anyone looking to enhance their intellectual workflow with the power of AI, without compromising on data privacy.

Optional packages selectable via the installer’s “Repository & Package Management Configuration” category

• PacUI - A convenient text-based graphical interface that supports quick browsing of available installation packages (including AUR) and their installation. In addition, pacui provides advanced commands, such as package dependency trees. It also uses fwupd to install firmware updates. For AUR, it supports pikaur, which is the default AUR helper on Ditana. In case of a Ditana desktop installation, PacUI is pinned to the dock.

Optional packages selectable via the installer’s “System Maintenance Tools” category

• rate-mirrors - An everyday-use client-side map-aware mirror ranking tool. This is also used by the Ditana Installer to find fast mirrors for the installation.

Optional packages selectable via the installer’s “Network and Security Tools” category

• Bubblejail - A sandboxing utility that provides application isolation without parallel packaging systems. It implements a resource-oriented permission model, enhanced by seccomp and D-Bus filtering. Key features include:
  • Fine-grained control over application permissions and resource access
  • X11/Wayland display server integration
  • Custom home directory isolation per application
  • User-friendly graphical interface for sandbox configuration

Optional packages selectable via the installer’s “Development Tools and Libraries” category

• auracle-git - A flexible client for the Arch User Repository (AUR). It provides advanced features for managing and searching AUR packages (not installation).
• stress-ng - Software to stress test a computer system in various selectable ways.

Dependencies of ditana-config-vscode

• code-marketplace - Enable vscode marketplace in the Open Source Build of Visual Studio Code.