The road to Nitrux 1.1: Pre-release available! v1.1.0
The best way to predict the future is to create it.
– Peter Drucker
A while back I talked about the fundamental changes that were coming to the next version of Nitrux here
These changes are now a reality, and we are happy to present a pre-release ISO image of Nitrux 1.1. Both of our projects, MauiKit, and znx make their debut in this pre-release of Nitrux.
MauiKit is our UI framework for developing convergent applications that work on Linux, Android and Plasma Mobile and znx is our operating system deployment tool and manager.
We were hoping to push this ISO during the release of Nitrux 1.0.16. Unfortunately, we had issues to resolve before we could provide a usable system that worked as a testbed for our emerging technologies. So, what’s different from our previous releases?.
Maui Applications
In this pre-release version of NItrux, we have included five applications that make use of our UI framework. Index (file manager), VVave (music player), Pix (image gallery), Buho (notes) and a preview of the Software Center.
The applications are also available for Android except for the Software Center.
For this pre-release, we have not replaced the KDE counterparts just yet since the primary focus is to receive feedback to improve the applications before we can do the switch.
znx
On the other hand, znx is now our default method for deploying the distribution replacing the traditional Calamares. However, we are not replacing an installer with another installer; this is because znx is not an installer.
znx follows the concept of AppImages which is that software isn’t “installed” but it is instead deployed.
We have aimed to make znx simple and easy. Simple to understand and maintain and easy to use for potential users.
What does it do?
znx deploys the ISO image into the storage device, makes the device bootable and creates the data partition where the user data is kept across reboots. Once that the ISO has been deployed the user can restart and boot into the storage device to select the system.
How is it different than using an installer?
znx follows the concept of AppImages which is that software isn’t “installed” but it is instead deployed.
That means that you don’t get lots of files and folders spread in a filesystem but just one file, same with znx, instead of unpacking the squashfs file (the compressed filesystem that holds the actual OS) and extracting the contents to the target device (thus “installing” the OS the traditional way). The OS remains as one file which can be updated using a zsync file for differential updates (so-called delta updates which is what znx does, similarly, AppImageUpdate performs updates to AppImages only updating the bits that changed) or replacing the entire file, i.e., downloading a new ISO that replaces the old one.
Where is my data stored then?
Any file that the user creates is kept in the data partition in /data. To install new software (by the software we mean desktop applications like Firefox, LibreOffice, etc.) the go-to method would be to get an AppImage. These AppImages would go in /applications where they would be kept when the user updates the deployed ISO to a new version.
Alright, but what would be the benefits of using znx?
An immediate benefit is that multiple systems can be deployed at once which allows the user to perform rollbacks and switch between them. When a new version of the distribution is available, the user would only have to download the differential zsync file instead of having to reinstall the system, think like OTA updates on mobiles. Or instead of having to rely on pre-compiled binary packages (like Debian packages, RPM packages, etc.) that can lead to unmet dependencies, broken packages, and related inconveniences during full-system upgrades the user would download the new version entirely or use the differential zsync file.
It also would provide a way to have a factory reset method available at any moment, i.e., immutable filesystems. Or for businesses znx would be able to offer an OEM-mode that would facilitate the deployment of the operating system.
For this pre-release of Nitrux, we have also included a simple GUI to use znx. This GUI is temporary, and it is also constrained since it has been created using KDialog.
Notes about using znx
Using znx means that there’s no manual partitioning required. znx also takes over the storage device to manage it. Initializing a storage device with znx means that it will be using a GPT Partition Table with the storage device, so only UEFI/EFI systems are compatible with znx, please refer to your motherboard manual to check for EFI compatibility.
Neither MBR or Legacy BIOS systems are supported with znx.
Software Center
In Nitrux 1.0.16 we introduced a newer version of the Software Center. This version notably includes one significant new feature, its backend.
Our backend which you can find here
Automatically lists AppImage files which then can be parsed by the Software Center, meaning that there’s no central repository to maintain and as a user you are getting the files directly from the developer.
In this pre-release of Nitrux 1.1, we also include a preview version of the Software Center that utilizes MauiKit components. Currently, the Software Center uses Plasma UI components which is why its interface is dark while the other applications use a light theme.
Notes about the Software Center
I would like to emphasize that this version of the Software Center is a preview and that the scraper is not final. I would want to put emphasis once more in that the go-to method to obtain new software in Nitrux is to download an AppImage; not APT/dpkg and not Snaps.
If you’d like to know why we made this decision, please read this article
Deploying Nitrux 1.1.0
Please check this article to learn how to deploy an ISO with znx
You can use either the terminal or the GUI.
Reporting issues
For issues with this pre-release, please go here
Download
You can download the ISO from opendesktop.org
https://www.opendesktop.org/p/1188112/
The release date for the formal release will be on October 26th.
