Skip to main content
Close Search
Nitrux — #DisruptiveByDesign — Official WebsiteNitrux — #DisruptiveByDesign — Official Website
search
Menu
  • x-twitter bluesky facebook youtube github instagram telegram mastodon threads email
  • search
  • Menu
Nitrux — #DisruptiveByDesign — Official Website
  • Nitrux Core Concepts 9
    • Distribution Philosophy
    • System Architecture
      • Immutable Architecture
      • Rootless App Model
      • Aesthetic FHS
      • Init System
      • Language Stratification
      • Workspace Environment
    • Workspace Architecture
      • Workspace Compartmentalization
      • Nitrux Workspace Session Manager
  • Getting Started 20
    • System Requirements
      • Hardware Compatibility Validation Layer
      • Minimum Requirements
      • Recommended Requirements
    • Installation Guide
      • Download the ISO
        • ISO for AMD and Intel Hardware
        • ISO for NVIDIA Hardware
      • Validate the ISO
        • ISO Integrity Validation
        • ISO Authenticity Validation
      • Flashing the ISO
        • USB Flash Preflight
        • Rufus (Windows)
        • Ventoy (Windows/Linux)
        • dd (*nix)
      • Installing Nitrux
        • Nitrux Installation Process Information
        • Using Secure Boot with Nitrux
        • Automated Partitioning Options
        • Non-automated Partitioning Options
        • Full-disk Encryption in Nitrux
        • Single-booting Nitrux
        • Dual-booting Nitrux with Windows or other Linux distributions
        • Triple-booting Nitrux, Windows, and other Linux distributions
        • Report Installation Bugs
  • Workspace and UX 10
    • Workspace Applications
      • Default Software Selection
      • Workspace Settings
    • Workspace Defaults
      • greetd + QMLGreet
      • Hyprland
      • Valenz
      • Marina
      • Vicinae
      • QMLogout
      • NudgeOSD
      • Workspace Daemons
        • Default Session Daemons
  • Software Management 4
    • Graphical Software Manager (AppFinder)
    • User Application Delivery
      • NX AppHub and AppBoxes
      • Flatpak
    • Development Environments
      • Distrobox
  • Security and Privacy 6
    • Security Features
      • System Security Features
    • Security Policies
      • Identity and Access Management
      • Kernel and Memory Hardening
      • Network Security and Privacy
      • Session Hardening
      • Bluetooth Security
  • System Performance 4
    • Filesystem Optimizations
      • XFS Features in Nitrux
      • F2FS Features in Nitrux
    • System Optimizations
      • Advanced Memory Management
      • Performance and I/O
  • System Management 5
    • System Administration
      • Nitrux Update Tool System
      • NX Overlayroot
      • Nitrux GRUB Modes
    • System Configuration
      • SB Manager
      • Kernel Boot
  • Troubleshooting 21
    • FAQ
      • Is Nitrux right for me?
      • Is Nitrux eating my RAM?
      • NVIDIA Driver Information
      • Virtualizing Nitrux
      • Support for Other Desktop Environments
      • Flatpak Information
      • Energy Saving Information
      • Virtual Consoles (TTY) Information
      • GRUB Menu Information
      • KDE Wallet Information
      • NetworkManager Information
      • Backups Information
      • General Gaming Information
      • AppImage Information
      • MauiKit UI Framework Information
    • Installation Issues
      • ISO doesn’t boot or System installs, but there's no GUI
      • Can't install due to the MBR partition limit
      • Can't install due to mounted Swap partitions
      • Failure to install due to an issue with rsync error code 11
      • Failure to install GRUB on a computer with multiple storage devices or using the MBR partition table
      • Installation is successful, but user data isn't persistent
  • Resources 2
    • Tutorials
    • Get Involved

Aesthetic FHS

1 min read

75 views

The traditional Filesystem Hierarchy Standard uses abbreviated, historically derived names (/etc, /usr, /var, /sbin) that obscure their purpose. Aesthetic FHS replaces this structure with human-readable paths that communicate intent directly.

This tree diagram is an initial implementation of a proposed filesystem hierarchy for Nitrux.

/Applications               System-wide bundles

/System                     System components
├── Binaries                Non-AppImage system-wide binaries
│   ├── Administrative      For administrative tasks (openrc, agetty, init, haveged)
│   ├── Optional            User-installed system-wide binaries (VirtualBox, DisplayLink)
│   └── Standard            For non-administrative tasks (pix, index, tree, rm, top)
├── Boot                    Kernel, initramfs, and GRUB files
├── Configuration           System-wide configuration files
├── Devices                 Device nodes
├── Filesystems             Mount points for storage devices
│   ├── Internal            Internal storage devices
│   └── External            External storage devices
├── Libraries               System-wide libraries
├── Shareable               System-wide resources
└── Variable                Variable system data

/Users                      User home directories

Rationale

A user encountering /System/Configuration immediately understands its purpose. A user encountering /etc must already know Unix conventions. Aesthetic FHS prioritizes legibility over tradition.

Relationship to Immutability and the Rootless App Model

Aesthetic FHS reinforces the boundaries established by the immutable root-and-rootless app model.

/System contains the OS; this is the immutable layer. Everything under /System belongs to Nitrux and remains read-only under normal operation. The naming makes this relationship explicit: modifying /System means modifying the root itself, which requires deliberate action via overlayroot-chroot

/Users sits outside /System. It is the writable layers where user activity happens. AppBoxes installed via NX AppHub, Flatpaks, and Distrobox containers land in the user space.

The hierarchy visually separates what Nitrux controls from what users control:

/System → Immutable (Nitrux)
/Users  → Writable (user space)

Traditional FHS scatters these concerns across /usr, /opt, /home, /etc, and /var without clear boundaries.

Aesthetic FHS makes the architecture legible.

Updated on 4 October, 2026
Previous - System ArchitectureRootless App ModelNext - System ArchitectureInit System
Close Menu
  • Documentation
  • Bug Tracker
  • Blog
    • Tutorial
    • News
    • Other
    • Blog Archive
      • News and Tutorial Archive
      • Maui Archive
      • ZNX Archive
      • VMetal Archive
      • PNX Archive
  • x-twitter
  • bluesky
  • facebook
  • youtube
  • github
  • instagram
  • telegram
  • mastodon
  • threads
  • email

© 2017-2026 Some Rights Reserved. Made with ♥ by Nitrux Latinoamericana S.C.