At Nitrux, we always look forward to the next thing we imagine and code for our Linux distribution. We’re always thinking about how far we can go and how now we can take Nitrux to its next milestone, which is to become an operating system for the future—for everyone.
Early this year, we revealed some of our plans, including the basis for creating a modern operating system. Nitrux is characterized as a unique take on desktop operating systems, focusing on genuinely portable applications in the form of AppImage and managing operating systems as a single file. Still, we’re not stopping there; we want to extend this concept to the operating system’s organization.
Nitrux System Core Foundation
Starting with the first topic, we plan to create a reliable OS that will serve as the basis for building our Linux distribution; we call this Nitrux SCF or Nitrux System Core Foundation, which is not a continuation of our current releases. The current versions of Nitrux are built on decades of legacy code and backward compatibility support, which is unnecessary to most users’ workflows in 2019. Nitrux System Core Foundation aims to rectify this, turning it into a modular platform that’s universal across devices and can be built upon with ease.
It’s mostly the next generation of Nitrux, built for new device types such as smart devices, next-generation smartphones, and other new and unique kinds of PCs.
It’s one OS that can adapt and change to fit on any device where necessary, with little effort on our part. It can reuse code, features, and shell experiences if required or build out new features for devices where it makes sense.
znx inner-workings diagram.
A new FHS for Nitrux. An FHS, or Filesystem Hierarchy Standard, defines the directory structure and contents in Linux distributions.
Given that our focus is not on using a package manager but on using 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 consider other similar means to make Nitrux modern.
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. 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 individual files in a device.
In Nitrux, a package manager is not integral to the user experience. We want to create a modern operating system; progress means making changes.
When devising the FHS, we took inspiration from various sources. The basic idea is to use multiple bundles within the ISO and have each “bundle” include the Linux FHS separated per 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
- Display Server
- 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)
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; for example,/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 consistent; 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, it can perform rollbacks. An older version can be selected if the new configuration crashes or does not boot properly.
Diagram of a storage device managed by znx.
Critical areas in Nitrux SCF
- Seamless updates.
- Secure by default.
- Sustained performance.
- Form factor agility.
Seamless updates
One of the features we mentioned is seamless updates, which we unveiled a while back and are part of Nitrux. Fundamentally, we have reworked the OS image so that updates no longer interrupt the user. On Nitrux SCF devices, updates behave much like Android, except faster.
When an update is ready to install, it uses atomic transactional updates. This makes the restart process incredibly quick as if you are usually rebooting.
This feature reduces update downtime to less than 30 seconds and, in most cases, even quicker. Once the OS boots back up, it’ll open everything exactly where you left it, too.
Secure by default
The previous area leads us to the next thing: security by default. The OS image is partitioned so the root filesystem is read-only except for some directories. The user can access its data, but other system files are not editable.
Unlike a Live system, when Nitrux is deployed using znx, it keeps all the data in your home folder even after the next time you boot. This feature is known as persistence. Using this feature of znx allows Nitrux to offer an immutable operating system. In other words, no changes will take place in the root directory.
Sustained performance
When it comes to performance, Nitrux SCF should remain fast and smooth. Thanks to a modern shell experience and apps, we have gutted many legacy components and features that would otherwise bog down the OS. Nitrux SCF can also instantly bring you back to what you were working on when turning on the device.
Form factor agility
This one is the most interesting. We refer to Maui Shell, Nitrux’s new, universal shell designed to complement Nitrux SCF. With Maui Shell, we can build many different shell experiences and share them across devices, in some cases bundling multiple shells that can be enabled and disabled where necessary, depending on the form factor or mode.
In short, this means Nitrux can adapt Nitrux SCF for any device form factor, even ones that don’t yet exist. We can build shell experiences that fit perfectly on new form factors and allow them to switch between different experiences depending on whether the device is a 2-in-1, 3-in-1, or some other kind of hybrid that doesn’t yet exist.