Design Philosophy

• 1: Why Arch?
• 1.1: Unified Package Management
• 1.2: Security and Transparency in Package Management
• 1.3: Embracing Arch’s Unified Package Management Philosophy
• 1.4: Comprehensive File Tracking: The Ditana Advantage
• 1.5: The Confinement Dilemma: Why Snap & Similar Solutions Aren’t Always Ideal
• 1.6: Questioning the Myth of Stability in Traditional Release Cycles
• 1.6.1: Boost Library Example: Timely Updates and API Stability
• 1.6.2: Incidents with rolling release distributions
• 1.7: Rolling Release Model Minimizes the Need for AppImage
• 1.8: Final Thoughts
• 2: Why Raku?
• 3: Best practices
• 3.1: Software Installations
• 3.2: Automatic System Snapshots
• 3.3: Desktop

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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 - 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

3 - Best practices

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

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.

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.