[drop_cap]R[/drop_cap]emember the original promise of Social Media? “Connect with your friends” – “share cool stuff” – “hang out and get to meet new people”.

Fast forward to 2026 and social media is a fragmented hellscape of ideological silos and algorithmic meatgrinders, everyone tap-dancing for ever-shifting virality metrics while the platform-keepers harvest each minuscule flick of our eyeballs for ad revenue.

“Don’t Show Me More Of This”

You know the drill. The longer these platforms keep you glued to their “feeds” (why does this term always remind me cattle farms?) the more vigorously they can present their PowerPoint presentations and proudly proclaim “2% increase in user stickiness”.

The fact that it’s all slop, propped up by bots, engagement-share-croppers, vapid hot takes and rage-bait–let’s not talk about it. Business is booming. Advertisers are spending. The kids are lapping it up. And so are the oldtimers. Swiping all day long. Just don’t make them leave. Integrate, consolidate! Intersperse cute animals with geopolitical carnage, productivity hacks with celebrity gossip, thirst traps and hyper-personalized content, custom-tailored to trigger you where it hurts, smack-dab in the mammalian cortex.

Can’t log off. Must “monitor the situation”. Pull to refresh. The dopamine slot machine. Open your mouth wide. And feed.

The funniest part about all of this is: nobody asked for social media to become a behavioral optimization machine. Yet that’s where every platform eventually drifted. The open web? Who needs it anyway? Hyperlinks? Pah, where we are going you’ll get likes and comments instead!

Somewhere along the way, “sharing something online” quietly became a commitment. Post something and now you’re expected to monitor reactions, reply to comments, check analytics, maintain a presence. Communication was no longer enough. You had to manage its aftermath.

But at the end of the day, social media is just software, like anything else. Input and output of data: simple text messages, with some images and videos sprinkled in.

Exodus To The Terminal

A few days ago I thought to myself: what if we stripped all that extraneous nonsense away and drilled down to the very core of what social media actually is? What is left if you kill the feed, the hearts, the thumbs up, the comments, the “analytics”?

Just bits and bytes of data going from A to B. Mostly text, with some images and videos sprinkled in. No tracking, no ads, no bloat, just pure unfiltered sharing.

And what better place to build it in than the terminal, that beautiful text-based domain of data manipulation.

I already had most of the cross-posting-API stuff ready from my previous project, including image/video support, so porting it all to the terminal was a surprisingly quick undertaking.

Have a quick thought? Just pop open a terminal (or even better: bind it to a hotkey), send off your tweet/toot or whatever they call it these days, and carry on with your life.

No harm done. Not a single browser or app icon touched. Not an eyeball defiled by ads. Never sidetracked by “related posts”. Just share and move on.

If someone replies, fine. Deal with it later. If not, also fine. At least you’re not going to waste time gulping down the slop-du-jour while the C-suite books yet another “digital detox” to the Bahamas.

And besides, what do you need notifications for? You have your phone next to you anyway at all times, you filthy animal.

But isn’t that “anti-social”, you say? To just “broadcast”, unidirectionally like a fax machine possessed by a purpose?

When you want to share, share.

When you want to read, read. Got a moment of downtime? Comment, engage. On your terms.

Clean separation of concerns.

FOSS / MIT license

Github repo: github.com/burninc0de/socialsox-tui

–

The post The Feed Is A Lie appeared first on André Klein Dot Net.

Adaptation (2002)

[drop_cap]T[/drop_cap]here’s a type of writer who just writes. That ain’t me. Hand-cutting and gluing books to sell after readings. Uploading home-made PDFs to an FTP server at 2am. Spending hours in Berlin print-shops agonizing over the perfect glue-binding for a short story collection. The writing was never enough–I always needed to control the whole thing, soup to nuts.

Having written and published around twenty books for German learners over the last decade, my workflow went through many different iterations, from using OpenOffice (sue me …) to Calibre, Mobigen, InDesign, Sigil, Scrivener, Vellum, Papyrus and a bunch more. I’ve always been on the lookout for the perfect brain-to-world pipeline, with minimum amount of fiddling–and quite frankly–nonsense.

There’s nothing worse than fighting your own tools.

Some tools are very good at doing one thing–InDesign for print, Sigil for EPUBs. Others try to do everything for everyone. Some lock you into a polished but shallow box–great until you need something they didn’t anticipate. Others go the opposite direction: corkboards, character sheets, diary entries about what your protagonist had for breakfast. You stop writing and start managing the software.

So for many years I just went with using special tools for special purposes, which meant maintaining different versions for digital and print. Reliable, deterministic results, yes, but also two completely separate pipelines. Never-ending “version-tracking” (finalv2_final_FOR_REAL.epub)–wondering what got updated where, what still needed syncing. Not to mention all the copy-pasting of recurring elements like “About the Author”, “Newsletter” and whatnot. So much copy-pasting!

But the dream was always: one manuscript → typographically perfect PDF and crisply-coded EPUB.

And yes, many tools promise that. They just never clicked with me.

Bootstrapping Time

In early 2025, I’d finally had enough. I was just going to build my own publishing suite, from scratch.

The plan: write in plaintext (Markdown), export to PDF and EPUB from the same “codebase”.

How hard could it be? Quick 20-minute in-and-out adventure.

Well, it’s now mid-2026. A year and a half of iterating, rewriting, bug-fixing, and at least one complete breakdown over German hyphenation in PDFjs. It’s probably the longest time I’ve ever spent on a (non-web) software development project.

Anyway, I’ve just published my latest book, Horror in Heidelberg, volume 13 in the Dino lernt Deutsch series for German learners, which was completely written, formatted and typeset in this new pipeline. So I guess it works.

