Skip to content

Mutable Atomicism

Hludwig edited this page Oct 15, 2026 · 6 revisions

Mutable Atomicism is a Linux distribution design philosophy formalized by Zeon (Hludwig), a developer affiliated with the NextFerret organization, in the year 2026. The philosophy proposes a hybrid approach to system architecture, positing that atomic updates and transactional integrity do not inherently require an immutable root file system or the reliance on Open Container Initiative (OCI) image formats. Instead, it advocates for the coexistence of a fully mutable root environment with robust, snapshot-based atomic operations.

Historical Context

The conceptualization of Mutable Atomicism occurred within the broader industry trend of moving toward immutable infrastructure. While many modern Linux distributions adopted read-only root partitions or image-based deployments to ensure system stability, Zeon observed a gap in architectures that preserved traditional administrative flexibility without sacrificing reliability. As a result, the NextFerret organization began developing a framework where mutability and atomicity are treated as complementary rather than mutually exclusive properties. Although transactional and snapshot-based system updates are not entirely unprecedented in the history of systems engineering, Mutable Atomicism serves as a specific formalization of these hybrid models tailored for modern Linux environments. It represents a continued evolution in distribution design, acknowledging prior art in logical volume management and transactional memory while applying these concepts to contemporary package management paradigms.

Core Principles

The philosophy is built upon several foundational tenets that distinguish it from other atomic system models:

  1. Coexistence of Mutability and Atomicity The root file system remains writable and structurally conventional. Users and package managers are permitted to modify files in place, configure system services, and interact with the file system hierarchy without the indirection of layered file systems or container runtimes.

  2. Rejection of Mandatory OCI Imagery System updates and packages are not bound to container image formats. The philosophy holds that atomicity is a property of transactional integrity rather than a property of the delivery format, thereby eliminating the need for OCI-based image distribution.

  3. Rejection of Mandatory Immutability The philosophy explicitly rejects the notion that the root file system must be rendered read-only in order to guarantee consistency. Immutability is viewed as merely one mechanism among many for achieving atomic behavior, and snapshot-based approaches are positioned as capable of providing equivalent guarantees without sacrificing writability.

Implementation in Arvor Linux

Arvor Linux serves as the primary reference implementation of the Mutable Atomicism philosophy. Developed under the NextFerret organization, Arvor Linux integrates the conceptual framework into a functional distribution through two foundational components:

Weld

Weld is the transactional package manager of Arvor Linux. It is a native binary component and the primary interface for package management operations within the distribution. As an entity, Weld represents the package-level abstraction layer of the system. It is designed to operate natively within the Mutable Atomicist paradigm, functioning as the bridge between user intent and the underlying transactional infrastructure. Weld is distinct from traditional package managers due to its inherent integration with the system's snapshot subsystem, ensuring that package management is treated as a series of discrete, recoverable states rather than a sequence of destructive file modifications.

NSM

NSM, which stands for NextFerret Snapshot Manager, is the snapshot management subsystem of Arvor Linux. It is a native binary component responsible for the storage-level abstractions that underpin the atomic nature of the system. As an entity, NSM constitutes the foundational layer of the Mutable Atomicism implementation, managing the logical volume manager snapshots that define the boundaries of system transactions. It is the component that enables the coexistence of a mutable root file system with the guarantees of transactional integrity, serving as the storage-level counterpart to the package-level operations managed by Weld.

Architectural Relationship

Within the Arvor Linux architecture, Weld and NSM operate as complementary, decoupled layers. Weld exists as the package resolution and user-facing interface, while NSM exists as the storage and state management foundation. Together, they form a cohesive realization of the Mutable Atomicist philosophy, ensuring that the system maintains traditional Linux flexibility while providing modern, atomic reliability guarantees.

Wings of Mutable Atomicism

Left Mutable Atomicism

Left Mutable Atomicism

In Left Mutable Atomicism, atomicity must decide for the user, so there are no errors due to user actions. Here, the root of the operating system should be read and write, and no part of the system should be immutable.

Right-Wing Mutable Atomicism

Right-Wing Mutable Atomicism

In Right-Wing Mutable Atomicism, the user must decide on atomicity,User errors are not seen as a problem because of the Rollback system, and sensitive parts like /boot can be immutable, but, just like on the Left, the mutability of / should be non-negotiable.

Pragmatic Mutable Atomicism

Pragmatic Mutable Atomicism

In Pragmatic Mutable Atomicism, anything that works and aligns with Mutable Atomicity should be used to ensure long-term maintenance. Here, atomicity doesn't necessarily have to decide for the user, nor does the user have to decide for it, but the most efficient and sustainable path in the long term should be prioritized.

Pragmatic Left-Wing Mutable Atomicism

Pragmatic-Left Mutable Atomicism

In Pragmatic Left-wing Mutable Atomicism, just like in Pragmatic Mutable Atomicism, anything that conforms to Mutable Atomicity should be used for greater long-term stability and maintainability. However, just like on the left, atomicity should decide for the user, but just like on the right, sensitive parts like /boot can be immutable.

Clone this wiki locally