Underneath this whole story there’s a decision almost nobody makes consciously: the filesystem. The Synology used btrfs all along. The QNAP uses ZFS. And your Linux machine, most likely, came from the factory with ext4 without anyone asking you anything. That’s what this is about.

Where the two came from

ext4 is the end of a dynasty of over three decades. ext (extended filesystem) was born with Linux itself, ext2 became the standard in the 90s, ext3 added a journal in 2001 so you wouldn’t need an epic fsck after every power loss, and ext4 arrived in 2008 with extents, delayed allocation and volumes up to 1 exbibyte. The design goal was always the same: be the default filesystem, fast, simple and predictable. It’s excellent at that. And it stopped there.

btrfs was born in 2007, at Oracle, with Chris Mason, with a completely different goal: be Linux’s answer to ZFS. Instead of writing data over data, it’s copy-on-write: every write goes to a new block and the pointers are updated cascading up the tree. That single decision is the mother of everything that matters in it.

What each one delivers, in a list:

ext4:

• journaling (consistent metadata after a crash)
• extents and delayed allocation (good performance)
• mature, stable, everywhere, every tool works

btrfs:

• copy-on-write on everything
• data and metadata checksums on every block
• instant, cheap snapshots
• independent subvolumes inside the same volume
• transparent compression (zstd, lzo, zlib)
• native RAID and scrub (verification sweep)
• snapshot send/receive for incremental backup
• reflinks (copies that don’t duplicate blocks)

The list already answers the title’s question. Let’s go piece by piece.

Even NTFS and APFS have passed ext4

And if the comparison with btrfs seems unfair, look sideways. NTFS was born in 1993, with Windows NT, already with metadata journaling and ACLs, and back in the 2000s it gained a log of every change on the volume plus shadow copies (Windows’ “Previous Versions”). APFS, which Apple launched in 2017 made for flash, is copy-on-write like btrfs: native snapshots (it’s what Time Machine uses for local restores), instant file clones that share blocks, volumes sharing the space of the same container, and per-file encryption.

Read the ext4 list again and compare: no snapshots, no data checksums, no CoW, no compression. Windows’ and Mac’s filesystems, which nobody considers examples of sophistication, protect your data better than Linux’s default, whose last big feature came out in 2008. btrfs is what puts Linux in the same generation as the other two, instead of a decade behind.

Why btrfs is far superior

What copy-on-write is, for those who never stopped to think about it

In classic filesystems, writing is destructive by definition: updating a block means writing the new content over the old one, in the same place on disk. If the machine dies mid-write, the file ends up half old, half new. The ext3/ext4 journal covers that for metadata (the directory structure doesn’t corrupt), but your data itself is left to luck.

Copy-on-write inverts the order: nothing is ever overwritten. Writing to a file allocates a new block, writes the new content there, and only when everything is safely on disk does the filesystem flip the pointers to the new version, atomically. At any instant, you have either the whole old version or the whole new version. Never a mix of the two.

What that buys in practice:

• Nearly free snapshots. The old blocks already persist by CoW’s nature; a snapshot is just the filesystem holding the root pointer of that instant, pure accounting.
• Power loss doesn’t corrupt. An interrupted write leaves the previous version intact, because it was never touched. For anyone who has lost a VM image or a database to a mid-write crash, this is worth the whole filesystem.
• Verification becomes possible. Since each block is written once and never touched again, keeping its checksum forever makes sense. It’s the base of the corruption protection I detail further down.

The cost exists and I pay it knowingly: random-write-heavy files (VM disks, databases) fragment and duplicate blocks, because each rewrite becomes a new block. For those cases you disable CoW per directory with chattr +C, which must be set before the file is created. In my layout, the VM image made with the right +C stayed healthy; the one made without became the textbook fragmentation case.

Snapshots are the feature that changes your life

A btrfs snapshot is an instant photo of a subvolume, and it costs almost nothing, because CoW already keeps the old blocks while someone references them. Creating a snapshot is a seconds operation, not hours. In practice: before every upgrade, the system takes a photo. If the upgrade breaks, you don’t “uninstall packages”: you boot back into the previous photo and you’re done. The boot recovery section, further down, shows this happening for real.

Subvolumes are the right way to organize the disk

A subvolume is an independent namespace inside the same filesystem, with its own snapshot policy. And it has a killer property: snapshots are not recursive. A child subvolume inside another is automatically left out of the parent’s snapshot.

I use this for everything. On my desktop, the cache directories that can be re-downloaded (mise, rustup, npm, opencode, AI caches) are becoming nested subvolumes inside @home: they stay in the same place for any program, but out of every snapshot. That separation alone takes 165 GiB out of snapshot scope, and the big caches (Hugging Face, yay, uv, pip) already live outside the system volume, with symlinks pointing to them: minus 148 GiB of snapshot, part already migrated and part in progress. The snapshot stays small, the restore stays fast, and whatever can be re-downloaded from the internet never enters the photo.

The real cost, measured on the new QNAP (ZFS, but the CoW math is the same): 27 hourly snapshots of a folder with almost 80 TB, and nearly all of them consume megabytes, because between one hour and the next almost nothing changed. Cheap snapshots are what let this routine exist without guilt.

Reflink deduplication

First, the caveat that matters: btrfs has no native online deduplication like ZFS (which keeps a dedup table in RAM and charges dearly for it). What it has are two practical things: reflink and offline dedup. Reflink is a copy that shares blocks: cp --reflink=auto creates a new file that points to the same blocks as the original, instant and free, and each one starts diverging only where written. In the era of dozens of checkouts, worktrees and similar builds, that saves a mountain of blocks. For retroactive dedup there are userspace tools like duperemove and bees.

Real corruption protection

Every btrfs block, data or metadata, carries a checksum. When the filesystem reads and the checksum doesn’t match, it knows the block rotted, and if there’s a second copy (RAID or metadata DUP) it self-heals. ext4 checks no data at all: bit rot passes silently until you open the file years later.

Two pieces of my configuration show what that buys in practice, and what ext4 simply doesn’t offer. The first is metadata in DUP mode. On ext4, each structure on the volume exists only once: a well-placed bad sector corrupts the directory table and the whole drive stops mounting. On btrfs, even with a single drive, every metadata block exists duplicated. The bad sector keeps existing, but the checksum flags the rotten block on read and the second copy answers in its place, without you noticing. It’s the difference between losing the volume and noting a warning in the log.

The second is the monthly scrub. ext4 never re-reads anything to check health: if a block rots, you find out the day someone tries to open that specific file, maybe years later, when there’s no fixing it anymore. The scrub is a scheduled sweep that re-reads the whole volume validating checksums, and finds the rot while it’s still small and recoverable. When the btrfs device stats counter leaves zero, it’s the siren to replace the drive before the disaster, not after.

Transparent compression, measured

Every mount on my desktop uses compress=zstd:1. Level 1 costs a few percentage points of one CPU core, and btrfs detects what doesn’t compress (model blob, video) and writes it raw, at no cost. The result, measured this week on my two new drives:

That’s 630 GB of free space on 2.2 TB: 15% more drive, paying nothing. On the initial migration the gain was even bigger, 45% on the system volume, because there was more text and less binary. Notice the table’s details: programs and libraries compress well, Docker layers compress even better (39%), text logs compress 4.5x, and AI model weights compress nothing, which is expected and costs nothing. Source code, which is what we produce the most in the AI era, compresses beautifully.

Synology uses btrfs, QNAP uses ZFS

Being fair to ZFS: for a big NAS it’s superior, and it’s what I chose for the QNAP. Native checksums and self-healing, mature RAIDZ, excellent send/receive. The price is complexity and resources: ZFS wants RAM for the ARC cache (my QNAP has 7 GB for a 174 TB pool, and I feel the lack), its online deduplication would need about 190 GB of RAM just for the table on my volume, and its provisioning model gave me a free scare when the snapshot was refused with 20 TB free (the thick vs thin story is in the NAS article).

btrfs is the right balance for a consumer machine. Light, native in the kernel, does almost everything ZFS does without demanding a storage administrator. Desktop, laptop, homelab, small or medium NAS: btrfs. Synology proved it in practice, twice: the btrfs volume survived readable with two drives out, and its snapshots saved 11 albums I deleted by mistake in the middle of the cleanup, byte by byte.

Big, serious NAS, with RAM to spare: ZFS. Everything else: btrfs. And for a personal Linux machine, it’s not even a discussion.

Boot recovery via snapshot

The feature that has saved me for real, told on both machines.

On the desktop, Omarchy configures snapper to take a snapshot before every update and limine-snapper-sync publishes each snapshot as a boot entry in Limine. New kernel won’t come up? In the boot menu you pick yesterday’s snapshot and the machine comes back as if nothing happened. On my machine the scheduled routine runs via Timeshift on cron (every boot and hourly), with snapper covering the update points: the way back is the same mechanism. (The gotcha: each snapshot entry carries the kernel image along, so a small ESP fills up fast. My 1 GB one already refused a kernel update for lack of space; the system stayed bootable on the old kernel, which is the right behavior.)

On the server, which runs openSUSE MicroOS, it’s even stronger: the whole system is transactional btrfs, and every update is a new snapshot. Last week, kernel 7.2.9 took down the NVMe controller silently, twice, in the middle of the nightly backup. The fix was a transactional-update rollback and a reboot back to 7.2.6, which ran the whole load (754 GiB of backup reads with concurrent download) without a hiccup. A kernel regression became a scheduled reboot, not a recovery all-nighter. One documented caveat: /etc lives inside the snapshot, so the rollback undoes configuration changes along with it. After any rollback, check your units again.

Maintenance is not optional (and the deleted file that won’t go away)

A modern CoW filesystem delivers a lot, but it charges two routines ext4 never asked for.

The first is the scrub, which already appeared here: re-read everything and check checksums, monthly, on all machines. It’s bit-rot detection in action, and without it the checksum only warns you about the rot when you try to read the file. The second point is subtler: a snapshot pins the blocks of deleted files. When you delete a file inside a snapshotted subvolume, the space doesn’t come back, because the block stays referenced by the photo. That’s exactly what happened on my NAS: the 2.14 TB cleanup I ran on the Synology only freed space for real after the old snapshots were removed; until then, the blocks stayed pinned.

The treatment is simple routine. Retention has to be automatic, with snapper or Timeshift deleting the old snapshots per policy (on the QNAP, the Snapshot Manager’s retention policy plays the same role). Space that doesn’t come back after deleting old snapshots is usually over-allocated chunks: a btrfs balance start -dusage=50 returns the little-used pieces to the free pool (in my house I don’t blindly schedule balance, I monitor the unallocated space and act when it gets tight). And on the restic side, forget alone only removes the snapshot’s reference: the repository space is only reclaimed with prune along, forget --prune.

House cleaning in the AI coding era

Now the part almost nobody connects with filesystems: the agent era produces garbage at industrial speed. I know because I measured.

• Rust is the biggest disk polluter in the dev world. Every build leaves behind 100 to 180 MB test binaries, and they accumulate with each edit. On my desktop, the target/ directories added up to 920 GiB. ai-memory alone accounted for 704 GiB. The hygiene tool I was using is cargo-sweep, weekly. A reader pointed out that the project declares itself unmaintained, and its own README points to cargo-clean-all, which works differently: instead of pruning old artifacts inside one target/, it finds every Rust project under a directory and deletes the whole target/ of the ones you filter, for example cargo clean-all --keep-days 7 ~ to clean only what hasn’t been compiled in a week.
• Docker is right behind. On my machine I found 1.26 TB of build cache plus 938 GB of images. A single cleanup recovered about 600 GB. On the server, the weekly cleanup collects 0.6 to 4.5 GB every Sunday.
• AI and package caches bloat quietly. The Hugging Face cache had 86 GB until I deleted three dead models and it dropped to 21. Pacman had 22 GB of outdated packages. yay, uv and pip, another 125 GB.
• And agents create temporary directories without asking permission. A complex project with several branches means worktrees, and each release worktree has its own CARGO_TARGET_DIR full of test binaries. On ai-memory that has already blown up the disk, and it became a mandatory rule in the project’s AGENTS.md: after every release, cargo clean in each created worktree and removal of finished worktrees, no exceptions.

The solution is to automate the sweeping. My minimal example, a user timer that runs on the 1st and 15th at dawn, with Nice and idle I/O:

• deletes target/ directories of projects idle for more than 14 days
• cleans the yay cache
• prunes only Docker build cache older than 30 days, never images or volumes

And the part that became standard in my house: instruct the agents to clean up what they create. Three real rules from my projects, for you to copy:

In the desktop’s AGENTS.md: “Never run broad cleanups like docker system prune without explicit user authorization after a read-only inventory. Cleanup uses an exact list of IDs; idle, old or unreferenced does not mean disposable.”

In the homelab’s CLAUDE.md: “Before finishing any task, remove the temporary things the task created, and only those. Never delete what you didn’t create or can’t attribute to the task. When in doubt, list it for the owner.”

In ai-memory’s AGENTS.md: “target/ grows without limit: every edit to a shared crate leaves behind a copy of each 100-180 MB test binary (seen at 157 GiB). Weekly cargo sweep --time 7, and mandatory cargo clean after every release.”

And the real backup: restic

A snapshot lives on the same drive, so a snapshot is not a backup: if the drive dies, the snapshot dies with it. The last item in the kit is restic, which for me is the best backup system on Linux today.

restic is a single open source binary, written in Go, that does deduplicated, encrypted and versioned backup to practically any destination: another directory, another NAS via SFTP or REST, S3, Glacier. The central trick is content-defined chunking: it slices each file into variable-size blocks defined by the content, hashes each block and only writes to the repository the blocks that don’t exist there yet. That’s why the delta is cheap: today’s backup carries the blocks that changed since yesterday, not the files that changed. Editing a 100 GB database in the middle costs a few megabytes of backup, not 100 GB again. Each run becomes a repository snapshot, a restore point you browse with restic mount as if it were a filesystem, and restic check audits the whole repository’s integrity whenever you ask.

Configuration matters more than the tool, so here’s ours, mistakes included. On the desktop, the repository lives on the NAS and retention is keep-daily 7, keep-weekly 4, keep-monthly 6, keep-yearly 1. On the server, backup runs daily at dawn to the repository on the QNAP, covering /etc, /usr/local/bin, /home and the container volumes, with the password off the machine and pg_dump before the databases, because a filesystem snapshot doesn’t guarantee consistency for a database that’s writing. The first full load was 729 GiB in under an hour, and restic crossed unharmed, on retries, the window in which the NFS mount went read-only by mistake during the migration.

The most important part of the configuration is what does not go into the backup. Our exclusions, all with a reason:

• AI model caches (Immich, Hugging Face, EasyOCR): if lost, download again;
• Prometheus metrics: history that regenerates itself;
• the Fulcrum database: reindexes from bitcoind;
• the decision classifiers’ weights: re-downloadable by revision hash (and this exclusion’s glob goes inside quotes inside the bash array, because unquoted it becomes a backup source instead of an exclusion);
• node_modules, target/, cargo registry, rustup toolchains: pure build artifacts.

And one retention lesson to close. When we shortened the server policy to “yesterday, 2 dailies, 2 weeklies and 1 monthly”, the correct translation to flags is --keep-daily 3 --keep-weekly 3 --keep-monthly 2, not 2/2/1: restic’s levels overlap, and yesterday’s snapshot is also the newest of this week and this month, so each number needs to be one more than the older points you want to keep. The detail caught us off guard: the script had a literal 2/2/1, and with it the monthly level would never hold anything older than last night. In practice, the intention was to keep 5 restore points, and 2/2/1 delivers only 3: yesterday, plus one daily, plus one weekly. We erred, measured, corrected.

A humility note from the disaster: the old repositories were left on the Synology by my decision (almost 2 TB of abandoned history, because the content was already re-covered on the new QNAP). A backup repository ages too, and revisiting its scope is part of the hygiene.

Conclusion: in the AI era, disk is not a detail

Agents coding all day change the storage math at both ends. On the volume end: builds, caches, worktrees and models fill the disk much faster than any human habit ever did, and without a cleanup routine you find out when it blows up. On the safety end: the more generated code, the more you need a cheap way back, because not every agent change is a good one.

btrfs covers both. Transparent compression gives back 15% of disk for free, and source code is exactly the kind of data that compresses the most. Snapshots and subvolumes give you instant rollback on the system and isolation for what doesn’t need protection. Checksums and scrub watch the health of blocks that ext4 simply ignores. ext4 had its 15 years of well-deserved reign. In 2026, choosing it on a new Linux is giving up protection you’ll need, sooner or later. Choose btrfs and set up the cleanup today.

You pay for a book, but you can only read it where Amazon allows. There is no decent native Linux app. Moving to another reader turns into an exercise in archaeology. I bought a new Xteink X4 and, naturally, my library couldn’t simply come along. The file was “in my account,” but it wasn’t under my control.

For years, I worked around this through the official route. I’d sign into Amazon’s website, use Download & Transfer via USB, download the .azw files for books I’d bought, and import everything into calibre. With the DeDRM plugin configured for my Kindle’s serial number, I’d convert them to EPUB and be done with it.

On February 26, 2025, Amazon shut that option down. No decent announcement, no replacement that actually handed over the file, and no concern for anyone who wanted a local backup. My newer books have been trapped in their ecosystem ever since. I tried again last year, updated the plugin, copied files from my Kindle Paperwhite, entered the correct serial number, and got nowhere.

To be fair, on January 20, 2026, Amazon began allowing verified buyers to download EPUB or PDF files when the publisher marks the book as DRM-free. Great. That doesn’t help with protected books, and the decision still belongs to the publisher. Older DRM-free titles must also be confirmed one by one by the publisher. This did not magically add a download button to my library.

I decided to try again now. The new DeDRM version can handle the current DRM, but the process has changed quite a bit. It takes work, requires Windows for one step, and relies on a community tool still in pre-release. It worked. I recovered 106 books I’d bought, tested the EPUB conversion, and can now read them on whatever device I choose.

This is the state of play on July 30, 2026 (updated August 19). Amazon could change the encryption or the app tomorrow. Ignore old tutorials telling you to install Kindle for PC 1.17, disable updates, and enter the device serial number in Calibre. That world is gone.

And let’s get the obvious out of the way: I’m talking about books I bought. I’m not talking about downloading Kindle Unlimited titles, library loans, or somebody else’s books. Laws covering DRM circumvention vary by country. Check the law where you live and take responsibility for what you do.

First things first: don’t throw out an old Kindle

Amazon doesn’t make it easy to repurpose an old Kindle either. The hardware remains perfectly good, the battery is usually replaceable, and an e-ink screen lasts forever, yet the software becomes increasingly closed and limited.

If you want to revive one of these devices, I recommend the Dammit Jeff channel. He covers jailbreaks, KOReader, alternative stores, and ways to keep Kindles useful after Amazon loses interest. His video about AdBreak and recent jailbreaks is a good place to start. Read the current Kindle Modding guide before doing anything, because supported firmware and methods change constantly.

Jailbreaking the device and removing DRM from an ebook are separate problems. You do not need to unlock your Kindle to follow the rest of this article. I mention both because they start from the same premise: hardware and media we’ve already paid for should remain useful without asking the manufacturer for eternal permission.

Crash course: AZW, EPUB, and KFX

DRM and file format are separate things. The format defines how text, images, fonts, the table of contents, and metadata are packaged. DRM adds a cryptographic lock on top and decides which account, app, or device can open it.

These are the three names that matter here:

The extension alone can be misleading. Pieces of a KFX book may show up as .azw, .azw.res, .voucher, and other variations. The KFX Input plugin exists specifically to understand that bundle.

EPUB is much less mysterious. The EPUB 3.3 specification defines it as a single-file container for structured Web content. It’s basically a small packaged website. Any halfway decent reader can support it without depending on a secret Amazon key.

Calibre and the two plugins

calibre is the Swiss Army knife of ebooks. It’s open source, runs on Linux, macOS, and Windows, organizes libraries, fetches metadata, edits covers, transfers books, and converts dozens of formats. It has been around since 2006 and was born precisely because the first Sony Reader didn’t work properly on Linux.

On Omarchy or any other Arch system, install the package:

sudo pacman -S calibre

For other distributions, see the official download page. Don’t install some random package from a download site.

One gotcha for environments using mise: if Calibre dies with ModuleNotFoundError: msgpack or BrokenPipeError, a Python shim probably got ahead of /usr/bin. The Arch package needs the system Python. Start it like this:

env PATH="/usr/bin:$PATH" /usr/bin/python3 /usr/bin/calibre

This has nothing to do with DRM or the plugins. It’s just Calibre’s helper calling the wrong Python. I left a permanent launcher with this PATH on my desktop.

Calibre alone does not remove DRM. We need two plugins:

1. DeDRM recognizes and removes locks from several ecosystems during import. It only runs when the book enters the library. Clicking Convert afterward removes nothing.
2. KFX Input understands Amazon’s modern containers, gathers the pieces of a book, and makes EPUB conversion possible.

At the time of writing, I’m using DeDRM 10.0.28, published on July 14 in the fork maintained by Satsuoni. It is a pre-release. Download the asset named DeDRM_tools.zip, never a standalone executable from some obscure mirror.

Update (August 2026): the Kindle app on the Microsoft Store keeps moving, and each new app version requires a new version of the tool. Since this article was published, the app moved past 1.0.18632: 10.0.29 added support for app 1.22326, and 10.0.30 supports app 1.0.22920. The practical rule is a single one: the executable’s name carries the app version it understands (MSIXKFXArchiverMobi1_22920.exe for Store app 1.0.22920, and so on). Before you start, always check the releases page of Satsuoni’s fork and grab the newest pre-release. Everything else in the process described here stays the same.

I extracted everything into a directory that would later be shared with the Windows VM:

mkdir -p ~/Windows/Kindle-DeDRM/v10.0.28
unzip ~/Downloads/DeDRM_tools.zip -d ~/Windows/Kindle-DeDRM/v10.0.28

The SHA-256 for the DeDRM_tools.zip I used was:

520cce704edf9ae26e43196efe2871daf9b25d6cb489aa56051626801c362947

Check it with sha256sum. This doesn’t magically turn a community binary into safe software, but it at least confirms that you’re using the same file I tested.

Inside that directory is DeDRM_plugin.zip. Do not extract this second ZIP. In Calibre, open Preferences → Plugins → Load plugin from file, choose DeDRM_plugin.zip, accept the warning, and restart the program.

Then go back to Preferences → Plugins → Get new plugins, search for KFX Input, and install it. My test used version 2.33.0. Restart again.

Why copying from the Kindle over USB didn’t work

The simplest path would still be plugging in my new Kindle Paperwhite, copying the book, and configuring the device serial number in DeDRM. That was the first thing I tried.

The file came in as KFX-ZIP, the plugin ran, but it remained encrypted. I opened Calibre in debug mode and the log showed that the book used the ACCOUNT_SECRET strategy. The serial number was correct. The required key no longer came from the device alone.

That’s why so many people follow an old tutorial, try five different serial numbers, and conclude that DeDRM is broken. New books with this DRM need the secret stored by the current Kindle app on Windows. That secret is protected by TPM APIs.

A disposable Windows inside Omarchy

I’m not keeping a dual-boot setup just to download ebooks. I’m also not going to pretend Wine runs everything. Fortunately, Omarchy already ships with everything needed to install and launch a Windows VM: it appears in the Omarchy menu, opens over RDP, and automatically shares ~/Windows with the guest. I didn’t have to build this integration from scratch.

Underneath, it uses dockur/windows. Dockur packages QEMU/KVM inside a container and automates the Windows installation. It remains a real virtual machine with its own disk and kernel. The container handles distribution, configuration, and lifecycle.

To install it from the terminal, run:

omarchy-windows-vm install

Choose the RAM, CPU count, and disk size. The installer creates ~/.config/windows/docker-compose.yml, stores the virtual disk in ~/.windows, and shares ~/Windows with the guest. Inside Windows, that directory appears as Shared, usually on Z:, and is also available at \\host.lan\Data.

The detail that mattered in my case was enabling TPM 2.0. Edit the generated Compose file and add TPM: "Y" to the environment block:

services:
  windows:
    image: dockurr/windows
    environment:
      VERSION: "11"
      TPM: "Y"

Then recreate the container. The Windows disk remains in the persistent volume:

omarchy-windows-vm stop
omarchy-windows-vm launch -k

The -k keeps the VM running after you close RDP. You can also watch it boot in a browser at http://127.0.0.1:8006.

Downloading the books with the right app

Inside Windows, open the Microsoft Store and install Amazon Kindle: Reading App, product 9P8JQ0JJSTLL.

Pay attention here. The old Kindle for PC installer found on blogs is not the same app. The tool I used looks for the Microsoft Store package AMZNKindle.AmazonKindleReadingApp. With the legacy program, it simply replies No AmazonKindleReadingApp installation found.

Sign in to your account and download every book you want to preserve. Opening the cover or seeing the title in your library isn’t enough. The content must be available offline inside the app.

Unfortunately, the most annoying part is still manual. Amazon found room for a one-click purchase button, but apparently not for a “download everything I’ve paid for” button.

I did this for 106 books. Yes, it was a pain in the ass.

Generating KFX-ZIP files and the K4I key

The DeDRM_tools.zip we extracted on Linux is already visible in Windows through the shared directory. Open PowerShell and switch to that directory:

cd \\host.lan\Data\Kindle-DeDRM\v10.0.28
.\MSIXKFXArchiverMobi1_18632.exe

The banner may still mention an older 1.0.15230 build. The versioned executable above looks for Store app 1.0.18632, and that’s the one that worked for me. The number in the file name must match your app version: if the Store already delivered a newer one, download the matching release from the project’s page (see the update in the plugins section).

This executable finds the current Microsoft Store app’s cache, gathers each book’s components, and produces two things:

• archived_kfx/, containing one .kfx-zip for every downloaded ebook;
• oldbooks.k4i, the keyfile DeDRM needs to open those files.

On my machine, the process found and archived 106 books. The SHA-256 of the executable I ran was:

0c78b45ccea2c36a5fbb01b9f66bdd9e5d5960a68a340ba2ee96e138f5cddf4a

It is a 32-bit binary. If it complains about a missing MSVCP140.dll, install the official Microsoft Visual C++ Redistributable x86. Do not hunt for a loose DLL on Google. That’s a great way to turn a book backup into a malware backup.

The oldbooks.k4i file is sensitive. It is derived from your account secret in that Kindle installation. Do not publish it, attach it to a GitHub issue, screenshot its contents, or put it in a public repository.

Configuring the key in DeDRM

Back on Linux, open Calibre and follow this path:

Preferences → Plugins → DeDRM → Customize plugin → Kindle for Mac/PC ebooks → Import Existing Keyfiles

Select:

~/Windows/Kindle-DeDRM/v10.0.28/oldbooks.k4i

Use Import Existing Keyfiles. Do not use the generic Set Keyfile button on the main screen. It records a different kind of key candidate and does not register the K4I key in the right place.

Close the key list, click OK in the main configuration window, and restart Calibre. If you close it with Cancel, it quietly throws the change away.

Importing and converting to EPUB

Before dumping a hundred files into the library, test one.

Choose a .kfx-zip from:

~/Windows/Kindle-DeDRM/v10.0.28/archived_kfx/

Use Add books in Calibre. Internally, the order is:

1. KFX Input recognizes the package;
2. DeDRM tries the K4I keys during import;
3. KFX Input assembles the decrypted book as KFX;
4. Calibre can now open and convert the result.

If the format still appears as KFX-ZIP, it failed. Clicking Convert ten times won’t help. Remove that entry from the library, fix the plugin or key, and import it again. DeDRM only acts on input.

When the book appears as KFX, open it in the viewer and check a few pages. Then click Convert books, choose EPUB as the output, and test the resulting file on the reader you plan to use. Only then should you run the batch import.

In my case, the KFX opened, converted, and the EPUB worked outside Kindle. That told me the entire path was working: Microsoft Store, TPM, archiver, K4I, DeDRM 10.0.28, and KFX Input 2.33.0.

Back up what actually matters

After the conversion, I preserve three things:

• the final EPUBs, which I can read on any device;
• the original KFX-ZIP files, until I’ve verified that every EPUB is intact;
• oldbooks.k4i, encrypted and stored separately from the library.