The core stack is pretty simple:

• Electron React/TS (works on Linux, Mac, Windows)
• react-markdown for Markdown processing
• epub-gen-memory for crisp EPUBs
• Typst for pixel-perfect print typesetting

Building The Skeleton

The first few weeks I wired up the basic skeleton: Obsidian-style “filesystem-as-database” approach where I can just drop introduction.md, chapter1.md into a folder and have that be my document outline. No SQLite or annoying abstractions.

Then I spent a lot of time on creating the actual writing area. Coming off years of working in WriteMonkey or iAWriter, I knew exactly what was needed: clean spacing, horizontal padding, nice fullscreen distraction-free mode, etc. (I’ve since recreated that same workflow in my terminal writing app Helowrite).

just words and a counter

So I opted for a bare-bones textarea approach. No complex dependencies like monaco or codemirror. That kept things simple, but it also meant writing a bunch of things like search/replace and highlighting from scratch. Anything for simplicity, right?

Next, I started work on a templating system. I’d manually copy-pasted copyright pages, TOCs, exercises, etc. a million times before. Automating it was long overdue.

I ended up writing a very basic template short-code language with a bunch of variables, so I could have a copyright.md that would look something like this:

**%%TITLE%%**
Copyright %%YEAR%%
[[EPUB: %%CLICKABLE_LINK%%]]
[[PDF: __CUSTOM_TYPOGRAPHIC_ELEMENT__]]

Obviously, images had to be processed separately for print & digital as well, with custom DPI and compression, etc. And then there was the whole footer, header, gutter business of typesetting.

It was my first time working with Typst–a steep learning curve, but nothing compared to LaTeX, a system I have spent a decade admiring from a safe distance.

So I wired up a simple Template.config, have my Electron app watch any changes in it and automatically hand it off to Typst to render changes in a PDF previewer, which made iteration extremely fast. Because let’s face it: constantly exporting a PDF just to see if you have the perfect value for a header margin or line-spacing is torture.

I haven’t seen other apps do this, but after experiencing “hot module reload” for PDF exports I never want to go back.

live PDF preview – export for print or digital

Once the pieces slowly started coming together, I had this dangerous feeling of: “damn, this might just work.” But a working prototype is just that. Would it survive a whole book-publishing run? Where were the critical faultlines, annoying bugs or perhaps show-stopping failures?

Only one way to find out …

Dogfooding Until It Clicks

I told myself: try to write and publish your next book with this tool. Either it’s going to work, you will fix all the bugs, or you will run into something critical, give up and just go back to the bifurcated road of maintaining separate versions for print and digital.

So anyway, I started dogfooding …

When you are developing something like a search function, you set up a keybind, have state of inputs and highlighting work and say: “There, done.”

But when you’re in the trenches in your fullscreen editor, just words on a page, you are not thinking like an engineer. You just need to quickly jump to a word, right now. If the search bar behaves even slightly weirdly, if it causes a micro-stutter, or if it messes with your cursor placement, you get irritated immediately.

The more I worked in it, the more annoyances I found and fixed. When something worked well enough that I stopped noticing it, when it became pure muscle memory, I moved on to the next problem.

And it wasn’t just pure UI-stuff either. I’d spent enough years on these types of materials to know exactly where the landmines were. For example, when creating glossaries with translations, it’s incredibly easy to accidentally mix up the order of words, or delete a definition that a later chapter still relies on.

So I ended up building a whole vocabulary manager tool that can not just keep track of this for me, but even provide a diagnostic view where I can see: “Oh, I’ve defined that word twice in chapter 2 and 4, or I’ve introduced the word in chapter 3 but only referenced it in glossary in chapter 4.”

VocabAnalyzer – catch continuity errors in glossaries (and ANKI export)

Same with exercises. Many of my books have multiple-choice questions scattered throughout the book and an answer key at the end. Manually compiling the answer key, while possible, was time-consuming and prone to errors, especially when doing quick edits where a question had changed its position or correct answer. So I just wired up a tool that could do it deterministically: check all exercise chapters (based on template), grab the correct answers, print in answer key.

There are a bunch of other quality-of-life improvements like these I ended up integrating, not because they would be helpful for some theoretical “user”, but simply because I needed them, because they would relieve very particular kinds of pains I’ve been struggling with for longer than I’d care to admit.

This includes stuff like: automatic export of glossaries into ANKI .apkg decks, noun gender parsing from dictionary, LanguageTool integration for grammar and spellchecks, EPUB post-processing, on-the-fly image optimization for print/digital, automatic export of truncated preview PDFs and EPUBs, and a million other things.

10/10 – Would Dogfood Again

Looking back over the last couple of months working like this, I can now safely say that the software, while obviously not perfect (I know better than anyone where the bodies are buried), is battle-tested enough and works well enough that I just don’t want to go back to the old way anymore.

Perhaps one day I’ll end up sharing this tool with a wider audience. The “Markdown to typographically perfect PDF and EPUB” is still somewhat of a holy grail, especially for books with complex layouts.

Then again, for now I just want to keep writing and publishing with it and not start a second career as a software support guy.

But if there’s a takeaway: don’t settle for tools and workflows that fight you. Fight back by building your own. Push through the roadblocks, squash the bugs and dogfood until it clicks.

How hard can it be?

–

The post Building My Own Markdown Publishing Suite, or: Dogfooding Until It Clicks appeared first on André Klein Dot Net.

font: Delta Corps Priest 1

[drop_cap]I[/drop_cap]t’s no secret that minimalist tiling window managers and “full-fat” desktop environments are deeply at odds with each other, both in form and function.

