Skip to main content

We always appreciate reviews and feedback about our work since that allows us to keep on improving. It means a lot that other people share their experiences, good or bad with Nitrux, and we’re always ready to answer questions about the distribution and talk about what makes it unique.

Previously, in another article, I wrote about some of the most common misconceptions about Nitrux.

In today’s article, I’ll address the points discussed by Distrowatch in their most recent review of our distribution.

First, a big thank you to Distrowatch for including us once more in their weekly issue and for reviewing Nitrux 1.0.15.

I’ll use the title corresponding to the review section.

Hardware

… When running in a VirtualBox test environment, the login screen was unusually slow to respond to input, but performed quickly when run on my desktop computer. In a similar fashion, the Nomad desktop proved to be slightly sluggish to respond in VirtualBox, but ran smoothly on physical hardware. I was pleased to find the desktop automatically resized itself to match my host computer’s screen resolution when run from a virtual environment.

Since the last couple of releases, we have added to our version notes the following text,

Notes
– Nitrux, by default, uses OpenGL (3.1) acceleration as the rendering backend. This is to provide users of a great experience when they are running the distribution in Live mode on their computers. Obviously, this affects the performance in VirtualBox since the 3D rendering is completely software based. We do recommend that in this case, testers use XRender instead. We also recommend that testers don’t attempt to install the guest additions from the VirtualBox Guest ISO or install the package using APT and this is because the Linux kernel since version 4.16 does already include the video driver and related modules.

Early Impressions

… I tried swapping out the Nomad menu for a classic tree-style menu and not only did the alternative menu not appear, but the Nomad Menu button disappeared too. This left me temporarily without an application menu until I tracked down a solution… I then tried to remove the default panel and replace it with a custom Plasma panel of my design, but found it is not possible to remove the Nomad panel. Going into the panel settings and trying to remove it does nothing.

The problem referred to here was a bug. This bug, issue #32 in the Nomad Look and Feel package was fixed a few days after the release was published.

As we noted in the release announcements that were published on Facebook, Twitter, Google+ (closing on August 2019), Mastodon, Sourceforge, OSDN.net and openDesktop.org on the 1st of September this was a known issue, and we were keeping track of it.

The fix was subsequently pushed to our GitHub repository on the 7th of September and posted on the mentioned websites on the 14th of September, thirteen days after the release of Nitrux 1.0.15.

Nitrux 1.0.16, which was released on the 28th of September, does not present this issue.

Nomad Software Center

… The software manager displays available AppImage packages in a grid, listing just their name and a truncated version number. There are no descriptions or icons associated with the packages and we cannot get more information about them by clicking on them. The packages are shown in alphabetical order with no method, so far as I could find, for sorting them into categories. We can search for packages based on their name, but otherwise we are left with a long list of packages with short names like “jaxx” or “xchat” without context.

The software center included in this and previous versions of Nitrux is an old build that did not have anything else other than the grid view and the ability to manage AppImages.

We made a mistake not to communicate this transparently. In retrospection, it would have been evident since every time that we posted about any progress on the Software Center; the pictures showed a different interface than what was included in the distribution.

Although, in the article that I linked to, I talked about this misconception. The included version of the Software Center in Nitrux 1.0.15 was not the finalized software.

In Nitrux 1.0.16, we included a newer version of the Software Center that also made use of our newly developed web scraper back end.

I found AppImage programs can be located in one of two places. In our home directory, there are two folders, Applications, and bin.

~/bin is a vestigial folder that the old build of the SC creates; this was changed to ~/Applications in later versions.

New applications do not appear in our application menu and are not added to our path and I began to wonder if the items I had selected were downloaded at all.

AppImages downloaded through the SC and added manually to ~/Applications are added automatically to the menu by the SC and appimaged, or the files can be integrated manually by the user using AppImage Desktop Integration.

This task is performed by one of 3 pieces of software, the Software Center, appimaged or AppImage Desktop Integration, all three are installed by default in Nitrux, with AppImage Desktop Integration being added in Nitrux 1.0.10, released on the 31st of March 2018 and appimaged being included since Nitrux 1.0.9, released on the 24th of February 2018.

