We’ve talked about Chimera Linux before – it’s a unique Linux distribution that combines a BSD userland with the LLVM/Clang toolchain, and musl. Its init system is dinit, and it uses apk-tools from Alpine as its package manager. None of this has anything to do with being anti-anything; the choice of BSD’s tools and userland is mostly technical in nature. Chimera Linux is available for x86-64, AArch64, RISC-V, and POWER (both little and big endian).
I am unreasonably excited for Chimera Linux, for a variety of reasons – first, I love the above set of choices they made, and second, Chimera Linux’ founder and lead developer, q66, is a well-known and respected name in this space. She not only founded Chimera Linux, but also used to maintain the POWER/PowerPC ports of Void Linux, which is the port of Void Linux I used on my POWER9 hardware. She apparently also contributed quite a bit to Enlightenment, and is currently employed by Igalia, through which she can work on Chimera.
With the description out of the way, here’s the news: Chimera Linux has officially entered beta.
Today we have updated
apk-tools
to anrc
tag. With this, the project is now entering beta phase, after around a year and a half.In general, this does not actually mean much, as the project is rolling release and updates will simply keep coming. It is more of an acknowledgement of current status, though new images will be released in the coming days.
↫ Chimera Linux’s website
Despite my excitement, I haven’t yet tried Chimera Linux myself, as I figured its pre-beta stage wasn’t meant for an idiot like me who can’t contribute anything meaningful, and I’d rather not clutter the airwaves. Now that it’s entered beta, I feel like the time is getting riper and riper for me to dive in, and perhaps write about it here. Since the goal of Chimera Linux is to be a general-purpose distribution, I think I’m right in the proper demographic of users. It helps that I’m about to set up my dual-processor POWER9 machine again, and I think I’ll be going with Chimera Linux.
As a final note, you may have noticed I consistently refer to it as “Chimera Linux”. This is very much on purpose, as there’s also something called ChimeraOS, a more standard Linux distribution aimed at gaming. To avoid confusion, I figured I’d keep the naming clear and consistent.
Don’t really like the choice of BSD userland. Its always a pain going from gnu’s tool set back to BSD. Newer options don’t exist in the BSD equivalent. I understand her technical reasoning, thats great, I just wish they had the same options as the GNU set. There close, but not close enough. And all of her reasons against gnu, have never ever affected me as an end user of them. If I had infinite time and money, I’d re do the gnu tools and address her complaints. Sure it would be a fork, but a drop in replacement in theory. I did a stripped down version of grep at one point before I knew there was a dos version.
I have never been a BSD user but I have been using Chimera. Do you have some examples of the differences in options? I am asking out of pure curiosity.
The only one I have run into myself is sed ( the ‘-i’ option in particular ).
It seems that ‘find’ has different options for regex:
GNU: find /var/log -type f -regextype posix-extended -regex “/var/log/[a-zA-Z\.]+(/[a-zA-Z\.]+)*”
BSD: find -E /var/log -type f -regex “/var/log/[a-zA-Z\.]+(/[a-zA-Z\.]+)*”
I found historical complaints about grep but, in my testing, the examples from the web seem to work the same in both userlands now.
It seems that one that used to trip people up was that ‘ls -G’ provides colour output on BSD while GNU uses ‘ls –color=auto’. However,, BSD takes the GNU option now as well so ( coming from Linux at least ), this is not an issue. One thing that I found Googling tonight is that ‘ls / -la’ works on GNU whereas BSD complains that the file ‘-la’ cannot be found. I have been a Linux user since forever and it has never occurred to me to put the flags at the end like that.
Anyway, it has not really been an issue for me so far but I am curious what the differences are.
I have been using Chimera Linux and really liking it a lot. The system has been very fast and stable for me. Pretty great for an Alpha. On the day of the beta announcement, I think the only package updates were the package manager itself.
Probably my favourite thing about Chimera Linux is that it wants to provide the advantages of Systemd without using Systemd itself. So far, dinit has provided me everything I am looking for as an end-user. I do hope Turnstile gets finished and catches on with other distros.
The only core userland tool that has caused me an issue has been ‘sed’ as the BSD and GNU versions do seem to differ. Given that the BSD ones are the “real” UNIX ones though, I have no problem with that. And I have found that the tools that I do want to use are more likely to already be there than I am used to. The default Almquist shell is great though I did install Bash to run other people’s scripts. Perhaps I am not the most prolific core utils user but it really has not been as much of a problem as I expected.
And while I love pacman and yay, the apk package manager has been growing on me as has using doas instead of sudo. The cports system is nice to work with as well and I have mostly been able to add any missing packages myself. I have created about a dozen packages so far though not all of them have been accepted back into the distro. Using KDE as a desktop, I do not find myself missing much compared to my usual daily driver ( including video processing ).
Based on everything I have read, I expected MUSL to be a much bigger problem than it has been. Pretty much everything has built easily for me and the Chimera repos already have VERY up-to-date versions of a lot of software ( even GIMP 3.0 ). Ironically, the one thing I was not able to compile was GCC. I am loving Clang but I wanted to port Microsoft dotnet and it has a bootstrap problem on new platforms. There are MUSL binaries of dotnet available but they were compiled with GCC and do not run on Chimera. So I tried to build GCC and it failed. No big deal as I did not really want GCC and I was able to simply run an Arch Distrobox to install dotnet. Honestly, installing it in Distrobox is probably a better idea anyway ( even on a Glibc based distro ). The entire AUR is available via Distrobox but I would rather run most things natively. Flatpak would work as well of course.
I would like to run Chimera Linux on my old Macbook Air but it needs out-of-tree drivers for the WiFi and webcam and Chimera does not include those yet. So, I need to figure out CKMS next I guess. I mean, I typically do not fiddle with my distros this much but Chimera has been quite logical and fun to dig into. I cannot fault the lack of drivers at this point. At least source is available. It does not impact me but the biggest obstacle for some people is going to be the inability to use proprietary NVIDIA drivers.
Serpent OS just entered Alpha. It too defaults to Clang as the system compiler and it takes an even bigger leap by defaulting to Rust based coreutils and providing a bespoke package manager. It still uses Glibc though and I think Systemd as well. So, Chimera Linux is the more innovative of the two distros in my view. Give it a shot.
I’ve used Void musl, and it was extremely disappointing how limiting musl is when you want to use any third party software. I do like the choices of the BSD parts, which I’ve used with Hyperbola, and of dinit. But the musl decision is a bad design path. Chimera should consider offering an option of glibc or musl, like Void does.
I have already commented too much on this story but I want to reply and see if I am missing something. This is my first musl based distro so please educate me if I am totally missing the mark here.
If by “third party software”, we mean software distributed as pre-compiled binaries built for a different environment, musl is not going to be the only issue. Even on glibc based distros, I use Distrobox to provide an environment that matches the expectations of the app. For example, if an application targets Red Hat Enterprise Linux, I can create an environment that matches RHEL9 bug-for-bug right down to Glibc 2.34:
distrobox create -i registry.access.redhat.com/ubi9/ubi -n redhat
I can also use Distrobox to get access to a larger universe of packages than Chimera bundles. For example, I use Distrobox to access the Arch repos and the AUR. I used that this morning to run Burpsuite on Chimera. Worked great.
If an application is available as a Flatpak, that is an option as well.
I am trying to embrace Chimera though. If I want to use something not in the Chimera repos, I am using cports to make Chimera native packages. For example, I packaged the Netflix VMAF library so that I could use ab-av1 on Chimera. So far, everything I have wanted to use has built just fine ( see 1 below ).
When source is available, I do not expect many problems ( famous last words ). With an increasing number of musl based distros, and of course the BSDs, Illumos, Haiku, and others, I hope apps will choose to be more portable. I like that Chimera may help with that.
(1) – The only thing that has not built for me is GCC. I have not spent any time to understand why. It must be possible given the number of musl based distros that use GCC as a system compiler. For GNU stuff, the problem may actually be Clang more than musl.
I just learned something really interesting about Chimera Linux that I did not realize before. Chimera replaces the default memory allocator in musl with mimalloc. It turns out that mimalloc was written by Microsoft! So, every userland memory allocation on Chimera is using Microsoft code. Microsoft wrote one of the most fundamental building blocks of the operating system. Their code is being called by every program run on the system.
Forget the BSD userland, having the main system memory allocator written by Microsoft is what really makes it a Chimera. I know I have made too many posts on this story but I thought this one was too interesting not to share.