Evaluating Artix Linux with OpenRC, KDE Edition

In an article for Distrowatch in July I looked at Artix Cinnamon and Plasma editions with Runit to start up and manage services. That indicated a problem in the sense that if reliant on software written for Systemd that no ready-made Runit service scripts are available for one will have to create their own. Specifically, I had a problem getting my VPN client to work. Let's see if this works any better with the OpenRC flavour of Artix.

This is really a follow-up but for those who haven't read the original review and not familiar with the distribution here's a quick recap.

Artix is a Systemd-free fork of Arch Linux that grew out of the Arch-OpenRC and Manjaro-OpenRC projects joining forces to provide installable images with alternative init solutions to Arch users who were unhappy with the parent moving to Systemd. In fact, Arch was one of the early adopters. While in the beginning only OpenRC might have been offered, Artix now also provides install images using the Runit and S6 init software. There's a lot of choice on the download page, only the x86_64 architecture is supported. The project provides Artix basic images of 520MB, similar to a net-install or the Arch install images, and with Cinnamon, MATE, Plasma, Xfce, LXDE and LXQt also ISOs for every major desktop environment. They come in between 939MB and 1.1GB depending on your chosen flavour - not too big a download these days. The page makes it clear what to expect, i.e. only a basic set of applications is included to get the user started.
A file manager, a media player (MPV), a network manager, a document viewer, a web browser and the graphical installer. It is then up to the user to add applications and shape the system.

Every flavour is available for download with any of the three supported init systems. Official images seem to be respun now and then. Although there are weekly images, at the time of writing most stable images were dated from February 2020, with the Xfce ISO labelled 20200506 apparently released in May.

Artix boot screen

Overall the desktop experience with the OpenRC version was exactly the same and presented with the same issues, namely the installer shortcut not showing up on the desktop if any other language rather than English was chosen to localise the Live session. Or rather, it DID show up infrequently. The menu also presented with the same entries as the runit edition. I am still puzzled why two archive managers, Ark and Xarchiver, are included in the otherwise sparse collection. By all accounts the only difference is the chosen init system which many users won't even notice until they need to manually set up services to run at boot and shutdown.

Artix Plasma desktop  with link to the installer showing up this time

...and again not showing.

Service scripts are available in the Artix package manager for various cases and they need to be installed alongside the main package if we want to run it at boot. This is quite well explained in sections of the manual that shortcuts on the desktop point to. However, the team behind Artix cannot possibly know of and make scripts available for all software and use cases out there so at a point you'll be on your own. This is something to seriously consider when choosing which init system to go with as most services these days seem to be configured to automatically work with and start with Systemd only without any further user intervention.

Installation

I covered this in the previous review. Artix uses the Calamares installer and it's a straight walk through with the usual steps, but be careful to read the summary squeezed in at the bottom before committing to disk.

The Calamares installer - steps on the left and summary at the bottom

I already had an existing install which I updated to the latest Linux 5.8.4 kernel and Plasma 5.19.5 in the Arch/Artix repositories. The jump from Plasma 5.17 went well but left me with some theming issues to be sorted out.

After this and with the Kodi media center, the Brave browser and the Octopi package manager added the system consumed a little over 6 GB disk space. I believe the 1.1 GB ISO initially extracted to somewhere around 5.6 GB for a fresh install.

With Octopi running KDE 5 Plasma used 491 MB Ram in the following screenshot so it will be slightly less for a new install.

 

Artix KDE does not come with many onboard applications and no favorites defined for us in the menu either. MPV is on board for video files, Okular is the only application in the office section (and probably only here to enable us to open and read the documentation linked on the desktop to help us get started) and Falkon is the web browser in the Plasma edition.

Like before Kodi was added from the repositories and the Brave browser from AUR. The install and operation of Octopi was flawless in the Plasma environment, as opposed to Cinnamon where it had caused a problem with authentication. Pamac had shown to be the better solution there for graphical package management and it also allows us to enable the AUR and install from there, a function that Octopi seems to be lacking.

A pristine Plasma 5.19 desktop after the upgrade from 5.17.

In general, large system updates are better done with Pacman at the command line and graphical package managers used to look for and install specific packages.

Now, what about my VPN service?

One could just run with the browser plugin installed to circumvent any problems but this will only isolate your browser traffic.
The other possibility is to use the generic OpenVPN client and the networkmanager-openvpn addon. This might be the easier solution. In this case the Artix team already provide a openvpn-openrc package which basically just installs the script so the service is started by OpenRC. Ideally this is what you want for all clients and services you want to start. But I'm not looking forward to importing about two dozen .ovpn configuration files and using Networkmanager doesn't quite cut it.

If you're running any sort of VPN service except your own you really want to use the client offered by your chosen provider to take advantage of additional services like kill switch, list of locations and being able to quickly change between different protocols.

My client is in the Arch User Repository. Like many slackbuilds for other package formats, what the build script does is actually just a repacking of the Debian binary so it can be installed on Arch Linux systems. This also works on Artix as a derivative but the repack does nothing about start up and shutdown scripts as Arch just like Debian is using Systemd so this part doesn't work on Artix.
To execute the repack and add the package from AUR I had to install binutils, otherwise you get this:

"==> ERROR: Cannot find the strip binary required for object file stripping."

Once this is done the package installs fine. Running the usual command to connect results in an error message that the service is not running and prompts us to start it with a systemd command. However, I found we can start it with  "sudo /usr/bin/binary start".
Now typing  "myvpnservice connect" works and prompts for the login credentials. Thinking of the Slackbuilds repository earlier gave me another idea and I was able to adapt the start/stop entries for the /etc/rc.d/rc.local file from there so that from now on the service will start at boot time.

CPU usage with the service running is once again in the 2% to 4% range on each core, quite the difference compared to my attempts with runit.

Conclusion

Trying to get my VPN service working under the Runit edition was quite a challenge and resulted in high CPU usage of about 25% as the init service was new to me and obviously too different. I had been unable to properly work out the calls and write my own init scripts to get the service up and running as intended.

OpenRC on the other hand did not pose such a problem and I was able to get it to work with a bit of input from the Slackbuilds site. This is because the two init systems are not too dissimilar and OpenRC works on top of traditional init systems like the one used in Slackware.

The Plasma install with only a few additions and clock widget. Enough to be hooked to the old TV via VGA.

This is definitely important to take into consideration when trying to move away from Systemd to one of the many alternative init systems, including the older SysV, while having to run services at startup reliant on init scripts that are not provided by your chosen software packages. If startup scripts are not provided by your chosen distribution nor by the supplier of the package do you have the skills to work out where to put them and write them yourself? May the distribution maintainers make it available for you on request? Do not forget to look at other distributions for inspiration.

Know your limits. For now OpenRC is the better solution for me because it is more like the SysV and BSD init systems I am used to.