You might have heard of Nitrux Linux. It was featured on It’s FOSS a couple of years ago.
Many people took it as just another distribution that is based on Ubuntu with a little theme change. That is so wrong!
In this interview with Nitrux founder Uri Herrera, you’ll learn why Nitrux is not just another Linux distribution and how it is adding new dimension to Linux scene with innovative tools like ZNX operating system manager, MAUI for quickly developing desktop and mobile apps and more.
IF: Few people know about the origin of Nitrux project. Could you please provide details about how you changed from a design company to a hardware company to a Linux distribution?
Uri Herrera: Nitrux was founded in 2012 by me (Uri Herrera) as Nitrux S.A. in Mexico. At the time, I was in college studying Graphic Design, so most of the early work was related to that. I created the Nitrux icon theme, the Compass icon theme, the Flattr icon theme, the ZERO icon theme, the Dots icon theme, a theme package for KDE 4 called Nitrux KDE Suite, a couple of GTK themes inspired by MIUI 4 along with many mockups for GUI applications, and other bundles that expanded on the icon themes, all of them are available at DeviantArt.
In 2013 I met Haashir Mohammed, who joined me, and he created many web-based applications for Nitrux like Typer.IM, nDisk, and Muire. Typer.IM was an instant messaging service with p2p file sharing and used WebRTC for calls, both audio and video. nDisk was a cloud storage service, and you could access it with WebDav from your desktop. Muire was a website builder like Weebly, and you could create, save, and export the websites that you created in it.
Throughout 2013 and 2014, we decided to enter the hardware business. We prototyped a small form-factor computer that would run a Linux distribution, so Nitrux OS (which we refer to as Nitrux) originated from this decision. We originally called this small computer the QtBox because we intended to use Plasma 4 in our distribution. Still, we later changed it to NXQ to avoid any problems with the name and also because it tied tightly to our brand (NX). In 2014 I was invited to join the newly formed KDE VDG too, this was my first contribution to a larger project outside of Nitrux, so after accepting, I created the Breeze icon theme and the new Plasma logo. In 2015 after attending a KDE meeting in Randa, Switzerland, I also updated the Breeze Plasma theme, which has been in use ever since.
We decided then to release Nitrux for x64 in 2015; however, due to changes in Ubuntu (which Nitrux was based on) we stopped the development of that version because of a severe problem we had with systemd and NetworkManager. A few months later we decided to discontinue the NXQ and halt any plans for a new upcoming model that was in the works due to the sudden rise in popularity of similar Android mini-pcs.
It wasn’t until 2017, two years after the development of Nitrux OS was stopped, that Nitrux OS was resurrected. Nitrux S.A. was also restructured under a different name, Nitrux Latinoamericana S.C.
A new developer, Alexis Zubieta, joined me, and together, we set new goals, a new vision, and an original intention for the distribution, we designed and developed Nomad Desktop, which we refer to as a customization layer for Plasma 5. Later that year, we started to work on a software store for Nitrux OS called the NX Software Center, initially using Snaps (there was no graphical frontend for Snaps at the time on the desktop, ours was the first) then adding support for AppImages and finally transitioning entirely to only use AppImages.
In early 2018 Haashir had left Nitrux to continue with his studies, so Alexis and I looked for more developers, the first to join was Luis Lavaire and then Camilo Higuita. In mid-2018, we were joined by another developer, Anupam Basak. Throughout 2018 we began developing MauiKit and ZNX (capitalized as znx). At the end of 2018, we started distributing both with Nitrux OS utilizing ZNX for the first time in version 1.1.0 and the inclusion of MauiKit applications or Maui Apps in Plasma Mobile after Akademy 2018.
In 2019 we presented VMetal a couple of weeks before we attended Akademy 2019.
IF: Tell us something about Nitrux Linux distribution? What is it based on?
Uri: The short answer is that Nitrux is built using Ubuntu sources as we do utilize some of their tools in our ISO images like Casper or initramfs-tools. Still, it’s not based on Ubuntu in any meaningful way as it was the case in prior years.
The long answer is that it’s not based on it as we have made many modifications and intent to a lot more, for instance, in Nitrux, the package manager is not an integral part of the distribution and the intended user experience. As a matter of fact, in the Development build of Nitrux (which eventually becomes the new Stable version), neither APT and dpkg are present since the idea is to use AppImages to manage software and ZNX to manipulate the operating system. We do include Homebrew as a mean to fill in the gap where a program might not be available as an AppImage, but Homebrew only manages the software it installs and nothing else.
Another instance of why Nitrux is not Ubuntu is that, for example, you could potentially have an AppImage to use Pacman on Nitrux, and that, of course, wouldn’t mean that Nitrux is based on Arch. Furthermore, we intend to remove Systemd and (later on) change the FHS in Nitrux. We even have a fully functioning ISO of Nitrux that does not use Systemd or has APT or dpkg, and there’s only one issue that it’s stopping us from releasing it.
In other words, you can’t add a PPA or repository to Ubuntu and turn it into Nitrux. You can add our artwork (which we made from scratch too), but that’s not Nitrux, it’s a part of it (a superficial part), but that’s not it. To put it in another way, we could have used LFS or Gentoo, and we’d have still made the same changes, we would yet have developed the same tools, our same software, etc. The way we see it, for example, is that we don’t think that we should focus on things like having to compile everything to make our distribution “worthy” of calling itself “independent” when we can focus that time and effort on other more user-focused things. Although we do have our infrastructure, tooling, and use a CI to generate the things that we need, like AppImages and our ISOs.
So as we say, “if you expect Nitrux to be “just” an Ubuntu + themes, that’s not at all what you will get. That’s not what we are doing or intend to do.”
IF: What made you create ‘another Linux distribution’? What’s unique about Nitrux Linux?
Uri: Nitrux is a unique distribution in the context of how traditional desktop Linux systems work. Nitrux was not built around the idea of using a package manager, whether that was APT, Pacman, DNF, Zypper, etc. but instead of using a portable application format. The reason for that is that we want Nitrux to be a convergent system, not limited to only a desktop or a phone but that it also is used for other embedded devices; IoT, TVs, Infotainment, Appliances, etc. The use of ZNX is precisely to have a method of efficiently managing the operating system and not deal with any packages, same with AppImages.
In reality, the way that Nitrux works it’s more closely related to a mobile OS like Android, e.g., with Android, you install apps using an APK, the APK file has the program, and its dependencies in it there’s no need to install another APK much less to use a package manager. You get the APK file, install it, and run the program, and that is the same idea with an AppImage; you get the AppImage, give it executable permissions and run it.
When it comes to managing the OS, when an Android device receives an update it’s usually with the built-in OTA mechanism, the manufacturer releases an update, the phone checks for this update downloads it and installs it by rebooting and entering recovery mode and updating the system image. With Nitrux, the distribution is packed in an ISO (similar to the Android system.img file). ZNX then performs a transactional update to the ISO; there’s no package manager involved whatsoever in this process (and no rebooting to recovery either). You could also, in a literal way, copy and paste different Nitrux ISO files, and you would have a new or old version of the distribution.
Like Android ROMs, where the OS is contained in a single file (system.img), Nitrux is also self-contained as a single file (ISO).
Another feature of Nitrux is VMetal. VMetal is, as its name suggests, a virtualization feature built into Nitrux. VMetal works by utilizing the following technologies: QEMU, KVM, VFIO, CPU virtualization extensions like Intel VT-d, VT-x or AMD-V, and Vi and an IOMMU.
With Nitrux, we prefer to keep it simple. The OS is a single file (ISO); new programs are added in a single file (AppImage), the OSes that VMetal uses are individual files (raw IMG files).
Then we have MauiKit in which applications are convergent by design, one code base that works in Linux, Android, Plasma Mobile, Windows. Currently, we have 7 applications built with MauiKit: Index, VVave, Nota, Station, Buho, Pix, and Dialer. All of them see active development and the framework and the applications are hosted at https://invent.kde.org since some of them are included in Plasma Mobile by default. Many improvements did come from the feedback that we receive from users that test the applications. We have a public group where users can join to give feedback here.
So it’s all about portability.
IF: Tell us more about ZNX? Despite an interesting concept why has it not become more popular?
Uri: ZNX is an operating system manager. It manages the lifetime of OSes that are deployed with it. ZNX is not an installer, a container, a program to flash USBs (it’s not a replacement for ‘dd’ or anything similar), or virtualization software. What ZNX does is frugal installations. “A frugal installation only occupies one folder in a partition, and the rest of the partition can be used for anything else. Other Linux distributions, for example.” Meanwhile, traditional Linux distributions do a full installation, “A full installation is where Linux occupies an entire partition, and in that partition you will see the folders /bin, /sbin, /opt, /etc/, /sys, /proc, /tmp, /dev, /usr, /run, /lib, and more.”
For example, package managers that work by using pre-compiled binaries install software by extracting an archive (deb, rpm, tar, etc.) and placing the contents of that archive to the corresponding paths in the filesystem and keeping an index of where those files are located, source-based package managers also do this with the exception of extracting an archive. An installer such as Ubiquity, Calamares (KPM Core), Anaconda, and every other installer works the same, they extract the contents of the SquashFS file inside the ISO and place the contents on a partition of the storage device.
So in this regard, ZNX is akin to AppImage. To install an AppImage, you don’t use a package manager; the AppImage isn’t extracted, you would just run it. Same with ZNX, that is why we don’t refer to ZNX “installing” an OS; instead, we use the word deploy. Because ZNX isn’t extracting the SquashFS file from the ISO, it’s booting the ISO directly, and data is preserved on the storage device using OverlayFS. ZNX then only copies the ISO to a directory in the storage device (STORE).
Once again, in comparison to Android, when the user resets a device to the factory, the user data is cleared. Still, the OS is not reinstalled at any point, ZNX also does this, it can remove the user data from the overlay, thus resetting the OS without any need whatsoever of reinstalling the OS. However, unlike Android, where there’s no simple way of downgrading, ZNX does allow the user to revert to a previous version of the OS. When it comes to updates, ZNX does them transactionally, performing delta updates on the ISO files, so time and bandwidth are saved.
ZNX can also restore the ESP partition, and it also leverages any bootloader management. If an ISO is in the directory STORE, it will automatically appear in the ZNX boot menu; if it’s not, it won’t. ZNX is init-independent, too, and uses GRUB to boot ISOs.
ZNX is, in reality, pretty straightforward.
I believe one reason as to why ZNX hasn’t become more popular is that because everyone is so used to the concept of package managers and installers that ZNX is alien to them. ZNX is to OS installers what AppImage is to package managers. There have been cases where people would even call ZNX a “proprietary boot system” when that’s simply wrong. It may be that ZNX is so much of a radical departure of how traditional Linux distributions work, especially in the desktop that the idea behind it it’s not understood even though we’re using an already existing (and functional) model.
Many people also seem to think that because of how Nitrux specializes in AppImages that ZNX would not allow them to use a package manager if another distribution but us would use it. That’s also incorrect, as we have ISOs of elementary OS and KDE Neon that can be deployed with ZNX where the package manager is perfectly functional, and other than not having an installer, there’s no difference compared to installing them using their installers.
Another reason I believe as to why ZNX is not popular is that ZNX does its operations in such an automated way, for example, partitioning is not handled by the user but by ZNX, there’s no user creation, language selection, keyboard selection, time zone selection as an installer traditionally handles these. Mostly because again, like in Android, all of that setup is done from within the booted OS and never during installation because there’s no installation. So once again, a rather significant departure on how traditional desktop Linux distributions work.
Derived from these significant changes that ZNX brings to the table is that everyone expects to install OSes in a traditional multi-boot configuration, e.g., One partition for Ubuntu, another for Fedora, another for openSUSE, another for Arch, and so on. Which is not the case with ZNX, since the idea is that you only have one partition where each ISO file (meaning each OS) is located and then select which one to boot in the ZNX boot menu. So one partition, with each OS in a separate directory inside STORE, with their data inside their corresponding directory structure, in this regard ZNX is somewhat similar to the Nix package manager in how Nix stores the data of each program in its directory structure.
The only hard requirement that ZNX has currently is that ISO files must support EFI, and the only limitation is the lack of support for Secure Boot. Still, even then, we’re entirely open to anyone contributing code that would enable Legacy BIOS support and Secure Boot support.
ZNX is not challenging to use at all. Still, it would benefit from having a better GUI, so it may be too that people new to it find it difficult because of that, although ZNX GUI exists, that’s why we’re working on integrating it into our software center instead.
Some people also seemed to think that ZNX was a Docker alternative; on that one, I’m not sure why? I suppose from us using the term “deploy.”
Certainly, ZNX has had problems, mainly that the AppImage wasn’t functioning as expected, as that is how we distribute it. However, we have fixed pretty much all of those problems already, and it works everywhere where we have tested.
Recently we also disclosed that the reason why we always said our ISO couldn’t be flashed to a USB was not a problem that was related at all to ZNX but instead to a component of our tooling, mkiso. We use mkiso to generate our ISO files; unfortunately, mkiso made ISO files that would not boot in computers that were not UEFI class 3 (Intel 6th gen.+ or AMD Ryzen+). ZNX, however, would allow the ISO to boot in older computers as long as they supported EFI (Intel 2nd. gen+ or AMD PII/800 series chipsets). We have since fixed mkiso, and our ISO files can now boot in older EFI computers when flashed to a USB. Perhaps this was the reason some people also thought that ZNX was like a ‘dd’ replacement or something like Etcher. Surely, you can deploy an OS to a USB with ZNX, and it would be a bootable USB in this regard it’s similar to programs like MultiBootUSB or YUMI with the exception that user data is stored directly on the device using OverlayFS instead of using a file as they do meaning that you’re not limited to the storage allocated to the persistent file but to the overall free space of the storage device.
All in all is a mix of confusion and misunderstandings that I believe is the reason why ZNX is not popular.
What kind of user base are you targeting with Nitrux?
We intend to target users that have been considerably exposed to the way that mobile OSes behave and work.
You have a strong focus on AppImage. Why so?
AppImage provides a simple way of obtaining software. Download it and run it. As before, that’s precisely how you get apps on mobile OSes. That ease of use is what we’re looking forward to. There’s no doubt that Flatpak and Snapcraft are more popular; they have the backing of two large companies and communities, so its invariably an uphill battle.
AppImage is also init-independent, which is very important to us as we do not have intentions to keep using Systemd, which means that neither Flatpak or Snaps will be available in Nitrux, not that they are in our current ISOs. It does not need or use daemons to work, AppImages don’t depend on other AppImages to work, no runtimes are required either, and it’s not tied to the init system as mentioned.
Many people seem to think too that AppImages lack a sandbox feature, integration with the desktop, or even the ability to update them. That’s incorrect, AppImages can be sandboxed with Firejail (SUID program that reduces the risk of security breaches by restricting the running environment of untrusted applications using Linux namespaces). The integration with the desktop can be done with multiple programs like AppImage Daemon, AppImage Launcher, or AppImage Desktop Integration (developed by us). Lastly, AppImages can be updated using AppImageUpdate, which will update the files using transactional, delta updates (like ZNX does), all of which we include, by default.
I think that the only “downside” is the size of the files in some cases, but it’s also a case of where is the AppImage intended to be run?. For example, a router would not have hundreds of GBs of storage or even dozens, but at the same time, there’s no real reason to have a desktop AppImage in it like LibreOffice.
Still, then that’s not a problem on any reasonably modern desktop computer or laptop, which is very likely to have hundreds if not thousands of GBs or even on most phones where internal storage is reaching the hundreds and the ones that support SD cards also have access to hundreds of GBs.
On that note, an AppImage is indeed meant to include what the program needs to be able to run, and that is not expected to be in the target OS. For example, the AppImage of Index (Maui file manager) is as little as 50 MBs because it’s meant to be run on a full desktop (desktop as in the type of system not as in the form factor) OS whereas if the AppImage was meant to be run in a server it would have to be a lot larger since the server OS would not have any graphical software on it, to begin with.
At the same time, the fact that the AppImage includes all it needs is what makes it work not just in a particular Linux distribution but on many more.
Surely enough, getting a random file from the internet may not sound like a good idea, but there are efforts being made to provide a centralized store for AppImages such as AppImageHub.com.
IF: I see a paywall while downloading Nitrux. Why is that? What (other) business model do you have?
The reason is relatively simple, Nitrux is a business, not a non-profit organization, and companies need to generate revenue to grow and to continue development. As with any commercial endeavor, there are expenses, even though we develop free and open-source software. From paying for our servers to our salaries and travel expenses to attend FOSS-related events. Therefore we’re upfront about it.
We don’t put Ads on our website or our OS, and we don’t send marketing emails, we don’t collect user data, we don’t include 3rd-party software, we don’t nag users with license keys, we don’t charge users for support of Nitrux. Also, 99% of our work is available in source code form or distributed as an AppImage at no cost on our GitHub organization, or it’s hosted in KDE infrastructure as it is the case with MauiKit and the Maui Apps. We also contribute upstream, as we do with KDE with Kirigami and AppImage (our former developer, Alexis Zubieta developed libappimage during his time with Nitrux and is currently part of the team that develops AppImage and all of its related software).
I would say that some people, however, seem to think that because we’re making a Linux distribution or that because we develop free and open-source software that we should not have to charge money for our work because nobody else does, or worse, that we can’t. Neither the FSF or the OSI prohibits commercialization of FOSS, so it’s an invalid argument, precisely because the F in FOSS does not stand for Free (zero-cost); in reality, it stands for Freedom and our software conforms to that. It’s not a majority, but it does happen.
In all certainty, we understand that not everyone can afford to pay, which is why we do offer the Development and Minimal builds at no cost, in addition to the source.
By paying to download the ISO, users are contributing towards paying our salaries and our ability to hire more people and create more software and continue to polish the one we have.
Other than paying for access to the download of the Stable ISO, we also accept donations through PayPal or with crypto, and we also have a Patreon and Liberapay pages.
IF: Are you looking for volunteers, developers or financial support of any kind? Any message for the readers?
Uri: We always are. If anyone wants to help, help is more than welcome. Currently, we don’t have any open positions as we just hired a new developer, but hopefully, we can afford another in the future.
Nitrux currently is composed of 4 members soon to be 5:
- Uri Herrera (me)
- Luis Lavaire
- Camilo Higuita
- Anupam Basak
- Ademir Tejada (new)
We do all work full-time as developing all of our software is our job, but we work remotely since we’re all in different countries.
We are looking for financial support, liked I mentioned we directly put that money back into developing everything that we do.
All I can request fromIt’s FOSS readers is to try Nitrux and report issues; that’s how we can improve it.
If you want to be up-to-date on what we do, follow us on social media like Twitter, Instagram and Telegram. You should also read our blog for more detailed updates. Of course, you are welcome to contribute on our GitHub repository.
