Bit Cannon

A Month on Chimera Linux

I installed Chimera Linux on my laptop a month ago and have been using it daily since then. This post details the experience so far.

Chimera Linux on HP Aero 13 laptop

Note 07 Jul 2024: Keep in mind that this was written in July 2023 and the distro has continued to improve. So the following does accurately represent the current state of things.

What Is Chimera Linux?

Chimera Linux is a unique from-scratch Linux distribution created in 2021 by q66 that combines the Linux kernel, musl libc, FreeBSD userland, apk package manager, and dinit binary init system. The whole system is built with the LLVM toolchain. The homepage says:

It aims to be clean and usable while addressing the various shortcomings of an average Linux distribution.

It does so by liberating itself from the common baggage of most Linux-based systems and doing its own thing. Software is sourced from different places and sometimes written from scratch.

Notably this unholy combination yields a Linux system that is not GNU/Linux. From the about page:

This means Chimera is not a GNU/Linux system, as it utilizes neither GNU utilities, nor GNU libc, nor GNU toolchain. The system is bootstrappable almost entirely without any GNU components (other than make) and is capable of booting without them (however, most people will have some).

To build Chimera q66 also implemented a package build tool called cbuild and ports tree, cports. cbuild and cports are implemented in Python (using only the standard library). This allows the package building architecture to make use of the niceties of a full-featured programming language instead of shell scripts or Makefiles which are commonly used by other ports trees. Additionally cbuild builds in a sandbox that isolates the build from the host system. This avoids undiscovered dependencies and allows the system to bootstrap on a non-Chimera Linux systems.

Why?

When picking any tool or software out of the ordinary a common question I see is: Why would you subject yourself to additional hurdles, bugs etc. I think this usually comes down to personal technology values and preferences. I'm not going to get into the specifics there but Chimera feels very close the distro I would build (and started building), so it's like my ideal distro.

Update 4 Jul 2024: I expanded on this a bit more in: Why Chimera Linux.

Installation

I have been closely following Chimera's progress towards a release that is deemed stable enough for daily use. With the announcement of the alpha phase on June 11 that happened:

Simply put, having entered the alpha phase means that the project is somewhat more ready to deal with users and potential repository expansion.

In summary, the current state of the project means it’s daily-driveable and can be gradually updated without significant manual fixups, but there may still be bugs, missing documentation, and some things may still change at conceptual level.

With the official go-ahead (despite travelling at the time) I wasted no time installing it on my laptop. My laptop is not my primary computer, it's more an ancillary device that I use kinda like an iPad — if you could actually code on an iPad too. I use it most days for web-browsing, email, chat, YouTube, but also coding (in Rust mostly) or writing blog posts like this one!

I already had a spare partition to install into and while the docs are adequate I do recommend reading them in their entirety (including the non-installation sections) before starting an installation. I deviated from the standard install by eschewing Grub as bootloader and using systemd-boot, which was already installed for the Arch Linux installation that Chimera boots alongside. My boot entry (/boot/loader/entries/chimera.conf) looks like this:

title   Chimera Linux
linux   /vmlinuz-6.1.35-0-generic
initrd  /initrd.img-6.1.35-0-generic
options root=PARTUUID=5ebb7ccb-5349-414c-bf1a-7bc8fb07aefb rw

An unresolved issue with this is that unlike Arch, which uses filenames that don't include the kernel version the Chimera kernel and init RAM disk include a version. This means I have to tweak the bootloader entry whenever the kernel version changes.

The installation target was a HP Pavilion Aero 13, which I am using to write this post (from Chimera). This is a surprisingly capable computer for the price (AU$1079, approx $740 USD), mainly owing to the 8 core AMD Ryzen CPU. It's main drawback is 8Gb of non-upgradable RAM. The appeal of it for me was that it weighs only 966g. That puts it well into iPad with keyboard territory (iPad Air 461g + Logitech Cobo Touch keyboard 574g = 1035g) without the arbitrary limitations on what I'm allowed to do with the computer that come with iPadOS — it even has multiple USB-A ports!

Basic specs are:

CPU: AMD Ryzen™ 7 5800U (up to 4.4 GHz max boost clock, 8c/16t)
RAM: 8 GB DDR4-3200 MHz RAM
Storage: 1Tb NVMe
Display: 13.3" diagonal, WQXGA (2560 x 1600), IPS
Graphics: Integrated Radeon Graphics
WiFi: Realtek Wi-Fi 6

My normal desktop environment is the Awesome window manager but since that's not packaged yet (I have it working but need to clean it up) I went with the default GNOME 44 desktop.

What Works

  • HiDPI (I run the display @2x)
  • Wi-Fi
  • Audio
  • Bluetooth headphones
  • Web cam
  • Brightness and volume controls on keyboard
  • Trackpad, including multi-touch gestures

The whole system is smooth and responsive and has been totally reliable. I've had no crashes or application instability. It sleeps and wakes perfectly. Battery life seems to be about the same as I get in Arch: 4 or 5 hours depending on what I'm doing (an iPad certainly wins here).

What Doesn't Work

  • Fingerprint scanner — doesn't work in Arch either.

Experience Report

With the installation done I set about installing my usual collection of software. The package manager is apk from Alpine Linux. My server runs Alpine so I was already familiar with it.

Firefox is in the package repo and includes a sub-package that has a desktop entry with the right arguments to make it run natively on Wayland. Firefox works great, including using the webcam and mic.

