Nitrux
New FHS for Nitrux #145
Replies: 4 comments
-
Topics of interest:
Programs of interest:
|
Beta Was this translation helpful? Give feedback.
-
Implementation of the new directory structureTo move forward, we need to organize how the structure will be; this is an example. Most would be under The example is an early attempt to move through with this, as there's still no implementation of the bundles in place. |
Beta Was this translation helpful? Give feedback.
-
ProgressThe 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.
|
Beta Was this translation helpful? Give feedback.
-
UpdateSo, 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 It's still not exactly what I proposed, but it's good enough for me. Here are some screenshots.
I'll move this to a discussion because we can still take it further. |
Beta Was this translation helpful? Give feedback.
-
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 indicate this. With Nitrux, we want to use AppImages for desktop applications and CLI tools. Still, for the rest of the operating system, like libraries or other binaries, we are considering other similar means to make 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
All files and directories in the FHS appear under the root directory, even if stored on different physical or virtual devices. Some 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 similarly; 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 my Linux alone >:(
The primary motivation is "KISS." No, not the rock band but the principle.
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, using a package manager is not integral to the user experience.
We want to create a modern operating system; 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.
The "bundles" would be categorized like this:
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:
Each "bundle" would be mounted using the OverlayFS driver, similarly to what we already do. As mentioned to the user, instead of finding these directories in the root folder:
The user would only see these directories instead:
This arrangement may seem familiar to the structure of GoboLinux. 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 halfway 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. An older version can be selected if the new configuration crashes or does not boot properly.
What would you like to do 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 maintenance.
This FHS is a departure from how popular Linux distributions work on the desktop and is more familiar with how a mobile OS works, making it a concurrent system.
Notes
Beta Was this translation helpful? Give feedback.
All reactions