FAQ

Is Chimera a fork?

No, it’s an independent project not directly derived from anything else.

What is the distro’s relation to Void Linux?

If Chimera build templates and process seem suspciously similar to Void Linux’s xbps-src, cbuild originally started as a rewrite of xbps-src to attempt to eliminate its various issues, and the main developer/founder of Chimera also worked on Void Linux. However, no actual code is shared with xbps-src.

Is Chimera an Alpine derivative?

Besides using the same user-side package manager (apk-tools), Chimera is unrelated to Alpine. The version of apk-tools it uses is also different, and the source packaging system as well as all actual packaging are written from scratch.

What about ChimeraOS?

The system also has no relation to ChimeraOS, besides the unfortunate name similarity. ChimeraOS used to be called GamerOS and renamed itself to ChimeraOS later; however, at this point Chimera Linux was already in public development with its name in place.

Why Python for the source packaging?

Python was chosen as it’s more or less the standard scripting language on Unix-like systems nowadays and is robust and portable. The cbuild system does not rely on any modules outside of Python’s standard library. The Python syntax is also flexible and adjustable enough to make for a nice syntax for templates without having to invent yet another DSL that would introduce its own bugs and need its own parsing.

So, why use a BSD-based userland anyway?

While coreutils may seem lightweight enough to not cause any issues already, there are some specific reasons the system uses a BSD-derived userland. The primary one is probably that the code of the BSD versions is overall much cleaner and easier to read. There are no cursed components such as gnulib, the codebase is leaner, and more aligned with the project’s goals.

Other reasons include helping the goal of improving software portability, as using a different userland tends to expose a lot of assumptions in various codebases, as well as improving bootstrappability and additional convenience; the core userland tools are not just coreutils, but also a a lot of tools around that (findutils, grep, sed, and so on) and some of those actually already introduce undesired dependencies into the bootstrap path. In Chimera, all those tools are neatly wrapped in a single package that depends on very little, while providing pretty much all functionality one needs to get things done. This means we are not only replacing the GNU utilities, but we also have a replacement for things such as Busybox at the same time, re-using the same environment to power our initramfs and other components.

Relatedly, it also helps cbuild/cports a lot. The way cbuild works, you are building everything in a little container that dependencies are installed into. Our BSD-ported utilities also replace some core portions of util-linux, which need to be present in the build containers. The util-linux package normally depends on things such as PAM and udev. That means if we were to use GNU utilities, we’d need a separate, stripped-down build of util-linux just for the containers, because everything that’s in the build container as well as every dependency of it is a part of the bootstrap process. That would mean either having to make this stripped-down version coexist with the full version installed in target systems, or make them conflict. For example Void Linux does the latter, and it creates trouble for instance whenever something wants to run a test suite and the test suite has a dependency on some missing util-linux tool. In Chimera, there is no need for util-linux anywhere in the base container or its bootstrap path, and such templates can simply add util-linux to their checkdepends.

Some people may also say that the BSD licensing is its own benefit. We do not say that, because as far as core userland goes, the licensing is more or less meaningless for us and we could easily live with the GPL. Therefore, this is largely a technical decision for us. While the benefits may seem small to some, they are there, and they matter to the project.

However, using an alternative userland is not and never was the project’s primary selling point. The userland tools are a means to an end, and the end is creating a well-rounded, general-purpose, practical operating system that addresses various real issues that Linux distributions tend to have. The tools simply exist to help us get there eventually.

Speaking of which, why not busybox or toybox?

Because Busybox is functionally more limited than what we have, while also not providing any other real benefit. A lot of parts of its codebase are also rather sketchy, and it can be configured in a countless ways with different sets of tools, because in the end it’s a single multi-call executable.

When your goal is a tiny embedded system, using such thing may seem like a good idea. This is not the case in Chimera, so there is no point.

As far as Toybox goes, it’s pretty much the same story, except it’s even more limited, with a lot of the tools being extremely bare. The code seems to be somewhat higher quality than Busybox’s, but the other aspects make it even less of a good fit.