Distro Test: Archcraft (June 2022 Version)

Despite initially planning on not wanting to test any new version of Archcraft due to Adi, its sole developer, never providing a solid reason why users should get rid of the old version of his distribution and install “New Archcraft”, I had to download a new ISO to be able to chroot into my installed version, as “old Archcraft” does not tolerate chrooting from another Arch-based distribution such as EndeavourOS, warning me that the live user is not allowed to gain access to passwd. Never having encountered such incompatibilities between two Arch-based distributions, I was wondering if “New Archcraft” suffers from the same issues I would encounter within a year of using this distribution.

But not only were my low expectations proven to be justified, the project's main community channel on Discord is largely being used by its developer to beg for money and to be arrogant towards other Linux distributions.

Live System

First things first: Due to having seen an increase in available skins for both Openbox and bspwm, Archcraft's ISO grew to 1.9 GB in size – roughly 400 MB more than its “old” version from June, 2021. The live ISO takes a minute to boot both within a virtual machine and on bare metal, though in VirtualBox, Archcraft fails to adjust its screen resolution automatically, with nearly the entire Desktop being blocked by a welcome window, which, in few cases, can open too far to the right, blocking access to the close button and having to use Windows key + c to get rid of it. Once the screen resolution was adjusted manually, both the wallpaper and Polybar failed to adjust to it, as well, forcing me to log out of the live user and start a new session.

The most obvious changes Adi made to his distribution is the increased “candyfication” of Polybar and OB-menu. Polybar's default theme now is more more colorful and rounder than before, while OB-menu now supports small, colorful icons next to all options. It is somewhat unfortunate that those icons initially distracted me from some new features within the menu, such as stats (which got its own fair share of issues within a virtual environment), which can be hovered over to show system information, and screen recording, which replaced Shortcuts and programs such as Color Picker (which also got replaced by the clunkier GPick).

Before installing the system, I skimmed through the Themes provided for Openbox, as this received the most attention by Adi. While “old Archcraft” only provided eight themes and two “Bitmap” variants of forest and beach for Openbox, “new Archcraft” now provides 18, alongside the mentioned “Bitmaps”. Neither I, not my mother considered the light skins – slime, kiss and the like – pleasant to look at and and the Windows 11 ripoffs creative (and I honestly do not know why anyone, besides few r/unixporn addicts would want their Linux system to look exactly like Windows 11). Annoyingly enough, some styles are much more suited for laptops, rather than stationary Desktop PC's.

Installation

Archcraft still offers two ways to install the OS: The beginner-friendly Calamares Installer and a CLI Installer previously known as “Archcraft Expert Installer”. During installation of “Old Archcraft” I repeatedly encountered issues with Calamares, with the installer stalling when attempting to create initframfs. The CLI Installer, on the other hand, had issues of its own, which showed up inconsistently and varied from machine to machine.

First wanting to see, if the GUI Installer has changed, I ran Calamares. As it turned out, no changes were made to it, besides new slides that will show up when Calamares is installing the system. If I would not have payed close attention to the text below the progress bar, I easily would have missed some default configurations being set without being given the option to change them within Calamares, such as disk encryption, which is set to be done automatically and was only seen for a slit of a second. The Toggle Log option logs nothing but the start of Calamares, ultimately being useless when wanting to check what's being copied and set in detail during the installation process. With image 1/2 consisting of 392.429 files that need to be copied, Calamares slows down significantly at 7% and freezes altogether at 63% during the creation of initramfs. Those were the same issues I already encountered when attempting to install “Old Archcraft” on three different machines.

Since there is no way around the “expert way”, I ran the CLI Installer, which also has not changed in the slightest since I gave this distribution a first chance in 2021. The base installation took nine minutes, with the installer freezing at 100% for two minutes. The whole procedure too approximately 13 minutes via CLI.

Installed System (VirtualBox)

