magda

Last year, I published a brief review of the Arch-based distribution Archcraft on Medium. Shortly afterwards, its sole developer released a new version dubbed “New Archcraft”, which would break with all previous releases and thus require a fresh install. At that time, I was unaware how deep some issues of the original Archcraft ran, as I currently am finding out.

Strange Dependencies

As the original repository became obsolete, I deactivated it in pacman, not knowing how many configurations were almost entirely dependent on it. While the “fancy aspects” of polybar and obmenu remained intact and packages such as archcraft-cursors were not removed automatically, polybar's base, yay, downgrade, betterlockscreen, plymouth, obmenu-generator, i3lock-color, and cava now needed to be linked directly to their original AUR packages.

Personally, I still do not get this seemingly random choice of packages. While lxdm also turned out to be dependent on archcraft.db, neither did it end up being removed (partially or entirely), nor is it among the packages now in need to be linked to its AUR counterpart. downgrade, on the other hand, is a simple script to simplify a downgrade process and already happens to be fully functional on its own, requiring no tweaks that could possibly justify to be separated from the AUR. And while packages like archcraft-cursors remained installed and fully functional, the custom configurations for plymouth and betterlockscreen got removed entirely during the switch-and-upgrade process, meaning both offered no local dotfiles that could be re-added to their specific global folders manually and were reset to their default configurations provided by their respecting projects.

The main reason why I am addressing this initial side effect is due to the lack of proper documentation provided by Archcraft's developer regarding the fundamental aspects of his distribution and the drastic changes implemented with the release of “New Archcraft”. It is not possible to tell which packages are dependent on which repository without turning Archcraft's own repository off.

Missing Global Configurations

At the time of writing this, I just finished re-configuring betterlockscreen and came across a bug exclusive to “Old Archcraft” reulting in sound to be automatically muted after waking the system up from sleep mode. Whilst searching for the cause of this, I noticed that some global configurations for betterlockscreen, alsa and pulseaudio simply did not exist in /etc, meaning that any Archcraft user that, at that time, would have created multiple user accounts would have encountered several significant issues with any user account created manually after installation, as crucial global settings were stored only in the first user account's /usr directory. I can not tell whether these global files were missing from the beginning or got removed automatically when deactivating archcraft.db anymore. Either way, this poor configuration of alsa in particular is not encouraged by ArchWiki, which recommends the creation of a global .conf as first step.

Later on, I discovered that /etc/pulse/default.pa.d was also missing for no obvious reason. Whether the missing global files of both alsa and pulseaudio are responsible for sound auto-muting itself when initiating sleep mode still needs to be figure out, though it is frustrating to first have to manually create global settings first that should have existed “out of the box” or at least should not have been tied to a smaller, now-obsolete repository in the first place.

Conclusion

As it turned out, Adi himself was unsure about the nature of his own repository, which does justify “New Archcraft”, yet simply was not – and still is not – communicated properly. It is possible to even upgrade a stable install of Debian to its latest stable release just by changing its repositories. While this might not be recommended due to possible incompatibilities, it has yet to cause the same amount of damage as I am experiencing with Archcraft, which had some of its core functionalities tied to a separate repository that eventually became obsolete. There is no logical reason to provide separate packages of tools like downgrade, when those do not even require manual intervention after updates if a proper local .config for re-adding or even a local script exists. Some tools are tied so deeply to the defunct archcraft.db that it removed their bases, which remained unchanged by Adi and thus only prevented updates not even affecting the “rice”, as those were stored entirely locally. The missing global configurations of alsa and pulseaudio indicate that the entire core of Archcraft was faulty to begin with, hence desperately required to be re-configured from scratch.

Of course, this will require a new test of Archcraft's latest version, though checking the issues listed on Archcraft's main GitHub repository, it appears this distribution still suffers from some design flaws that easily could be fixed if Adi would just provide additional scripts (in one case, he even claimed it would not be possible, which was disproved by himself in another issue).

For Further Debate: The Core Flaw of Niche Distributions

In terms of documentation, the official homepage still is in a half-hearted state, which requires those wanting to contribute to study closed GitHub issues to figure things out. This a very common issue of “niche distributions” which only one or two people happen to work on (more often than not) in their spare time. Even the more-known elementary OS suffers from the exact same issue of niche distributions that solely focus on providing a “fancy Desktop”: Their main “selling point” might work, yet its base almost always turns to be badly configured to ridiculous degrees and will become apparent until users start to mess with it.

