News

Latest 10 recent news (see index)

March 06, 2023

New images

As of today, a new set of images has been released. This is following the complete world rebuild that has been going on the last few days.

The new images are therefore generated from these new packages, and are the last images that are released before the alpha release.

World rebuild

The world rebuild has been successful and mostly uneventful on all architectures. There aren’t any or many updated versions, as that will happen after this.

However, it is very important that the rebuild has happened for the alpha release that will come soon after this.

Updates since last post

A lot of the work since the last update has been on cleanups and overall quality. Overall, a summary:

  1. The hardening overhaul fallout has been mostly addressed. There may be some crashes left, which will be dealt with over the next few weeks.
  2. The login stack has been switched from util-linux to shadow.
  3. Various service management fixes and cleanups.
  4. Overhaul of console-setup to uses non-XKB keymaps by default, removing base system dependency on Perl.
  5. Chimerautils has been tagged, and various new tools have been ported (e.g. locate, whereis, script, logger, cal, and others) and many others have been written from scratch.
  6. Util-linux has been split up, and much less of it is now installed by default. Several new chimerautils tools replace its various functionality.
  7. Base metapackages have been cleaned up.
  8. The system has been switched from eudev to systemd-udev.
  9. Support for kernel efibootmgr hook for automatic EFISTUB boot entries.
  10. Automatic ZFS root detection has been fixed for GRUB, and there is now a new tool to detect root for U-Boot menu and other places.
  11. Overhaul of agetty handling, with support for config files to specify various parameters such as baud rate.
  12. Our system toolchain now defaults to -fno-semantic-interposition.
  13. The apk package manager will not mess up early permissions anymore, simplifying binary bootstrapping.

This is not an exhaustive list.

New images

The new images are mostly an incremental refresh, to allow for cleaner installations that do not update thousands of packages. There have been some notable improvements too, however:

  1. The new tools chimera-live-bootstrap and chimera-live-chroot to simplify installations.
  2. Much improved detection of serial terminals, which means in a lot of cases it is not even necessary to specify a console= anymore. If the kernel is configured to output to serial in any way, the respective agetty service will be configured, if it exists.
  3. The graphical images now use networkmanager by default.

Upcoming alpha

Up next is updating our packages to their latest versions, as a lot of stuff in the repository is by now fairly out of date. Various minor improvements will be done while doing this, and issues reported with the new images will be addressed.

The alpha release should then come a few weeks from now, definitely during March.

The release will mark the next stage of the project, where adventurous people will be able to pick it up as their daily driver, and expansion of the package set can begin.

January 16, 2023

Chimera at FOSDEM 2023 and the path towards alpha

It has been a while without an update post, so perhaps it’s time to refresh things a little.

No news does not mean progress hasn’t been happening; there has been a continuous stream of commits in cports as well as other parts of the project, so I will do my best to summarize it as well as provide an updated overview of what’s going to happen.

FOSDEM 2023

FOSDEM 2023 is happening once again with an in-person format, as usual in Brussels, on the first weekend of February, which is the 4th and 5th this time. I will be giving a talk about Chimera, this time in thE BSD devroom (huge thanks to the organizers for letting me have a slot, despite this project being a Linux system).

I will give a general overview of the project, our progress since last FOSDEM, as well as what’s planned for the future, and perhaps more, in the form of a full length talk (we have a 50 minute slot). The devroom changes into the LLVM devroom right afterwards, which is fitting considering we are also using the LLVM toolchain.

Cports progress since last post

The previous post was at the beginning of November, which is two and a half months ago. Since then, there has been a lot of updates in the project. Here are the main highlights, in chronological order.

  1. A general refresh of packaging templates, with everything being updated to its most recent version.
  2. Our suite of Dinit services, dinit-chimera has received a complete overhaul. Besides being more fine-grained, it also provides a cleaned up targets system, better thought-out configuration, and better integration.
  3. Full-disk encryption is now supported, besides a variety of other initramfs improvements, which includes better support for LVM, root on ZFS and others.
  4. CKMS, our kernel module source build system that replaces DKMS, got an initial release, and no longer conflicts with binary modules (so you can have binary ZFS for some kernels while letting CKMS manage it for others without interfering).
  5. We now use a custom version of the musl libc, which uses Scudo (a part of LLVM and default in Android/Fuchsia) as the system allocator (malloc implementation). This brings significantly better performance in multithreaded scenarios.
  6. A big overhaul of kernel packaging, alongside Linux 6.1, which is the new baseline version. The new packaging brings support for kernel backups on upgrades besides other things.
  7. Cbuild hardening overhaul, with significantly expanded list of hardening types, and new defaults. Now, templates are built with UBSan integer overflow checks by default, as well as hidden visibility and CFI (Control Flow Integrity) by default. Enabling templates to properly use it is still a work in progress. There is also initial infrastructure for other hardening including Intel CET and ARM BTI (which will both need support in musl to be useful) as well as Clang SafeStack. All ELF files are now also checked for executable stack in the build system.
  8. Cbuild now supports locking, preventing race conditions when building multiple things in parallel. The sources are properly locked, as are the repositories when generating packages.
  9. Cbuild no longer requires fakeroot in the host system.
  10. New policy packages base-devel and base-devel-static. These provide a way for users to declare that they want development packages to be automatically installed alongside runtime packages. This allows users to choose whether they wish to save space not installing development files (default) or whether they want the convenience of having development files for everything (similarly to e.g. Arch Linux).

This list is not exhaustive, but includes most major things.

The Chimera handbook

The documentation for the project has undergone significant expansion, now containing detailed installation instructions including how to deal with things like disk encryption and root oN ZFS, and various configuration tasks.

The FAQ is now a part of the handbook and has been expanded as well.

Preparing for alpha

We still have plans to release an alpha as soon as possible. This will be the point where the distro is ready for early adopters. The following needs finishing:

  1. The hardening overhaul fallout. Since we have enabled the UBSan checks as well as CFI by default, this exposes all sorts of bugs in libraries and applications, turning them into crashes. Therefore we are rebuilding and testing things as necessary, trying to iron out most issues to have a stable experience before the alpha launches.
  2. Packages will need updating to their latest version at the time of the alpha.
  3. Automated build system for packages still needs launching. This is experiencing delays, but we plan to have that up as soon as possible.
  4. There will be a world rebuild before the alpha happens, on all 4 architectures that are currently supported in repositories. This is needed in order to accommodate the various cbuild updates that have happened in the meantime.

Since these are still pretty significant tasks, it will take some time to get them done. Therefore, the alpha will not come out before the FOSDEM talk. Right now, the idea is to make it coincide with one of the beta releases of FreeBSD 13.2, to get a chance to rebase the userland. That means mid February to early March most likely.

There will be a new set of ISO images before the alpha comes out, to give people a chance to test and expose various issues. Another set will then be made for the alpha release.

After the alpha

The alpha cycle is planned for 6 months to 1 year. Once it is over and the project is ready to be declared beta quality, another world rebuild will be done.

Summary

I am hoping there will be no more significant delays. Right now, it is very near, with only a small number of tasks remaining to do. Those tasks however cover a lot of ground, so they take time.

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!