So, 1.0.6 is out, and the highlight is the removal of Snap support in the NX Software Center. The obvious question is why we removed support for Snaps from it.
Let’s begin with: While we removed support for Snaps from the software center, you still can install and manage Snaps in Nitrux. You won’t be able to do so using a friendly UI; you will have to do it from the terminal.
The NX Software Center was created to serve portable apps such as Snaps. However, it hasn’t gone without its fair share of difficulties. At first were the libraries that we had used: libsnapd-glib and libsnapd-qt, which at the time had very early support for Qt so for us to use them and create a Qt front-end we had to patch them. Eventually, our changes made their way into upstream, and both libraries were available in the Ubuntu repositories with the updated code.
As we continued to update the software center, we came across another problem: We couldn’t create a Snap store of our own.
What does that mean, it means that the only proper way to get a Snap is through the Ubuntu Store (read: repository). Say we wanted to create our platform to serve Snaps, well we can’t because the server-side software needed to do that is not publicly available to use by 3rd parties (like us). That doesn’t mean you can’t install a Snap that doesn’t come from the Ubuntu Store, however, you can, in the same way, you can install an APK in Android (read: sideload). But like with Android, it isn’t a good idea to do so because of security concerns.
We understand why that is the way it is (that there’s only a single sanctioned store), but it was a downer.
From then on, we didn’t have any more problems with the software center up until the past few days before this release when libsnapd-qt was mostly unusable. The library, unfortunately, isn’t actively maintained, which is a massive problem for us and so when Qt was updated to 5.9.2, our software center wouldn’t work.
In the meantime, we had been working on integrating AppImages to the NX Software Center. In Nitrux version 1.0.5, this integration had been fully added. Unlike Snaps, AppImages don’t require to set up a single, proprietary, sanctioned Store to download them and they also don’t need something like a daemon to work. However, we do use one to manage them from our UI, they also don’t require connecting Snaps with other Snaps (plugs) an AppImage while more extensive in size can have all of its dependencies inside a single file, in our case this is very important because packaging Snaps of KDE apps was ultimately futile. Still, we managed to package KDE apps with AppImage. Concerning sandboxing, we used firejail to provide the layer of security that might be missing from not getting an AppImage from a “sanctioned store.”
But best of all is that the library we use — libappimage is actively maintained, and it was created by one of our developers, Alexis Lopez Zubieta, in collaboration with the AppImage team.
Right now, the software center offers the same functionality as it did when it had Snap support, installing, managing, and removing AppImages. The Store UI components were removed since they were designed for Snaps categorization; noticed that empty app category? Well, that’s because web apps (which are also packaged as Snaps) used those categories. The Snaps that were listed on the software center were the actual Snaps like Blender, Inkscape, etc.
To finalize: We will be working on restoring the UI to accommodate for AppImages instead of Snaps, continue our work with the AppImage team and reach out to other 3rd parties like Opendesktop.org to work with them on a web store or improving the one they might already have.
In other words, Nitrux ❤ AppImage.