That’s why usually when someone wants to get started with Hyprland the recommendation from the Council of Greybeards is: start from scratch (set up a new machine), or at least use a different user so your Hyprland and KDE or Gnome don’t end up in a turf-war over .config files, GTK/QT theming and whatnot.

And they are right. And so an ironclad decree was forged in the hearts of minds of the unixpr0n community: “Ye who want to taste the Rice must abstain from the ways of the regular desktop.”

And I get it, if you spent too many hours jerry-rigging the perfect waybar setup (been there, done that) and have the borders and animation of your rofi or walker dialed in juuust right, you’re in for the long haul.

But what if you want to have your cake and eat it too?

Tiling Fatigue

What if sometimes you just want to lazily go about your business with a trackpad without holding down SUPER like a clutch (the audacity … I know), yet at other times, when inspiration strikes, you are pining for the neon-drenched void of the Hyprland for dev work or bashing out prose in a brutalist terminal?

“Well,” they say. “You can’t do that! You either learn how to do everything in a tiling window manager or you simply are not worthy.”

So you ignore them. You set up a new user for Hyprland, but then find yourself “locked out” from your own files, configs, wallet (passwords) and whatnot. And maintaining a whole second account with second configs and everything just for switching your desktop workflow?

That’s no fun.

So for my latest experiment I wired up an ungodly alliance between my KDE Plasma desktop and Hyprland. No different user switching, no endless GTK/QT theming conflicts. Just switch the session whenever you feel like it.

I stole the basic look & feel from “Omarchy”, but since this is neither real “Omarchy” nor even Hyprland in a classical sense (see below), I dub it: “Fauxmarchy”.

The Masquerade

To achieve this seamless switch between KDE and Hyprland we are essentially “tricking” Hyprland into thinking it’s KDE with this sacrilegious array of environment variables:

env = QT_QPA_PLATFORMTHEME,kde
env = KDE_FULL_SESSION,true
env = XDG_CURRENT_DESKTOP,KDE
env = KDE_SESSION_VERSION,6
env = DESKTOP_SESSION,plasmawayland
env = GDMSESSION,plasmawayland
env = GTK_USE_PORTAL,1
env = GTK_THEME,Breeze-Dark
env = XDG_MENU_PREFIX,plasma-

I know. It’s ugly, it’s blasphemous. It goes against the grain of everything the Greybeards have taught us. But it’s brutally effective for a number of reasons.

No More Theming Bullshit

KDE Plasma has a nice and convenient way of globally styling all GUIs (whether QT or GTK) via their Application Style menu.

To achieve the same in Hyprland you have to fiddle endlessly with nwg-look, qt5ct and qt6ct just so native Linux GUIs don’t look like an ugly stepchild from the Windows era.

But with our unholy environment variables we are basically letting Hyprland inherit the KDE space, no questions asked.

So you could do all your “app styling” in KDE, plop over to a Hyprland session and have it all be registered. No more worries that Hyprland’s meticulously curated QT/GTK themes will mess up your KDE Plasma look & feel, or vice versa.

Plasma sets the tone, Hyprland follows. Zero conflict. For good measure also wipe all fake envs on exit from Hyprland:

bind = CTRL ALT, Q, exec,
QT_QPA_PLATFORMTHEME= KDE_FULL_SESSION= XDG_CURRENT_DESKTOP= KDE_SESSION_VERSION= DESKTOP_SESSION= GDMSESSION= GTK_USE_PORTAL= XDG_MENU_PREFIX=
&& hyprctl dispatch exit

Wallet Woes

Another annoying issue with switching in between Hyprland and KDE is the “secure storage” issue. You don’t want to constantly re-authenticate everything, just because you switched your session and have Hyprland scream: “new phone who dis?”

By masquerading our Hyprland session as KDE we can bypass all of that. All apps and services can continue using the same wallet, without triggering false-positive “breaches” and forcing re-auth. Because for all intents and purposes we are running a KDE session.

To get the party started without any “unlock your wallet” prompts in either KDE or Hyprland, get the kwallet-pam package and then we can directly hook into the wallet as soon as SDDM hands off to our Hyprland Fauxmarchy session. Note: user pw and wallet pw need to be identical for this to work.

In hypr autostart.conf :

# 1. Export the core Wayland context to the systemd user session
exec-once = dbus-update-activation-environment --systemd WAYLAND_DISPLAY
exec-once = systemctl --user import-environment WAYLAND_DISPLAY
# 2. Force the PAM handshake to claim the decrypted wallet keys left by SDDM
exec-once = /usr/lib/pam_kwallet_init
# 3. Tell the systemd/D-Bus environment that a KDE-compatible desktop is handling secrets
exec-once = dbus-update-activation-environment --systemd DISPLAY XDG_CURRENT_DESKTOP=KDE


And there you have it. One wallet to rule them all.

KRunner

Yet another cool thing about this setup is this: no more need for cobbled together app launchers. You can just use KRunner.

I know, right? Is this allowed? Well, usually it won’t work if your XDG_CURRENT_DESKTOP is set to Hyprland. But since we are basically lying to the desktop portal at this point, KRunner works just fine.

It’s extremely fast and more flexible than any other Hyprland launcher I have ever used (search for files, bookmarks, do calculations, whatever) and best of all: no need to install and babysit yet another package.

But, the bloat!

So what’s the cost of running a system like this? Because, yes, the xdg-desktop-portal-de sits in RAM now, but at least it uses 0 CPU until called upon.

There’s a long-running obsession in this community where people scoff at an Electron app using 150MB–a rounding error on any modern system–while cheerfully running ten dockerized Alpine containers without a second thought.

