magda

Artix, calling itself “Arch Linux without systemd”, is a project I've had my eyes on since I got into Linux two years ago and gave a quick spin myself before eventually settling with EndeavourOS for over half a year. Back then, I would let its s6 variant run within a virtual environment and was pleasantly surprised that it would work very smoothly even with little hardware resources provided. My test, however, came to a sudden stop when pacman stopped fetching updates out of the blue and repeatedly stated that the system was up to date, despite being at least three kernels behind.

And because two years have passed since that incident, I decided to give Artix another shot.

Live System

Before booting the system, users are free to set their keyboard layout, language, and time zone. Once set, booting the live ISO took less than 30 seconds, making the s6 variant of Artix significantly faster than any live system relying on systemd that I got to test, so far. Since the OS also fails to automatically adjust the screen resolution within a virtual machine, it was pleasant to notice that Artix relies on a higher default resolution – 1024x768 – than most distributions, allowing me to make adjustments without having to upscale the VM.

Besides that, the live system provides a vanilla XFCE4 environment with only a handful of tools, such as Risetto and Atril, included, alongside three additional links on the Desktop leading to offline Wiki pages about configuration, used init system, and troubleshooting. This keeps the ISO at a relatively light 1.2 GB of size and makes it an adequate choice for system rescue, in case an installed Artix gets messed up.

Installation

As it is common for graphical live systems, Artix also ships with the GUI installer Calamares, which has been tweaked to make offline installation possible, though advising against it due to possibly missing modules. Once letting my host access the internet, hardly anything had to be set in Calamares, as it instantly registered any setting that was made prior to booting the system, only needing attention when reaching Partitioning. The installer, overall, is being kept sparse and does not provide additional options to choose the preferred file system or init, in case the one used by the live ISO is not the one the user may prefer.

Much to my surprise, the installtion took three minutes and 49 seconds, copying just 174,573 files – a stark contrast to Archcraft, which needed to copy nearly 400,000 files and thus required 16 minutes to install.

Installed System

Booting the newly-installed Artix took much longer than expected, needing one and a half minutes to get the process done and temporarily freezing during automatic login. Once done, I was being presented with the same sparse Xfce desktop from the live ISO with the offline Wiki links removed and very few background choices out of the box that would look decent enough with the odd default icon theme borrowed from the MATE desktop environment.

Annoyingly, when wanting to take a screenshot, Artix, just like ArchLabs, refused to react to the print key when being pressed, despite a proper keybinding being set by default this time around. In both cases, this issue only occurs on installed systems within VirtualBox, yet not when letting the live ISO run within a VM, so it is hard to tell whether it's caused by the system itself or by VirtualBox. I let this bug slide and opened Xfce's Screenshot tool manually, only to notice a glitch affecting the top bar. Closing any window does not remove it from the bar automatically and makes it appear as if it currently is inactive. Clicking on it did not cause any reaction and the only ways to get rid of it were either by opening a new window, which would replace the dead one, or opening and closing the application menu. The latter proved to be more efficient when several windows were running silmutaneously.

Package Management

As Artix is not based on systemd like Arch Linux, it naturally relies on its own repositories to provide software that's independent from its parent distribution's init system. Since Artix does not ship with a GUI manager, package management is done via pacman. By default, only three repositories are enabled, though pacman.conf can be edited to allow access to more supported repositories like universe, which acts like a systemd-free pendant to the Arch User Repository. Another repository named Omniverse can be added to get access to non-free software, such as drivers for NVIDIA GPU's.

While the system update went mostly smootly, my user suddenly got logged out and I was sent to tty just after pacman finished updating icon theme caches. Logging back in via TTY, it was impossible to do basic things like reboot and restart X server without root privileges. Granting myself the required privileges with su, I chose to reboot the system and was, perhaps, lucky to be logged in to a working system.

Performance