My plaintext keyfile has 0600 permissions. I also keep an encrypted copy using SOPS and age, with the private key in a separate backup. Do not put a raw oldbooks.k4i in Git just because the repository is private. Private repositories leak too.

The EPUBs follow the same strategy I use for other important files: a local copy, NAS, and off-site backup. I explained this paranoia in Protecting and Recovering Lost Data and showed the same philosophy applied to movies in My Personal Netflix.

Do not delete files from the Kindle or the VM the minute conversion finishes. Open the EPUBs and check the cover, table of contents, images, notes, and a few pages. A backup you’ve never tested is just wishful thinking.

Conclusion

Amazon has remotely deleted books, publishers update covers and content, old apps stop working, and formats change. The end of Download & Transfer via USB proved that a feature available for eighteen years can disappear with one line in a notice.

The classic example is still unbelievable: in 2009, Amazon deleted 1984 and Animal Farm by George Orwell from customers’ Kindles. Later, revisions to Roald Dahl, R.L. Stine, and Agatha Christie were pushed into digital copies people had already bought. The Vice article summarizes those cases. Dammit Jeff makes the same point often: even the original cover you chose can turn into an ugly poster for the streaming adaptation because the publisher and store decided to update your “purchase.”

It doesn’t matter whether the next change is censorship, a legitimate correction, another horrible Netflix adaptation cover, or a plain bug. I bought an edition. I want to preserve the edition I bought.

DRM does not stop piracy. A popular book lands on torrents the day it comes out. DRM only gets in the paying customer’s way, makes accessibility harder, locks up perfectly good hardware, and turns a purchase into an indefinite rental.

Calibre, DeDRM, KFX Input, and a disposable VM gave me my library back. I can now put those EPUBs on the Xteink, a Kobo, a tablet, my phone, or a reader that doesn’t even exist yet. I can switch operating systems and turn off the internet. The files stay with me.

If it isn’t on your machine, it isn’t yours.

Ayub posted on X that this has all the usual signs of a national block ordered by Anatel against api.github.com. In that same context, the tweet he quoted showed api.github.com resolving to 4.228.31.149, but with no working route. The author said he tested through VIVO, Claro, and Oracle, and that it only worked through a Miami VPN. In other words: this does not look like “my Wi-Fi is down.” It looks like a block somewhere in the path.

According to Ayub, this kind of thing often happens in blocking waves, many times after Wednesday meetings with large carriers, inside the Brazilian mechanism for blocking addresses under the excuse of fighting piracy. The problem is the blast radius: instead of taking down only the target, it breaks legitimate infrastructure. Today it was the GitHub API. Tomorrow it can be anything your work depends on.

And yes, I confirmed it from here.

How to know if you were affected

First, test whether the main site opens:

curl -4 -I --connect-timeout 8 --max-time 12 https://github.com/

Here it worked. Then test the API:

curl -4 -I --connect-timeout 8 --max-time 12 https://api.github.com/

Here I got:

curl: (28) Connection timed out after 8002 milliseconds

Now check which IP your system resolves:

getent ahostsv4 api.github.com

In my case:

4.228.31.149    STREAM api.github.com
4.228.31.149    DGRAM
4.228.31.149    RAW

And gh depends on this API too. So commands like these may hang:

gh api rate_limit
gh pr list
gh issue list

If you are a developer and suddenly gh stopped, your release scripts stopped, your PR-listing bot stopped, or some CLI that queries issues started hanging, this may be it. It is not your bug. Your route to api.github.com is being thrown into a hole.

First try DNS 9.9.9.9

Some people mentioned that changing DNS to Quad9, 9.9.9.9, could work around it. It makes sense to test, because some blocks are done through DNS: the provider returns the wrong IP, NXDOMAIN, or sends you into a sinkhole. If the problem is only your provider’s DNS, changing DNS fixes it.

Test without changing anything in the system:

dig @9.9.9.9 +short api.github.com A

In my case, it did not help. Quad9 also returned:

4.228.31.149

And forcing that IP in curl still timed out:

curl -4 -I --connect-timeout 8 --max-time 12 \
  --resolve api.github.com:443:4.228.31.149 \
  https://api.github.com/

Result:

curl: (28) Connection timed out after 8002 milliseconds

So, on my link, 9.9.9.9 did not fix it. But test yours. If your provider is only poisoning DNS, it may work.

On Arch with NetworkManager, it would be something like this:

sudo pacman -S bind-tools curl

nmcli con show --active
sudo nmcli con mod "YOUR CONNECTION NAME" \
  ipv4.ignore-auto-dns yes \
  ipv4.dns "9.9.9.9 149.112.112.112"
sudo nmcli con down "YOUR CONNECTION NAME"
sudo nmcli con up "YOUR CONNECTION NAME"

On Ubuntu, same idea. Install the tools and adjust through NetworkManager:

sudo apt install dnsutils curl
nmcli con show --active

Or use the GNOME/KDE network settings screen and set manual DNS to 9.9.9.9 and 149.112.112.112 for the connection. Then disconnect and reconnect.

Test again:

dig +short api.github.com A
curl -4 -I --connect-timeout 8 --max-time 12 https://api.github.com/

If it works, good. You are done here.

If it keeps timing out, DNS was only the first layer. Then you need to route the connection through another path.

Why I do not like the fixed-IP hack

Another suggestion I saw was manually adding IPs to local DNS, like Pi-hole, Unbound, /etc/hosts, dnsmasq, that sort of thing. Example: “resolve api.github.com to this other IP that works.”

That can work for a few hours. I don’t like it.

GitHub is large infrastructure. IPs change. Routes change. Load balancing changes. Regions change. The IP that works for somebody in Miami may be bad for you in São Paulo. The IP that works today may fail tomorrow. And if the block is a blackhole route at the provider, changing DNS to another IP may only trade one hole for another.

Pi-hole is great for a home network. Unbound is great. /etc/hosts saves you in an emergency. But pinning the IP of a large service like GitHub is how you forget an invisible hack and lose two hours next month trying to understand why only your machine is broken.

Use alternate DNS as a test. Use fixed IP only as a temporary bandage and document where you changed it.

Fallback: SOCKS proxy only for GitHub tools

My solution was the least invasive thing I could make: a wrapper that starts a local SOCKS proxy through Tor and runs only the command I choose through it. It does not route the whole system. It does not touch the browser. It does not affect package managers, Steam, banking, nothing. Just gh, or whatever tool I explicitly call.

In my case, the wrapper lives at ~/.config/zsh/bin/github-proxy, and the alias in ~/.config/zsh/aliases does this:

alias gh='$HOME/.config/zsh/bin/github-proxy gh'

The wrapper is this:

#!/bin/bash
set -euo pipefail

proxy_host="127.0.0.1"
proxy_port="9050"
tor_dir="${XDG_RUNTIME_DIR:-/tmp}/github-proxy-tor"
tor_rc="$tor_dir/torrc"
tor_log="$tor_dir/tor.log"