Meanwhile the KDE portal service sits at a respectable ~354MB. Not nothing, but not a dent in real-world usage either. And look what it buys you: full KRunner integration, consistent styling across sessions, zero-effort wallet auth.

If your Hyprland config breaks (because it always does during updates), doesn’t matter. Switch to KDE and fix it later. Got tired of Hyprland? No problem. Just remove the ~/.config/hypr folder and the packages and you’re back to square one.

No life-long commitment to the “tiling only” workflow. Non-destructive. Best of both worlds.

Screenshots

The blasphemy: KRunner in Hyprland

HeloWrite and Dolphin and pushing markdown to blog

just some audio TUI goodness

Now I can go from the above workflow to the below and back, by just switching the desktop session (note how the QT GUIs retain their styling):

no actual EPUBS were harmed in the making of this screenshot

And yes, both workflows have their upsides and downsides. For office and publishing work I prefer the organized mess of floating windows, for dev stuff or raw writing, there’s nothing better than the Way of the Tile. Why limit yourself to one? Just switch depending on context. And the best part:

No config pollution (just a neat hypr folder in .config ripped straight from the Omarchy repo, plus a few waybar edits and fresh keybinds). And it didn’t even take an ungodly amount of packages:

hyprland waybar awww hyprlock
bluetui wiremix hyprpicker wlctl
wl-clipboard swayosd hyprshot

The Greybeards will not approve. But they never do. Switch sessions whenever you feel like it, fix Hyprland when it inevitably breaks, and go back to clicking things with a mouse without shame. The rice will still be there when you need it.

–

P.S: By masquerading as “KDE”, Hyprland will complain on launch that “Your XDG_CURRENT_DESKTOP environment seems to be managed externally. This might cause issues unless it’s intentional.”

Since this is definitely intentional you can bypass that warning by dropping this into your hyprland.conf:

misc {
disable_xdg_env_checks = true
}

P.P.S: Of course I also had to implement the screensaver in true Fauxmarchy fashion. Just tte and a text file:

The post Fauxmarchy: A Sacrilegious Hyprland/KDE Setup appeared first on André Klein Dot Net.

[drop_cap]I[/drop_cap] never understood all the hype around Obsidian as “second brain”, and the way some people throw around the German word Zettelkasten like some obscure grand cru vintage. As if the gritty business of memorization had a dress code.

(By the way, the German “Z” here is a hard “ts”, not soft “z” as in “zoom”, so at least get it right. But I digress …)

“Look”, the Obsidian snobs sneered from within their meticulously organized vaults: “If you don’t organize everything you do in markdown, you’ve already lost control of your life.”

I pressed “x” for doubt. Hard. And kept on pressing.

For years I was perfectly fine just stuffing various notes about my books into Evernote (before the SaaS-mandated nickel-and-diming started) or even just randomish important.txt and todo_BK.txt scattered around my local filesystem and cloud drives like demented breadcrumbs.

Then I started messing around with Linux last year, and suddenly, I had to keep track of a host of different configs, strange dotfile quirks, custom systemd services, cmdline flags, fstab mounts and a million other things.

So I gave Obsidian another try.

And no, before you ask — I haven’t gulped down the kool-aid. I still only use about 1% of Obsidian features. In fact, I barely ever open the app.

What I did embrace was the idea of “markdown files in folder” as a kind of poor man’s database. Similarly to how HTMX treats the DOM as state rather than a separate layer, with this paradigm of plaintext in folders and subfolders, the filetree is the database. Relations are mapped transparently, right there in front of you.

No proprietary lock-in. No esoteric SQL invocations. Extremely light-weight, low-friction and portable.

It was glorious.

And the more I worked in this way, the more I started applying this principle to other arenas. For example, I’ve been building a new publishing suite for my books where I can go from one codebase of raw markdown to typographically perfect PDFs (via TYPST) and EPUB.

Database? Nah. Just chapter1.md in a mybook folder. Done.

So, what do you Sync?

Since I barely use the official Obsidian app anymore, their proprietary sync mechanism is useless to me.

My “vaults” are just git repositories. Easy to commit, push and pull, from wherever I need.

And no, I am not letting Microsoft get their mittens on my “second brain”. No GitHub roundtrips here. I just have a bare repo sitting on my (diet)Pi, which acts as upstream source to all my devices. Just simple ssh git straight over local network.

And thanks to Tailscale I can now be “at home” even when away from home and push to my private local repo. It’s beautiful.

And for the purists: Yes, Tailscale is ‘managed’ WireGuard. But I’m here to get stuff done, not spend three days manually configuring handshake keys. It’s the same logic as using CachyOS over a manual Arch bootstrap. Pragmatism isn’t betrayal.

I was only left with one gap in that setup. Since the two biggest mobile operating systems (IOS/Android) are lobotomized bricks in terms of basic file system access, it makes it very difficult to run direct git operations, unless you jump through a million hoops.

So I ended up building a little React app (I know, famous last words …) that talks to a tiny gunicorn backend on my Pi. And now I can have direct access to my notes from anywhere in the world, completely local, no proprietary apps or any nonsense.

Not to make this seem like a “sponsored post” for Tailscale, but thanks to Tailscale’s HTTPS certificate feature, I was even able to install my little React app as a PWA, and now this thing just runs in standalone mode, virtually indistinguishable from a “real” app.

Pretty neat.

And I’m taking more notes than ever before. Linking, cross-linking, folders within folders. A glorious sprawling web of untethered information. And I’m never going back.

The Atomic Parade

