When we announced that Nitrux would not include dpkg (and therefore APT) anymore back on November 8th, a lot of confusion and controversy arise. “How are we going to add software?,” “Why?,” “There aren’t enough AppImages,” etc. We hear you, and we understand your concerns.
First, we want to say that, as we put in our FAQ.
[…]We have built Nitrux with the goal of not depending on the Debian package manager (dpkg) or its extended set of tools APT (Advanced Packaging Tool) to manage the operating system.[…]
The package manager is not an integral part of Nitrux, and that’s why dpkg and APT are no longer present in the system.
[…]Our changes run deep, and even though we build Nitrux from Ubuntu sources, Nitrux is not Ubuntu neither does it work like Ubuntu, nor it will be Ubuntu under the hood forever.
However, we understand that not all software is available as an AppImage or that AppImages cover all use cases, which is why we have included various options to fill the gap, such as Homebrew and (the recently announced) PNX, to name a couple.
The idea is that while you are capable of managing software using a package manager (if you want to), that doing this would not result in a possibly broken system. It has never been our intention to impede or limit the way that users manage their software. Nonetheless, we remain committed to putting forward the AppImage format.
So, in this article, we will take a look at how users can manage (add, remove, upgrade, and downgrade) software in Nitrux.
First, let’s list the methods that you can use that are native to Linux and that we currently include.
- AppImage.
- Homebrew.
- PNX.
- Flatpak.
- Docker.
- npm.
Second, let’s list the methods that you can use for software that’s not native to Linux.
- Wine (incl. AppImage).
- VMetal.
Third, let’s list what other options might be available in the future.
- Nix.
Finally, let’s list what we won’t be adding, don’t worry we’ll explain why.
- Snap(s).
And, now let’s see how with each option, users can manage their software in Nitrux.
AppImage
The first method to manage software in Nitrux is by using AppImages. AppImage provides a very innovative and simplistic solution to software distribution. It is abundantly clear that a one-click solution to obtain software would be instantly accessible to anyone.
An AppImage is a downloadable file for Linux that contains an application and everything the app needs to run (e.g., libraries, icons, fonts, translations, etc.) that you can’t expect to be part of each target system.
By default, with AppImage, the only thing that you need is to visit the program website and download the file, simple enough. However, there’s no way to manage them until now.
In Nitrux, we include appimage-installer. appimage-installer is a CLI program that allows the users to search, install, remove, and update Appimages from AppimageHub.com easily via terminal commands.
This tool is available as the command app and can be used in the following way.
app --help Usage: app [options] command Command details search <query> list applications available in the store install <STORE ID> install the application with the given store id list list applications available on your system update <APP ID> update if possible the given application remove <APP ID> remove the application from your system Options: -h, --help Displays this help. Arguments: command Command to be executed: search | install | list | update | remove
Homebrew
Homebrew is a macOS package manager that works on Linux, which allows users to install software to their home directory.
Homebrew features are the following:
- Homebrew can install software to your home directory, and so does not require sudo.
- Install software not packaged by your host distribution.
- Install up-to-date versions of software when your host distribution is old.
- Use the same package manager to manage your macOS, Linux, and Windows systems.
- A package in Homebrew is called a formula. A list of all available formulas can be found here.
- Third-party repositories in Homebrew are called a tap.
- A package in Homebrew is called a formula. A list of all available formulas can be found here.
To begin, open Station and type the command brew.
brew --help Example usage: brew search [TEXT|/REGEX/] brew info [FORMULA...] brew install FORMULA... brew update brew upgrade [FORMULA...] brew uninstall FORMULA... brew list [FORMULA...] Troubleshooting: brew config brew doctor brew install --verbose --debug FORMULA Contributing: brew create [URL [--no-fetch]] brew edit [FORMULA...] Further help: brew commands brew help [COMMAND] man brew https://docs.brew.sh
When you run Homebrew the first time, this command will update brew and will add the necessary folders to the /home directory. Follow the instructions on the screen.
Once you have successfully set up Homebrew on your machine, you can start using it.
To list all installed formulae, run.
brew list
To install a formula using Linuxbrew, use the command brew. For instance, hello, which is a Hello World! Example package.
brew install hello
You can search for packages using the following syntax.
The first command will show all the available formula, while the second will show formulae that match a keyword.
brew search brew search --desc <keyword>
You can also add third-party repositories to Homebrew. To list all current repositories, run.
brew tap
To know more about Homebrew usage options, type:
brew help
We strongly recommend reading the Homebrew documentation at https://docs.brew.sh.
PNX
PNX (originally Pacman for Nitrux) allows users to install software from Linux distributions that use the Pacman package manager on other Linux distributions that don’t use it without interfering with the distributions default package manager. By including PNX, it does not mean that the Pacman package manager is utilized by Nitrux to manage the operating system. Still, it is instead an option that, in addition to Homebrew, aims to fill the gap where an AppImage of any given program might not be available.
PNX follows the same workflow as Pacman in Arch Linux or distributions that use it as their package manager.
pnx: Welcome to PNX!.
Description:
PNX is a wrapper for Pacman. Pacman is a package management utility that tracks installed packages on a Linux system.
This wrapper allows the user to use Pacman on a Linux distribution that is not a derivative of Arch Linux without conflicts with
the distribution existing package manager.
Report bugs at: https://github.com/Nitrux/pnx.
Flags:
--initialize, Create PNX root directory.
--key, Use pacman-key: pacman-key - manage pacman's list of trusted keys.
--repo, Use repo-add: repo-add - package database maintenance utility.
--launch, Launch a program installed using PNX.
--makepkg, Create a package from a PKGBUILD.
--remove-dirs, Remove PNX directories.
--debug, Run PNX with debug on.
--release, Show the version.
Usage:
When no flag is specified, PNX will default to package management.
pnx <operation> [options] [targets]
pnx <flag> <operation> [options] [targets]
Examples:
sudo pnx -S inkscape
To install a package using PNX use the same syntax as Pacman.
For example, pnx -S inkscape will download and install inkscape and all the packages it depends on.
sudo pnx -Syu
Update package list and upgrade all packages afterwards.
sudo pnx --key --init
Ensure the keyring is properly initialized and has the required access permissions.
sudo pnx --repo --verify
Verify the PGP signature of the database before updating the database.
pnx --launch inkscape
This will execute a program installed using PNX.
To access the AUR it’s necessary to use a helper program, such as Yay. However, Yay is not available from the Arch Linux repository as a package and it’s recommended that Docker is used to build a package using an Arch Linux or Manjaro container.
The newly created package can be copied to the Nitrux host from the container and installed using PNX.
Flatpak
Flatpak builds upon existing technologies such as cgroups, namespaces, bind mounts, and seccomp in the Linux kernel, OSTree from Project Atomic, and the OCI format that is developed by the Open Container Initiative.
Flatpak support is a very recent addition to Nitrux. Initially, we were skeptical about including Flatpak (and Docker) for the straightforward reason that both depend on systemd. As we have reiterated various times, we do not intend to keep using systemd in the future. However, during our most recent work towards making a usable SysV image, we have successfully added both to Nitrux. Surprisingly, Flatpak does function without systemd in recent versions.
And we have also enabled the default Flatpak location to the overlay so that any changes persist across reboots (albeit temporarily because it installs the software to the root, we will move the default install-location to the /home just like Homebrew and PNX). The primary reason to add Flatpak support is Steam.
It’s well-known that Steam is still a 32-bit program, and we do not include any 32-bit support at all, meaning that Steam was not available. Sadly, Steam is also not available as an AppImage, yet. However, it is available from the Flathub repository.
We do not include the Flathub repository by default, but it’s effortless to add it.
To enable it, run.
flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
You don’t need to restart the system.
Docker
Docker is an open-source lightweight virtualization tool that runs on top of a kernel, allowing users to create, run, and deploy applications encapsulated into small containers.
The decision to also add Docker is very recent as with Flatpak; we were skeptical about adding it due to its dependency on systemd. However, in newer versions, that is no longer the case, so it’s safe to add it to Nitrux. The primary motivation to add Docker is not so much to provide end-users of applications but instead to give developers of an environment more suitable for, well, software development.
There’s no setup needed to configure Docker.
Note: Currently, cgroupfs is not started automatically, to start it run.
cgroupfs-mount dockerd &
npm
Node.js is a lightweight and efficient JavaScript platform that is built based on Chrome’s V8 JavaScript engine, and NPM is a default Node.js package manager. npm consists of a command-line client, also called npm, and an online database of public and paid-for private packages called the npm registry.
As with Docker, the inclusion of npm is mostly to provide an environment for developers.
Wine (AppImage)
We include Wine in Nitrux for those users interested in running Windows software without using VMetal. Wine describes itself as “Wine (originally an acronym for “Wine Is Not an Emulator”) is a compatibility layer capable of running Windows applications on several POSIX-compliant operating systems, such as Linux, macOS, & BSD.[…]”
Do note that by using Wine alone, not all software written for Windows will work right away, further configuration by the user may be necessary. We include Wine as an AppImage (version 4.2 w/ Proton), which means that it isn’t an official release by the Wine developers. The AppImage does include the necessary 32-bit libraries for Wine to work.
We encourage users to visit the official Wine site for support in running a specific Windows application.
A fantastic way of making use of this Wine AppImage is to use portable Windows applications, such as the ones provided by https://portableapps.com/. “PortableApps.com is a website offering many free, commonly used Windows applications that have been specially packaged for portability.“
To run an EXE file do the following:
Note: Nvidia users can present problems with programs that require 3D acceleration due to inconsistencies found in the Nvidia proprietary driver and OpenGL calls. AMD and Intel users will not present OpenGL issues.
VMetal
However, our primary method of running Windows software is to use VMetal, which, unlike Wine, does offer full compatibility with Windows software.
VMetal allows users to run Windows in parallel to Nitrux to provide users of access to Windows software; meanwhile, they can still use their Linux desktop at the same time. VMetal is not a wrapper or a compatibility layer; it makes use of QEMU and KVM (Kernel-based Virtual Machine) on the software side and of VFIO and IOMMU on the hardware side, meaning that Windows is accessing directly the hardware that it utilizes.
For this feature in Nitrux to work, the hardware where VMetal will be running must support specific features; otherwise, the software will not work, and you won’t be able to enjoy the benefits.
- CPU must support virtualization extensions (Intel VT-x, AMD-Vx)
- CPU must support Directed I/O (VT-d for Intel or AMD-Vi, generically known as IOMMU)
- The motherboard must support VT-x and VT-d (or AMD equivalents).
- The motherboard and the graphics cards must support UEFI. When buying new hardware, check the motherboard and the graphics card user manual.
- The computer should have one or more discrete PCIe graphics cards in separate IOMMU groups. A combination of an iGPU and a discrete GPU is also usable.
The listed system requirements to use VMetal in Nitrux are high because they are considering two things.
- The computer will be effectively running two operating systems at the same time. A piece of sufficiently robust computer equipment is needed.
- Therefore, you need a CPU that has enough cores to provide an optimal configuration (4+2 or 6+2 or 4+4) for VMetal with optimal IPC performance, enough RAM (8GB or more) to run both operating systems and software within them, and two graphics cards with individual outputs (compatible with UEFI). Additionally, all the core hardware components must support features tailored for virtualization.
VMetal, unlike other popular virtualization options for end-users, provides almost native performance when it comes to games, which are the primary focus of this feature.
This reasoning is considering that Windows would be accessing the hardware such as the graphics card directly, and it wouldn’t be using an emulated piece of hardware or software rendering using the CPU as do most popular virtualization software.
Please refer to the FAQ for more information.
Nix
Finally, we would also like to offer another option to this roster.
The Nix package manager is a bit different from other Linux package managers in-terms of functionality and features. Concerning about the features, we can list the following:
- Multi-user package management. That means each user in the system can have a different set of installed packages.
- The users can install packages without root or sudo user privileges.
- Nix package manager stores packages in the Nix store, usually the directory /nix/store. Each package has its unique subdirectory. Say, for example, the package gzip will be stored under a unique directory /nix/store/c5y9w08xkiz6kvnscpjv3205gyr6iybz-gzip-1.8/ along with all required dependencies and libraries.
- Different users can have different versions of the same package installed at the same time.
- Since all packages are installed in unique directories, one user can’t interfere (like remove, update or upgrade packages) with packages installed by another user.
- Rollback packages to previous versions are possible.
- Atomic upgrade support.
- Unused packages can be safely removed.
- DevOps-friendly package manager.
- Nix package manager can be used in GNU/Linux and Mac OS X.
Snap(s)
We have talked about previously why we don’t support Snap(s) in Nitrux. But, as we have moved forward, another concern became apparent, Snap(s) require systemd, and that makes them immediately unfit for Nitrux as we move away from systemd to other inits, such as SysV and potentially OpenRC in the future.
Conclusion
We want to emphasize the following, we’re not in a crusade against package managers, quite the contrary, we’re happy to provide options to those users that want to use them, and the Nix package manager is an option that we’re looking forward to adding to Nitrux in the future. However, we want these options to be available in a way that does not end up in a broken system. And, that allows users to easily discard, or rollback damaged installations in seconds.
To achieve this end-goal, we do have to perform a lot of testing, and doing trial-and-error runs does take time.
So, we would like to ask users not to make assumptions that we want to limit or prevent/forbid/impede the use of package managers in the distribution, or that znx is somehow(?) incompatible with them (something that we have started to see being said here and there, which is most definitely not true).
With that said, AppImage is, first and foremost, the best-supported method for managing software in Nitrux, but we’re open to providing other options.