Why Arch?

• 1: Unified Package Management
• 2: Security and Transparency in Package Management
• 3: Embracing Arch’s Unified Package Management Philosophy
• 4: Comprehensive File Tracking: The Ditana Advantage
• 5: The Confinement Dilemma: Why Snap & Similar Solutions Aren’t Always Ideal
• 6: Questioning the Myth of Stability in Traditional Release Cycles
• 6.1: Boost Library Example: Timely Updates and API Stability
• 6.2: Incidents with rolling release distributions
• 7: Rolling Release Model Minimizes the Need for AppImage
• 8: Final Thoughts

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

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.

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.

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.

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.

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.

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.

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.

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.