As usual, all that glitters is not gold. The atomic file writing operations of this “markdown as database” paradigm can be problematic. On Linux this is very transparent where inotify is screaming at every daemon on the system. When you try to combine this with cloud stuff like abraunegg’s onedrive client, all hell breaks loose.

The official Obsidian app for some reason has still no way to disable auto-save or at least stagger saves, and this stuff can get chaotic fast.

Obsidian provides no mechanism to change how this save behaviour operates. This is a serious design limitation and should be treated as a bug in the application – abraunegg

Of Backups And Unicorns

For my new local-first Pi-based setup, I am literally my own one person Git provider. It’s insanely fast, but it also means, if the Pi goes bye bye, I lose my upstream.

But when Microsoft has a bad day and GitHub’s ‘Unicorn’ starts puking 500 errors, the entire world stops coding. When my Pi hangs, I just walk into the other room and power cycle it. I’d rather be my own sysadmin than a helpless passenger on a sinking corporate ship.

My mitigation is simple: the Pi just dumps encrypted vault backups in the middle of the night to an offsite server. So: multiple local copies, across different media/devices, plus offsite backup. Belt and suspenders.

–

The post Vault Dweller: How I Ditched The Cloud For A Pi And A Git Repo appeared first on André Klein Dot Net.

Brazil (1985)

[drop_cap]I[/drop_cap] built my first home page in 1996 in Microsoft FrontPage. It looked like a digital ransom note, but it was mine. Instantly accessible from anywhere in the world, without permission, like global graffiti.

In the early 2000s, like many others, I learned CSS by endlessly customizing MySpace profiles. Turns out learning to type the same HTML and CSS tags over and over again actually does wonders for remembering. I wonder if prompting Claude Code has similar effects. Probably not.

Then I got into WordPress and PHP, and that’s basically where I’ve been ever since—the constant hype-cycle of new JS frameworks nothing but a faint murmur beyond the walls of my trusty LEMP stack.

Until very recently, my “version control” system consisted of renaming files to index_FINAL_v2_FIXED_FOR_REAL.php.BAK. My “deployment pipeline” was an SFTP client and a prayer. If the site broke, I edited the live code on the server while users watched. It was stupid, and I knew it, but I had other things to worry about.

I’m not a developer in the classical sense. My identity isn’t tied to “the craft”. I love messing around with tech, but at the end of the day I just need stuff to work so I can publish my books and get back to writing.

A Brave New World

Last year I got the Modern Dev itch. I jumped into React and Tailwind, and Vite’s hot module reload is a blast—seeing a color change instantly without a browser refresh almost made me forget I was building a single-page app held aloft by a rickety stack of ever-shifting npm modules. I finally even learned Git (though I still treat rebasing like a dark ritual that might accidentally delete my hard drive).

Then I needed a contact form.

Suddenly I wasn’t a writer anymore; I was a civil servant in a Terry Gilliam movie, shuffling JSON through pneumatic tubes just to appease the Gods of TypeScript. I was spinning up Next.js instances, worrying about serialization and environment variables, and spending three days building a space station just to send an email that says “Hi.” I’d traded my sanity for a node_modules folder spilling out clown-cars of esoteric dependencies.

Meanwhile, PHP has no build step. You write, you execute, you’re done. A PHP process runs and dies with the request—no long-running Node processes accumulating memory, no weekly vulnerability disclosures in your 47 transitive dependencies. These modern frameworks were designed by massive engineering teams at companies obsessed with scale. That’s fine for them. I’m just one dude.

So I tried headless WordPress—React on the front end, WordPress handling auth, email, and content management behind it, all pre-configured. It worked great, even if you accept that most of your plugins are basically useless now.

Then I hit the hydration problem. A single-page app is basically an empty HTML file that loads a giant JavaScript bundle, and search engines hate it. So now you need two versions of your site: a skeleton and the actual interface layered on top. I got it working, eventually, by mixing in some PHP. Very much reinventing the wheel. Not as bad as running your own Next.js “vulnerability accelerator,” but still annoying enough.

“In 2025, attackers published 454,648 malicious npm packages. The average npm project pulls in 79 transitive dependencies. A single compromised package can cascade through entire ecosystems within hours.”cyberdesserts.com

Back To Basics

For my last two projects I went a different direction: HTMX and Alpine.js. Two tiny libraries that give you 80% of React’s interactivity at maybe 10% of the complexity. No build step, no dependency hell, no fresh CVEs landing in your inbox on a Tuesday morning. You write HTML, sprinkle in a few attributes, and things respond dynamically. It’s not as slick as React with Vite, but the friction it removes makes the tradeoff feel obvious.

But the real kicker is the stability. React code from three years one week ago is usually a graveyard of deprecated hooks and broken builds. PHP and HTML? They just sit there and work. Modern web dev feels like babysitting a Tamagotchi that dies if I don’t massage it with npm audits and overrides every second day.

My current happy place is WordPress as the backend with a lean HTMX/Alpine theme on top, developed locally with LocalWP, versioned in Git, and deployed with a simple bash script. I’m not pretending the last few years didn’t happen—I just got selective about which parts to keep.

How The Sausage is Made

Let’s have a look at some concrete examples to better illustrate the madness:

Exhibit A: Search Suggestions

With React/Next.js/TS you need a Client Component, a Debounce Hook, a Fetcher, a JSON API route, and a TypeScript interface for the “Shape” of a Post:

So far so good, right? But, wait! That’s only the front-end. Now go write the api/search.ts route, define the Post interface twice, once for the API route, once for the front-end, naturally. Oh, and don’t forget to fix the hydration error because the server time doesn’t match the client time…

Now let’s look at the “boring” alternative with HTMX. You don’t manage state; the DOM is the state.