I would even go so far as to claim that such distributions are fundamentally pointless, as such distributions almost always target those with the least amount of technical knowledge and skills. This becomes a huge issue once such users encounter bugs, as they often end up requiring manual intervention by said users and knowing which forums to rely on. And it would not be far of a stretch to assume that the majority of average computer users do not know anything about GitHub and likely would get scared by such places. For the developers it would be less of a burden to simply continue to provide “rices” for advanced users to download from sites like GitHub, rather than to create a separate distribution unintentionally (or even intentionally in the case of elementary OS) tricking the average Windows or macOS users into assuming it is perfectly tailored to them. Such distributions simply are not and can not fulfill their own promises due to their developers' flawed assumptions about “average users” and poor communication skills.

This problem will be elaborated further in a separate post once I have gathered more examples, so for now I can only recommend to not use such distributions, unless you are capable – and do not mind to – fix some bugs and poor configurations on your own.

__________________________________

Some additional bugs and oddities discovered after publishing this summary

7 April: I finally may have figured out why “New Archcraft” relies on SDDM as its default Display Manager. Previous version came shipped with the GTK2 variant of LXDM. Unfortunately, it is quite time-consuming to customize and may become a security issue, if users want to change the face icon of their user, as the desired face icon is being stored in the user's home directory. This, in return, would require global read-and-write permission for home due to LXDM lacking a caching system similar to betterlockscreen. While “Old Archcraft” was not designed to support multiple users, this still is a significant aspect.

Another bug only occurring on one of the three machines currently running on Archcraft is affecting screen brightness. When booting, brightness remains at max, though lowering it using hotkeys results in brightness jumping straight to its lowest setting, oftentimes not even reacting when wanting to increase it. When logged on, the GUI fails to detect the correct percentage, always residing at 0%, and Archcraft is only able to switch between two or three levels of brightness.

The nastiest glitch, which boils down to the same core issue, is screen tearing, which currently affects all of my machines. Adi, unfortunately, assumed it only affects machines with AMD GPU's – both of my laptops are Intel-based – and published a small guide to mitigate the glitch. Testing it on my AMD-powered tower, the solution did not fix the screen tearing and will likely require the re-installation of drivers, as it appears that the installer, at one point on “New Archcraft”, even removed AMD drivers after installing them. The new guide, despite no longer excluding other GPU's, warns users that this solution might not work on all machines, and I really do not want to test another solution with random consequences, at this point.

Both issues, screen tearing and brightness, are a result of a faulty installation process, which occurred twice on this machine – the Acer laptop – and my tower (the latter still requiring an in-depth check on its own). According to the project's GitHub page, the installation scripts, even with the release of New Archcraft, still tend to not function properly for seemingly random reasons. You either are lucky and all files will be copied or you are not and random files will be missing entirely, even if the installation itself demonstrated no signs of issues.

(Please, Adi, instead of introducing new Window Managers and focusing solely on putting as many themes into the system as possible (and producing even more), maybe you should take more care of what's under the hood of your OS and leave some themes as optional choices during installation. ArcoLinux does this, too, and no one, besides some fanatics from r/unixporn, needs two WM's with dozens of themes each. It defeats the purpose of an operating system and I am not sure why anyone would want to fund your project at this stage. And I honestly don't know why you are hiding in your Discord channel, quietly begging for donations just to keep the homepage active. If I were you, I would be worrying about something else.).

4 May: A series of issues currently causes some headaches in regards to up- and download speed. Whilst troubleshooting, I discovered that Archcraft lacks the quite popular network driver r8168, which my main machine requires. Most popular distributions offer inxi to quickly check one's network; Archcraft does not, hence I had to dig through the output of lspci. After downloading and installing the correct driver, the wrong driver – r8169 – turned out to be irremovable via CLI, prompting pacman to claim that this package does not exist. Manual deletion via Thunar does removes the driver, yet does not disable its respecting kernel module, which now is enabled alongside the correct one.

Surprisingly enough, the wrong driver was not responsible for download speed remaining below 230 KiB/s. This issue also only appears to be limited to downloading Arch Linux updates on one machine, as a quick speed tests with ping and Cloudflare (web) on all three machines revealed.

Even more surprising, one New Archcraft user recently reported the opposite, stating that his internet speed is being drastically reduced when browsing the web with Firefox and using Discord.