if [[ $# -eq 0 ]]; then
  echo "usage: github-proxy <command> [args...]" >&2
  exit 2
fi

if ! ss -ltn "sport = :$proxy_port" | grep -q "$proxy_host:$proxy_port"; then
  mkdir -p "$tor_dir"
  : >"$tor_rc"
  tor -f "$tor_rc" --SocksPort "$proxy_host:$proxy_port" --DataDirectory "$tor_dir/data" >"$tor_log" 2>&1 &

  for _ in {1..60}; do
    if grep -q 'Bootstrapped 100%' "$tor_log"; then
      break
    fi
    if ! kill -0 "$!" 2>/dev/null; then
      echo "github-proxy: tor exited before bootstrap; see $tor_log" >&2
      exit 1
    fi
    sleep 1
  done

  if ! grep -q 'Bootstrapped 100%' "$tor_log"; then
    echo "github-proxy: timed out waiting for tor bootstrap; see $tor_log" >&2
    exit 1
  fi
fi

export HTTPS_PROXY="socks5h://$proxy_host:$proxy_port"
export HTTP_PROXY="socks5h://$proxy_host:$proxy_port"
export ALL_PROXY="socks5h://$proxy_host:$proxy_port"

exec "$@"

Notice socks5h. That h matters. It makes DNS resolution happen through the proxy, not through your local network. If you use plain socks5://, depending on the library, DNS may still happen locally before the proxy is used. With socks5h://, the idea is: “take the hostname to the other side and resolve it there.”

Installing on Arch

On Arch:

sudo pacman -S tor github-cli iproute2
mkdir -p ~/.local/bin

Create the script:

nano ~/.local/bin/github-proxy

Paste the wrapper above and make it executable:

chmod +x ~/.local/bin/github-proxy

Test it directly:

~/.local/bin/github-proxy gh api rate_limit --jq .resources.core.limit

An authenticated account usually returns:

5000

That is what happened here. Direct timed out. Through the wrapper, gh api rate_limit --jq .resources.core.limit returned 5000.

Now add an alias to your shell.

ZSH:

echo "alias gh='$HOME/.local/bin/github-proxy gh'" >> ~/.zshrc
source ~/.zshrc

Bash:

echo "alias gh='$HOME/.local/bin/github-proxy gh'" >> ~/.bashrc
source ~/.bashrc

Test:

gh api rate_limit --jq .resources.core.limit
gh pr list

Ubuntu

On Ubuntu, the Tor package is easy:

sudo apt update
sudo apt install tor iproute2 curl

For GitHub CLI, if the gh package is available in your version:

sudo apt install gh

If it is not, follow the official GitHub CLI installation for Ubuntu/Debian. The rest is the same: create ~/.local/bin/github-proxy, run chmod +x, and put the alias in .bashrc or .zshrc.

Better alternatives than Tor

Tor worked and it is convenient, but it is not the only option. Sometimes it is slow. Sometimes a service dislikes Tor exits. For gh api and listing PRs, fine. For heavier use, you may want something more predictable.

Reasonable options:

• Normal VPN: Proton, Mullvad, IVPN, your own WireGuard. Route everything or use split tunneling if you know how to configure it.
• Tailscale with an exit node outside Brazil: clean, if you have a trusted machine outside the country or a VPS.
• SSH SOCKS to a VPS: ssh -N -D 127.0.0.1:9050 user@your-vps. Then use the same HTTPS_PROXY=socks5h://127.0.0.1:9050.
• Corporate proxy: if your company has egress outside Brazil, configure only the tools that need it.

The care here is not changing everything at the same time. First prove that direct api.github.com fails. Then prove that another path works. Only then automate.

Adjusting your own tools: ghpending

This block also hit one of my utilities: ghpending. I already wrote about it in “I Built a CLI to Check My GitHub Pending Stuff: ghpending”. It lists open issues and pull requests across my repositories, so I know where somebody is waiting for an answer.

The problem is obvious: it uses the GitHub API. If api.github.com falls into a hole, it falls with it.

So I added a proxy fallback. ghpending now reads GITHUB_TOKEN like before, but also tries to use a SOCKS proxy in this order:

1. GHPENDING_GITHUB_PROXY, if you want to force a specific proxy.
2. HTTPS_PROXY, https_proxy, ALL_PROXY, or all_proxy, if they are socks5:// or socks5h://.
3. A local SOCKS proxy at 127.0.0.1:9050, if one is listening.
4. If none of that exists, it tries direct access.

In the README, it looks like this:

GITHUB_TOKEN=$(gh auth token) ghpending

And for proxy:

GHPENDING_GITHUB_PROXY=socks5h://127.0.0.1:9050 ghpending

Or just run it through the wrapper:

~/.local/bin/github-proxy ghpending

My wrapper starts Tor on 127.0.0.1:9050; ghpending detects that proxy and uses it for API calls. If you are not blocked, it keeps working directly. If you are blocked, it has an escape route.

This is the kind of fallback every Brazilian dev should now consider for tools that depend on foreign APIs. It is ugly, but the Brazilian internet is getting unpredictable.

The political problem

At the end of the thread, Ayub reminded everyone that, because of these secret collateral blocks and their side effects, there would already be around 250 million addresses blocked on the Brazilian internet. He also linked a presentation about the state of blocking in Brazil. In another tweet in the same thread, he says authorities defend secrecy as the only alternative left to fight crime.

I do not buy that excuse.

Secret blocking of critical infrastructure, with no transparency, no public adversarial process, no auditable list, no explanation of scope, is operational censorship. In my read, it is illegal precisely because it dodges the public, auditable process that should exist when the State orders internet access to be broken. Maybe it started with pirate TV boxes. Maybe the speech sounds noble. But the mechanism is there: somebody presses a button, carriers apply the block, legitimate users only find out when a work tool stops.

Today, the collateral damage hit honest developers trying to work with GitHub. Tomorrow it hits a Linux package, a container registry, a CDN, a payment API, an authentication service. Then everybody runs to VPNs, Tor, proxies, alternate DNS, /etc/hosts, Pi-hole. Congratulations: little by little, we are rebuilding the survival manual for a censored internet.

No need to overdo the metaphor. Brazil is not China yet. But the smell is the same: centralized opaque blocking, collateral damage, and ordinary users having to learn bypasses to work.

If you were affected, document it. Run the commands. Save outputs. Open an issue with your provider. Complain with data. Share workarounds, but do not normalize this. A bypass is a bandage. The real problem is a State giving itself the power to silently break pieces of the internet.

And if all you wanted was to run gh pr list to review a pull request: welcome to Brazilian infrastructure in 2026.

Email has always been the most annoying piece of this puzzle. My old workflow was to open Thunderbird, let it pull everything from Gmail over IMAP, and back up the ~/.thunderbird directory. Works, but it’s manual, tedious (remembering to open Thunderbird every so often), and locked to Thunderbird itself: if I want to read those emails in another client, they’re sitting in some proprietary internal format.

After a while it clicked: Linux has had native email support forever. The modern protocols (IMAP, SMTP) are open standards. And the local storage format, Maildir, has been around and working well since the 90s. Thunderbird isn’t needed for any of this.

What is Maildir

Maildir was created by Daniel J. Bernstein (djb) as part of qmail in 1995. The idea was to fix the file-locking pain of the mbox format, where the entire mailbox is a single file and two processes writing at the same time could corrupt the whole thing. In Maildir, each message becomes a separate file inside a three-subdirectory structure:

• tmp/ — where the email is written while being delivered
• new/ — newly arrived messages, not yet seen
• cur/ — messages the client has already seen, with flags encoded in the filename (:2,S = seen, :2,F = flagged, etc.)

Delivery is atomic: the MTA writes the message into tmp/, then does a rename() into new/. rename() on a POSIX filesystem is atomic, so there’s no corruption window. No locking, no corruption, and every email is just a plain-text file you can read with cat, index with grep, or version with git if you feel like it.

Thirty years later, it’s still the default local format for most Linux email clients. And it’s the format I’ll use to mirror Gmail.

The tool: mbsync (isync)

The bridge between Gmail’s IMAP and the local Maildir is mbsync, the binary in the isync package. It reads a simple config (~/.config/isyncrc), connects to Gmail’s IMAP, and copies the messages to disk. What makes it different from offlineimap (the better-known alternative) is that mbsync is written in C, it’s significantly faster on large mailboxes, and it has fewer weird edge cases with Gmail.

The config is straightforward. Here’s a sketch of what my ~/.config/isyncrc looks like (no password, obviously):

IMAPAccount my-account
Host imap.gmail.com
User you@example.com
PassCmd "/home/akitaonrails/.config/mbsync/bin/mbsync-password you@example.com"
TLSType IMAPS
CertificateFile /etc/ssl/certs/ca-certificates.crt
AuthMechs LOGIN

IMAPStore my-remote
Account my-account

MaildirStore my-local
SubFolders Verbatim
Path ~/.local/share/mail/mbsync/you.example.com/
Inbox ~/.local/share/mail/mbsync/you.example.com/INBOX

Channel my-backup
Far :my-remote:
Near :my-local:
Patterns * !"[Gmail]/Trash" !"[Gmail]/Spam" !"[Gmail]/Drafts"
Create Near
Sync Pull New Flags
Expunge None
Remove None

Three things worth flagging in that config:

1. Sync Pull: only pulls from the server to local. Nothing I do in the Maildir propagates back to Gmail. That’s accident protection (if I delete a file locally, it doesn’t disappear from Gmail).
2. Expunge None + Remove None: if a message disappears from Gmail (someone deleted it or Google decided to move it nowhere), it stays in my Maildir. The backup accumulates history, it doesn’t mirror the current state.
3. PassCmd instead of a plaintext password: the password goes through a script that does secret-tool lookup against the desktop keyring. No password sitting in a config file on disk.

The password block

The mbsync-password script is a tiny wrapper that isolates the secret:

#!/usr/bin/env bash
set -euo pipefail
account="${1:?usage: mbsync-password ACCOUNT}"
password="$(secret-tool lookup service mbsync account "$account" 2>/dev/null || true)"
[ -z "$password" ] && { echo "missing keyring secret for $account" >&2; exit 1; }
printf '%s' "$password"

The password gets stored once with secret-tool store --label="mbsync gmail" service mbsync account you@example.com. Modern Gmail requires a specific app password (16 characters, generated at myaccount.google.com/apppasswords) because it no longer accepts plain basic auth — you don’t paste your Google password there, you paste a key generated exclusively for the app, revocable any time without touching the rest of your account.

Automation with a systemd user timer

To avoid running mbsync by hand, I set up two systemd user units. First the service, which is just a call to the wrapper script:

# ~/.config/systemd/user/mbsync-backup.service
[Unit]
Description=Mirror Gmail accounts locally with mbsync
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
ExecStart=%h/.config/mbsync/bin/mbsync-run

And the timer that fires the service periodically:

# ~/.config/systemd/user/mbsync-backup.timer
[Unit]
Description=Run mbsync periodically

[Timer]
OnBootSec=10m
OnUnitActiveSec=30m
Persistent=true
Unit=mbsync-backup.service

[Install]
WantedBy=timers.target

OnBootSec=10m waits 10 minutes after boot before the first run (avoids fighting with network-online early in the session). OnUnitActiveSec=30m refires 30 minutes after each run completes. Persistent=true makes the timer catch up: if the machine was off when it would’ve fired, it runs at the next boot instead of skipping. The wrapper itself grabs flock so two mbsync runs never overlap, so if a sync ever takes longer than 30 minutes the next one just waits. Everything logs to ~/.local/state/mbsync/mbsync.log.

To manage the timer, the basic commands:

# Re-read the unit files after creating/editing
systemctl --user daemon-reload

# Start now + enable for the next boot
systemctl --user enable --now mbsync-backup.timer

# Check whether the timer is active and when it fires next
systemctl --user status mbsync-backup.timer
systemctl --user list-timers mbsync-backup.timer

# Trigger an immediate sync without waiting for the interval
systemctl --user start mbsync-backup.service

# Tail the logs in real time
journalctl --user -u mbsync-backup.service -f

# Inspect the status of the last service run
systemctl --user status mbsync-backup.service

# To shut the whole thing down
systemctl --user disable --now mbsync-backup.timer

For the timer to keep running when you’re not logged in (handy on a desktop that stays up 24/7), enable linger once: sudo loginctl enable-linger $USER. Without that, user units only run while you have an active session.

Enable it, check the status once to make sure it’s green, and forget it exists.

Backing up the Maildir with restic

Now that Gmail is mirrored under ~/.local/share/mail/, it rides into the same backup pipeline as the rest of my home directory. I use restic to push encrypted snapshots to the NAS. Restic is incremental via content-addressable storage, so adding 100MB of email to today’s snapshot costs basically the delta, not the full 100MB every time. For the off-site copy, my Synology NAS already has the Glacier Backup package built in, which handles pushing encrypted snapshots to AWS Glacier without me having to configure anything beyond the bucket and the key. The Maildir rides along on the same plan, so the off-site backup is essentially free in terms of extra configuration.

Maildir is friendly to incremental backup by construction: every email is an immutable file (the filename doesn’t even change after download, except for the seen/flagged flag bit). Restic dedups perfectly. A 5GB mailbox snapshot has near-zero marginal cost after the first one.

The open-format upside: many clients

Here’s the part that sealed it for me. Maildir is an open standard, so any client that speaks Maildir reads the same backup. I can:

• Open it in mutt or neomutt when I want something quick in the terminal.
• Open it in aerc when I want a more modern TUI.
• Point Thunderbird or Claws Mail at ~/.local/share/mail/... when I want a GUI.
• Migrate to a different client down the road without an export/import dance.

The emails are mine. They live on my disk. In a plain text format, readable by anything.

Bonus: scripts and bots read directly

A less obvious consequence: if I want to build a filter, a bot, a classifier, or anything that touches the emails, I don’t need to go through Gmail OAuth, create a Google Cloud project, manage refresh tokens, deal with quotas — none of it. I just read the Maildir.

Python has native Maildir support in the standard library’s mailbox module. A trivial example to list subjects from the inbox:

import mailbox
from email.header import decode_header

inbox = mailbox.Maildir("/home/akitaonrails/.local/share/mail/mbsync/you.example.com/INBOX")

for key, msg in inbox.iteritems():
    subject = msg.get("Subject", "")
    sender = msg.get("From", "")
    # decode_header handles Subject in UTF-8 / latin-1 / etc
    decoded = "".join(
        part.decode(enc or "utf-8") if isinstance(part, bytes) else part
        for part, enc in decode_header(subject)
    )
    print(f"{sender[:40]:<40}  {decoded[:60]}")

Runs in milliseconds, consumes zero API quota, has no rate limit, never needs a credential refresh. It’s just file reads. If you want to build something more serious (attachment parsing, LLM-based classification, automated rules), the same principle holds.

Summary

The combination that finally let me relax about this:

• mbsync (isync) pulls from Gmail’s IMAP into a local Maildir, automatically via a systemd timer.
• Maildir keeps the open format, one file per email, pull-only protects against accidental deletion.
• restic snapshots the Maildir to the NAS with ridiculous deduplication, and Synology’s Glacier Backup carries that off-site as an encrypted copy.
• Free choice of mail client — mutt, neomutt, aerc, Thunderbird, Claws, anything reads it.
• Light automation — bot or script reads straight off disk, no OAuth, no API.

Gmail becomes just a convenient web interface for reading and replying. The real ownership of the emails sits on my disk, replicated to the NAS, replicated to an encrypted off-site backup. If Google shuts my account down tomorrow (it’s happened to people), I lose the interface but keep the entire history. For me, this is the definitive way to handle it. Recommended.

This post inaugurates an experimental project I’ve been hacking on for the past few weeks: NW-Omarchy. The pitch is easy to explain and stubborn enough to be worth defending: take the opinionated, pretty look-and-feel of Omarchy (which is Hyprland, meaning Wayland) and bring all of that to the X11 world, as a parallel session you pick at SDDM. Your Hyprland session stays untouched. When you want to try X11, pick nw-bspwm at login and land in something that looks like the same Omarchy with different parts underneath.

The obvious question is “why bother”. Red Hat already announced in 2025 that upstream xorg-server is gone from RHEL 10, and the corporate Linux narrative shifted to “use Wayland and move on”. As usual, in open source we don’t have to agree. There’s XLibre, a fork of xorg-server picking up active maintenance, and there are plenty of people with old hardware, legacy drivers, or legacy software for which Wayland still isn’t a viable path. NW-Omarchy is for that scenario: give that gear a graceful second wind and, while you’re at it, make it pretty.

What XLibre is and why it matters

XLibre is a fork of xorg-server that started in 2025, after it became clear upstream had no energy left to evolve. X.Org itself was only taking critical security patches, and the historical primary funder of new development (Red Hat) announced it was stepping out of new X-server work as part of the RHEL 10 plans. XLibre took the codebase and went back to cleanups, security fixes, modernization and driver-ABI bumps. The first public release was XLibre 25.0, and the project lives at github.com/X11Libre/xserver.

XLibre’s technical pitch is being a drop-in replacement for xorg-server. Same X11 protocol, same client API (libxcb/libx11), same dependency graph in pacman. Your xterm, your Firefox, your Steam, your favorite emulator for arcade machines from the 90s, none of them know the X server changed. Distros already shipping XLibre as default or tier-one:

• Artix Linux (2026.04+) ships it as the default X server.
• Fedora has an open Change proposal to migrate.
• Arch Linux has an official binary repo at x11libre.net/repo/arch_based/. That’s exactly what NW-Omarchy uses.

Comparing what’s still alive:

If your reason for staying on X11 is any of the classics (legacy proprietary Nvidia driver, vintage Intel GPU, Optimus laptop with quirky muxing, dependency on xdotool/wmctrl/xprop/xinput for accessibility or remap tools, ssh -X to run a remote app, clipboard with no permission prompt, screen reader that needs to read input from any window), XLibre is the path that keeps that stack under active maintenance.

Why this project exists

I run Omarchy on my Thinkpad T14 Gen 6 (wrote about it here) and I genuinely like it. DHH did serious curation work: a single coherent theme across everything (terminal, launcher, top bar, lockscreen), consistent shortcuts, visual choices that don’t tire your eyes. It’s opinionated the right way, and it spares you the fatigue of configuring everything from scratch.

The catch is that Omarchy is Hyprland, Hyprland is Wayland-only, and Wayland still has scenarios where it’s the wrong tool for the job. Older machines with legacy Nvidia drivers, environments leaning on software with deep X11 integration, situations where you want ssh -X and don’t want to learn waypipe, or just machines you want to keep running without swapping half the stack. For those cases, I wanted Omarchy’s aesthetic and workflow on top of X11. It didn’t exist. So I built it.

The name NW-Omarchy is short for “Not Wayland Omarchy”. It’s deliberately a sidecar: runs alongside, doesn’t replace. You install it on top of an existing Omarchy install, it creates a separate SDDM session called nw-bspwm, and nothing in your Hyprland setup gets touched. Want to go back to Hyprland? Pick Hyprland at SDDM next login. Want to uninstall? There’s an uninstall script that reverses exactly what got installed, based on a manifest that tracks every action.

What changes in the stack (Wayland → X11)

Hyprland is compositor + WM in the same binary. In the X11 world, those two functions come as separate pieces, and each has a well-known substitute. The translation work was mapping every Omarchy component to its X11 equivalent, then making sure the keyboard shortcuts, theming, and behavior stayed as close as possible.

bspwm is a minimalist tiling window manager. The WM itself only responds to commands over a socket, and bspwmrc is literally a shell script. Keybindings live in a separate daemon, sxhkd, which reads a plain text file. That separation is classic X11: each piece does one thing.

picom is the compositor that gives you blur, shadows, rounded corners, fade-in/out, and per-window opacity rules. NW-Omarchy uses upstream v13 (released February 2026), not the old picom-ftlabs-git fork, abandoned since 2024. The visual effects Omarchy has under Hyprland (rounded corners, fade on open/close, blur on rofi and dunst) all come from picom in NW-Omarchy.

polybar replaces waybar. Same visual layout: Omarchy logo on the left, date in the middle, audio/wifi/bluetooth/battery indicators on the right. Same nerd-font icons. Left click opens the same TUIs (wiremix, impala, bluetui), right click opens the GUI variants. Scroll on audio adjusts volume, middle click mutes. Practical parity.

rofi replaces walker. super + space opens the full launcher with every .desktop on the system plus icons. super + shift + space opens a cheat-sheet of the pinned apps, with the chord shown next to each name. Useful for remembering “what was the chord for Signal again”.

For a user who isn’t going to crack open ~/.config to customize anything, the difference between the two sessions is cosmetic at homeopathic levels. The same Omarchy shortcuts (over 70 bindings) are wired up, the same menus pop up, the same logo sits in the bar, the same nerd-font icons.

The theme system is the same

This was the most fun part to build, and the part that surprises people most. Omarchy has a centralized theme system: each theme lives at ~/.local/share/omarchy/themes/<name>/, ships a colors.toml with a universal palette (accent, background, foreground, color0..15), and omarchy-theme-set <name> re-renders each app’s config to match. The active theme lives at ~/.config/omarchy/current/theme/, and every app imports its colors from there.

NW-Omarchy plugs into that same pipeline. I added .tpl templates for bspwm, polybar, rofi and dunst that follow the Omarchy convention, and omarchy-theme-set-templates regenerates everything on every theme change. The result is that all 19 themes Omarchy ships work as-is in NW-Omarchy, with zero porting work. Catppuccin, gruvbox, kanagawa, nord, tokyo-night, all of them. The wallpaper changes along with the theme via an inotify daemon (nw-omarchy-bg-watch).

A few examples in action:

When Omarchy adds a new theme via omarchy-theme-update, NW-Omarchy gets it for free. No extra work, no rebuild, nothing for me to republish.

System menu and TUIs

Omarchy’s system menu (the super + alt + space one that opens the hierarchical menu with Hardware, Setup, Update, etc.) has a 1-to-1 port in NW-Omarchy. Same tree, same navigation. Where Omarchy calls walker --dmenu, I call rofi -dmenu. The rest of the code is identical, and most of the helpers the menu invokes (omarchy-pkg-add, omarchy-theme-set, omarchy-update, etc.) have nothing Wayland-specific in them and run straight on X11.

The TUIs too: wiremix for audio, impala for wifi, bluetui for bluetooth, btop for system resources. They all open as a centered floating window, same as Omarchy under Hyprland. bspwm has a rule (bspc rule -a) that recognizes the org.nw-omarchy.<cmd> class and applies state=floating center=on rectangle=900x600 automatically.

What’s there and what isn’t

Honesty first: there are Hyprland features that are Wayland-only and don’t come back. Per-monitor fractional scaling is gone, X11 only does integer scaling per output, so mixed-DPI setups look off. HDR doesn’t exist on X11. Tear-free rendering by design needs Wayland; on X11 you need picom + vsync and a cooperative GPU, and even then you get close to Wayland without quite matching it. Workspace swipe with live preview during the gesture is also gone, because bspwm has no in-progress switch state, so the gesture fires a discrete command only on completion (you go to the next workspace, but you don’t see the preview slide). And the Wayland-specific daemons (voxtype, walker preview pane, hyprsunset, hypridle) become redshift and xss-lock, with no preview pane in rofi.

If any of those points is a deal-breaker for you, stay on Omarchy/Hyprland. SDDM picks between the two sessions every login, so they coexist without resentment.

On the other hand, what X11 has going for it still applies. xdotool, wmctrl, xprop and xinput keep working for automation, key remapping, screen readers, AutoKey, kanata, xkeysnail. xclip, xsel and clipmenu do straightforward clipboard plumbing, no permission dialog. ssh -X keeps working: you run Firefox on a remote box and the window pops up locally. Legacy Nvidia, vintage Intel and quirky Optimus drivers are all first-class on X11. The tiling WM ecosystem is mature (bspwm, i3, awesome, openbox, xmonad, dwm) and configs port between them with little pain. And the predictable input model, where any client can read any event, is bad for security but excellent for accessibility and productivity tooling.

For older hardware, that’s the difference between “live machine” and “machine sitting in a corner”.

Install

Prerequisite: Arch Linux with Omarchy already installed. NW-Omarchy runs on top of it, doesn’t replace it.

One-liner install:

curl -fsSL https://raw.githubusercontent.com/akitaonrails/NW-Omarchy/master/boot.sh | bash

boot.sh runs preflight (checks Arch, Omarchy, git), clones the repo to ~/.local/share/nw-omarchy, and runs the full install pipeline: packages, the nw-bspwm session, configs in ~/.config, and the XLibre swap as the last step. It asks for confirmation once before touching anything. Skip the prompt with:

curl -fsSL https://raw.githubusercontent.com/akitaonrails/NW-Omarchy/master/boot.sh | bash -s -- --yes

When it finishes, reboot. The X server swap (xorg-server → XLibre) only takes effect on the next session. At SDDM you’ll see a session picker. We also swapped Omarchy’s SDDM theme for one with a selector, because the vanilla Omarchy theme has the session name hard-coded in the QML with no UI to change it. Pick nw-bspwm and you’re in.

If you’d rather clone and run by hand to inspect first:

git clone https://github.com/akitaonrails/NW-Omarchy.git ~/.local/share/nw-omarchy
cd ~/.local/share/nw-omarchy
./install.sh           # dry-run, prints what it would do
./install.sh --apply   # actually run it

Upgrade

When a new release ships, the path is:

nw-omarchy-upgrade --check    # checks current vs latest, exits
nw-omarchy-upgrade            # yay -Syu, fetch latest tag, migrations, install

The script runs yay -Syu (or pacman -Syu if you don’t have yay), compares the local tag to the remote, and if there’s a new release does git fetch && git checkout v<latest>, runs the migrations between the current and new versions, and re-applies install.sh --apply. All idempotent. Re-running on an already-current machine is a no-op.

Uninstall

If you tried it and didn’t like it, uninstall this way:

~/.local/share/nw-omarchy/uninstall.sh --apply

The uninstaller reads ~/.local/state/nw-omarchy/manifest.tsv and replays it in reverse: removes only the packages it installed (pkg-skip rows are left alone; packages that were already on the system stay on the system), restores original configs from ~/.local/state/nw-omarchy/backups/, deletes the nw-bspwm session entry, wipes the state dir. Your Hyprland session keeps working as before. Nothing under ~/.config/hypr/ or ~/.local/share/omarchy/ gets touched at any point during install or uninstall.

To revert specifically XLibre back to xorg-server (without uninstalling anything else), pacman handles it on its own:

sudo pacman -S xorg-server xorg-server-common xf86-input-libinput

The package provides/conflicts graph handles the rest of the swap atomically.

Status: experimental, feedback welcome

The current version is at 1.0 but the project is still young, in polish phase. The big items are in place: binding parity, menu parity, theme parity, TUI parity, doctor for health-checking the install, manifest for clean uninstall. What’s left is polish, edge cases, working through varied hardware, listening to feedback from anyone running it on a different machine than mine (Thinkpad T14 Gen 6).

If you try it and hit something (something that doesn’t work, configuration that’s missing, behavior that differs from Omarchy in a way that breaks flow), open an issue here:

github.com/akitaonrails/NW-Omarchy/issues

Repros, stack traces, output of nw-omarchy-doctor, anything helps. PRs are welcome too.

Defending X11 in 2026 is a pragmatic argument. The transition to Wayland takes time, plenty of hardware and plenty of software still live comfortably on this side of the fence, and the open source community can support more than one path at a time. XLibre is the bet on keeping the X server alive a few more years. NW-Omarchy is my bet that you can make this older stack look as pretty as the newer one, without compromising any of what makes X11 still worth the trip.

If you’re on a new machine, modern GPU, 4K HiDPI display, wanting HDR, stay on Omarchy/Hyprland. If you’re on an older box, or you simply prefer the X11 ecosystem for any of the reasons above, give NW-Omarchy a shot.

Two monsters sit at the top of that list. First, Driveclub on shadPS4. It’s a PS4 exclusive, never got a port, Evolution Studios was shut down, no remaster. To play it outside the original PS4, emulation is the only option, and PS4 emulation is still the most immature part of the ecosystem. This is by far the hardest on the list.

Second, Forza Motorsport 4 with Project Forza Plus on Xenia Canary. FM4 is the GOAT of the Xbox 360 era, Project Forza Plus is the community mod that consolidates patches and content, and getting the two to run together on Xenia with decent graphics, no audio crashes and no shadow bugs took serious hours of trial and error.

Around those two I organized the rest of what I already knew worked at some level, just needed consolidating into a reproducible setup: Gran Turismo 4 with Retexture 3.0 and HD HUD, Gran Turismo 3 with HD textures and widescreen, Gran Turismo 2 with the Spec II mod, the PS3 Gran Turismos (GT5 and GT6), Forza Horizon 1 and 2, the PGRs, Ridge Racer, Enthusia, Colin McRae. I had an idea how to make these work, I just needed a setup that doesn’t break the next time I reinstall the system.

Before the details, two things to clarify.

First, on infra: I’m not going to repeat here how the setup was built. I wrote that in detail in An Emulation Distrobox with Claude Code. Arch Linux in a distrobox with --nvidia, 17 Ansible roles, every emulator from the AUR, ES-DE as frontend, automated per-game configs, Python scripts for PS3 update checking and Xbox 360 title updates, Xenia via Wine. Go read that one. The repo is at akitaonrails/distrobox-gaming if you want to reproduce. Here I’m going to talk about the games.

Second, on taste: I like simcade racing. Gran Turismo has been my declared addiction since PS1, and I wrote about the rest in the Formula FX1 cockpit article. Direct-drive wheel, load-cell pedal, triple monitor when I’m feeling masochistic. That’s the kind of racing I like.

The warning for the “well, actually” crowd

Yes, I know iRacing and the rest of the current sims and simcades. I have 12 TB of ISOs and ROMs on the NAS, I probably have one you’d remember to mention. It’s not for lack of options that I’m focusing on emulation today.

On the new side, the games I’m genuinely anticipating: Forza Horizon 6 in Tokyo, Assetto Corsa EVO, and Assetto Corsa Rally. I’ve been playing the demos of both Assetto Corsa titles and enjoying their single-player campaigns a lot. When those ship, they’ll become my main sim rotation. This article covers a different side of the collection, pulling classics out of oblivion that still don’t have a remaster.

Today, here, I’m interested in these specific games I listed above. Period. You do what you want, I do what I want. If you want iRacing, fire up Steam and go in peace. This article is about messing with emulators, preserving old games, and pulling these gems out of oblivion on a Linux setup. If you’re here for current-sim reviews, you won’t find them.

Now to what matters.

A note on the videos: most of them have no audio because I forgot to turn on sound capture in OBS before recording and I was too lazy to re-record. Audio works perfectly on every emulator here; this is my OBS mistake, not a setup issue.

Global settings per emulator

Before the games, a quick consolidation of the global configs that apply across each emulator. This is automated in the repo, but if you’re setting up by hand, here’s the summary.

DuckStation (PS1)

• Renderer: Vulkan
• Internal Resolution Scale: 8x (8K internal, downscaled to the monitor)
• Texture Filtering: JINC2 (preserves pixel art but smooths)
• PGXP: on (fixes the typical PS1 vertex wobble)
• Widescreen Hack: on as fallback, but I prefer per-game widescreen cheats
• Aspect Ratio: 16:9 with widescreen cheat, 4:3 without

PS1 runs smoothly on DuckStation these days. It’s the most mature emulator on the list. The attention goes to per-game choices (some games need a specific widescreen cheat).

PCSX2 (PS2)

• Renderer: Vulkan
• Upscale: 4x SSAA (1440p native → 4K internal)
• Anisotropic Filtering: 16x
• Post Processing: FXAA on, PCRTC antiblur on
• Deinterlacing: Automatic (some games need override)
• Controller: Xbox-style bindings (I use an 8BitDo)

PCSX2 2.7.x is much better than the 2.6.3 still in Arch’s official repo. The AUR’s pcsx2-latest-bin tracks 2.7.x and that’s where texture replacement, modern FXAA and PCRTC antiblur live. If you’re on a different distro stuck on 2.6.3, get the official AppImage.

RPCS3 (PS3)

• Renderer: Vulkan
• Resolution Scale: 300% (generally) or native (for games with upscale issues)
• Shader Precision: Ultra
• Force High Precision Z: on
• SPU XFloat: Accurate
• Multithreaded RSX: on
• Write Color Buffers (WCB) / Read Color Buffers (RCB): off by default (GT-series safety)

RPCS3 is where the most traps are. Each game has a recommended preset in the official compatibility DB. And a heads-up: per-game configs live in ~/.config/rpcs3/custom_configs/config_<SERIAL>.yml. The config_ prefix is mandatory. It cost me time to figure out. RPCS3 silently accepts the YAML and then ignores it if the name is wrong.

Xenia Canary (Xbox 360)

• Build: Canary (master has been stagnant for months, Canary is where development lives)
• Renderer: Vulkan
• Render Target Path: rtv by default, fsi for specific games (PGR4)
• User Profile: created once, persists
• Wine Prefix: dedicated, managed by Xenia Manager

Xenia on Linux runs via Wine, managed by Xenia Manager. There’s no decent native build. It works well, but each game needs specific tuning, and Title Updates have to be pulled manually from archive.org (I wrote a script for that, details in the previous article).

shadPS4 (PS4)

Gets its own section at the end. TL;DR: works for some simple games, Driveclub is still a moving target. Still a shot in the dark.

PS1 on DuckStation

Gran Turismo (the first, from 1997)

This one is pure sentiment. GT1 was one of the first games I bought for the PS1 and I played it until the CD cracked. At the time, it was on another level. Real simulation on a machine with 128K of video RAM, decent physics, 140 cars when everybody else had 15, memorable soundtrack.

But let’s be honest: you can’t go back today. GT1’s physics has exaggerated drift, the car slides more than it should on any corner above 80 km/h. It’s part of the 1997 charm but gets annoying in 2026. The handling model was refined starting in GT2, and everything after only got better. Between GT1 and GT2, GT2 wins on content (650+ cars vs 140) and especially on drivability.

I keep GT1 in ES-DE to open in nostalgic moments, drive 10 minutes at Trial Mountain, and close it. For serious PS1-era gameplay, it’s GT2.

Gran Turismo 2 (Spec II Mod)

The original PS1 Gran Turismo is a historical milestone. I played a lot of it back then. To replay today? No. GT2 exists, and GT2 is superior in everything. More cars (650+), more tracks, more modes, and most importantly, a much better handling model. GT1 has that exaggerated drift where the car slides more than it should, GT2 tightened that up to something closer to what the series would become starting on PS2. Between playing GT1 or GT2, always GT2.

And the GT2 I run today is the GT2 Spec II Mod by Project A-Spec, a community project that merges the two regional variants (Arcade + Simulation) into a single game, brings back events that were cut from the final release, fixes physics bugs, adds native widescreen support, and ships quality-of-life menu updates. It’s the definitive way to play GT2 in 2026. The project doesn’t maintain its own website anymore, updates come through the author’s Twitter.

To run it:

The 8 MB RAM cheat matters for crowded tracks (Seattle in populated races for example) where audio starts clipping. It simulates the memory expansion of the Japanese version that never made it West.

Colin McRae Rally 1 and 2

Iconic PS1 games. CMR1 has that rough first-gen rally feel that has its charm. CMR2 is technically superior, better physics, more rallies, better graphics. But honestly: to play CMR2 today, it’s worth looking for the original PC version. Higher resolution, native 60fps (the PS1 version is locked to 30), direct keyboard/wheel support. Codemasters repacks exist on the internet, a 40-second search will find them. I’m not going to link them, you know where to look.

On PS1 via DuckStation they run smoothly, nostalgia guaranteed, but it’s not where I spend my time.

PS2 on PCSX2

Gran Turismo 3 A-Spec

GT3 was a generational leap. Out of the blocky PS1 world into shaders, decent environment mapping, serious polygon car models, physics that finally started to feel like actual physics. The soundtrack with Feeder’s “Just a Day” opening the game still gives me goosebumps.

The problem is that GT3 has LESS content than GT2. Polyphony was more cautious, cut modes to focus on polish. The A/B/S license tree is smaller, fewer cars, fewer tracks. But what’s there is polished.

In 2026 on PCSX2 2.7.x, GT3 looks great. Community HD textures, widescreen pnach, anti-aliasing via SSAA, 16x AF. Feels like a re-release.

Caveat on the retexture pack: when enabled, some car-showcase cutscenes in the garage have momentary flicker due to NFS streaming. Doesn’t bother in-race. If it bothers you in menus, turn it off.

Reminder: for the widescreen pnach to take effect, you still need to go into the in-game options and switch the aspect ratio to 16:9. The pnach unlocks the option in the menu, it doesn’t apply automatically.

Gran Turismo 4 (Spec II Mod)

GT4 is my GOAT in the series. 700+ cars, 50+ tracks, physics still respectable by 2026 standards, and that soundtrack mixing alternative rock, Japanese lounge, and Moby’s infamous “Sail Away” on the main menu. It’s the game I poured the most hours into back in 2004, and it’s what I play the most today.

Like GT2, the GT4 I run today is not the original disc. It’s the Gran Turismo 4: Spec II maintained by TheAdmiester — a massive community mod that’s objectively the best way to play GT4 in 2026. It combines the final USA disc, the 2003 Beta prototype, and the original Japanese release into one game, restoring cut cars (including several that never left Japan), cancelled events, dozens of missing soundtrack tracks, adding 16:9 widescreen support, over 30 built-in cheats exposed as menu options (pro tuning, top speed, fuel economy), the option to switch between English and Japanese, and original bug fixes. The project is active, still gets patches, and ships its own installer that applies over a clean USA ISO.

In practice, Spec II is what GT4 should have been if Polyphony had six more months to polish. Playing it today feels like GT4 with all the content that got left out, plus modern quality-of-life. For anyone who enjoyed the original, it’s mandatory.

On top of that goes the community’s Retexture 3.0 (HD texture pack) and the HD HUD by Silentwarior112. With those three pieces together (Spec II Mod + Retexture + HD HUD), GT4 runs at 1440p SSAA on PCSX2 2.7.x with 16x AF, FXAA, and a look that’s honestly indistinguishable from a new low-poly-style release. It’s my current favorite to sit down and play long.

Spec II users need to pay attention to the CRC: the vanilla GT4 HD packs were built for 77E61C8A (USA), so on Spec II with CRC 4CE521F2 I symlink the assets into the CRC-suffixed folder that PCSX2 looks for. The widescreen pnach was also renamed to match the Spec II CRC. Without that, the game runs but the mods don’t load.

In-game reminders: same as GT3, the widescreen pnach only unlocks the option, you still need to enter Options in-game and switch to 16:9. And important: change the video mode to progressive 480p (also in Options). The default is interlaced 480i, which looks terrible on a modern screen. Spec II Mod has native progressive support, just flip it on.

If I could recommend a single GT in the series for someone starting today, it would be this one. If you like racing and never played GT4 in full, you’re missing out.

Enthusia Professional Racing

Enthusia is the forgotten Konami game from 2005. Launched in GT4’s shadow and died on the shelves. It’s a shame, because Enthusia’s physics was more realistic than GT4’s. Car weight, mass transfer, limit behavior, all closer to real-world behavior. The sim-racing community of the 2000s knew this and the game has a cult following today.

Enthusia’s problem was the Enthusia Points system: you earned points for driving clean, lost them for crashing, and the game’s progression depended on those points. A lot of people found it punitive. I found it perfect. It forced you to drive with your head.

On PCSX2 with retexture and widescreen, the game looks great. Strong recommendation for anyone who wants something different from Gran Turismo.

Ridge Racer V

Ridge Racer is its own thing. Not simcade, pure arcade. Drift everything, cartoony grip, electronic soundtrack, saturated colors. Ridge Racer V was the Japanese PS2 launch title and it carries that “show what the console can do” vibe, with massive scenery and a sense of speed GT never attempted.

On PCSX2 it runs well, with a catch: car textures sometimes flicker on the hardware renderer (PCSX2 issues #3639 and #13729). Software renderer fixes it but kills performance. I stay on hardware and accept the occasional flicker.

Colin McRae Rally 3, 4, 5 (PS2)

PS2 Colin McRae versions run well on PCSX2 with default configs. CMR3 and CMR04 are good. CMR05 (the last before the rebrand to Dirt) is the best of the three technically. But again: if you’re on PC, look for the native version. The PS2 ports were relatively inferior to PC of the era, ran at lower resolution, and a modern PC with a repack will hit 144Hz easily.

I keep them on PCSX2 just for collection completeness.

PS3 on RPCS3

Gran Turismo 5

GT5 is controversial. Polyphony promised the world and delivered a somewhat fragmented game: gorgeous Premium models next to Standards that were basically HD GT4 cars, a level system some loved and others hated, online that went to mud when PSN service was cut, a Top Gear mode that was weird. The contemporary critical reception was mixed, and I remember entire communities fighting over whether the game was a disappointment or a masterpiece.

For me, it’s a masterpiece. GT5 has the Course Maker (design your own track from real sections), real 24h Nurburgring with dynamic weather, the Moon Rover (yes, a drive-on-the-moon mode), Red Bull X-Challenge with Vettel, and the single-player endurance experience is ridiculously big. Anyone who went deep into the game knows there’s content for a whole year.

On RPCS3 in 2026, GT5 runs really well. Stable, without the serious bugs from years past. It’s the most stable GT I have emulated today.

The Shader Precision Ultra + Force High Precision Z combo kills the typical RSX dithering that made GT5 look grainy on RPCS3 in years past. Without those two, asphalt looks permanently noisy. With them, the game looks clean.

Gran Turismo 6

GT6 is one of my favorites in the series. It came out in 2013 for an end-of-life PS3 while the competition was already looking at PS4. Sold poorly. A lot of people didn’t play it. That’s a shame, because GT6 took the GT5 base, cut the fat (Standards were reduced), added more Premiums, better Moon circuit sessions, dynamic weather on more tracks, physics refinement. It’s basically GT5 polished.

On content, GT6 is comparable to GT4. A lot of old-guard players put GT4 above it because of the PS2-era charm. I stay between the two and go GT6 on a normal day, GT4 on a nostalgic day.

On RPCS3, GT6 has a serious catch: patches 1.06 and beyond regress visually. Black surfaces on cars in the garage menu, flicker in cockpit view, full-screen flashing on certain tracks. The version that works well in 2026 is pinned at v1.05. The repo’s extract_ps3_dlc.py script has a per-title version ceiling specifically to pin GT6 at 1.05 even when PSN serves 1.22 as “most recent”.

Also, Force CPU Blit is mandatory. Without it, full-screen flicker in the menu. The trade-off is the rear-view mirror stays permanently black. I prefer losing the mirror to having the flicker. Anyone who wants the mirror can enable Write Color Buffers, but then resolution drops to 720p native.

In 2026, with these settings, GT6 is in my rotation. Not perfect, but playable enough that I can spend an afternoon doing endurance.

Ridge Racer 7

Ridge Racer 7 was a PS3 launch title in 2006 and the last mainline in the franchise. Arcade like Ridge Racer V, drift-first, electronic soundtrack, cinematic camera. For a PS3 of that era it was a pretty tech demo.

On RPCS3 it runs, but with caveats: requires Write Color Buffers on to avoid lighting issues, and the recommended preset in the compat DB is different from my GT preset. I use a dedicated per-game config. Not my favorite, but it’s there for completeness.

No video for this one, I’ll record later.

Xbox 360 on Xenia Canary

This is the part that caused me the most headaches this Sunday. Xbox 360 on Linux is hostile territory. Xenia runs via Wine, each game needs specific tweaks, title updates have to come from archive.org, and Forza Motorsport 4 specifically had serious problems until recently.

Forza Motorsport 4 (the GOAT)

FM4 is, for a lot of people, the best Forza Motorsport ever released. Polyphony made Gran Turismo, Turn 10 made Forza, and FM4 is the peak of the 360 era. Beautiful car models for their time, well-designed tracks, solid physics without being a hard sim, Autovista mode with Jeremy Clarkson narration, epic soundtrack, and that feeling of the Xbox 360 being pushed to its limit.

FM4 on Xenia was a nightmare until recently. Severe shadow artifacts, constant texture pop-in on the car, grainy pixelated track textures, sky brightness completely wrong (it came out white-blown-out instead of the deep blue of the original), and worst: frequent audio crashes where XMA (the Xbox 360’s proprietary codec) would freeze and the audio would turn into a high-pitched noise until the game hung. I spent hours this Sunday messing with configs, testing builds, searching the xenia-canary issue tracker, testing different title updates.

What unlocked it:

• Latest Xenia Canary build (master is stagnant, Canary tracks active development)
• Render Target Path: rtv (the default works fine for FM4)
• Title Update 1.0.17.0 installed via Xenia Manager (version matters, older ones regress shadows)
• Vulkan GPU with NVIDIA ICD forced (on my hybrid setup with AMD iGPU, I had to hardforce the 5090)

After that, FM4 ran. Not perfectly. Still gets the occasional audio crash (xenia-canary issue #161 open). But it’s playable, and I spent two hours of the Sunday at Top Gear Test Track just admiring the Koenigsegg CCX. Worth every hour of debugging.

Forza Motorsport 3

FM3 is one of the solid entries in the series, sitting between FM2’s rougher charm and FM4’s technical peak. Getting it to emulate was surprisingly annoying, because I was using the wrong ISO.

There are two releases of FM3: the retail (original disc sold in stores) and the Ultimate Edition (all DLCs packaged on a second disc). I was trying to run the Ultimate, which combines both discs into a hybrid ISO that Xenia can’t parse correctly. I swapped to the standard retail + DLCs installed separately via Title Update, and bang, the game ran first try.

Moral: if your FM3 isn’t running on Xenia, check that it’s retail. Ultimate breaks.

Forza Motorsport 2

FM2 is from 2007, first-gen 360. Less refined systems, more basic modeling, but that original Forza charm some prefer to FM4’s sophistication. On Xenia it ran practically out of the box. No special tweak.

Forza Horizon 2

FH2 was the most polished Forza Horizon of the 360 generation (there’s also the Xbox One version, which is technically better, but the 360 has its charm because of the smaller map and more focused progression). Open world in southern Europe, iconic soundtrack, Horizon festival at its peak.

On Xenia it ran without asking for anything extra. Same as FM2.

Forza Horizon 1 (with XE Mod)

Original FH1 runs OK on Xenia, but there’s a community maintaining the Forza Horizon 1 XE Mod, which improves traffic AI, rebalances progression, adds cars that were cut, fixes known bugs, and brings quality-of-life tweaks to the UI. I tested the XE Mod this Sunday and it’s worth it. The game feels more alive and progression feels fairer.

Install details for the XE Mod are on the project site. Basically it’s a patch over the original ISO + a few custom title updates.

For comparison, here’s FH1 without the mod, running vanilla:

The most visible difference is traffic and the variety of situations that come up, but the XE Mod has a lot of stuff you only notice after a few hours.

Project Gotham Racing 3 and 4

PGR3 was a 360 launch title in 2005 and still looks gorgeous today. Urban tracks (New York, Tokyo, Nurburgring, Las Vegas), kudos system, cinematic camera. PGR4 added dynamic weather (rain and snow) and motorcycles (some people love them, I prefer to pretend they don’t exist).

PGR3 on Xenia Canary runs reasonably well with default configs. PGR4 needs a specific tweak: render_target_path_vulkan = "fsi" in the config. Without it, some tracks break with severe visual artifacts (green bars across the screen in snow races).

And PGR4 on NVIDIA has a known audio bug: XMA decoding produces intermittent garbage (open xenia-canary issue, no resolution). Not game-breaking, but annoying.

Ridge Racer 6

Ridge Racer 6 was the Ridge Racer of the 360, skipping the 7 that stayed on PS3. Pure arcade, like Ridge Racer V of the PS2. On Xenia Canary it runs with default config, no special tweak. Fun for short sessions. No video for this one in the article, but it’s in the catalog running.

PS4 on shadPS4: the state of the emulator

shadPS4 still doesn’t have a stable release. The project is under active development, the main branch changes several times a week, and “what works today” can regress on a rebase tomorrow. That said, many games already boot and run well enough. The community list is on the compatibility tracker and grows every week.

The difference between shadPS4 and the other emulators in this article is the kind of effort. PCSX2, RPCS3, Xenia are mature projects where each game has a reasonably up-to-date wiki page. shadPS4 is the opposite: you read a Reddit guide, try to reproduce, discover the guide uses a specific fork (not the official main), or a two-month-old commit, or a firmware with sys_modules symlinked in a particular way, or XML patches applied in a specific order that the author didn’t document. Reproducing a shadPS4 setup from a YouTube video is like trying to solve a Rubik’s Cube blindfolded.

But that doesn’t mean you shouldn’t try. It means you need to treat shadPS4 as a hobby, not a workflow. And if you have the patience, you can pull off impressive results.

Driveclub: the impossible, finally possible

Driveclub is my Moby Dick of emulation. It’s the only PS4 game I really want to run. Released in 2014 by Evolution Studios, had a catastrophic launch (online servers collapsed on day one), got patched over two years until it became one of the best racing games of the generation, and was discontinued by Sony when Evolution was closed in 2016. No PC port. No remaster. No sequel. Only exists on PS4.

And today, after many hours of debugging, it’s running here. Main menu loads, intro plays, races start, controller responds, audio works, daytime tracks visible, night tracks with headlights lighting the road. The video above is real gameplay, stable 30 FPS, v1.28 with DLC content accessible.

Getting here required dismantling several traps. Worth documenting, because most online guides don’t mention any of them.

Trap 1: the FMOD loop error that wasn’t FMOD

When you try to boot Driveclub on shadPS4 straight from the retail PKG, the log hits an infinite loop of:

/app0/audio/fmodstudio/masterbank.bank failed, file does not exist

The first reaction is to investigate FMOD. Some people online spent hours messing with sceFont, libtbb, sceNgs2, convinced it was an audio or HLE lib problem. None of that is the cause. The masterbank.bank file literally doesn’t exist on disk, because it’s packed inside the gameNNN.dat files in a custom Evolution Studios archive format that shadPS4’s VFS can’t read. Same story for fonts, models, shaders. All the game’s content lives inside the .dat files.

The only public tool that parses that format is Nenkai’s DriveClubFS. It’s a .NET app that reads game.ndx (the index) and decompresses the .dat files into loose files. Without that unpack, shadPS4 can’t open anything.

Build detail: the DriveClubFS project targets net9.0, and Arch has net8 and net10. You need to retarget the csproj to net10.0 before building. The exact command is documented in the repo’s docs/driveclub-shadps4.md.

Trap 2: v1.28 is a patch, not a base installer

Like every PS4 update, v1.28 is a patch that layers on top of a base install. The v1.28 PKG ships the updated eboot, new-content .dat files, and patch content (sce_sys/about/right.sprx), but no param.sfo, no disc_info.dat, no keystone. Those metadata files live in the v1.00 base — on a real PS4 they’d already be on disk from the original install.

And there’s more: v1.28’s game.ndx references both the base .dat files and the new ones. Running DriveClubFS against v1.28 alone makes the index point at files that aren’t there.

The cruelest symptom hits later: the game boots, the Qt Launcher shows the tile, you click, the loading screen comes up. Then the game decides no content “has been released yet” and asks you to download. Download obviously isn’t happening because PSN for PS4 isn’t accessible. You get stuck thinking it’s a network bug, when actually it’s missing metadata.

The correct flow is to treat v1.28 as an overlay on top of the base. First, extract the v1.00 PKG into a dedicated dir (CUSA00003.v100-working-backup/ works well, and doubles as a rollback snapshot if some experiment breaks the live install). Then extract v1.28 into staging and symlink the base’s low-index .dat files into the staging dir so DriveClubFS sees the full set. Run the unpack. You get 8018 loose files, ~47 GB.

Move that into the live CUSA00003/ dir, copy v1.28’s updated eboot and new patch content on top, then pull param.sfo, disc_info.dat, and keystone from the v1.00 base. The base’s param.sfo already has APP_VER = 01.28 recorded (because it was the version that received the patch originally), so there’s no version conflict. The v1.28 eboot reads those files and unlocks the content.

Trap 3: the 60fps XML patch produces slow-motion

There’s a community Driveclub.xml patch that makes the game render at 60fps. Intuitively, it looks like pure upside. In practice, the patch rewrites the render rate but doesn’t touch the game’s fixed logic tickrate, which is locked at 30fps. On a real PS4 Pro, the hardware reconciles the mismatch. On shadPS4, it doesn’t.

Result: the game renders smoothly at 60fps, but the physics, AI, audio, race timing all run in slow motion. You press the throttle and the car takes a perceptible two seconds to launch. Looks like a random bug until you understand the mismatch.

Disabling the XML patch is the move (just rename the file to something like .disabled). Without the patch, the game runs at native 30 FPS, same speed as a stock PS4 base. Which is what we want. If someone in the future produces a patch that moves both rates (render + logic), we’ll flip it back on.

Trap 4: pipeline cache has to be on

shadPS4’s default ships with pipeline_cache_enabled = false. On a large game like Driveclub, which has hundreds of Vulkan shaders and pipelines, that means every cold launch recompiles everything. My first launch counted ~864 shaders and ~590 pipelines being compiled in real time. The menu animated at 2-3 fps. A minute later, with everything compiled, it snapped to normal fluidity. Next launch, same from-scratch compilation cycle.

Just enable "pipeline_cache_enabled": true in the global config.json. The first session pays the one-time compilation cost, subsequent sessions read from cache and start up instantly.

Trap 5: TOML silently ignored

shadPS4 migrated from TOML to JSON for per-game configs in late 2025. If you have an old CUSA00003.toml in the custom_configs/ folder, it’s silently ignored, no warning in the log. You think your config is active, in reality you’re running all defaults.

Delete any TOML and use CUSA00003.json. The per-game configs that work for Driveclub are specific and detailed, all documented in the docs/driveclub-shadps4.md of the repo.

Trap 6: controller not detected without hidapi hints

shadPS4’s Qt Launcher calls an internal Shadps4-sdl.AppImage. Without specific SDL hidapi env vars, the controller (8BitDo Ultimate 2 in my case) isn’t detected, even though it works in every other emulator. The fix is to wrap the AppImage in a shell that exports SDL_JOYSTICK_HIDAPI=1 and platform-specific variants (PS4, PS5, Xbox), before executing the original.

Plugging the controller in before opening the Qt Launcher also helps. Hot-plug works during the game, not before.

Trap 7: night tracks are pitch black on upstream

This one needed a code patch, not just config. On upstream shadPS4, Driveclub night tracks came out pitch black. The HUD rendered on top, but the track, the car, everything hidden in absolute black. Not even the car’s own headlights lit anything up.

Investigation pointed at the log repeating 1325 times the message ResolveDepthOverlap: Unimplemented depth overlap copy. The cause: Driveclub uses a forward+ renderer, which writes scene depth into a 4x MSAA D32Sfloat buffer, then reads that same buffer as R32G32B32A32Sfloat 1x for effects like SSAO, volumetrics, and dynamic lighting (headlights). shadPS4 upstream has a path for MSAA → MSAA and for color → color as MSAA depth, but it didn’t have a path for “MSAA depth 4x becomes color 1x” in that specific format. It falls into the final else, frees the buffer, and the shader reads uninitialized memory — i.e., black.

I implemented in my local shadPS4 fork a ReinterpretMsDepthAsColor symmetric to the existing ReinterpretColorAsMsDepth. It’s a tiny fragment shader (ms_depth_to_color.frag) that does texelFetch of sample 0’s depth and writes it as vec4(depth, 0, 0, 1) to the color attachment. Plus a BlitHelper helper and a new else if branch in TextureCache::ResolveDepthOverlap. With that, night tracks light up properly, opponent headlights appear, AO and volumetrics on day scenes get more precise too.

The fix lives on a gamma-debug branch of my fork, ready to become an upstream PR. Until it merges, anyone who wants to race at night on Driveclub on shadPS4 needs to build from that branch. Anyone sticking to daytime can use upstream nightly directly.

What finally worked

All of this is encapsulated in docs/driveclub-shadps4.md in the repo, with the exact step-by-step for extraction, config, and wrapper. The full technical investigation (5 phases, detailed engineering log) lives in the fork’s driveclub-v128-investigation.md.

How playable it is today

Good. The video above is real gameplay, stable 30 FPS, physics responding, audio in sync, HUD correct, v1.28 with DLC accessible. Day races and night races both work (with the MSAA depth fork for night). What’s left as limitation:

• Daytime brightness sits a bit below what the PS4 delivered. Not an emulator bug. I spent hours testing tonemap, auto-exposure, gamma curves, ACES, various post-processing shaders, and in the end discovered the game writes already-correct SDR to the framebuffer. What was missing was the display-calibration pipeline that PS4 firmware 4.0+ applied on the outside, and that Linux doesn’t have. The in-game brightness slider (which on shadPS4 maps to sceVideoOutAdjustColor) works, but only up to the point where the game expected the firmware to pick up the rest. The 5-second dim at the start of a race is also the game’s own cinematic fade-in VFX, not an emulator fault. Accepted.
• Native 30 FPS. No viable 60fps patch (due to the fixed logic tickrate explained above). Stock PS4 speed.
• MSAA depth fix still on the fork. PR candidate ready, awaiting upstream merge.

“Achievement Unlocked”. The game runs, with sound, controller, gameplay, day and night, and I complete a whole race without crashing. That’s a personal milestone. I spent years trying to get this game running on Linux and would always hit a point where I just gave up. Now it’s part of my ES-DE, shortcut on the desktop, sitting there waiting for me to play.

If you want to replicate, the repo is public. Good luck. You’re going to need patience.

“Achievement Unlocked”

I’ve been trying to make these games work, at some level, since each respective emulator came out of alpha. I’ve been running GT2 since ePSXe. I’ve been messing with GT4 since PCSX2 0.9.6. I tried to get FM4 running on Xenia twice in past years and gave up both times. And I looked at shadPS4’s face three times before this Sunday and swallowed hard.

Today it closed. The two monsters that opened this article (Driveclub on shadPS4 and FM4 with Project Forza Plus on Xenia) are running, along with the rest of the Gran Turismo, Forza, Ridge Racer, Colin McRae, and Enthusia collection. All in a single setup, reproducible, automated. I’m now part of the very small group of people who brute-forced their way into emulating Driveclub on Linux, and that alone made the Sunday unforgettable.

The frustration of years wasn’t lack of information. It was the OPPOSITE. Too much information, poorly indexed, scattered across dead forums, YouTube videos that went stale, Reddit threads with solutions for two-year-old emulator versions that don’t apply today, wikis that are out of date on half the pages, and mods with VERY specific requirements of CRC, version, patch, path, setting. Every time I sat down to get one of these games running right, I spent three hours reading conflicting material before writing the first line of config. Worse still when the good material was buried under wrong diagnoses, like the Driveclub FMOD loop everyone investigated as if it was an audio problem when in reality it was Evolution Studios’ proprietary archive format.

What changed in the last year is that Claude Code can be my aggregator. I tell Claude to hit the Xenia issue tracker, the PCSX2 wiki, the RPCS3 subreddit, shadPS4 PRs, cross-reference all that info with the emulator version I have installed, cross-reference with the logs I’m looking at, and give me back the combination that works today. It reads source code when needed, understands why Force CPU Blit changes behavior on GT6, finds which FM4 title update was the one that fixed the shadow bug, discovers that DriveClubFS needs a retarget to .NET 10 before compiling. What used to take three weekends of research now takes an afternoon of assisted execution.

This Sunday is the consolidated result of all that work. distrobox-gaming is that knowledge turned into code, reproducible, automated. Starting on a fresh machine, one ansible-playbook site.yml puts me back in this state in under two hours. Fewer than 10 commands separate “vanilla Arch Linux” from “Driveclub running”.

If anyone wants to contribute, test on different hardware, report a bug, or send a config that’s missing, the repo is open. The more people test on different setups, the more resilient the project gets. If you improve the Driveclub situation (get the MSAA depth fix merged upstream, a 60fps patch that also fixes the logic tickrate, font dumps that don’t need jailbroken hardware), send a PR and I’ll embrace it.

For now, I’m going to do a race in Iceland on Driveclub. Good Sunday night.

I bought a Lenovo Thinkpad T14 Gen 6 and installed Omarchy on it. It’s not my main machine, and it’s not supposed to be. It’s a companion: a notebook I can open on the 3D printing office desk, SSH into the desktop, fire up Claude Code, access files on the NAS, debug the network through ethernet without hunting for a USB dongle and a long cable. This article covers the hardware choice, the Omarchy setup on top, the customizations specific to a laptop and to this Thinkpad in particular, and the architecture decisions that might not be obvious.

Mini-review of the Thinkpad T14 Gen 6

Let’s get this out of the way: this isn’t the notebook of my dreams. If I were picking by looks, I’d grab an Asus Zenbook S 14 with an OLED screen. If I were picking by portability, the Thinkpad T14s with the aluminum shell, which is lighter and much better looking. The regular T14 has a 14" 1920x1200 IPS panel, 400 nits, 60Hz, no HDR. It gets the job done, but it’s a far cry from the Zenbook’s screen. The shell is plastic with a rubberized finish, which makes it scratch-resistant but not premium. Reviews from NotebookCheck and XDA Developers land on the same verdict: good price, good connectivity, fine performance for office work, but the screen is dated.

What makes up for it:

• Port selection. Full-size HDMI. Gigabit ethernet. USB-A, USB-C Thunderbolt 4, charges over USB-C (not a proprietary charger). For a debug companion, this is exactly what I wanted. The Zenbook S 14, being thinner, cuts ports.
• Fingerprint sensor that actually works on Linux (Goodix MOC, works with libfprint on kernel 6.11+). I use this, details later.
• Thinkpad keyboard. 1.5mm key travel, trackpoint, classic layout. It’s not the best keyboard in the world in 2026, but it’s reliable and durable.
• Rugged shell. It will fall, it will scratch, it will travel in a backpack. If I put a Zenbook OLED or a Macbook Pro on the 3D printing office desk next to the printer with PLA dust in the air, I’d be nervous. The Thinkpad can take a beating.

If I wanted a gaming machine, I’d get an Asus Zephyrus G14, my favorite gaming notebook. If I wanted a creative work machine, I’d get the Asus Zenbook Duo (UX8406) with two vertical OLED screens, great for video editing and 3D modeling. I can afford any Macbook Pro or Mac Studio, and I chose not to go that way. I’ll explain in the next section.

My use case

My main PC is a desktop with Ryzen 9 7950X3D, 96 GB of RAM, RTX 5090 with 32 GB. That’s where I work, experiment with local models, run containers, edit the blog. For gaming, I have a separate mini-PC with an RTX 4090. Those two cover 100% of what I need to do at home.

The notebook exists to cover the remaining 1%: sitting on the couch, taking it to the 3D printing office, taking it to the kitchen, short trips. It’s not meant to replace the desktop. It’s meant to give me remote access to the desktop when I’m away from it.

In practice it looks like this: open the notebook, split the Hyprland layout, left pane SSHs into the main desktop, right pane is the notebook itself. Same Omarchy on both, same keybindings, same bash. The notebook becomes an extension of the desktop, not a parallel environment I have to re-learn in my head every time I switch.

SSH from outside the house: Tailscale

Inside the local network, SSH is trivial, the notebook talks to the desktop through the internal IP. Outside the house is another story. My home IP is dynamic, opening port 22 to the internet is a terrible idea, and even with DDNS and port forwarding you’re putting SSH on the public internet for any scanner to find.

The solution I use is Tailscale. For those who don’t know: Tailscale is a mesh VPN built on WireGuard that creates a private network between your devices (the “tailnet”). Each machine runs the agent, authenticates once, and gets a fixed IP on the private network (something like 100.x.y.z). Traffic between your own devices goes peer-to-peer, encrypted by WireGuard. It doesn’t route through Tailscale’s central server, they only coordinate NAT traversal. Result: from my notebook in a café anywhere in the world, I run ssh hal9000 and land on my home desktop as if I were on the same network.

More sophisticated options exist: Cloudflare Tunnel with Zero Trust to expose services publicly with SSO auth, self-hosted headscale, raw WireGuard with manual config, Nebula, OpenVPN. Each has its use case. If you need to expose services to third parties, control granular per-identity access, or run the whole infrastructure at home without depending on anyone, those options win. In my case, it’s just notebook talking to desktop, for short periods (it’s not a full week of work, it’s a weekend debug session), so free Tailscale covers it. The free tier accepts up to 100 devices and 3 users, way more than I need.

Setup is as simple as it gets:

# On Arch/Omarchy
sudo pacman -S tailscale
sudo systemctl enable --now tailscaled.service
sudo tailscale up --ssh

The --ssh flag enables Tailscale SSH, which authenticates via tailnet identity instead of a local SSH key. Once you log in through the browser to tailscale, each registered machine can SSH into the others based on ACL policy defined in the admin panel. Zero key management.

I repeat the same on the desktop, log in with the same account, done. Both machines show up in the panel (hal9000 and hal9666 in the screenshot above, both with SSH enabled). From the notebook: ssh hal9000. From the desktop to the notebook: ssh hal9666. No port forwarding, no public IP, no port 22 exposed to the internet. If the notebook is stolen, I remove it from the tailnet with one click.

A practical detail: since the tailnet gives stable names, I added entries to ~/.ssh/config to use these short names:

Host hal9000
  HostName hal9000
  User akitaonrails

Now ssh hal9000 works from anywhere that has Tailscale connected. It’s the closest thing to “it just works” I’ve seen for remote SSH.

Why not a Mac

I have no use for macOS. As a dev, I live better in native Linux. Every tool I need has a first-class Linux version, and on macOS I’d get a second-class version via Homebrew. I don’t do iOS, so I don’t need XCode. For mobile I use Flutter or Hotwire Native, which run on any OS. iTerm2 and Ghostty on Mac are fine, but Alacritty, Kitty and Ghostty itself on Linux work just as well. Every good piece of software lands on Linux first and gets ported afterwards. Arch with AUR covers everything in a single yay.

For creative work, I haven’t done it professionally in years. DaVinci Resolve Studio on Linux is better than Final Cut Pro. Krita or Affinity Photo replace Photoshop for most cases. Clip Studio Paint on Android is better than Procreate. I simply don’t have a workflow that depends on Apple, and the App Store annoys me.

For gaming, Mac is terrible. Apple Silicon has a decent GPU for some things, but the native macOS game library is pathetic compared to Windows or Linux. Game Porting Toolkit exists, CrossOver exists, but for anyone who games seriously, it doesn’t cut it. I won’t be gaming on the Thinkpad, I have the main desktop and the mini-PC with the RTX 4090 for that. But if I ever feel like running Hollow Knight or some indie on a train, I just install Steam and let Proton handle it. Linux became a real gaming platform in the last few years, with Proton/DXVK running almost the entire Steam catalog (check ProtonDB). I recently wrote about running my emulation library in distrobox without polluting the host system. With Mac, those options don’t exist.

Another argument that always shows up: “but a Mac Mini M4 or a Mac Studio with 128GB of unified memory runs large models locally, it’s a ChatGPT replacement.” I already tested that thesis and wrote a detailed benchmark. The conclusion: expensive local hardware to run LLMs is a weekend hobby, not a production tool. The open source models that fit don’t deliver the quality Claude Opus delivers. I have a home server with AMD Strix Halo and 96 GB of unified RAM, I ran models for dozens of hours, and in my real coding flow they’re fine for simple tasks. For complex tasks, Claude Opus. Before spending $4000 on a Mac Studio justifying it with local models, actually test it first. You’ll probably end up paying for Opus again.

Why Omarchy

I’ve been using Omarchy on the desktop for months and documented the path in a series of articles. Omarchy 2.0 has its own installer with LUKS, Btrfs, Limine, snapper and SDDM already configured. I wrote about using the official ISO, about ZSH customizations with atuin, starship, secrets properly organized, about Mise for multiple languages, about LazyVim and LazyExtras, about SSH and Yubikeys, about modern TUIs. There’s also Omarchy 3 with dual GPU AMD + NVIDIA and Crush as a coding agent.

For those who don’t know: Omarchy is plain Arch Linux with a cosmetic layer on top of Hyprland/Wayland. Pre-configured with sane defaults. I could build all of it from scratch, I’ve done it several times in my life, but why redo work someone already did well? I install Omarchy, I stack the tweaks that are mine on top, and I have customized Arch in a fraction of the time.

A point I raise every time I recommend Omarchy: the documentation is excellent. There’s an official manual covering everything from installation to theme customization, keybindings, Hyprland, Waybar, the works. If you’re coming from Ubuntu or Fedora and are wary of Arch, this manual handles most of the doubts. If you’ve never touched Hyprland, open it and read around. It’s not a README dumped on GitHub, it’s a real manual with chapters and an index.

The story of this article starts in a previous thread. I recently migrated my home server, swapping an old Ubuntu box for a Minisforum MS-S1 running openSUSE MicroOS configured with Claude Code. That was the first serious experiment of letting Claude Code drive an entire infra migration, with containers, NFS, services, networking. It worked. And it left an idea in the air: why not use the same approach to configure a new notebook?

That’s what I did. I grabbed the Thinkpad, downloaded the latest Omarchy ISO, burned it to a flash drive, installed it over Windows. From zero to working desktop in under an hour. From there on, it’s all tweaking, which I documented as I went.

I’ll detail the two layers of customization: what any notebook needs, and what’s specific to this Thinkpad.

Laptop-specific configs

A notebook has problems a desktop doesn’t: battery, suspend, lid, brightness, trackpad. Those are the parts Omarchy default doesn’t cover the way I want.

Power management with TLP

Omarchy defaults to power-profiles-daemon. I swapped it for TLP, which gives granular control over CPU scaling, battery thresholds and dynamic profiles based on AC vs battery.

sudo pacman -S tlp tlp-rdw
sudo systemctl mask power-profiles-daemon.service
sudo systemctl enable --now tlp.service

The mask is necessary because upower pulls power-profiles-daemon back in if you just disable it.

Charge thresholds: 60% to start, 85% to stop. The notebook spends most of its time plugged in on the office desk, and keeping the battery at 100% 24/7 wrecks capacity over time. With 60/85, the battery spends most of its time in the healthy lithium range and still has decent usable capacity.

Profiles: balanced with balance_power on battery, performance on AC. TLP’s low-power was too aggressive on the Core Ultra 5 235U, window and terminal response became noticeable. Balanced gives the best consumption/responsiveness ratio for normal use.

There’s a gotcha: tlp auto after tlp ac doesn’t always re-apply the battery profile. I wrote a small script bound to Super+Ctrl+P that reads the current state and calls tlp bat or tlp ac explicitly:

#!/bin/bash
set -euo pipefail

profile=$(cat /sys/firmware/acpi/platform_profile 2>/dev/null || echo unknown)
on_ac=$(cat /sys/class/power_supply/AC*/online 2>/dev/null | head -1 || echo 0)

if [[ "$profile" == "performance" ]]; then
  if [[ "$on_ac" == "1" ]]; then
    sudo /usr/bin/tlp auto >/dev/null
    label="Plugged in — back to AC auto"
  else
    sudo /usr/bin/tlp bat >/dev/null
    label="On battery — normal profile"
  fi
  notify-send -t 2000 "Performance mode: off" "$label" 2>/dev/null || true
else
  sudo /usr/bin/tlp ac >/dev/null
  notify-send -t 2000 "Performance mode: on" "Forcing AC profile" 2>/dev/null || true
fi

In waybar, a custom module custom/perf shows the current state (󰓅 PERF, 󰌪 ECO, or empty for balanced) and accepts a click to toggle. The output script is tiny:

#!/bin/bash
p=$(cat /sys/firmware/acpi/platform_profile 2>/dev/null)
case "$p" in
  performance) printf '󰓅 PERF' ;;
  low-power)   printf '󰌪 ECO'  ;;
  balanced|"") printf ''       ;;
  *)           printf '%s' "$p" ;;
