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:
- The hardening overhaul fallout has been mostly addressed. There may be some crashes left, which will be dealt with over the next few weeks.
- The login stack has been switched from
util-linux
toshadow
. - Various service management fixes and cleanups.
- Overhaul of
console-setup
to uses non-XKB keymaps by default, removing base system dependency on Perl. - 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. - Util-linux has been split up, and much less of it is now
installed by default. Several new
chimerautils
tools replace its various functionality. - Base metapackages have been cleaned up.
- The system has been switched from
eudev
tosystemd-udev
. - Support for kernel
efibootmgr
hook for automatic EFISTUB boot entries. - 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.
- Overhaul of
agetty
handling, with support for config files to specify various parameters such as baud rate. - Our system toolchain now defaults to
-fno-semantic-interposition
. - 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:
- The new tools
chimera-live-bootstrap
andchimera-live-chroot
to simplify installations. - 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 respectiveagetty
service will be configured, if it exists. - 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.
- A general refresh of packaging templates, with everything being updated to its most recent version.
- 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. - Full-disk encryption is now supported, besides a variety of other initramfs improvements, which includes better support for LVM, root on ZFS and others.
- 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).
- 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.
- 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.
- 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.
- 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.
- Cbuild no longer requires
fakeroot
in the host system. - New policy packages
base-devel
andbase-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:
- 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.
- Packages will need updating to their latest version at the time of the alpha.
- Automated build system for packages still needs launching. This is experiencing delays, but we plan to have that up as soon as possible.
- 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:
- Service management. The
dinit-chimera
suite 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.conf
generator 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_SOURCE
has been added and is now in use by default for better hardening. - 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. - Full switch from linker
--hash-style=both
to--hash-style=gnu
. - The
dinit-userservd
project 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,udevd
andelogind
. 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-setup
from the Debian project. - Various other improvements in core service management.
- 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:
- 64-bit x86 EFI and BIOS computers
- AArch64 computers capable of UEFI boot
- RISC-V computers capable of UEFI boot
- Select U-Boot-based AArch64 devices
- Select U-Boot-based RISC-V devices
- POWER architecture computers (POWER8+)
- Virtual machines for all of those
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!