07/04/2026
From Arch To Artix – VM Tests
I first went from Archcraft to plain Arch
in 2021 after Adi thought it'd be a good
idea to replace Archcraft's old repos
with new ones that were identical to the
old one, further raising my doubts about
the distro that exclusively relies on
Discord support. Some Archcraft-specific
configurations got replaced, others are
kept as local packages and files. All of
my devices, both laptops and my daily
driver, have been running on Arch since
then but more out of necessity; only
Archcraft is capable of running on a
very cheap Asus from 2013 with persistent
power issues AND a 14-year-old Acer
Aspire that runs on x86_64 but was
shipped with a classical MBR partition
scheme where three out of four primary
partitions already got claimed by
Windows 7 and Acer's own proprietary
recovery environment. With the exception
of some systemd bugs, Arch borking GRUB
and then blaming its users for relying
on GRUB instead of systemd-boot, and the
recent issues caused by X.org which only
stopped after I put its core packages
in my IgnorePkg, all systems
are much more reliable than any Windows
version I've used so far (which have been
all but Windows Me and the Windows 3x
series).
It's hard to deny, however, that I never could warm up the "Arch way". Its own website doesn't even state that it actually is highly opinionated but still had to go with it even after studying its famous Wiki, which... actually is pretty terrible if you don't use GNOME or KDE Plasma (or any software that pretty much replicates a stock Fedora setup). Despite this, pacman still is very pleasant to use and no package manager even comes close to its speed. The AUR is what ultimately sold me and I managed to tailor each install to its respective machine without going the Gentoo way. I like Gentoo, don't get me wrong, but the constant tinkering prevents me from getting anything done.
The recent panic regarding age verification was the final straw to me. I already avoid the Arch Linux forum because it's quite useless for the most part and it speaks for itself when the only people providing support are the same four terminally online men that lack any kind of social skills. The Age ID outcry prompted me to check the forum, only to witness how every thread just asking about it was instantly sent to the dustbin. Only one thread where one user mentions that their thread got deleted without any explanation remains and the "core" of Arch visibly avoids and distracts from the topic but still somewhat subtly implying that they would not be against it if systemd would implement such mechanisms. While the current mechanism is more of an expansion of parental controls with an optional BOD field, the current political climate is pushing for stricter verifications on the OS level across the globe. This is something that cannot be ignored and thus trivializing it proved to me that the people behind Arch Linux are unprofessional.
Why Artix?
I already tested Artix Linux a few years ago and was quite satisfied with it until I noticed how many leftover files from the dev's personal install got installed, as well. Its Desktop ISO's thus disappointed me in that regard but I was more than pleased with how snappy s6 was. Sadly, Artix' poor documentation extends towards its main selling point and you mostly are on your own trying to figure out the more obscure inits such as s6 (back then also often combined with Suite66) and the more recent dinit, which resembles systemd at first glance but lacks the Poettering philosophy. I also tested runit and OpenRC back then but whereas OpenRC was noticeably slower than systemd, runit is almost too minimalistic and slower than s6 which got more capabilities.
It shouldn't be too surprising that dinit
caught my eye, alongside the Migration
tutorial and the
artix-archlinux-support
package that includes dummy files for
programs dependent on systemd. Before I
make the jump that could render my machines
useless, I decided to do some test runs to
get familiar with dinit and compare it to
s6, which I still would like to figure out.
Artix Linux Xfce (dinit)
Those who may have read my old blogs on paper.wf or even on Medium should already know that I run on ancient budget hardware. My VM tests thus aren't designed to just take the low specs into account but test the absolute limits of each distribution, meaning each VM is purposely configured with the most ridiculous low specs no computer released after 2010 offers. Since I upgraded my daily driver's RAM before the big price hike, I just went "fuck it" and gave it one core and 6 GB of memory because... why not, the actual performance is not what I want to focus on since Artix already proved to be quite stable and fast in the past even on utter garbage VM's.
Acer config
Obviously this ISO still ships with a
buggy Xfce experience. The audio always
gets muted and the GTK2 themes no
longer work well after GTK2 got
deprecated. Overall it doesn't look
like much care is being put into the
"cosmetics" of the Desktop ISO's, at
least in the case of Xfce. I installed
my Acer Aspire's Fluxbox configuration
(minus Lemurs) and most of the
software it depends on, namely Alacritty,
PCManFM and LibreWolf. I first hit a
wall when I noticed that Artix doesn't
offer xfce-polkit. No other
Polkit agent wanted to run, so I enabled
some Arch repos and installed yay to make
it easier to install AUR packages.
Just to be safe I also installed
artix-archlinux-support
that I will require once I test my Asus'
Fluxbox configuration which relies on
the systemd-dependent dunst to handle
notifications.
After updating some configs and replacing connman with Network Manager I finally replicated my Acer config. This was a rather easy task in itself since this config is the least dependent on systemd. More time was spent on fixing bugs Artix got shipped with, so right now I still can't recommend its Desktop ISO's.
It didn't help that right after I ported my Acer config, Artix announced that new ISO's now default to Xlibre but still package X.org. I decided to stick to X.org for the time being and moved on to port my Asus config.
Asus config
There isn't much to say other than I didn't have to worry about dunst, as Artix offers a package that is not dependent on systemd.
Just after a minor system upgrade I
discovered another package that
shouldn't be installed.
xf86-video-wmware is
not even offered by Artix and was
pulled from the AUR but for some
reason this ISO had it pre-installed.
It bricked X.org until I removed it.
I also updated VirtualBox and did
a brief Xlibre test, only to find
out that VBox 7.2.0 and Artix don't
get along, so I downgraded VBox.
This only partially solved the sudden
sluggish GUI behavior.
Even after diabling the Machine ID change, Alsa/Pulseaudio continued to start in a muted state and my cursor also got reset with each (re-)boot. At this point I genuinely got frustrated with Artix and thus decided to clone an old Arch VM to do a test migration.
Arch VM Migration
Since this machine remained unused for several years, this install was in dire need of a system upgrade. Ater I resolved every new dependency hell, I learned that the DE I chose back then, Budgie, has changed a lot since I last used it. It now relies on Sway AND labwc as Wayland compositors. Other than that, the upgrade didn't break the cloned VM.
There were some minor hiccups during
the migration that later turned out
to be fatal. Not only did I yet again
encounter the unintended return of
the VMware drivers that caused X.org
(and later Xlibre) to segfault, both
display servers complained about my
unchanged host name and refused to start
any DE, WM or Wayland compositor, despite
not generating any errors (except for the
missing VMware module which caused the
annoying segfaults in the first place).
Even after trying every solution I came
across on various forums, including
Gentoo and FreeBSD, nothing worked –
and that's when I noticed that the
migration also wiped my
/run/user/1000 folder.
Not a single file was left and the
D-Bus service accounts-daemon.service
turned out to be gone, as well. Since
Artix dropped its support for GNOME
and various components typically
associated with GNOME, Artix's dinit
implementation does not offer any
replacement scripts for this daemon.
Obviously this raises the question how
Artix is treating Budgie and other
GNOME-based DE's. I digged through its
package search and found a rather
conflicting stance. While Budgie and
Pantheon are not offered by Artix,
itself
still is available and receives updates,
despite the
announcement of Artix
dropping support for GNOME dating back
to September, 2025. The package's
last update was shipped in February, 2026,
five months after the announcement that
excluded gnome-desktop for
unknown reasons.
Conclusion
Right after this, I reverted my cloned VM and decided to not bother with Artix Linux anymore. Not only are the Desktop ISO's still shipping with files for programs that aren't even installed, the migration guide is hilariously incomplete and the migration itself prone to corrupting various programs. The overall development always came off as pretty messy to me, giving how they maintain multiple Desktop ISO's that all seem to copy files for uninstalled packages with multiple inits which aren't properly documented for the most part (if it weren't for Gentoo even OpenRC would be hard to figure out). The forum itself is friendlier but even less helpful than the Arch forum. Throughout this endeavor I used anything BUT the Artix forum that is fully unaware of even similar issues and, to my own surprise, I found no one asking for migration support. Only single post on Reddit warns against a migration to Artix for loosely related user issues.
I REALLY want to like Artix but the more I test it, the more I start to despise it. This test alone was so frustrating that I decided against setting up a "GNOME-free" VM to judge the migration guide more fairly, though there's nothing fair about the laziness in terms of their own docs. For the most part users are being pointed to the Arch Wiki which recommends a high degree of systemd dependence.
And this hot take by one of its developers is peak comedy:
GNOME was dropped because it made the decision to demand systemd; systemd sucks, tough luck, end of story, goodbye. XLibre and PipeWire were adopted over Xorg and PulseAudio because they reached a point of better functionality.
We don't allow politics to dictate our decisions, unless said politics make software patently worse. Similarly, we won't refuse to package quality software because its developers express "questionable" opinions.
I hate systemd but at least it works.