esac

Suspend, hibernate, and the lid

This is what changed compared to the notebooks I used in 2015. The T14 Gen 6 closes the lid, suspends, and wakes up when you open it. No bug, no weird delay, no needing to log in again mid graphical session. Hyprlock kicks in after the suspend, accepts fingerprint or password, and brings me back to the desktop in seconds. This is the behavior Apple has had for years and that on Linux used to be an adventure. In 2026, on modern hardware with kernel 6.11+, it just works.

Mem sleep mode is s2idle (no deep sleep). Hibernation is enabled via a ~30 GB Btrfs swapfile and resume=/dev/mapper/root resume_offset=... on the Limine kernel cmdline. I rarely use it, but it’s there.

Hypridle has aggressive timeouts for a laptop:

• 2.5 min → screensaver
• 5 min → lock
• 5.5 min → DPMS off + keyboard backlight off

After lock, another 5 min and the screen turns off completely. On unlock, it restores screen and keyboard brightness to the previous level. These timings are much shorter than on the desktop (20-40 min there). The battery difference over a day is measurable.

Brightness and keyboard backlight

brightnessctl controls both. Fn+Space toggles the keyboard backlight across three levels. Hypridle saves the current level before turning off and restores it on resume. Command I use in the script:

brightnessctl -sd '*::kbd_backlight' set 0    # save and turn off
brightnessctl -rd '*::kbd_backlight'          # restore

Touchpad

In hypr/input.conf:

touchpad {
    natural_scroll = true
    clickfinger_behavior = true
    disable_while_typing = true
    scroll_factor = 0.4
}
gesture = 3, horizontal, workspace

clickfinger_behavior swaps the 2-finger click as right-click (more comfortable than hitting the lower-right zone). disable_while_typing is basic palm rejection. Three-finger horizontal swipes switch workspaces, the most useful gesture in Hyprland.

Thinkpad-specific configs

This is what’s specific to this model. Some things modern Linux handles on its own, others need explicit configuration.

Fingerprint sensor

Goodix MOC 27c6:6594, works with libfprint 1.94.9+ on kernel 6.11+. Package is fprintd.

sudo pacman -S fprintd
fprintd-enroll                        # right index finger by default
fprintd-enroll -f left-index-finger   # other finger

To make sudo accept fingerprint, I added auth sufficient pam_fprintd.so above the pam_unix.so line in /etc/pam.d/sudo. With sufficient, if the fingerprint passes, it authenticates directly. If it fails or I hit ESC, it falls back to the password prompt. This is genuinely worth it: dozens of times a day, sudo pacman -Syu or sudo systemctl restart something, and I just touch the sensor.

On hyprlock, I use hyprlock’s native configuration, not PAM:

auth {
    fingerprint {
        enabled = true
        ready_message = Scan fingerprint or type password
        present_message = Scanning...
        retry_delay = 250
    }
}

The PAM path gives a double prompt. Configured natively, hyprlock accepts fingerprint or password, whichever succeeds first unlocks.

On SDDM (initial login), I kept password only. The reason: the login password unlocks the GNOME keyring, and the fingerprint can’t provide plaintext for that. Once the keyring is unlocked, hyprlock can use fingerprint without issues.

In practice, sudo looks like that. Touch the sensor, authenticate, move on.

Brazilian Thinkpad keyboard

The Brazilian Thinkpad keyboard has an annoying quirk. The /? key sits where the right Ctrl would be (keycode 97), not in the traditional ABNT2 AB11 position (keycode 89). If you use the standard br(abnt2) layout, that key is inaccessible. It literally prints nothing.

The solution is the br(thinkpad) variant that exists in /usr/share/X11/xkb/symbols/br:

xkb_symbols "thinkpad" {
    include "br(abnt2)"
    name[Group1]="Portuguese (Brazil, IBM/Lenovo ThinkPad)";
    key <RCTL> { [ slash, question, degree, questiondown ] };
};

In hypr/input.conf:

kb_layout = br
kb_variant = thinkpad
kb_model = thinkpad60

And system-wide for TTY/X11:

sudo localectl set-keymap br-abnt2
sudo localectl set-x11-keymap br thinkpad thinkpad60

I wrote a small Python that reads raw scancodes from /dev/input/event* to diagnose these quirks. Useful when a key decides not to work and you need to find out if it’s hardware, kernel, or xkb.

Input method: fcitx5

Alongside the layout I install fcitx5. Input method, for those who don’t know, is the layer that turns a key sequence into characters. It handles deadkeys (tilde for nasalization, acute accent, circumflex), composing characters that aren’t on the keyboard (ç, Ç, uppercase accented letters), emoji support. In Qt or GTK apps, the input method also drives context menus for cedilla and accents.

Packages:

sudo pacman -S --needed fcitx5 fcitx5-configtool fcitx5-gtk fcitx5-qt

And the environment variables for toolkits to find fcitx5. I created ~/.config/environment.d/fcitx.conf:

INPUT_METHOD=fcitx
QT_IM_MODULE=fcitx
XMODIFIERS=@im=fcitx
SDL_IM_MODULE=fcitx

systemd’s environment.d is loaded before graphical sessions, so Brave, Alacritty, VS Code and any GTK/Qt app pick it up automatically. I enable autostart in Hyprland:

exec-once = fcitx5 -d

Typing ~a produces ã, 'e produces é, ç works as it should in every app. On a Brazilian Thinkpad keyboard, this is the difference between typing Portuguese naturally or hunting for each character.

SOF audio

Realtek ALC3306/ALC287 codec via Sound Open Firmware. Without sof-firmware, the kernel module loads but the DSP never boots and PipeWire silently falls back to auto_null. Result: you think the speaker is on mute, but actually PipeWire has no device at all.

sudo pacman -S --needed sof-firmware alsa-ucm-conf pipewire pipewire-pulse wireplumber

If you need to force SOF instead of legacy HDA:

