wezm/wezm.net
1
0
Fork 1
mirror of https://github.com/wezm/wezm.net.git synced 2024-11-18 12:52:47 +00:00
Code Issues Projects Releases Packages Wiki Activity
wezm.net/v2/content/posts/2024/why-chimera-linux.md

4.4 KiB
Raw Blame History

+++ title = "Why Chimera Linux" date = 2024-07-04T08:48:55+10:00

[extra] updated = 2024-07-26T09:58:10+10:00 +++

I received a reply to my Tech Stack 2024 post asking: Why Chimera Linux? I wrote a response that turned out longer than anticipated and figured I may as well post it here too. I'm not trying to convince you to use Chimera with this post, just note down why it appeals to me. That's really the crux of it: there's dozens of distros out there all with different goals and values and Chimera really speaks to me, for you it might be something else.

Below is a lightly edited version of my email response.

I like Chimera Linux because it's the closest distro I've found to what I would build if I was building my own (something I've tinkered with a few times over the years).

I like that it is a comparatively small and easy to understand system without giving up quite as much as you do with Alpine Linux, which to be clear, I like as well and use on my server. The userland from FreeBSD is capable and easy to understand code wise, Dinit provides an init system with process monitoring, dependency tracking, and a service file format that doesn't require writing shell scripts like in FreeBSD and Alpine. musl is designed to be secure and uses quite straightforward implementations of libc functions while sticking closely to the POSIX standard. See the recent OpenSSH vulnerability where remote code execution was not possible on musl based systems.

I really like the cbuild system for building packages. It uses a real programming language (Python) to define packages and share library code. This makes package templates easier to write and understand over Make and shell based packaging systems. Packages are built in an isolated sandbox, preventing them depending on the host system accidentally—this is definitely an advantage over building packages on Arch. Most run-time dependencies are automatically determined so you don't have to list all those out in the package template.

apk is fast (although not as fast as Pacman when doing updates1). It has a clever way of tracking packages where the world file specifies all the packages that should be present and it uses a solver to determine what needs to be installed/removed. The neat bit is that when you apk del a package it can remove all packages that are no longer specifically requested, whereas in Arch it's easy to end up with orphaned packages that are dead weight and require manual maintenance to clean up.

Chimera is also a rolling distro (like Arch) so things stay up to date. There's a low barrier to submitting new packages and updates, you don't have to have a special "committer" or "developer" account, you can just open a pull request like any other open-source project. Packages in the repo are built automatically with a build bot server for all supported architectures, whereas I believe Arch is still working towards automated packaging. Additionally first class support for multiple CPU architectures allows me to run the same system on different devices I use such as Raspberry Pis, RISC-V single board computers, and hopefully eventually my new ARM based Snapdragon X Elite laptop.

Having written that all out I guess Chimera feels like a distro that is full-featured but also simple enough that you can poke around and understand all the parts. It's also easy to get involved with the project.

  1. Pacman downloads in parallel (5 at a time in my config), then does the actual upgrades. apk fetches one package at at time and then stages the upgrade before moving on to the next one. There's a couple of related open issues:

    ↩︎