Yup, that’s it. That’s the whole code. Back-end? Eh. Let WordPress spit out HTML. Done.

Exhibit B: A Simple Toggle Or Drop-Down

With React this would look something like this:

With Alpine you can do the same, but with fewer lines and no bureaucratic javascript wrangling parade:

Don’t get me wrong—I haven’t completely thrown in the towel. I still maintain a few SPAs in React (including this headless blog) where a high-fidelity interface actually justifies the headache. But it’s simply not always worth the trouble. Sometimes the old way (turbocharged with some HTMX and Alpine) is just fine.

Maybe it’s a step backwards. I don’t care. As long as the site loads fast, my code is readable, and I can get back to doing actual work.

We’ve spent a decade making the web harder to build just so we can feel more important. I’m over it. I’ll take a boring site that works over a cutting-edge one that turns basic maintenance into a second job.

–

The post I Went Back to Boring Web Dev, and I’m Not Sorry appeared first on André Klein Dot Net.

I prefer a global hotkey that triggers a picker and stays hidden otherwise. And we can hook right into the default KDE color picker, no need for additional packages.

the default widget is minimalist, but still distracting

The Solution: KWin D-Bus

We can do this by tapping directly into the KWin compositor using D-Bus. It’s fast and just works.


dbus-send --print-reply --dest=org.kde.KWin /ColorPicker org.kde.kwin.ColorPicker.pick


This will run the color picker. Pick a spot and click. As you will see it returns a uint32 (a big number), and we’ll need to convert that to a Hex code in the next step.

The One-Liner

For Wayland:


dbus-send --print-reply --dest=org.kde.KWin /ColorPicker org.kde.kwin.ColorPicker.pick | awk '/uint32/ {printf "#%06x\n", $2 % 16777216}' | wl-copy


This will run the color picker, convert the uint32 to hex and shove it straight into your clipboard, ready to be pasted.

For X11:
Swap wl-copy for xclip -selection clipboard.

Set the Global Hotkey

Don’t wrap this in a shell script unless you have to. KDE can handle this natively:

• Open System Settings > Shortcuts.
• Go to Commands and click Add New.
• Name: Global Color Picker.
• Command: Paste the one-liner above.
• Shortcut: Assign your favorite combo (e.g., Meta+Shift+C).
• Hit Apply.

And there you go. No wasted visual space. Just instant color pickings whenever you need it.

–

The post How to Create a Global Color Picker Hotkey in KDE Plasma (Without Widgets) appeared first on André Klein Dot Net.

As soon as I try to paste in an annotation saying, for example, “שלום” (shalom), it looks alright in the modal, although the left alignment is already an early warning sign that this isn’t fully parsed as RTL text:

But as soon as I hit “OK”? It flips. It renders as “םולש” (molash).

I work with Hebrew PDF documents constantly, and this has been a consistent blight on my otherwise happy Linux life. I even went so far as to try patching Okular (my favorite PDF app, if you couldn’t tell), but my C++ skills weren’t enough to defeat the beast.

And then it hit me. The glorious solution to this annoying problem. It is hacky as hell. In fact, it is such a gloriously dirty fix that one might almost call it elegant.

The RTL Fixer Script

I present to you the RTL Fixer: four lines (three if you’re a minimalist who hates notifications) of glorious letter reversal.

#!/bin/bash
content=$(wl-paste)
reversed=$(echo "$content" | rev)
echo -n "$reversed" | wl-copy
notify-send "Clipboard reversed" "$reversed"

What does it do? Exactly what it says on the tin. It takes whatever is in your clipboard, reverses the character order, and shoves it back into the clipboard.

The Workflow

Once bound to a hotkey (I use Alt+R), the workflow is seamless:

• Type your RTL text.
• Select and copy it. (CTRL+A, CTRL+C)
• Hit Alt+R.
• Paste it. (CTRL+V)

Enjoy your correctly rendered RTL text. (Of course, if you hate this 4-hotkey-pronged workflow, you could easily chain them, but for the sake of this post, let’s keep it simple.)

It works because the PDF viewer is going to reverse the letters anyway, so we’re just preemptively reversing them so they land in the “wrong” order, which makes them look right. It’s double-negative logic for the digital age.

And there you have it. Finally! RTL annotations in Linux PDF apps. Just as the good Lord intended. Well, strike that. The PDF format is clearly the devil’s work.

The “Legacy” Edition (X11)

I see you over there, still clinging to Xorg like a comforting, slightly buggy security blanket. If you aren’t on Wayland yet, the wl-clipboard tools won’t help you. You’ll need xclip installed.

Your version of the “dirty fix” looks like this:

#!/bin/bash
content=$(xclip -selection clipboard -o)
reversed=$(echo "$content" | rev)
echo -n "$reversed" | xclip -selection clipboard
notify-send "Clipboard reversed" "$reversed"

Same logic, different plumbing.

A Small Warning for the Multiline-Enthusiasts

Because we are using the rev command, this script is a “dumb” character-by-character flipper. It works flawlessly for single lines or short phrases. However, if you try to reverse a three-paragraph manifesto, it will reverse the entire string: meaning your last line will become your first line, and your brain will melt trying to read it.

Stick to one line at a time, and you’ll be golden.

Anyway, perhaps this will help someone else out there in the struggle. Or perhaps the PDF reader maintainers will eventually fix the BiDi engine.

Then again, I’m not holding my breath. The Venn diagram of “Linux Desktop Users” and “RTL-enjoyers” is probably not a massive circle.

In the meantime, I will keep calm and hit Alt+R.

Molash… I mean, Shalom.

–