echo "options snd-intel-dspcfg dsp_driver=3" | sudo tee /etc/modprobe.d/alsa.conf

Reload without reboot:

sudo modprobe -r snd_sof_pci_intel_mtl
sudo modprobe snd_sof_pci_intel_mtl
systemctl --user restart wireplumber pipewire pipewire-pulse

Firmware updates via fwupd

fwupdmgr update works, but with Limine there’s a gotcha: fwupd tries to write to /boot/EFI/systemd/ or /boot/EFI/arch/, which don’t exist. The workaround:

sudo mkdir -p /boot/EFI/arch
sudo fwupdmgr update -y --no-reboot-check
fwupdmgr get-history  # should show "Success"

HiDPI / fractional scaling

14" panel at 1920x1200, Hyprland’s free resolution. Omarchy’s auto 1.5x felt too chunky. I pinned it at 1.333x:

env = GDK_SCALE,1
monitor=,preferred,auto,1.3333,vrr,2

Effective 1440x900. GTK with GDK_SCALE=1 renders 1:1 with Hyprland (no double magnification). VRR mode 2 only in fullscreen, because LCD panels tend to flicker on static content with VRR active.

Brave and Chromium flags to render well at this scale:

--ozone-platform=wayland
--enable-features=WaylandFractionalScaleV1,UseOzonePlatform,VaapiVideoDecoder,VaapiVideoEncoder
--enable-gpu-rasterization

VAAPI makes a real difference on YouTube battery life.

Tuning Omarchy to be mine

Omarchy comes with good defaults. What I adjust stacks on top of them, without touching ~/.local/share/omarchy/ (which is clobbered by omarchy-update). All customization lives in ~/.config/.

Infra: Btrfs, snapshots, Snapper

Omarchy already ships with Btrfs and separate subvolumes:

@home separated means ~/.cache, ~/.config/BraveSoftware, etc. don’t bloat root snapshots. Snapshot is for system, not profile.

Swap: 4 GB zram at priority 100 (hit first), plus a 30 GB swapfile at priority 0 (enables hibernation, sized to match RAM).

The snapshot stack: Snapper takes a snapshot before and after every pacman -Syu via snap-pac. limine-snapper-sync writes those snapshots into the Limine menu, so you can boot into a previous snapshot to roll back. If something breaks after an update, you hold a key on boot, pick the pre-update snapshot, boot read-only to verify, and if it’s good, run snapper rollback.

Omarchy leaves snapper-cleanup.timer and snapper-boot.timer disabled by default. I enabled both and configured retention to fit on a 1 TB SSD without blowing up:

TIMELINE_LIMIT_HOURLY=10
TIMELINE_LIMIT_DAILY=0
TIMELINE_LIMIT_WEEKLY=1
TIMELINE_LIMIT_MONTHLY=1
NUMBER_LIMIT=50

A detail that costs debug time if you forget: Docker and Ollama write gigabytes into /var/lib/docker and /var/lib/ollama. If that falls inside @, snapshots go catastrophic. Each Docker image or Ollama model downloaded triples in size. I created nested subvolumes for both, with chattr +C to disable CoW:

sudo btrfs subvolume create /var/lib/docker
sudo chattr +C /var/lib/docker
sudo btrfs subvolume create /var/lib/ollama

This has to be done BEFORE Docker or Ollama writes any data. If they already have data there, you need to migrate.

NFS to the Synology NAS

My Synology exposes three volumes. On the desktop, I mount them the usual way. On the notebook, it has to be more defensive. The notebook moves around, forgets networks, connects to public WiFi. Notebook’s fstab:

nfs4  _netdev,noauto,nofail,x-systemd.automount,x-systemd.idle-timeout=10min,x-systemd.mount-timeout=15s,noatime,nodiratime,nconnect=4,actimeo=10,soft,timeo=30,retrans=2

Critical difference vs the desktop: soft with short timeouts (doesn’t hang forever), x-systemd.idle-timeout=10min (auto-unmount when idle), no network-online.target in the require (doesn’t slow boot). Practical result: cd /mnt/gigachad at home mounts lazily, away from home it fails fast without locking the shell.

Another important detail: my user on the notebook has UID 1026, which matches the share permissions on the Synology. Linux defaults to creating users at 1000, the Synology enforces identity via UID on the wire. If the UIDs don’t match, you can’t read the files, or worse, you write as nobody. I ran the usermod/groupmod from a TTY (with the user logged out) to remap the user to 1026/1026 and did chown -R on /home.

Public WiFi hardening

The notebook will leave the house. In an airport or café, I don’t want to announce hostname, don’t want a trackable MAC, don’t want a service listening on an open port.

/etc/NetworkManager/conf.d/00-macrandomize.conf:

[device]
wifi.scan-rand-mac-address=yes

[connection]
wifi.cloned-mac-address=stable
ethernet.cloned-mac-address=stable
connection.stable-id=${CONNECTION}/${BOOT}

ipv6.ip6-privacy=2
ipv6.addr-gen-mode=stable-privacy

Random MAC per scan (passive anti-fingerprinting). Stable cloned MAC per SSID (captive portals don’t re-prompt you every time) but different MACs between networks. IPv6 with temporary addresses and interface ID derived from a stable secret, not from the MAC (no EUI-64 leak).

/etc/systemd/resolved.conf.d/hardening.conf:

[Resolve]
LLMNR=no
MulticastDNS=no

Kills hostname broadcast on LLMNR and mDNS. I also disable avahi:

sudo systemctl disable --now avahi-daemon.service avahi-daemon.socket

UFW firewall:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw --force enable

SSH server is already off by default on Omarchy. Nothing listening. Even if the firewall leaks, there’s no surface.

All of it rolls into a single initial setup ritual.

SSH agent persistence (keyring + keychain)

If you use SSH seriously, you want to type the passphrase once per boot and have ssh, git push, scp stay silent for the rest of the day. On current Arch there’s a catch: gnome-keyring 50 dropped its SSH component, and the replacement (gcr-ssh-agent) is a plain in-memory agent with no passphrase persistence. The “remember this key” checkbox you saw in old guides simply doesn’t exist anymore.

The combination that works has three pieces:

1. gcr-ssh-agent.socket managed by systemd serves SSH_AUTH_SOCK at $XDG_RUNTIME_DIR/gcr/ssh
2. pam_gnome_keyring on SDDM login unlocks the keyring with the login password (used by GUI apps like Brave, not by SSH)
3. keychain (wrapper) keeps an ssh-agent alive across logouts, overrides SSH_AUTH_SOCK to point at that persistent agent, and caches the PID in ~/.keychain/<host>-sh

First, install the keyring:

sudo pacman -S --needed gnome-keyring seahorse keychain

Then edit /etc/pam.d/sddm so the login password unlocks the keyring automatically. Add at the top:

-auth      optional    pam_gnome_keyring.so

And at the end:

-session   optional    pam_gnome_keyring.so    auto_start

The leading hyphen (-auth, -session) marks it optional, so if the module fails to load, login doesn’t break.

Pin SSH_AUTH_SOCK for graphical and TTY sessions via ~/.config/environment.d/ssh-agent.conf:

SSH_AUTH_SOCK=%t/gcr/ssh

%t resolves to $XDG_RUNTIME_DIR, something like /run/user/1026. Enable the gcr socket and user linger (so user daemons survive logout):

systemctl --user enable --now gcr-ssh-agent.socket
sudo loginctl enable-linger $USER

Finally, in ~/.config/bash/init.sh, keychain starts or reuses the agent:

if command -v keychain &>/dev/null && [[ -r ~/.ssh/id_ed25519 ]]; then
  eval "$(keychain --eval --quiet ~/.ssh/id_ed25519)"
fi

--eval emits shell assignments (SSH_AUTH_SOCK, SSH_AGENT_PID) pointing to keychain’s agent, overriding the gcr path set by environment.d. --quiet silences the banner once the key is loaded.

Flow in practice: boot → first terminal → keychain prompts for the passphrase once → key stays loaded. Logout → login again → new shells reattach to the same agent (via ~/.keychain/<host>-sh) → zero prompts. ssh-add -l confirms the key is there, echo $SSH_AUTH_SOCK confirms it’s at keychain’s path.

When you’ll re-enter the passphrase: reboot, ssh-add -D, or keychain --clear. In normal use, once a day.

Bash instead of ZSH

On the desktop I use ZSH. On the notebook I went with Bash to align with Omarchy’s default, without having to maintain a parallel stack of modular layers. ~/.bashrc is a symlink to ~/.config/bash/bashrc, which sources Omarchy’s defaults first and then stacks my customizations:

source ~/.local/share/omarchy/default/bash/rc
source ~/.config/bash/envs.sh
source ~/.config/bash/aliases.sh
source ~/.config/bash/mounts.sh
source ~/.config/bash/init.sh
source ~/.config/bash/secrets    # gitignored, chmod 600

envs.sh has what’s mine: OpenRouter base URL, Ollama pointing to the LAN GPU box (192.168.0.14), AWS region, Hugo analytics, zoxide and SSH agent configs. aliases.sh has TLP shortcuts, an alias for shell-gpt via Docker, and functions to harden PATH when running makepkg or yay (prevents binary injection via a malicious user config).

init.sh does the integration work. Atuin with a manual bind for Ctrl-R (so the up arrow keeps bash’s default history-search, which I use more). Keychain loading ~/.ssh/id_ed25519 once per boot and reusing it across shells (no need to re-authenticate SSH every time). Blesh if installed (ZSH-style autosuggestions for Bash). And a function that has PROMPT_COMMAND set the window title to the current pwd and the running command:

__title_idle() { printf '\033]2;%s\007' "${PWD/#$HOME/~}"; }
__title_busy() {
  local cmd="${BASH_COMMAND}"
  [[ "$cmd" == "__title_"* || "$cmd" == *"PROMPT_COMMAND"* ]] && return
  printf '\033]2;%s — %s\007' "${PWD/#$HOME/~}" "$cmd"
}
if [[ -n "${PROMPT_COMMAND-}" ]]; then
  PROMPT_COMMAND="__title_idle; ${PROMPT_COMMAND}"
else
  PROMPT_COMMAND="__title_idle"
fi
trap '__title_busy' DEBUG

Idle, the title shows just the pwd. With a command running, trap DEBUG catches the BASH_COMMAND and updates the title. Waybar’s hyprland/window picks that up and displays it.

For the modern Rust toolbelt, the list:

sudo pacman -S --needed \
  eza bat fd ripgrep sd git-delta dust procs bottom duf tokei hyperfine \
  zoxide atuin tldr starship

eza replaces ls. bat replaces cat with syntax highlighting. fd replaces find. ripgrep replaces grep. sd replaces sed. delta plugs into git for colored side-by-side diff. dust for visual du. procs for ps. btm (bottom) for top. duf for df. tokei counts lines of code. hyperfine for command benchmarking. zoxide is cd with memory (very useful). atuin is shell history with encrypted sync (I point it to my home server via sync_address = "http://192.168.0.90:8888"). starship is the prompt. tldr is a man page in 10 lines.

The atuin key has to be backed up offline. If you lose it, you lose the encrypted history. I saved mine in my self-hosted Bitwarden (Vaultwarden), documented in the Bitwarden self-hosted article.

Git pipes diff through delta:

[core]        pager = delta
[interactive] diffFilter = delta --color-only
[delta]       navigate side-by-side line-numbers hyperlinks, light=false
[merge]       conflictstyle = zdiff3

Hyprland and Waybar

Visual and UX customizations on top of the default.

In hypr/looknfeel.conf, smaller gaps (2/5 vs the default 5/10), slide animation between workspaces, VFR on (reduces consumption when the screen is static), allow_session_lock_restore (if hyprlock crashes, it goes back to the lock screen instead of dumping you on the desktop).

In hypr/bindings.conf:

On Waybar, three custom modules I recommend:

Window title: the hyprland/window module shows what’s focused. In bash, PROMPT_COMMAND updates the title to something like “~/Projects/blog — hugo server”. So in waybar the directory and running command show up, without me needing to look at the terminal.

"hyprland/window": {
    "format": "{title}",
    "max-length": 50,
    "rewrite": { "(.{47}).+": "$1…" }
}

Perf mode: custom/perf runs a script that reads TLP state and shows an icon:

"custom/perf": {
    "exec": "~/.config/scripts/perf-waybar.sh",
    "interval": 3,
    "format": "{}",
    "on-click": "~/.config/scripts/perf-toggle.sh"
}

Empty for balanced, 󰓅 PERF for performance, 󰌪 ECO for low-power. Click toggles. Useful to quickly see what mode the machine is in.

Claudebar: I integrated claudebar as a custom module that shows the Claude Code session usage % and extra spend inline in waybar. No need to open another window.

The clock:

"clock": {
    "format": "{:L%A %d %B - %H:%M}",
    "format-alt": "{:L%A W%V %Y - %H:%M}"
}

Shows “Thursday 17 April - 14:32” by default, click toggles to “Thursday W16 2026 - 14:32” with the ISO week number, useful for planning articles and tasks.

Self-hosted Atuin

Atuin runs on my home server at 192.168.0.90:8888. I made a separate account for the notebook (akitaonrails-thinkpad), I don’t mix history with the desktop on purpose. atuin sync runs every 5 minutes and all history is encrypted before going to the server. The server doesn’t see the commands, only encrypted bytes.

Conclusion: picking a notebook for Linux

One thing I learned on this journey: picking a notebook to run Linux comfortably is not trivial. You have to check the ArchWiki for your specific model before buying. The T14s Gen 6 AMD page, for example, catalogs every hardware quirk and how to work around it. Without that reference, you discover the problems during install.

Rule I follow: never buy a freshly-released model. Let 6 to 12 months go by after launch. That gives the community time to iron out bugs, drivers to land mainline, the ArchWiki to have a decent page, libfprint to include the fingerprint sensor, and the kernel to cover WiFi and the IR camera. Buying on day one means signing up as a beta tester.

Brands with a decent Linux track record: Lenovo (especially Thinkpad, they ship Ubuntu and Fedora pre-loaded), Dell (the XPS and Latitude lines), Asus (Zenbook and ROG have reasonable support), Framework (built for Linux from the factory). Any recent Mac is cut off from Linux mainline or runs through Asahi with caveats.

The Thinkpad T14 Gen 6 isn’t the prettiest notebook I could have bought. But it’s rugged, it has the right ports, the fingerprint sensor works, and the plastic shell lets it fall, get scratched, travel in a backpack without making me nervous. To serve as a remote debug companion, it’s what I needed. If that’s your use case too, I recommend it. If you want OLED and metal, go Zenbook or T14s. Every premium comes with a compromise, no Linux notebook in 2026 is perfect.

Everything I described here is versioned in a private repo of mine. If I need to reinstall tomorrow, I run half a dozen steps in order and I’m back at the same place. That’s the whole point of keeping config in Git: notebook is commodity, config is mine.

Hyprland doesn’t play nice with NVIDIA

You can use it. But there are several little problems, particularly with Hyprlock, and particularly with DPMS where I leave my computer idle, it locks itself, and after a timeout turns off the monitors to save power, avoid burn-in, etc.

When I try to wake it from sleep, Hyprlock crashed and I have to jump to another TTY to restart it. I even wrote a ~/.local/bin/hypr_unlock.sh script like this:

hyprctl --instance 0 'keyword misc:allow_session_lock_restore 1'
hyprctl --instance 0 'dispatch exec hyprlock'

But then I unlock and see that my Brave crashed too. NVIDIA really doesn’t like the monitor being turned off while it’s active. People said this happened in Hyprlock 0.9.1, but I’m already on 0.9.2 and it still crashes. I tried enabling services like nvidia-suspend/resume/hibernate, but nothing worked either.

At the end of the day I decided it’s not worth fighting with this: I have an AMD 7850X3D, and this CPU has an iGPU (integrated GPU), an AMD Raphael, which for things like rendering a window manager is more than powerful enough.

First, detect the GPUs:

❯ ls /dev/dri/by-path
Permissions Size User Date Modified Name
lrwxrwxrwx     - root 21 Jan 15:22   pci-0000:01:00.0-card -> ../card1
lrwxrwxrwx     - root 21 Jan 15:22   pci-0000:01:00.0-render -> ../renderD128
lrwxrwxrwx     - root 21 Jan 15:22   pci-0000:1a:00.0-card -> ../card2
lrwxrwxrwx     - root 21 Jan 15:22   pci-0000:1a:00.0-render -> ../renderD129

To find out which is AMD and which is NVIDIA, just run:

❯ lspci | grep -i vga
01:00.0 VGA compatible controller: NVIDIA Corporation GB202 [GeForce RTX 5090] (rev a1)
1a:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Raphael (rev c9)

Done. From the PCI ID we know card1 is NVIDIA and card2 is AMD. Now I need to configure my ~/.config/hypr/hyprland.conf:

....
# NVIDIA environment variables
env = NVD_BACKEND,direct
#env = LIBVA_DRIVER_NAME,nvidia
env = LIBVA_DRIVER_NAME,radeonsi
#env = __GLX_VENDOR_LIBRARY_NAME,nvidia

# Comment these out when using AMD as primary
#env = __NV_PRIME_RENDER_OFFLOAD,1
#env = __VK_LAYER_NV_optimus,NVIDIA_only

# card1=nvidia, card2=amdgpu (verify with: cat /sys/class/drm/card*/device/uevent)
# AMD first for iGPU primary:
env = AQ_DRM_DEVICES,/dev/dri/card2:/dev/dri/card1

env = ELECTRON_OZONE_PLATFORM_HINT,auto

I left the NVIDIA-specific settings commented out; none of them can be active. But the most important line is AQ_DRM_DEVICES, which lists the order for Hyprland to pick the GPU. Card2/AMD has to come first. Done, just reboot and move the HDMI cables to the iGPU output.

With that, I can now choose to offload only some apps to the NVIDIA using Prime. For that, I first created the script ~/.local/bin/nvidia-load.sh:

#!/bin/bash
__NV_PRIME_RENDER_OFFLOAD=1 __VK_LAYER_NV_optimus=NVIDIA_only __GLX_VENDOR_LIBRARY_NAME=nvidia "$@"

Finally, I configured some bindings in ~/.config/hypr/bindings.conf:

...
bindd = SUPER SHIFT, B, Blender, exec, ~/.local/bin/nvidia-load.sh blender
bindd = SUPER SHIFT, L, Bambu Studio, exec, ~/.local/bin/nvidia-load.sh bambu-studio
bindd = SUPER SHIFT, P, Blender, exec, ~/.local/bin/nvidia-load.sh plasticity
...

This way, only Blender, Plasticity, and Bambu Studio, which primarily use the NVIDIA to render 3D in real time. All the other apps open on the AMD iGPU.

AI tools like ComfyUI, Ollama, or LM Studio automatically recognize the NVIDIA and pick it. And with that I also have more free VRAM to load LLMs.

If you’re going to use XLibre/X.org, you can stay on NVIDIA just fine. But if you’re going to use Wayland, NVIDIA still isn’t fully stable, particularly with Hyprland. It’s less of a headache to drop in a second AMD GPU just for this.

The thing is, to be useful these tools need access to your filesystem so they can poke around your project files and analyze your code. And more: they need to run things like compilers, linters, and the everyday stuff like grep, sed, awk, ls, and other system commands.

Eventually, an LLM might fire off some random rm -rf / and start wiping things from your system, for example. The code itself, if it accidentally deletes something it shouldn’t, in theory you should be safe because your code should at the bare minimum be in a Git repo (GitHub, GitLab, etc.), so you’d just revert the change. But if the agent runs an rm outside your project directory, you can be in for all kinds of trouble.

It doesn’t happen often and all these tools have checks for it, including asking whether you really want to run a command. At the same time, they also have an option to let any command run during the session without asking — because at some point it gets tedious to “ok” every individual command. Everyone eventually gets lazy and says “screw it, run whatever you want”.

And you might be thinking “oh, my favorite tool is well-behaved, it always asks before running anything, so I’m in control”. Don’t forget: SUPPLY-CHAIN ATTACKS exist. Every other day some open source library gets compromised with malware and the programs that depend on those libs end up infected without anyone noticing. This has happened many times, in many NPM libraries for example. There’s no way to guarantee that even open source software is trustworthy. Always assume everything is insecure until proven otherwise, and treat these programs accordingly: with maximum restrictions.

To make sure these agents really aren’t going to do anything outside the project directory, the best option is to build a JAIL. Here’s the command for that:

bwrap --ro-bind /usr /usr \
      --ro-bind /bin /bin \
      --ro-bind /lib /lib \
      --ro-bind /lib64 /lib64 \
      --dev /dev \
      --proc /proc \
      --bind $(pwd) $(pwd) \
      --chdir $(pwd) \
      --unshare-all \
      --share-net \
      bash

bwrap is Bubblewrap, one of the components that make things like Flatpak possible. It creates a sandbox. The Bash that fires up when you run the command above is essentially in “jail” — locked in. Inside it we hand out read-only access to a few system directories in case it needs libraries and tools. That’s what --ro-bind is for.

But only the current directory pwd has write permission. Any command that runs inside the jail has no permission to write anywhere else on your system. Look at the example in the screenshot below where I try to delete a file in my $HOME:

It can’t even list the files in my home directory. Everything is invisible inside the sandbox. This is one of the upsides of apps running under Flatpak: they’re much more isolated than apps installed directly.

Inside this sandboxed bash we can now run opencode, crush, cursor or any other agent and be confident that they aren’t going to do anything stupid to your system.

To make life easier, I’d recommend creating a script like ~/.local/bin/ai-jail:

#!/bin/bash

# ai-jail — bubblewrap sandbox for AI coding agents
# Mounts the project dir read-write, auto-discovers home dotfiles with a
# deny-list for sensitive dirs, and isolates namespaces.
#
# Usage: ai-jail [--map PATH]... COMMAND [ARGS...]
#        ai-jail claude
#        ai-jail bash

PROJECT_DIR=$(pwd)
TEMP_HOSTS=$(mktemp /tmp/bwrap-hosts.XXXXXX)

trap 'rm -f "$TEMP_HOSTS"' EXIT

# ── Mise discovery ─────────────────────────────────────────────
REAL_MISE_BIN=$(type -p mise 2>/dev/null || echo "")

# ── Localhost fix (Go resolver needs /etc/hosts) ───────────────
printf '127.0.0.1 localhost ai-sandbox\n::1       localhost ai-sandbox\n' > "$TEMP_HOSTS"

# ── Parse --map / --rw-map arguments ─────────────────────────
EXTRA_MOUNTS=()
while [[ "${1:-}" == --map || "${1:-}" == --rw-map ]]; do
    FLAG="$1"
    MAP_PATH="$2"
    if [ -e "$MAP_PATH" ]; then
        if [[ "$FLAG" == "--rw-map" ]]; then
            EXTRA_MOUNTS+=("--bind" "$MAP_PATH" "$MAP_PATH")
        else
            EXTRA_MOUNTS+=("--ro-bind" "$MAP_PATH" "$MAP_PATH")
        fi
    else
        echo "Warning: Path $MAP_PATH not found, skipping." >&2
    fi
    shift 2
done

# ── Mise init command ──────────────────────────────────────────
if [ -n "$REAL_MISE_BIN" ]; then
    MISE_INIT="$REAL_MISE_BIN trust && eval \"\$($REAL_MISE_BIN activate bash)\" && eval \"\$($REAL_MISE_BIN env)\""
else
    MISE_INIT="true"
fi

# ── Dotfile deny-list (never mounted — sensitive data) ─────────
DOTDIR_DENY=(.gnupg .aws .mozilla .basilisk-dev .sparrow)

# Subdirs of ~/.config to hide (tmpfs over rw config mount)
CONFIG_DENY=(BraveSoftware Bitwarden)

# Subdirs of ~/.cache to hide (sensitive browser/app caches)
CACHE_DENY=(BraveSoftware basilisk-dev chromium spotify nvidia mesa_shader_cache)

# Dotdirs requiring read-write access
DOTDIR_RW=(.claude .crush .codex .aider .config .cargo .cache .docker)

# ── Helper functions ───────────────────────────────────────────
is_denied() {
    local name="$1"
    for d in "${DOTDIR_DENY[@]}"; do [[ "$name" == "$d" ]] && return 0; done
    return 1
}

is_rw() {
    local name="$1"
    for d in "${DOTDIR_RW[@]}"; do [[ "$name" == "$d" ]] && return 0; done
    return 1
}

# ── Auto-discover dot-directories in $HOME ─────────────────────
# Only directories — regular dotfiles (e.g. .claude.json) are NOT mounted.
# The tmpfs $HOME is writable so tools can create dotfiles as needed.
DOTFILE_MOUNTS=()
for entry in "$HOME"/.*; do
    [ -d "$entry" ] || continue
    name=$(basename "$entry")
    [[ "$name" == "." || "$name" == ".." ]] && continue
    is_denied "$name" && continue

    if is_rw "$name"; then
        DOTFILE_MOUNTS+=("--bind" "$entry" "$HOME/$name")
    else
        DOTFILE_MOUNTS+=("--ro-bind" "$entry" "$HOME/$name")
    fi
done

# ── Explicit dotfile mounts (regular files) ────────────────────
[ -f "$HOME/.gitconfig" ] && DOTFILE_MOUNTS+=("--ro-bind" "$HOME/.gitconfig" "$HOME/.gitconfig")
[ -f "$HOME/.claude.json" ] && DOTFILE_MOUNTS+=("--bind" "$HOME/.claude.json" "$HOME/.claude.json")

# ── Hide sensitive subdirs inside ~/.config (after rw mount) ───
CONFIG_HIDE_MOUNTS=()
for denied in "${CONFIG_DENY[@]}"; do
    [ -d "$HOME/.config/$denied" ] && CONFIG_HIDE_MOUNTS+=("--tmpfs" "$HOME/.config/$denied")
done

# ── Hide sensitive subdirs inside ~/.cache (after rw mount) ──
CACHE_HIDE_MOUNTS=()
for denied in "${CACHE_DENY[@]}"; do
    [ -d "$HOME/.cache/$denied" ] && CACHE_HIDE_MOUNTS+=("--tmpfs" "$HOME/.cache/$denied")
done

# ── Override ~/.local subdirs as rw (parent .local is ro) ──────
LOCAL_OVERRIDES=()
[ -d "$HOME/.local/state" ] && LOCAL_OVERRIDES+=("--bind" "$HOME/.local/state" "$HOME/.local/state")
for rw_share in zoxide crush opencode atuin mise yarn flutter kotlin NuGet pipx ruby-advisory-db uv; do
    [ -d "$HOME/.local/share/$rw_share" ] && LOCAL_OVERRIDES+=("--bind" "$HOME/.local/share/$rw_share" "$HOME/.local/share/$rw_share")
done

# ── GPU device mounts (NVIDIA + DRM) ─────────────────────────
GPU_MOUNTS=()
for dev in /dev/nvidia* /dev/dri; do
    [ -e "$dev" ] && GPU_MOUNTS+=("--dev-bind" "$dev" "$dev")
done

# ── Docker socket ────────────────────────────────────────────
DOCKER_MOUNT=()
[ -S /var/run/docker.sock ] && DOCKER_MOUNT+=("--bind" "/var/run/docker.sock" "/var/run/docker.sock")

# ── Shared memory (Chromium needs large /dev/shm) ───────────
SHM_MOUNT=()
[ -d /dev/shm ] && SHM_MOUNT+=("--dev-bind" "/dev/shm" "/dev/shm")

# ── Display passthrough (X11 + Wayland) ─────────────────────
DISPLAY_MOUNTS=()
DISPLAY_ENV=()

# X11 / XWayland socket
[ -d /tmp/.X11-unix ] && DISPLAY_MOUNTS+=("--bind" "/tmp/.X11-unix" "/tmp/.X11-unix")
[ -n "${DISPLAY:-}" ] && DISPLAY_ENV+=("--setenv" "DISPLAY" "$DISPLAY")
[ -n "${XAUTHORITY:-}" ] && {
    DISPLAY_MOUNTS+=("--ro-bind" "$XAUTHORITY" "$XAUTHORITY")
    DISPLAY_ENV+=("--setenv" "XAUTHORITY" "$XAUTHORITY")
}