AppImage Desktop Integration is a tool to integrate AppImages into any freedesktop.org desktop environment. If the user downloads and runs an AppImage outside of the directories that the SC and appimaged monitor this window will appear, asking the user to Deploy it will integrate the AppImage with the DE, providing of an icon in the menu. AppImage Desktop Integration is also capable of deploying the file system-wide so that it is accessible to other users. To only run the AppImage first check the checkbox “Trust appimage (makes the appimage executable)” and click on Run.

As far as I could tell, there does not appear to be any method in place to upgrade packages. Perhaps this happens automatically in the background, but I could find no method for checking on potential AppImage updates and downloading them.

The SC, by default, can update AppImages, as long as there’s a newer file available from the source.

Since we are not storing any files in a server of our own (the AppImage files in the SC come from https://www.linux-apps.com), if the site where the SC is pulling its data from does not have a new AppImage, then the SC can not update the file, this does not mean that the SC doesn’t have that feature.

AppImages, too can be updated without using the SC. One way is doing it the rudimentary way, which is replacing the file; the other is using AppImageUpdate. We don’t include this tool since the software center does have that feature.

To update the Debian packages, we have added a KCM to System Settings called Software Updater. Updates are not downloaded or applied automatically.

As of Nitrux 1.1.0, Software Updater has been deprecated in favor of znx.

For me, installing large, portable versions of packages which are (for the most part) already available in Ubuntu’s repository and which will not be added to my menu or path seems like a big step backwards.

As I mentioned, the deployed files are added to the menu either by the SC or AppImage Desktop Integration.

I probably would have overlooked the inconvenience of this approach had there been another software centre, like GNOME Software or Discover, on the system, but to deal with Ubuntu’s underlying packages we need to use the APT command line tools.

The NX Software Center was never intended to deal with package managers. But this is also coming from what we want to do with Nitrux. We do not want to rely on traditional package managers, be it APT, pacman, dnf, etc.

I will refer to these articles where I talk about the SC and the reason why we put AppImages first and package managers second.

The one aspect of working with portable packages I did like was AppImage packages did not integrate with the Nomad desktop. Basically this means that any program we install via AppImages cannot use Nomad’s global menu bar and instead has its own, in-window menu…

This issue varies from app to app. If the app does support exporting its menu, then the global menu applet will display the menus in the top panel. It works best with Qt applications.

Conclusions

Previously, when I tried Nitrux I did not like the default audio player. I think the Babe audio player has come along nicely. While it might not be my first choice for a music player, it gets the job done and worked much better for me during this trial.

Babe was deprecated from Nitrux in version 1.0.16, and its development had stopped many months ago, the version that was included in Nitrux 1.0.2 was almost the same, if not the same as the one included in Nitrux 1.0.15. However, its developer (who works at Nitrux ;P) has been working to put out something even better, and way more significant.

I did run into some design choices that frustrated me. The first being that Nomad seems to be basically the Plasma desktop with some hard-wired choices made for us. I like the Plasma desktop and greatly appreciate its flexibility. To run into fixed features I didn’t want (such as the global menu bar I couldn’t remove) in a Plasma-based environment somewhat soured me to the experience. This is all the more unfortunate because some of Nomad’s style and approach I liked, but being unable to tweak it to better suit my workflow left me wanting to swap out Nomad for plain KDE Plasma.

We never intended to offer a vanilla Plasma experience. We think that there are already great projects that provide this experience and fulfill this purpose, like KDE Neon or openSUSE, to name a couple.

We did intend, however, to offer a different experience, our own.

My biggest issue with Nitrux though is the software manager. Instead of having a rich and easy to browse software manager like GNOME Software or mintInstall (or a powerful package manager like Synaptic) the distribution uses a custom software manager that only works on AppImages. This not only limits easy access to Ubuntu’s massive package repositories, it also makes searching for packages harder.

As I mentioned in this and the other articles, the build-in Nitrux 1.0.15 and the build-in Nitrux 1.0.16 are not the final versions of the software. The SC was never built nor designed to be used with traditional package managers; neither is our goal to keep using conventional package managers.

The developers of AppImage have made it very clear that the format does not intend to replace package managers. However, we want to make AppImages first-class citizens in Nitrux.

In Nitrux 1.1.0 and onwards, APT is not the primary method of obtaining software, nor is it the primary method to update the distribution.

For instance, AppImages are a mixed bag when it comes to security updates. Ubuntu’s main repositories get regular security fixes, but AppImages may or may not depending on the specific package’s maintainer and there isn’t much the user can do about that.

The users can do a lot; for one, users can contact the developer(s) of the app and ask nicely about an AppImage. Some of the significant software is already distributed as an AppImage, GIMP, Inkscape, LibreOffice, ONLYOFFICE, Blender, Krita, among others.

And Appimages can be updated using the SC or AppImageUpdate. There’s no waiting time and no intermediary, there’s only the user and the developer.

Another concern I had was that each AppImage is installed in the user’s home directory, not a central location. This means on computers with multiple users we may end up with the same AppImage installed multiple times as each user gets their own copy. AppImages are relatively large so it may become a storage issue as well as a security concern.

I’ll take the liberty here to point out that storage is cheap nowadays.

Computers no longer come with 10, 20, 40 GB hard drives. However, this is negating the fact that an AppImage does not need for dependencies of any kind, be it plugs or runtimes to be installed before running it, and the same file can be used in multiple distributions.

Yes, they are larger, but then this means that the base distribution doesn’t have to include dozens of dependencies that, at one point, may conflict with one another.

And, AppImage Desktop Integration does allow the user to deploy the file system-wide. Speaking of security, we use firejail to sandbox the AppImages, which is why LibreOffice or ShowImage will not run during the Live session.

Finally, AppImages are not added to the application menu so the user needs to be able to find and manually run their newly installed programs and this seems like a lot of unnecessary fiddling about when most software managers add new programs to the menu for us.

As I mentioned, this is done automatically when the AppImage is in ~/Applications as it is the case with LibreOffice and ShowImage, which are AppImage files and are included in Nitrux 1.0.15 or manually using AppImage Desktop Integration.

It’s not that Nitrux introduces poor ideas, but that it replaces existing good tools with its new ideas which haven’t matured to the same levels as the items being replaced. I would probably like the new software manager if it were an add-on alongside another package manager, like Discover. I might enjoy the Nomad menu and panel if I could customize it as I can any other Plasma widget without my application menu vanishing. In short, I think Nitrux’s custom tools make good additions to the Ubuntu base, but not good replacements for more mainstream utilities.

I will also interject here, If we wanted Nitrux to be nothing more than a re-skin of whatever distribution, in this case, a re-skin of Ubuntu, that’s what we would have done, and we would not have bothered to design and build our pieces of software. And we would have been transparent about it, but that’s not our goal.

I think too that comparing a piece of software like the SC which has been around for approximately two years and that had a substantial change in the way it works one year later to software like Discover, for example, is not fair. Our SC should be judged on its own merits, in its context, and the same applies to the distribution in general. I believe that what we have accomplished in the time that we have been putting out releases (one year and a half) should not be minimized.


Maybe 1.0.15 is the first version that you know of Nitrux, and that is okay. Maybe you have used Nitrux in the past, and you did not like it, and that is also okay. Maybe you prefer to use another desktop, other colors, themes and that is okay too.

It’s never too late to get to know each other.


I would strongly recommend for new users and reviewers not familiar with Nitrux to truly explore the distribution, use it daily for a week or two, to follow us on any of our social media or to follow this blog to understand why we did this or why we want to do that. And to not dive into Nitrux thinking of finding a vanilla Plasma and Ubuntu experience because precisely that is what we are not doing.

The Live session is not representative of the system once installed, running the system on a virtual machine does not make use of the full potential of your hardware.