I quickly missed CopyQ for clipboard history and it looked a bit challenging to port so I opted for the gnome-clipboard-history GNOME extension. None of the browser integration things would work to install the extension so I did it manually.

One thing that stumped me for a bit but isn't really Chimera specific was how to enable the Compose key in GNOME. Previously I'd done this in GNOME Tweaks but that isn't in the repos. After dealing with multiple pages of outdated info on the GNOME website I eventually discovered that you can now just set it in the Keyboard pane of the Settings app.

Compose key settings in GNOME Settings

Being proprietary apps 1Password, Obsidian, and CLion all would not run due to depending on glibc but fortunately they are all available as Flatpaks on Flathub. Installation was a simple flatpak install. Later Flatpak also saved the day when it came to Prusa Slicer, which despite being open-source depends on a specific patched development version of wxWidgets.

1Password isn't quite as integrated as usual due to the browser extension and application being separated by the Flatpak sandbox. This means that choosing Edit on an item in the browser opens 1Password on the web instead of the application. There's also no synchronisation of the lock state of the extension and application, meaning if you unlock with your password in one the other remains locked.

I manage my dotfiles with dot, which was easy enough to install with the packaged Rust toolchain (see below for notes on rustup).

On the command line zsh git, and Neovim were in the repos but other tools I commonly use were not: ripgrep, fd, tig, bat, zoxide, git-grab, fzf, zenith, and exa. exa seems unmaintained so I swapped it for lsd, which had been recently added to the repos. A glace at the open PRs showed there were ports for zoxide and bat in progress. I set about building ports for ripgrep, fd, tig, and fzf. These were all easy enough although I had to tweak both ripgrep and fd to prevent them switching the Rust global allocator to jemalloc, since the jemalloc crate fails to build on Chimera so far.

git-grab is a tool I wrote so wasn't sure it was popular enough to package right now. I settled for a simple cargo install git-grab.

zenith failed to build for uninteresting reasons. I bumped a dependency to fix that and submitted a PR. Once they publish a new release with that fix I might create a Chimera port for it.

Some other notable tooling choices in the base system:

  • Wi-Fi is managed with iwd.
  • Pipewire is the audio server.
  • doas is the privilege escalation tool.
  • dinit init system. Nothing to really say here. It's fast and has worked fine.

What's Missing

Some things that I tried to install but hit roadblocks. Not necessarily insurmountable ones, just ones I haven't taken the time to tackle yet.

Docker/Podman is not currently available but there is a work-in-progress PR for Podman. This means that I currently can't use Chimera to build new images for my server.

I didn't dig too deeply but I'm not sure if there's a story for running VMs on Chimera at the moment. Normally I use virt-manager but it's not packaged yet.

Websites using Widevine DRM (like Netflix) don't work. It's likely that a backup Flatpak browser will work around this.

I wanted to install Deno to deal with a broken dependency on my very important website: mistakes.computer. The pre-compiled binaries they publish use glibc so I tried building from source with: cargo install deno --locked. That failed because a dependency (rusty_v8) tries to avoid building V8 using a pre-compiled library that it fails to find for Chimera.

Downloading https://github.com/denoland/rusty_v8/releases/download/v0.74.2/librusty_v8_release_x86_64-chimera-linux-musl.a...
HTTP Error 404: Not Found

You can tell it to build V8 from source: V8_FROM_SOURCE=1 cargo install deno --locked but that also fails because building V8 depends on some Google specific build tool that I haven't bothered trying to build/package so far.

Rustup installs and runs. It installs a stable-x86_64-unknown-linux-musl toolchain but that is non-functional due to depending on libgcc:

$ ldd ~/.rustup/toolchains/stable-x86_64-unknown-linux-musl/bin/rustc
	/lib/ld-musl-x86_64.so.1 (0x7f3903800000)
	librustc_driver-d2bfe141fc706ea1.so => /home/wmoore/.rustup/toolchains/stable-x86_64-unknown-linux-musl/bin/../lib/librustc_driver-d2bfe141fc706ea1.so (0x7f38f9200000)
	libstd-fe6ad1580bc261a5.so => /home/wmoore/.rustup/toolchains/stable-x86_64-unknown-linux-musl/bin/../lib/libstd-fe6ad1580bc261a5.so (0x7f38f8e00000)
	libc.so => /lib/ld-musl-x86_64.so.1 (0x7f3903800000)
Error loading shared library libgcc_s.so.1: No such file or directory (needed by /home/wmoore/.rustup/toolchains/stable-x86_64-unknown-linux-musl/bin/../lib/librustc_driver-d2bfe141fc706ea1.so)
	⋮

That's not a huge issue as the latest stable Rust compiler is in the repos (although rustfmt is notably absent rustfmt was added the day I wrote this post). Also since CLion is running in a Flatpak sandbox it can't see the system Rust compiler anyway. The CLion sandbox is a glibc environment so installing rustup into it works fine.

Other Issues

It hasn't been 100% smooth sailing. Some other small issues and bugs I've ran into:

Conclusion

So far my experience has actually been better than I expected. Since I installed it I have not rebooted back into Arch. This isn't the first time I've run a desktop musl system and I was prepared to encounter incompatible software more often than I did. Flatpak really helps fill the gaps there.

As the alpha announcement suggested, I have run into the odd bug here and there but for the most part the system is remarkably polished and stable. I plan to keep using it as the primary OS on my laptop, including its Framework 13 AMD replacement that should arrive Q4 2023.

It is currently my aim to use Chimera on my desktop computer at some point in future too. That probably won't be until after the beta phase is reached though.

Comments