Software on 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.

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.

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.

Software on dev@iostream.pl

Escape from the Tropics

Minimal Version

Standard Version

Full Version

RPM Packages

Tools

Minimal

Standard

Full

Building the Packages

Installing the Packages

GitHub Actions

Summary

A Window Manager Unlike Any Other

F? VWM

What Exactly Is a Window Manager?

What Does FVWM Provide?

Installation

Hello Darkness

Configuring X11

First Start

Windows

Desks and Pages

Menus and Window Information

Cutting, Bending, Soldering

Introduction

Backup

A Quick Trip Through Windows

What’s on the Plate?

Installing Windows

Initial Windows Configuration

The Second Operating System

Installing Fedora

UnsupportedPartitioningError

First Boot

Mounting the NTFS Partition

Fonts

Standard Software

Additional Software

KeePassXC

HeidiSQL

Opera

Visual Studio Code

VSCodium

Brave

Spotify

VirtualBox

A Better-Looking GRUB Menu

Enough for One Day

`UnsupportedPartitioningError`