It is November, and so far without a release. While progress is happening and there is pretty much constant flow of improvements, the idea was to get something out faster, and that has unfortunately not happened yet.
So instead here is a rough plan for the near future, with an alpha release at the end (hopefully).
Current work in progress
But first, about the progress. The packaging work is not quite finished yet, and there are several things being worked on at the same time:
- Service management. The
dinit-chimerasuite is currently receiving a variety of improvements.
- Userland hardening. The idea is to enable CFI (Control Flow Integrity) in some form on supported platforms, limited UBSan (Undefined Behavior Sanitizer) with production runtime, GWP-ASan (a limited, low overhead form of address sanitizer) and possibly other things before the distro goes stable. Use of the Scudo hardened allocator (in use in production by notably the Android and Fuchsia OSes) is being investigated for improved performance over Musl stock allocator.
- Kernel packaging. The current form is not quite there yet, and needs an implementation of kernel backups as well as packaging improvements for better flexibility. Additionally, CKMS needs polishing.
- Various minor tasks.
Work done since last update
A bunch of work has been done since the last update on October 12:
- Kernel dotconfigs got a large sync and cleanup. That means they are much closer between architectures in terms of feature sets.
- The vanilla kernel now has improved support for a large variety of AArch64 devices, primarily from PINE64. The device-specific Pinebook Pro kernel was removed, with the vanilla kernel now preferred.
- The redistributable binary firmware (
linux-firmware) packaging was carefully cleaned up and split into many individual packages. Chimera’s elaborate policy packages system allows for simple management.
- A shared
extlinux.confgenerator for U-Boot-based devices has been implemented, so that all devices can use a single boot menu system.
- A Clang-compatible implementation of
_FORTIFY_SOURCEhas been added and is now in use by default for better hardening.
- Speaking of hardening, the toolchain now applies
-Wl,-z,nowby default (without explicit flags) along with
-Wl,--as-neededon top of FORTIFY.
- Full switch from linker
dinit-userservdproject got an initial release.
- The core services (
dinit-chimera) now support system-enabled services, for both system and user. That means packaging can install implicit service links and users do not have to enable them manually. This applies to a select set of services such as the D-Bus system and session buses,
elogind. The links are in dedicated packages with no hard dependencies, so they are fully optional (but still implicit for most users).
- Console fonts and keymap are now managed using
console-setupfrom the Debian project.
- Various other improvements in core service management.
- Various packaging updates and
cbuildcleanups, and so on.
Now for the roadmap.
Right now, Chimera is not meant to be daily driven by most people. One thing is missing software, but also updates are not guaranteed to be safe and it takes a lot of knowing what one is doing to safely use the system.
This should change with the first alpha release, which is planned for the end of 2022 or beginning of 2023.
With the alpha release, new guarantees will be introduced. Notably,
package versioning will become more stable, with no more arbitrary
changes without incrementing revision numbers. That means it will
no longer be necessary to always use the
--latest flag when
Initial, rudimentary documentation will be available with the alpha release, covering things like installation, basic package management, service management and so on.
To reach the alpha release, there are several tasks left to do, tagged
with the right milestone in the
cports issue tracker.
The alpha release will not be suitable for general audience. It will be an early adopter release, for careful daily driving and testing. The amount of available software will grow during this period, and bugs will be fixed. It is expected that users will package software they need to use the system.
Sometime during this cycle, additional architecture support may be
introduced (notably for big-endian
ppc64 and maybe 32-bit
An automatic package build infrastructure should function during
this period and will be set up before the alpha phase begins.
Once the OS stabilizes further, the alpha cycle will be declared finished, and all packages will be rebuilt from scratch for every supported architecture. Users will be expected to carefully upgrade their systems (this will be announced ahead of time). The beta phase will begin, suitable for less adventurous users.
The current estimate for beta phase is sometime in 2023 (summer or fall). Another cycle will begin. This is expected to take at least until mid 2024, when the distro will be declared stable. This will come with another world rebuild, most likely.
Alpha and blockers
Unfortunately, one of the main blockers for alpha is outside of
the project’s control. It’s
apk-tools, which hasn’t had much
work done on it lately in the upstream, due to the maintainer
not having time. That means issues and pull requests also go
unaddressed, and there is nothing the project can do about it.
While currently most of the issues are minor and can be worked
around, it is blocking several features and improvements in
cbuild, such as getting rid of host requirement for
and cleanup of build dependency handling.
If the situation does not improve before the alpha release is
near, Chimera will continue to rely on a Git snapshot of
during the alpha phase. The situation is supposedly temporary,
and the idea is to keep the amount of downstream patching to
a minimum. The project would definitely prefer not having to
fork the package manager, so as long as there is nothing truly
major, the preferred strategy is to wait and see, at least until
beta is near.
In addition to packaging work scheduled for before alpha, it will
be necessary to launch automated build infrastructure. This needs
work on Chimera’s own primary server (which currently does not have
its own public IP) as well as various improvements in
The build infrastructure is absolutely necessary, as the current
manual workflow takes too much effort with the growing number
of supported architectures.
Other issues can be tracked here.
Hopefully this clears things up a little. There will be at least one new set of testable images before the alpha phase is reached. Soon there will also be initial work on the Chimera handbook, which will serve as the primary source of documentation.