Chimera Linux

A Linux distribution based on FreeBSD userland and LLVM

GitHub organization

IRC: #chimera-linux @ OFTC



Chimera Linux

Chimera aims to be a modern, general purpose Linux distribution.

For that, it aims to break free from the usual conventions of most other other Linux distros and do its own thing.

While at it, we aim to increase the diversity of software choices in the Linux ecosystem through a combination of new software ports and fixing existing stuff to work better with alternative userland.

For specific questions, read our FAQ.

The distribution is currently in heavy development. It can boot as well as build itself, and the software collection is growing rapidly, but version numbers are not stable right now.

Current plan is to wait for apk-tools 3.x before releasing any repos, in order to avoid transition pains to the new package format. Once that is out, the distro will stabilize.

Non-GNU, non-systemd userland

Chimera comes with an alternative userland that is quite different from even the unconventional distributions such as Alpine.

Its “coreutils” as well as other associated basic tools come from FreeBSD. Many have been ported specifically for this purpose.

The whole system is compiled with LLVM/Clang. This includes the runtime components (compiler-rt, libunwind and libc++) as well as the linker (lld). The robust musl library provides the libc. The whole system is built with link-time optimziation (Thin LTO) to enable further opportunities regarding e.g. CFI.

Here is an example table of some tools and their providers:

Software Source
C/C++ compiler LLVM
C runtime LLVM
C++ standard library LLVM
Linker LLVM
Unwinder LLVM
C standard library musl
binutils Elf Toolchain
elfutils Elf Toolchain
coreutils FreeBSD
findutils FreeBSD
diffutils FreeBSD
sed, ed FreeBSD
grep, m4 FreeBSD
make NetBSD
awk One True Awk
Shell dash, mksh
yacc byacc
tar, cpio libarchive
Readline NetBSD libedit
Init system dinit

This does not mean the other tools are banned from being packaged. Just like FreeBSD packages them in their ports, Chimera does too; it is not here to make your software choices for you. The defaults were chosen in general for technical merits (for instance, the default text editor in the full metapackage is GNU nano, as it was determined to be the highest quality choice).

However, there is a goal of being fully bootstrappable without GNU components, and it is possible to have a bootable system without them. The only GNU component required for bootstrapping right now is GNU Make, and this is a build-time-only dependency.

Consistency and clean design

Since Chimera is a new distribution, it aims to use this to get rid of some legacy compatibility that is holding things back.

Examples of this are:

The “There should be one obvious way to do it” motto is always considered and emphasis is put on the system being simple and easy to grok. However, user choice is also important. We are explicitly not a minimalist or “suckless” distro, eschewing any kind of software fundamentalism.

Easy bootstrapping and building

The source packages system was written from scratch in Python. Likewise, the source package templates themselves are Python scripts. The goal here is to make the build system fast (unlike shell-based solutions that are very common) and introspectable.

It strictly follows the idea that good things should be easy and concise, while bad things should be verbose and obvious.

All builds are containerized using Linux namespaces (thanks to Bubblewrap). This includes things such as the build having no network access after all declared sources have been fetched, and the root file system used during building being strictly read-only, and the whole build not requiring and outright rejecting root privileges.

Unit tests are run for all builds by default to help catch issues and keep track of what’s broken.

The result are binary packages in the apk format. We use apk-tools originally from Alpine Linux as the binary packaging system.

You can bootstrap the system from source on any musl-based distribution that has sufficient dependencies available. If you have a glibc system, there is tooling to help you bootstrap (again without root privileges) using a binary snapshot of another Linux distro.

The bootstrap process has 3 stages, i.e. it rebuilds the whole build container 3 times. During stage 0, all the components necessary to assemble the container are built inside your host system. Then the container is created and used to rebuild all these components once again (stage 1). This is repeated once more (stage 2) to get a clean environment that can be used for any further builds.

Once bootstrapped, you can build packages for Chimera on a completely foreign system without any further problems thanks to the container.

The build system has support for transparent cross-compiling for both bootstrap and non-bootstrap packages. This can be used to bring Chimera to new architectures as well as say, cross-compile custom packages for slow hardware of another architecture.


Chimera currently targets a variety of CPU architectures, including aarch64, ppc64le and x86_64 for the highest support tier, riscv64 for second tier and big-endian ppc64 for third tier.

As long as LLVM fully supports the target, it is very easy to add support for new architectures - one simply needs to create a profile, which is a small configuration file.

Portability is an important goal of the distro - it is not here to make your hardware choices for you.