A Linux distribution based on FreeBSD userland and LLVM
Matrix: #chimera-linux:matrix.org
Chimera aims to be a modern, general purpose Linux distribution.
A major goal of the system is to break free from the common conventions of most Linux distributions and do its own thing. To achieve that, it seeks alternative solutions to various aspects of the stack.
In addition to new ways of doing things in the system itself, this should result in increased diversity of software choices in the ecosystem and indirectly benefit other projects as well.
For specific questions, read our FAQ.
The distribution is in heavy development. Right now, it is a relatively complete graphical system with a multimedia stack and a web browser, capable of running Wayland and X11 environments. However, it is still source-based (meaning you have to compile everything yourself) and undergoes frequent refactoring, so it is not yet safe to use.
It is currently planned that the distribution will stabilize once apk-tools
has released a stable 3.x version and the distribution has transitioned to it.
This is in order to avoid pains with switching to a new package format.
Chimera comes with a userland that is quite different from most distributions,
even lightweight busybox-based ones such as Alpine. The core userland (what
would normally be coreutils and various related packages) is ported from
FreeBSD.
The entire system is additionally compiled with the LLVM/Clang suite. This
includes the runtime components (compiler-rt, libunwind, libc++) as
well as the linker (lld); the libc is provided by musl. The GCC
compiler is currently not present in the system at all.
ThinLTO (link-time optimization) is used system-wide for nearly all packages to gain extra size and performance benefits and further ahead prepare for enablement of more things such as CFI.
The dinit project provides the init system/service manager combo. It’s
a lightweight, dependency-based, supervising system with a good balance of
features to simplicity. Chimera uses it to also provide out of box support
for user services, which are used to manage session daemons such as the
D-Bus session bus and the PipeWire multimedia server. It is intended that
most long-running processes should be managed as services so that they are
easy to track and reliable.
The system is bootstrappable without GNU components (except their make)
and you can have an entirely GNU-free bootable system. Therefore, Chimera
should not be considered a GNU/Linux system. This is in line with the
alternatives-seeking policy; the project does not actually reject GNU
or the GPL (though permissively-licensed software is preferred when
there are two otherwise equivalent options).
Here is an example table of some major system components and their providers:
| Software | Source |
|---|---|
| Compiler and runtime stack | LLVM |
| C standard library | Musl |
binutils, elfutils |
ELF Toolchain |
| Core userland | FreeBSD, NetBSD |
| Init and logging | Dinit, syslog-ng |
| Audio stack | PipeWire |
| Desktop environment | GNOME (future) |
| Web browser | GNOME Web |
There is, of course, a lot more software in the repository, and some of the above have other alternatives available that you can choose from.
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:
elogind by default and SUID bits
are frowned upon.The system follows the rule of “there should be one obvious way to do it”. That does not mean pointlessly restricting user choice, but there should be well supported defaults for most things, and the system should be easy to grok and not take roundabout technical choices.
Chimera is explicitly not a minimalist or “suckless” system, and likewise rejects all sorts of reactionary tendencies or pointless traditionalism. It’s not a goal to work like something else or hold onto something for the sake of it; it should be its own system and have its own ways, when necessary.
All the source packaging is made from scratch, and uses a custom build system written in Python. The source package templates are also simply Python scripts. The collection is designed to be fast and strict by default, to prevent technical debt and enable introspection. Best practices are strictly enforced through a combination of a sandbox and well designed API.
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.
Chimera considers portability very important, to avoid monoculture as well
as to help catch bugs, so it supports 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.
Adding support for a new architecture is extremely easy, as long as the
LLVM stack properly supports it. One simply needs to create a cbuild
profile, bootstrap the system, and possibly modify build templates that
have architecture-specific parts in them (which is kept to a minimum).
The build system supports transparent cross-compiling, and the same profile configuration can be used for both native and cross builds. Cross-compiling can be used to bootstrap for previously unsupported architectures as well as compile regular packages for them (however, native builds are encouraged, as cross-builds do not provide the same guarantees and not everything cross-compiles cleanly).