# Wayland socket (lives in XDG_RUNTIME_DIR, typically /run/user/UID)
if [ -n "${XDG_RUNTIME_DIR:-}" ] && [ -d "$XDG_RUNTIME_DIR" ]; then
    DISPLAY_MOUNTS+=("--bind" "$XDG_RUNTIME_DIR" "$XDG_RUNTIME_DIR")
    DISPLAY_ENV+=("--setenv" "XDG_RUNTIME_DIR" "$XDG_RUNTIME_DIR")
    [ -n "${WAYLAND_DISPLAY:-}" ] && DISPLAY_ENV+=("--setenv" "WAYLAND_DISPLAY" "$WAYLAND_DISPLAY")
fi

# ── Assemble and launch ───────────────────────────────────────
echo "Jail Active: $PROJECT_DIR"

bwrap \
  --ro-bind /usr /usr \
  --symlink usr/bin /bin \
  --symlink usr/lib /lib \
  --symlink usr/lib /lib64 \
  --ro-bind /etc /etc \
  --ro-bind "$TEMP_HOSTS" /etc/hosts \
  --ro-bind /opt /opt \
  --ro-bind /sys /sys \
  --dev /dev \
  "${GPU_MOUNTS[@]}" \
  "${SHM_MOUNT[@]}" \
  --proc /proc \
  --tmpfs /tmp \
  --tmpfs /run \
  "${DOCKER_MOUNT[@]}" \
  "${DISPLAY_MOUNTS[@]}" \
  --tmpfs "$HOME" \
  "${DOTFILE_MOUNTS[@]}" \
  "${CONFIG_HIDE_MOUNTS[@]}" \
  "${CACHE_HIDE_MOUNTS[@]}" \
  "${LOCAL_OVERRIDES[@]}" \
  "${EXTRA_MOUNTS[@]}" \
  --bind "$PROJECT_DIR" "$PROJECT_DIR" \
  --chdir "$PROJECT_DIR" \
  --die-with-parent \
  --unshare-pid \
  --unshare-uts \
  --unshare-ipc \
  --hostname "ai-sandbox" \
  "${DISPLAY_ENV[@]}" \
  --setenv PS1 "(jail) \w \$ " \
  --setenv _ZO_DOCTOR 0 \
  bash -c "$MISE_INIT && ${*:-bash}"

This version is heavily customized. Read it through carefully because it has a deny-list so that only the directories you actually need inside the Jail are available. Some are read-write because Claude needs to be able to write to ~/.claude or Codex needs ~/.codex; several directories should never be inside the Jail like a Brave password store or BitWarden. Everything else you might need should be read-only. This script handles all of that.

Just chmod +x ~/.local/bin/ai-jail. Now you can run it directly or pass the command you want to run inside the sandbox:

~/.local/bin/ai-jail crush

In this version it’ll create a temporary $HOME directory in case it needs to write something temporary there. And I also set it up to map your ~/.config so the agents have access to your settings. If you need more stuff like environment variables and the like, modify it to map those too — but this is the bare minimum to put together a safe sandbox.

Be very careful with programs that run random commands on your system. Nothing is 100% safe, especially an LLM that can hallucinate at any moment and decide to delete things, or shady tools you downloaded without being sure of where they came from that might be malware in disguise. Always run truly suspicious things only in a VM, or at the very least, inside a jail like this one.

This isn’t just for AI agents, obviously. Any time you’re about to run any command you’re not sure about or that looks fishy, run it inside this jail.

As a bonus, note that I also map Mise into the container. If you’re on Omarchy, you should be using Mise too.

Specifically for Claude Code, which is what I use the most, I don’t like to leave everything authorized in automatic mode with --allow-dangerously-skip-permissions, but I also don’t like having to keep authorizing dumb stuff like every single domain it wants to search the web for (just searching is no problem at all) or any command that just lists things like ls or grep. So you can improve things by configuring directly in ~/.claude/settings.json:

{
  "permissions": {
    "allow": [
      "Bash(git add *)",
      "Bash(git commit *)",
      "Bash(git status *)",
      "Bash(git diff *)",
      "Bash(git log *)",
      "Bash(git branch *)",
      "Bash(git checkout *)",
      "Bash(git switch *)",
      "Bash(git stash *)",
      "Bash(git show *)",
      "Bash(git fetch *)",
      "Bash(git pull *)",
      "Bash(git merge *)",
      "Bash(git tag *)",
      "Bash(git remote -v*)",
      "Bash(git rev-parse *)",
      "Bash(git ls-files *)",
      "Bash(ls *)",
      "Bash(find *)",
      "Bash(grep *)",
      "Bash(wc *)",
      "Bash(cat *)",
      "Bash(head *)",
      "Bash(tail *)",
      "Bash(file *)",
      "Bash(which *)",
      "Bash(echo *)",
      "Bash(pwd)",
      "Bash(cd *)",
      "Bash(ps *)",
      "Bash(env *)",
      "Bash(printenv *)",
      "Bash(mkdir *)",
      "Bash(cp *)",
      "Bash(mv *)",
      "Bash(touch *)",
      "Bash(npm *)",
      "Bash(npx *)",
      "Bash(yarn *)",
      "Bash(pnpm *)",
      "Bash(bun *)",
      "Bash(node *)",
      "Bash(ruby *)",
      "Bash(bundle *)",
      "Bash(rails *)",
      "Bash(rake *)",
      "Bash(go *)",
      "Bash(cargo *)",
      "Bash(rustc *)",
      "Bash(python *)",
      "Bash(pip *)",
      "Bash(docker compose *)",
      "Bash(docker ps *)",
      "Bash(docker logs *)",
      "Bash(docker images *)",
      "Bash(make *)",
      "Bash(gh *)",
      "Bash(curl *)",
      "Bash(jq *)",
      "Bash(sed *)",
      "Bash(awk *)",
      "Bash(sort *)",
      "Bash(uniq *)",
      "Bash(diff *)",
      "Bash(* --version)",
      "Bash(* --help)",
      "WebSearch",
      "WebFetch"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(rm -r *)",
      "Bash(sudo *)",
      "Bash(chmod 777 *)",
      "Bash(git reset --hard *)",
      "Bash(git clean *)",
      "Bash(git push --force *)",
      "Bash(git push -f *)",
      "Bash(docker rm *)",
      "Bash(docker rmi *)",
      "Bash(docker system prune *)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(git rebase *)",
      "Bash(git branch -D *)",
      "Bash(git branch -d *)",
      "Bash(rm *)",
      "Bash(kamal *)",
      "Bash(docker run *)",
      "Bash(docker exec *)",
      "Bash(docker stop *)"
    ],
    "defaultMode": "acceptEdits"
  },
  "enabledPlugins": {
    "gopls-lsp@claude-plugins-official": true,
    "typescript-lsp@claude-plugins-official": true,
    "pyright-lsp@claude-plugins-official": true,
    "rust-analyzer-lsp@claude-plugins-official": true,
    "github@claude-plugins-official": true,
    "pr-review-toolkit@claude-plugins-official": true,
    "frontend-design@claude-plugins-official": true
  },
  "alwaysThinkingEnabled": true
}

Look up the documentation (or just ask Claude itself) about more customizations you can do in this file to better fit your project type or workflow.

This is basically how a Docker or Podman container works too. I explained that in my video about Docker. If you haven’t watched it yet, I recommend it.

The questions I get the most, literally every single day, come in this format: “Akita, should I go to college?”, “Akita, what do you think I should study?” and variations of that.

Dude, I don’t know you, I will never know nor will I ever be interested in knowing who you are, what you aim for, your aspirations, ambitions, tastes, preferences. Nothing. Neither me nor ANYONE ELSE. Only you know what’s best for you. If you don’t know, go find out. That’s what LIVING means.

What you won’t admit is that you want someone you consider more important or relevant to approve your choice and tell you that you got it right.

Never expect that from me, I will never validate you.

I will always say: FIGURE IT OUT. That’s how I became who I am. I never followed anyone, I never asked anyone what I should do. I just went there and did it. Fell on my face, got up, tried again. That’s life.

Let me show you what actually BOTHERS me:

Let’s check the manual?

DHH took the trouble to write a manual. It has a section called “Security”. A quick Google search would have found it. Or this other gem:

How do you want to become a “DEVOPS” (who has to know EVERYTHING about Linux) starting like this? Already off to a bad start. Park your butt in the chair, roll up your sleeves, and test them one by one, and learn.

Linux for Beginners?

That said, watch my video. But since I’ve been talking a lot about Omarchy already, I’ll say that yes, this is what I use in my day to day and it’s the only one I’ll recommend for the near future (I may change my mind later). Having used distros ever since Linux was invented in the early 90s, I know there are dozens of distros and even I don’t have the patience to try them all.

Why Omarchy?

First, because it made the right choice of base distro: Arch Linux. I consider it the best distro out there today for two reasons: it has very little “bloat” (it doesn’t install a bunch of stuff you’ll never use, like Ubuntu, Fedora, Mint, Deepin, or any of those other “beginner-friendly” distros).

Second, Arch Linux has the AUR, which is a repository of user-made packages that has basically everything. You don’t need to go hunting for third-party repositories or install things manually. With a single command, yay, you install everything. There’s none of that apt-repository add nonsense or having to make install or anything like that. The AUR manages all of it for you.

Third, it installs Hyprland (which I was already using and liked), with very good configs, and a very good package selection. Everything I would install manually myself. So it’s a thousand times easier to get what would take me much more work to do on my own. Check my series of posts about Omarchy to see those options.

Linux for Beginners?

Beginner at what?

I hate this question. If you’re really an amateur user, not a programmer, maybe you’re an accountant, maybe you’re just a teenage gamer. The first question I ask is: why do you want to use Linux?

Let’s say it’s because you heard it’s more secure (and it actually is). Then it doesn’t matter, any distro will do. Install Ubuntu, install Manjaro, install Garuda. It makes no difference, because you’ll never deal with anything under the hood. You’ll open Chrome, open Steam, and that’s it. The rest is going to be web apps.

Let’s say it’s just for gaming, then install Bazzite on your mini-PC or handheld. Or just install your games on a separate Windows box just for gaming like I did. Whatever.

Or just stick with Windows or macOS. If you’re a total amateur, you’re probably going to use the same weak password for everything, and click on WhatsApp links without checking who they’re from. It literally makes no difference which OS you use. No security from any OS will protect you from your bad habits and ignorance.

If you’re a beginner at programming or tech, then I have no mercy: learn Linux properly. You want to be a professional, be a professional, learn the right way: learn to have 100% control over your own machine. There’s no step-by-step or tutorial for that. It’s something you’re going to do continuously for the rest of your life. I’ve been in this field for over 30 years and I still learn new things every day.

Hardware

The BIGGEST problem anyone is going to face, with ANY distro, is going to be hardware support. And that’s why you shouldn’t just follow what someone recommends to you:

Nobody has the same PC as you.

What’s your notebook? A Lenovo? A Dell? A Positivo? From what year? Which model?

Everything varies: which Wi-Fi and Bluetooth device? Which graphics card? Which firmware is running? With which power profile support? Do you need FIDO2 devices for things like a fingerprint reader? Hardware keys? Does your machine have TPU? Will you need Secure Boot?

I don’t know. You are the one who has to know.

A practical example, I have an Asus Zephyrus G14 notebook that I use with Windows because it only lives in my workshop to run Bambu Studio to control my X1C 3D Printer. I haven’t gotten around to installing Omarchy on it, but let’s say I wanted to. Would it work?

Fortunately there’s a page on the ArchWiki dedicated to this model. It looks like everything works “out-of-the-box”. But if it were the previous year’s version I’d have to check extra items. There are Wi-Fi issues, for example.

Each different machine will have different problems.

Live Env and Ventoy

“So what do I do, you [censored]?”

That’s why pretty much every good distro offers an installation ISO that comes with a live environment. I’ve seen a lot of people on Windows who have trouble knowing what to do with an ISO. It’s very simple.

The easiest program to use is Balena Etcher. You download the file with the .iso extension, whether from Ubuntu, Mint, Elementary, etc (ALWAYS FROM THE OFFICIAL SITE!!!!). Open Balena and there are only 2 steps: select the image (the ISO file), select the drive (your pen drive, careful not to pick your HD!), and done.

Now just boot your PC and go into the BIOS to select the pen drive to boot from, or use a key like F12 (varies from BIOS to BIOS) to have UEFI select your pen drive.

That will boot the Live Environment straight from the pen drive.

Most distros start by opening a “Welcome” screen similar to the one above. This installer app is called Calamares and everyone with a graphical installer uses it. That’s why it looks similar across all of them. It’s the same step-by-step. If you’ve installed one distro, you’ve installed them all.

But you don’t have to follow Calamares. You can close it. And now you’re already in the graphical environment of the distro you chose to install. USE IT. Try to configure your Wi-Fi, try to pair your Bluetooth headphones or mouse, try to turn on the webcam, put in a micro-SD card and see if it shows up. Try to browse the web and feel the performance.

If at this point you can do all the basic things, it means the chances that everything will work are high. If at this point you already start having problems, like not being able to connect to your Wi-Fi, that distro is probably going to give you a headache. Start by going to Google and see if somebody has already solved the problem for your notebook or PC model, before continuing with Calamares.

Let’s say you decided to take the day to test several distros to see which one runs best on your machine. Great call, but you’ve probably figured out that it’s going to be a huge pain to have several pen drives, one for each distro. Or having to keep going back to Windows and using Balena to overwrite a new distro on your only pen drive.

You don’t need to do that.

You just have to first download and install Ventoy on your pen drive. Check the documentation on their site, but it’s ridiculously simple.

After installing it on your pen drive, now just copy ALL THE ISOS you want at once onto the pen drive. When you boot from it, you’ll enter the Ventoy menu, which lets you pick any of the ISOs you copied there. If you didn’t like the current distro, just reboot into Ventoy again and pick another ISO. It’s that simple.

Distrobox

Let’s say you’re a programmer, or a devops, or any tech professional. Your concern isn’t so much the graphical interface (which you can test with Ventoy), but whether the OS infrastructure is going to work with your development requirements.

Let’s say you use Fedora. I wonder, if I go to Mint, will it have the K8s packages the way I need them? Does it support the Java version I use? If I build a .deb package on my Fedora, will it install properly on Ubuntu?

Having to dual boot or install a VM feels too heavy, too much work, just to test 2 command lines, for example.

That’s what Distrobox is for. It needs Docker or Podman already installed on your machine. But after that you just do:

distrobox create -n debian-test --init --image debian:latest --additional-packages "build-essential"

Once the box is created you just enter it:

distrobox enter debian-test

Done, you’re inside Debian, super fast. Since it’s a Docker container, you can map directories on your local machine into the container, so everything stays integrated. And the most important thing: it loads super fast, because it’s just a Docker container.

The Quick Start guide explains all of that and has this video with a tour to demonstrate how it works:

Conclusion

Seriously. With Distrobox there’s no excuse not to test another distro in 2 minutes. Stop wasting time sending DMs to “influencers”. See for yourself! If you’re not capable of doing that, maybe you’re in the wrong profession.

Every “dev” or tech professional, whether devops, cybersec, data analyst, blah blah blah, whatever the trendy title is these days, MUST have control over their own machine. MUST know how to deal with security (that’s why I wrote posts about Vaultwarden, Cloudflare, SSH, etc).

IT’S YOUR RESPONSIBILITY!

Don’t outsource your responsibility to others. Don’t look for validation. Be promiscuous and test whichever distros you want, and do whatever you want on those distros: they are yours! There’s no such thing as a “distro for beginners”, “distro for devs”, “distro for devops”. A distro is a distro. Linux is Linux. It’s all the same, what varies is your skill. If you don’t have the skill: earn it! Learn! Break your head over it! Pull all-nighters tuning configs! Read the official documentation! Don’t waste time thinking you’re going to learn on social media. You won’t.

I’ve been using Linux since the early 90s and I don’t stick with Slackware just because it was the first one I learned and I feel a need to validate my first choice. I use whichever ones I want. Right now, I had my own Hyprland setup, and I decided I wanted to learn and use Omarchy. I spent the week banging my head against it, and wrote half a dozen blog posts. And now I’ve learned. I know Omarchy: one more for the collection.

Just head to the official site and click “ISO” to download. Use Rufus or Balena Etcher on Windows (or Caligula on Linux) to burn it to a USB stick and boot from it. From there, follow the step-by-step and in less than 5 minutes you’ll have everything installed.

As I explained in the first article, I did it differently: I installed pure Arch Linux, Desktop style, with Hyprland + SDDM. Then I installed Omarchy using the manual command line:

curl -fsSL https://omarchy.org/install | bash

You can do it either way. The second gives you more control, but after gaining more experience and reading the install scripts, I recommend downloading the Omarchy ISO itself. It really is easier.

Limine vs Grub

The reason I went the manual route was because I wasn’t sure if Omarchy supported BTRFS rollback via snapshots. I had heard that the Limine bootloader didn’t support that. But I was wrong: Omarchy installs Limine with Snapper support (which is similar to Timeshift, the one I usually use). Read ArchWiki section 6.2. So this should be a superior option to my GRUB+Timeshift setup that I talked about in the first article.

Since I already installed it manually, I’ll keep things as they are because in practice it’s the same thing. But if I were installing again, I’d go with Limine+Snapper just to try it out.

This means there’s support for snapshotting your entire filesystem with BTRFS before a package update, and if something goes wrong, you can reboot and roll back to a previous snapshot. That gives you peace of mind so you don’t lose a whole day trying to fix something if an important system package ships buggy or corrupted. That’s the most important feature.

SDDM vs UWSM

Another thing I noticed was the login manager. On pure Arch, it installs Hyprland by default with SDDM, the same one KDE uses.

Omarchy uses UWSM, which auto-logs you in with your user at boot. So there’s no login screen, it just opens Hyprland automatically.

“But isn’t that insecure??”

No, because the Omarchy ISO pre-configures your SSD with LUKS, below the filesystem.

For those who don’t know, LUKS stands for Linux Unified Key Setup, which provides full-disk encryption. Its advantage over Windows BitLocker is that it’s filesystem-agnostic. In other words, it works with BTRFS or EXT4 or any other, because in the boot sequence, after the bootloader (whether Limine or Grub), it loads before the filesystem. It’s a block-level encryptor.

So when you boot your system, it first asks for the passphrase to decrypt your disk. Then the filesystem opens and the Linux kernel can continue the normal boot with the disk unlocked. So you are always forced to type your strong user passphrase at boot to decrypt the disk.

That’s why typing a password again at a login manager would be redundant and unnecessary, and I imagine that’s why they chose UWSM instead of SDDM.

Especially on a laptop, or in situations where other people live with you, it’s essential to make sure your disk is encrypted, no matter the operating system. Say you go out to work or travel and your laptop gets stolen. Without encryption, it’s game over, regardless of whether you have a login manager. It doesn’t protect your data. Anyone can just pull the SSD from your laptop, plug it into another computer, and boom, they can copy everything by booting as root.

With encryption, without the passphrase to decrypt it, accessing your data is impossible. Truly impossible, because on any modern computer from the last 15 years, the CPU ships with hardware-accelerated instructions for AES 256 encryption.

Getting a bit more nerdy: the decryption key is not your passphrase. During the install process, a new stronger and more secure key is generated using a key derivation process (KDF - Key Derivation Function), nowadays using Argon2id, previously PBKDF2. I explain this in this video:

So when you type your passphrase, what actually happens is it decrypts that secure key, and it’s with that secure key that your disk is encrypted. That’s why you can’t brute-force decrypt your data.

Plus, AES 256 is one of those encryption algorithms that’s quantum resistant. Even if a quantum computer were possible (it isn’t), not even that could decrypt your disk. That’s the level of security.

“But won’t it be slower?”

No. It’s practically imperceptible, because AES, as I said, is hardware-accelerated by your CPU and doesn’t depend on operating system software. In day-to-day use, you’ll barely notice. Performance is practically the same. There’s no reason not to enable encryption, especially on a laptop.

In my personal case, where I installed it on a desktop PC that I control myself on a secure local network, because I know how to implement network security, it’s not an issue. My most important data lives on my NAS (which is encrypted), in backups (which are encrypted). I don’t have sensitive data on this PC, and the little I do have sits in files encrypted by Veracrypt on a separate sub-volume.

That’s why I didn’t enable LUKS on my PC. And I kept the SDDM that pure Arch installed. Except it’s REALLY ugly by default, so here’s a small tip: install either the sddm-sugar-dark theme or dark-arch-sddm. I prefer the second one because it’s more minimalist and looks like this:

I customized it and swapped the Arch logo for the Omarchy one, and that was it.

Conclusion

I’ll say it again: only after installing manually did I see how Omarchy installs things, and today I prefer the Omarchy way. If I were installing from scratch, I’d use the Omarchy ISO and keep it with Limine+Snapper and Hyprland+UWSM, with snapshot rollback support, full disk encryption, and automatic login into Hyprland.

You can tell the people behind Omarchy have experience and have already picked components that make sense to work together in the most convenient and secure way possible. I was worried that, being a new distro, maybe they hadn’t given this much thought, but I’m happy to say I was wrong.

Use the official Omarchy ISO.

Every programmer needs to know how to manage their SSH keys. At the very least because every GitHub account requires one.

Every time you run git push to one of your repositories, it will ask for the passphrase of that key:

❯ git push origin master
Enter passphrase for key '/home/akitaonrails/.ssh/id_ed25519':

What does this mean?

SSH is a set of tools, both client and server, to create a secure, encrypted connection over the internet. It has several uses and I explained how to do SSH Proxy in this video:

The whole process starts by installing SSH on your machine, and on Omarchy/ArchLinux you just do this:

yay -S openssh

If you’ve never created a key pair (yes, it’s a pair), just run this command:

ssh-keygen -t ed25519 -a 100 -C "your_email@example.com" -f ~/.ssh/id_ed25519

ED25519 is a public-key algorithm, meaning it creates a pair of keys: a private one that must never leave your machine, and a public one that can be exposed on the open internet (the one you register on your GitHub account, for example). I explained public keys in this other video:

ED25519 is a more modern algorithm than the old RSA (which I think is still the default in ssh-keygen if you don’t make an explicit choice — it’s still secure, but elliptic curve is even more secure).

It’s based on elliptic curve cryptography (ECC). For the paranoid, yes, it’s even considered quantum-resistant, meaning that even if a quantum computer became feasible, it wouldn’t be able to break an ED25519 key.

Two files will be created after running ssh-keygen:

.rw-------   464 akitaonrails 14 Nov  2017  󰌆 id_ed25519
.rw-r--r--   108 akitaonrails 14 Nov  2017  󰷖 id_ed25519.pub

Pay attention to the permissions of these files. It’s important that the ~/.ssh directory and the private key files inside it always have 600 permission, meaning read-write only for your user, and no permission for groups or any other user. Nobody else should even be able to list the directory.

The *.pub files, which are the public keys, have 644 permission, which is read-write for you and read-only for other groups and users. As I said, the public key can be exposed publicly. Mine, for example, is this one:

❯ cat id_ed25519.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIEWG5bHK02sMqilMiYu67xqdaBsk3TtCQ564bcJibDiO akitaonrails@Miner42.local

ED25519 has another advantage: it’s orders of magnitude more secure than RSA and still provides a much shorter public key, which makes copy-pasting it around much easier.

A private key has an envelope in this format:

-----BEGIN RSA PRIVATE KEY-----
MIIEpA ...
...
XfI0X....
...
... nQ5w==
-----END RSA PRIVATE KEY-----

Repeating: THIS FILE MUST NEVER LEAVE YOUR MACHINE. Never leave it lying around on a pen drive, for example. And always make sure the permission is chmod 600 as I explained.

Yubikey 5

The most secure form, one that many companies even enforce, is the use of a HARDWARE-KEY. The private key is never written to your local machine; instead, it’s generated inside secure hardware from which it’s impossible to read that private key. Examples are Yubikey or FIDO2.

About Yubikey, be careful, you want the newer Yubikey Series 5 models:

If you have the old one — usually the blue one — it’s the Security Key v4.3.1 and only supports U2F (FIDO U2F) but not FIDO2/WebAuthn, and no PIV/OpenPGP/OTP applets. To be sure, install these packages on your Arch:

sudo pacman -S yubikey-manager libfido2

Then check with this command:

❯ ykman info
WARNING: PC/SC not available. Smart card (CCID) protocols will not function.
Device type: FIDO U2F Security Key
Firmware version: 4.3.1
Enabled USB interfaces: FIDO
 
Applications
Yubico OTP   Not available
FIDO U2F     Enabled
FIDO2        Not available
OATH         Not available
PIV          Not available
OpenPGP      Not available
YubiHSM Auth Not available

See how it finds the Yubikey connected via USB but everything shows up as “Not available”. That’s the wrong model — this Yubikey only works as Two-Factor Authentication on websites. It’s not useless, but for our case it doesn’t work because:

• it has no PIV applet, so it can’t act as a smartcard
• it has no OpenPGP applet, so it can’t store GPG or SSH private keys
• it has no FIDO2, so you can’t run ssh-keygen -t ed25519-sk.

A new one, on Mercado Livre today, costs around BRL 800. If you’re going to use it for work per the company’s security policy, they should provide it or reimburse you. But even for personal use, I recommend investing a bit more in security.

With a Yubikey 5 in hand, the procedure is as follows. Start by making sure you have the packages on your machine:

sudo pacman -S yubikey-manager yubico-piv-tool opensc

Initialize the PIV application by changing the PIN:

ykman piv reset                # wipes PIV, careful
ykman piv access change-pin    # default PIN is 123456
ykman piv access change-puk    # default PUK is 12345678

Generate a new key pair inside the Yubikey:

ykman piv keys generate 9a pubkey.pem

Extract only the public key to your local ~/.ssh directory:

ssh-keygen -D /usr/lib/opensc-pkcs11.so -e > ~/.ssh/id_yubikey.pub

The contents of that ~/.ssh/id_yubikey.pub file is what you’ll add to the ~/.ssh/authorized_keys file on the remote server you want to connect to via SSH. To open an SSH connection to it, plug the Yubikey into the USB port and run:

ssh -I /usr/lib/opensc-pkcs11.so your-user@server

It will ask for your PIN and authorize the connection. If you don’t want to keep typing that -I every time, just edit ~/.ssh/config with this:

# ~/.ssh/config
Host server
  PKCS11Provider /usr/lib/opensc-pkcs11.so
  User your-user

HOWEVER

This procedure uses the key generator inside the Yubikey, which only supports RSA (1024–2048) or ECC (P-256, P-384). If you want to generate an ED25519 key, the flow is different, we have to run it like this:

ssh-keygen -t ed25519-sk -a 100 -C "you@example.com" -f ~/.ssh/id_ed25519_sk

The id_ed25519_sk file that it generates on your local machine is not the private key, it’s just a “stub” that points to your Yubikey. So the key stays stored in the hardware and never passes through your machine.

To add your public key to the remote server, just manually append it to the ~/.ssh/authorized_keys file as we did before, or run this command to log in with your password and it will add the public key for you:

ssh-copy-id -i ~/.ssh/id_ed25519_sk.pub your-user@server

To use your key to log in now, just do:

ssh -i ~/.ssh/id_ed25519_sk your-user@server

This only works because the Yubikey 5 has FIDO2 support. The old ones don’t, which is why you can’t do this with them.

Oh, and on your home server or any other server, AFTER adding your key to authorized_keys, I recommend DISABLING the password login option (so that no bot keeps trying to brute-force its way in). On the server, edit:

# /etc/ssh/sshd_config
PasswordAuthentication no
ChallengeResponseAuthentication no
KbdInteractiveAuthentication no
UsePAM no
...
PubkeyAuthentication yes

In other words, turn off all login options and leave only public-key. Now just restart the service:

sudo systemctl restart sshd

SSH-Agent

To be clear: the most secure way to manage private keys is via an external security hardware device, in this case the Yubikey 5.

But it’s not mandatory. If you have a dedicated PC for work, with your Arch Linux or Omarchy installed, and you don’t keep installing shady software — like pirated games — nor keep browsing sketchy sites and clicking on random links (malware risk), keeping your keys locally on your machine isn’t entirely bad. I’ve been using it this way for years and have never had problems — because I’m paranoid about the security of my machine.

Remember, one of the most common types of malware are the ones that upload your files, or encrypt your files and then demand a cryptocurrency ransom to return them. The good old RANSOMWARE:

