My distrohopping journey has been quite a weird one: From Fedora, to Arch Linux, to NixOS, and, at the end, Artix Linux. Obviously speaking, all of that is simplified to hell, as there have been many switches.

It's quite a silly story of how I got here: I was starting off to understand privacy and cybersecurity, and found what (then) felt like a gold mine: Fedora Linux. I got to try the 39th (or 38th?) release before I moved over to Arch Linux. All the fuzz made it seem like it was something really hard to get to work, but I ended up installing via archinstall.

It all went well, sometimes it would break, and sometimes I'd go back to Fedora. One of those times while using Arch, I found NixOS! I got it working well, but I felt as if I wasn't doing any of the juicy things, so I (naturally) went back to sweet, sweet Fedora.

It goes on from me moving back to Fedora/Arch/NixOS, so I won't be going further. Instead, I'll explain how I got into Artix Linux: I was interested in decreasing boot time, and decided to check Artix for the funsies: It really did well! I got used to it real quick, until, I broke my system to the point of reinstalling. From there on, I've been making my system more and more of a blob of bunched things I deemed as ‘good enough’ for my system. So you get an idea, my system has a considerable amount of directories (they're two) on the ROOT directory, which I use almost daily. To this commit, I have created a new directory over on the /var directory, which I'm considering to use for daemons.

Quick note to back up your things: I have lost my data various times all for not saving backups (and also some ocassional bullcrap), and wouldn't like for you to experience the same.

The Search / “The search for the inexistent perfection.”

Now, I face a choice which I really want to take: should I continue on using Artix Linux, of which uses most of the GNU toolset?

For context, I REALLY like minimalism. I can't live without it, if I say so myself. So you get an idea, I am using the suckless sbase, ubase, and plan9port binaries instead of the GNU-provided ones. In fact, some gzipped archives in the /files directory are gzipped with plan9port binaries.

“But why, though?” I hear you asking. “Why switch from something that has worked well?” Response: I hate clutter. I hate a lot of stuff, actually. But! The actual response would just be to try and find a place to stay and feel comfy.

…and a candidate for that is Chimera Linux.

The Potential Savior / “Chimera who?”

Chimera linux is, in it fullest form, everything I have done to my poor, poor Artix install: non-GNU userland? Has it. musl libc implementation? It has it. No systemd fuzz of any kind? It. Has. It.
And guess what's the best part? I can use bcachefs, which my current setup uses. Is it not great?

In their own words, Chimera Linux is:

“[...] a general-purpose Linux-based OS born from unhappiness with the status quo.”

— https://chimera-linux.org

Now, you might be thinking: “But, Stella, this just seems like a bunch of nonsense choices!” My response: You couldn't be more incorrect. To prove myself, I'll either recite (because I don't have experience with something, or simply can't think of something) or tell my personal experience on the tools Chimera Linux provides as default.

To start off: the userland (or core utilities, e.g.: ls, cd, grep, sed, etc.).

As you know from a bit back, I mentioned that I used the suckless sbase and ubase, as well as the plan9port binaries instead of the GNU CoreUtils ones.

This is mainly to fill my need of using suckless software, but at the same time to know for sure that my programs won't simply just break on me. In fact, the minimalism lets me open up the C file and simply “get” what it does: it does not only let me comprehend it, but allows me to tweak the binaries as I please.

Chimera Linux uses a fork of the FreeBSD utilities, which, from personal experience, can say that they work (duh!).

NOTE: The source code for the FreeBSD binaries are accesible [here]. I took some time finding them, so I thought about linking them.

To second off: the system initiliazer (e.g.: SystemD, OpenRC, sv-init (or sysvinit)).

The system init, of which is usually SystemD, is the program responsable for initializng the system, as well as user services.
Chimera Linux uses the dinit init, which is one, if not, the best init. The dinit initializer, although rather unknown, is one of the fastest, as well as the easiest to create init services: below is the ufw dinit script used by Artix Linux.

type         = scripted
command      = /usr/bin/ufw enable
stop-command = /usr/bin/ufw disable
restart      = false
logfile      = /var/log/dinit/ufw.log
depends-on   = pre-local.target
before       = pre-network.target
				

The services are usually stored in /etc/dinit.d, and, additionally, the on-boot scripts are stored in /etc/dinit.d/boot.d as symlinks. The log files are, as shown above, stored in /var/log/dinit.

To third off: the libc implementation (such as glibc).

Chimera Linux uses musl as it's libc implementation.

In their wiki header image, they simplify their [introduction], which says:

“a new libc striving to be fast, simple, lightweight, free, and correct”

— https://wiki.musl-libc.org

The nature of musl does have its drawbacks, however: some programs might not compile, or not work altogether, thus needing the user to either tweak or find an alternative for such program (which may be the only one of its kind).

To end off: the filesystem.

The default filesystem for Chimera Linux is nonexistent, as the user needs to manually partition and format their created partitions. However, the filesystem that comes by default on the ISOs is btrfs, which is a Copy-on-Write (CoW) filesystem that provides the use of subvolumes, of which allows the user to use the journaling feature of the filesystem for version control.

Sadly, though, Chimera Linux is still a recent (and small) distribution, so the package count is awfully low. But, hey, surely you didn't think that was all, right?
Open up to Alpine!

The second Potential Savior / “It stands for peak.”

Alpine (rudely said) is Chimera but without dinit as its init system. Of course, I'm oversimplifying things: Alpine came first, and then did Chimera.

Alpine, as stated before, is highly similar to Chimera, mainly in the aspect of its desing choices: musl, non-gnu utils (busybox), non-systemd init (OpenRC), and decides to be as minimal as possible. Did you know that they both share the same package manager, also?

Due to this, I highly doubt of re-explaining my turn-ons; just re-read the specs of Chimera and replace them with Alpine's. Since Alpine is older than Chimera (and also more popular), though, the package count is bound to be comparable with Artix Linux's repositories, thus making it more usable and preferable over Chimera.

…Psst, did I also mention that they both use doas by default? Isn't that great?

A Honarable Mention / “*BSD!”

This part was written on a notebook already, and, woops, too lazy to write it here.

…I'm obviously going to write it soon enough. Maybe.