See the BlueBuild docs for quick setup instructions for setting up your own repository based on this template.
All images are built with a selection of common packages, flatpaks as well as some configuration.
It is a flavor of Bazzite Stable for ASUS Laptops with NVIDIA dGPU.
Bazzite Stable for either desktop or laptop gaming.
Bazzite Deck Stable for Steam Deck clone(s).
Fedora (Sericea/)Sway Atomic suitable for low resource footprint devices (e.g. netbooks).
The podman.service is enabled on Buttgenbachit.
- KeepassXC
- LibreOffice
- LibreWolf
- Signal
- SynologyDrive
- Warehouse
- Mozilla Firefox
- Discord
- OpenRGB
- AusweisApp2
- BoxBuddy
- Calibre
- Codium
- HandHeldDaemon
- LACT
- Libation
- MediaWriter
- Obsidian
- Ptyxis
- Weasis
- byobu
- htop
- kitty
- neovim
- firefox
brew install pdfgrep
Fedora packages clatd to translate flows from an IPv6-only client to IPv4 hosts via NAT46, so it can be transmitted and then translated back via NAT64 in a PLAT device, e.g. at the edge in a CPE or in an ISP network. Although clatd is functional there was no actual testing in my networks, yet.
The ZRAM Linux kernel module is capable of creating compressed ram disks. Since being block devices they can be formatted with any filesystem. Fedora uses Swap on ZRAM by default on all Spins.
There exist several packages to configure compressed ZRAM drives and some are conveniently setting one up as swap. Fedora uses the systemd-zram-generator via its zram-generator-defaults package. Starting with v1.2.1 it supports (via systemd/zram-generator#178 and systemd/zram-generator#200) the configuration of secondary compression algorithms to recompress pages on a ZRAM drive. Furthermore ZRAM requires recompression to be triggered by touching a knob in sysfs, which is out of scope of the project.
It is important to know that in ZRAM terms incompressible (e.g. with one compression algorithm but not necessarily with another) pages are called huge; Linux's Memory Management subsystem also has a concept of huge pages but means something entirely different. On top of that marking pages as idle requires memory tracking which Fedora / Bazzite currently deactivates in production kernels. The actual implementation neither relies on either huge or idle pages.
The Linux Memory Mangement subsystem has been heavily tilted in 20-zram-swap.conf for swapping out pages by setting swappiness=180 and the swap's page readahead was deactivated by setting page_cluster=0 to improve random IOPS with the cost of more page faults. Some synthetic benchmarks (see links below) measured ~2M IOPS with lz4 and ~820k IOPS with zstd1. Other values were essentially collected from the Arch Linux documentation and some blog posts I've also linked below.
Therefore ZRAM is configured in zram-generator.conf to use lz4 as a fast, low-latency compression algorithm and zstd1 as secondary one. The system will try to recompress some amount of pages once every few seconds. The exact amount of pages is scaled with the system's resources, depending on the total system memory per CPU core as a simple metric.
To actually facilitate recompression it uses a zram-recompression.timer to orchestrate the one-off execution of a zram-recompression.service. Since freed memory is likely to become fragmented over time another set of systemd units, a zram-compaction.service and a zram-compaction.timer have been created. The Service units are configured to trigger either compaction for all existing ZRAM devices or recompression for the ZRAM swap drive. Timers add a randomized delay of up to 10% to the cycle time.
On an old device with less than 4 GiB of system memory, I've observed that the ZRAM swap converged from a ratio of minimum 2:1 to ratios of roughly 3:1 during "normal" and up to 4:1 during certain excessive usage scenarios (Browser, several Electron shells e.g. for code editing + communication, E-Mail, password databases, office application(s), file synchronization application(s), screen capture, image manipulation, ...) while the system stays mostly reactive, as much as one can expect from this outdated machine. With this configuration I try to achieve an amenable user experience, but the capabilities of my system are still limited. At the very least it is more fun and less frustrating to work with than ever before. ;c)
Regularly trying to recompress some fixed number of pages may not be sufficient. One next step could be to enable memory tracking which allows to set a duration after which an unused page would be marked as idle. Recompression could thus be limited to such idle pages which were swapped out for a time, limiting the chance to recompress pages which are going to be evicted qickly. More compression algorithms and levels could be added as well to account for remaining huge (=incompressible) pages, subsequently using zstd3 or lz4hc, for instance.
- Free vs. Available Memory in Linux; August 30, 2024 by Hayden James, in Blog Linux
- Linux Performance: Almost Always Add Swap Space – Part 2: ZRAM; September 25, 2023 by Hayden James, in Blog Linux
- Tales from responsivenessland: why Linux feels slow, and how to fix that
- Tuning ZRAM in Fedora for Better Performance and Get Rid of OOM Crashes; Tue, Dec 12, 2023
- Zram can be configured more optimally by using lz4 instead of zstd1 #1570
- fix: General ZRAM Optimizations #2202
- Arch Wiki - Zram
- Fedora Wiki - Changes/Scale ZRAM to full memory size
- Fedora Wiki - Changes/Swap on ZRAM
Warning
This is an experimental feature, try at your own discretion.
To rebase an existing atomic Fedora installation to the latest build:
- First rebase to the unsigned image, to get the proper signing keys and policies installed:
rpm-ostree rebase ostree-unverified-registry:ghcr.io/blue-build/template:latest - Reboot to complete the rebase:
systemctl reboot - Then rebase to the signed image, like so:
rpm-ostree rebase ostree-image-signed:docker://ghcr.io/blue-build/template:latest - Reboot again to complete the installation
systemctl reboot
The latest tag will automatically point to the latest build. That build will still always use the Fedora version specified in recipe.yml, so you won't get accidentally updated to the next major version.
If build on Fedora Atomic, you can generate an offline ISO with the instructions available here. These ISOs cannot unfortunately be distributed on GitHub for free due to large sizes, so for public projects something else has to be used for hosting.
These images are signed with Sigstore's cosign. You can verify the signature by downloading the cosign.pub file from this repo and running the following command:
cosign verify --key cosign.pub ghcr.io/blue-build/template