Roadmap for near future

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:

1. Service management. The dinit-chimera suite is currently receiving a variety of improvements.
2. 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.
3. 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.
4. Various minor tasks.

Work done since last update

A bunch of work has been done since the last update on October 12:

1. Kernel dotconfigs got a large sync and cleanup. That means they are much closer between architectures in terms of feature sets.
2. 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.
3. 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.
4. A shared extlinux.conf generator for U-Boot-based devices has been implemented, so that all devices can use a single boot menu system.
5. A Clang-compatible implementation of _FORTIFY_SOURCE has been added and is now in use by default for better hardening.
6. Speaking of hardening, the toolchain now applies -Wl,-z,relro and -Wl,-z,now by default (without explicit flags) along with -Wl,--as-needed on top of FORTIFY.
7. Full switch from linker --hash-style=both to --hash-style=gnu.
8. The dinit-userservd project got an initial release.
9. 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, udevd and elogind. The links are in dedicated packages with no hard dependencies, so they are fully optional (but still implicit for most users).
10. Console fonts and keymap are now managed using console-setup from the Debian project.
11. Various other improvements in core service management.
12. Various packaging updates and cbuild cleanups, and so on.

Future plans

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 updating.

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 ppc). 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 fakeroot, 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 apk-tools 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 cbuild. 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.

Summary

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.