At Nitrux, we’re always looking forward to the next thing that we will imagine and code for our Linux distribution. We’re ever thinking how far we can go and how now can we take Nitrux to its next milestone for it to become an operating system for the future; for everyone.
Early this year, we set out to reveal some of our plans, and among them were the basis to create a modern operating system. Nitrux is characterized for being a unique take on desktop operating systems, with its focus 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 how the operating system itself is organized.
Nitrux System Core Foundation
Starting with the first topic, we plan to create a reliable OS that will serve as the basis of which we build 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, much of 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, being built for new device types such as smart devices, the 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 entire new features for devices where it makes sense.
znx inner-workings diagram.
New FHS for Nitrux. An FHS or Filesystem Hierarchy Standard is a standard that defines the directory structure and directory contents in Linux distributions.
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.
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. 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, 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.
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
- 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, 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.
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, and this is something we unveiled a while back and is part of Nitrux. Fundamentally, we have reworked the OS image so that updates are no longer interruptive to the user. On Nitrux SCF devices, updates behave much like they do on Android, except faster.
When an update is ready to install, it’ll do so utilizing atomic transactional updates, this makes the restart process incredibly quick, just as if you were rebooting like normal.
This feature reduces update downtime to less than 30 seconds, in most cases, even quicker than that. Once the OS boots back up, it’ll open everything exactly where you left it, too.
Secure by default
The previous area leads us into the next thing, security by default. The OS image is partitioned in such a way that the root filesystem is read-only except for some directories. The user gets access to 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, 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. What we are referring to here is Maui Shell, Nitrux’s new, universal shell that’s 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 will be able to adapt Nitrux SCF for any device form factor, even ones that don’t yet exist. We will be able to 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.