dev@iostream.pl

Escape from the Tropics

Mon, 05 Oct 2026 15:05:00 +0200

KDE Plasma is a remarkably pleasant environment for work — and for pretty much everything else — so there is very little to complain about.

However, since I have already taken the first steps toward moving completely to FVWM3, a little consistency seems appropriate.

It is time to start replacing some of the applications from the KDE ecosystem as well.

Not all at once.

No need to panic.

First, we need a survival kit.

Minimal Version

The absolute minimum I would find difficult to live without is:

another terminal → Alacritty, because why not,
another file manager → PCManFM-Qt — I used its GTK ancestor about twenty years ago, so now the Qt version gets a chance,
Qt appearance configuration → qt6ct — without it, surprises await,
somewhat more deliberate wallpaper handling → feh,
a launcher slightly more sophisticated than dmenu → rofi,
display configuration management → autorandr and arandr.

There is one additional detail with qt6ct: Qt applications need to know that they are supposed to use it.

An FVWM session will therefore eventually need something along the lines of:

export QT_QPA_PLATFORMTHEME=qt6ct

Simply installing qt6ct does not magically make it take control of every Qt application.

Unfortunately.

The magic comes later.

Standard Version

The standard version contains everything from the minimal one, plus:

Bluetooth device management → blueman,
display brightness control → brightnessctl,
notifications → dunst,
a PolicyKit authentication agent → lxqt-policykit,
screenshots → flameshot,
NetworkManager connection management → network-manager-applet,
an audio mixer → pavucontrol,
an X11 compositor → picom,
media-player control → playerctl,
automatic removable-media mounting through UDisks → udiskie,
a volume-control applet → volumeicon,
a second terminal, for variety → qterminal,
a system tray → stalonetray.

At this point, an innocent little window manager starts looking suspiciously like a desktop environment.

But that is fine.

We still know exactly what it consists of.

Full Version

Naturally, the full version requires the standard version and all of its dependencies, and adds:

yet another terminal, just to prevent boredom → kitty,
another file manager → Thunar.

Three terminals may sound excessive.

They are not.

RPM Packages

Since Fedora is now my main operating system, there is an obvious next step:

package all of this as RPMs.

Right?

Right.

The packages do not even need to contain any programs or configuration files of their own.

What we need are metapackages — almost empty RPM packages whose main purpose is to depend on other packages.

Instead of remembering fifteen package names, I should eventually be able to type:

sudo dnf install kde-refugee-pack-standard

and be done with it.

Tools

First, install the basic RPM-building tools:

sudo dnf install rpm-build rpmdevtools rpmlint

Create the standard build tree:

rpmdev-setuptree

and generate a fresh spec template:

rpmdev-newspec my-package.spec

A typical spec template contains fields such as:

Name,
Version,
Release,
Summary,
License,
URL,
Source,
BuildRequires,
Requires.

It also contains sections such as:

%description,
%prep,
%build,
%install,
%files,
%changelog.

For a package consisting entirely of dependencies, most of these are unnecessary.

There are no sources.

There is nothing to compile.

There is not even anything to install into the filesystem.

Minimal

The kde-refugee-pack-minimal.spec file can therefore look like this:

Name: kde-refugee-pack-minimal
Version: 0.0.1
Release: 1%{?dist}
Summary: KDE refugee pack, minimal version

License: MIT
BuildArch: noarch

Requires: alacritty
Requires: qt6ct
Requires: pcmanfm-qt
Requires: feh
Requires: rofi
Requires: autorandr
Requires: arandr

%description
Mandatory metapackage for everyone who leaves KDE for fvwm3
(minimal version)

%files

%changelog
* Sat Oct 03 2026 Marcin Bielewicz <marcin.bielewicz@gmail.com>
- initial version

Important: keep the empty %files section.

The package does not contain any files, but we still want rpmbuild to produce a binary RPM.

That is its entire purpose:

to exist and require other packages.

Standard

The next level depends on the first one:

Name: kde-refugee-pack-standard
Version: 0.0.1
Release: 1%{?dist}
Summary: KDE refugee pack, standard version

License: MIT
BuildArch: noarch

Requires: kde-refugee-pack-minimal = %{version}
Requires: blueman
Requires: brightnessctl
Requires: dunst
Requires: flameshot
Requires: lxqt-policykit
Requires: network-manager-applet
Requires: pavucontrol
Requires: picom
Requires: playerctl
Requires: udiskie
Requires: volumeicon
Requires: qterminal
Requires: stalonetray

%description
Mandatory metapackage for everyone who leaves KDE for fvwm3
(standard version)

%files

%changelog
* Sat Oct 03 2026 Marcin Bielewicz <marcin.bielewicz@gmail.com>
- initial version

The important line is:

Requires: kde-refugee-pack-minimal = %{version}

which means:

I require kde-refugee-pack-minimal in the same version as this package.

Of course, this could be written explicitly:

Requires: kde-refugee-pack-minimal = 0.0.1

but %{version} saves us from having to remember to change it in the next release.

Laziness.

Once again, the driving force behind computer science.

Full

The final level:

Name: kde-refugee-pack-full
Version: 0.0.1
Release: 1%{?dist}
Summary: KDE refugee pack, full version

License: MIT
BuildArch: noarch

Requires: kde-refugee-pack-standard = %{version}
Requires: kitty
Requires: Thunar

%description
Mandatory metapackage for everyone who leaves KDE for fvwm3
(full version)

%files

%changelog
* Sat Oct 03 2026 Marcin Bielewicz <marcin.bielewicz@gmail.com>
- initial version

This gives us a dependency chain:

full
 └── standard
 └── minimal

with each level adding its own collection of tools.

Building the Packages

A binary RPM can be built with:

rpmbuild -bb package.spec

The result will normally appear under:

~/rpmbuild/RPMS/noarch/

The -bb option builds the binary package only.

If we also want an SRPM:

rpmbuild -ba package.spec

That is what I will use in CI.

If the computer is doing the work anyway, there is little reason to stop it.

Installing the Packages

A local RPM can be installed through DNF:

sudo dnf install ./package.rpm

The ./ matters: it tells DNF that this is a local file rather than a package name to search for in configured repositories.

DNF then resolves and installs the dependencies.

Which was the whole point of this exercise.

GitHub Actions

Once the spec files live in a repository, rebuilding them manually every time starts looking suspiciously like a task that could be automated.

Tasks like that are dangerous.

They tend to produce CI pipelines.

The workflow can look like this:

name: Build RPM packages

on:
 push:
 paths:
 - "specs/**"
 - ".github/workflows/rpm.yml"
 pull_request:
 paths:
 - "specs/**"
 - ".github/workflows/rpm.yml"

permissions:
 contents: read