This exists not only on Windows but on Mac and Linux as well. And web browsers are the main vector, especially phishing emails with malicious links that you click on, or links that come through Discord, Telegram, or WhatsApp channels.

NEVER CLICK ON LINKS. Copy the link, paste it into a terminal, and see what kind of link it is. If it’s not an obviously official domain like “whatspp.com” or “google.com”, don’t go forward.

With all that said. Let’s say you created your keys locally and registered them in your server’s authorized_keys and in your GitHub account. Now, every time you run ssh or git push, it will ask you to type your passphrase (which, if you’re not silly, you made VERY LONG).

This is extremely inconvenient to keep typing all the time. That’s why SSH has a feature to help: caching your authentication for a fixed period using ssh-agent.

Start by creating this user service for systemd:

# ~/.config/systemd/user/ssh-agent.service
[Unit]
Description=SSH Agent

[Service]
Type=simple
Environment=SSH_AUTH_SOCK=%t/ssh-agent.socket
ExecStart=/usr/bin/ssh-agent -D -a $SSH_AUTH_SOCK

[Install]
WantedBy=default.target

Enable it with your user privileges (no sudo):

systemctl --user enable --now ssh-agent.service

Expose it in your .bashrc or .zshrc:

# ~/.zshenv (or ~/.profile)
export SSH_AUTH_SOCK="$XDG_RUNTIME_DIR/ssh-agent.socket"

Now, every time you log into your system and start working, add your work key:

ssh-add -t 30m ~/.ssh/id_ed25519

It will ask for your passphrase once, but for 30 minutes (which is what the -t 30m option does), you won’t need to re-type the passphrase and can comfortably keep accessing ssh or doing git push.

If you want to remove the cache from the agent before the timeout, you can do:

ssh-add -d ~/.ssh/id_ed25519

If your work routine involves using ssh, instead of manually running ssh-add you can add the following configuration to your ~/.ssh/config:

# ~/.ssh/config
Host *
  AddKeysToAgent yes
  IdentitiesOnly yes
  IdentityFile ~/.ssh/id_ed25519

And every time you open the terminal, it will ask you to type your passphrase. And that will last while your session is logged in.

Finally, the filename in the examples is always id_ed25519, but that has no relevance whatsoever — you can rename it however you want and even create multiple keys to use for separate services if you want to be extra secure. Just generate keys like heroku_id_ed25519 or google_cloud_id_ed25519 and so on. Create as many keys as you want or think necessary. This applies both to local keys and to keys on the Yubikey 5.

I think these are the aspects I consider most important to know about SSH keys. Did I forget anything else important? Feel free to share more tips in the comments below.

The more “modern” apps are basically canned web front-ends wrapped inside Electron. The problem? They’re HEAVY and chew through RAM like there’s no tomorrow. Start opening Discord, Spotify, and a handful of these and see if your old 8GB notebook can keep up.

But, especially if you’re a programmer, you should pay more attention to TUIs. At first, some will turn their nose up: “terminal apps are ugly, black and white, boxy, blegh”

Twenty years ago, they’d be right. But it’s 2025 and today’s terminals support 256 colors (more than enough), various resolutions and, most importantly, fonts, in particular Nerd Fonts, fonts that have icons inside. That’s how a tool like eza works, which I use every day aliased to ls and looks like this:

And there’s more: there are modern libraries, for several languages, like BubbleTea, a framework for building TUIs. Check their GitHub but they have the tools to make interfaces like this:

And if you just want a simple widget to complement a Bash script you’re writing, they have Gum, which lets you do interfaces like this:

And to use it just install the binary and put lines like this in your script:

# Gum examples
gum choose "fix" "feat" "docs" "style" "refactor" "test" "chore" "revert"

gum input --placeholder "scope"

gum confirm "Commit changes?" && git commit -m "$SUMMARY" -m "$DESCRIPTION"

And if you use Omarchy they ship an extra feature for TUIs. Just hit “SUPER+ALT+SPACE” to bring up the main menu, then pick “INSTALL” and “TUI”. Or simply open the terminal and run:

$OMARCHY_PATH/bin/omarchy-tui-install

It’ll ask for a name for the App and the command line to run. You can also pick icons at Dashboard Icons. Once registered that way, when you call the Rofi launcher with “SUPER+SPACE” and type “lazy”, LazyDocker shows up as if it were a regular app:

And since Hyprland has no title bar or anything, TUI apps or web apps (there’s omarchy-webapp-install too) open as if they were “native” apps:

Read the TUIs and Web-Apps sections in the Omarchy manual.

Obviously, this is only for those who prefer the feeling of running “Apps”, but it’s the same thing as opening a Terminal and simply typing lazydocker on the command line - which is my preference. What these Omarchy scripts do is create a .desktop file at ~/.local/share/applications. The LazyDocker.desktop example generates this:

❯ cat ~/.local/share/applications/LazyDocker.desktop
[Desktop Entry]
Version=1.0
Name=LazyDocker
Comment=LazyDocker
Exec=alacritty --class TUI.tile -e lazydocker
Terminal=false
Type=Application
Icon=/home/akitaonrails/.local/share/applications/icons/LazyDocker.png
StartupNotify=true

If you don’t want this launcher anymore, just delete the file or call the $OMARCHY_PATH/bin/omarchy-tui-remove script.

This feature is particularly interesting in Hyprland because, unlike GNOME or KDE, the window has no top title bar, so it doesn’t give away that you’re just opening a terminal or web browser. That’s how it ships pre-configured with things like ChatGPT or Grok looking like “native” apps, when they’re really just Chromium windows opening each one’s URLs directly:

Some TUIs I like

In my opinion, since there are no pretty GUI apps for Linux, it’s really better to use the respective web apps like Canva or ChatGPT that way, but more interesting is having actual TUIs. As I said, these days it’s not hard to make pretty TUIs. For a programmer, the advantage is that you don’t have to deal with front-end frameworks first, and second, you don’t have to deploy anywhere on the internet.

TUIs are lightweight, use few machine resources, they’re easy for any programmer to build, and you can have a home server or a server in some cloud, SSH in, and access the TUI, without having to deal with X11 or RDP or anything heavier just to get a GUI.

Some TUIs are obvious: in the previous post I already talked about LazyVim and how it’s a text editor as competent and complete as VS Code, using only a fraction of the machine’s resources. Everyone should know tools like HTOP or BTOP. Plus LazyGit or LazyDocker. All of these already come in Omarchy.

But there’s much more, for example, dblab which is a TUI database client for MySQL or Postgres:

Another similar one is LazySQL, written in Go:

Or if you prefer tools written in Rust, there’s rainfrog:

For those who can’t use CURL on the command line and prefer Postman to call and explore APIs, there’s the TUI Posting that does the same thing:

For those of us who run lots of Docker containers, I already mentioned LazyDocker, but there’s also oxker:

If you use Discord, there’s discordo:

Anyone who does a lot of Linux ricing has had to burn ISOs to USB sticks dozens of times; for that there’s dd on the command line, but there’s a cooler TUI called Caligula:

If your SSD is filling up and you have no idea where the hell all that space is going, there are several tools to analyze and show you. One of them is gdu:

And the last one I thought was cool out of nostalgia is sc-im; think Excel as a TUI or - for those of us who came from the 80s - think Lotus 1-2-3 but with Vim keybindings:

Why open Google Spreadsheets just to make a Todo list if you can do it in the Terminal?? TUIs are exceptional!

If you want to discover more TUIs check out awesome-tuis on GitHub:

Again: zero need for heavy web front-ends for simple things. Nothing beats the simplicity of a command line. And with libraries like BubbleTea or Gum, it’s now very easy for anyone to make a pretty app. And with Hyprland and Omarchy, everything stays integrated side-by-side with any other GUI app.

Getting a bit philosophical, the history of GUIs starts with skeuomorphic graphical interfaces that try to imitate objects from our daily life, particularly looking pseudo-3D, like Windows 95 was. The 2000s arrived and they started migrating to flat or minimalist interfaces, completely removing the skeuomorphism, making everything flat. That came mainly from Windows 8’s Metro. And I think that’s converging toward a more TUI-like style, coming full circle, going back to how it was on 70s terminals. Personally, I find that fascinating.

In my case, I spent 10 years using Manjaro GNOME as my daily driver. Manjaro is an Arch derivative. The reason was the easier install and the pre-made configs. But these days, with archinstall, I don’t think it’s worth it anymore. I know there are other derivatives, but it’s better to stick with the original.

For Ubuntu folks or those coming from Debian derivatives, Fedora, etc, there’s a small learning curve on the package manager: Pacman and Yay instead of Apt or Dnf. But once you understand the AUR, you’ll never want anything else. It has literally everything you need, without having to deal with third-party repositories.

I took a while to test Omarchy because I was already using Hyprland before Omarchy was created. DHH previously had Omakub, which was a set of scripts to customize Ubuntu into a good development environment. I liked it, but since I preferred Manjaro, I made a fork called Omakub-MJ. After that I decided to uninstall GNOME and GDM and install another set of scripts called ML4W, which makes Hyprland look great as well. So Omarchy wasn’t that novel, for me.

The thing is, I’d been using the same Manjaro for years. It had a ton of old configs and scripts all mixed up. My Manjaro GNOME no longer even had GNOME. My Hyprland was a Frankenstein. The only barrier was my QEMU/Libvirt setup to run Windows with GPU passthrough, which is what I used to edit videos back when I was still posting on my YouTube channel.

But since I stopped editing videos, that Windows isn’t as important anymore. I had another Windows VM with GPU passthrough for games. But currently I have a separate mini-PC with Windows that I use just for games. I also had another VM with another Linux just for my AI experiments, but since then I migrated to running natively while isolating everything with Docker. In other words, my VMs are no longer important. Check my previous blog posts to learn about AI in Docker.

With the release of Omarchy 2.0, it looks like a good time to reinstall Arch from scratch with Omarchy on top and start over clean and beautiful.

1 - My Setup

Every case will be different. This post’s main purpose is to serve as my personal reference for the future, in case I need to reinstall everything again.

No, I’m not going to use NixOS. I really don’t think it’s worth it. It only pays off if you’re a computer lab admin or server infrastructure admin and your day-to-day involves rebuilding identical setups reliably. For a normal user who only reinstalls every 2 or 3 years, the learning curve and maintenance work aren’t even remotely worth it. It’s a waste of time. I’d spend days learning now, finish the setup, go 2 years and I’d already have forgotten everything. Arch Linux by itself is stable enough that I don’t need this.

My setup is still the same from the days I was editing videos for the channel. It’s a Ryzen 9 7850X3D with 16 cores, 32 threads, 5GHz peak. It’s still an excellent CPU with power to spare for my use cases, which is why I don’t see myself wanting to upgrade anytime soon. It’s rare for me to saturate all those cores at those speeds at the same time. Better yet: it has an integrated AMD GPU which makes installing Linux a thousand times easier than if I had NVIDIA.

But I also have a separate discrete GPU, the NVIDIA RTX 4090 (no, I don’t need a 5090, it has the same amount of VRAM). It’ll stay for secondary tasks and not for carrying my graphical environment. Things like Cycles rendering in Blender, or running LLMs with ollama and the like. Before I used GPU passthrough to a VM in QEMU/Libvirt to run Windows in parallel with Linux. Both to edit videos and to game.

Since I no longer edit videos, I don’t need this complicated setup, so I won’t bother installing Libvirt back. If I need Windows, I’ll leave it in dual boot. If I need to edit video, these days we have DaVinci Resolve Studio which runs natively on Linux (a thousand times better than Adobe Premiere). For games I have a separate mini PC with an RTX 4060 hooked up to my TV. The best thing is to have a totally separate PC for games.

So this setup is meant to be pure Linux, with access to my Synology DS 1821+ NAS with 100TB. The only extra thing I’ll need is to configure NFS mounts, as I’ve already detailed in this other post.

One detail is that I have 4 NVMEs in this PC. 2TB for my old Linux. 2 TB for dual boot/Windows VM. 2 TB just as a Steam drive and 1 TB for random stuff. Since I’m wiping the Steam VM, I also no longer need to dedicate an entire NVME just for that. Instead, I’ll make the new Linux’s “/home” directory this entire 2 TB.

This will let me stop worrying about Docker filling my drive and freezing my entire system from lack of space. Last time I had “solved” this by making a remote drive with iSCSI on my NAS (which has infinite space). Since removing my Steam VM will give me 2TB back, I’ll solve the problem locally and with fewer configurations.

RAM I have in spades, 96GB of DDR5. With that, I also don’t need to worry about a swap partition. Swap only matters if you have less than 32GB of RAM, if you’re running lots of Docker and keep hitting the max RAM consumption very fast. Or if you’re on a laptop and want the option of hibernation (being able to record RAM to disk, fully power off the machine, and come back later exactly where you left off — which is different from suspend, which still uses power).

If you want to hibernate, you need a bit more than the size of your RAM. So if you have 32GB, it’s good to leave a margin, around 34GB or more of swap. Since my PC is a desktop at home, I don’t need hibernation, just enable ZRAM for the rare cases where there’s a spike over 96GB (which is super rare). Plus, it’s easier for me to just bump up to 128GB of RAM if I really need it. Swap to compensate for RAM only pays off on laptops that don’t have room for more real RAM.

2 - Why Omarchy?

As I said, I’ve been an Arch user for a decade and I don’t see any package repository bigger and more complete than the AUR. The only other repository that actually competes is NixOS’s. But since Nix is ruled out for my use case, the AUR remains unbeatable.

Arch has Pacman as its package manager. To access the AUR you need a second manager. There are several like the old Pacaur, Paru, and many others. But the best, in my opinion, is Yay. It has exactly the same syntax as Pacman and replaces Pacman. In practice, we just use Yay for everything.

To search packages by name just do yay -Ss spotify.

To remove packages just do yay -Rns spotify.

To update all system packages just do yay -Syu

To remove orphan packages that pile up over time just do sudo pacman -Rns $(pacman -Qdtq)

And those are the commands I use 99% of the time.

I’ve already used every type of desktop manager out there: GNOME (which behaves more like a Mac), KDE (which behaves more like Windows for power users), XFCE (which is GTK-based and lighter), Cinnamon (also GTK-based), i3 (which is a tiling window system), Sway (like i3, also tiling but if I’m not mistaken was designed with Wayland in mind).

In practice, everyone uses apps in two ways: a full-screen window or 2 vertical windows splitting the monitor in the middle (editor on one side, browser on the other), or 3 windows (a vertical editor taking half the monitor, a browser taking 1/4, and a terminal taking another 1/4). Then we organize more open apps into virtual desktops/workspaces. That’s the easiest way to work.

This means being able to drag floating windows is a waste of time. I prefer that windows already open sized into one of these layouts I mentioned above. You can configure GNOME or KDE to do that. But it smells like a kludge. Instead it really is better to use i3 or Sway.

Setting controversies aside (yes, I’m a bit wary of Wayland and I like that XLibre exists). But it’s a fact that X11 is behind the times and is a very old and complicated architecture. Wayland really does have a better “appeal,” despite having taken a while to round off basic things like screen sharing (OBS, Zoom). But I’ve been using Wayland for some years now without headaches. These days I’d say it’s pretty stable. I’ve been using GNOME on Wayland for a long time. I don’t stop using things because I’m wary of them: with technology I’ll always be absolutely promiscuous and use everything.

Knowing I’ll use Wayland and knowing I want automatic window layouts, and don’t need floating windows, the best is a desktop manager with a tiling windows system (tiles are “azulejos” and we’re talking about tiles being side by side and never one on top of another), which organizes windows side by side in a smart and automatic way.

In this case we only have 2 options: Sway or Hyprland (either one is good). Hyprland, installed from scratch, is completely bare — it has absolutely nothing. We need to configure everything through files in .config/hypr. It’s simple enough, but it’s work.

The only good option for having a pre-configured and well-done Hyprland was ML4W, which I was already using. But now we have Omarchy, which installs and pre-configures everything to work smoothly on Hyprland. This is the best option we have today.

Besides configuring Hyprland to work with Waybar, Rofi, and other components, it has its own system for switching themes and styles to leave the system with the “look and feel” you want (and all the ones that come with it are super pretty), but it also installs things I’ve been using for a long time like Neovim with the LazyVim package (in my opinion, the easiest way to make Neovim not fall short compared to VS Code), Mise (the best way to organize development environments to have multiple versions of your favorite programming language).

If you’re installing a distro from scratch, the only two things you need to have are Mise and LazyVim. Plus Docker and LazyDocker. That’s enough to start a productive development environment. And Omarchy already brings all of that pre-configured. No one “needs” Omarchy, but it already brings everything integrated and beautiful. So why bother doing everything from scratch to end up almost the same?

Also, this is Linux. Don’t like one of the components? Just swap it out.

3 - Back Up

The vast majority of everything I have already lives on the remote server, my 100TB Synology NAS. That already helps a lot. Even so, there’s still a good amount of stuff locally on my PC, so the first thing to do is copy everything to the NAS. If you don’t have a NAS, then an external HD. Any server will do; the important thing is to guarantee you won’t lose anything before installing a new OS from scratch.

Don’t forget directories like .config or .local. It’s better to do an rsync -avz --progress .config /mnt/nas/backup/, for example, and copy everything. Even what you think you won’t need. Better to copy more than to be missing stuff. As a rule, the ideal is to copy everything in your $HOME to an external drive or NAS.

Just to make sure I won’t forget anything important, I’m also going to record a list of all the packages I have installed on my old system:

yay -Q > pacotes.txt
flatpak list > flatpak.txt

Also making sure I won’t lose old configs of services I made in systemd, so also copy everything from /etc/systemd/system. It’s also worth recording things like /etc/fstab. Also don’t forget to back up your SSH keys with tar cvfz ssh.tgz ~/.ssh!!

If, like me, you were using QEMU/Libvirt for VMs, it’s good to save the configs of the virtual machines you used. Usually the tool to manage VMs is virsh, so I just did:

sudo virsh list --all
sudo virsh dumpxml <vmname> > <vmname>.xml

If I want to recreate the machines in the future, it will all be in the backup. In my case I keep all virtual drives on my NAS, but if yours are local, you also need to save those files that live in /var/lib/libvirt/images/

rsync -avh --progress /var/lib/libvirt/images/ /backup/libvirt-images/

4 - Is Installing Arch Hard?

Arch, less than Gentoo, has always had a reputation for being the most brutal Linux distro for a beginner to install. That’s not a lie, but the truth is Arch is simultaneously the hardest distro and also the easiest.

Download the official ISO and burn it to a USB drive (on Windows, using Rufus or Balena Etcher). Now press F12 (depends on your BIOS) or configure the BIOS directly to boot from the USB drive. Doing that loads the Arch live environment, which is literally dropping into a command line. With no further help.

From this point you have to follow the Installation Wiki from the excellent ArchWiki and learn how to install a Linux from absolute scratch using only the command line, step by step, through trial and error (more erring than hitting the mark), and in the end you’ll have a much better feel for how a Linux distro actually works.

I didn’t make an Arch video but I did make videos of Slackware to explain how a package manager works. I also made a Gentoo video to show how a distro that compiles everything from scratch works. And I made a video about how the Linux Boot Works to understand where the kernel lives and how it’s structured. But I didn’t make an Arch video because I always left it as an exercise for beginners.

The manual way is viable, but if you’re used to a graphical installer, like Calamaris, which most more popular distros like Ubuntu or Fedora have, you’ll be totally lost. But here comes the bonus: you don’t need to go through all of that to have Arch Linux on your machine.

For that there’s archinstall.

When you boot the Arch USB and drop into the command line, just type archinstall and you’re done — just follow the step by step it provides (which I consider even simpler than Calamaris) and it will install and configure everything automatically for you, the same way installing Fedora or any other distro is. Seriously, it shouldn’t take more than 15 minutes.

archinstall looks like this:

Just go into each of the items on the left and fill in your choices. Configure things like keyboard layout (I normally choose ‘us-acentos’). Edit the hostname of your machine. Choose “NetworkManager” in network configuration (it will configure both ethernet and wifi for you), add Bluetooth and Audio support (choose “Pipewire”). Choose the “desktop” type instead of “minimal” to already get the main packages needed for a desktop. Choose the timezone (“America/Sao_Paulo” in my case).

I also recommend choosing the Hyprland option, I think under Applications or Additional Packages. It will install SDDM to give you a graphical login.

Only two options need more attention: for bootloader, many will be tempted to use Limine, which is more modern and lightweight. But I still recommend using GRUB, I’ll explain why in a moment.

The second important option is “Disk Configuration”. Don’t worry, unlike fdisk, it’s super intuitive. Just choose the correct drive where you want to install (if you have dual boot, careful not to wipe your Windows). Then let it do the automatic partition layout (only edit manually if you have some very special need). Most importantly, choose BTRFS instead of the traditional ext4.

Every Linux always formats its Linux partitions with ext4, which is the oldest, most stable, and best-documented file system. These days I recommend BTRFS; it’s much more modern, safer (has better corruption protection systems), uses less space (learn about CoW - Copy on Write), and most importantly: it has cheap snapshot support (think of Apple Time Machine, only better). It has most of the features of a file system dedicated to a file server but is much simpler and more intuitive to use than the monster that is ZFS (I don’t recommend it for normal users).

It has some maintenance needs that are worth reading about in the Wiki to learn. But overall it’s plug and play, install and forget. In the next sections I’ll show some things you need to know, but trust me: choose BTRFS.

I know Omarchy 2.0 has an option for a pre-configured ISO which I imagine is normal Arch with archinstall and Omarchy on top all at once. But I don’t know if they allow this choice, which is why I preferred going straight to pure Arch first. In the end the effect is the same. Comment below later if the Omarchy ISO also has the same options. Just make sure in the end you have BTRFS. Future you will thank you.

5 - Separate HOME

As I explained before, I used one of my 4 NVMEs as the Linux drive. But now I’ve freed up another NVME and want to move my $HOME there and have 2 TB dedicated just to user space.

I won’t explain how to partition and format that other drive. It’s simple: just use fdisk or later install Gparted which is the graphical version of the parted tool that you can use from the command line. There are several options. The important thing is just to wipe my old Windows partition and also format it with BTRFS.

Each person will have different device and partition names than mine. To find out which are yours, use the lsblk command. See my example:

In my example nvme1n1 is the 1TB drive for random stuff. nvme2n1 is my new Arch Linux. nvme0n1 is the old Windows dual boot drive. nvme3n1 is the Steam drive I formatted with BTRFS to become my new HOME drive.

If you didn’t get it, HOME is the /home/akitaonrails directory. It will live on a separate drive. After archinstall finishes and I boot into the new Linux, I just do the following:

sudo mount -t btrfs /dev/nvme3n1p1 /mnt
sudo btrfs subvolume create /mnt/@home
rsync -aAXHv /home/ /mnt/@home/
sudo umount /mnt

This mounts the new partition, then we use the “btrfs” command to create a new sub-volume called “@home” (again, read the BTRFS Wiki to understand concepts like sub-volumes).

The commands above create the sub-volume and copy everything from the old HOME to the new. Now we need /home to be mounted on this new partition at boot. For this we need to know the UUID of that partition:

~ ❯ sudo blkid /dev/nvme3n1p1
/dev/nvme3n1p1: LABEL="HOME" UUID="84e9a1b7-a30e-...

The blkid command returns the unique UUID of each partition and, with that, we can edit the /etc/fstab file using sudo nvim or sudo nano or the editor of your choice:

# /etc/fstab
...
# /dev/nvme2n1p2
# UUID=da3aea43-...-aeaf8c7224d7 /home      btrfs      rw,relatime,ssd,discard=async,space_cache=v2,subvol=/@home 0 0

# /dev/nvme3n1p1
UUID=84e9a1b7-...-7a6a17fd0395 /home      btrfs      rw,relatime,ssd,discard=async,space_cache=v2,subvol=/@home 0 0
...

See how I commented out the old line that mounted /home and added a new line with the new UUID. The rest is all the same. And that’s it, just boot and from now on my /home will mount on the new drive. Now I have 2 TB dedicated just to my junk downloads lol 🤣

But not only that, I also have space for big things like Docker images or LLM models, without risking filling the operating system drive and running the risk of it no longer booting due to lack of space — as has happened to me several times in the past. Always remember to do maintenance on Docker and LLMs and delete old things.

Speaking of which, BTRFS supports snapshots. And one of the basic mistakes is forgetting that Docker or LLM directories can end up in the snapshots and occupy space without you knowing. To avoid this it’s better to mark those directories to not enter the snapshots. For that we have to tell BTRFS to ignore those directories.

The correct way is to create separate subvolumes for them. For this I’ll mount that same partition on the separate drive where I mounted my $HOME:

~ ❯ sudo mkdir /mnt/temp
~ ❯ sudo mount -o subvolid=5 -t btrfs /dev/nvme3n1p1 /mnt/temp

~ ❯ ls /mnt/temp
 @home   timeshift-btrfs

~ ❯ sudo btrfs subvolume create /mnt/temp/@docker
Create subvolume '/mnt/temp/@docker'

~ ❯ sudo btrfs subvolume create /mnt/temp/@ollama
Create subvolume '/mnt/temp/@ollama'

~ ❯ sudo umount /mnt/temp

Now just edit /etc/fstab to mount correctly just like we did with HOME:

# /etc/fstab
...
# /dev/nvme3n1p1
UUID=84e9a1b7-...-7a6a17fd0395 /home      btrfs      rw,relatime,ssd,discard=async,space_cache=v2,subvol=/@home 0 0
UUID=84e9a1b7-...-7a6a17fd0395 /var/lib/docker      btrfs      rw,relatime,ssd,discard=async,space_cache=v2,subvol=/@docker 0 0
UUID=84e9a1b7-...-7a6a17fd0395 /var/lib/ollama      btrfs      rw,relatime,ssd,discard=async,space_cache=v2,subvol=/@ollama 0 0
...

Done, clean subvolumes. More important in my case: I moved directories that have a tendency to grow without control out of the operating system partition, making it harder to end up with an inaccessible system due to lack of space. Do the same with other similar directories, with things like Kubernetes, for example. Anything that keeps downloading large files, like system images.

Now just mount and bring things back:

# every time you edit fstab, run this:
sudo systemctl daemon-reload

# create the mount points
sudo mkdir /var/lib/docker
sudo mkdir /var/lib/ollama

# mount
sudo mount /var/lib/docker
sudo mount /var/lib/ollama

# copy the contents of the old directory back
sudo rsync -aHAX --inplace /var/lib/docker.old/ /var/lib/docker/
sudo systemctl start docker

Besides space management, what’s the other advantage of making separate subvolumes? Because the next section will be about making the system even more robust by adding snapshot and rollback capability to past snapshots. And the ideal is to keep huge files out of snapshots that will sit in the past. Docker images are easy to recover: just docker pull again, no need for backup.

6 - Installing Omarchy

This is the easiest part. When you’re done installing with archinstall, if you chose the Hyprland option, SDDM will appear for you to log in. And when you enter you’ll be shocked at how raw Hyprland is. You basically can’t do anything.

So this doesn’t become an entire day of manual configuration, we’ll use Omarchy. Hit “Super Enter” to open the terminal and don’t mind how ugly things look right now. It’ll get better.

In the terminal just do this:

curl -fsSL https://omarchy.org/install | bash

Just follow the on-screen instructions and let it do the rest. And that’s it, done, there’s no next step.

I HIGHLY recommend you read the OMARCHY ONLINE MANUAL that DHH made. It’s very clean, simple, and direct. All the keyboard shortcuts, for example, are in the HOTKEYS section. Spend an hour reading the basics to be able to operate it. But by now you already have practically everything you need: Alacritty as terminal, Chromium as browser (you can install Brave if you prefer, as I do).

“Super Alt Space” opens the Omarchy main menu. “Super Space” opens Rofi to type the name of the app you want to open. “Super Enter” opens the terminal. “Super B” opens the browser and so on.

7 - Customizing Omarchy

Omarchy is a customized Hyprland. We can edit whatever we want directly in ~/.config/hypr. And since I was used to ML4W, I decided to tweak a bit to make it good for my setup. Your setup will vary depending on your needs.

Right after I finished installing Omarchy and tried to use Gparted to partition that second NVME of mine for HOME, it had an authentication problem. I don’t remember if this was the solution but it’s good to make sure you have Polkit installed:

