New FHS for Nitrux

[UriHerrera]

Introduction

Given that our focus is not to use a package manager but to use AppImages exclusively, this is the next evolutionary step with Nitrux, and a cleaner directory tree would be indicative of this. With Nitrux we want to make use of AppImages for desktop applications and CLI tools, but for the rest of the operating system like libraries or other binaries, we are considering other similar means to achieve our goals of making Nitrux a modern operating system.

What is an FHS?

An FHS or Filesystem Hierarchy Standard is a standard that defines the directory structure and directory contents in Linux distributions.

Directory structure

In the FHS, all files and directories appear under the root directory even if they are stored on different physical or virtual devices. Some of these directories only exist on a particular system if specific subsystems, such as the X Window System, are installed.

Most of these directories exist in all Unix-like operating systems and are generally used in much the same way; however, the descriptions here are those used specifically for the FHS and are not considered authoritative for platforms other than Linux.

Are you crazy? Why?! Leave mah Linux alone >:(

The primary motivation is "KISS." No, not the rock band but the principle.

The KISS principle states that most systems work best if they are kept simple rather than made complicated; therefore, simplicity should be a key goal in design, and unnecessary complexity should be avoided.

Therefore we want simplicity. Obtaining and managing software is as easy as managing a single file (by using AppImages), and the same applies to the operating system itself with znx which manages immutable operating systems as single files in a device.

In Nitrux, the use of a package manager is not an integral part of the user experience.

We want to create a modern operating system and progress means making changes.

How can this new FHS be implemented?

We took inspiration from various sources when devising the FHS. The basic idea is to use multiple bundles that would be contained within the ISO and have each "bundle" include the Linux FHS separated in accordance to a more friendly categorization.

In NeXTSTEP, OPENSTEP, GNUstep, and their lineal descendants macOS and iOS, a bundle is a file directory with a defined structure and file extension, allowing related files to be grouped as a conceptually single item.

The "bundles" would be categorized like this:

• Core
• Firmware
• DisplayServer
• Desktop, and
• Applications

To the user only /Core, /Firmware, /DisplayServer. /Desktop and /Applications are visible in the root directory, but the contents are those of /bin, /lib/, /usr and so on

The structure that would be visible in the storage device would be like this:

storage_device
├─── ZNX_BOOT (partition)
│    ├─── /boot
│    │    └─── grub
│    ├─── /efi
│    │    ├─── boot
├────└────└────└─── bootx64.efi
├─── ZNX_DATA (partition)
│    ├─── /store
│    │    ├─── /os_1
│    │    │   ├─── /version_1
│    │    │   │   ├─── /data
│    │    │   │   │   ├─── /user_1_data (home directory)
│    │    │   │   │   └─── /user_2_data (home directory)
│    │    │   │   ├─── image (ISO)
│    │    │   │   │   ├─── /core.bundle
│    │    │   │   │   │   ├─── /bin
│    │    │   │   │   │   ├─── /lib
│    │    │   │   │   │   ├─── /usr
│    │    │   │   │   │   ├─── /var
│    │    │   │   │   │   └─── ...
│    │    │   │   │   ├─── /firmware.bundle
│    │    │   │   │   │   ├─── /lib
│    │    │   │   │   │   ├─── /firmware
│    │    │   │   │   │   └─── ...
│    │    │   │   │   ├─── /displayserver.bundle
│    │    │   │   │   │   ├─── /lib/udev
│    │    │   │   │   │   ├─── /usr
│    │    │   │   │   │   ├─── /var
│    │    │   │   │   │   └─── ...
│    │    │   │   │   ├─── /desktop.bundle
│    │    │   │   │   │   ├─── appimage_1
│    │    │   │   │   │   └─── ...
│    │    │   │   │   └─── /applications.bundle
│    │    │   │   │   │   ├─── appimage_1
│    │    │   │   │   │   ├─── appimage_2
│    │    │   │   │   │   ├─── appimage_3
│    │    │   │   │   │   └─── ...
└────└────└───└───└─── image_bak (ISO backup)

Each "bundle" would be mounted using the OverlayFS driver similarly to what we already do. And as mentioned to the user instead of finding these directories in the root folder:

/
├─── /bin 
│    ├─── bin_1
│    ├─── bin_2
├────└──── ...
├─── /boot  
│    ├─── dir_1
│    ├─── file_1
├────└──── ...
├─── /cdrom  
├────└──── ...
├─── /dev  
├────└──── ...
├─── /etc  
├────└──── ...
├─── /home
└────└──── ...
...

The user would only see these directories instead:

/
├─── /Core 
│    ├─── /dir_1
├────└─── ...
├─── /Firmware 
│    ├─── /dir_1
├────└─── ...
├─── /DisplayServer 
│    ├─── /dir_1
├────└─── ...
├─── /Desktop 
│    ├─── appimage_1
├─── /Applications 
│    ├─── appimage_1
└────└─── ...
...

This arrangement may seem familiar to the way that GoboLinux is structured. Like GoboLinux the Nitrux FHS is structured in an array of descriptive directories, e.g.,/Desktop contains the AppImage for the desktop shell; however, unlike GoboLinux we do not aim to structure each program within its subdirectory tree, where all of its files (including settings specific for that program) may be found since for that purpose we are utilizing AppImages.

Like GoboLinux and NixOS, Nitrux allows the user to have different versions of the same program installed concurrently (and even run them simultaneously).

Unlike GoboLinux but like NixOS Nitrux provides atomic upgrades via znx, this means that if the update to a new configuration is interrupted – say, and the power fails half-way through – the system will still be in a consistent state: it will either boot in the old or the new configuration. In other operating systems, a machine might end up in an inconsistent state, and may not even boot anymore.

Also, like NixOS Nitrux via znx provides the ability to perform rollbacks. If the new configuration crashes or does not boot properly, an older version can be selected.

What do you even want to achieve with this?

A benefit, for instance, is that it would allow, for example, an OEM to provide the UI component (/Desktop) or any other element as a separate part of the operating system, allowing for easy updates, easy rollbacks, and easy maintaining.

This FHS is a departure on how popular Linux distributions work on the desktop and is more familiar with how a mobile OS works making it a convergent system.

Notes

• We need to evaluate the requirements for this proposition.
• And, have an estimate of how long will it take.

[UriHerrera]

Topics of interest:

• From the creator of AppImage https://github.com/probonopd/hello/wiki

Desktop operating system with a focus on simplicity and usability (think Macintosh System 1).
Based on the Linux kernel but without the complexities of normal Linux distributions.

• Slax internals. https://www.slax.org/internals.php

Various parts of the final root filesystem are now mounted read-only under separated folders in /memory/bundles.

• What is standard for OS X filesystem? e.g. /opt/ vs. /usr/ https://apple.stackexchange.com/questions/119230/what-is-standard-for-os-x-filesystem-e-g-opt-vs-usr

• Also: Access the Root Directory in Mac OS X in 4 Ways Quickly https://osxdaily.com/2013/01/17/access-root-directory-mac-os-x/

macOS and Mac OS X lean on the cautious side and hides most root directory contents from the Finder by default.

Programs of interest:

• bindfs.

The bindfs filesystem is a FUSE filesystem that creates a view of a directory tree. For example, the command bindfs /some/where /else/where

• filterfs apparently it's dead

FilterFS (Filter File System) is a FUSE-based virtual filesystem that allows filtering existing filesystems. Filters consist of include/exclude rules which are stored in a filter chain, similar to the way iptables stores IP filtering rules for network packets.

• filterfs looks like it's a GO implementation of FilterFS (2 years old).

• filterfs looks like it's a Python implementation of FilterFS (12 years old).

• GoboHide requires kernel patching and userland tool.

  • GoboHide: surviving aside the legacy tree
  • Gobohide kernel extension

[UriHerrera]

Implementation of the new directory structure

To move forward, we need to organize how the structure will be; this is an example.

 /boot/ -> /Core/Boot
 /cdrom/ -> /Core/Boot/ESP
 /dev/ -> /Devices
 /etc/ -> /System/Configuration
 /home/ -> /Users
 /isodevice/ -> /Core/System/Deployments
 /media/ -> /Devices/Removable
 /mnt/ -> /System/Mount/Filesystems
 /opt/ -> /System/Binaries/Optional
 /proc/ -> /System/Processes
 /run/ -> /System/Runtime
 /srv/ -> /System/Server/Services
 /sys/ -> /System/DevicesFS
 /tmp/ -> /System/TempFS
 /usr/bin/ -> /System/Binaries
 /usr/lib/ -> /System/Libraries
 /usr/share/ -> /System/Resources/Shared
 /var/ -> /System/Variable

Most would be under /System, and as per the original idea, the names are descriptive of their contents.

The example is an early attempt to move through with this, as there's still no implementation of the bundles in place.

[UriHerrera]

Progress

The following pictures are a partial implementation of the above structure. Works as intended, but there's the side effect that the sidebar of Index is cluttered.

[UriHerrera]

Update

So, it's almost four years since we last checked this.

TL;DR

I've reimplemented the FHS in what would be the next release. It's visible in both the Live session, as when we used znx, and now visible in an installed system, as we use Calamares.

Also, it's visible using Index or other graphical file managers and command-line commands like ls and tree, using the magic of not patching stuff.

It's still not exactly what I proposed, but it's good enough for me.

Here are some screenshots.

Using ll in the Live session.

Using `tree ' in the Live session.

Using Index in the Live session.

---

I'll move this to a discussion because we can still take it further.