jobs:
 build:
 name: Build ${{ matrix.package }}
 runs-on: ubuntu-latest

 strategy:
 fail-fast: false
 matrix:
 package:
 - kde-refugee-pack-minimal
 - kde-refugee-pack-standard
 - kde-refugee-pack-full

 container:
 image: fedora:44

 steps:
 - name: Install build tools
 run: |
 dnf install -y \
 findutils \
 rpm-build \
 rpmdevtools \
 rpmlint

 - name: Checkout repository
 uses: actions/checkout@v7

 - name: Prepare rpmbuild tree
 run: rpmdev-setuptree

 - name: Copy spec
 run: |
 cp specs/${{ matrix.package }}.spec ~/rpmbuild/SPECS/

 - name: Lint spec
 run: |
 rpmlint specs/${{ matrix.package }}.spec

 - name: Build RPM
 run: |
 rpmbuild -ba ~/rpmbuild/SPECS/${{ matrix.package }}.spec

 - name: Show result
 run: |
 find ~/rpmbuild/RPMS ~/rpmbuild/SRPMS -type f -print

 - name: Collect build artifacts
 run: |
 mkdir -p artifacts
 cp ~/rpmbuild/RPMS/noarch/*.rpm artifacts/
 cp ~/rpmbuild/SRPMS/*.src.rpm artifacts/

 - name: Upload build bundle
 uses: actions/upload-artifact@v7
 with:
 name: bundle-${{ matrix.package }}
 path: artifacts/

 - name: Upload binary RPM directly
 uses: actions/upload-artifact@v7
 with:
 path: ~/rpmbuild/RPMS/noarch/${{ matrix.package }}-*.noarch.rpm
 archive: false

 install-test:
 name: Test package installation
 needs: build
 runs-on: ubuntu-latest

 container:
 image: fedora:44

 steps:
 - name: Download kde-refugee-pack-minimal
 uses: actions/download-artifact@v8
 with:
 name: bundle-kde-refugee-pack-minimal
 path: rpms/

 - name: Download kde-refugee-pack-standard
 uses: actions/download-artifact@v8
 with:
 name: bundle-kde-refugee-pack-standard
 path: rpms/

 - name: Download kde-refugee-pack-full
 uses: actions/download-artifact@v8
 with:
 name: bundle-kde-refugee-pack-full
 path: rpms/

 - name: Install refugee pack
 run: |
 dnf install -y \
 rpms/kde-refugee-pack-minimal-*.noarch.rpm \
 rpms/kde-refugee-pack-standard-*.noarch.rpm \
 rpms/kde-refugee-pack-full-*.noarch.rpm

At first glance, this line may look odd:

runs-on: ubuntu-latest

We are building Fedora packages, after all.

A few lines later, however:

container:
 image: fedora:44

GitHub provides the runner, while the job itself executes in a Fedora 44 environment.

There is no need for a separate Fedora runner.

The matrix:

matrix:
 package:
 - kde-refugee-pack-minimal
 - kde-refugee-pack-standard
 - kde-refugee-pack-full

creates three independent builds.

Each spec file is checked with rpmlint, built, and stored as an artifact.

And this is where things become pleasantly convenient.

A normal artifact upload creates an archive containing the RPM and SRPM.

But actions/upload-artifact@v7 also supports:

archive: false

for a single file.

So every binary RPM is additionally available directly as an .rpm file.

No ZIP extraction required.

Like civilized people.

The second job downloads all three build bundles and tries to install the packages on a fresh Fedora environment.

The workflow therefore verifies more than:

the RPM builds.

It also verifies:

DNF can resolve the dependency chain and install all three levels.

And because the workflow itself lives at:

.github/workflows/rpm.yml

while the path filter contains:

paths:
 - "specs/**"
 - ".github/workflows/rpm.yml"

changing the workflow itself triggers another run.

The pipeline therefore tests, among other things, itself.

Summary

A small joke of a task somehow grew into:

a list of programs I will actually use,
three levels of a KDE survival kit,
three RPM metapackages,
automated linting,
automated builds,
an installation test,
artifacts available both as bundles and directly as RPM files,
and a GitHub repository: specfiles.

All because I did not want to type a dozen package names by hand.

It was laziness, Your Honor.

Customize Me

Wed, 30 Sep 2026 16:20:00 +0200

The King of Editors works remarkably well with its default settings.

The interface is well thought out, the functionality is all there, and most things are roughly where they ought to be.

Nothing left to do but use it.

And use it.

And then use it some more.

Emacs, however, also tries to be universal enough to accommodate almost any personal preference, just like other editors.

The difference is that while most applications moved two or three steps beyond the traditional preferences dialog containing five checkboxes and a dropdown menu, Emacs ran about five kilometers farther.

And it is still accelerating.

At First Glance

Exploring a standard Emacs frame reveals an Options entry in the main menu.

Open it and you will find a perfectly sensible collection of commonly used settings.

You can change them.

You can save them.

Restart Emacs and, surprisingly enough, they are still there.

Simple?

Simple.

Anyone who has been paying attention during the previous episodes about the Best of All Editors should already suspect that this is far too straightforward for Emacs.

Somewhere, the real mechanism must be waiting.

Something that makes you feel alive again.

Customize

That secret weapon is Customize — Emacs’s universal interface for changing everything its developers explicitly marked as customizable.

Which is a very, very large portion of Emacs.

Observation based on extensive personal research: eleven out of ten users claim that absolutely everything can be configured, while approximately 107 percent of programmers insist that it is merely almost everything.

What is a setting, after all?

In greatly simplified terms, it is a named value.

So if literally everything could be configured, a hypothetical preferences dialog containing every possible option would need to be…

[several tedious calculations follow]

…well, I am not sure there are enough 4K monitors in my city.

More seriously, Customize approaches configuration differently.

Related settings are grouped together.

Groups contain subgroups.

Those may contain more subgroups.

The result is an enormous hierarchy that can look slightly intimidating at first, but quickly becomes logical and surprisingly easy to navigate.

Run:

M-x customize

and Emacs creates a special buffer containing the top-level customization groups.

Its title?

Customization of the One True Editor.

Excellent.

I need to remember that.

Among other things, the buffer contains:

a search field,
a Revert… button,
an Apply button,
an Apply and Save button,
the group’s title and description,
a State button,
subgroups with descriptions.

Group names are links.

They can be activated with the mouse, or by moving point onto them and pressing RET.

Naturally, the search field works.

And with this many settings, it rapidly becomes one of the most important parts of the entire interface.

There is one useful caveat: Customize searches settings belonging to features that have already been loaded into the current Emacs session.

Revert

The Revert… button opens a menu of reset operations.

The most important ones are:

Undo Edits in Customization Buffer — discard edits made in this buffer that have not yet been applied,
Revert This Session’s Customizations — restore values from before changes made during this session,
Erase Customizations — remove saved customizations and return to standard values.

That last one becomes particularly useful after an adventurous experiment.

Which means sooner or later.

Apply and Apply and Save

Apply makes all edited values in the current Customize buffer effective for the current Emacs session.

Exit Emacs and they are gone.

Apply and Save does the same thing, but also stores the settings for future sessions.

Under the hood, Emacs writes Lisp code representing those settings — normally into your initialization file.

You can also direct Customize output into a separate custom-file, which becomes increasingly attractive as the configuration grows.

We will return to that later.

State

Individual options and groups also have their own State buttons.

These let you operate on a single setting rather than everything currently shown in the buffer.

Depending on its current state, the menu can contain operations such as:

Set for Current Session,
Save for Future Sessions,
Undo Edits,
Revert This Session’s Customizations,
Erase Customization.

So one setting can be tested temporarily, another can be saved permanently, and everything else can remain untouched.

Going Deeper

Let us open an actual group.

For example:

Environment → Dnd

What DND does is not important just yet.

The point is to see several different kinds of settings.

Below the search field, standard buttons, group title, and description, the actual options begin.

Some are collapsed and can be expanded with the triangle button.

For example:

Dnd Direct Save Remote Files — a Choice,
Dnd Indicate Insertion Point — a Boolean value,
Dnd Open Remote File Function — a function,
Dnd Protocol Alist — a list.

And this is where it becomes clear why Customize is not simply another preferences window.

Choice

For a Choice value, the Value Menu button displays the permitted alternatives.

You do not type arbitrary text.

You select one of the values anticipated by the author of the option.

Boolean

A Boolean setting provides a simple switch:

off (nil)

or:

on (non-nil)

The traditional yes-or-no question, translated into Emacs.

Function

An option whose value is a function lets you specify the name of the function that should be used.

And here, for the first time, the shadow of Lisp appears.

Still far away.

But watching.

List

Lists can be extended, shortened, and edited.

Buttons such as:

INS
DEL

allow elements to be inserted or removed.

In the case of Dnd Protocol Alist, the value is specifically a list of pairs — an association list, or alist.

We will return to that word as well.

The important part is that Customize knows the type of each option.

It does not simply throw one enormous text box at the user.

It knows whether a value is Boolean, numeric, textual, a function, a choice among alternatives, or a more complex structure.

Then it builds an appropriate editing widget.

Now things are beginning to feel properly Emacs-like.

The Shorter Route

Walking through the hierarchy is excellent when learning what Emacs can do.

It is less attractive when you already know what you want.

If you know the name of the relevant item, you can jump directly to it:

M-x customize-option
M-x customize-face
M-x customize-group

There is also:

M-x customize-apropos

which searches for matching settings and groups.

After a while, these commands tend to become much more common than opening M-x customize from the very top.

Themes

Emacs has also provided a theme system for quite some time.

To browse available themes, use:

M-x customize-themes

Note the plural: customize-themes.

A buffer containing available themes appears.

Choose one, enable it, and see what happens.

An Emacs Custom theme can affect not only colors but also option values.

Technically, a theme is simply an Emacs Lisp file containing the relevant settings.

You can even create your own:

M-x customize-create-theme

But that is a story for another day.

Faces

Another particularly entertaining area to experiment with is faces.

The simplest way to think of them is as named styles used to display text.

A face can define attributes such as:

font family,
size,
weight,
slant,
foreground color,
background color,
underline.

You can enter the Faces group through the main Customize buffer, or jump directly to a specific one with:

M-x customize-face

and choose the face you want to modify:

The basic face is:

default

It provides the default appearance of displayed text, and its background color also determines the frame background.

That is usually a sensible place to begin.

But this is Emacs.

There is no requirement to begin sensibly.

Everyone is master of their own session.

And later the blacksmith of their own fate, which may become unpleasant when 2 is entered as the font size instead of 120.

What Next?

That is probably enough for a first encounter with configuration.

We now know that:

Emacs has an interactive configuration interface,
settings are arranged hierarchically,
values have types,
changes can be applied temporarily or saved,
individual options, groups, and faces can be opened directly,
Customize also handles themes.

The next step is to look under the hood.

Where exactly are these settings stored?

What lands in init.el?

What is custom-file?

And why does manual Emacs configuration sooner or later lead to the standard question:

Which language would you choose for configuration, and why is it Lisp?

That is enough for today.

Nice?

Nice.

Easy?

Easy.

Future episodes will be even nicer.

Easier?

Well…

A Window Manager Unlike Any Other

Mon, 28 Sep 2026 19:10:00 +0200

Thirty-three years is a very long time in software.

Trends change.

Architectures come and go.

Companies collapse, occasionally taking genuinely excellent projects to the grave with them.

It is long enough that, back in 1993, I was considering moving from a Commodore 64 to an Amiga 500 — which never actually happened — while in 2026 I find myself interested in software from that same era which somehow still exists.

And not merely exists.

Some of it is doing remarkably well.

In 1993, engineer Robert Nation needed a lightweight window manager for a 33 MHz 486 laptop with just 4 MB of RAM.

At the same time, his work involved analyzing enormous spectrograms, and he needed a virtual desktop larger than a single physical screen.

TWM worked, but it consumed more memory than he liked and did not provide everything he needed.

So he did what any reasonable programmer dissatisfied with an existing tool would do:

he started taking it apart.

The result was FVWM.

Its first public version was bundled with an rxvt release on June 1, 1993. Soon afterward FVWM became an independent project, and it is still with us today.

Despite more than three decades of development, it has retained much of its original character:

it is lightweight, modular, extraordinarily configurable, and assumes that the user may actually know how their own desktop should behave.

F? VWM

So what does the name mean?

Today the official project calls it:

F? Virtual Window Manager

where F? can be expanded into almost anything beginning with the letter F.

Preferably something printable.

Originally, however, the F had a very specific meaning:

Feeble Virtual Window Manager.

Robert Nation himself confirmed this, explaining that the earliest versions offered very few user-selectable features, so feeble was a fairly accurate description.

The software eventually stopped being feeble in any meaningful sense, while the interpretation of the letter F drifted into folklore.

The modern project page suggests words such as:

fantastic, fabulous, famous, flexible…

and wisely leaves the rest to the user’s imagination.

What Exactly Is a Window Manager?

That is a reasonable question.

What sort of software is this?

And why should anyone care?

A window manager manages application windows within a graphical session.

In the X11 world it is responsible for things such as:

window placement,
size,
stacking order,
focus,
decorations,
minimization,
maximization,
switching between windows.

An application creates a window.

The window manager decides what happens to it next.

And that is all?

More or less.

Which is exactly what makes the idea interesting.

GNOME, KDE Plasma, Xfce, and LXQt are complete desktop environments.

They are collections of cooperating components that usually provide things such as:

panels,
menus,
session management,
display configuration,
settings tools,
notifications,
desktop icons,
wallpapers,
device integration,
often an entire set of applications.

A window manager is only one part of that puzzle.

In the old days, an X11 desktop was often assembled gradually.

Need a panel?

Install one.

Need a menu?

Add one.

Want a wallpaper?

Run a wallpaper setter.

Need desktop icons, a notification area, media controls, or animated penguins wandering around the screen?

No problem.

xpenguins is waiting.

Today, we are much more likely to install an entire desktop environment and accept whatever came from the factory.

And the factory keeps providing more.

Increasingly tightly integrated.

Eleven out of ten users never even change the wallpaper.

What Does FVWM Provide?

FVWM is a classic window manager in exactly that older tradition.

Its primary concern is windows and how they behave.

Want a panel?

You can have one.

Menus?

Of course.

A pager?

Certainly.

A window list?

Also available.

But FVWM does not assume that its developers know better than you how all of those things should look or behave.

The default configuration provides enough to get started and then seems to say:

Run me.
Use me.
Decide what is missing.
Then configure it yourself.

That is what its extensive configuration system is for.

The official project describes FVWM3 as a lightweight floating window manager for X11 that can be configured as anything from a small minimal setup to something resembling a complete desktop environment.

Installation

I assume you already have some graphical environment installed.

Modern Linux distributions usually come with KDE, GNOME, Xfce, LXQt, or something similar.

You therefore probably also have a display manager.

In my case, this is Fedora with KDE Plasma and SDDM.

Installation is straightforward:

sudo dnf install fvwm3 dmenu

The first package contains FVWM3 itself.

The second provides dmenu, which the default FVWM configuration uses as a simple application launcher.

It is worth checking that the package installed an X session definition:

rpm -ql fvwm3 | grep xsessions

On my system:

/usr/share/xsessions/fvwm3.desktop

Excellent.

Log out.

Select FVWM3 on the login screen.

Enter the password.

Press Enter.

And…

Hello Darkness

…enjoy the majestic sight of absolutely nothing.

The session did not start.

The reason turned out to be simple:

FVWM3 is an X11 window manager, while my Fedora installation only had Wayland available.

FVWM3 is still primarily built around Xlib and the X Window System.

So Xorg needs to be installed:

sudo dnf install xorg-x11-server-Xorg

Fedora 44 still ships Xorg separately for X11 sessions and software that depends on it.

Ah.

Much better.

Configuring X11

The biggest surprise after all these years is that X11 no longer needs to be configured.

It simply starts.

And works.

There is no need to:

select graphics drivers manually,
describe the monitor,
write Modeline entries,
configure the mouse,
configure the keyboard,
specify font directories.

I remember a time when starting X11 and getting a black screen instead of smoke already counted as progress.

Today it simply works.

Thank you, 2026.

First Start

The default FVWM3 session looks like this:

What exactly are we looking at?

On the right is a panel constructed with the FvwmButtons module.

It contains:

the FVWM logo — still maintaining the cat theme,
desktop buttons 0–3,
a pager,
an area for open windows managed by FvwmIconMan,
a clock and date display.

This is essentially what the current upstream default configuration defines.

As applications are opened, the panel gradually fills up:

That is already quite a lot.

We can even launch something.

Press:

Alt+Space

and dmenu_run appears.

The current default FVWM configuration binds exactly that command to Alt+Space, provided dmenu is installed.

It displays executables found through $PATH.

Which means:

a lot of things.

Far too many things.

Fortunately, the list is filtered as you type.

Windows

The first application window looks something like this:

There is:

a title bar,
buttons on both sides,
a frame,
borders,
corners.

The button on the left opens the window operations menu.

The ones on the right perform more obvious jobs such as closing, maximizing, and minimizing.

Drag the title bar to move the window.

Drag an edge to resize it.

Drag a corner to resize it in two directions at once.

The technology is clearly almost ready for worldwide adoption.

Click the left mouse button on the root window and the main FVWM menu appears:

Not bad.

The important commands are already present.

Including:

Restart,
Quit.

Restart will become extremely useful in future episodes.

Trust me.

Desks and Pages

One of FVWM’s more interesting features is its enormous virtual workspace.

The default configuration provides four desks:

0 1 2 3

Each desk can itself contain multiple pages.

FVWM therefore distinguishes between two concepts:

Desk — a separate desktop.

Page — a position within the larger virtual space of that desktop.

With the normal global multi-monitor configuration, all connected displays together form the visible area of one page.

This means the virtual desktop can extend beyond the complete physical monitor arrangement.

Then you can have several such virtual spaces.

And several desks containing those.

Sounds excessive?

Give it a few days.

You will run out of room.

This becomes especially useful when many windows are open and you want to group them by purpose.

One desk for code.

One for documentation.

One for communication.

One for terminals that have been open for so long that nobody dares close them anymore.

Open a window and try dragging it beyond the current visible workspace.

Near the edge, you will feel a slight resistance.

Keep going.

The window crosses onto the neighboring page.

At that moment the physical screen stops feeling like the desktop itself.

It becomes merely a viewport onto something much larger.

Menus and Window Information

Clicking the right mouse button on the root window opens the window operations menu.

At this point no particular window has been selected.

First choose the operation.

Then choose the target window.

For example, choose:

Identify

and then:

GNU Emacs.

FvwmIdent appears:

At first it looks like a collection of obscure X11 properties.

Later, these values become extremely useful when writing configuration rules.

That is precisely what FvwmIdent is intended for: among other things, identifying a window’s name, resource, and class.

Clicking the middle mouse button on the root window displays a window list, including geometry information.

Its main purpose is to activate another window quickly.

Alt+Tab produces a simpler window list without geometry.

The default configuration binds this directly to FVWM’s WindowList.

Clicking the right mouse button on a title bar opens the current window’s operations menu:

Among the more interesting entries are:

Stick / Unstick — make the window appear across desks, or return it to normal behavior,
Shade / Unshade — collapse the window until only the title bar remains, then restore it.

And that is enough for the first encounter.

Spend a while moving windows around, switching desks, exploring pages, and generally discovering how much space FVWM is prepared to give you.

Then choose Quit from the main menu.

In the next episode, we will log in again.

But this time, into our FVWM.

Cold and Darkness (III)

Sun, 20 Sep 2026 17:15:00 +0200

The third and final episode of the saga about SBC cases and cooling.

ROCK 5T

The latest SBC to find its way into my home is the ROCK 5T — a serious contender in my Kubernetes cluster.

It is based on the Rockchip RK3588, an eight-core SoC combining:

four Cortex-A76 cores,
four Cortex-A55 cores,
a Mali-G610 GPU,
an NPU capable of up to 6 TOPS.

My unit has 16 GB of RAM and a 500 GB NVMe SSD — the latter being entirely my own indulgence.

This configuration should remain useful for years: compiling software, collecting metrics, running heavier cluster workloads, and experimenting with relatively small language models.

The ROCK 5T also provides two HDMI outputs, one HDMI input, DisplayPort over USB-C, dual 2.5 GbE, and two M.2 M-Key slots for NVMe drives.

There is also a standard 40-pin GPIO header, which suggests plenty of other possible uses.

Operating system?

Armbian, obviously.

The ROCK 5T currently has Platinum support there, placing it among the better-supported boards in Armbian’s catalogue.

But first…

…the board needs a case, proper cooling, and a little stress testing.

Power

The power supply must be purchased separately.

And here comes the first surprise: the ROCK 5T does not use ordinary USB-C power.

It accepts 9–20 V DC through a 5.5/2.5 mm barrel connector, with 12 V recommended.

Radxa recommends a supply capable of at least 36 W, which means 12 V / 3 A or more.

The USB-C port handles things such as OTG and DisplayPort, but it does not power the board.

So all those convenient USB-C power supplies already sitting on the shelf?

Not this time.

Apparently the marketing department decided that the purchasing experience would be more complete if several parts of a complete computer had to be bought separately.

CPU Cooling

The CPU fan also has to be purchased separately.

Fortunately, the official active heatsink fits perfectly and requires no improvisation.

Radxa lists active cooling among the official accessories for the board.

So at least this time it is clear what the designer intended.

The Case

The case…

Yes.

You guessed correctly.

That must be purchased separately as well.

I chose the official Radxa metal enclosure.

The product description warned that the case might not provide proper access to the HDMI-IN connector.

Naturally, this sounded disappointing.

When the package arrived, however, the HDMI-IN opening turned out to be perfectly usable.

The GPIO header, on the other hand, was not conveniently accessible.

So the documentation warns about the problem that is not there and forgets to mention the one that is.

One has to admire the consistency.

Assembly

The package contains two thermal pads roughly the size of an M.2 2280 drive.

That makes sense, because the ROCK 5T supports two 2280 NVMe SSDs.

The pad goes onto the SSD before the board is placed inside the case.

Once the case is closed, the pad makes contact with the metal enclosure, effectively turning the case itself into a large heatsink for the drive.

Simple.

Effective.

The case also includes two external Wi-Fi antennas.

The original antennas can therefore be disconnected and replaced with the external ones before the enclosure is closed.

In my case, I removed the Wi-Fi antennas entirely.

This machine has been connected exclusively through Ethernet from the beginning.

When a board provides two 2.5 GbE interfaces, it becomes surprisingly difficult to justify making a cluster node send packets through the air.

Testing

Measurements were taken exactly as in the previous two parts.

Two thermometers.

For the NVMe drive:

sudo nvme smart-log /dev/nvme0 | grep temperature

For the CPU:

armbianmonitor -m

Then the two now-familiar stress tests.

CPU and memory:

stress-ng \
 --cpu 0 \
 --vm 4 \
 --vm-bytes 60% \
 --timeout 10m \
 --metrics-brief

I/O:

fio \
 --name=nvme-test \
 --filename=/tmp/fio.test \
 --size=4G \
 --rw=readwrite \
 --bs=1M \
 --iodepth=32 \
 --direct=1 \
 --runtime=5m \
 --time_based \
 --group_reporting

As always, fio writes data to the selected file.

Here, that file is /tmp/fio.test.

Do not casually replace it with a block device unless you intend to begin writing an entirely different article immediately afterward.

Results

Component	`stress-ng`	`fio`
NVMe	39 °C	40 °C
CPU	62.8 °C	55.5 °C

Very good.

The NVMe remains cool, and the CPU stays comfortably below temperatures where thermal throttling would become a concern.

That means this machine can now be used regularly in the cluster in a way that actually reflects its computing power, memory capacity, and storage.

In my case, that means heavier CI/CD workloads, metrics, and everything smaller SBCs would accept only with a very audible sigh.

Series Conclusion

After three episodes, the conclusion is fairly simple:

cooling is not an optional accessory.

On modern high-performance SBCs, it is part of the basic system design.

Without a heatsink, fan, or properly designed enclosure, every board described in this series can reach unpleasant temperatures very quickly under sustained load.

With appropriate cooling, the picture changes completely.

Every machine tested here maintained reasonable temperatures during both CPU stress and intensive NVMe activity.

In several cases, the results were better than I expected.

So the patients survived.

They are doing well.

And they can safely be sent back to work.

If another single-board resident appears in my fortress, this supposedly final trilogy may receive an entirely unplanned fourth episode.

Because everyone always says:

this is definitely my last SBC.

Cold and Darkness (II)

Tue, 15 Sep 2026 15:20:00 +0200

In this episode, two more machines go through the usual treatment:

Raspberry Pi 500+,
Odroid M2.

They are interesting for very different reasons.

One is essentially a complete computer hidden inside a keyboard.

The other is a traditional SBC that still needs a case, cooling, and a little persuasion before it behaves properly under sustained load.

Raspberry Pi 500+

The next machine is the Raspberry Pi 500+.

I bought mine at a very good price, and it turned out to be an excellent purchase.

It comes with:

a mechanical keyboard,
16 GB of RAM,
a factory-installed 256 GB NVMe SSD.

The mechanical keyboard obviously has no effect on CPU performance or temperature.

I simply happen to be a very big fan of mechanical keyboards.

Perhaps there will be an episode about those one day.

That is a threat.

The other two features are considerably more practical.

A proper SSD is a much better place for an operating system than an SD card, and nobody has ever become ill from having too much RAM.

Except perhaps after looking at the invoice.

As mentioned earlier, though, I bought this particular machine at a substantial discount — considerably cheaper than any other bare SBC in my collection with comparable NVMe support.

The Raspberry Pi 500+ is an all-in-one design, with all the electronics enclosed inside the keyboard case.

The result looks a little like a modern, simplified Amiga 500, or one of the classic home computers from the 1980s and 1990s.

That is not accidental.

Raspberry Pi itself described the 500+ as a tribute to the home computers many of us grew up with.

What is less obvious without opening the case is how exactly the cooling has been implemented.

Questions include:

how the CPU is cooled,
where thermal pads are used,
whether additional heatsinks are present,
how the NVMe drive is cooled.

The SSD itself is also something you mostly know about from the specification rather than from direct visual inspection.

Yes, I know.

I could open the case.

Unfortunately, one of the screws appears to have made a personal decision to remain exactly where it is.

And since the machine works perfectly well, for now I am satisfied with knowing that it works perfectly well.

That is, after all, what I bought it for.

Testing

The same tests used earlier for the Orange Pi 5 Plus and the Raspberry Pi 5 in the DeskPi case work perfectly well here.

For the NVMe temperature:

sudo nvme smart-log /dev/nvme0 | grep temperature

For the Raspberry Pi itself:

vcgencmd measure_temp
vcgencmd measure_clock arm
vcgencmd get_throttled

The first command reports CPU temperature.

The second shows the current ARM clock frequency.

The third is especially useful because it reveals whether the system has experienced thermal throttling, undervoltage, or related issues.

The CPU and memory stress test:

stress-ng \
 --cpu 0 \
 --vm 4 \
 --vm-bytes 60% \
 --timeout 10m \
 --metrics-brief

And the I/O test:

fio \
 --name=nvme-test \
 --filename=/tmp/fio.test \
 --size=4G \
 --rw=readwrite \
 --bs=1M \
 --iodepth=32 \
 --direct=1 \
 --runtime=5m \
 --time_based \
 --group_reporting

As before, fio writes data to the selected file.

In this example, that file is /tmp/fio.test.

Do not spontaneously replace it with a block device unless ruining the rest of your day is part of the benchmark.

Results

Component	`stress-ng`	`fio`
NVMe	35 °C	31 °C
CPU	47.7 °C	37.8 °C

Compared with the other SBCs tested so far, these results are excellent.

Especially considering that the whole computer is enclosed inside a keyboard.

It looks very much as though the engineers behind the Raspberry Pi 500+ did an exceptionally good job.

One might even say they did their homework.

Although in Poland in 2026, that metaphor now requires a little caution.

Odroid M2

The Odroid M2 arrived with its standard case and cooling fan.

The enclosure is made of plastic, which initially made me wonder whether it would cope well with sustained heat, especially from the NVMe drive.

As it turns out, the design is quite sensible.

The top of the case contains ventilation openings directly around the fan area.

The underside has openings near the NVMe drive.

This strongly suggests that the intended cooling strategy is airflow rather than pressing the SSD against the enclosure through a thermal pad.

So I left it exactly as designed.

Assembly took perhaps three minutes.

Which is always suspicious.

Usually, if assembling an SBC takes only three minutes, it means you forgot something.

Not this time.

Hardkernel itself notes that the Odroid M2 can generate enough heat under sustained CPU and GPU load to require active cooling, which is why a fan is included in the kit. Its speed can be controlled using PWM.

Testing

The tests were identical to the previous ones.

For NVMe temperature:

sudo nvme smart-log /dev/nvme0 | grep temperature

For SoC temperature under Armbian:

armbianmonitor -m

Then:

stress-ng \
 --cpu 0 \
 --vm 4 \
 --vm-bytes 60% \
 --timeout 10m \
 --metrics-brief

and:

fio \
 --name=nvme-test \
 --filename=/tmp/fio.test \
 --size=4G \
 --rw=readwrite \
 --bs=1M \
 --iodepth=32 \
 --direct=1 \
 --runtime=5m \
 --time_based \
 --group_reporting

Results

Component	`stress-ng`	`fio`
NVMe	46 °C	50 °C
CPU	61 °C	59.2 °C

Before running the tests, I was slightly concerned that every SBC enclosed in a metal case would outperform the plastic Odroid by a wide margin.

That did not happen.

The CPU remained comfortably below troublesome temperatures, and the NVMe temperature was perfectly reasonable as well.

So plastic does not always mean:

this is going to get hot.

Sometimes it simply means:

someone designed the airflow properly.

To Be Continued

Next time:

Rock 5T.

More metal.

More NVMe.

And more reasons to run stress-ng.

Cold and Darkness

Tue, 08 Sep 2026 11:10:00 +0200

After several weeks of experimenting with various SBCs, the time finally came to provide them with two basic necessities: a proper case and proper cooling.

Neither is always as straightforward as it sounds, so I decided to document the process.

Raspberry Pi 5 and DeskPi

Assembly

For the Raspberry Pi 5, one can buy a DeskPi kit.

Which is exactly what I did.

The word kit is particularly appropriate here, because the box contains:

the case itself,
a fan,
thermal pads,
a multifunction adapter board.

That last item is by far the most interesting part.

It acts as an M.2 NVMe adapter, converts the Raspberry Pi’s micro-HDMI connectors to full-size HDMI, reroutes USB-C power, and adds a proper physical power button.

In other words, it fixes several things one might reasonably wish had been there from the beginning.

DeskPi’s own product description confirms support for M.2 NVMe drives, full-size HDMI through an adapter board, rerouted USB-C, and a power switch.

Assembly is not particularly difficult.

Except for the ribbon cable.

The first step is to throw the manual into the trash.

Unless you own a paper shredder.

In that case, use the shredder.

I envy you.

Trust me: the manual will not help much.

I had already been using an NVMe drive with my Raspberry Pi 5, so I first had to dismantle the existing setup and remove the Pimoroni NVMe Base.

A very good product, incidentally.

Just no longer useful in this particular configuration.

The USB-C and HDMI extension pieces fit without much trouble, and most of the assembly is pleasantly uneventful.

If you do not already have a fan installed, this is a good moment to add one.

Remember the thermal pads.

My Raspberry Pi 5 already had the official active cooler installed, and I decided to keep it because it works perfectly well.

The one thing that deserves disproportionate attention is the PCIe ribbon cable.

Yes, it can physically be inserted in more than one orientation.

No, only one of them is useful.

The final result should look like this:

If it does not, you may spend several enjoyable hours wondering why the Raspberry Pi can no longer see the NVMe drive.

I did.

No, the manual does not clearly explain the ribbon orientation.

Do not retrieve it from the trash.

If the Raspberry Pi already booted from NVMe before moving into the case, there is a good chance it will continue doing so without any additional changes.

That was exactly what happened in my case.

No new config.txt entries.

No bootloader changes.

Nothing.

Null.

Nada.

However, my bootloader had already been configured for NVMe booting beforehand, so a fresh setup may require additional preparation.

Testing

Once everything works and the case is properly assembled, it seems reasonable to perform a few basic stress tests.

I used:

stress-ng,
fio,
nvme-cli.

First:

sudo apt install nvme-cli fio stress-ng

The NVMe drive temperature can be read with:

sudo nvme smart-log /dev/nvme0 | grep temperature

The CPU temperature on Raspberry Pi can be checked with:

vcgencmd measure_temp

The first test applies ten minutes of CPU and memory pressure:

stress-ng \
 --cpu 0 \
 --vm 4 \
 --vm-bytes 60% \
 --timeout 10m \
 --metrics-brief

The second one produces sustained I/O activity:

fio \
 --name=nvme-test \
 --filename=/tmp/fio.test \
 --size=4G \
 --rw=readwrite \
 --bs=1M \
 --iodepth=32 \
 --direct=1 \
 --runtime=5m \
 --time_based \
 --group_reporting

A small warning here:

the fio test writes data to the selected file.

In this example that file is /tmp/fio.test, which is intentional.

Do not casually replace it with a block device unless destroying data is part of the experiment.

Results

The NVMe drive peaked at around 50°C.

The CPU reached 73.6°C.

For a Raspberry Pi 5 under sustained load inside a compact case, I consider that perfectly acceptable.

Orange Pi 5 Plus and the GeekPi Case

Assembly

The GeekPi case is a black aluminum enclosure.

It is appropriately ugly.

It is also extremely well suited to the Orange Pi 5 Plus, which is much more important.

The case accommodates an M.2 2280 drive and has a top-mounted fan that moves air across a larger portion of the board rather than cooling only the SoC.

The kit also includes thermal pads and small heatsinks.

Unlike the DeskPi manual, the product page does a reasonably good job of showing where everything belongs.

Progress.

There is, however, one complication:

the fan.

The Orange Pi 5 Plus provides a dedicated two-pin FAN connector using a small JST-style plug, while the fan included with the case terminates in two separate DuPont connectors intended for GPIO pins.

If one simply wants the fan to run continuously, it can be connected to:

+5V,
GND.

This works.

The disadvantages are equally obvious:

the fan runs all the time,
there is no temperature control,
two GPIO header pins are occupied,
even a quiet fan becomes surprisingly noticeable after several hours.

I wanted the board itself to control the fan.

Modifying the Fan Cable

The dedicated Orange Pi fan connector is intended to cooperate with software-controlled fan handling.

On current Linux setups this is typically exposed through the kernel’s pwm-fan mechanism and device-tree configuration. Orange Pi documentation and Armbian discussions show temperature-dependent fan levels rather than a simple permanently powered connection.

That sounded much better.

I bought a handful of inexpensive 1.25 mm JST pigtails and prepared to modify the cable.

Before soldering anything, I checked the connector electrically with a multimeter.

This is highly recommended.

Do not trust wire colors alone.

Do not trust random diagrams found in image search.

Do not trust yourself after midnight.

I connected a JST pigtail to the FAN header, powered on the Orange Pi, and observed the behavior while increasing CPU temperature with stress-ng.

The test confirmed that the dedicated connector was being controlled according to temperature.

With that established, the rest was simple:

cut off the DuPont connectors,
strip roughly one centimeter of insulation from the fan wires,
strip the JST pigtail wires,
slide heat-shrink tubing onto the wires before soldering,
solder the matching wires,
move the heat-shrink tubing over the joints,
gently heat it until it contracts.

The third item deserves special emphasis.

Most people remember heat-shrink tubing immediately after finishing the solder joint.

This is one of the traditional stages of electronics education.

Testing

After carefully assembling the case again, it was time for another round of tests.

First, the tools:

sudo apt install nvme-cli fio stress-ng

The NVMe temperature:

sudo nvme smart-log /dev/nvme0 | grep temperature

For the Orange Pi under Armbian, system temperature can conveniently be monitored with:

armbianmonitor -m

The output refreshes every few seconds and includes the SoC temperature.

The same stress tests can then be repeated:

stress-ng \
 --cpu 0 \
 --vm 4 \
 --vm-bytes 60% \
 --timeout 10m \
 --metrics-brief

and:

fio \
 --name=nvme-test \
 --filename=/tmp/fio.test \
 --size=4G \
 --rw=readwrite \
 --bs=1M \
 --iodepth=32 \
 --direct=1 \
 --runtime=5m \
 --time_based \
 --group_reporting

Results

The NVMe drive peaked at 44°C.

The CPU briefly reached 68.4°C.

At that point, the fan came alive.

Afterward, the temperature rarely exceeded roughly 65°C under the same workload.

That is exactly the kind of behavior I wanted: silent when cooling is unnecessary, audible only when the board actually needs help.

And, most importantly, controlled by the SBC rather than permanently wired to five volts like a tiny desk fan from 1997.

To Be Continued

Two boards down.

Several still waiting.

In the next part:

Odroid M2,
Raspberry Pi 500+.

One of them has a perfectly reasonable case.

The other has opinions.

Cutting, Bending, Soldering

Tue, 25 Aug 2026 23:00:00 +0200

Introduction

Three years ago, I bought a computer with a preinstalled operating system commonly known as Windows.

You may ask: why?

Surely it would have been possible to find a machine with an empty drive and save myself the trouble.

Well, I happened to find a computer with what was then the latest Core i5, 64 GB of RAM, a 1 TB NVMe drive, and an NVIDIA RTX 3050 at a price low enough that the correct order of operations was:

buy the computer,
ask questions later.

And Windows?

It came with the machine.

Might as well keep it. You never know when it might become useful.

After several months, however, working with this otherwise magnificent operating system started to resemble an experiment designed to determine the limits of human patience.

I wanted it gone.

Or, at the very least, I wanted its influence over my life significantly reduced.

Using Windows itself, I managed to shrink its partition and install Ubuntu, which had long been my default Linux distribution both on PCs and on many ARM64 machines.

Ubuntu received 244 GiB.

In theory, that should be plenty. With a little maintenance, that amount of space can last for a very long time.

The problem was that the rest of the drive was being wasted spectacularly.

Windows later allowed me to reclaim another 115 GiB or so, but no more.

Where was the administrator’s control over his own computer?

Where was the sacred right to partition a disk according to one’s own unreasonable plans?

This led to a bold decision:

delete the main NTFS partition, reinstall the hostile operating system into the smallest sensible amount of space, and use everything else to live dangerously.

For Fedora, which I had never had time for.

For FreeBSD, which I had never had room for.

For Arch Linux, so that I could finally approach random strangers in the street and say:

I use Arch, btw.

For Slackware, so that I could watch its installer produce a segmentation fault and reassure myself that reports of the distribution’s death had indeed been greatly exaggerated.

And so on.

That is exactly what I did.

Backup

First things first: backups.

Important files from NTFS first, then the ext4 partition as well.

Because you never know.

A question for the brave:

how often do you not make backups?

And what happens if the power disappears halfway through repartitioning the drive?

I’m seriously asking.

For a friend.

Who also does not make backups.

The obvious tool is rsync:

rsync -av --info=progress2 /source-directory/ /destination-directory/

The destination will probably be an external NTFS drive already containing other important backups.

Converting it to ext4 right now would merely create another project that nobody asked for.

Run rsync as many times as necessary.

Including the Windows user directory.

You never know when something from there might turn out to be useful.

At worst, six months later you discover several dozen gigabytes of Go, Firefox, pip, and other caches proving that civilization once existed there.

A Quick Trip Through Windows

The world has moved on since Windows XP.

You no longer need to keep an installation DVD hidden in a drawer somewhere.

Windows installation media can be downloaded from the Internet, and on machines originally sold with Windows, activation will normally happen automatically using the OEM key stored in UEFI firmware.

For peace of mind, however, you can still retrieve the key before doing anything destructive:

(Get-CimInstance -ClassName SoftwareLicensingService).OA3xOriginalProductKey

On Linux, the key stored in the ACPI MSDM table can often be displayed with:

sudo strings /sys/firmware/acpi/tables/MSDM

On my machine, that produced the correct activation key as well.

To make reinstalling Windows slightly less painful, I prepared the USB stick using Rufus.

Rufus detects Windows installation images and offers several additional installation options.

After pressing Start, I was presented with the Windows User Experience dialog.

I selected, among other things:

no requirement for a Microsoft account,
creation of a local user with a name of my choosing,
fewer telemetry and privacy questions,
disabling automatic BitLocker device encryption.

With the installer prepared, the time finally came to delete some partitions.

Using a proper operating system, naturally.

What’s on the Plate?

gparted revealed the following landscape:

Partition	Size	Purpose
`/dev/nvme0n1p1`	300 MiB	EFI System Partition
`/dev/nvme0n1p2`	128 MiB	Microsoft Reserved Partition (MSR)
`/dev/nvme0n1p3`	546.37 GiB	Windows C:
unallocated	115.86 GiB	free space
`/dev/nvme0n1p4`	1.12 GiB	Windows Recovery / WinRE
`/dev/nvme0n1p5`	244.14 GiB	existing Ubuntu
unallocated	1.05 GiB	a small gap
`/dev/nvme0n1p6`	21.07 GiB	Dell factory recovery image
`/dev/nvme0n1p7`	1.49 GiB	Dell support / diagnostics
unallocated	1.71 MiB	alignment

The plan:

Delete nvme0n1p3 and nvme0n1p4. Windows Setup can recreate what it needs. Leave p1, p2, p5, p6, and p7 alone.

Snip.

Gone.

Installing Windows

On Dell laptops, pressing F12 during boot opens the temporary boot menu, from which the Windows installer USB stick can be selected.

The installer started correctly.

There was just one tiny problem:

The only visible drive was the USB stick itself.

The solution was simple.

Back into the firmware setup using F2, then change the storage-controller mode from RAID to AHCI.

After rebooting, the NVMe drive appeared in Windows Setup.

This is where a little attention becomes important:

Do not simply keep clicking Next.

Windows is perfectly happy to consume all available space for itself.

I manually created a partition of roughly 150 GiB and installed Windows there.

Partition created.

Windows installed.

Initial Windows Configuration

The objective here was simple: prevent Windows from quietly reserving unreasonable amounts of disk space for things I did not particularly care about.

First, disable hibernation:

powercfg /h off

This also removes hiberfil.sys.

sysdm.cpl

Then:

Advanced → Performance → Settings → Advanced → Virtual Memory → Change

Automatic pagefile management can be disabled and a fixed limit selected.

In my case:

Initial size: 1024 MB
Maximum size: 4096 MB

This is not universal advice.

My machine has 64 GB of RAM. On systems with significantly less memory, leaving pagefile management to Windows may be the better option.

Advanced → Startup and Recovery → Settings → Write debugging information → None

If full crash dumps are not useful to you, there is little reason to reserve many gigabytes for them.

Then:

SystemPropertiesProtection

For C:, System Protection can either be disabled or given a small storage limit.

I kept it enabled but limited.

After major updates, the component store can also be cleaned:

DISM /Online /Cleanup-Image /AnalyzeComponentStore
DISM /Online /Cleanup-Image /StartComponentCleanup

And finally:

Settings → System → Storage → Temporary Files

Phew.

Windows had now been successfully confined to its 150-gigabyte room.

It was time to return to the actual experiment.

The Second Operating System

For the second operating system — from the normal family — I chose Fedora KDE.

With every intention of eventually making it my main system.

The fvwm3 configuration can wait for long autumn evenings, when ordinary life stops providing enough problems.

Installing Fedora

Fedora boots into a Live environment, which has several advantages.

First, a complete system and disk tools are available before installation.

Second, you can open a browser, play a movie, and enjoy a genuine sit back and relax experience.

Another company advertised that concept back in 1995.

It did not go particularly well.

Fedora’s installer was also quite enthusiastic about using all available disk space, so I politely declined and prepared the partitions myself.

I allocated 2 GiB of ext4 for /boot.

The root filesystem received roughly 215 GiB of btrfs.

It is worth keeping Fedora’s usual Btrfs subvolume layout:

root → /
home → /home

There is no need for a separate /home partition.

Both subvolumes share the same Btrfs storage pool, so free space is not artificially divided between the operating system and user files.

The installer then needed three mount points:

/boot,
/,
/boot/efi.

The last one comes with an important rule:

do not format the existing EFI System Partition.

Unless crying and gnashing of teeth happens to be part of the plan.

At this point, tea can be prepared while the installer does its work.

`UnsupportedPartitioningError`

There was, naturally, one surprise.

The installer refused to use the Btrfs filesystem I had prepared for / and stopped with UnsupportedPartitioningError.

In my particular case, manually creating the expected subvolumes solved the problem:

sudo mount /dev/nvme0n1p9 /mnt/btrfs

sudo btrfs subvolume create /mnt/btrfs/root
sudo btrfs subvolume create /mnt/btrfs/home

sudo btrfs subvolume list /mnt/btrfs

In other words:

mount the filesystem,
create root,
create home,
verify that they actually exist.

The next installation attempt completed successfully.

Fedora installed its own GRUB configuration afterward.

Fortunately, it also discovered the other operating systems and added them to the boot menu.

First Boot

After the first successful boot, I created the normal administrative user.

Its UID and GID were the usual:

1000:1000

Exactly the same as my user account under Ubuntu.

A small detail, but a very convenient one when files are shared between installations.

The root password remained unset.

Use sudo, Luke.

Mounting the NTFS Partition

Once the Windows partition was known, it could be added to /etc/fstab.

My first version used the kernel ntfs3 driver:

UUID=NTFS-PART-UUID /mnt/c ntfs3 rw,nosuid,nodev,nofail,uid=1000,gid=1000,umask=022,windows_names 0 0

Later, however, I found that ntfs-3g behaved much better in my particular setup, so that is what I ultimately kept.

Fonts

With the Windows partition mounted, its fonts can also be reused.

After all, the files are already sitting on a machine whose Windows license came with the hardware.

For manually installed system-wide fonts, a suitable location is:

sudo mkdir -p /usr/local/share/fonts/microsoft

Then:

sudo cp /mnt/c/Windows/Fonts/*.ttf /usr/local/share/fonts/microsoft/
sudo fc-cache -fv

And this is where another adventure began.

fc-cache reported no usable fonts.

fc-scan failed:

fc-scan /usr/local/share/fonts/microsoft/arial.ttf

while:

file /usr/local/share/fonts/microsoft/arial.ttf

identified the file merely as:

data

Something was clearly wrong.

After several experiments, the issue disappeared when I switched the Windows filesystem from the kernel ntfs3 driver to ntfs-3g.

I remounted it, copied the font files again, rebuilt the Fontconfig cache, and this time everything was recognized correctly.

I am not claiming that ntfs3 inherently breaks font files.

I am saying that this was the exact symptom on my machine, and changing the driver fixed it.

That distinction becomes rather important once something is published on the Internet.

I could, of course, have installed one of the packages that retrieves Microsoft’s traditional core fonts.

But why add another mechanism for downloading data when the files I actually wanted were already sitting on the neighboring partition?

Standard Software

After this unexpected NTFS lesson, normal life could finally begin.

First:

sudo dnf upgrade --refresh

Then the basic toolkit:

sudo dnf install \
 fish rsync curl wget zip unzip ansible git \
 emacs vim firefox gimp inkscape jq yq mc htop tmux \
 gcc gcc-g++ make cmake python3-pip python3-devel \
 podman buildah skopeo

At this point the computer finally begins to resemble a workstation.

Additional Software

KeePassXC

KeePassXC is available directly from the Fedora repositories:

sudo dnf install keepassxc

Years ago, applications like this required considerably more effort.

Civilization occasionally moves forward.

HeidiSQL

HeidiSQL now offers a Linux build and an RPM package.

Installing it is therefore considerably less exotic than it once would have been.

The Linux version uses Qt rather than .NET.

Opera

Opera provides its own RPM repository.

Import the signing key:

sudo rpm --import https://rpm.opera.com/rpmrepo.key

Add the repository:

sudo tee /etc/yum.repos.d/opera.repo <<'RPMREPO'
[opera]
name=Opera packages
type=rpm-md
baseurl=https://rpm.opera.com/rpm
gpgcheck=1
gpgkey=https://rpm.opera.com/rpmrepo.key
enabled=1
RPMREPO

Then install:

sudo dnf install opera-stable

Not opera-developer.

I have no idea why I briefly considered installing that one.

Visual Studio Code

Following the recommendations of the company whose extremely enthusiastic CEO once ran around a stage shouting:

Developers! Developers! Developers!

first import their signing key:

sudo rpm --import https://packages.microsoft.com/keys/microsoft.asc

Then add the repository:

printf '%s\n' \
'[code]' \
'name=Visual Studio Code' \
'baseurl=https://packages.microsoft.com/yumrepos/vscode' \
'enabled=1' \
'autorefresh=1' \
'type=rpm-md' \
'gpgcheck=1' \
'gpgkey=https://packages.microsoft.com/keys/microsoft.asc' \
| sudo tee /etc/yum.repos.d/vscode.repo >/dev/null

And install:

sudo dnf install code

From this point on, a normal:

sudo dnf upgrade

will update VS Code along with everything else.

VSCodium

The process is similar, except that the packages no longer come from the repository belonging to the company whose enthusiastic CEO…

All right.

Enough.

printf '%s\n' \
'[gitlab.com_paulcarroty_vscodium_repo]' \
'name=VSCodium' \
'baseurl=https://paulcarroty.gitlab.io/vscodium-deb-rpm-repo/rpms/' \
'enabled=1' \
'gpgcheck=1' \
'repo_gpgcheck=1' \
'gpgkey=https://gitlab.com/paulcarroty/vscodium-deb-rpm-repo/raw/master/pub.gpg' \
'metadata_expire=1h' \
| sudo tee /etc/yum.repos.d/vscodium.repo >/dev/null

sudo dnf install codium

Brave

Right.

Definitely enough about enthusiastic CEOs.

sudo dnf install dnf-plugins-core

sudo dnf config-manager addrepo \
 --from-repofile=https://brave-browser-rpm-release.s3.brave.com/brave-browser.repo

sudo dnf install brave-browser

Spotify

Spotify comes from Flatpak.

Possibly because the company is Swedish and its CEO, in turn…

No.

Never mind.

flatpak remote-add --if-not-exists flathub \
 https://dl.flathub.org/repo/flathub.flatpakrepo

flatpak install flathub com.spotify.Client

VirtualBox

First enable RPM Fusion:

sudo dnf install \
 https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-44.noarch.rpm \
 https://mirrors.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-44.noarch.rpm

Then:

sudo dnf install VirtualBox akmod-VirtualBox kernel-devel

To explicitly build the module for the currently running kernel:

sudo akmods --kernels "$(uname -r)"

Future kernel updates should normally be handled automatically by akmods.

Once a computer contains several operating systems, it seems only reasonable to make the screen used to choose between them somewhat pleasant to look at.

Fortunately, there is no need to spend an evening designing one.

There is Tela:

git clone https://github.com/vinceliuice/grub2-themes.git
cd grub2-themes
sudo ./install.sh -t tela -s 1080p

And suddenly the boot menu looks as though somebody actually expected a human being to see it.

Enough for One Day

In a single day, I managed to:

confine Windows to an amount of disk space I can tolerate,
preserve Ubuntu,
add Fedora,
learn something about Btrfs,
discover an interesting difference between ntfs3 and ntfs-3g,
recover the fonts,
install the basic workstation software,
and make GRUB look respectable.

Doctors do not recommend more excitement than this in a twenty-four-hour period.

And there is still plenty of unallocated disk space left.

FreeBSD is waiting.

So is Arch.

Slackware, one hopes, is still waiting too.

So there will be more.

Probably sooner rather than later.

The Most Popular Computer in the World

Sun, 02 Aug 2026 19:20:00 +0200

Introduction

Imagine that, several decades ago, one person made a few slightly different decisions — and today your professional life looked nothing like the one you know.

Dennis Ritchie, Niklaus Wirth, Steve Jobs, Richard Stallman, Bill Gates — although in that last case it might have worked out rather well for all of us — Guido van Rossum…

For me, that person is the author of the phrase “computers for the masses, not the classes”: Jack Tramiel. Without him, the eight-bit computer would never have found its way into quite so many homes.

It certainly would not have found its way into mine.

A Little History

Jack Tramiel was born in Łódź in 1928 as Idek Trzmiel. He rarely spoke about the early years of his life, which is hardly surprising. During the war, he was imprisoned in the Łódź Ghetto, then deported to Auschwitz-Birkenau, and later sent to the Ahlem labor camp near Hanover. He was liberated by American troops in 1945 and emigrated to the United States two years later.

He served in the US Army, where he learned to repair office equipment. He later worked for small typewriter companies until he eventually founded his own business, selling and repairing such machines under the Commodore brand.

The name was chosen deliberately. It was meant to evoke a military rank — preferably an American one — and sound suitably serious. General and Admiral were already taken, so he had to move a little farther down the chain of command.

Calculators and Computers

When typewriters could no longer compete effectively with Japanese products, the company changed direction. It moved into electronic calculators with LED displays, which at the time represented the height of modern technology.

A price war with Texas Instruments taught Tramiel one important lesson: it was better to own a semiconductor factory than to buy chips from your main competitor.

Commodore therefore acquired MOS Technology, gaining control over both the design and production of its most important components.

Designer Chuck Peddle persuaded Tramiel to enter the computer market. He argued that the calculator business had little future left and that the company needed to take the next step.

This led to machines including the Commodore PET and the VIC-20.

The Most Popular Computer in the World

The Commodore 64 was unveiled in January 1982 as the successor to the VIC-20. It reached the market — at least in the United States — in August of the same year.

Production continued until 1994, when Commodore declared bankruptcy. The machine also entered the Guinness Book of World Records as the best-selling desktop computer model in history.

Its success did not come from one exceptional component. Commodore combined excellent custom chips, its own manufacturing facilities, a generous amount of memory, and a merciless pricing strategy.

Competitors could design computers that were equally good, or perhaps even better. Commodore, however, could build its machine quickly, produce it in enormous numbers, and place it on store shelves at a price that caused sudden emergency meetings in the boardrooms of other companies.

Specifications

At the heart of the C64 was the MOS 6510, a modified version of the MOS 6502 processor.

Because MOS Technology already belonged to Commodore, it could prepare chips tailored to the needs of its parent company — provided, of course, that they could be manufactured quickly, cheaply, and in enormous quantities, in accordance with management policy.

Graphics were handled by the VIC-II, while sound came from the legendary SID. Both were also designed by MOS Technology and, at the time of release, ranked among the finest chips of their kind available in home computers.

Depending on the target market, the computer used a VIC-II variant compatible with either PAL or NTSC. It offered a palette of 16 colors, a 40 × 25-character text mode, and graphics modes reaching a resolution of 320 × 200 pixels.

The VIC-II could also display eight hardware sprites: independent graphical objects that could move across the screen without constantly redrawing the background.

Today, that may not sound particularly revolutionary.

At the time, it certainly did.

The character set used by the computer was called PETSCII. In addition to letters, digits, and punctuation marks, it included a substantial collection of graphical symbols, allowing users to create borders, simple illustrations, interface elements, and anything else a determined person could assemble from a grid of characters.

Two DE-9 ports, already familiar from Atari computers and consoles, accepted joysticks. The keyboard, joystick ports, timers, and several other input-output functions were managed by two MOS 6526 CIA chips.

The original machine came in its distinctive rounded case, commonly known as the breadbin, and occasionally as the soapbox.

Characters were printed both on the top and the front of the keys. Four physical function keys on the right-hand side, used either alone or together with Shift, provided eight possible combinations.

The joystick ports sat on the right side of the case next to the power switch. Along the back were, among other things, the cartridge port, video output, serial disk-drive connector, cassette-port connection, and user port.

And then there was the most important feature: 64 KiB of RAM, from which the computer took its name, together with 20 KiB of ROM.

In 1982, when memory was expensive, offering 64 KiB in a computer aimed at ordinary users was impressive.

Furthermore, although part of the processor’s address space was occupied by ROM and input-output hardware, RAM still existed underneath. By switching memory banks, an experienced programmer could use almost all of the available memory.

And an experienced C64 programmer used everything.

Preferably several times.

Peripherals

The three basic devices purchased by the user — or, more accurately, by the user’s parents — were a cassette drive, a joystick, and a cartridge.

The cassette drive was the cheapest and therefore the most popular mass-storage device. Programs were stored on ordinary audio cassettes. The waiting times, the peculiar noises coming from the television, and loading errors occurring just before the end soon achieved legendary status among users.

The joystick was naturally used for improving productivity, usually in the form of better grades at school.

Without a decent utility cartridge equipped with at least a fast-loading system, working with either cassette or disk storage became significantly more irritating. Popular cartridges added faster loading routines, machine-code monitors, program-freezing features, convenient file-copying tools, and a reset button.

In other words, everything that should have been built into the computer from the beginning, but could not then have been sold separately.

Commodore also offered dedicated monitors, such as the later Commodore 1084S. But who could afford a monitor when the computer could be connected to an ordinary household television without much trouble?

That is exactly what most of us did.

Another peripheral that remained beyond the reach of many users was the Commodore 1541 disk drive, followed later by the 1541-II, with its external power supply and a case designed to match the C64C.

The drive was expensive because it was almost a separate computer in its own right. It had its own MOS 6502 processor, RAM, ROM, and an operating system responsible for handling disks.

Some programmers even persuaded it to perform tasks extending far beyond simply loading files.

Does that remind you of anything?

Ah, if only cryptocurrencies or machine learning had existed back then…

A third device, known to many users only from urban legends and computer magazines, was the dot-matrix printer — for example, the MPS 801, MPS 802, or MPS 803.

Most of us probably learned about plotters, mice, modems, and memory expansions only twenty years later, after venturing much deeper into retrocomputing and the demoscene.

Reception

From the beginning, Jack Tramiel imposed an aggressive pricing policy. The competition was always supposed to remain two steps behind, never one step ahead.

Commodore did not restrict itself to specialist computer stores. The C64 appeared in ordinary shops and department stores, and repeated price cuts brought it within reach of customers who had never previously considered owning a computer.

Eventually it also crossed the Iron Curtain — and certainly reached one particular country on the Vistula River.

The gaming community and the demoscene welcomed the new machine with open arms, especially as its price continued to fall. The number of games, demos, utilities, and productivity programs created for the C64 probably surpassed everything produced for competing platforms.

The computer worked at home, at school, and in small offices. It could be used for gaming, programming, word processing, household accounting, music, drawing, modem communication, or spending several hours adjusting the cassette-head alignment.

It suited its era perfectly.

Nobody knows exactly how many units were sold. Serious estimates begin at around 12.5 million, official Commodore figures claimed 17 million, and Jack Tramiel himself mentioned numbers exceeding 20 million.

Commodore was more interested in counting the money it earned than in maintaining accurate sales statistics.

This is unfortunate, because later inventions such as the C116, C16, and Plus/4 did not share the fate of their older and far more famous sibling.

Keeping precise records of their sales would probably have been considerably easier.

Shortcomings

The computer’s greatest limitation was Commodore BASIC V2, whose origins went back to the Microsoft BASIC interpreter licensed by Commodore in the 1970s.

The language provided virtually no convenient commands for controlling graphics, sound, or sprites. To use the VIC-II or SID, users had to write values directly into hardware registers with the POKE command.

As a result, the first program written by many young users was not:

PRINT "HELLO"

but something more like:

POKE 53280,0
POKE 53281,0

You did not yet know what a hardware register or an address space was, but at least you had a black border and a black background.

Mass-storage support also fell far short of what some competing systems offered. BASIC V2 did not even include a convenient command for listing the contents of a disk.

The directory had to be loaded as though it were a program, potentially destroying the program already stored in memory.

The absence of a built-in reset button was another serious inconvenience. The user had to turn the machine off and back on again, or rely on a button provided by an external cartridge.

Frequently switching the computer off and immediately back on was not a particularly good idea. The original C64 power supply was hardly the pinnacle of engineering. It was, however, unquestionably the pinnacle of cost-cutting, and when it failed, it could take the computer’s chips with it.

The consequences of cost-cutting could also be seen on the keyboard. Reducing the cursor keys to two because the other two directions could be produced using Shift was worse than a crime.

It was a mistake.

Still, the accounts balanced, and fortunately neither VisiCalc nor Excel had arrived yet.

Variants

The best-known later variant was probably the C64C, housed in a slimmer, more angular, and considerably more modern case styled after the Commodore 128.

In terms of capabilities, the machine remained compatible with the original. During production, however, the motherboard was redesigned to reduce the number of chips and lower manufacturing costs.

In later units, the main components included:

the MOS 8500 processor,
the MOS 8580 SID sound chip,
the MOS 8565 VIC-II graphics chip in PAL machines, or the MOS 8562 in NTSC models.

The newer chips used less power and produced less heat. The SID 8580, however, sounded somewhat different from the older 6581, particularly in the behavior of its filters.

To this day, the subject can provoke a debate every bit as calm and rational as a discussion about the best text editor — Emacs, obviously.

As another cost-saving measure, Commodore stopped printing graphical symbols on the front faces of the keys. All markings were now placed on the top surface.

Another variant was the C64G. It combined the light-colored keyboard of the C64C with the classic breadbin case, also produced in light-colored plastic. Inside, it usually contained one of the newer simplified motherboards.

The result looked as though two generations of the C64 had met by accident in a parts warehouse and decided to build a computer from whatever happened to be lying around.

Entirely in keeping with Commodore tradition.

The Company Goes Bankrupt

Commodore’s management style was truly original: from one major argument to another, from the conflict between Jack Tramiel and Irving Gould to yet another loan carrying an interest rate high enough to make even a banker glance around nervously.

After one particularly serious dispute, Tramiel left the company. Not long afterward, he acquired the consumer division of the collapsing Atari and began work on the Atari ST family.

Commodore, meanwhile, possessed the Amiga technology — probably the finest multimedia platform of the second half of the 1980s — but failed to exploit its potential as effectively as it had once exploited the C64.

The company went bankrupt in 1994. This was the culmination of many problems: poor management, internal conflicts, unsuccessful products, bad marketing decisions, and a complete lack of long-term vision.

More forward-looking machines such as the Amiga 1200 and Amiga 4000 later found a new owner in the form of Escom.

That did not lead to a happy ending either.

The Commodore curse is a name that could be given to the fate of successive companies acquiring rights to the brand or technology of the former corporation. Sooner or later, the new owner runs into trouble, goes bankrupt, or sells the rights to the next brave contender.

The name survives.

The owners change.

Afterward

The community surrounding Commodore products seems not to have noticed that the company went bankrupt.

Admittedly, for obvious reasons, millions of new machines no longer appear in stores, and the global economy is no longer based on C64 sales.

The computer itself, however, remains very much alive.

Original units can still be purchased secondhand. Replacements are being developed for increasingly rare chips, together with new motherboards, FPGA-based systems, HDMI video adapters, SD-card readers, modern joysticks, and universal tools such as the Ultimate-II+.

From time to time, the market also receives a device such as THEC64, available in a full-size version with a functional keyboard, or the MEGA65 — a development of the concept behind the almost mythical and never properly released Commodore 65.

Nor do the original machine’s limitations appear to represent a particularly low ceiling for modern creators.

The number and quality of new demos, hobbyist programs, and commercial games can be astonishing. Every year, someone crosses another boundary that was supposedly impossible to cross. Someone discovers a new way to exploit the graphics chip, another memory trick, or a method of extracting a sound from the SID that the chip should theoretically be unable to produce.

The ceiling is still nowhere in sight.

So, should you have a little free time, join me in returning to this unforgettable world — to discover the computer that changed an entire generation, to enjoy its limitations, or simply to remember the years of our youth.

In future articles, we will look inside the C64, run it on modern hardware, connect a few devices, see what it can still be useful for, and try to answer the most important question of all:

can a computer from 1982 still improve our productivity?

Welcome.

Seek & Destroy

Sat, 25 Jul 2026 00:20:00 +0200

Every respectable text editor supports searching and replacing text, whether interactively or automatically. Editors from the upper shelves can also work with regular expressions.

And then there is the editor from the highest shelf — Emacs — which handles all of this brilliantly, in several different ways.

Searching

In an average text editor, searching for text requires pressing a keyboard shortcut. Alternatively, you can try to remember beneath which pile of debris on your desk the mouse is buried, move it around until the pointer appears, and click whichever button opens the appropriate dialog box.

Then you type the search term, confirm it, and the text is found. Thank you very much, and we hope to see you again during your next search.

But not in Emacs.

By default, the King of Editors provides incremental search. Pressing C-s — or invoking M-x isearch-forward — starts the search and waits for input in the minibuffer.

With every character you type, Emacs attempts to find the entire string entered so far and moves the cursor to the matching location in the text. The current match is highlighted by default. Any other occurrences visible in the buffer are highlighted as well, using a different combination of foreground and background colours.

The search string is remembered between searches. Pressing C-s again moves the cursor to the next occurrence of the current search string.

When Emacs reaches the end of the buffer, it displays an appropriate message in the minibuffer. Pressing C-s once more wraps the search around and continues from the beginning of the buffer.

Searching backwards

Incremental search also works backwards.

The C-r shortcut — or M-x isearch-backward — behaves just like forward incremental search, except that it moves in the opposite direction.

After reaching the beginning of the buffer, Emacs displays an appropriate message in the minibuffer. Pressing C-r again wraps the search around and continues from the end of the buffer.

Search results

Pressing M-s o during an incremental search — which invokes M-x isearch-occur — opens another window containing the search results: every line in which the requested phrase occurs.

The matching phrase is, naturally, highlighted so that it stands out. At the top of the window, Emacs displays a summary showing how many matches were found, on how many lines, and in which buffer.

More importantly, the results are navigable. Move to any entry and press RET, and Emacs takes you directly to the corresponding line in the original buffer.

Non-incremental search

What if someone simply wants to enter a complete search string first and then jump to its first occurrence?

A traditional, non-incremental search can be performed as follows:

C-s RET <search text> RET — or M-x search-forward — searches forwards,
C-r RET <search text> RET — or M-x search-backward — searches backwards.

In other words, it works much like incremental search, except that you press RET before entering the phrase.

Case sensitivity

By default, Emacs uses a convenient mechanism known as case folding.

As long as the search string contains only lowercase letters, Emacs ignores case and attempts to match as many occurrences as possible. As soon as you enter an uppercase letter, the search becomes case-sensitive.

During an incremental search, M-c toggles case sensitivity explicitly, so there is no need to introduce an uppercase letter merely to change the matching behaviour.

Searching with regular expressions

Emacs also provides both incremental and non-incremental searches based on regular expressions:

M-x re-search-forward searches forwards for the next piece of text matching the given regular expression. When a match is found, the cursor is moved to its end. If no match exists, Emacs displays an appropriate message in the minibuffer.
M-x re-search-backward performs the same operation in the opposite direction.
C-M-s — M-x isearch-forward-regexp — starts an incremental forward search using a regular expression.
C-M-r — M-x isearch-backward-regexp — starts an incremental backward search using a regular expression.

Searching within a region

By default, Emacs searches through the buffer. To limit a search to a particular region, one can use a small but extremely useful trick: narrowing.

Press C-x n n — or invoke M-x narrow-to-region — to narrow the buffer to the currently selected region.

This is interesting because the rest of the text temporarily disappears. All subsequent operations, including searching, are restricted to the visible part of the buffer.

Once the work is complete, press C-x n w — or invoke M-x widen — to restore the hidden text to its rightful place.

Search history

Search history is, of course, preserved.

While searching, you can use:

M-p to recall the previous search string,
M-n to move to the next search string in the history.

Other useful commands

C-y — M-x yank — inserts the most recently killed text into the search string, because why would it not?
C-w adds the remainder of the word at point to the search string.

Replacing

Once again, the King of Editors refuses to blend in with the crowd and offers something better than the competition.

M-% — M-x query-replace — interactively replaces occurrences of one string with another, starting from the position at which the command was invoked.

At every match, Emacs asks the user what should happen next:

y replaces the current match and moves to the next one,
n skips the current match and moves to the next one,
q ends the replacement operation,
! replaces the current match and every remaining match without asking any more unnecessary questions.

Other available actions can be found, for example, by invoking:

M-x describe-function RET query-replace RET

C-M-% — M-x query-replace-regexp — works in the same way, but uses regular expressions.

Emacs also tries to preserve the capitalisation style of the replaced text.

Suppose that every occurrence of windows must be replaced with linux. Emacs may perform the following replacements:

windows becomes linux,
Windows becomes Linux,
WINDOWS becomes LINUX.

The author believes that Windows should be replaced with Linux not only in this example, but also in the lives of us all.

Non-interactive replacement

Emacs also provides commands that replace all matching occurrences without asking for confirmation:

M-x replace-string replaces every occurrence of one string with another, starting from the position at which the command was invoked.
M-x replace-regexp replaces every piece of text matching the given regular expression with the specified replacement string, again starting from the current position.

Replacing within a region

If a region is active, Emacs performs replacement commands within that region by default.

There is no need to narrow or widen the buffer manually — although, naturally, Emacs will not prevent anyone from doing so.

Jenkins, Part Two: Disposable Agents and Builder Images

Sun, 12 Jul 2026 17:20:00 +0200

Once again: why all these containers?

The Kubernetes approach — short-lived, disposable things — works beautifully for Jenkins and similar CI/CD systems.

Here is a list of tasks to execute in a place described by a specification, not by a physical location. Whether that place existed five minutes ago or will disappear five minutes from now does not matter all that much.

Look at how the approach to running CI/CD jobs has evolved over the last twenty years:

run the job in a blocking shell script,
run the job directly on the Jenkins master,
run the job on a dedicated Jenkins node,
run the job on one of several dedicated Jenkins nodes.

And now?

run the job inside an ephemeral Pod, created just before the work starts and removed when the work is done.

Hard not to admire that, is it?

And there is more to admire. Each container can provide a different set of tools. Instead of installing everything manually on physical machines, you can point Jenkins at a ready-made image, built by someone else — and if you do not like that one, you can use another.

All right, that is enough admiration for now.

What do we already have?

Quite a lot:

Jenkins running under Kubernetes,
a working container registry,
a PVC for Jenkins data,
a Kubernetes cloud definition in Jenkins,
two already built images that we are about to use.

What else do we need?

Eventually, Jenkins will run jobs such as:

building Python applications,
building Go applications,
building Hugo sites.

So we need three images.

Python builder

The Python image can be built from the following Dockerfile:

FROM registry.lab.local/base-builder:0.1

USER root

RUN apt-get update && apt-get install -y --no-install-recommends \
 python3 \
 python3-pip \
 python3-venv \
 python3-build \
 && rm -rf /var/lib/apt/lists/*

RUN python3 -m pip install --break-system-packages \
 build \
 twine \
 wheel \
 setuptools \
 pytest \
 ruff

USER builder
WORKDIR /workspace

CMD ["sleep", "infinity"]

Wait a moment. Do not reach for docker build yet.

Actually, do not reach for it at all.

Put this Dockerfile into a source repository, preferably in a dedicated subdirectory. Later it will be much easier to tell what kind of creatures are being produced from it.

We are about to enable a tiny bit of magic. If you are not ready, perhaps take a short walk.

Jenkins can wait. That is, after all, usually its main job.

Create a Jenkinsfile with the following contents:

pipeline {
 agent {
 kubernetes {
 yaml '''
apiVersion: v1
kind: Pod
spec:
 hostAliases:
 - ip: "10.10.10.24"
 hostnames:
 - "registry.lab.local"
 containers:
 - name: base
 image: registry.lab.local/base-builder:0.1
 command: ["sleep"]
 args: ["infinity"]
 - name: kaniko
 image: registry.lab.local/kaniko-builder:latest
 command: ["sleep"]
 args: ["infinity"]
 volumeMounts:
 - name: docker-config
 mountPath: /kaniko/.docker
 volumes:
 - name: docker-config
 configMap:
 name: kaniko-docker-config
'''
 }
 }

 environment {
 IMAGE_NAME = 'registry.lab.local/python-builder'
 IMAGE_TAG = '3.11.1'
 }

 stages {
 stage('Prepare') {
 steps {
 container('base') {
 script {
 env.GIT_SHA = sh(
 script: 'git rev-parse --short HEAD',
 returnStdout: true
 ).trim()

 currentBuild.displayName = "#${env.BUILD_NUMBER} python-3"
 currentBuild.description = "python-builder:3, commit ${env.GIT_SHA}"
 }

 sh '''
 echo "IMAGE=${IMAGE_NAME}:${IMAGE_TAG}"
 ls -la
 '''
 }
 }
 }

 stage('Build and push image') {
 steps {
 container('kaniko') {
 sh '''
 /kaniko/executor \
 --context "${WORKSPACE}" \
 --dockerfile "${WORKSPACE}/python-builder/Dockerfile" \
 --destination "${IMAGE_NAME}:${IMAGE_TAG}" \
 --insecure \
 --skip-tls-verify \
 --insecure-registry registry.lab.local
 '''
 }
 }
 }
 }

 post {
 success {
 echo "Built and pushed ${IMAGE_NAME}:${IMAGE_TAG}"
 }
 }
}

Commit it to the same repository, in the same subdirectory as the Dockerfile.

The cluster needs one additional ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
 name: kaniko-docker-config
 namespace: jenkins
data:
 config.json: |
 {
 "auths": {}
 }

The Jenkinsfile refers to this ConfigMap in the agent section.

Now create a new Multibranch Pipeline job. Give it a sensible name, for example python-builder, and configure it:

enter the repository URL,
if credentials are required, select them, or add them first,
under Build configuration → Mode, make sure by Jenkinsfile is selected,
in Script Path, enter the path to the file, for example python-builder/Jenkinsfile.

Save the job and wait a moment.

Jenkins will start scanning branches in your repository, looking for the specified Jenkinsfile in each of them. If it finds one, it will try to run the job for that branch.

Once the Stage View starts rendering, you can observe what is happening in the jenkins namespace:

kubectl get pods -n jenkins -w

A new Pod will appear, do its job, and leave, as in the example below:

NAME READY STATUS RESTARTS AGE
jenkins-0 1/1 Running 12 (57m ago) 19d
python-builder-main-1-30xvv-l1cp7-vcw9m 0/3 Pending 0 0s
python-builder-main-1-30xvv-l1cp7-vcw9m 0/3 ContainerCreating 0 0s
python-builder-main-1-30xvv-l1cp7-vcw9m 3/3 Running 0 1s
python-builder-main-1-30xvv-l1cp7-vcw9m 3/3 Terminating 0 63s
python-builder-main-1-30xvv-l1cp7-vcw9m 0/3 Error 0 93s

The job completed successfully and the python-builder image landed in the registry.

You can verify that either through registry-ui or directly:

curl http://registry.lab.local/v2/python-builder/tags/list

The response should look like this:

{"name":"python-builder","tags":["3.11.1"]}

The image is now ready to use.

What just happened?

The contents of the Jenkinsfile definitely deserve an explanation, so let us start from the beginning.

`agent`

The agent section is without a doubt the most interesting part of this file.

Besides the type name, kubernetes, it contains a full Kubernetes Pod definition. In the specification we can see that:

hostAliases are used, because we do not have proper DNS here and still need to smuggle the registry address into the Pod,
all important containers are listed:
- base, which provides Git and basic shell tools,
- kaniko, which provides… well, kaniko.

Keeping the names consistent is important.

If you name the containers something like the_one_with_git and the_one_with_kaniko, you will have to use exactly those names later in the actual pipeline steps:

stages {
 stage('Prepare') {
 steps {
 container('the_one_with_git') {

In short: Jenkins creates an agent described in the agent section, and pipeline steps are executed inside specific containers from that Pod — the ones that provide the required tools.

This is the important part.

We are not installing build tools inside the main Jenkins server. The server only orchestrates work. The tools live in disposable containers, created only for the job that needs them.

That keeps the Jenkins controller cleaner, makes builds easier to reproduce, and avoids the traditional CI server problem where one machine slowly turns into a museum of forgotten compilers, package managers, SDKs, symlinks and emotional damage.

`kaniko`

Remember that kaniko is not Docker.

Its job is simply to build a container image and push it to a registry.

The important parameters are:

--context — the working directory, usually the job workspace,
--dockerfile — the location of the Dockerfile, in this case inside a subdirectory,
--destination — the registry location, image name and tag to push after the build.

Simple? Simple.

“But wait!” you might shout. “What about that mysterious kaniko-docker-config ConfigMap?”

Here it is.

kaniko likes to look inside /kaniko/.docker, mainly for a config.json file containing credentials, if they are required.

Our registry does not require authentication, but we still mount a ConfigMap there and provide an empty auths object:

{
 "auths": {}
}

This allows kaniko to try pushing the image anonymously right away.

Go builder

Not enough examples? Fine. Let us create a go-builder.

The Dockerfile could look like this:

FROM golang:1.26-bookworm

RUN apt-get update && apt-get install -y --no-install-recommends \
 git \
 openssh-client \
 ca-certificates \
 curl \
 wget \
 jq \
 make \
 rsync \
 && rm -rf /var/lib/apt/lists/*

RUN update-ca-certificates

USER root

WORKDIR /workspace

RUN go version

CMD ["sleep", "infinity"]

And the Jenkinsfile could look like this:

pipeline {
 agent {
 kubernetes {
 yaml '''
apiVersion: v1
kind: Pod
spec:
 hostAliases:
 - ip: "10.10.10.24"
 hostnames:
 - "registry.lab.local"
 containers:
 - name: base
 image: registry.lab.local/base-builder:0.1
 command: ["sleep"]
 args: ["infinity"]
 - name: kaniko
 image: registry.lab.local/kaniko-builder:latest
 command: ["sleep"]
 args: ["infinity"]
 volumeMounts:
 - name: docker-config
 mountPath: /kaniko/.docker
 volumes:
 - name: docker-config
 configMap:
 name: kaniko-docker-config
'''
 }
 }

 environment {
 IMAGE_NAME = 'registry.lab.local/go-builder'
 IMAGE_TAG = '1.26.1'
 }

 stages {
 stage('Prepare') {
 steps {
 container('base') {
 script {
 env.GIT_SHA = sh(
 script: 'git rev-parse --short HEAD',
 returnStdout: true
 ).trim()

 currentBuild.displayName = "#${env.BUILD_NUMBER} go-${env.IMAGE_TAG}"
 currentBuild.description = "go-builder:${env.IMAGE_TAG}, commit ${env.GIT_SHA}"
 }

 sh '''
 echo "GO_VERSION=${IMAGE_TAG}"
 echo "IMAGE=${IMAGE_NAME}:${IMAGE_TAG}"
 ls -la
 '''
 }
 }
 }

 stage('Build and push image') {
 steps {
 container('kaniko') {
 sh '''
 /kaniko/executor \
 --context "${WORKSPACE}" \
 --dockerfile "${WORKSPACE}/go-builder/Dockerfile" \
 --destination "${IMAGE_NAME}:${IMAGE_TAG}" \
 --insecure \
 --skip-tls-verify \
 --insecure-registry registry.lab.local
 '''
 }
 }
 }
 }

 post {
 success {
 echo "Built and pushed ${IMAGE_NAME}:${IMAGE_TAG}"
 }
 }
}

Yes, you do not need to rub your eyes in disbelief.

This Jenkinsfile looks almost identical to the previous one. The agent definition is the same, the kaniko invocation is the same, and the base image usage is the same. In practice, only names, version numbers and file paths change.

Simple? Simple.

Example use case

If you have a Go application lying around, you can use a Jenkinsfile like this one.

In this example, the test application is called rme:

pipeline {
 agent {
 kubernetes {
 yaml '''
apiVersion: v1
kind: Pod
spec:
 hostAliases:
 - ip: "10.10.10.24"
 hostnames:
 - "registry.lab.local"
 containers:
 - name: rme-go-builder
 image: registry.lab.local/go-builder:1.26.1
 command: ["sleep"]
 args: ["infinity"]
 - name: rme-kaniko
 image: registry.lab.local/kaniko-builder:latest
 command: ["sleep"]
 args: ["infinity"]
 volumeMounts:
 - name: docker-config
 mountPath: /kaniko/.docker
 volumes:
 - name: docker-config
 configMap:
 name: kaniko-docker-config
'''
 }
 }

 environment {
 IMAGE_NAME = 'registry.lab.local/rme'
 }

 stages {
 stage('Prepare') {
 steps {
 container('rme-go-builder') {
 script {
 env.VERSION = env.GIT_COMMIT.take(7)

 currentBuild.displayName = "#${env.BUILD_NUMBER} ${env.VERSION}"
 currentBuild.description = "${env.IMAGE_NAME}:${env.VERSION}"
 }
 }
 }
 }

 stage('Build binary') {
 steps {
 container('rme-go-builder') {
 sh '''
 git config --global --add safe.directory "$WORKSPACE"
 CGO_ENABLED=0 GOOS=linux go build -o rme .
 '''
 }
 }
 }

 stage('Build and push image') {
 steps {
 container('rme-kaniko') {
 sh '''
 /kaniko/executor \
 --context "${WORKSPACE}" \
 --dockerfile "${WORKSPACE}/Dockerfile" \
 --destination "${IMAGE_NAME}:${VERSION}" \
 --destination "${IMAGE_NAME}:latest" \
 --insecure \
 --skip-tls-verify \
 --insecure-registry registry.lab.local
 '''
 }
 }
 }
 }
}

The application Dockerfile can be very small:

FROM scratch

COPY rme /rme

EXPOSE 9101

ENTRYPOINT ["/rme"]

This is a more realistic example.

It uses a dedicated builder image, go-builder, to compile the Go application, and kaniko only for building and pushing the final container image.

A few details are worth noticing, because the devil usually lives exactly there:

container names matter, because they are later used in container(...) blocks,
the second --destination in the kaniko invocation:

--destination "${IMAGE_NAME}:latest" \

is intentional.

The latest tag will not magically appear in our registry by itself. If we want the most recently pushed image to also be available as latest, we need to tag and push it that way.

Summary and notes

As you can see, there is less and less that we strictly must do inside the cluster, and more and more that we can do in a controlled and repeatable way.

Versioned configuration, job history, artifact history, example applications, builds running inside containers — quite a lot is happening here.

Why use a Multibranch Pipeline?

Good question, but the answers are fairly obvious:

we do not have to clone the repository manually or hard-code credentials in the Jenkinsfile,
test branches do not require separate Jenkins jobs,
Jenkins detects new branches automatically,
deleted branches can disappear from Jenkins automatically as well,
each branch can have its own version of the Jenkinsfile,
pull requests are handled in a much cleaner way.

And now a suspicious thought appears.

What if we put all those YAML files under version control and let some clever mechanism take care of them automatically, instead of calling kubectl by hand every few minutes?

Could such a thing exist?

Who knows.

Jenkins in Kubernetes: Bring a Bucket

Sat, 11 Jul 2026 11:10:00 +0200

Warning: working with Jenkins requires a lot of determination. It is also wise to prepare a bucket in advance — for blood, sweat, tears, and all the failed pipelines.

There. I warned you.

Why Jenkins?

Jenkins has accumulated enough myths and urban legends to deserve several dedicated episodes of a good television show about mysterious phenomena and conspiracy theories.

For now, let us focus on a few practical facts:

Jenkins is a true Swiss Army knife in the CI/CD world.
Jenkins is worth knowing, because it may be lurking just around the corner in the organization you are about to join.
Jenkins is easy to run both locally and centrally.
Thanks to its many plugins, Jenkins can probably be used for almost anything.
You do not have to spend your life clicking around the UI. Jenkins Pipelines do their job.
It is worth getting familiar with Jenkins if only to form your own opinion about what you actually need from a CI/CD ecosystem.

A pinch of history

Jenkins originally started as a tool for building Java code, wrapped in a convenient web service available to everyone.

At first it was called Hudson, and perhaps it would still be called that today, but Sun Microsystems — where Hudson was created — was acquired by the large and not particularly cuddly company known for large and not particularly agile databases.

Then came a dispute over the name and project ownership. A fork appeared, someone proposed a new name, and off it went.

If this reminds you of MariaDB, congratulations: your pattern recognition module is working correctly.

Jenkins in a Kubernetes cluster

We will use Jenkins not only to build containers, but also to build regular applications and run ordinary tasks using purpose-built containers.

Requirements

Jenkins stores data on disk, so we will need a PersistentVolumeClaim.

From the cluster’s point of view, the main Jenkins server will run as a StatefulSet. An Ingress controller will provide HTTP(S) access through the address jenkins.lab.local.

As usual in this lab, add the following line to /etc/hosts on every machine that needs to access Jenkins, including your workstation:

10.10.10.24 jenkins.lab.local

The image

You can use an existing Jenkins image, for example the latest LTS image.

I do not recommend doing that here.

The bucket for blood, sweat and tears would need to be emptied far too often, with very little benefit. It is better to commit a custom image yourself — or in pairs, because at some point the basement nerds need someone to hold the light bulb.

Dockerfile

The Dockerfile looks like this:

FROM jenkins/jenkins:lts-jdk21 AS jenkins-tools

FROM eclipse-temurin:21-jre-jammy

ARG JENKINS_VERSION=2.555.3

USER root

RUN apt-get update && apt-get install -y --no-install-recommends \
 curl \
 git \
 openssh-client \
 ca-certificates \
 tini \
 fontconfig \
 jq \
 unzip \
 zip \
 && rm -rf /var/lib/apt/lists/*

RUN useradd -m -d /var/jenkins_home -u 1000 jenkins

RUN mkdir -p /usr/share/jenkins /var/jenkins_home /usr/share/jenkins/ref/plugins

RUN curl -fsSL \
 -o /usr/share/jenkins/jenkins.war \
 "https://get.jenkins.io/war-stable/${JENKINS_VERSION}/jenkins.war"

COPY --from=jenkins-tools /usr/bin/jenkins-plugin-cli /usr/bin/jenkins-plugin-cli
COPY --from=jenkins-tools /opt/jenkins-plugin-manager.jar /opt/jenkins-plugin-manager.jar

COPY plugins.txt /tmp/plugins.txt

RUN JENKINS_WAR=/usr/share/jenkins/jenkins.war \
 JENKINS_HOME=/usr/share/jenkins/ref \
 jenkins-plugin-cli \
 --war /usr/share/jenkins/jenkins.war \
 --plugin-file /tmp/plugins.txt

RUN chown -R jenkins:jenkins /usr/share/jenkins /var/jenkins_home

USER jenkins

ENV JENKINS_HOME=/var/jenkins_home

VOLUME /var/jenkins_home

EXPOSE 8080 50000

ENTRYPOINT ["/usr/bin/tini", "--"]
CMD ["java", "-Djenkins.install.runSetupWizard=false", "-jar", "/usr/share/jenkins/jenkins.war", "--httpPort=8080"]

You can put plugins in plugins.txt and install them directly into the image.

You can also install them later, because Jenkins will have persistent storage. Whether this is a convenience or the beginning of a future archaeology project depends on your level of optimism.

Building the image

The image is built for the arm64 architecture:

docker buildx build \
 --platform linux/arm64 \
 -t registry.lab.local/jenkins-lab:0.0.1 \
 --push .

The most likely result at this point is something like this:

> [stage-1 2/11] RUN apt-get update && apt-get install -y --no-install-recommends curl git openssh-client ca-certificates tini fontconfig jq unzip zip && rm -rf /var/lib/apt/lists/*:
0.126 exec /bin/sh: exec format error

Which means we need to help Docker understand how to run arm64 binaries:

docker run --privileged --rm tonistiigi/binfmt --install arm64

A successful installation should produce something like this:

Installing: arm64 OK
{
 "supported": [
 "linux/amd64",
 "linux/amd64/v2",
 "linux/amd64/v3",
 "linux/arm64",
 "linux/386"
 ],
 "emulators": [
 "python3.14",
 "qemu-aarch64"
 ]
}

Now we can build the image again:

docker buildx build \
 --platform linux/arm64 \
 -t registry.lab.local/jenkins-lab:0.0.1 \
 --push .

Cluster objects

For Jenkins to work properly, we need a few Kubernetes objects.

Namespace

The simplest way to create the namespace is:

kubectl create namespace jenkins

If you keep your configuration under version control — and you should, because future you has enough problems already — use a manifest instead:

---
apiVersion: v1
kind: Namespace
metadata:
 name: jenkins

PersistentVolumeClaim

The PVC definition looks like this:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: jenkins-home
 namespace: jenkins
spec:
 accessModes:
 - ReadWriteOnce

 resources:
 requests:
 storage: 20Gi

 storageClassName: local-path

ServiceAccount and Role

Jenkins needs permission to create and manage agent Pods in its namespace.

The following definitions are enough for this lab:

apiVersion: v1
kind: ServiceAccount
metadata:
 name: jenkins
 namespace: jenkins
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
 name: jenkins-agent-manager
 namespace: jenkins
rules:
 - apiGroups: [""]
 resources: ["pods", "pods/exec", "pods/log", "persistentvolumeclaims"]
 verbs: ["get", "list", "watch", "create", "delete", "patch", "update"]
 - apiGroups: [""]
 resources: ["secrets", "configmaps"]
 verbs: ["get", "list", "watch"]
 - apiGroups: [""]
 resources: ["events"]
 verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
 name: jenkins-agent-manager
 namespace: jenkins
subjects:
 - kind: ServiceAccount
 name: jenkins
 namespace: jenkins
roleRef:
 kind: Role
 name: jenkins-agent-manager
 apiGroup: rbac.authorization.k8s.io

Service and Ingress

Now we need a Service and an Ingress:

apiVersion: v1
kind: Service
metadata:
 name: jenkins
 namespace: jenkins
spec:
 selector:
 app: jenkins
 ports:
 - name: http
 port: 8080
 targetPort: http
 - name: agent
 port: 50000
 targetPort: agent
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 name: jenkins
 namespace: jenkins
spec:
 ingressClassName: nginx
 rules:
 - host: jenkins.lab.local
 http:
 paths:
 - path: /
 pathType: Prefix
 backend:
 service:
 name: jenkins
 port:
 name: http

StatefulSet

Finally, the StatefulSet:

apiVersion: apps/v1
kind: StatefulSet
metadata:
 name: jenkins
 namespace: jenkins
spec:
 serviceName: jenkins
 replicas: 1

 selector:
 matchLabels:
 app: jenkins

 template:
 metadata:
 labels:
 app: jenkins

 spec:
 serviceAccountName: jenkins
 nodeSelector:
 przeznaczenie: ci-cd

 volumes:
 - name: jenkins-home
 persistentVolumeClaim:
 claimName: jenkins-home

 containers:
 - name: jenkins
 image: registry.lab.local/jenkins-lab:0.0.1
 imagePullPolicy: Always

 ports:
 - name: http
 containerPort: 8080
 - name: agent
 containerPort: 50000

 env:
 - name: JENKINS_HOME
 value: /var/jenkins_home
 - name: JAVA_OPTS
 value: "-Djenkins.install.runSetupWizard=false"

 volumeMounts:
 - name: jenkins-home
 mountPath: /var/jenkins_home

 startupProbe:
 httpGet:
 path: /login
 port: http
 periodSeconds: 10
 failureThreshold: 60

 readinessProbe:
 httpGet:
 path: /login
 port: http
 periodSeconds: 10
 failureThreshold: 12

 livenessProbe:
 httpGet:
 path: /login
 port: http
 periodSeconds: 30
 failureThreshold: 10

Save all of the above definitions as YAML files and apply them with kubectl.

First start

Jenkins should start and greet us by asking for the initial token.

That token can be found in the depths of its home directory on the PVC. After that, it is the usual Jenkins ritual: administrator account, password, pending plugins, and all the other traditional rites of passage.

A freshly started Jenkins is a strange creature.

On one hand, it can be armed to the teeth with plugins. On the other hand, it is as naked as a jaybird. It does not have any build tools installed — but that is fine. We do not really need them.

The actual work will be done by purpose-built containers, created only when needed.

Configuring the Kubernetes cloud

This is where the Jenkins Cloud configuration comes in.

Configure it like this:

Manage Jenkins → Clouds → Add a new cloud → Kubernetes
Name: kubernetes, or any other name you prefer
Kubernetes URL: https://kubernetes.default.svc
Kubernetes namespace: jenkins
Enable WebSocket
Jenkins URL: http://jenkins.jenkins.svc.cluster.local:8080

Save the configuration.

Now all that remains is to create a few useful images, wire them into Jenkins pipelines, and then use them, use them, and use them some more.

Base builder

The first image will be… a base image for building other, better base images.

What does that mean?

The plan is for Jenkins to build many different applications, and also run jobs that may not build anything at all, but still need containers with specific tools inside.

There are two ways to approach this problem:

create one large image with every possible tool inside,
create many small, specialized images and use each one only when needed.

The second approach is easier to maintain.

The Dockerfile for the base builder looks roughly like this:

FROM debian:bookworm-slim

RUN apt-get update && apt-get install -y --no-install-recommends \
 ca-certificates \
 curl \
 wget \
 git \
 openssh-client \
 bash \
 make \
 jq \
 yq \
 tar \
 gzip \
 xz-utils \
 unzip \
 zip \
 rsync \
 file \
 procps \
 iputils-ping \
 dnsutils \
 && rm -rf /var/lib/apt/lists/*

RUN useradd -m -u 1000 builder

USER builder
WORKDIR /workspace

CMD ["sleep", "infinity"]

Build it like this:

docker buildx build \
 --platform linux/arm64 \
 -t registry.lab.local/base-builder:0.1 \
 --push .

Kaniko builder

The second image will contain kaniko, mainly for building container images.

Note: this is a lab setup. Kaniko works well enough for our purposes here, but before using it in production, check the current state of the project and consider alternatives such as Buildah or Podman. The CI/CD ecosystem moves quickly, usually while pretending it is doing so in a controlled manner.

Yes, kaniko is simpler to use than Docker in this setup. It does not require root privileges and it does not need a Docker daemon.

The Dockerfile can look like this:

FROM gcr.io/kaniko-project/executor:latest AS kaniko

FROM alpine:3.21

RUN apk add --no-cache \
 ca-certificates \
 bash \
 coreutils \
 curl \
 git

COPY --from=kaniko /kaniko /kaniko

ENV PATH="/kaniko:${PATH}"

WORKDIR /workspace

CMD ["sleep", "infinity"]

Build it like this:

docker buildx build \
 --platform linux/arm64 \
 -t registry.lab.local/kaniko-builder:0.1 \
 --push .

These two images need to be built manually.

All the other ones will be created later by Jenkins itself.

If you managed to get here in one piece, that is already quite good. In the next episode, we will learn how to make actual use of our newly assembled toys.

2026-06-30

Tue, 30 Jun 2026 19:10:00 +0200

Suit Up and March On!

What is Helm?

Kubernetes is popular enough that it was only a matter of time before someone came up with a way to install applications using one or two commands instead of manually assembling yet another small mountain of YAML files.

That tool is called Helm. It helps define, install, upgrade and manage applications running inside a Kubernetes cluster.

Think of it as the Kubernetes equivalent of apt, dnf or brew — except instead of installing packages on a machine, it installs applications into your cluster.

How does it work?

Helm introduces three basic concepts:

Chart — a package containing templates for all Kubernetes manifests required by an application.
Values — parameters used to customize those templates.
Release — a deployed instance of a chart inside a cluster. The first installation creates the initial revision, and every upgrade creates another one, making rollbacks straightforward.

In practice, you take a chart, adjust its values, install it into the cluster and get a named release that Helm can later upgrade, list, inspect or remove.

What do we need?

Not much:

a Kubernetes cluster,
kubectl,
helm.

Our first application will be Headlamp.

Kubernetes Dashboard still exists, but these days Headlamp is often the more pleasant choice, so that is what we will use here.

Headlamp is one of those rare applications that you install once and it simply works. Such things deserve appreciation.

Installing applications with Helm

Most applications are distributed through Helm repositories.

Adding one is simple:

helm repo add repository-name https://some.repo.url
helm repo update
helm install my-application repository-name/chart

repository-name is your local alias for the repository.

Likewise, my-application is the name of your release. It may look redundant at first, but imagine testing three different MariaDB installations from three different sources. Suddenly meaningful release names start looking less like ceremony and more like self-defense.

helm repo update works much like apt update: it refreshes the local cache with information about available chart versions.

You can also search through charts available in your configured repositories:

helm search repo headlamp
helm search repo bitnami

Where do the values come from?

The easiest way is to ask Helm for the default configuration:

helm show values repository-name/chart > values.yaml

Then edit the generated file and adjust it to your environment.

For Headlamp, the following values.yaml is enough for this lab:

config:
 inCluster: true

ingress:
 enabled: true
 ingressClassName: nginx
 hosts:
 - host: headlamp.lab.local
 paths:
 - path: /
 type: Prefix

nodeSelector:
 przeznaczenie: observability

We need to define the Ingress class, the hostname under which the application will be available, and optionally a nodeSelector if we want to control where the Pod runs.

As usual in this lab setup, we also need to add the hostname to /etc/hosts on every machine that will access the service, including the workstation:

10.10.10.24 headlamp.lab.local

Installing Headlamp

Now comes the easy part:

helm repo add headlamp https://kubernetes-sigs.github.io/headlamp/
helm repo update

helm install headlamp headlamp/headlamp \
 --namespace headlamp \
 --create-namespace \
 -f values.yaml

After opening the URL in a browser, we get a friendly login screen:

Headlamp asks for a Kubernetes authentication token.

Generating one is straightforward:

kubectl -n headlamp create token headlamp

The application itself is clean, tasteful and not overloaded with options. Most things are exactly where you expect them to be.

You can browse resources, inspect logs and click through various settings without leaving the browser.

Another excellent Kubernetes client is k9s. It runs entirely in the terminal, so you do not get fancy graphical topology views, but everything else is there — and it is fast.

As you can see, basic Helm usage is pleasantly simple.

Installing databases

There is not much point in overexplaining databases here. We are going to install a few of them from a popular public repository and see how little work is actually required.

We will use Bitnami’s repository:

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update

kubectl create namespace databases

The separate namespace is not strictly magical, but it keeps things tidy.

PostgreSQL

Example values.yaml:

global:
 storageClass: local-path

architecture: standalone

auth:
 postgresPassword: "some-password"
 username: "marcin"
 password: "some-other-password"
 database: "utensils"

primary:
 nodeSelector:
 przeznaczenie: heavy-worker

 persistence:
 enabled: true
 size: 20Gi

 service:
 type: NodePort
 ports:
 postgresql: 5432
 nodePorts:
 postgresql: 30432

The database will be exposed through NodePort 30432.

Since this is not a web application, we need to remember which node actually hosts the Pod. Thanks to the nodeSelector, that should be 10.10.10.25.

Installation:

helm install postgresql bitnami/postgresql \
 --namespace databases \
 -f values.yaml

Afterwards Helm prints a few useful notes, including commands for retrieving generated credentials:

To get the password for "postgres" run:

export POSTGRES_ADMIN_PASSWORD=$(kubectl get secret --namespace databases postgresql -o jsonpath="{.data.postgres-password}" | base64 -d)

To get the password for "marcin" run:

export POSTGRES_PASSWORD=$(kubectl get secret --namespace databases postgresql -o jsonpath="{.data.password}" | base64 -d)

MariaDB

Example configuration:

global:
 storageClass: local-path

architecture: standalone

auth:
 rootPassword: "some-password"
 database: "utensils"
 username: "marcin"
 password: "some-other-password"

primary:
 nodeSelector:
 przeznaczenie: heavy-worker

 persistence:
 enabled: true
 size: 20Gi

 service:
 type: NodePort
 ports:
 mysql: 3306
 nodePorts:
 mysql: 30306

This database will listen on NodePort 30306, on the same node as PostgreSQL.

Installation:

helm install mariadb bitnami/mariadb \
 --namespace databases \
 -f values.yaml

Administrator credentials can be retrieved from the generated Secret:

Username: root
Password: $(kubectl get secret --namespace databases mariadb -o jsonpath="{.data.mariadb-root-password}" | base64 -d)

Redis

Example configuration:

architecture: standalone

auth:
 enabled: false

master:
 nodeSelector:
 przeznaczenie: heavy-worker

 persistence:
 enabled: true
 storageClass: local-path
 size: 5Gi

 resources:
 requests:
 cpu: 50m
 memory: 128Mi
 limits:
 memory: 512Mi

metrics:
 enabled: true
 serviceMonitor:
 enabled: true
 namespace: databases

Installation is exactly what you would expect:

helm install redis bitnami/redis \
 --namespace databases \
 -f values.yaml

At this point the cluster is starting to look like an actual environment instead of an empty playground.

As an exercise, I recommend installing a few well-known applications and checking how they are packaged, configured and exposed. There is no need to rediscover America when so many useful things are already available in public Helm repositories.

Updating an application

Sooner or later, you will change something in values.yaml.

Instead of uninstalling and installing the application again, upgrade the existing release:

helm upgrade headlamp headlamp/headlamp \
 --namespace headlamp \
 -f values.yaml

Helm applies the new configuration while preserving release history. If something goes sideways, that history becomes useful very quickly.

Removing applications

When an application outlives its usefulness — and why is it always Headlamp? — removing it is just as easy:

helm uninstall my-application

If it was installed in a specific namespace, add it explicitly:

helm uninstall my-application \
 --namespace namespace-name

Listing installed releases

This command shows releases from the current namespace:

helm list

Which is technically correct and practically disappointing most of the time.

Usually, this is what you want:

helm list -A

It lists releases across all namespaces.

And that is the nice thing about Helm: the basic workflow stays small.

Add a repository, inspect the values, install a release, upgrade it when needed, list what is running, remove what is no longer useful. Underneath, Kubernetes still does Kubernetes things, but at least you do not have to hand-write every single manifest like it is some YAML-based monastic ritual.

2026-06-29

Mon, 29 Jun 2026 19:15:00 +0200

Buffer Overflow

Today we begin in a slightly unusual place.

Interrupting the Current Operation

If there is one key binding worth remembering before you even open your first file in Emacs, it is this one:

C-g

While Emacs is executing some more complicated Lisp code, it may occasionally stop responding to user commands and give the impression that it has frozen.

Nothing could be further from the truth.

Emacs is not dead. It is merely busy executing that unfortunate piece of Lisp.

There are two possible approaches:

wait patiently until the Lisp interpreter finishes its work,
or interrupt it.

The latter is usually more practical.

C-g interrupts the current operation. It works when Emacs is running a long command, waiting for minibuffer input, or otherwise pretending not to hear you.
M-x keyboard-quit is the function bound to C-g by default. Calling it manually is usually pointless: when Emacs is busy, you cannot invoke it, and when Emacs is not busy, there is nothing to interrupt. Still, the name is worth knowing if you ever decide to remap keys.

If you forget everything else from this section, remember C-g.

When something goes wrong, Emacs will usually listen.

Lisp programmers are less predictable.

What Does This Key Do?

Let us continue.

Emacs contains an excellent built-in help system. One of its most useful features is the ability to ask:

What command is this key binding actually running?

To find out, use:

M-x describe-key
or, more conveniently, C-h k

Emacs will then ask you to press a key sequence, mouse button, or menu item.

For example:

C-h k C-p

opens a help buffer describing the command bound to C-p.

A shortened version looks like this:

C-p runs the command previous-line.

It is bound to C-p and <up>.

Move cursor vertically up ARG lines.

This function is for interactive use only;
in Lisp code use `forward-line' with negative argument instead.

Even this small fragment tells us quite a lot:

which function is bound to the key,
where the function comes from,
which other keys invoke the same command,
what the command does,
whether it is meant for interactive use,
and sometimes which related commands or variables are worth knowing about.

This is one of Emacs’ great strengths.

The program is not merely configurable. It is also unusually good at explaining itself.

Bookmark: if you have reached this point and started yawning, leave this article open. Tomorrow you will know exactly where to resume reading.

You do not have to thank me.

What Does This Function Do?

The same idea works in the other direction.

If you know the name of a function and want to inspect it, use:

M-x describe-function
or simply C-h f

For example:

C-h f find-file

opens a help buffer for the function used to visit files.

A shortened fragment looks like this:

find-file is an interactive function in `files.el`.

It is bound to <open> and C-x C-f.

Edit file FILENAME.
Switch to a buffer visiting file FILENAME, creating one if none already exists.

You can visit files on remote machines by specifying something like:

/ssh:SOME_REMOTE_MACHINE:FILE

You can also visit local files as a different user by specifying:

/sudo::FILE

To visit a file without conversion and without automatically choosing
a major mode, use M-x find-file-literally.

This is why reading Emacs help buffers is often surprisingly useful.

Even a command as ordinary as find-file turns out to do more than merely open files.

Several useful details appear immediately:

Wildcards — file name patterns can be expanded, allowing multiple files to be opened at once.
Remote files — paths such as /ssh:some-host:some-file open files over SSH.
Files as another user — paths such as /sudo::some-file allow editing files with elevated privileges.

The last option is useful for editing configuration files that require administrative access.

Other possible uses are left to the reader’s imagination and the local security department.

At this point, Dear Reader, I assume you have already typed a single * in some directory full of random files and discovered that Emacs can open rather more things than expected:

images,
PDFs,
OpenOffice and LibreOffice documents,
documents produced by that office suite which now apparently wishes to be known as a co-pilot,
EPUB and MOBI files,
archives,
and many other formats.

It probably will not play your movies, but it can certainly inspect archives.

What to do with all those joyfully opened files will be discussed a little later.

Buffers and Frames

Dividing the working area of a frame into two or more windows was invented mainly so that several buffers could be displayed side by side.

Anyone who writes code probably understands the value of that immediately.

The King of Editors can split a frame both horizontally and vertically. The resulting windows can be split again, although not forever. Once a window becomes too small, Emacs will politely refuse and display an appropriate message.

Useful key bindings:

C-x 2 — split the current window horizontally
C-x 3 — split the current window vertically
C-x 1 — delete all other windows and return to a single-window layout
C-x 0 — delete the current window
C-x 5 2 — create a new frame
C-x 5 1 — delete other frames
C-x 5 0 — delete the current frame
C-x o — move focus to the next window
C-x S-o — move focus to the previous window

A very important detail:

C-x 1 removes window splits, but it does not kill any buffers. The buffers remain open; only one of them is currently visible.

Working with Multiple Buffers

Emacs can open as many buffers as available memory allows.

Because of that, there is usually no point in starting another Emacs instance every time you want to open another file. When you need another file, open it in the same Emacs session.

Emacs was designed for working with many buffers at once. Running several separate instances is possible, but in everyday use it is rarely necessary.

Yes, this is the “a little later” mentioned above.

If a file is no longer needed, kill its buffer with:

C-x k

By default, Emacs asks what to do with buffers that contain unsaved changes.

You can move to the previous or next buffer with:

C-x Left
C-x Right

You can also switch directly to a named buffer using:

C-x b

If the buffer visits a file, its name is usually the same as the file name.

If you do not remember the exact name, press TAB. Emacs will display possible completions in a temporary window. You can also start typing and let completion narrow the list.

Completion, selection, and minibuffer behavior are, of course, topics for another volume of the Emacs saga.

To list all buffers, use:

C-x C-b

This opens a buffer containing the buffer list. You can move into that buffer and choose one of the listed entries.

The buffer list does not automatically refresh every time a new buffer is created. This makes sense once you realize that the buffer list is itself just another buffer.

Press:

to refresh it.

What else can be done inside the buffer list?

As homework, press:

and read the help page.

Scrolling Another Window

One of the more useful Emacs features is the ability to scroll the contents of another window while continuing to work in the current one.

No switching back and forth.

No mouse.

No unnecessary ceremony.

If you are writing in one window and need to inspect something above or below in another window, Emacs has you covered.

This is especially useful when both windows display different parts of the same file and you want to check what regrettable code you wrote earlier.

Useful key bindings:

C-M-v — scroll the other window down
C-M-S-v — scroll the other window up

Alternative bindings:

M-PageDown — scroll the other window down
M-PageUp — scroll the other window up

This is one of those features that sounds minor until you start using it. After a few days, working without it feels unnecessarily clumsy.

A note that will age badly and is not really on topic: at the moment, southern Poland is experiencing temperatures that feel entirely incompatible with human life. Some people of questionable judgment still insist that climate change does not exist, and that trains in the seventeenth century were also stuffy.

Drink enough water.

This is not a joke.

Otherwise, the seventeenth-century train will arrive for you personally.

2026-06-28

Sun, 28 Jun 2026 16:08:00 +0200

Listbox, anyone?

Many popular UI toolkits have their listbox control implemented to be as simple in use as possible. The most common operations are: creating the control, adding the data rows, deleting and editing data, handling the selection. Almost all toolkits provide single functions or suitable methods to realize above operations.

Gtk+ is quite different: it requires more abstract way of thinking and additional objects to be created, but the lists and trees are more flexible and elegant.

Storing the data

Before we can display a single string, let’s first earn a PhD in data models.

Unlike the the other toolkits, the gtk+ list allows to display a few values per a row. Gtk+ list also distinguishes between the types of data, while other lists treat its row data as a single string.

In fact, the TreeView widget will be used to display elements. The model lets the display widget know about data types to be used in the control, it also determines the type of the control (if it should be a list or a tree). Besides, the model is used to store all the data (it is common to find a “store” term instead of “model” in various papers or in someone’s code)

A store/model can be created by calling a proper constructor with at least one data type (to be used in the list) as argument:

store = Gtk.ListStore(type1, ...)

Example:

store = Gtk.ListStore(int, str, str)

Created store will contain one integer value and two strings per row. Although pygtk reference recommends to use build-in GObject types (for instance, gobject.TYPE_INT and gobject.TYPE_STRING instead of int and str respectively), python built-in types are also allowed (GObject names really matter in C or C++)

Adding the data rows

The method append from Gtk.ListStore class allows to append one row at the end of the store. Sequence with all values should be passed as a parameter:

store.append([val1, ...])

Example:

store.append([7, "str1", "str2"])

Columns and renderers

Control widget should know about columns it should display, their order and how to present data from the store. Gtk+ provides the column widget (Gtk.TreeViewColumn) to manage displaying the cells of data and renderer widgets (Gtk.CellRenderer and its derivatives) to realize rendering of particular cells.

Column widget is usually created by calling a constructor of Gtk.TreeViewColumn with a header title passed as the argument:

column = Gtk.TreeViewColumn(title)

Example:

column = Gtk.TreeViewColumn("Column header")

Column header is visible by default — passing an empty string to the constructor will not get rid of it.

Cell renderer should be one of Gtk.CellRendererAccel, Gtk.CellRendererCombo, Gtk.CellRendererPixbuf, Gtk.CellRendererProgress, Gtk.CellRendererSpin, Gtk.CellRendererText, Gtk.CellRendererToggle. The renderer object is usually created by calling the constructor with no parameters

Example:

renderer = Gtk.CellRendererText()

Renderers should be added to the column widgets: pack_start and pack_end methods are used to do the packing.

column.pack_start(renderer)

column.pack_end(renderer)

Example:

column1 = Gtk.TreeViewColumn("Column1")
renderer1 = Gtk.CellRendererText()
renderer2 = Gtk.CellRendererText()
renderer3 = Gtk.CellRendererText()
column1.pack_start(renderer1)
column1.pack_start(renderer2)
column1.pack_end(renderer3)

The column widget must know which data column from the model should be connected to any of these renderers. This could be done by calling set_attributes method:

column.set_attributes(renderer, ...)

All optional parameters are “key = value” pairs, where key is the data type and value is number of column in the store

Example:

column1.set_attributes(renderer1, text = 2)
column1.set_attributes(renderer2, text = 0)
column1.set_attributes(renderer3, text = 1)

TreeView control

The last step is to create a control and add all columns. Constructor of the control takes the store as first parameter:

listControl = Gtk.TreeView(model=store)

The method append_column adds given column to the tree/list control:

listControl.append_column(column)

Summary: at least, four objects should be created to have the tree/list control working: a model which determines types of data and stores all the rows, a renderer, which takes care of displaying the cells, a column, which glues together model columns and suitable renderers and a treeview control itself.

Working examples

Following examples illustrate the creation and displaying of the lists.

Very simple list control

The simplest list control contains only one column and displays only one value per row

#!/usr/bin/env python3
 
import gi

gi.require_version("Gtk", "3.0")
from gi.repository import Gtk
 
class ListBoxViewer1:
 def destroyCallback(self, widget, data=None):
 Gtk.main_quit()
 
 def __init__(self):
 self.listStore = Gtk.ListStore(str)
 self.listStore.append(["String 1"])
 self.listStore.append(["String 2"])
 self.listStore.append(["String 3"])
 self.listStore.append(["String 4"])
 self.listStore.append(["String 5"])
 self.listColumn = Gtk.TreeViewColumn("Sample column")
 self.textRenderer = Gtk.CellRendererText()
 self.listColumn.pack_start(self.textRenderer, True)
 self.listColumn.set_attributes(self.textRenderer, text = 0)
 self.mainWindow = Gtk.Window(type=Gtk.WindowType.TOPLEVEL)
 self.mainWindow.set_title('ListBoxViewer1');
 self.listBox = Gtk.TreeView(model=self.listStore)
 self.listBox.append_column(self.listColumn)
 self.mainWindow.add(self.listBox)
 self.mainWindow.connect('delete_event', self.destroyCallback)
 self.mainWindow.show_all()

if __name__ == "__main__":
 lbv1 = ListBoxViewer1()
 Gtk.main()

This example covers the theory of creating listboxes with additional routines necessary to run minimal gtk+ program. Additional method is added to provide termination of this example when its window has been closed.

All list-related routines are explained below:

self.listStore = Gtk.ListStore(str)
self.listStore.append(["String 1"])
self.listStore.append(["String 2"])
self.listStore.append(["String 3"])
self.listStore.append(["String 4"])
self.listStore.append(["String 5"])

The model is created: it can hold one string value per a row. Then it is populated by 5 rows.

self.textRenderer = Gtk.CellRendererText()

Text renderer is created.

self.listColumn = Gtk.TreeViewColumn("Sample column")
self.listColumn.pack_start(self.textRenderer, True)
self.listColumn.set_attributes(self.textRenderer, text = 0)

A column is created. Then the renderer is packed into the column, and the column is informed which column and what type of data from the store will be used.

self.listBox = Gtk.TreeView(self.listStore)
self.listBox.append_column(self.listColumn)

Main widget is created. The column is appended to the list.

It looks like the following:

Explanation of the next examples contains only the routines related to list control; other routines did not change if not mentioned.

Two values per row

 self.listStore = Gtk.ListStore(str, int)
 self.listStore.append(["String 1", 18000])
 self.listStore.append(["String 2", 1500])
 self.listStore.append(["String 3", 900])
 self.listStore.append(["String 4", 60])
 self.listStore.append(["String 5", 3])

Now the store holds a string an integer pair per a row.

self.listColumn = Gtk.TreeViewColumn("Sample column")
self.textRenderer = Gtk.CellRendererText()
self.numRenderer = Gtk.CellRendererText()
self.numRenderer.set_property('xalign', 1.0)

A column and two cell renderers are created. The set_property routine with xalign property to be set tells the renderer to align right the values in the row. Value of 0.0 means left alignment, 0.5 centers the text and 1.0 means right alignment.

self.listColumn.pack_start(self.textRenderer, True)
self.listColumn.pack_start(self.numRenderer, False)
self.listColumn.set_attributes(self.textRenderer, text = 0)
self.listColumn.set_attributes(self.numRenderer, text = 1)

The two renderers are packed into the column. The string value renderer will expand the cell if possible. Proper renderers are assigned to proper data columns from the store.

self.listBox = Gtk.TreeView(store=self.listStore)
self.listBox.append_column(self.listColumn)

The control is created and the column is appended to the control.

The following picture shows the result of this example:

Two columns in the control

self.listColumn1 = Gtk.TreeViewColumn("Ascii text")
self.listColumn2 = Gtk.TreeViewColumn("Numeric value")
self.textRenderer = Gtk.CellRendererText()
self.numRenderer = Gtk.CellRendererText()
self.numRenderer.set_property('xalign', 1.0)
self.listColumn1.pack_start(self.textRenderer, True)
self.listColumn2.pack_start(self.numRenderer, False)
self.listColumn1.set_attributes(self.textRenderer, text = 0)
self.listColumn2.set_attributes(self.numRenderer, text = 1)

Every column packs one of the renderes. It looks like the following:

Adding pixmaps to the list

Now, creating the store is like below:

self.sheetIcon = Gtk.gdk.pixbuf_new_from_file("sheet.xpm");
self.listStore = Gtk.ListStore(str, int, Gtk.gdk.Pixbuf)
self.listStore.append(["String 1", 18000, self.sheetIcon])
self.listStore.append(["String 2", 1500, self.sheetIcon])
self.listStore.append(["String 3", 900, self.sheetIcon])
self.listStore.append(["String 4", 60, self.sheetIcon])
self.listStore.append(["String 5", 3, self.sheetIcon])

The pixbuf is added in every row. Of course, it may be different in every row. This is only the example.

self.iconRenderer = Gtk.CellRendererPixbuf()

The icon requires a special kind of cell renderer.

self.listColumn1.pack_start(self.iconRenderer, False)
self.listColumn1.set_attributes(self.iconRenderer, pixbuf = 2)

Pixbuf cell renderer is now packed into the first column together with the text renderer.

It looks like the following:

Display the same values twice or more times

Displaying more values per row is achieved by multiplicating the renderes:

self.listColumn1 = Gtk.TreeViewColumn("Ascii text")
self.listColumn2 = Gtk.TreeViewColumn("Numeric value")
self.textRenderer = Gtk.CellRendererText()
self.textRenderer2 = Gtk.CellRendererText()
self.numRenderer = Gtk.CellRendererText()
self.numRenderer2 = Gtk.CellRendererText()
self.numRenderer3 = Gtk.CellRendererText()
self.iconRenderer = Gtk.CellRendererPixbuf()
self.iconRenderer2 = Gtk.CellRendererPixbuf()
self.numRenderer.set_property('xalign', 1.0)
self.numRenderer2.set_property('xalign', 0.0)
self.numRenderer2.set_property('xalign', 0.5)
self.textRenderer2.set_property('xalign', 1.0)
self.listColumn1.pack_start(self.iconRenderer, False)
self.listColumn1.pack_start(self.textRenderer, True)
self.listColumn2.pack_start(self.numRenderer, False)
self.listColumn2.pack_start(self.numRenderer2, False)
self.listColumn2.pack_start(self.iconRenderer2, False)
self.listColumn2.pack_start(self.numRenderer3, False)
self.listColumn2.pack_start(self.textRenderer2, True)
self.listColumn1.set_attributes(self.iconRenderer, pixbuf = 2)
self.listColumn1.set_attributes(self.textRenderer, text = 0)
self.listColumn2.set_attributes(self.numRenderer, text = 1)
self.listColumn2.set_attributes(self.numRenderer2, text = 1)
self.listColumn2.set_attributes(self.numRenderer3, text = 1)
self.listColumn2.set_attributes(self.textRenderer2, text = 0)
self.listColumn2.set_attributes(self.iconRenderer2, pixbuf = 2)

Also, the left, right and center alignment of text is shown.

It looks like the following:

2026-06-26

Fri, 26 Jun 2026 11:15:00 +0200

Why Do We Need a Registry?

Sooner or later, every Kubernetes cluster starts running applications that were built locally.

At first, using Docker Hub seems perfectly reasonable.

Then the first custom application appears.

Then another.

Eventually every deployment references images that exist only on your workstation.

Clearly, this is not a sustainable solution.

A private container registry solves this problem by providing a permanent home for your own images. Since the home lab already has plenty of storage available, hosting the registry locally is both the simplest and the fastest option.

PersistentVolume and PersistentVolumeClaim

One of the original design goals of Kubernetes was that Pods should be ephemeral.

Applications come and go.

Containers are recreated.

Nodes may disappear.

Unfortunately, databases tend to have rather strong opinions about losing their contents.

To bridge the gap between ephemeral workloads and persistent storage, Kubernetes introduced two API objects:

PersistentVolume (PV)
PersistentVolumeClaim (PVC)

PersistentVolume

A PersistentVolume represents an actual storage resource available inside the cluster.

Unlike Pods, a PersistentVolume exists independently of any application using it. Deleting a Pod does not automatically remove the underlying storage.

Think of it as the physical disk—or, more precisely, a piece of storage that Kubernetes knows how to manage.

PersistentVolumeClaim

A PersistentVolumeClaim is exactly what its name suggests: a request for storage.

Rather than asking for a specific disk, an application simply requests:

a certain amount of space,
an access mode,
and, optionally, a storage class.

The Pod never mounts a PersistentVolume directly. Instead, it references a PVC and lets Kubernetes handle the rest.

Binding

Whenever a PersistentVolumeClaim is created, Kubernetes searches for a suitable PersistentVolume that satisfies the requested parameters.

If one is found, the claim becomes permanently bound to that volume.

From the application’s point of view, none of this complexity exists.

The Pod simply mounts the PVC as a directory inside the container.

Access Modes

Access modes describe how Kubernetes nodes are allowed to mount a volume.

Four access modes currently exist:

ReadWriteOnce (RWO) — the volume may be mounted for reading and writing by only one node at a time. Multiple Pods may still use it, provided they all run on that node.
ReadWriteMany (RWX) — the volume may be mounted simultaneously by multiple nodes.
ReadOnlyMany (ROX) — multiple nodes may mount the volume, but only for reading.
ReadWriteOncePod (RWOP) — introduced more recently, this mode guarantees that exactly one Pod in the entire cluster has read-write access to the volume.

Note: the underlying storage backend must actually support the requested access mode. Kubernetes cannot magically turn a local SSD into a distributed filesystem.

Where Should the Data Live?

By default, k3s ships with the Local Path Provisioner, which stores dynamically created PersistentVolumes under:

/var/lib/rancher/k3s/storage

Personally, I prefer keeping persistent application data somewhere more obvious, such as:

/srv/storage

To do that, create the directory on every node:

sudo mkdir -p /srv/storage
sudo chmod 777 /srv/storage

The permissions are intentionally generous. This is a home lab, not Fort Knox.

Next, edit the local-path-config ConfigMap:

kubectl -n kube-system edit configmap local-path-config

The interesting part looks like this:

apiVersion: v1
data:
 config.json: |-
 {
 "nodePathMap":[
 {
 "node":"DEFAULT_PATH_FOR_NON_LISTED_NODES",
 "paths":["/var/lib/rancher/k3s/storage"]
 }
 ]
 }

Simply replace:

"paths":["/var/lib/rancher/k3s/storage"]

with:

"paths":["/srv/storage"]

Newly created PersistentVolumes will now live there instead.

Deploying the Registry

The registry will be available as:

registry.lab.local

Since there is no local DNS server yet, every machine—including your workstation—should receive the following /etc/hosts entry:

10.10.10.24 registry.lab.local

The registry should preferably run on the most capable machine in the cluster.

In my case, that is iridium.

Assign it an appropriate label:

kubectl label node iridium registry=true

The Deployment manifest below uses that label via a nodeSelector.

At first glance, a registry seems like a simple application.

Then you remember it needs persistent storage.

And a Service.

And an Ingress.

And perhaps its own namespace.

And a ConfigMap.

So, in the end, it turns out to require exactly six Kubernetes objects:

Namespace
PersistentVolumeClaim
ConfigMap
Deployment
Service
Ingress

Their complete definitions are shown below.

(YAML manifest unchanged.)

Save everything as:

registry.yaml

and deploy it using:

kubectl apply -f registry.yaml

Interesting Bits

The PVC requests persistent storage:

accessModes:
 - ReadWriteOnce

The registry is pinned to the node labelled earlier:

nodeSelector:
 registry: "true"

The ingress disables request size limits:

nginx.ingress.kubernetes.io/proxy-body-size: "0"

Without this annotation, pushing sufficiently large images eventually results in sadness, disappointment, and extensive arm waving.

The registry configuration itself is stored in a ConfigMap rather than a long list of environment variables.

Since the registry already expects a YAML configuration file, using a ConfigMap keeps the deployment considerably cleaner.

This setup stores all registry data on the local filesystem of a single node. That is perfectly adequate for a home lab. Production environments usually rely on distributed storage instead.

Running Without TLS

If the registry temporarily runs over plain HTTP, Docker must be told to trust it.

Create:

/etc/docker/daemon.json

containing:

{
 "insecure-registries": ["registry.lab.local"]
}

Likewise, every k3s node should receive:

/etc/rancher/k3s/registries.yaml

containing:

mirrors:
 "registry.lab.local":
 endpoint:
 - "http://registry.lab.local"

Finally, restart k3s:

sudo systemctl restart k3s || sudo systemctl restart k3s-agent

Don’t forget to update the ConfigMap as well if you’re switching from HTTPS to HTTP.

Verification

The usual suspects come first:

kubectl get pods -n registry
kubectl get pvc -n registry
kubectl get ingress -n registry
kubectl get svc -n registry
kubectl describe ingress registry -n registry
kubectl get configmap -n registry

If the PVC reports:

STATUS: Bound

everything is proceeding nicely:

the PersistentVolume exists,
the claim has been bound,
the Pod is successfully using it.

Smoke Test

Let’s put the registry to work.

docker pull php:8.4.22-zts-trixie

docker tag php:8.4.22-zts-trixie \
 registry.lab.local/php:8.4.22

docker push registry.lab.local/php:8.4.22

To make sure the image really came from the registry rather than your local cache, remove it first:

docker image rm registry.lab.local/php:8.4.22

docker pull registry.lab.local/php:8.4.22

Finally, query the registry directly:

curl https://registry.lab.local/v2/php/tags/list

which should return:

{"name":"php","tags":["8.4.22"]}

Or list every repository:

curl -s https://registry.lab.local/v2/_catalog | jq

Congratulations.

Your registry is officially alive.

Registry UI

A registry works perfectly well without a graphical interface.

Humans, however, tend to appreciate one.

The excellent Docker Registry UI provides browsing, searching, and deleting images from a web browser.

As before, add:

10.10.10.24 registry-ui.lab.local

to every /etc/hosts.

Deploy the accompanying Deployment, Service, and Ingress manifests (shown below), save them as:

registry-ui.yaml

and apply them:

kubectl apply -f registry-ui.yaml

The interface is intentionally simple.

It won’t win any design awards, but it makes exploring your registry significantly more pleasant than remembering API endpoints.

Wrapping Up

At this point, the cluster has become largely self-sufficient.

Applications can now be built locally, pushed into the private registry, and deployed without relying on Docker Hub.

It may not look particularly impressive yet, but from now on every new service added to the cluster can remain entirely within the home lab.

Which, after all, was the idea from the very beginning.

2026-06-25

Thu, 25 Jun 2026 11:15:00 +0200

Installation

There isn’t much to say about installing Emacs.

Every respectable Linux distribution includes Emacs in its package repositories. Simply use your distribution’s package manager.
The same is true for the BSD family.
On macOS, you can install it using Homebrew, MacPorts, or download a native build from https://emacsformacosx.com/.
On Windows, simply download the official installer (.exe) or the ZIP archive and extract it somewhere sensible.
On Android, install the official .apk package and allow applications from unknown sources in the system settings.

A small note: if you have no interest in running the graphical version, most Unix-like systems also provide an emacs-nox package.

Of course, you can always build Emacs from source.

But why would you, when you could spend that hour starting another flame war on Twitter (formerly “X”), Reddit, or simply improving your thumb’s scrolling endurance on social media?

Personally, I’d rather spend that hour weeding the vegetable garden.

Usenet has long since passed into history, and no equally entertaining place for operating-system flame wars has ever truly replaced it.

Getting Started

Launching Emacs

Launching the Finest Editor Known to Humankind is surprisingly simple.

On graphical desktops, Emacs should appear in your applications menu like any other program.
On Windows, if you extracted the ZIP archive instead of running the installer, start bin\runemacs.exe.
If you prefer a purely terminal-based experience, simply run:

emacs -nw

This is where the Emacs journey truly begins.

The first launch of an unmodified (vanilla) Emacs under X11, Windows, or macOS opens a window featuring the GNU antelope, a welcome screen, and a few introductory notes.

Curiously, what most desktop environments call a window, Emacs calls a frame.

The reason is historical.

Long before graphical user interfaces became commonplace, Emacs already knew how to divide a terminal screen into multiple independent editing areas called windows. When graphical support arrived, the terminology remained unchanged: the top-level GUI object became a frame, while the individual editing regions inside it continued to be called windows.

Some traditions are simply too old to change.

Meet the Interface

A default Emacs frame consists of:

a menu bar,
a toolbar (whose appearance ranges from “functional” to “deeply unfortunate”, although fortunately it can be hidden),
one or more editing buffers,
and the command line, better known as the minibuffer.

Buffers

A buffer is the place where text is edited.

Unlike most editors, however, an Emacs buffer is not necessarily associated with a file.

Buffers may contain:

source code,
documentation,
shell sessions,
email,
directory listings,
Git status,
help pages,
or virtually anything else.

This abstraction is one of the core ideas behind Emacs.

Every buffer contains an editing area together with a mode line, which displays useful information such as:

the buffer name,
whether the buffer has unsaved changes,
the current cursor position,
and the active editing mode.

Major Modes

Most editing behavior in Emacs is controlled by major modes.

A major mode typically corresponds to the type of document being edited.

Whether you’re writing C code, XML, Markdown, Lisp, YAML, or something entirely your own, the selected mode determines:

syntax highlighting,
indentation rules,
available commands,
keyboard shortcuts,
and countless editor behaviors.

Creating your own modes is also entirely possible, should inspiration strike.

The Minibuffer

The minibuffer serves as the communication channel between Emacs and its user.

Emacs displays prompts and status messages there, while the user enters commands, filenames, search patterns, and countless other parameters.

The minibuffer supports:

command history,
TAB completion,
and context-sensitive suggestions.

It may look like a single line of text, but it is one of the most heavily used parts of Emacs.

Windows and Frames

A frame may be divided into multiple windows.

Each window displays a buffer.

Interestingly, multiple windows may display the very same buffer simultaneously, each with its own cursor position and viewport.

Only the minibuffer is shared across the entire frame.

Keys and Commands

Emacs documentation uses a notation that initially looks mysterious but quickly becomes second nature.

The most common forms are:

C-x — hold the Control key while pressing x.
C-x C-f — execute the first key sequence, release the regular keys (you may keep holding Control if you like), then execute the second.
M-x — hold the Meta key. On most PC keyboards this is simply the left Alt key. I strongly recommend getting used to the left Alt immediately, since the right one is often reserved for national characters or other platform-specific input methods.
C-M-x — press both Control and Meta together.
S-x — press Shift together with the specified key.

Finally, one notation deserves its own paragraph.

M-x

M-x executes an Emacs command.

Press M-x, release the keys, type the command name into the minibuffer, and press Enter.

Almost everything Emacs can do—apart from simply inserting text—is ultimately implemented as a Lisp function.

Some of those functions appear in menus.

Some are bound to keyboard shortcuts.

All of them can be executed directly via M-x.

For example:

choosing File → Open…
pressing C-x C-f
executing M-x find-file

all invoke exactly the same underlying function.

Useful Keyboard Shortcuts

The following commands quickly become second nature:

C-x C-c — exit Emacs. Generally considered a questionable life decision, although shutting down the computer is usually accepted as a valid excuse.
C-x C-f — open an existing file or create a new one.
C-x C-s — save the current buffer.
C-x C-w — save the current buffer under a different name.
C-x k — kill (close) the current buffer.
C-x Left — previous buffer.
C-x Right — next buffer.
C-x C-b — list all buffers.
C-x h — select the entire buffer.

Editing Text

Unlike some other editors, Emacs does not have separate “insert” and “command” modes.

Open a file.

Start typing.

That’s all there is to it.

Modern keyboards provide cursor keys, Home, End, Page Up, and Page Down, and Emacs fully supports them.

For historical reasons—and because terminals were not always so well equipped—traditional Emacs key bindings are also available:

C-a — beginning of line
C-e — end of line
C-f — forward one character
C-b — backward one character
C-p — previous line
C-n — next line
M-v — previous page
C-v — next page
M-w — copy selected text
C-w — cut selected text
C-y — paste
M-y — immediately after C-y, cycle through previous clipboard entries
C-k — kill text from the cursor to the end of the line. Pressing it twice at the beginning of a line removes the entire line.
C-x h — select the whole buffer.
C-_ (or C-x u) — undo, with unlimited history.

Graphical Emacs naturally supports selecting text with the mouse.

Keyboard users, however, can set the beginning of a selection using C-SPC, move the cursor to the desired position, and then perform any operation on the selected region.

It is one of those habits that soon becomes completely automatic.

One unexpected benefit of learning Emacs is that the keyboard shortcuts tend to follow you.

Bash, the Python REPL, GDB, and many other command-line programs borrow their line-editing behavior from GNU Readline, whose default key bindings are deliberately Emacs-like.

Even if you eventually decide that Emacs is not your editor of choice, the time spent learning C-a, C-e, C-k, or M-f will continue to pay dividends every time you open a terminal.

In fact, many people use Emacs key bindings every day without realizing where they originally came from.

2026-06-24

Wed, 24 Jun 2026 11:15:00 +0200

k3s: Ingress

What exactly is an Ingress?

In the Kubernetes ecosystem, an Ingress is an API object that manages external access to applications running inside a cluster. It acts as an intelligent HTTP and HTTPS router, eliminating the need to create a separate load balancer for every service.

How Does Ingress Work?

Traditional service exposure methods, such as NodePort or LoadBalancer, typically require assigning an external IP address to each service. This quickly becomes tedious and difficult to manage as the cluster grows.

Ingress centralizes external access and operates at Layer 7 (the application layer) of the OSI model:

Single entry point — only one public IP address needs to be exposed to the outside world.
Rule-based routing — traffic is forwarded to the appropriate service based on the requested URL path (for example, my.domain/something) or hostname (for example, something.my.domain).
SSL/TLS termination — HTTPS certificates can be handled centrally, removing that responsibility from individual applications.

Ingress vs. Ingress Controller

This distinction is important.

An Ingress object itself is merely a collection of routing rules.

For those rules to have any effect, the cluster must run an Ingress Controller — a reverse proxy responsible for processing incoming traffic and applying the rules defined in Ingress manifests.

Popular examples include:

NGINX Ingress Controller
Traefik
HAProxy Ingress

This guide uses the NGINX Ingress Controller.

Domain Names

Since the cluster will eventually host various web applications, it makes sense to identify services by DNS names rather than IP addresses.

The examples below use:

.lab.local

as the local domain.

This allows services to be accessed using names such as:

grafana.lab.local
argocd.lab.local
whoami.lab.local

which is considerably more pleasant than remembering port numbers.

Certificates

Sooner or later, running everything without TLS becomes annoying.

For a home lab environment, generating your own Certificate Authority and issuing certificates locally is perfectly acceptable.

Root Certificate Authority

Create a dedicated CA:

mkdir -p certs
cd certs

openssl genrsa -out lab-ca.key 4096

openssl req -x509 -new -nodes \
 -key lab-ca.key \
 -sha256 \
 -days 3650 \
 -out lab-ca.crt \
 -subj "/CN=Lab Local CA"

Wildcard Certificate

A wildcard certificate can secure every host under:

*.lab.local

Create the configuration file lab-local.cnf:

[req]
default_bits = 2048
prompt = no
default_md = sha256
distinguished_name = dn
req_extensions = req_ext

[dn]
CN = *.lab.local

[req_ext]
subjectAltName = @alt_names

[alt_names]
DNS.1 = *.lab.local
DNS.2 = lab.local

Generate the key, request, and certificate:

openssl genrsa -out lab-local.key 2048

openssl req -new \
 -key lab-local.key \
 -out lab-local.csr \
 -config lab-local.cnf

openssl x509 -req \
 -in lab-local.csr \
 -CA lab-ca.crt \
 -CAkey lab-ca.key \
 -CAcreateserial \
 -out lab-local.crt \
 -days 825 \
 -sha256 \
 -extensions req_ext \
 -extfile lab-local.cnf

Namespace for the Ingress Controller

The ingress controller will live in its own namespace.

Create ingress-namespace.yaml:

apiVersion: v1
kind: Namespace
metadata:
 name: ingress-nginx

Apply it:

kubectl apply -f ingress-namespace.yaml

TLS Secret

The certificate must be stored inside Kubernetes as a TLS secret:

kubectl -n ingress-nginx create secret tls lab-local-tls \
 --cert=lab-local.crt \
 --key=lab-local.key

The secret is named:

lab-local-tls

and can be referenced as:

ingress-nginx/lab-local-tls

throughout the cluster configuration.

Installing the CA Certificate on Your Workstation

The root CA must also be trusted by your workstation:

sudo cp lab-ca.crt /usr/local/share/ca-certificates/lab-ca.crt
sudo update-ca-certificates

Firefox users should additionally import the CA certificate manually through the browser settings.

Deploying the Ingress Controller

A complete ingress controller deployment requires several Kubernetes resources:

ServiceAccount
IngressClass
ConfigMap
ClusterRole
ClusterRoleBinding
Deployment

The container image used in this setup is:

registry.k8s.io/ingress-nginx/controller:v1.14.0

which provides the familiar NGINX reverse proxy and load balancer functionality.

The deployment manifest is shown below.

# ingress.yaml
# (manifest unchanged from the original article)

Noteworthy Configuration

The ingress controller is pinned to the control-plane node:

nodeSelector:
 kubernetes.io/hostname: iridium

This is perfectly acceptable for a small home lab.

The controller also uses the wildcard certificate by default:

--default-ssl-certificate=ingress-nginx/lab-local-tls

which means every ingress can immediately benefit from TLS.

Verifying the Installation

Start with the usual checks:

kubectl get pods -n ingress-nginx -o wide
kubectl get rs -n ingress-nginx -o wide

Next, add a test host entry:

10.10.10.24 test.lab.local

to your workstation’s /etc/hosts.

Then run:

curl http://test.lab.local

Expected result:

<html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx</center>
</body>
</html>

Surprisingly, this is good news.

The DNS lookup works.

The ingress controller works.

NGINX works.

There simply isn’t any application behind the hostname yet.

The infrastructure is doing exactly what it should.

TLS Verification

Next, test HTTPS:

curl -v https://test.lab.local

The interesting part is not the final HTTP response, but the TLS negotiation itself.

Look for output similar to:

SSL connection using TLSv1.3
...
subject: CN=*.lab.local
...
issuer: CN=Lab Local CA
...
subjectAltName: "test.lab.local" matches cert's "*.lab.local"
...
SSL certificate verified via OpenSSL

If these messages appear, the certificate chain is functioning correctly and the wildcard certificate is being served as expected.

Finally, open the URL in Firefox and confirm that the browser displays the expected lock icon and certificate information.

Conclusion

At this point:

DNS works,
the ingress controller is running,
TLS works,
wildcard certificates work,
external traffic reaches the cluster.

No actual applications are exposed yet, but the foundation is now in place.

The cluster is finally ready to host something more interesting than infrastructure components.

Which, as every Kubernetes administrator eventually discovers, is usually the easy part.

2026-06-23

Tue, 23 Jun 2026 11:15:00 +0200

Installing k3s

Warning:

This article describes the preparation, installation, and initial configuration of a Kubernetes cluster.

You are reading at your own risk. There is a non-zero chance that your life will never be quite the same afterward.

All procedures described here have been tested.

Also, no animals were harmed during the writing of this article. Unless we count two flies, six mosquitoes, and one unfortunate snail removed from a home cucumber plantation.

Hardware

The cluster consists of the following machines:

Hostname	IP Address	SBC	Architecture	RAM	Storage	Operating System	Intended Role
palladium	10.10.10.20	Odroid N2	arm64	4 GB	128 GB	Armbian	tiny-int
vanadium	10.10.10.21	Raspberry Pi 5	arm64	8 GB	512 GB	Ubuntu Server	ci-cd
iridium	10.10.10.24	Odroid M2	arm64	16 GB	512 GB	Armbian	control-plane
ruthenium	10.10.10.25	Orange Pi 5 Plus	arm64	16 GB	512 GB	Armbian	heavy-worker
tantalum	10.10.10.26	Raspberry Pi 500	arm64	16 GB	256 GB	Ubuntu Server	observability

All IP addresses are assigned by the home router using static DHCP reservations based on MAC addresses.

Operating System and Required Software

All nodes run either Ubuntu Server or Armbian based on Ubuntu Noble.

Versions may differ slightly, but package management remains identical across the cluster.

The first step is ensuring that every machine can resolve the names of every other machine.

At the moment there is no local DNS server, so each host requires an /etc/hosts entry similar to the following:

10.10.10.20 palladium
10.10.10.21 vanadium
10.10.10.24 iridium
10.10.10.25 ruthenium
10.10.10.26 tantalum

It is also worth adding the same entries to the workstation or laptop used to manage the cluster.

Windows users may perform the traditional rite of passage and figure out where Microsoft decided to hide the hosts file this decade.

Useful Tools

It is highly recommended to install kubectl on your workstation.

The official installation instructions can be found here:

https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/

On every cluster node, install a basic set of utilities:

sudo apt update && sudo apt install -y \
 curl \
 wget \
 vim \
 git \
 htop \
 net-tools \
 iproute2 \
 iptables \
 ca-certificates \
 gnupg \
 lsb-release \
 jq \
 socat \
 conntrack \
 open-iscsi \
 nfs-common \
 tmux \
 dnsutils \
 tcpdump \
 lsof \
 nc

If you prefer the Emacs lifestyle but do not enjoy “the Sixth Editor”, replace vim with mg.

You may also want:

sudo apt install mc

if navigating directories through a dual-panel interface reminds you of happier times.

On iridium, I additionally install:

sudo apt install -y sqlite3

Swap was already disabled during the preparation of the machines, but it is worth double-checking before proceeding.

Kernel Modules

Enable the required kernel modules:

cat <<EOF | sudo tee /etc/modules-load.d/k3s.conf
overlay
br_netfilter
EOF

sudo modprobe overlay
sudo modprobe br_netfilter

Then configure the required kernel parameters:

cat <<EOF | sudo tee /etc/sysctl.d/k3s.conf
net.bridge.bridge-nf-call-iptables=1
net.bridge.bridge-nf-call-ip6tables=1
net.ipv4.ip_forward=1
EOF

sudo sysctl --system

cgroups

It is also worth checking whether cgroups are properly enabled:

cat /proc/cgroups

Some systems may require additional kernel parameters in /boot/cmdline.txt:

cgroup_enable=cpuset cgroup_enable=memory cgroup_memory=1

Kubernetes

The chosen distribution is k3s.

It is fully compatible with “serious” Kubernetes while requiring significantly fewer resources, making it an excellent choice for home labs, edge computing, and IoT deployments.

Small, lightweight, easy to install, and surprisingly capable. What more could one ask for?

Control Plane

iridium has been selected as the control-plane node because it is the most powerful machine in the cluster.

The remaining nodes will join as workers with specific responsibilities.

Install k3s on iridium:

curl -sfL https://get.k3s.io | sh -s - server \
 --node-name iridium \
 --node-ip 10.10.10.24 \
 --advertise-address 10.10.10.24 \
 --write-kubeconfig-mode 644 \
 --disable traefik

Run this command directly on the machine, either through SSH or a local terminal session.

What Do These Flags Do?

--node-ip — forces a specific IP address and therefore a specific network interface.
--advertise-address — makes the API server reachable from the LAN.
--disable traefik — k3s ships with Traefik as its default ingress controller, but this cluster will use NGINX later.
--write-kubeconfig-mode 644 — creates the kubeconfig file with world-readable permissions.

That’s it.

Really.

After installation, verify that everything is running correctly:

sudo systemctl status k3s

More importantly:

kubectl get nodes

should produce something similar to:

iridium Ready control-plane

An even better command is:

kubectl get nodes -w

The -w option continuously watches for changes.

This is useful because a node that repeatedly transitions between Ready and some other state usually indicates an incomplete kernel configuration.

The most common culprits are missing overlay or br_netfilter modules.

If everything looks healthy, retrieve the cluster configuration:

cat /etc/rancher/k3s/k3s.yaml

Copy it to your workstation.

You may store it as:

~/.kube/config

or keep multiple cluster configurations separately.

For Bash:

export KUBECONFIG=~/.kube/my-cluster-config

For Fish:

set -x KUBECONFIG ~/.kube/my-cluster-config

Before using the file, edit the server address:

apiVersion: v1
clusters:
- cluster:
 certificate-authority-data: ...
 server: https://127.0.0.1:6443

Replace:

127.0.0.1

with:

10.10.10.24

You should now be able to run:

kubectl get nodes

directly from your workstation and obtain the same results.

Joining Worker Nodes

The node registration token can be found on the control-plane node:

sudo cat /var/lib/rancher/k3s/server/node-token

Use it on each worker node:

curl -sfL https://get.k3s.io | \
K3S_URL=https://10.10.10.24:6443 \
K3S_TOKEN='YOUR_TOKEN_HERE' \
sh -s - agent \
 --node-name vanadium \
 --node-ip 10.10.10.21

This example joins vanadium.

Remember to adjust both the node name and IP address accordingly.

Run the command directly on the target machine.

Once all nodes have joined, verify the cluster:

kubectl get nodes -o wide

Every node should eventually report:

Ready

Simple?

Simple.

A little time-consuming, perhaps, but there are no lengthy computations involved.

Only now is it safe to reach for your favorite book.

2026-06-22

Mon, 22 Jun 2026 20:05:00 +0200

The original version of this article was written in 2006.

Back then:

Python 2 was still alive,

distutils existed,

XEmacs was technically not dead,

and people still owned VHS tapes.

Let’s see how much of this still works in 2026.

Modules, Lies, and VHS Tapes

Sometimes you need to write Python bindings for a strange third-party library. It happens.

Sometimes you need to write the library itself. That happens too.

And sometimes you have to do all of that on Windows using GNU tools.

This article serves both as a professional tutorial and as a public service announcement suggesting that you abandon everything and move to a remote mountain cabin. Mostly because I can never remember the correct order of the steps involved.

Prerequisites on Windows

The easiest approach is to use MSYS2 and GCC.

You should have the following tools available somewhere in your PATH:

GCC
Python
dlltool

Nothing particularly exotic.

A Sample Library

Our example library is intentionally simple. It contains only two functions: one that adds two integers and one that multiplies them.

int mul2x(int x, int y)
{
 return x * y;
}

int add2x(int x, int y)
{
 return x + y;
}

Since the library is simple, let’s call it SimpLib.

Assume the source code is stored in a file called simplib.c.

Building the Library

As always, source files should first be compiled into object files.

To produce a shared library, GCC requires the -shared option.

Following Unix naming conventions, shared libraries usually have a lib prefix and a .so extension. Linking with -lname assumes the presence of a library named libname.so somewhere on the library search path. Many GNU projects ported to Windows continue to use this naming convention internally, even though the final artifact is a .dll.

Linux

gcc -o simplib.o -c simplib.c
gcc -o libsimp.so simplib.o -shared

Of course, for a single source file you could simply write:

gcc -o libsimp.so simplib.c -shared

However, once a project grows beyond a trivial example, compiling each source file separately and linking everything at the end is usually a much better idea.

Congratulations. The library has been built and is ready for use.

Cue triumphant fanfare.

Windows

Although we’re using exactly the same compiler, Windows requires one additional step.

We need to create an import library (sometimes called an interface library) that other applications can link against. This is where dlltool enters the picture.

Creating the Import Library

gcc -o simplib.o -c simplib.c
dlltool -l libsimp.lib simplib.o
gcc -o libsimp.dll simplib.o -shared

The DLL is now ready.

The import library is also ready.

Cue Windows-themed fanfare.

Header File

Providing a header file is generally considered a polite thing to do.

Other developers will appreciate not having to reverse-engineer your function declarations, and they will be less inclined to say unpleasant things about you.

#ifndef __SIMPLIB_H__
#define __SIMPLIB_H__

int mul2x(int x, int y);
int add2x(int x, int y);

#endif

Assume this file is called simplib.h.

A Sample C Program

The best way to test a library is to write a small program that uses it.

There are not many activities one can perform while fully clothed that are more enjoyable than programming, although surprisingly few people seem aware of this fact.

#include <stdio.h>
#include "simplib.h"

int main(int argc, char *argv[])
{
 printf("Adding 5 to 10: %d\n", add2x(5, 10));
 printf("Multiplying 5 by 10: %d\n", mul2x(5, 10));

 return 0;
}

Assume this program is stored as simprg.c.

Building the Sample Program

Linux

gcc -o simprg.o -c simprg.c
gcc -o simprg simprg.o -lsimp

Windows

Remember the import library:

gcc -o simprg.o -c simprg.c
gcc -o simprg simprg.o libsimp.lib -lsimp

A Brief Note About Flags

If the library is not located on the system library search path, remember to use the -L option.

Windows searches the current directory by default.

Linux does not.

For example:

gcc -o simprg simprg.o -L. -lsimp

Writing a Python Extension Module

Historical note

The code below targets Python 2.x and reflects the state of the CPython API around 2006. Modern Python 3 extension modules use a different initialization mechanism based on PyModuleDef and PyModule_Create.

The following code demonstrates Python bindings for SimpLib:

#include <Python.h>
#include "simplib.h"

static PyObject *simp_mul2x(PyObject *self, PyObject *args)
{
 int x, y, result;
 PyObject *pyresult;
 if (!PyArg_ParseTuple(args, "ii", &x;, &y;))
 {
 return NULL;
 }
 result = mul2x(x, y);
 pyresult = Py_BuildValue("i", result);
 return pyresult;
}

static PyObject *simp_add2x(PyObject *self, PyObject *args)
{
 int x, y, result;
 PyObject *pyresult;
 if (!PyArg_ParseTuple(args, "ii", &x;, &y;))
 {
 return NULL;
 }
 result = add2x(x, y);
 pyresult = Py_BuildValue("i", result);
 return pyresult;
}

static PyMethodDef SimpMethods[] = {
 {"mul2x", simp_mul2x, METH_VARARGS, "Multiply two integer values"},
 {"add2x", simp_add2x, METH_VARARGS, "Add two integer values"},
 {NULL, NULL, 0, NULL}
};
 
PyMODINIT_FUNC initsimp(void)
{
 (void) Py_InitModule("simp", SimpMethods);
}

Assume the file is called simpmodule.c.

What Is Happening Here?

Every extension module requires an initialization function.

Historically, for Python 2.x, this function was named init followed by the module name, hence:

initsimp()

The initialization function creates the module object itself.

Every function listed in the module’s method table becomes a method of that module.

In our case:

static PyMethodDef SimpMethods[]

contains:

the names visible from Python,
the addresses of the corresponding C functions,
additional flags describing how arguments are passed.

The METH_VARARGS flag indicates that Python will pass arguments as a tuple.

The binding functions themselves follow a simple pattern:

Validate input arguments.
Perform the actual computation.
Convert the result into a Python object.

Argument validation is handled by:

PyArg_ParseTuple(args, "ii", &x, &y)

The format string "ii" means:

I expect two arguments, and both of them must be integers.

If validation fails, the function should simply return NULL.

Building the return value is similarly straightforward:

Py_BuildValue("i", result);

which constructs a Python integer object.

The Python documentation traditionally recommends declaring all binding functions as static.

Building the Module

One way to build the extension is to use distutils.

Example setup.py

#!/usr/bin/env python3

from distutils.core import setup, Extension

simpmodule = Extension(
 'simp',
 sources=['simpmodule.c'],
 libraries=['simp'],
 library_dirs=['.']
)

setup(
 name='SimpLib',
 version='1.0',
 description='This is SimpLib bindings package',
 ext_modules=[simpmodule]
)

The Extension object describes:

source files,
required libraries,
library search paths.

The setup() function handles the rest.

Linux

python setup.py build

Windows

Unfortunately, Python traditionally expects Visual C++ when building extension modules.

If that doesn’t bother you, feel free to use it.

That would, however, make this article considerably shorter.

To force MinGW:

python setup.py build --compiler=mingw32

Installing the Module

Linux

python setup.py install

The extension and all required files will be installed into the appropriate Python directories.

Windows

The generated simp.pyd file should be copied into either:

Lib\site-packages

%APPDATA%\Roaming\Python\site-packages

Make sure you know which Python installation you’re targeting before copying files around.

If you happen to own Visual C++, and if the sight of it does not cause emotional distress, installation works exactly like it does on Linux.

A Short Test Program

Naturally, the best way to test the module is to use it.

from simp import *

print("Adding 212 to 384:", add2x(212, 384))
print("Multiplying 212 by 384:", mul2x(212, 384))

You should also verify that incorrect input is handled properly.

For example:

print(mul2x(212, "A tester walks into a bar"))

or:

print(mul2x(212, 384, 25))

Both cases should result in Python exceptions being raised by the argument validation code.

Final Thoughts

Keep your spirits up.

Rome wasn’t built in a day.

Neither are C libraries, Python bindings, build systems, or debugging skills.

Compilation errors, broken builds, failed tests, and nights spent chasing mysterious bugs are simply part of the profession.

The important thing is to remember that every experienced developer has been through exactly the same process.

Some of them are still going through it.

2026-06-20

Sat, 20 Jun 2026 08:15:00 +0200

What Is Emacs, and Do I Need It?

GNU Emacs is a text editor originally created by Richard Stallman for the PDP-10 platform.
GNU Emacs is a universal development environment available on Unix and Unix-like systems, Microsoft Windows, macOS, and many others.
GNU Emacs is an operating system disguised as a text editor.
GNU Emacs is a philosophy and a way of life.
GNU Emacs is a religion.

All right, let’s start over.

A Brief History

Richard Stallman, while working at MIT, became increasingly frustrated with proprietary software. Not only was it often full of bugs, but there was usually little anyone outside the vendor could do to fix them. Bug reports rarely led to meaningful improvements, and users were expected to simply accept whatever they were given.

Eventually, Stallman left MIT and launched the GNU Project, whose goal was to create a completely free Unix-like operating system.

Emacs itself began as a collection of macros for the TECO editor. After a rapid evolution, it became a standalone application and eventually one of the most influential pieces of software in the free software ecosystem. A large community of developers, thousands of articles, books, tutorials, and decades of active use suggest that Emacs still has a long future ahead of it.

Not everyone, however, was happy with the project’s leadership style. The most significant fork occurred when developers from Lucid, who wanted to use Emacs as the foundation of their development environment, split off and created Lucid Emacs. This project later evolved into XEmacs.

Incidentally, the “X” in XEmacs has nothing to do with whether the editor can run under the X Window System. Both GNU Emacs and XEmacs work perfectly well with or without X11.

Over the years, various other forks appeared, often for technical or political reasons. While some introduced interesting ideas, none managed to surpass GNU Emacs itself. XEmacs, despite its innovations, gradually lost momentum. A long period without significant releases and declining community activity eventually left the project effectively dormant. Its website still feels like a time capsule from the late 1990s, apparently untouched by mobile devices, TLS certificates, or modern web design.

What Is Emacs?

A Text Editor

At its core, Emacs is a text editor.

This remains the primary goal of the project: creating an exceptionally capable environment for editing text of all kinds. Source code, notes, books, articles, documentation, LaTeX manuscripts, configuration files—everything is ultimately text, and Emacs is designed to handle all of it.

A Lisp Interpreter and Runtime Environment

One of Emacs’ defining features is its built-in Lisp interpreter.

Through Emacs Lisp, users can extend the editor to perform virtually any task imaginable. Email clients, news readers, calendars, web browsers, file managers, games, and countless other tools are available either as part of the standard distribution or through third-party packages.

Need an AI assistant? Someone has almost certainly written one already.

Installing extensions is typically as simple as fetching the appropriate package from a repository and enabling it.

A Development Environment

For many users, Emacs serves primarily as an integrated development environment.

Support exists for an astonishing number of programming languages. Syntax highlighting, code navigation, language servers, debugging tools, build systems, version control integration, documentation generation, shells, terminals, and countless other development tools are readily available.

Whether you write C++, Go, Python, Rust, Lisp, or something more obscure, chances are that someone has already built excellent Emacs support for it.

An Environment for Markup Languages

Emacs is equally comfortable working with markup and document-oriented formats.

XML, HTML, YAML, Markdown, Org Mode, TeX, LaTeX, DocBook, and many others are all well supported. Validation, transformation, navigation, and editing tools are often available out of the box.

The live preview capabilities available for TeX and LaTeX workflows remain particularly impressive even today.

Anything You Can Convince Lisp to Do

Ultimately, Emacs is whatever you can persuade Emacs Lisp to become.

This flexibility is both its greatest strength and one of the reasons why Emacs users occasionally develop a reputation for eccentricity.

What Emacs Is Not

A Universal Solution

Emacs is an incredibly powerful tool, but it is not magic.

Installing Emacs will not automatically teach you a programming language, system administration, networking, or software architecture. It can help you work more effectively, but it cannot replace knowledge or experience.

Is Emacs for Me?

Perhaps.

Emacs may be a good fit if:

You want a consistent environment for editing, programming, writing, note-taking, and other text-oriented tasks.
You enjoy highly configurable tools.
You appreciate software that can evolve alongside your workflow.

Emacs may not be a good fit if:

Editing configuration files makes you uncomfortable.
You expect every feature to be immediately discoverable through graphical menus.
You are unwilling to invest time learning new tools.
Your primary computing activity consists of scrolling through social media feeds on a phone.

Emacs has a steep learning curve, but it rewards patience. For many users it eventually becomes much more than an editor; it becomes the environment in which a significant portion of their computing life takes place.

Whether that sounds exciting or alarming is entirely up to you.

2026-06-17

Wed, 17 Jun 2026 08:15:00 +0200

Continuation of the post Hardware and Software (I)

Odroid M2

The Odroid M2 deserves a dedicated article, as installing and configuring the operating system requires a few extra steps and a fair amount of patience.

The board vendor seems particularly fond of shipping museum-grade software as officially supported images. Personally, I am not a fan of running Ubuntu 20.04 with a 4.9 or 5.1 kernel in 2026. That is not exactly what modern workloads are looking for.

Instead, I strongly recommend using Armbian, whose developers release updates regularly. If you’re impatient, you can always build your own image.

Unfortunately, after installing the official image on an SD card, it quickly becomes apparent that Kubernetes is not particularly happy with the default kernel configuration. The kernel is built with only a minimal set of features enabled, so it is time to roll up your sleeves and build a custom version.

Storage

The Odroid M2 provides an M.2 NVMe slot on the underside of the board, making SSD installation straightforward. Simply insert the drive, secure it using the supplied screw, and enjoy your new storage.

Important: The board cannot boot directly from an NVMe SSD. You must use either an SD card or the built-in eMMC module for booting.

Take a close look at the connectors and switches on the board. One of them controls the SD/eMMC boot source selection. During installation and initial setup, leave it in the Micro SD position.

Building the System

Additional requirements: two SD cards (assuming limited prior experience and the possibility of rebuilding the image later).

Bootstrap

Start by installing the latest version of Armbian onto an SD card and booting from it.

Complete the initial system configuration (passwords, user accounts, locale, and everything else the setup wizard asks for).
Allow your user to execute sudo without a password by adding something similar to /etc/sudoers:

marcin ALL=(ALL) NOPASSWD:ALL

Install git.
Clone the build repository:

git clone --depth 1 https://github.com/armbian/build

Launch the main build script:

cd build
./compile.sh

The script handles the entire build process:

installs missing dependencies,
guides the user through the required configuration,
downloads and builds the kernel,
fetches all remaining packages,
generates a complete system image.

Configuration and Build

Important options in the configuration wizard:

Show a kernel configuration menu before compilation

The default kernel configuration is generally reasonable, but it is worth verifying that options required by Kubernetes are enabled, particularly various netfilter features.

Choose a board → odroidm2
Choose a kernel → current
Choose a release package base → noble

(resolute has recently appeared, but I have not tested it yet.)

Choose image type → Image with console interface
Choose image type (II) → Standard image with console interface

You may spend anywhere from a few minutes to several hours reviewing kernel options, which is why I recommend having a spare SD card available.

Once configuration is complete, the build system will spend quite some time compiling kernels, building packages, and assembling the final image.

During that time, you can:

go for a run,
visit the swimming pool,
ride a bicycle,
or, as a last resort, take a very long walk.

Once the build completes successfully, you should find something similar to the following in output/images:

Armbian-unofficial_26.08.0-trunk_Odroidm2_resolute_current_6.18.35.img

Yes, every locally built image automatically receives the -unofficial suffix.

Writing the Image

Since the device only provides a single SD card slot, you will need to transfer the generated image to your regular workstation and write it to the second SD card.

After that:

shut down the device,
replace the SD card,
power it on,
enjoy your shiny new system,
go through the initial configuration one more time.

Make sure the SSD is visible:

lsblk | grep nvme0

The output should look similar to:

nvme0n1

Installing the System onto eMMC and NVMe

Running from an SD card is useful for diagnostics and experimentation, but the built-in eMMC should be used for everyday operation.

To begin installation:

armbian-install

The most important choice during installation is:

boot from eMMC, root from NVMe

The installer will warn about potential data loss, create fresh partitions on both eMMC and SSD storage, and transfer the already configured system onto the SSD.

As a result, you will not need to repeat the entire setup process again.

Once installation completes:

shut down the device,
remove the SD card,
switch the boot selector to eMMC,
power the board on,
enjoy a significantly faster-booting Odroid M2.

Final System Configuration

The first thing to do is disable swap.

Check whether swap is active:

swapon --show
free -h

Typical output:

NAME TYPE SIZE USED PRIO
/swap.img file 8G 0B -2

Disable it completely:

sudo swapoff -a

If swapon --show reports something like:

/dev/zram0

then zram should be disabled as well:

sudo systemctl disable --now armbian-zram-config

Optionally remove the configuration:

sudo rm -f /etc/default/armbian-zram-config

Kubernetes does not particularly appreciate active swap devices, so it is best to disable them before proceeding further.

Your user account probably no longer has passwordless sudo access, so repeat the same sudoers modification as before.

Finally, replace your SSH keys:

ssh-copy-id marcin@odroidm2

In my case:

ssh-copy-id marcin@10.10.10.24

Voilà. The system is now ready for the next stage.

2026-06-15

Mon, 15 Jun 2026 19:15:00 +0200

This post provides a brief overview of the hardware, installation methods, and software configuration used in my home Kubernetes lab.

Hardware

The cluster currently consists of:

Odroid N2
Odroid M2
Raspberry Pi 5
Raspberry Pi 500
Orange Pi 5 Plus

Among these devices, only the Odroid N2 lacks an M.2 interface for an NVMe SSD and must rely on an SD card for storage. All the others support NVMe drives — well, almost all of them, but we’ll get to that in a moment.

I’m only interested in 2280 form-factor drives due to their lower cost and wider availability.

Let’s take a quick look at what is required to use — and boot from — an NVMe drive on each platform.

Raspberry Pi 5

The Raspberry Pi 5 supports M.2 NVMe storage through an additional PCIe expansion board (HAT). The best option in terms of price and quality is the one made by Pimoroni.

The Internet is full of installation guides, so I’ll keep it brief. The process consists of:

attaching the metal standoffs,
mounting the SSD using the supplied screw,
connecting the ribbon cable,
attaching the HAT to the underside of the Raspberry Pi.

The SSD ends up hidden inside the assembly, between the Raspberry Pi 5 and the HAT itself.

Operating System Installation

There are two ways to install the operating system: with or without an SD card. For the purposes of this project, we’re only interested in Ubuntu Server.

Method 1

The first method is straightforward:

write a standard Raspberry Pi OS image (or any other operating system) to an SD card and boot the Raspberry Pi,
verify that the system can see the SSD:

$ lsblk | grep nvme0

The command should return something similar to:

nvme0n1

Then:

install and launch rpi-imager,
select Ubuntu Server from the operating system list,
choose the NVMe drive as the target device,
start the image-writing process,
shut down the Raspberry Pi,
remove the SD card,
boot the system again.

There is no need to modify the boot order and make NVMe booting the default. It’s useful to retain the ability to boot from an SD card “just in case”.

The Raspberry Pi will still boot from the NVMe drive automatically, albeit a few seconds later. Those extra seconds are hardly a problem.

Method 2

The second method requires an M.2 to USB adapter.

In this case, the operating system image is written directly to the SSD before it is mounted onto the HAT.

Once installed, the Raspberry Pi boots exactly the same way as in the first method.

Configuration

There are two things worth doing immediately after installation:

disable swap,
create a dedicated user account, grant passwordless sudo access, and exchange SSH keys.

You can verify whether swap is enabled using:

$ swapon --show
$ free -h

If swap is active, you’ll likely see something similar to:

NAME TYPE SIZE USED PRIO
/swap.img file 8G 0B -2

Disable swap immediately:

$ sudo swapoff -a

Then remove the corresponding entry from /etc/fstab, for example:

/swap.img none swap sw 0 0

This prevents swap from being re-enabled after a reboot.

Creating a dedicated administrative user is equally simple. Assuming the new user is called marcin, add the following entry to /etc/sudoers:

# marcins and others:
marcin ALL=(ALL) NOPASSWD:ALL

Finally, exchange SSH keys:

$ ssh-copy-id marcin@raspberry-pi-5-address

In my case:

$ ssh-copy-id marcin@10.10.10.21
$ ssh-copy-id marcin@10.10.10.26

With that done, the machine is ready for automation with tools such as Ansible.

In the next installment: Odroid M2 — and there will be quite a bit to talk about.

2026-06-12

Fri, 12 Jun 2026 19:15:00 +0200

Home Kubernetes Lab

I’ve always been a fan of ARM-based single-board computers (SBCs). My journey started with a Raspberry Pi 4, which served as my primary workstation for nearly two years, followed by an Odroid N2. These are simple, reliable devices that are surprisingly versatile—even capable retro-gaming machines.

While the Raspberry Pi 4 has since been replaced by a Raspberry Pi 5, the Odroid N2 remains in active service. It hosts several lightweight databases and web applications and continues to perform flawlessly.

Over time, my collection has expanded to include:

Odroid M2 — the next generation of the Odroid product line,
Orange Pi 5 Plus,
Raspberry Pi 500 — purchased as an impulse bargain.

Hardware Overview

Hostname	palladium	vanadium	iridium	ruthenium	tantalum
SBC Model	ODROID N2	Raspberry Pi 5	ODROID M2	Orange Pi 5 Plus	Raspberry Pi 500
SoC	Amlogic S922X	Broadcom BCM2712	Rockchip RK3588S2	Rockchip RK3588	Broadcom BCM2712
CPU Architecture	4× Cortex-A73 + 2× Cortex-A53	4× Cortex-A76	4× Cortex-A76 + 4× Cortex-A55	4× Cortex-A76 + 4× Cortex-A55	4× Cortex-A76
Memory	4 GB	8 GB	16 GB	16 GB	16 GB
Storage Type	microSD	NVMe	NVMe + eMMC	NVMe	NVMe
Storage Capacity	128 GB	512 GB	512 GB + 64 GB	512 GB	256 GB
Operating System	Armbian	Ubuntu Server	Armbian	Armbian	Ubuntu Server

Retired Systems

Hostname	ferrum	thorium
SBC Model	Radxa Rock Pi S	FriendlyElec NanoPi Neo
SoC	Rockchip RK3308	Allwinner H3
Architecture	64-bit (ARMv8-A)	32-bit (ARMv7-A)
CPU	4× Cortex-A35 @ 1.3 GHz	4× Cortex-A7 @ 1.2 GHz
Memory	512 MB DDR3	512 MB DDR3
Storage Type	microSD	microSD
Storage Capacity	64 GB	64 GB
Operating System	DietPi	DietPi

Objectives

The goal of this project is to build a robust Kubernetes cluster capable of hosting both personal and widely used applications and databases. The cluster should also include a complete platform engineering stack, featuring:

comprehensive observability,
CI/CD pipelines,
GitOps-driven deployments.

Proposed Node Roles

iridium — Kubernetes control plane,
palladium — lightweight worker node and test environment,
vanadium — CI/CD workloads,
tantalum — observability stack,
ruthenium — heavy worker node for resource-intensive web applications.

Tooling

k3s — lightweight Kubernetes distribution,
Ansible — infrastructure automation and configuration management.

2026-06-06

Sat, 06 Jun 2026 16:15:00 +0200

This blog is designed to be a pragmatic engineering log. If you are passionate about open-source infrastructure, automation, and writing efficient software, you will feel right at home.

This will also be a place for retro-lovers (C64, ZX Spectrum, etc)

What We Will Explore Here

Moving forward, the content will focus on:

Software Engineering
Hardware – arm64 based SoCs and SBCs
Linux & BSD Systems
Automation & Orchestration
CI/CD
Cloud Native
Observability
Retro Gaming – hardware, software, emulation