Since the CLI Installer does not offer the choice to log in automatically, I was prompted to enter my password upon booting, initially not noticing that the default session was set to bspwm due to sddm's tiny font used for session selection. Once logged in, I was greeted by a different welcome screen quickly summarizing keybindings for both Window Managers. However, attempting to close the window with Windows + c proved to be just as ineffective as attempting to kill the application with STRG + Alt + Esc. Attempting to log out and to shut the system down did not work with the given keybindings, either, hence forcing me to kill and to restart the virtual machine. This time I selected Openbox to not get stuck again, though selecting it temporarily froze the system.

Simply navigating the system already revealed an annoying glitch that has been present since “Old Archcraft” and has been addressed on Archcraft's Wiki since Day 1: Screen tearing. The wiki recommends two options to fix this bug:

  1. Enable 'glx' in Openbox's backend, or
  2. Create a separate configuration file for GPU drivers and store it in /etc/X11/x.org.conf.d.

The first “solution” came off as downright ridiculous to me, as my “Old Archcraft” install has got glx enabled by default, yet still suffered from screen tearing on all three machines even when just a tiny window was just being moved. Solution #2 does, however, fix the issue, though Adi appears to be even more confused by this glitch than I am, as “Old Archcraft” already offered two config files for amdgpu and radeon, yet simply turned out to be incomplete and in the wrong directory (X11's folder in /usr/share/ instead of /etc/). “New Archcraft” lacks those files altogether. Even more strange: Applying the same fix on machines with Intel GPU's causes the performance of the system to decline, which is most noticeable when opening an internet browser. This is an issue I've yet to encounter on other Arch-based distributions or any other OS, in fact this appears to be a bug exclusive to Archcraft, old and new.

And just like “Old Archcraft”, its “new” version comes with automatically-installed programs such as Timeshift – which is useless, if you choose ext4 when running the CLI Installer – and hard-coded applications such as Plank, which autostarts regardless of what theme or session is being chosen. Some themes like Hack actually look “clean” until moving the mouse to the right or left-most side of the Desktop, revealing a hidden Plank bar that does not even match with the rest of the theme. Only forest seems to be the only theme in which Plank runs as a mere background process for no reason.

Performance (and more bugs)

Overall, “New Archcraft” consumes just as much CPU resources and memory as its predecessor, barely comparable to my old and tweaked, “Plank-free” version, which idles at around 400 MB RAM. As this OS runs within a virtual machine with intentional bad specifications, it was no surprise that CPU usage would go beyond 40% when moving windows with a mouse.

Annoyingly enough, when I tried to take a screenshot of the window running htop, the only result I would repeatedly get was an empty image. Attempting to circumvent this by trying to capture a limited area of the Desktop resulted in the whole screen turning blue, with the blue first limiting itself to polybar when navigating the mouse to the upper-left corner and then taking up the whole screen again when trying to capture the running Alacritty window. It would occur again when I wanted to do a system update.

The bugs did not end there, however. Initially, it was a bit of a surprise to me that chaotic-aur has been implemented and is set to be active by default. With Arch Linux's main repositories, Archcraft's own repository, AND Chaotic AUR being set as default repositories, it is hard to figure out why certain community packages such as downgrade are being pulled from either Adi's own repository or even Chaotic AUR, even though he made no changes to their upstream versions and makes no attempt at explaining why he thinks this is more beneficial or the like.

Unfortunately, my attempt at updating the system came to a full halt when noticing the download speed. It turns out that this is the same issue I repeatedly encounter when running Archcraft's old version on all of my three machines, with my Realtek-powered tower experiencing it much more often and more prominently than both of my Broadcom-powered laptops combined. This more-than-significant drop in up- and download speed only occurs within Terminals running either yay -Syu or sudo pacman -Syu, as several web-based speed tests via Firefox (LibreWolf on my customized old versions) revealed that my internet connection was perfectly fine and ping providing no indication that this is an server-side issue.

(Even More Poor And Strange) Configurations

Just before finishing my test, I noticed some very odd configurations that possibly could explain why the OS takes way too long to download updates. Perhaps the least concerning one out of those has to be the duplicates of all dotfiles and the music samples. All dotfiles usually are located in /home, yet Archcraft also hosts the exact same files in a folder named skel that located just between dotfiles and Home folders. The separate Music folder is an inheritance from “Old Archcraft”, which also came with two music folders for no obvious reason besides providing sample tracks (which, to be honest, really are far from my cup of tea and were the first things I deleted after installing the OS for the first time). This begs the question, of course, which dotfiles are the “correct” ones that need to edited when a user decides to make changes to, let's say, the music player ncmcpp. Users are left to do a lot of guess work, which will I come back to when discussing the documentation of this project.