The post The End-Boss of Linux Formatting: RTL Annotations in PDF appeared first on André Klein Dot Net.

[drop_cap]L[/drop_cap]ast year, I moved to CachyOS on my laptop. I expected a different Kernel. I was ready to do some things differently. What I didn’t expect was a total disruption of my workflow. Not just on that Linux machine, but across any other machine I would touch afterward.

Once you get familiar with Linux’s terminal-first approach and you’ve tasted the speed of a GPU-accelerated terminal and a shell that doesn’t fight you, going back to a standard Windows setup just feels … wrong.

I tried to reverse-engineer that workflow on Windows. I tried WezTerm, Starship on Git Bash, and native TUIs. I failed. Between terminal escape codes screaming into my mouse movements and Windows eating my AltGr keys, I realized the truth: Native Windows and truly “terminal-first” workflows are like water and oil (unless you enjoy working with Powershell. But that’s a totally different story).

Elevating The Subsystem

Just when I was ready to fold and relegate my TUIs to my Arch rig, I was ready for one last Hallelujah: WSL2.

Yeah, I know. By default, WSL is not the best experience. It’s a superior OS running inside an inferior one, burdened by a translation layer designed for trouble. But after a day of chipping away at the friction, I found a stack that almost makes me forget that I’m on a Windows machine and not mashing away at Kitty on CachyOS.

Lobotomizing the WSL

By default, WSL is slow because it scans your entire Windows $PATH—thousands of folders of legacy garbage. The trick is to cut the cord in /etc/wsl.conf:

[interop]
appendWindowsPath = false

Setting this to false drastically reduces shell initialization time because WSL stops crawling through your Windows binaries.

To stop WSL from becoming a memory parasite, I also added some performance flags. First of all, we shutdown the virtual machine after an hour of idle, so it doesn’t keep hogging resources forever:

[wsl2]
# Automatically shut down the WSL VM after 1 hour of inactivity
vmIdleTimeout=3600000

Next, we add this tweak to our %USERPROFILE%\.wslconfig (that’s on the host system, not the WSL box) to make the RAM-usage a bit “smarter”:

[experimental]
# Give RAM back to Windows as soon as Linux stops using it
autoMemoryReclaim=gradual

GPU-Accelerated Goodness

I settled on Alacritty for the terminal. Unlike WezTerm it plays nice with my weird German keyboard layout, e.g. AltGr+Q = @ and Shift+7 = /, and delivers the raw speed I need for my TUI development workflows.

But first of all we need to get a cleaner start. Let’s edit alacritty.toml:

[terminal.shell]
program = "C:\\Windows\\System32\\wsl.exe"
args = ["-d", "Ubuntu", "--cd", "~", "fish", "--login"]

Launching with --cd ~ ensures we start in the Linux home directory, not the/mnt/c/ mount which is a slow and sad reminder that Linux is just a tenant on this system.

If the colors are off, because they probably are, we can explicitly request the full truecolor goodness like this:

[env]
TERM = "alacritty"
COLORTERM = "truecolor"

Once everything is done, you should get a crisp and clean terminal experience on WSL. Here’s a quick screenshot:

Theme is the ever-goated TokyoNight, font is Delugia (which has excellent icon support) and just overall pleasant to look at. Shell is Fish+Tide. For those sweet ls colors you see in the screenshot above I stole some aliases from the excellent CachyOS fish.config, most notably:

alias ls='eza -al --color=always --group-directories-first --icons'
alias la='eza -a --color=always --group-directories-first --icons'
alias ll='eza -l --color=always --group-directories-first --icons'
alias lt='eza -aT --color=always --group-directories-first --icons'
alias l.="eza -a | grep -e '^\.'"


Since we are replacing ls with eza you need to sudo apt install eza on Ubuntu.

In the same vein, I also applied CachyOS’s replacement (slightly modified) for man so we can get actual nice-looking manuals:

set -x MANROFFOPT "-c"
set -x MANPAGER "sh -c 'col -bx | batcat -l man -p'"

For this to work you need sudo apt install bat on Ubuntu. And then typing man git will give you something like this:

Fixing Shell Colors, Path and Browser on WSL

If for whatever reason you get the “muddy color” problem where WSL doesn’t recognize Alacritty’s capabilities, you can force it in config.fish:

# Force Alacritty identity and TrueColor
set -gx TERM alacritty
set -gx COLORTERM truecolor

Once everything is set correctly $TERM and $COLORTEM should return the correct values:

The Bottom Line

By effectively decoupling WSL from Windows you can genuinely improve performance and make it feel a lot more like a native Linux environment. Add a modern terminal like Alacritty with truecolor support, a user-friendly shell like Fish and you’re officially on your way to making the terminal-first workflow on Windows significantly suck less more palatable.

Since I’ve been doing lots of terminal-centric work lately, I can now seamlessly switch between my Linux and Windows rig. Same look, same commands, same muscle memory. And when I launch Alacritty now and start bashing away, it almost feels like Linux is no subsystem at all, but the dominant driver.

Last but not least, to top off the TerminalCeption, here’s a screenshot of me writing the draft for this post in HeloWrite on the very stack (WSL-Alacritty-Fish) described in thist post:

UPDATE: once I had all of this working, I deleted the whole Ubuntu WSL instance and replaced it with a proper ArchLinux WSL install. Look and feel are the same, but using pacman and AUR on Windows is just so much fun. Almost a sacrilege. Even getting native Windows NVIDIA drivers passed through to CUDA-enabled FastWhisper on this Arch box just works.

Whodathunk.

–

The post Taming WSL into a Tactical Workbench For A Terminal-First Workflow appeared first on André Klein Dot Net.