Before continung to explore the system, I decided to let the VM sit idle and observe its resource requirements. But before I could start, I had to download and install htop, as Artix only offered top out of the box. Overall, Artix Xfce running on s6 is fairly midweight in terms of hardware requirements, needing only 469 GB of RAM when idle. Even within a poorly-configured virtual machine, Artix barely experienced any decrease in speed and did not start to slow down until I opened Epiphany.

Speaking of browsers: Despite the bottom bar offering a web browser shortcut, the default browser has to be manually set to Epiphany upon first usage. The browser itself would then open four pages leading to the repositories offered by Artix, the project's wiki, its forum, and the distribution's homepage, which not only was quite annoying but also began to noticeably affect the system's performance.

And Back To Package Management & Documentation

As I am not the biggest fan of Epiphany, I wanted to download my preferred browser, LibreWolf. Unfortunately, it can only be obtained with the universe repository enabled, which is what I had to do first. The Artix wiki recommends to copy and paste a list of servers to pacman.conf, since there is no separate mirrorlist included by the project itself. Being quite familiar with Arch, this advice came off as a bit sloppy to me, as it is uncommon to include mirrors directly in pacman's configuration file. And only then I would notice that Artix' live ISO does not ship with vim, only providing vi to get the job done.

After saving the new configuration and updating the database, I assumed that downloading a graphical software manager like pamac would make things a little easier. The wiki states (in a rather annoyed tone on its troubleshooting page) that GUI managers can be downloaded from universe, however once downloaded, pacman informed me that pamac is “incompatible with Artix”.

Since the wiki merely covers the installation steps, some basic facts about the init systems Artix can run, and available repositories, I went back to the project's homepage, as even I did seem to miss that the Community versions are supposed to be the “just works” variants of Artix. The Community versions are not labeled by the desktop environment they rely on but their underlying frameworks, GTK and Qt, only offering a choice between MATE and KDE Plasma, with LXQt and LXDE as lightweight alternatives. Both Community ISO's are twice the size of the bare-bone ISO I downloaded and only offer OpenRC – no s6 or any other init system and the very reasons why I did not download any of those in the first place.

Quickly checking the project's forum revealed that I am not the only one who “does not read documentation”, as two users recently tried to download a package to enable support for Arch Linux but couldn't due to the package having been moved to universe because, according to the developers, “more and more packages are available through out repositories”.

Other Observations

Sometimes after logging in, Xfce would start with an empty window opening and closing within a split second. This random glitch does not occur in a predictable manner that could make the possible source of it somewhat noticeable. But this should not be the only sign that the live ISO's of this project do not receive as much attention from their developers as needed, as taking a closer look at the dotfiles Artix requires reveals that the project once must have relied on Midori as its default browser. Why dotfiles for thw window manager Openbox, which cannot be aquired via a live ISO of Artix, and KDE Plasma Workspaces exist in the first place, may be something only the developers possibly could know – they certainly are not required by a vanilla Xfce4 desktop to work properly.

To check how Artix handles old packages, I decided to run sudo paccache -r, only to find out that Artix does not support paccache.

TL;DR

I'm not exactly sure how to judge this distribution without merely stating that the project is drifting away from its roots and not really having much in common with its parent distribution anymore. There also is not a need to get reminded that this project was largely born out of a strong dislike for systemd, yet Artix is not what Devuan is to Debian, and the quiet famous Arch Wiki is mostly useless when trying to figure out Artix, which could be compensated if the Artix Wiki would not make passive-aggressive remarks in some areas.

Overall, Artix XFCE s6 appears to be in a somewhat neglected and messy state that I would not want to install on bare metal. And I could not agree more with user “onekk” highlighting the possibly counter-productive philosophy of Artix. I'd even go a step further and blame the project's confusing state at its developers' irrational hatred torwards systemd.

---

Hardware

Medion Akoya E4070 D

Processor: AMD A10–5700 APU @ 3.40 GHz

Display: Trinity (Radeon HD 7660D)

Memory: 4 GB RAM (3462 MiB)

Storage: 1 TB ST1000DM003-9YN162 (CC4G)

Network: RTL8111/8168/8411 PCI Express Gigabit Ethernet Control