# make sure polkit + agent exist
sudo pacman -S --needed polkit polkit-gnome xorg-xhost

# Hyprland: export full env to systemd user bus once
dbus-update-activation-environment --systemd --all

Back to it, the first thing I need to solve is that I have 2 monitors. An Asus 32" 1440p 144fps as the main and another Samsung 24" 4K 60fps vertical on the left side. The way to configure this in Hyprland is by editing a file like ~/.config/hypr/monitors.conf which is normally loaded by ~/.config/hypr/hyprland.conf.

Instead of doing this manually, I prefer to install:

yay -S nwg-displays

Here I configure things like transform 90 degrees to rotate the vertical monitor, resolution scaling, 10-bit color support, etc.

It will save two files: ~/.config/monitors.conf and ~/.config/workspaces.conf. Omarchy doesn’t load this second file, so we have to edit ~/.config/hypr/hyprland.conf to look like this:

...
# Change your own setup in these files (and overwrite any settings from defaults!)
source = ~/.config/hypr/monitors.conf
source = ~/.config/hypr/workspaces.conf`
...

I also took the opportunity to add some extra configurations in this file:

...
# animation
animations {
  enabled = yes
  bezier = easeOutQuint, 0.23, 1, 0.32, 1
  animation = workspaces, 1, 4, easeOutQuint, slide
  # optional extras:
  animation = specialWorkspace, 1, 4, easeOutQuint, slide
  animation = windows, 1, 4, easeOutQuint, popin 80%
  animation = fade, 1, 4, easeOutQuint
}

xwayland {
    force_zero_scaling = false # careful with mixing scaling wayland and x11
}

input {
  numlock_by_default = true
}

# dialogs/splash/utility ONLY
windowrulev2 = float,  xwayland:1, windowtype:^(dialog|splash|utility)$
windowrulev2 = center, xwayland:1, windowtype:^(dialog|splash|utility)$

# never center menus/tooltips
windowrulev2 = tile,   xwayland:1, windowtype:^(popup_menu|dropdown_menu|tooltip)$

Some people don’t like it but I like having a quick animation when I switch from one workspace to another, which is why I added the animations block.

When you use apps made for X11, they’ll run on top of XWayland. One annoying thing is that some of them open “dialog boxes,” which are floating windows. And they can end up in places hard to click, especially on a multi-monitor setup. That’s why I added blocks like xwayland and windowrulev2 rules to force those dialog boxes to always appear centered on screen.

Finally, I have an 8bitdo numpad keyboard connected via Bluetooth, but it doesn’t start up with numlock on. To fix this there’s that input block.

Back to the monitor layout. After nwg-displays generated the files, I still had to modify a bit for my case, like this:

# ~/.config/monitors.conf
# Generated by nwg-displays on 2025-08-28 at 14:30:17. Do not edit manually.

#monitor=HDMI-A-3,2560x1440@143.97,1080x407,1.25,bitdepth,10
#monitor=DP-5,3840x2160@60.0,0x0,1.875,bitdepth,10
#monitor=DP-5,transform,1
#monitor=DP-1,0x0@60.0,-1x-1,1.0
#monitor=DP-1,disable

monitor=HDMI-A-3,2560x1440@143.97,2813x948,1.0,bitdepth,10
monitor=DP-5,3840x2160@60.0,1373x350,1.5,bitdepth,10
monitor=DP-5,transform,1
monitor = DP-1,disable

The monitor file I didn’t have to change anything, really, just remember to disable that DP-1 that appears on my main monitor (I think it’s its DisplayPort, but I use HDMI, so I have to disable DP-1).

# ~/.config/workspaces.conf
# Generated by nwg-displays on 2025-08-28 at 13:07:02. Do not edit manually.

workspace=5,monitor:DP-5,persistent:true
workspace=1,monitor:HDMI-A-3,persistent:true
workspace=2,monitor:HDMI-A-3,persistent:true
workspace=3,monitor:HDMI-A-3,persistent:true
workspace=4,monitor:HDMI-A-3,persistent:true

This one I also didn’t have to change much, in nwg-displays itself I said which workspaces I want on each monitor. In my personal preference I prefer to leave the vertical monitor only with workspace 5 and the others on the main monitor. The difference here was that I added those persistent:true options on all of them, to guarantee that everything will work correctly with the workspaces “pinned” in the right places. Workspaces in Hyprland are quite dynamic; it’s worth reading the documentation later if you want more complicated cases.

This solves my two-monitor setup the way I prefer. Experiment with things like scaling until everything is okay for your setup.

Next I needed to solve the hotkeys (key bindings). I’m used to some combinations that came from ML4W so I decided to copy them directly into ~/.config/hypr/bindings.conf. First, switch chromium for Brave:

# Application bindings
$terminal = uwsm app -- alacritty
$browser = brave # omarchy-launch-browser
...

Then I added a bunch of binds at the end of the same file:

unbind = SUPER, V
bind = SUPER, V, swapsplit
bind = SUPER, M, fullscreen, 1                                                           # Maximize Window
bind = SUPER, T, togglefloating                                                          # Toggle active windows into floating mode
bind = SUPER SHIFT, right, resizeactive, 100 0                                           # Increase window width with keyboard
bind = SUPER SHIFT, left, resizeactive, -100 0                                           # Reduce window width with keyboard
bind = SUPER SHIFT, down, resizeactive, 0 100                                            # Increase window height with keyboard
bind = SUPER SHIFT, up, resizeactive, 0 -100                                             # Reduce window height with keyboard

# Display
bind = SUPER SHIFT, mouse_down, exec, hyprctl keyword cursor:zoom_factor $(awk "BEGIN {print $(hyprctl getoption cursor:zoom_factor | grep 'float:' | awk '{print $2}') + 0.5}") # Increase display zoom
bind = SUPER SHIFT, mouse_up, exec, hyprctl keyword cursor:zoom_factor $(awk "BEGIN {print $(hyprctl getoption cursor:zoom_factor | grep 'float:' | awk '{print $2}') - 0.5}") # Decrease display zoom
bind = SUPER SHIFT, Z, exec, hyprctl keyword cursor:zoom_factor 1 # Reset display zoom

# Workspaces
bind = SUPER, 1, workspace, 1 on HDMI-A-3 # Open workspace 1
bind = SUPER, 2, workspace, 2 on HDMI-A-3  # Open workspace 2
bind = SUPER, 3, workspace, 3 on HDMI-A-3 # Open workspace 3
bind = SUPER, 4, workspace, 4 on HDMI-A-3 # Open workspace 4
bind = SUPER, 5, workspace, 5 on DP-5 # Open workspace 5

bind = SUPER SHIFT, 1, movetoworkspace, 1  # Move active window to workspace 1
bind = SUPER SHIFT, 2, movetoworkspace, 2  # Move active window to workspace 2
bind = SUPER SHIFT, 3, movetoworkspace, 3  # Move active window to workspace 3
bind = SUPER SHIFT, 4, movetoworkspace, 4  # Move active window to workspace 4
bind = SUPER SHIFT, 5, movetoworkspace, 5  # Move active window to workspace 5

bind = SUPER, Tab, workspace, m+1       # Open next workspace
bind = SUPER SHIFT, Tab, workspace, m-1 # Open previous workspace

bind = SUPER CTRL, 1, exec, $HOME/.config/hypr/moveTo.sh 1  # Move all windows to workspace 1
bind = SUPER CTRL, 2, exec, $HOME/.config/hypr/moveTo.sh 2  # Move all windows to workspace 2
bind = SUPER CTRL, 3, exec, $HOME/.config/hypr/moveTo.sh 3  # Move all windows to workspace 3
bind = SUPER CTRL, 4, exec, $HOME/.config/hypr/moveTo.sh 4  # Move all windows to workspace 4
bind = SUPER CTRL, 5, exec, $HOME/.config/hypr/moveTo.sh 5  # Move all windows to workspace 5

Note that the last block of scripts needs a script to move all windows at once to another workspace. I copied this moveTo.sh from ML4W’s GitHub and placed it directly in ~/.config/hypr. Don’t forget to give execute permission with chmod +x moveTo.sh afterwards. The various workspace ones below are how I prefer to move workspaces and move apps to different workspaces.

Omarchy already comes with “SUPER J” to change the orientation of windows, for example, if there are two horizontal windows one on top of the other, with SUPER J they become vertical, but “SUPER V” was missing which I added for “swapsplit” which is swapping windows’ places.

I also like “SUPER M” to temporarily make one of the windows full screen, and “SUPER T” to temporarily make a window floating (like a calculator, for example). I had to unbind the previous SUPER M that opened Spotify, but I barely use Spotify on desktop so I don’t need it. When I want to open that app, I go to SUPER SPACE to open Rofi and type it there.

If you have questions about the default combinations, Omarchy has “SUPER K” to open a window with help for all of them.

I still haven’t modified combinations for specific applications. The ones that come with Omarchy are already very useful, like SUPER A to open ChatGPT as if it were a separate app, or SUPER CTRL A to open Grok in a separate window. SUPER O to open Obsidian is also very useful for me. I recommend playing with these binds to make specific bindings and, again, reading the manual to learn everything else it already brings. But up to here it’s enough to leave Hyprland the way I like to use it.

8 - Timeshift, Snapshots and GRUB

Remember I said to choose GRUB in archinstall? It’s time now. The goal: let the system make periodic snapshots of itself, and in case you install some corrupted package or do things on your system that prevent it from booting, instead of having to resort to a USB drive to try to boot and diagnose the error, it’s easier to just boot, choose a snapshot right before the destructive operation, and come back intact.

Before proceeding, an adjustment I think is important: my 4K monitor makes GRUB letters too small for me to read. I prefer bigger letters. Fortunately GRUB uses bitmap fonts so I can use any. I did the following:

sudo grub-mkfont -s 48 -o /boot/grub/fonts/caskaydia48.pf2 /usr/share/fonts/TTF/CaskaydiaMonoNerdFont-Regular.ttf

This will generate a font in the format that GRUB can load. Choose any one you like; Omarchy already pre-installs several very good ones like JetBrains’s. If size 48 is too big, lower it to 32, experiment until it’s the way you like.

Then just edit /etc/default/grub to, at the end, have this line:

GRUB_FONT=/boot/grub/fonts/caskaydia48.pf2

And now just regenerate the bootloader:

sudo grub-mkconfig -o /boot/grub/grub.cfg

Every time yay -Syu brings a kernel or driver update, GRUB will be regenerated with the same font. Look at how it turned out for me, I think it looks much better (this is a 4K monitor):

Now the entire reason for having chosen GRUB: allowing you to choose BTRFS snapshots to boot into the past, before some destructive operation, as shown in the photo above. For this we need the following:

pacman -S timeshift grub-btrfs
yay -S timeshift-autosnap
systemctl enable --now grub-btrfs.service

Done. From now on, every time GRUB is rebuilt, it’ll have a new option to choose snapshots. We just need to create those snapshots automatically, and for that we have the Timeshift app. Open it and follow its step by step. The important thing is to choose the BTRFS option (yes, you can use RSYNC if you’re on ext4, but that occupies a lot of space, because it will literally keep making copies of your entire system’s files. The beauty of BTRFS is that its snapshots don’t duplicate files).

I leave it making snapshots and accumulating versions of the last hours, last days, last weeks, and months. If later on I remember “damn, there was that file I deleted last month but now I need it” just open Timeshift and browse a snapshot from last month. Like Mac folks do with Time Machine, but occupying almost no extra space.

Besides that, every package upgrade will generate a snapshot beforehand. That way, if by chance a corrupted package comes in or breaks some important config of yours, you can go back exactly to how it was before the update. And if it breaks catastrophically, where your Linux no longer boots, just go to the GRUB extra menu and boot from the previous snapshot, which worked. And everything comes back just like it was before.

Nothing is more important for your system than having automatic snapshots that occupy almost no extra space. This alone makes BTRFS superior to any alternative.

This does not replace external Backup!!

This rollback and the ability to recover things easily is good for day-to-day accidents. But let’s say your NVME breaks somehow, or your PC breaks somehow. That’s what external backups are for (be it external HD, NAS, or Cloud). You want to be sure that, in a catastrophic situation, it’s still possible to recover your files.

I have all the protection layers: local snapshots via BTRFS and Timeshift, backups done remotely to my NAS, and a backup of the most important parts of my NAS on Amazon Glacier which, unlike Amazon S3, is for keeping backups, where storage cost is ultra low but transfer cost is higher (S3 storage is more expensive but transfer is cheap, which is why it serves to serve website assets).

I like being prepared so that, in case my house catches fire, I don’t lose anything important.

9 - NFS on the NAS

Speaking of NAS, one thing I configured differently — since I primarily use Linux instead of Windows — was enabling the NFS server.

But beware that some NAS have a characteristic that can be annoying: your user on the NAS will have a UID and GID different from 1000!

When you create a user on any Linux, the default is to assign UID 1000 to the first user, 1001 to the second, and so on. But since on the Synology NAS the first user receives UID 1026, if I mount with NFS (which passes through UNIX permissions), I’ll have authorization problems.

There are two solutions: try to change the UID on the NAS from 1026 to 1000. I tried that and I’ll tell you up front it’s a waste of time, you can end up breaking your NAS’s configurations catastrophically.

It’s much easier to change the user of your new local Linux to be 1026 and that’s it. It’s pretty easy.

First, we need to log out and leave Hyprland and go back to the SDDM login screen. Then we need to switch to another TTY with CTRL + ALT + F3 (to go to tty3, for example). From there we have to log in as root.

Now we run: systemctl isolate multi-user.target to run in isolated recovery mode, where no other user has processes running. Since we’re going to mess with the user, they can’t be active.

usermod -u 1026 akitaonrails
groupmod -g 1026 akitaonrails
chown -R 1026:1026 /home/akitaonrails

With the commands above we change from 1000 to 1026 and fix the permissions on the local files to reflect this change. Now yes, we can edit /etc/fstab to mount the shared directories on the NAS with NFS:

# NFS
192.168.0.x:/volume1/GIGACHAD /mnt/gigachad nfs4 _netdev,noauto,nofail,bg,x-systemd.automount,x-systemd.requires=network-online.target,x-systemd.after=network-online.target,x-systemd.idle-timeout=60s,noatime,nodiratime,async,rsize=65536,wsize=65536,actimeo=1  0 0
192.168.0.x:/volume1/TERACHAD /mnt/terachad nfs4 _netdev,noauto,nofail,bg,x-systemd.automount,x-systemd.requires=network-online.target,x-systemd.after=network-online.target,x-systemd.idle-timeout=60s,noatime,nodiratime,async,rsize=65536,wsize=65536,actimeo=1  0 0

Don’t forget to create the mount points:

mkdir /mnt/gigachad
mkdir /mnt/terachad

Done, just reboot and everything will work correctly. The file permissions on the NAS — which are UID 1026 and GID 1026 — will be accessible to the local user without problems.

10 - Utilities

Here are the last small tips to keep everything in one place. The first is to replace the ls command with eza which offers a nicer face, with icons and everything, like this:

Just do yay -S eza and add this to your .zshrc or .bashrc:

alias ls='eza --icons --color=auto --group-directories-first'
alias ll='eza -l --icons --color=auto --group-directories-first'
alias la='eza -la --icons --color=auto --group-directories-first'

Second tip is to install Atuin. For anyone who deals with infra, this is extremely important: backup of all the command history you’ve used in your terminal to this day.

Install with yay -S atuin and do:

atuin login
atuin sync

Read the official site, but first you need to create an account and a secret encryption key — yes, you can run it locally on a server at your house, but their cloud option is pretty convenient and secure because it’s all encrypted, so there’s no problem if you upload passwords from your history.

Just put this in your .zshrc:

export ATUIN_NOBIND=true
eval "$(atuin init zsh)"
bindkey "^R" atuin-search

# incremental history search with arrow keys
bindkey "^[[A" history-beginning-search-backward
bindkey "^[[B" history-beginning-search-forward]]

If you’re using ZSH, its autocomplete will work normally but, if you type CTRL+R, it will open the Atuin history. It will save all your commands in a SQLite and sync. That way you can sync several machines and servers you use day-to-day or, as in my case, recover the whole history on a new install.

And to make it better, we can configure it to auto-sync:

mkdir -p ~/.config/atuin
sed -i 's/^#\?auto_sync.*/auto_sync = true/; s/^#\?sync_frequency.*/sync_frequency = "30m"/' ~/.config/atuin/config.toml 2>/dev/null || \
printf 'auto_sync = true\nsync_frequency = "30m"\n' >> ~/.config/atuin/config.toml

Third tip: since we have Docker already installed and configured, I like to use SGPT on the command line for when I want to remember the syntax of some command I rarely use, instead of opening an app or browser. Just add this to my .zshrc:

export OPENROUTER_API_KEY="sk-or-v1-8b8...17"
export OPENAI_API_KEY="sk-or-v1-db...f3"
export OPENAI_API_BASE="https://openrouter.ai/api/v1"

alias sgpt='docker run --rm -e OPENAI_API_BASE=${OPENAI_API_BASE} -e OPENAI_API_KEY=${OPENROUTER_API_KEY} ghcr.io/tbckr/sgpt:latest txt '

I use OpenRouter to have access to different commercial LLMs in a single API, but you can just use your OpenAI key. With this done, I’d use it in the terminal similar to this:

~ ❯ sgpt "what is the pacman command in Arch to find out if a particular file came from an installed package?"
To find out if a particular file came from an installed package in Arch Linux, you can use the following pacman command:

``bash
pacman -Qo /path/to/file
``

Replace "/path/to/file" with the actual path to the file you want to check. This command will show the package which owns the file, or report that the file does not belong to any package if that is the case.

If you want, it supports sessions, so it’ll remember the conversation on each new call. Read the project’s Github.

Since I backed up my old ~/.config, things like open tabs from my Brave browser opened normally in this new Omarchy install and I can keep doing my things exactly from the point I left off. I didn’t lose anything. The same goes for all the other apps like emails that I back up locally via Thunderbird. I don’t need to have it all downloaded again.

If, like me, you have several audio output devices, it’s possible that right after finishing the install you’ll notice that it seems there’s no sound. But that’s not a problem because it may just be that the output is pointing to the wrong device or the wrong profile. Use SUPER ALT SPACE to open the Omarchy menu, choose SETUP and AUDIO to open that program which is text mode (I like text mode programs).

In my case, I use a Topping D70 DAC to process my audio and the “Default” profile doesn’t work but switching to “Pro Audio” worked. Also be careful that there’s a global volume setting and individual volume control per program. Overall, thanks to Pipewire, everything should work normally.

I tested apps like Discord, Blender, Bambu Studio, VLC and everything worked perfectly. Only VLC needed codecs from a separate package:

yay -S extra/vlc-plugin-ffmpeg

Blender too, the best is to install from this package:

yay -S blender-bin

If you use the normal “blender” package, some of its add-ons don’t install right. I had this problem with MACHIN3Tools and MESHMachine, for example.

Speaking of Blender, it’s an X11 app. Wayland runs X11 applications using an adapter layer called XWayland. I had several problems with menu and dialog box positioning, even adding windowrule. One thing that worked, I’m not sure why, was installing Blender and Bambu Studio via Flatpak:

yay -S flatpak
flatpak install org.blender.Blender
flatpak install com.bambulab.BambuStudio

Finally, if you’re new to LazyVim, don’t forget to run the :LazyExtras command to install extra plugins for your favorite languages, like LSP, Linter, syntax highlight, snippets, and more. Pure LazyVim is already complete but without support for many languages so as not to be unnecessarily heavy; you need to install them separately afterwards.

Also learn to use Mise-en-place. In the Omarchy menu there’s an option to install support for various languages and it will use Mise, which is the correct way to manage your languages.

Mise is really easy, in general, from inside your project directory, just do something like:

mise use ruby@3.4.3

With this, only inside your project will Ruby 3.4.3 be available, but outside there can be another global version. Don’t forget to activate it in your .zshrc:

eval "$(mise activate zsh)"

Impressions and Conclusion

Compared to my old Manjaro, there’s a lot I no longer need to configure. For example, because of the amount of space Docker and LLMs needed, I had configured an iSCSI drive on my NAS just for that. But since I freed up 2 TB of local NVME, I no longer need to deal with that, I just use the new BTRFS sub-volumes I created above.

I also no longer need to configure QEMU/Libvirt because I no longer need to use Windows alongside Linux side by side. I kept the NVME with the Windows partitions and I can dual boot to it if I really need something. Overall I never need it, so it’s one less complicated configuration.

I spent months using apps via Flatpak, with the aim of being more secure and isolated from the system. It’s like running apps via Docker. But it’s too annoying. Being isolated means it doesn’t obey system themes, and in the end I’m forced to keep opening permissions for the apps. And if it’s going to keep opening them, it’s easier to install natively via yay and everything works perfectly.

I think that completes my notes of everything I needed to do to leave Omarchy exactly the way I like. As I said repeatedly, what works for me doesn’t mean it’ll work for you. For that there’s documentation like ArchWiki which is “THE” best place to learn everything about Linux. Use and abuse that documentation.

As you can see, there wasn’t all that much I customized in Omarchy, which is why I like it: it already did 95% of the path for me, I just had to touch a few adjustments to leave it the way I need. And now without all the junk that piled up in my old Manjaro. I recommend everyone install Omarchy as a first Linux and learn to actually use it.

Everyone who follows me, particularly on Instagram, knows about my NAS saga. In particular my new Synology DS1821+ with more than 100TB (4x 12TB HDs and 4x 20TB HDs, and I already have 4 more 20TB HDs to upgrade in the future when I need to). I use it for a lot of stuff, particularly my Personal Netflix that I explained in that other post on how I set it up with Docker.

In the highlights and posts about it on Insta I already discussed details of this NAS, but to summarize:

• I prefer Synology because deep down it is a Linux box with the BTRFS filesystem (which I like), which is almost as flexible but easier to use than ZFS. And yes, I know unraid, TrueNAS and others exist. But I think Synology DSM is very competent (there is an open source version if you want), and it does everything I need.
• I prefer Plex over Emby or Jellyfin. I have tested them, but Plex’s support for TV and mobile apps is much better in my opinion, the player is more stable, and I also think its organization features are more robust.
• Why not just use Cloud? First because it is slow. My fiber is only 1Gbps and upload is half of that. Second because my internal network is ultra fast (10Gbps) and much better. Third because nothing in the “Cloud” has any guarantee, they can block you, they can get hacked, they can delete things by accident. Fourth, everything that is mine, I like it being really mine, within my reach, under my total control, with nobody to mess with my property. It costs more, it is a choice. I literally have more and better movies and series than Netflix with content you will not easily find in any streaming service anymore, for example.

In fact, I trust “cloud” so little that I use it but I keep a copy of everything on my local NAS using the Cloud Sync app from the Synology store:

“Yeah, but what if your NAS dies in some unrecoverable way and you lose EVERYTHING?!”

No backup is complete unless it follows the 3-2-1 Mantra, remember??

• 3 copies, 2 media types, 1 off-site

I have some things recorded on Millennial Discs (mdiscs, which are like Blu-Rays but made of inorganic material that never degrades). And I make copies of the most important things from my NAS to Amazon Glacier using the “Glacier Backup” app that is also in the Synology store.

Glacier is like S3 but much cheaper because it does not have easy access or fast transfer. It is built for backups, where you write once and almost never access again. ENCRYPTED, of course.

Notice how little I trust cloud, like dropbox, that I make a copy on my NAS and send it to another cloud. There are things with multiple copies indeed. I do not trust anyone’s service, some human will always commit a catastrophic mistake one day, it is just a matter of time.

Oh yes, and I do download a lot of things from torrent and I consider myself a Power User and I know what is malware/virus and what is not, and I know how they work. But I am also human, so all my Windows machines have at least Windows Defender active, Malwarebytes which I also like, and even so I still run yet another antivirus on the NAS as well, which is also in the Synology store. I do not trust anything without redundancy of everything, under my total control.

More importantly, and the reason I choose BTRFS both on the NAS and on my PC: snapshots. It takes snapshots of everything periodically. So, if at some point I run a botched rm -Rf, I lose nothing, I just go back to the previous snapshot and everything will be there, intact. Snapshots are smart, they take almost no space, because in BTRFS the same binary content of identical files points to the same physical location. It does not work like rsync that actually duplicates everything and doubles the space used.

On your Linux PC/notebook, with BTRFS, install the Timeshift program to do the same thing. The best part: if one day you update your system and it does not boot or something breaks after an update, it is easy: just reboot and choose the previous snapshot in GRUB and that is it, it will go back exactly as it was before the update. On Arch/Manjaro it is smart and already takes snapshots automatically every time before pacman runs:

Anyway, another use is for personal code projects on my Linux. On the mini-PC I use on the TV as a media center, I run Windows 11. Because I use it connected to another eGPU with an RTX 4060 and I use Steam for games. Yes, many Steam games run on Linux, there is Bazzite, etc. But there are things that only run on Windows and I preferred convenience. I only use it for games and media, so screw it, it works plug and play.

My other home server mini-PC is where my Docker stuff for media center, torrent, plex server and everything else runs. It is a headless Ubuntu LTS. Plus my handhelds like the Rog Ally X that runs Windows. All of them have access to my Synology NAS, where I expose shared folders with SMB and that is it. Plug and play.

I used to do the same on my Manjaro Linux: mount the folders with SMB. But this has a problem if I want to code something and want to use Git: in SMB there are no chmod attributes (like the +x flag for executable scripts) and every time I do git push, it messes up all the permissions of everything. It is a huge pain. Anyone who has used Git on Windows knows this.

I cannot keep scripts executable in this shared directory. So it makes my life hard on Linux. So I decided to fix this once and for all and do the right thing: stop using SMB and start using NFS, which is the native Linux way to access shared folders on the network from another Linux server (if the server were Windows, then it would have to be SMB, but nobody in their right mind sets up a NAS with Windows Server).

In SMB, the service ignores filesystem ownership and permissions. I create users and assign them to the service, not to the files. Just log in with that user and it will have access to the files. So there is no way to do chown and change ownership, nor chmod to change permissions individually on the files, it is all normalized.

In NFS, the service exposes exactly the ownership and permissions on the filesystem directly, without an ACL middleman to check permissions on the side. So I have the same level of access to those attributes that I have on the local files of my Linux, which is what I want.

But Synology does an annoying thing for some reason. On any Linux, the first user and first group created are usually UID: 1000 and GID: 1000. Try it, go to your terminal and run id [your user]:

❯ id akitaonrails
uid=1000(akitaonrails) gid=1000(akitaonrails) groups=1000(akitaonrails),998(wheel),996(audio),994(input),...

So it does not matter whether you do chown akitaonrails:akitaonrails foo.txt or chown 1000:1000 foo.txt. In practice, the identifier number is what matters, not the name.

With NFS, if on the Synology side there is a user with the same UID and GID number, I automatically have permission. But when you create users on Synology, for whatever reason, it starts creating them with IDs above 1020 instead of 1000. So I have an “akitaonrails” user on Synology with UID 1026 instead of 1000.

Even being able to mount the shared folder with NFS, if I try to use Git, for example, it detects that my local UID is 1000 and the files have ownership of UID 1026:

git st fatal: detected dubious ownership in repository at '/mnt/gigachad/Projects/dotfiles' To add an exception for this directory, call: 

	git config --global --add safe.directory /mnt/gigachad/Projects/dotfiles

I cannot keep using mixed UIDs, it becomes a mess as bad as SMB. There are mapping tricks and other hacks, but there are only two “cleaner” solutions:

• change my Linux UID/GID to also be 1026
• create a new user on Synology, change its ID to 1000 and chown all files to this new user.

I chose the second option. The first thing is to enable SSH access on the NAS (the ideal is to leave such things off, for security, but I am on a private local network so the risk is minimal):

At a minimum I always change the default SSH port, out of habit, but it does not really matter. You need to know how to use SSH, I will not teach it here, there is ChatGPT for that.

Now, create a new standard user:

Let’s also make sure the NFS service is on, since I am going to start using it (by default it comes off, with only SMB on because the majority of clients are Windows PCs):

Now SSH into the NAS and edit the UID and GID, first by editing /etc/passwd and finding a line like:

akitaonrails-nfs:x:10xx:10xx:...