MacOS users get Native Tabs in VS Code. On Linux/Windows? You get one instance per workspace and a mess of groupings on your taskbar.

I didn’t want a new OS; I just wanted a quick way to visualize and switch in between open workspaces.

The Solution: A Focused Taskbar

The native KDE Plasma Task Manager is powerful. You can customize it infinitely, drop it into top panel, massage appearance until it has a “tab-like” feel, but it lacks one crucial feature: Application Filtering. By default, the taskbar will always show all and any open tasks.

I hacked together a version that lets you “pin” specific apps to a dedicated panel. This creates a “Dev Mode” bar in the corner of your screen that mimics the VS Code native tabs feeling by showing only your active development tools. And it’s not limited to VS Code. You can create “tabs” like this for any combination of apps. Want to show only your active terminals and browser? Only file managers? No problem. Just filter.

Who needs “native” tabs when you can get a custom taskbar?

• Only show whatever you tasks you actually need for your workflow
• Filter by single instances like “code” or combinations like “zed,firefox”
• Minimal task bar without hover previews, audio bubbles, etc.
• Keep the “unrelated” junk (Slack, Spotify, Mail) in your main taskbar.

Quickstart

Here’s a quick way to get the plasmoid, copy it to your .local/share and restart plasma:

git clone https://github.com/burninc0de/kde-filtered-taskbar.git
cd kde-filtered-taskbar
./install.shAfter that, right-click any panel, click “Add Widgets,” and search for Filtered Taskbar.

The post How to get VS Code “Native Tabs” on KDE Plasma (Linux) appeared first on André Klein Dot Net.

[drop_cap]W[/drop_cap]riting is hard. It’s messy, unresolved, chaotic. You scrape scenes out of your skull and massage syntactical turds until they shine (or get thrown out in the next rewrite).

Code is different. Something either works or it doesn’t. Problems usually have clear paths to solutions.

Prose has no linter. You can’t pre-compile a plot-twist to catch continuity leaks.

So this week, after making solid progress with my new book, I “relaxed” by building a writing tool in my spare time. The irony isn’t lost on me.

The Calm of The Void

Staring at a white page sucks. First step? Make it not white. Stop shining a flashlight into your retinas while trying to decant the subconscious. Next, ditch the Microsoft kitchen-sink ribbons of colorful icons and formatting gizmos. Stop pretending you are a typesetter and fiddling with font sizes instead of dredging up dirt on your characters.

In short, remove everything else except the words.

I’ve always been a huge fan of this type of minimalist approach.

The less I see, the better. For years I’ve bounced between minimalist word processors: WriteMonkey, iAwriter, FocusWriter—always configured the same way: dark background, generous horizontal padding to spare my eyes the long left-to-right trek, a clean mono/duospace font, and a subtle word counter tucked in a corner that only shows when idle.

Notifications off, music on, deep dive. That’s the only way to play this game.

This weekend I thought: why not follow this minimalist approach, but strip it down even further, in the shape of a terminal-based tool. TUIs (terminal user interfaces) are all the rage these days and I admit—it’s fun in a deliberately discordant way!

No graphics. No animations. No gamification or “engagement” loops. Just the brutal, high-contrast reality of text.

I built HeloWrite in Python with the Textual library (great starter). Here’s a screenshot of the distraction-free mode, and yes, there ain’t much to see, which is precisely the point:

Cursor color follows theme, or your custom preference.

The Secret Sauce: Performance & Paranoia

I realized halfway through Sunday that I wasn’t just building this for the “aesthetic.” I was building it because I’m tired of waiting for my tools to catch up to my brain. Many modern writing apps are resource hogs. They have “loading” states awkwardly disguised by splash screens. They index. They bloat.

HeloWrite has a cold start so fast it feels like it was never closed. We’re talking 0.5 seconds from hitting Enter to a blinking cursor. And that’s running from source—no pre-compiled binaries, no bloat, just raw Python and the void.

And then there’s the Git workflow. You can set your Obsidian vault dir (or any repo for that matter) in the settings and git to your heart’s content. Push and pull individual files or chapters as you work on them and get version control for your writing. Never lose a line again. Send it all to the vault, while you write.

Don’t use git? No problem. Auto-save is built in as well. But if you are a writer (or a developer), you’ll probably spam Ctrl+S anyway. Just in case, right?

Settings Screens

Code and Corkboards

There are tons of amazing code editors out there. Vim fanatics can rice their configs until the heat death of the universe. Emacs people have basically built an operating system. Developers are spoiled for choice when it comes to terminal-based workflows.

Writers? Not so much.

We get word processors designed by committee, skeuomorphic corkboards, or minimalist apps that cost $50, do less than Notepad and still somehow end up feeling heavy.

I wanted something different. Something that understood the writer’s brain, but had the heart of a code editor.

I’ve tried other terminal-based word processors like WordGrinder, and while I loved the concept, the workflow never quite seemed clicked with me. So I just built my own, tuned exactly to the quirks of a lifetime of writing.

Begin Jump Prep

HeloWrite, pronounced “hee-lo” and named after Karl “Helo” Agathon from Battlestar Galactica, is completely free open-source software. It includes:

• Fully distraction-free mode with an out-of-the-way word counter
• On the fly adjustable horizontal padding to cut eye strain
• Many popular custom color themes including cursor styling
• Granular git push and pull commands

“I fell in love with a machine. That’s stupid. So just call me an idiot, and let’s be done with it.” — Karl Agathon

Clone, fork or hack here: burninc0de/helowrite

–

The post HeloWrite: A Minimalist Writing Tool For The Terminal appeared first on André Klein Dot Net.