Now to the most concerning configuration: By default, Archcraft automatically starts Reflector, which already did not work at all on “Old Archcraft”. The system supposedly searches for updates automatically and informs the user of pending updates, yet this feature still does absolutely none of that even on this version. By contrast, the polybar skin used by forest registers a continuous and stable data transmission of 3 and 4 KB/s, though dnstop, which I installed just to check network usage, did not pick up anything that possibly could indicate that Reflector is quietly searching for updates or any kind of data being transmitted to any sever. Archcraft, even when not connected to the internet and being misled by VirtualBox, wants to send 3 to 4 KB of data every second to an unknown location.

Documentation And The Developer

As a “long-time user” of Archcraft, I can confirm that the Archcraft Wiki has been a poor state since the project kicked off, still largely only providing solid guidance for installations and few post-install tweaks. The only new additions are three lists of keybindings for Openbox, bspwm, and xmonad submitted by two users, which merely copy and pasted the respecting keybinding files and submitted those to Adi, and few translations of some pages in French and Polish. The main issue of the developer being very poor at communicating his need for assistance is an issue I already mentioned in my additions to my last review of Archcraft. But the longer this project goes on, its sole developer becomes more irritating, especially on Discord.

When Adi began to work on Archcraft, he claimed that his distribution is just “Arch with a bunch of themes” but recently he began to consider Archcraft as “a big project”. At the same time, Adi passive-aggressively shuns any mention of other Linux distributions – and especially those that are not based on Arch Linux – on his Discord server. If I were not so lucky, I probably would have missed that just after mocking other projects, he would refuse to provide help to an user who tagged Adi and requested help, implying that the affected user messed their configuration up on purpose (and only because Adi assumes that because his OS runs flawlessly on his machine, it automatically has to be the user's fault). This behavior of Adi lines up perfectly with his disinterest in providing support for his own project, still closing issues after just a few days, if no other user can provide any help, and rather spending his time – and I am not going to excuse my English here – being a dick on his Discord server for the shits and giggles, whilst also complaining that he struggles to turn his endeavors into monetary profit. (On the other hand, him putting his Myers-Briggs Personality Type into his Twitter biography already should have been interpreted as a big warning sign by me years ago; it is pseudoscience).

TL;DR

The amount of bugs and misconfigurations increases in proportion to the ego of its developer. Archcraft, unfortunately, is becoming an irritating project that causes headaches as soon as you want to tweak it a little. The transition from “old” to “new” largely was a superficial gimmick that did not solve any of the underlying issues of Archcraft and only introduced a new Display Manager (even though lxdm is still being available in Archcraft's new repository), some unexplained replacements of perfectly functional tools (Color Picker), more themes you cannot manually select during install, downright missing driver configurations to prevent issues like screen tearing from happening, and a community that largely cannot write decent sentences and is only here for the “eye candy” and shitposts.

If Adi would take his own project a little more seriously, he would at least attempt to fix core issues, instead of providing more and more themes for more Window Managers no one asked for and recommending commands on Twitter such as “sudo pacman -Syy” to install updates (that only does an database update!) or set the still-not-working Reflector to use “-Syyu”, which is not even recommended by Arch Wiki. But the cherry on top of this cake was Adi largely using his Discord server to look down on other Linux distributions, whine about his project not providing him enough cash, and shitposting – which is ironic, since his profile on GitHub states that he is “slow to respond” (when, in fact, he just can't be arsed to).

Archcraft might be a dream for those seeking a Desktop that is “straight outta r/unixporn”, however no one outside that Subreddit would be interested in a project that does nothing but provide a “fancy” Desktop on top of a badly configured base. Any other Arch-based distribution – and even Manjaro, which has become known for randomly withholding important updates – is not nearly as chaotic and downright confusing as Archcraft has become.

Please stick to creating themes and ditch Archcraft, Adi.


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