Void PPC goes Chimera (and bust)

Void PPC maintainer Daniel Kolesa has announced that instead of simply phasing out big-endian support in Void in 2022, he will instead cease maintaining the PowerPC/Power ISA fork of Void Linux entirely in favour of Chimera Linux, a fusion of a Linux kernel, musl libc and FreeBSD userland built with LLVM. There may even be a return of support for big-endian, at least for 64-bit Power (32-bit Power to be considered), as well as Chimera's core support for ppc64le, aarch64 and x86_64 (with 64-bit RISC-V coming).

As with the announcement for big-endian, if you like Void PPC and want to maintain it yourself, you can — provided you bring your own build and distribution infrastructure. Otherwise, Void PPC maintenance will end in January 2023. You can try Chimera Linux in the meantime and see how it works for you.


  1. Well, poop. And I'd only just gotten to the point that I felt sorta handy with Void. Chimera feels a little more esoteric than I need for a machine built to be predictable... maybe it's time for me to take up AlmaLinux.

    I hope FireFox is still rewarding and not a source of frustration.

    1. quite the opposite, it's built to be more robust and predictable (better quality control, far more powerful and reasonable service management, stricter build system with higher quality packaging, unit tests are actually run, package manager that's not a fragile ad-hoc mess, etc.)

    2. If anyone knows Void's limitations and the strengths of its successor, it's gonna be you. Thanks for addressing my misgivings so well. I'll take Chimera for a spin in November, probably in a dual-boot with Alma only because I've been putting off learning Red Hat for a decade and it's probably time for me to fix that.

    3. to be quite honest one of the main reasons i'm stopping the project is my overall unhappiness with the technical state of things

      1) i don't like how rudimentary runit is, and i want to have a service management system that can compete with systemd in terms of useful functionality but without the bad design (so it absolutely needs to be dependency-based, support oneshot services, i want it to manage user services, i want it to handle dbus-activated daemons, and generally all long-running daemons should be managed as services)
      2) i'm not super happy with xbps-src, being a pile of shell code that is slow and impossible to reason about, with only a very basic sandbox, and full of helper magic while still being clunky despite of that (cbuild is designed to remedy all of these things)
      3) xbps is fragile and lacks a real solver and support for basic things such as triggers (emulating them with hooks, making a lot of things impossible or slow), its handling of virtual packages is sketchy and its handling of shlibs is poorly thought out (shlibs are not treated as dependency links, which means xbps-src has to resolve all shlibs to actual names at build time which comes with an array of drawbacks)
      4) arm and aarch64 packages are cross-compiled, which means a lot of unnecessary jank in lots of different places
      4) all that + other things + that void-ppc has had to live outside the official build infrastructure for all this time means a lot of maintenance burden that i'm effectively eliminating (which in turn lets me support more platforms with less effort and so on)

  2. Chimera looks interesting will have to check it out.

    I've never been entirely satisfied with Void's init approach. On Alpine I've had good experiences with replacing OpenRC with s6-linux-init and s6-rc.


Post a Comment

Comments are subject to moderation. Be nice.