News

Latest 10 recent news (see index)


November 03, 2022

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.


October 12, 2022

New images available

New images have been released today.

We now support a fairly wide variety of hardware:

When provided with an external kernel and/or bootloader, Chimera can be made to work even on other devices of supported architectures.

Specific non-UEFI AArch64 devices that are now supported are the Pinebook Pro, MNT Reform 2 and Raspberry Pi 3/4/400, in addition to virtualized qemu systems.

RISC-V has explicit support for the HiFive Unmatched in addition to virtualized qemu systems (plain or OpenSBI).

The list of devices is subject to further expansion over time.


August 27, 2022

Binary repositories and future plans

As of today, Chimera now has binary package repositories for the ppc64le and x86_64 architectures, as well as fresh ISO images.

Every package has been updated to latest version. That means the system comes with Linux kernel 5.19, latest version of GNOME 42, WebKitGTK 2.36.x, Firefox ESR 102, and other software.

This does not mean that the distribution is ready to be daily driven. These are still experimental, and subject to arbitrary changes and rebuilds. The repositories are currently managed manually. In the coming months, automated infrastructure as well as CI will be launched.

Within the next couple weeks you can also expect the aarch64 architecture to be added to the repositories (alongside generic UEFI ISOs and Raspberry Pi 3/4 images).

The main repository is automatically installed in any Chimera system. To add the contrib repository, add chimera-repo-contrib. To get debug packages, you can add chimera-repo-main-debug or chimera-repo-contrib-debug.

Packages outside of main and contrib are not built.

This also means that the new ISOs do not contain any tooling necessary to bootstrap the system, as you can easily install that yourself.

Additionally, repos, images as well as auxiliary files such as bootstrap tarballs for language toolchains can now be found on a stable URL, which is https://repo.chimera-linux.org.

Cports and bootstrapping

Most importantly this means you no longer have to bootstrap the system from source. The binary repos have been integrated into cports which means that binary-bootstrap now works out of box, and you can build any package you want without having to bring up the whole system from scratch.

Future plans

The immediate goal is to launch the aarch64 repos and images.

The primary near-term goal is to reach the alpha milestone. That is available on GitHub Issues.

The milestone is subject to expansion, with current completion ETA being somewhere around November. Once the project has reached alpha phase, it will be ready for some careful daily driving and additional packaging.

From there, it is expected that things will stabilize more, so that they can eventually be declared safe for general use.

Alongside that, there are also plans to launch packages and images for the RISC-V architecture, once the build hardware issue is solved.


May 19, 2022

Hello world!

This is the beginning of the new project website, powered by Jekyll and GitHub Pages. Nothing much else to put here for now.

Don’t forget to join us on IRC/Matrix and other channels!