daal.cloud - blog

My favourite anime

2026-05-14T00:00:00.000Z

If there's one thing I love, it's watching television. Or maybe it's just any screen, as I'm mostly sitting in front of screens. Makes me suddenly remember how I fucked up my eyes by programming when I was about 17, a whole summer holiday long, on a good ol' CRT monitor in a dimly-lit room. But I'm getting off track :-).

I wouldn't consider myself a huge anime fan. I used to have a friend who learned basic Japanese by basically inhaling a ton of anime shows, and that's a level of dedication I never got close to. But I've definitely watched my fair share, and I have clear favourites. I always prefer them in Japanese with subtitles. The dubs are usually fine, but the original voice acting just lands differently for me. The cadence, the yelling, the awkward pauses. Dubs flatten that out, and on top of it the lip-sync compromises end up changing the lines themselves. So subtitles it is.

# Elfen Lied

Oh wonderful Elfen Lied. I can already hear "Lilium" popping up in my head as I just write down the title of the show. Elfen Lied still, to this date, just "hits" me.

The character development is what does it. Lucy is the one we're talking about, although she also goes by Kaede, and by the gentler alter-ego Nyu. She's a Diclonius, a kind of next-step human with little horns and a set of invisible "vector" arms she can kill with from across a room. The show spends most of its runtime quietly explaining how she ended up that way.

The Kota bit (spoilers, click to reveal)

The relationship with Kota is the load-bearing piece. They met as kids, before any of the violence, when she was just a lonely orphanage girl and he was a boy on his summer holiday. He was kind to her. That early bond is basically the only piece of her life that wasn't cruelty or experimentation, and the rest of the show is asking what happens when you take a child, isolate her, abuse her, and then years later let her stumble back into that one thread of kindness. Honestly, chef's kiss.

# Hellsing Ultimate

Then we have Hellsing. Hellsing Ultimate specifically. That's the 10-episode OVA, not the older 2001 TV series, which goes off-script halfway through and turns into a completely different show. (Although honestly the fan-made Hellsing Ultimate Abridged is also a SOLID watch. Story-wise it's amazing, and I still laugh out loud every time I rewatch it.)

What I like about Ultimate is that it commits. Alucard is an ancient vampire bound to serve the Hellsing Organisation, which hunts other vampires in the name of the British crown. Sir Integra Hellsing is the one holding his leash, and somehow she actually pulls it off. A young woman in a suit, ordering the most dangerous creature on the planet around, and you buy it. Then there's Seras Victoria, a former cop turned vampire under Alucard, and her arc of slowly accepting what she's become is honestly the most grounded part of the whole thing.

What the plot actually does (spoilers, click to reveal)

The Millennium plot is the engine. A leftover Nazi battalion of artificial vampires turns up to settle a 50-year-old grudge, the Vatican's Iscariot organisation gets dragged in, and London ends up flattened. The fights are absurd and over-the-top in a way only animation gets away with, and the script takes itself seriously enough that the absurdity lands instead of curdling. The whole thing reads like a long argument about what monstrosity is, and whether men or monsters do more damage. It doesn't really land on an answer, which I think is the point.

# Panty & Stocking with Garterbelt

And now, in the voice of John Cleese to camera (possibly sitting at a desk in the middle of a field): "And now for something completely different." Panty & Stocking with Garterbelt. Rowdy innuendos? Check. Song tracks that contain too much moaning (looking at you "Pantscada", the whole OST was produced by Teddyloid and featured all over the series)? Check.

But mostly it has a ton of comedy that just hits my spot. It's two angel sisters kicked out of Heaven and parked in a place called Daten City, hunting ghosts for "Heaven coins" so they can earn their way back. The animation style is a deliberate slap at "tasteful" anime, closer to early Cartoon Network than to anything Studio Ghibli would put out, and they parody half the genre while they're at it. There's a transformation sequence in there that's basically Sailor Moon by way of a strip club.

The OST is the other reason to watch. Teddyloid's work on this show is unreasonably good, and it shows up at exactly the right moments. "Fly Away" over a car-chase episode is the kind of track you queue up later to listen to on its own.

And there is a twist at the end. I won't spoil it outright, but here's a small hint if you want one:

How the ending lands (mild hint, click to reveal)

The final episode commits to a bit so hard it almost stops being funny, and the long-awaited sequel that finally got greenlit is doing nothing to make things easier on people who liked clean endings.

# So why anime?

Makes me think, why do I like anime? Maybe because I grew up with cartoons and watched too much Ren & Stimpy :-). The three shows above don't have a lot in common other than being animated and being willing to commit to a tone. But I guess it boils down to me watching them at certain periods in my life, when they really resonated. These days I barely watch any anime anymore... maybe it's time to start again?

Recipe: Easy Tray Bake

2026-05-14T00:00:00.000Z

First food recipe on the blog. Wooooh! Time to see if Eleventy can handle a kitchen.

This is one of those toss-everything-on-the-tray recipes. About ten minutes of "work" and thirty minutes of oven. Most of the active time is fighting with baking paper on your tray.

Servings:

The base recipe serves 2. Scaled amounts are an estimate, adjust to taste. Whole items (onions, meatballs) round up.

# Ingredients

1x pack of AH Biologisch Rundergehakt balletjes (ah.nl) - that's 12 small beef meatballs
500 gram AH Krieltjes mix (ah.nl) - small waxy potatoes, mixed colours
375 gram AH Biologisch Winterpeen (ah.nl) - winter carrots, about half a 750 gram pack
2 large red onions, or 3 small ones
A bit of salt or Herbamare
A bit of olive oil (engine oil is not recommended)

# Time

Prep depends on how good your knife skills are. Mine are mediocre, so I spend roughly 15 to 20 minutes getting everything ready. It tends to help if your partner, your mother, or your neighbour gets a head start on the potatoes. Something something efficiency. Then 30 minutes in the oven.

Pro tip: switch the oven on to preheat right at the start of your prep, so it's at temperature by the time the tray is ready. Use conventional top + bottom heat, not the fan / hot-air setting.

# Tools

Knife
Cutting board
Peeler ("dunschiller" in Dutch; "rasp" is the Dutch word for grater, and the linked video is a small Dutch meme of someone hilariously struggling to pronounce it)
Oven
Baking tray
Baking paper
Electricity
Oven gloves, or a tea towel folded double

We have a 90 cm oven and tray. A smaller one is fine too, you'll just probably need to split it across 2 trays or 2 rounds.

# Instructions

Grab the baking tray and chuck the baking paper on top. Once you have won the fight with the baking paper and it actually stays put (seriously, always a hassle, my tip is to wet it a bit), start by de-sprouting and lightly cleaning the potatoes. We're fans of potatoes with the skin on, because hey, why bother buying the pre-mixed bag otherwise ;-). But you do you! Cut them into bite-sized chunks and lay them on the baking tray on top of the baking paper (under it would be a bit strange).

Peel the carrots with the peeler first (long strokes, away from your fingers, you know the drill). Then cut them into bite-sized chunks and put those on your baking tray too (yes, on top of the baking paper that is on top of the tray, you've got the idea by now right? ;').

Slice onion rings. Yes I know, boring work, but you can do this. I can do this, trust me, you can do this too. Drop them on the tray.

Open the pack of meatballs. Try not to send the balls flying across the kitchen because you opened it a bit too enthusiastically (speaking from experience). Place them on the tray.

Grab your olive oil (so NOT engine oil) and sprinkle a bit over everything on the tray. Or, if you want a less greasy result, grab a small bowl and a fancy silicone basting brush and brush everything with oil (hopefully you know how that works? Right?!?!? But if not: fill the bowl with some oil, dip the brush in the oil, brush the brush over the ingredients, and repeat until everything has a light coat).

Now flick a bit of salt or Herbamare over them (the ingredients, you know, the ones on the baking paper on the baking tray).

Put it (gently) in your preheated oven at 200 degrees Celsius for about 30 minutes. Don't forget to set a timer.

After 30 minutes, when your oven goes BEEP BEEP, or whatever your timer does, put on your oven gloves, or one of those fancy thermal suits you see people wearing near volcanoes, or just grab a tea towel and fold it double, or burn your hands (not recommended). Take the food out of the oven (yes yes, the whole shebang, tray and all, just dump the lot onto your worktop) and spoon it onto a plate.

Or spoon it onto multiple plates, or eat it straight off the scorching hot tray. Whatever floats your boat. I'd grab a plate.

Voila! Bon appétit!

Co-writing with AI, without the slop

2026-05-13T00:00:00.000Z

I use AI to help write this blog. Shocking, I know. It's 2026. My fridge probably uses AI to schedule its own defrost cycle, the toaster has a personality, and at this point if a blog post wasn't at least partly drafted by a language model, that's the unusual case.

# How I do it

I usually write an excerpt or the rough idea myself, drop it into a prompt with markers like (Claude note: expand on this with X or Y), run /tagore over the result, and then go back through it myself because tagore doesn't catch everything and I have opinions about how a sentence should land. I check every post myself, Vince the human ;-), before it ships.

That's it. That's the whole workflow.

# Is that shocking? Does it kill the human element?

I don't think so.

The part I write first is the load-bearing piece: the hot take, the structure, the specific examples, what I want to say. The model expands it, fills in transitions, suggests phrasing I wouldn't have reached for, and then I edit the parts that landed wrong. The opinions are mine. The choice to publish is mine.

"Proofreader" undersells it. Proofreading is comma placement and dangling modifiers, and Claude does a lot more than that. It offers ways to phrase a paragraph that I'd never have written but, once I read it, I recognise as the thing I was trying to say. "Ghostwriter" overshoots. Ghostwriters write the whole thing while the named author signs off. Neither fits.

Co-writer is the word. Funny timing: Anthropic recently launched Claude Cowork, which is roughly the same framing: Claude as someone you collaborate with on the actual work, not as an oracle you query. Different product, same idea. Stop pretending the AI is a vending machine and start treating it like the smart colleague who's read everything and types fast.

# The hot take

The "AI vs human writing" frame is the wrong one in 2026. The interesting question is whether anyone thought about the writing before publishing. Whether a human typed it or a model drafted it matters much less.

A model can produce a thousand competent-but-soulless posts a day. A human can also produce a thousand competent-but-soulless posts a day. Look at any content marketing pipeline from 2018. Neither is interesting.

What I notice when I read good writing now is that the author had a point of view, picked the specific examples that matter, and trusted the reader. None of that depends on whether a human or a model wrote the first draft. Pure-human writing with no point of view is just as boring as pure-AI writing with no point of view. The collaboration model, where the human supplies opinion and judgment and the model supplies fluency, produces better stuff than either does alone, provided you do the judgment part instead of mass-accepting the suggestions.

So no, AI didn't take the human out of writing. It took the typing out. Which, honestly, was always the boring part.

# The practical upside

This setup lets me publish faster, and from places where I'd never normally bother to draft. A post like this one can start as a phone-typed lump of thoughts on the train, get expanded against my usual workflow, run through tagore, and end up reviewable by the time I'm home. That used to be a half-day's work at a laptop. Now it's an evening with the laptop just for the edit pass.

The blog you're reading exists because the friction of writing a post dropped enough that I do it at all. That, on its own, would be enough to justify the workflow. Everything else is upside.

My take on using AI for coding. The same thinking, applied to code instead of prose.

# References

/tagore on GitHub

My take on using AI for coding

2026-05-07T00:00:00.000Z

# What I actually use

Mostly Claude. Claude Code in the terminal, Claude in the browser for one-off thinking. I've tried Cursor and GitHub Copilot too, and Codex is competitive on a lot of tasks. Honestly the gap between the top tools is small compared to the gap between "good prompt with guardrails" and "vibe-coded one-shot". The model matters less than I expected. The harness around it matters more.

# The bottleneck moved

When I wrote everything by hand, the slow step was typing and remembering syntax. Now the slow step is reviewing what the model produced and making sure it actually does what I asked, on the inputs I care about, without quietly breaking something else.

So the work shifted:

Less time writing boilerplate, glue code, first-pass implementations.
More time reading diffs, writing tests for the diffs, and asking "wait, why did it touch that file?"

This isn't a complaint. Reading and reviewing is higher-leverage than typing. But anyone who claims AI coding is "10x faster" without mentioning that the review burden went up too is selling something.

# Prompt steering and guardrails do most of the work

The biggest jump in output quality I've seen comes from constraining the model up front:

A CLAUDE.md (or equivalent) at the repo root that spells out conventions, commands, and the shape of the codebase. Claude Code reads it on every session.
Permissions, hooks, and explicit allow-lists so the agent can't run arbitrary destructive commands without asking.
Sub-agents and skills for repeatable workflows. The post you're reading was created by a private skill of mine that enforces "branch from origin/main, run /tagore, open a PR, never merge". It's not really a tool, just a workflow I trust wrapped in something Claude can invoke.

Without those rails you end up with a very smart intern who occasionally rm -rfs something they shouldn't. With them you get a very smart intern who actually checks before doing anything load-bearing.

# "Hey Claude, design a full-blown fullstack knowledge base. Make no mistakes."

That kind of prompt almost never produces what you actually want. It produces something, usually a plausible-looking scaffold, but:

The model picks defaults that don't match your stack, your hosting, or your constraints.
Trade-offs you'd have argued about (auth model, data store, deploy target) get resolved silently.
Six iterations later you've got a folder full of code you didn't choose, and when something breaks you have no map of what depends on what.

I've watched this play out on side projects and on bigger work too. The further you let the AI run without you actually understanding the architecture, the more painful the eventual debugging session. Because at some point there will be a debugging session, and the only person who can drive it is someone who understands how the pieces fit. If that's not you, you're stuck.

So the takeaway isn't "don't use AI for new projects". It's that understanding the architecture of your application matters more, not less, when AI writes most of the code. You don't need to type every line, but you do need to be able to redraw the box-and-arrow diagram from memory.

# What works better: specs and RALPH

The pattern I keep coming back to is spec-driven development plus a tight loop.

Spec-driven means: before the model writes code, write down (or have it write down, then edit) what the thing should do, what it should not do, what the inputs and outputs are, and where the edges are. Save that spec next to the code. Then prompt against the spec, not against vibes.

The loop part is what Geoffrey Huntley calls RALPH, short for Read, Analyse, Loop, Plan, Hone. The short version: don't ask for the whole feature in one shot. Ask the model to read the spec, look at the current state, plan the next small change, make it, then loop. Each pass is small enough to review honestly. Each pass updates the spec and the code together.

claude-mem bakes a similar workflow in directly. /make-plan produces a phased spec, /do executes it pass by pass with subagents, and observations from each session feed the next one. One caveat: /make-plan and /do are barely documented. You kind of have to read the skill source to understand what they actually do. But once you do, they work brilliantly in my experience. There are alternatives, get-shit-done being one of the more visible ones, but most of them feel bloated to me. claude-mem stays small and gets out of the way, which is what I want.

# What I'd tell someone starting today

Pick one tool (Claude Code, Cursor, whichever) and learn its harness deeply. Switching constantly is a tax.
Always have a CLAUDE.md (or equivalent) at the repo root. Update it when conventions change.
Write the spec first. Even three bullet points beats nothing.
Loop in small increments. Review every diff. Don't merge what you can't explain.
When the model surprises you, good or bad, figure out why before continuing.

The tools are good. They're not magic, and they don't replace the work of knowing what you're building. The people I see getting the most out of them treat the AI as a fast collaborator that needs a clear spec and tight feedback, not as an oracle.

# References

Fixing Chromium virtual backgrounds on NVIDIA + Wayland

2026-05-04T00:00:00.000Z

Switched on background blur in a Meet call and turned into a flat white rectangle. Camera works fine without the effect. The moment any background filter (blur or virtual background) is applied, everyone on the call (me in the self-preview included) sees a solid white frame where my video should be. Reproduces in any Chromium-based browser (Chromium, Vivaldi). Firefox is fine. Setup that hits this: NVIDIA proprietary driver (tested on 595.71.05, open kernel module branch, RTX 4090), KDE Plasma 6 on Wayland (Bazzite), Flatpak Chromium 147.

# Why it breaks

Meet's virtual background pipeline runs per frame:

camera frame
  → MediaPipe TFLite WebGL segmentation
  → WebGL composite shader (frame + background, masked)
  → canvas.captureStream() → MediaStream
  → WebRTC encoder

The captureStream() hop has to share the WebGL output texture cross-process to the GPU process where the encoder runs. Chromium does this through its SharedImage abstraction, which on Linux maps to EGLImage / dmabuf. On NVIDIA's Wayland EGL implementation, the shared image arrives at the encoder side either uninitialised or wrongly synchronised, so reads come back as all-1s. Solid white frames.

The shader runs and the composite is correct. The readback path is the broken thing.

Firefox doesn't hit this because it doesn't use ANGLE or Chromium's SharedImage. Its captureStream goes through a different path (often a CPU readback) that never exercises the broken NVIDIA EGL interop.

# Fix

Two flags work. Pick one based on monitor setup.

# Option 1: `--ozone-platform=x11` (preferred on a desktop with same-scale monitors)

Runs Chromium under XWayland. GPU compositing stays on, WebGL/canvas/video decode stay full-speed, PipeWire screen sharing still works (it's independent of Ozone). Cost:

XWayland is integer-scale only. No fractional HiDPI, no proper per-monitor scaling.
Drag-and-drop and clipboard with native Wayland apps can be slightly flaky.

Fine on a desktop with one or two monitors at the same scale. Annoying if you mix a 4K-at-200% panel with a 1080p-at-100% one.

# Option 2: `--disable-gpu-compositing` (preferred on laptops or mixed-scale monitors)

Wayland-native integration kept. Compositor runs on CPU. WebGL and canvas individual draws still hit the GPU; only the final composite is software. Cost:

Continuous extra CPU usage.
Less smooth scrolling on heavy pages.
Worse battery on laptops.

Genuinely unnoticeable on a 4090 desktop. Can matter on a laptop.

# How to apply (Flatpak Chromium)

Don't edit the system .desktop file. Flatpak rewrites it on every update. Copy it to ~/.local/share/applications/ instead and edit the local copy. KDE picks up the local override automatically:

cp /var/lib/flatpak/exports/share/applications/org.chromium.Chromium.desktop \
   ~/.local/share/applications/

Add the chosen flag to all three Exec= lines (main, "New Window" action, "New Incognito Window" action). For Option 1 the main line becomes:

Exec=/usr/bin/flatpak run --branch=stable --arch=x86_64 --command=/app/bin/chromium --file-forwarding org.chromium.Chromium --ozone-platform=x11 @@u %U @@

Quit Chromium fully and relaunch. Verify in chrome://gpu: "Ozone platform" should now read x11, or under Option 2 "Compositing" should read software-only.

For Vivaldi the equivalent lives in ~/.config/vivaldi-stable.conf. Same flags, see Persistent CLI flags for Vivaldi on Linux for the conf-file syntax.

# Things I tried that didn't work

For future-me, so I don't bisect them again. None of these fix it:

--disable-features=WebRtcVideoCaptureGpuMemoryBuffer. Disables zero-copy GPU buffers for camera capture. The camera path is fine, the bug doesn't live here.
--disable-features=WebRtcVideoCaptureGpuMemoryBuffer,VaapiVideoDecoder. Adds VA-API decode disable on top. Same outcome.
--use-angle=gl. Forces ANGLE off Vulkan onto plain GL. The ANGLE backend isn't the broken thing.
--disable-features=WebRTCPipeWireCamera. Falls back to V4L2 capture. Doesn't matter; camera path is fine.
--disable-features=Vulkan. Kills Vulkan everywhere. The shared-image bug doesn't go through Vulkan in this configuration.
--disable-accelerated-2d-canvas. Forces 2D canvas to CPU. MediaPipe outputs from a WebGL canvas, so this is the wrong canvas.

Only the two flags above cross the broken path entirely (Ozone on X11 sidesteps the NVIDIA Wayland EGL path; --disable-gpu-compositing forces a CPU readback that doesn't need shared images at all).

# The real fix lives upstream

This is a Chromium ↔ NVIDIA Wayland EGL interop bug. Almost certainly already tracked in issues.chromium.org. Worth searching with terms like chromium wayland nvidia canvas captureStream white or MediaPipe NVIDIA Wayland virtual background before filing anything new.

Could also end up being a Flathub packaging fix. The Chromium flatpak already pre-applies --enable-features=WebRTCPipeWireCapturer for exactly this kind of platform-specific compatibility patch, so a future build could ship one of these flags by default for NVIDIA users.

Persistent CLI flags for Vivaldi on Linux. Same flags, applied via Vivaldi's conf-file mechanism.
Bazzite: an immutable gaming-first Fedora variant. Why the browser is a Flatpak in the first place.
Making 1Password browser extensions talk to the Flatpak desktop app. Another Flatpak browser quirk worth knowing about.

# References

Making CoolerControl's GUI start on login

2026-05-03T00:00:00.000Z

CoolerControl is two binaries: a system daemon (coolercontrold) and a Qt GUI client (coolercontrol). The daemon does the actual work (pump curves, fan curves, temperature monitoring), and the rpm enables it as a systemd service, so cooling stays correct at boot whether you log in or not. The GUI is just a viewer for the daemon's API plus the configuration UI.

When you reboot and there's no tray icon, your fans are still being controlled. You're missing a UI, not a fan curve. But you'll still want it back.

Notes below are written for KDE Plasma (the default Bazzite spin) on Wayland. GNOME-specific deltas are called out where they matter.

# Why it doesn't autostart

The Fedora rpm (coolercontrol-4.2.0-1.fc44.x86_64 at the time of writing) installs:

/usr/lib/systemd/system/coolercontrold.service, the daemon, enabled by default.
/usr/share/applications/org.coolercontrol.CoolerControl.desktop, a launcher entry for the apps menu.

What's missing: no /etc/xdg/autostart/coolercontrol.desktop, and the package doesn't drop anything into ~/.config/autostart/ on first run either. The entry under applications/ puts CoolerControl in your apps menu. XDG autostart loaders don't look there.

Different from Making KopiaUI start on login when installed as a Flatpak, where an in-app toggle exists but silently writes into a sandboxed config dir. Here there's no toggle that writes a .desktop file at all; the package just doesn't ship autostart.

# Fix (Plasma, click path)

If you'd rather not edit dotfiles: System Settings → Autostart → Add → Add Application → CoolerControl → OK. Plasma writes a .desktop under ~/.config/autostart/ for you and applies it on the next session start.

# Fix (any DE, file path)

Drop a minimal autostart entry on the host:

# ~/.config/autostart/coolercontrol.desktop
[Desktop Entry]
Type=Application
Name=CoolerControl
Comment=Monitor and control your cooling device
Exec=coolercontrol
Icon=org.coolercontrol.CoolerControl
Terminal=false
StartupNotify=false
X-GNOME-Autostart-enabled=true

Plasma needs nothing more than a valid XDG .desktop file in ~/.config/autostart/. Its session manager honours the freedesktop spec directly. The X-GNOME-Autostart-enabled=true line is a GNOME-specific extension; Plasma ignores it, but leaving it in keeps the file portable if you ever switch DE or copy it to another machine.

Verify after a reboot:

pgrep -af coolercontrol

You should see two processes: coolercontrold under the system slice (the daemon) and coolercontrol under your user session (the GUI).

# Get it to start in the tray

By default the GUI opens its main window on launch, which is annoying as an autostart. There's no --start-in-tray CLI flag despite forum threads claiming there is. coolercontrol --help lists -h, -v, -d, --full-debug, --disable-gpu, --chromium-flags, --clear-cache. That's it.

Tray-on-launch is a setting inside the app: Settings → Start in Tray. Enable it once with the GUI open, then future autostarts come up minimised to the system tray.

Plasma's tray shows the CoolerControl icon out of the box (StatusNotifierItem support is native). GNOME needs the AppIndicator and KStatusNotifierItem Support extension. Without it, the GUI is running but invisible: no main window, no tray icon, just a process you can only see in pgrep.

# When it still doesn't work

Daemon isn't running. systemctl status coolercontrold.service. If it's disabled, sudo systemctl enable --now coolercontrold.service. The GUI will sit at "Connecting to daemon" forever without it.
GUI launches but pegs at "Connecting to daemon" with the daemon up. The daemon listens on 127.0.0.1:11987 over HTTPS with a self-signed cert. If you've tightened the local firewall or replaced the cert, that's where to start.
Wayland session, GUI window flashes on login then closes. Check journalctl --user -b | grep -i coolercontrol. Usually a Qt platform plugin or GPU acceleration issue. Add --disable-gpu to the Exec= line as a workaround.
Plasma's System Settings → Autostart lists the entry but it doesn't run. Check perms on the desktop file. It must be readable by your user. chmod 644 ~/.config/autostart/coolercontrol.desktop. Same applies to GNOME's Tweaks → Startup Applications.

# Why not just the system desktop file

You might be tempted to copy /usr/share/applications/org.coolercontrol.CoolerControl.desktop into /etc/xdg/autostart/. Don't, on Bazzite or any other rpm-ostree atomic system: /etc is layered, but /usr is read-only and gets rebuilt on every rebase. A user-level autostart entry under ~/.config/autostart/ survives both system updates and rebases, and doesn't need root.

Making KopiaUI start on login when installed as a Flatpak. Same family of "Linux desktop autostart is annoying" problem, different root cause: Flatpak sandbox vs missing package autostart entry.
Bazzite: an immutable gaming-first Fedora variant. Why this matters more on immutable Fedora: /usr/share/applications/ is read-only, so you can't fix this by editing the system desktop file.
Making 1Password browser extensions talk to the Flatpak desktop app. Another sandbox/permissions wrinkle in the same family of desktop-Linux papercuts.

# References

Making KopiaUI start on login when installed as a Flatpak

2026-04-28T00:00:00.000Z

KopiaUI installed as a Flatpak (io.kopia.KopiaUI) has a "Launch at startup" toggle in Settings → Preferences. Under Flatpak, ticking it does nothing useful. The app reports success, but no autostart entry lands on the host and Kopia just doesn't come back after reboot.

Sandbox problem, not a Kopia bug.

Notes below assume KDE Plasma on Wayland (default Bazzite spin). The fix file itself is DE-agnostic; GNOME-specific deltas are called out where they matter.

# Why it breaks

The toggle writes to $XDG_CONFIG_HOME/autostart/kopia-ui.desktop. Under Flatpak, $XDG_CONFIG_HOME is rewritten to the per-app sandbox directory (~/.var/app/io.kopia.KopiaUI/config/), and the sandbox doesn't get --filesystem=xdg-config/autostart:create by default. The file is "written" inside the sandbox where the session autostart loader never looks.

The flatpak-exported launcher at /var/lib/flatpak/exports/share/applications/io.kopia.KopiaUI.desktop is also a bad copy-paste source. Its Exec= line is built for URL-handler launches:

Exec=/usr/bin/flatpak run --branch=stable --arch=x86_64 --command=kopia-ui --file-forwarding io.kopia.KopiaUI @@u %U @@

The --file-forwarding ... @@u %U @@ block expects URL arguments. With no URLs at autostart, what actually happens depends on the session manager. Anything from a stray "Open File" prompt to silently failing to background.

This is also why the click-path through Plasma's System Settings → Autostart → Add Application doesn't save you: it copies the exported .desktop into your autostart dir verbatim, broken Exec and all. Same trap on GNOME's Tweaks → Startup Applications. You need the hand-rolled file below.

# Fix

Drop a minimal autostart entry on the host:

# ~/.config/autostart/kopia-ui.desktop
[Desktop Entry]
Type=Application
Version=1.0
Name=KopiaUI
Comment=Fast and secure open source backup
Exec=flatpak run io.kopia.KopiaUI
StartupNotify=false
Terminal=false
X-GNOME-Autostart-enabled=true

The file is plain XDG autostart-spec, so Plasma's session manager picks it up directly from ~/.config/autostart/ and runs it on login. The X-GNOME-Autostart-enabled=true line is GNOME-specific extra metadata; Plasma ignores it, but leaving it in keeps the file portable if you also use a GNOME session somewhere.

Verify after a reboot:

pgrep -af 'kopia-ui|io.kopia.KopiaUI'

You should see a flatpak run wrapper and the actual kopia-ui process under it.

# When it still doesn't work

Plasma's System Settings → Autostart lists it but it doesn't run. Check ~/.config/autostart/kopia-ui.desktop perms. It must be readable by your user. chmod 644 it. Same applies to GNOME's Tweaks → Startup Applications.
Tray icon never appears on Plasma. Plasma has native StatusNotifierItem support, so this should just work. If it doesn't, make sure the system tray widget is on your panel and configured to show all icons, not just an allow-list.
Tray icon never appears on GNOME. GNOME has no native system tray. Install the AppIndicator and KStatusNotifierItem Support extension. Without it, KopiaUI runs but minimises to nothing.
Kopia repo not unlocked at autostart. By design. Kopia won't decrypt the repo without the password. Either configure the OS keyring integration in KopiaUI, or accept that you need to click through the unlock prompt once per session.

# Why not the in-app toggle

Even if a future Kopia release adds --filesystem=xdg-config/autostart:create to its Flatpak manifest, the in-app toggle still produces the messy Exec line from the exported launcher (it copies the system desktop entry verbatim). The Plasma and GNOME click-path autostart dialogs do the same thing. The hand-rolled file above is cleaner and survives Kopia upgrades because nothing on the package side touches ~/.config/autostart/.

Bazzite: an immutable gaming-first Fedora variant. Why Flatpak is the default install path on immutable Fedora.
Making CoolerControl's GUI start on login. Same family of "Linux desktop autostart is annoying" problem, different root cause: rpm package ships no autostart entry at all, instead of one written into a sandboxed path.
Making 1Password browser extensions talk to the Flatpak desktop app. Same shape of problem: Flatpak sandbox isolation breaking an in-app feature that assumes host-level filesystem access.
Running rsync from a systemd timer on Bazzite (SELinux rsync_t domain). If you're running Kopia alongside other backup automation.

# References

Running rsync from a systemd timer on Bazzite (SELinux rsync_t domain)

2026-04-28T00:00:00.000Z

Likely you will never do this. But the SELinux gotchas I hit along the way are worth writing down even if the original task isn't. So treat this less as a recipe and more as a tour of how SELinux actually behaves when something it didn't expect tries to read or write under /home, and how to figure out why it's blocking you instead of just flipping a boolean and moving on.

For context: I don't normally run SELinux. On a desktop, why would you? ;-) The benefit-to-friction ratio just isn't there for me on a single-user box. But Bazzite ships it enforcing by default, and I'd rather work with the policy than turn it off, so when this hit I leaned in.

The setup that triggered it: two user accounts on the same Bazzite install, call them username1 and username2. Username2 already had a working backup. Username1 wanted their savegames included in it. The obvious move would be to set up backups on username1 too, but I already had this thing running on username2, so instead I wrote a systemd timer that runs rsync as root from username1's home into a folder under username2, and let username2's existing backup pick it up from there. I like a challenge but also don't want to reinvent the wheel. While writing this post I'm already regretting it. But hey, here we are.

And SELinux had thoughts.

A systemd timer that runs rsync as root does not behave like rsync from a sudo shell, even though the UID is the same. Fedora's SELinux policy labels /usr/bin/rsync as rsync_exec_t and ships a type_transition that moves the process into the confined rsync_t domain whenever it's launched from a system context (init_t, initrc_t, etc). rsync_t is intentionally narrow. It's the domain for the rsync server, not for ad-hoc file copies. Reading or writing anything under /home or /var/home is denied by default.

A sudo shell stays in unconfined_t and skips the transition. That's why "but it works when I run it by hand" is the usual entry point to this rabbit hole.

Below: the Bazzite-specific traps I hit, plus how I cut a small local SELinux module for it instead of flipping the rsync_full_access boolean.

# Confirm the transition is happening

sudo ausearch -m AVC -ts recent | grep rsync_t

If you see scontext=system_u:system_r:rsync_t:s0 paired with denied operations against user_home_t or data_home_t, that's the transition. Outside SELinux, a quick check is cat /proc/<pid>/attr/current on the running rsync.

# Two ways to fix it

# A. The blunt boolean

sudo setsebool -P rsync_full_access on

Persistent across reboots. Lets rsync_t access most non-security files anywhere. Fine for a personal box, too wide for anything shared.

# B. A scoped local policy module

What you want when rsync only needs to touch a specific subtree.

Put just the rsync_t domain into permissive so a full sync runs end-to-end and logs every denial it would have hit:
```
sudo semanage permissive -a rsync_t
```
Trigger the unit, ideally with a stale file in the destination so --delete actually fires:
```
sudo touch /path/to/dest/STALE.tmp
sudo systemctl start your-rsync.service
```

Pull the AVCs and generate a module:

sudo ausearch -m AVC --start recent | audit2allow -M your_module
sudo semodule -i your_module.pp

Drop permissive and verify under enforcing:

sudo semanage permissive -d rsync_t
sudo systemctl start your-rsync.service

For my use case (rsync mirror with --delete and --chown, source under one user's home, destination under another), the rules I needed were:

allow rsync_t data_home_t:dir { getattr open read remove_name search setattr write add_name };
allow rsync_t data_home_t:file { getattr setattr unlink read open create write };
allow rsync_t gconf_home_t:dir search;
allow rsync_t user_home_dir_t:dir search;
allow rsync_t user_home_t:dir search;
allow rsync_t self:capability { dac_override chown fowner fsetid };

One thing that bit me: data_home_t:file setattr. audit2allow only suggests it once rsync has actually tried to update mtimes on an existing destination file, so the first permissive pass usually misses it and you find out the next time you run.

# Debugging traps that ate hours

# audit2allow only sees AVCs that already happened

If rsync exits on the first denial, you only get that first denial in the audit log. Flip rsync_t permissive, let the run finish end to end, then collect. Otherwise the module ships incomplete and every enforcing run after that hands you one more rule, one denial at a time.

# dontaudit rules silently hide denials

The default policy contains dontaudit rules that suppress AVCs the policy author considered noise. When a denial is real but invisible:

sudo semodule -DB   # disable all dontaudit, rebuild policy
# ... reproduce, debug ...
sudo semodule -B    # restore

# Bazzite's default audit rule suppresses a class of events

/etc/audit/rules.d/audit.rules ships with -a never,task, which can hide events you'd expect to see. If AVCs are still missing after disabling dontaudit:

sudo auditctl -D                  # clear runtime audit rules
# ... reproduce, ausearch, debug ...
sudo augenrules --load            # restore from rules.d

# Files inherit the label of whichever process created them

If your initial seed ran from a sudo shell (unconfined_t) and the later periodic runs come from the timer (rsync_t), the destination directory and the files inside can end up with different SELinux types. The dir-class denials in audit2allow won't match the file-class denials, which is confusing for about an hour. Fix with:

sudo chcon -R -t data_home_t /path/to/dest

# Authoring a `.te` file by hand

When you want to skip audit2allow and write the rules yourself:

sudo checkmodule -M -m -o your_module.mod your_module.te
sudo semodule_package -o your_module.pp -m your_module.mod
sudo semodule -i your_module.pp

sudo semodule -l | grep your_module confirms install. sudo semodule -r your_module removes it.

# Bazzite specifics worth flagging

The rsync_t transition is Fedora policy, nothing Bazzite-specific. Same workflow applies on Silverblue, Kinoite, Bluefin, plain Fedora, and RHEL.
/var/lib/selinux/targeted/active/modules isn't where modules live on rpm-ostree systems; storage sits elsewhere under the ostree deployment. Use semodule -l and semodule -E <name> to inspect rather than find.
Audit rules persist across rpm-ostree upgrades because /etc is a real directory, not part of the immutable image.

# Why bother with the module instead of the boolean

The boolean would have saved me hours. The module is safer: it lists exactly which types rsync_t is allowed to touch and nothing else. On a personal machine the boolean is probably fine. If you hit this on a server, now you know how to fix it. Although... if you really want to copy things between Username1 and Username2 on a server, I have other questions for you ;-)

# References

Escaping the AWS SSM AppArmor profile with systemd-run

2026-04-25T00:00:00.000Z

On Ubuntu via SSM Session Manager, your shell (and every child it spawns) runs under the snap.amazon-ssm-agent.amazon-ssm-agent AppArmor profile. uid 0 with CAP_DAC_OVERRIDE doesn't get out of it. Writes to paths like /var/log/postgresql/* return EACCES even with a clean lsattr, a writable fs, and the right caps.

# Confirm it's AppArmor

$ cat /proc/self/attr/current
snap.amazon-ssm-agent.amazon-ssm-agent (enforce)

dmesg will probably stay quiet. Snap profiles use audit deny for "expected" paths, which suppresses the kernel audit line. When entries do show up they can lag a couple of minutes.

# Escape via systemd-run

systemd runs as PID 1, outside any AppArmor profile. Anything it starts is unconfined. systemd-run --pipe --wait delegates a command to PID 1 and pipes the result back:

sudo systemd-run --pipe --wait <cmd> [args...]
sudo systemd-run --pipe --wait --uid=postgres bash -c 'truncate -s 0 /var/log/postgresql/postgresql-16-main.log'
sudo systemd-run --pipe --wait tee /etc/foo/bar.conf <<'EOF'
some content
EOF

--pipe forwards stdin/stdout/stderr.
--wait is synchronous and propagates the exit code.
--uid=<user> drops privilege. PID 1 can become any uid.

# Better alternatives

SSH with a real keypair. SSH sessions don't inherit the snap profile. Worth the setup if you touch the box more than occasionally.

# Why bother

SSM is the right tool for ad-hoc ops without exposing SSH, or when you've lost the original key. It's also audited, which is nice. Knowing about the AppArmor inheritance saves you the hour of wondering why root can't write to a directory it owns (like I did).

# References

Why your MCP server cannot see env vars from .bashrc

2026-04-25T00:00:00.000Z

You add an MCP server to Claude Code and it requires an environment variable. But the server doesn't show up when you run /mcp, no error surfaces, nothing useful in the logs. Nine times out of ten: an env var it needs is set in ~/.bashrc, and nothing Claude Code launches will ever see it.

# The mechanic

Claude Code spawns each MCP server as a plain child process. No interactive shell, no .bashrc sourcing. .bashrc is for interactive shells only. Non-interactive children inherit the parent's already-resolved environment, not the file.

So this:

# ~/.bashrc
export MY_API_KEY=sk-xxxxxxxx

is invisible to MCP servers, hooks, and skill scripts. The server starts, can't read the var, exits silently. Claude Code only sees "didn't initialise."

# Where to put env vars instead

In rough order of preference:

systemd environment.d (Linux, systemd-based distros). Drop ~/.config/environment.d/mcp.conf:
```
MY_API_KEY=sk-xxxxxxxx
ANTHROPIC_LOG=debug
```
These are part of the user session, loaded by systemd --user, inherited by every desktop, IDE, terminal, and Claude Code process spawned from that session. Log out / log in to apply, or systemctl --user daemon-reload and relog.
The MCP server's own env config. In ~/.claude/settings.json or project .mcp.json:
```
{
  "mcpServers": {
    "myserver": {
      "command": "/path/to/server",
      "env": { "MY_API_KEY": "sk-xxxxxxxx" }
    }
  }
}
```
Explicit and per-server. Downside: secrets end up in a config file. Only safe if it isn't synced or committed.
~/.profile or ~/.zprofile. Login shells source these, and most display managers do start the user session via a login shell. Cleaner than .bashrc but more fragile across distros.
launchctl setenv on macOS. Persists only inside the current launchd session unless you wire a LaunchAgent plist.

# Confirming the failure mode

When an MCP server is missing from /mcp and you suspect env vars are the cause:

Run the binary from a non-interactive shell to reproduce:
```
bash -c '/path/to/mcp-server'
```
An interactive shell sources .bashrc. bash -c doesn't. If it fails here, it'll fail when Claude Code spawns it.
Add a startup log line that prints os.environ.get("MY_API_KEY", "(missing)"). Fastest way to confirm the var isn't reaching the child.

# Child processes not seeing what you'd expect is a recurring failure mode

Escaping the AWS SSM AppArmor profile with systemd-run. SSM child shells inherit an AppArmor profile silently.
Cron with no $PATH because cron's environment is a stripped-down version of root's login env.
Docker build steps not seeing $DOCKER_BUILDKIT because the daemon, not your shell, holds it. (See Living without docker: podman as a daily driver)

In every case, don't assume your shell's environment is what the child process actually sees. Set the var where the child picks it up.

# References

Pagefind: full-text search for static sites, no backend

2026-04-25T00:00:00.000Z

Pagefind is a search library for static sites. It indexes the built HTML once at build time and serves the index as static files. Queries run in the visitor's browser against a small WASM binary - no search backend, no API key, no third-party JS.

This site uses it for the /blog/ index.

# How it works

Build step. After your site generator writes HTML, you run pagefind --site _site. Pagefind crawls the output, looks for data-pagefind-body (or just falls back to <main>/<article>), tokenises the text, and writes:
- pagefind/pagefind.js - the loader.
- pagefind/pagefind-ui.js + pagefind-ui.css - the optional default UI (a search input + result list).
- pagefind/wasm.*.pagefind - the WASM binary that does the actual querying.
- pagefind/index/*.pagefind - the index, chunked by term prefix (typically a few hundred bytes to a few KB per chunk).
- pagefind/fragment/*.pagefind - per-page metadata (title, URL, excerpt source).
Page load. The browser loads pagefind-ui.js lazily. Nothing else fetches yet.
First keystroke. Pagefind loads the WASM (~70KB gzip), then fetches only the index chunks matching the prefix the user typed. For a query like podm, it pulls the pod chunk, not the whole index.
Result render. Matched fragment files are fetched to build excerpts. Each result is one or two extra ~500-byte requests.

The total network cost for a typical search is well under 200KB even on a multi-thousand-page site, because nothing is loaded until the user actually searches and only the relevant chunks come down.

# Why it beats a backend search service

For a static site or a personal KB, Pagefind cuts out a bunch of operational headaches:

No server. Nothing to provision, monitor, rate-limit, patch, or pay for. It's bytes on a CDN. CF Pages / GitHub Pages / S3 / Netlify all serve it the same way they serve the rest of your site.
No third-party. Algolia/Typesense/Elastic-as-a-service all add a domain to your CSP, a tracking surface, an SLA you depend on, and a key that can leak. Pagefind queries never leave the page - relevant if you write about anything you'd rather not hand to a vendor's logs.
Private by design. No analytics. No "what did this user search for" telemetry to leak. There's no place for it to go, since the search runs entirely in the page.
Builds in the same pipeline. It's one extra command after your site generator. No separate index-rebuild job, no webhook, no eventual-consistency window between "I published a page" and "it's searchable." When the site deploys, the index deploys.
Trivial to roll back. A bad index ships with a bad deploy and reverts with a git revert + redeploy. With a hosted index, rollback means re-indexing.
Cheap. Free. MIT-licensed. The hosting cost is whatever your static host charges (often $0).

# Where a backend still wins

Tens of thousands of pages. Pagefind chunks the index but the fragment count grows linearly. Past ~10k pages, the build step gets slow and the cold-start WASM + chunk fetches start to feel sluggish on mobile data. Backend search keeps a constant client cost.
Per-user authorisation. If results depend on who's logged in (private docs, multi-tenant SaaS), the index can't be public, and shipping a per-user index isn't realistic. You need a server enforcing access at query time.
Frequent index updates without a deploy. If content changes outside the build (user-generated, CMS-driven, real-time), you need an index that updates independently. Pagefind only updates when you rebuild.
Fancy features. Synonyms, typo-tolerance with a learned language model, query analytics, A/B-tested ranking, federated search across heterogeneous sources - all things Algolia / Typesense / Meilisearch do well and Pagefind doesn't try to.

# Integration notes (Eleventy specifically)

Three things to remember:

Pagefind has no watch mode. eleventy --serve keeps the build in memory and never invokes Pagefind. For dev, npm run dev shows you the empty #search div with no UI; it's not broken. To actually exercise search, build to disk and serve the directory: npm run build && npm run serve.
Indexing scope. By default Pagefind indexes everything inside <body>. Wrap your real content in <main data-pagefind-body> (or <article data-pagefind-body>) to exclude nav/footer chrome from search results. Worth doing - otherwise every result excerpt starts with "home blog Dark mode ☾".
UI customisation through CSS variables. The default PagefindUI widget exposes --pagefind-ui-primary, --pagefind-ui-background, --pagefind-ui-border, etc. You set them on :root and the widget picks them up. The override block in css/style.css:326 is all this site does to theme it.

Why your MCP server cannot see env vars from .bashrc

# References

Living without docker: podman as a daily driver

2026-04-25T00:00:00.000Z

Podman ships on most modern Linux desktops, Bazzite included. The CLI is intentionally docker-compatible (most subcommands and flags work identically), but two things differ under the hood:

No daemon. Podman invokes containers directly via runc/crun. There's no long-running root service.
Rootless by default. Each user has their own container store under ~/.local/share/containers/. Containers run mapped to your UID via user namespaces.

Both are a security win. They also remove the "is the daemon running?" and "is my user in the docker group?" failure modes.

# Common docker commands as podman commands

docker pull alpine          →   podman pull alpine
docker run -it alpine sh    →   podman run -it alpine sh
docker build -t foo .       →   podman build -t foo .
docker compose up           →   podman compose up        # via podman-compose
docker ps                   →   podman ps
docker exec -it <id> sh     →   podman exec -it <id> sh
docker logs -f <id>         →   podman logs -f <id>
docker network ls           →   podman network ls
docker volume create x      →   podman volume create x

If your fingers keep typing docker, install podman-docker. It symlinks /usr/bin/docker to /usr/bin/podman so old scripts keep working. Bazzite ships it by default.

# Where the abstraction leaks

docker compose v2 vs podman-compose. Parity is close but not perfect. The compose plugin shipped with Podman 5.x handles most multi-container apps. If you hit a wall, Quadlet units are closer to how production actually runs anyway.
Docker socket. Tools that hardcode /var/run/docker.sock need a podman socket. Run systemctl --user enable --now podman.socket, then point them at DOCKER_HOST=unix://$XDG_RUNTIME_DIR/podman/podman.sock.
NVIDIA passthrough. The container toolkit supports both runtimes. The podman path needs --security-opt=label=disable on SELinux distros.
Buildkit features. docker build --secret, --ssh, --mount=type=cache all have podman equivalents. Flag names differ slightly. Check podman build --help.
macOS / Windows. Podman runs a Linux VM under the hood (podman machine). Resource limits and bind mounts work, but host.docker.internal becomes host.containers.internal.

# Why it matters on immutable distros

On Bazzite and other rpm-ostree systems, you avoid layering RPMs into the base image (see rpm-ostree: rebase, pin, rollback). Containers are how you install traditional CLI tooling. distrobox and toolbx both wrap Podman to give you a transparent shell into a container with your home directory mounted in. That's where gcc, kubectl, terraform, etc. should live.

# References

Podman documentation

Bazzite: an immutable gaming-first Fedora variant

2026-04-25T00:00:00.000Z

Bazzite is a community-built Linux distribution derived from Fedora's atomic desktop family (Silverblue, Kinoite) with a heavy focus on gaming, handhelds (Steam Deck, ROG Ally), and home-theatre boxes. Ships with the Steam stack, Mesa drivers, Proton-tuned kernels, and gamescope preconfigured.

# Mental model

Two things change relative to a traditional Fedora install:

The base system is image-based and read-only. Updates are atomic. You boot into a new commit or roll back to the previous one. There's no dnf install of arbitrary RPMs into the running system. The OS image is built upstream and you rebase between images.
User software lives in containers and Flatpaks. Flatpak for graphical apps, distrobox and toolbx for traditional CLI tooling, Homebrew for one-shot CLI packages.

That split is why Bazzite is hard to brick (you can break the user side without touching boot).

# Day-to-day

Update. rpm-ostree upgrade, or ujust update on Bazzite (which wraps the same machinery and also refreshes Flatpaks). Reboot to apply. See rpm-ostree: rebase, pin, rollback for rebase, pin, and rollback.
Install a GUI app. Prefer Flatpak: flatpak install flathub <app>. Desktop integration is fine for almost everything. Notable exception is browser → 1Password. See Making 1Password browser extensions talk to the Flatpak desktop app for some notes on that.
Install a CLI tool. Spin up a toolbox or distrobox container running Fedora or Arch, install the tool inside, export the binary. Containers are throwaway. Destroy and recreate when you want a clean state.
Container runtime. Bazzite ships Podman, not Docker. See also Living without docker: podman as a daily driver.

# When troubleshooting

"Where does this thing live?" is harder on Bazzite than on stock Fedora. A given binary is in one of four places:

Image layer. Read-only at /usr. Changes only via rpm-ostree.
Layered RPM. Added via rpm-ostree install. Listed by rpm-ostree status -v.
Flatpak. Sandboxed under /var/lib/flatpak.
Container. Inside distrobox / toolbox. Invisible to the host package manager.

Knowing which layer a misbehaving binary lives in tells you which tool fixes it. A 1Password browser plugin failing to talk to the desktop app is almost always a Flatpak permission / host-bridge problem, not a system one.

# Privacy footnote

Everything in this note is public Bazzite behaviour, nothing specific to my install. For the authoritative reference, man rpm-ostree and the Bazzite docs.

Making 1Password browser extensions talk to the Flatpak desktop app

2026-04-25T00:00:00.000Z

If you install the 1Password desktop app as a Flatpak (the recommended path on Bazzite and other immutable distros), and your browser is also a Flatpak, "Connect to 1Password" hangs. The unlock screen sits forever, or the extension claims the desktop app isn't running even though it clearly is.

Sandboxing problem, not a 1Password bug.

# Why it breaks

The desktop app and the extension talk via native messaging. The browser launches a small helper binary (com.1password.1password.json on Linux) that opens a Unix socket inside the desktop app's runtime directory. Normal install: both sides share /run/user/<uid>/, they find each other.

Under Flatpak, each app runs in its own sandbox. The browser sandbox can't see 1Password's /run/user/<uid>/ by default. Even if it could, the NativeMessagingHosts manifest path the browser scans (~/.config/<browser>/NativeMessagingHosts/) is rewritten by the sandbox to a Flatpak-private location.

Net result: browser never sees the manifest, never spawns the helper, never finds the socket.

# Fix

1Password ships a cross-sandbox bridge. Set it up once:

# Make the manifest visible to Flatpak browsers
mkdir -p ~/.var/app/<browser-app-id>/config/<browser>/NativeMessagingHosts
flatpak run --command=/app/bin/1password-cli com.1password.1Password --setup-browser

Typical setup (Vivaldi or Chromium as Flatpak, 1Password as Flatpak):

# Allow the 1Password app to talk to host browsers
flatpak override --user --talk-name=com.1password.1Password com.vivaldi.Vivaldi
flatpak override --user --talk-name=com.1password.1Password org.chromium.Chromium

Then enable Browser Integration inside the desktop app: Settings → Developer → Allow connection from browser extensions. The integration check inside the extension's settings should now flip to green.

# When it still doesn't work

Wayland-only browsers. A few extensions misbehave under pure Wayland. --ozone-platform-hint=auto in the browser launch flags often fixes it. For Vivaldi specifically, Persistent CLI flags for Vivaldi on Linux is where the flag belongs.
App ID mismatch. 1Password 8 uses com.1password.1Password. The 7.x snap manifest used com.onepassword.OnePassword. Mixing the two silently fails. Check flatpak list | grep -i password.
com.1password.1Password.Policy missing. Happens if you grabbed the app from a third-party Flathub mirror without the Policy extension. Reinstall from the official Flathub remote.
PIN/biometrics on the wrong account. Only one signed-in account at a time can serve native messaging. Switch primary account in Settings → Accounts.

Bazzite: an immutable gaming-first Fedora variant. Why Flatpak is the default install path on immutable Fedora.
rpm-ostree: rebase, pin, rollback. If reinstalling 1Password meant a base image change.

# References

rpm-ostree: rebase, pin, rollback

2026-04-25T00:00:00.000Z

rpm-ostree manages the OS image on Fedora's atomic desktops (Silverblue, Kinoite, Bazzite). A handful of verbs cover 90% of what you need.

# The shape

You always have two deployments at minimum: the one you're running and the one you'll roll back to. Each rpm-ostree operation stages a new deployment. Nothing changes until you reboot.

$ rpm-ostree status -v
State: idle
Deployments:
* ostree-image-signed:docker://ghcr.io/ublue-os/bazzite:stable
                   Digest: sha256:…
                  Version: 41.20260420.0   (current)
  ostree-image-signed:docker://ghcr.io/ublue-os/bazzite:stable
                   Digest: sha256:…
                  Version: 41.20260413.0   (rollback target)

* marks "currently booted". Reboot into the older deployment from GRUB to roll back.

# Verbs

rpm-ostree upgrade. Fetch the latest ref of the same image. Reboot to apply.
rpm-ostree rollback. Make the previous deployment the default for next boot.
rpm-ostree rebase ostree-image-signed:docker://ghcr.io/<org>/<image>:<tag>. Switch to a different OS image. How you go between Bazzite GNOME and Bazzite KDE, between :stable and :testing, or to a uBlue variant.
rpm-ostree deploy <version>. Pin to a specific image version. Subsequent upgrade calls won't move past it until you deploy --reset.
rpm-ostree reset. Drop all layered packages and overrides. Useful when an upgrade is wedged because of a layering conflict.

# Pin a known-good deployment

Pin the current deployment so a future rollback can reach it:

sudo ostree admin pin 0

Pinned deployments aren't garbage-collected when newer ones land. List with ostree admin status. Unpin via ostree admin pin --unpin <index>.

# Layering escape hatches

You can install RPMs into the image with rpm-ostree install <pkg>. They become layers on top of the base. Keep this list short:

Every layer has to be re-applied on each rebase, slowing rebase and upgrade.
A package that conflicts with the new base wedges the upgrade until you rpm-ostree override remove or rpm-ostree reset.
Layered drivers and kernel modules are particularly fragile across major version jumps.

# When a boot fails

GRUB shows the previous deployment as a separate entry. Reboot, pick one. The next rpm-ostree status will show the broken one as "Deployment 1". rpm-ostree rollback makes it the default; rpm-ostree cleanup -p drops it once you've recovered.

Bazzite: an immutable gaming-first Fedora variant. Context for why this is even a thing.
Making 1Password browser extensions talk to the Flatpak desktop app. Flatpak troubleshooting for sandbox-aware apps.

# References

Persistent CLI flags for Vivaldi on Linux

2026-04-25T00:00:00.000Z

Vivaldi's launcher script (/opt/vivaldi/vivaldi, with /usr/bin/vivaldi-stable symlinked to it) reads extra CLI flags from a config file in ~/.config/ on every launch. That's the right place for --disable-gpu-compositing, --enable-features=..., --ozone-platform-hint=auto, and other flags you want Vivaldi to use.

# Where to write it

Config filename comes from the channel:

Stable: ~/.config/vivaldi-stable.conf
Snapshot: ~/.config/vivaldi-snapshot.conf

One flag per line. (# is a comment). Example:

# ~/.config/vivaldi-stable.conf
--disable-gpu-compositing
--ozone-platform-hint=auto

Quit and relaunch Vivaldi for changes to take effect. Closing the last window doesn't quit Vivaldi if you have a tray icon enabled.

# Confirm the flags are active

Open vivaldi://version and check the Command Line field. Every flag you set should be visible there alongside the defaults. Missing flag usually means a typo or a syntax issue (forgetting the leading -- is a common one).

# Why not the .desktop file

It's tempting to edit /usr/share/applications/vivaldi-stable.desktop and append to Exec=. Don't:

Package manager rewrites that file on every Vivaldi update. Your changes drop silently.
Only affects launches from the desktop application menu, not the CLI or other launchers.
The launcher reads the conf file in addition to Exec=, so you'd still need the conf file for command-line launches.

If you genuinely need a per-application override (different flags for a launcher icon vs. a CLI alias), copy the .desktop file to ~/.local/share/applications/ first and edit the copy.

# When something breaks

GPU glitches on Wayland. --disable-gpu-compositing usually fixes things, but expect higher CPU load since the CPU now handles compositing. --ozone-platform-hint=auto can also help.
vivaldi://flags overrides. Those persist in the user profile, separate from CLI flags. If a flag from ~/.config/vivaldi-stable.conf doesn't seem to take effect, check vivaldi://flags for a conflicting override.
Vivaldi as Flatpak. Conf file path is sandboxed to ~/.var/app/com.vivaldi.Vivaldi/config/vivaldi-stable.conf. Same syntax. Useful when Vivaldi is installed via Flatpak (e.g. on Bazzite).

Bazzite: an immutable gaming-first Fedora variant. Flatpak browsers on immutable Fedora.
Making 1Password browser extensions talk to the Flatpak desktop app. When the password manager extension can't talk to the desktop app.

# References

Vivaldi help: command-line switches
Chromium command-line switches list. Vivaldi accepts all of these.

daal.cloud - blog

My favourite anime

# Elfen Lied

# Hellsing Ultimate

# Panty & Stocking with Garterbelt

# So why anime?

Recipe: Easy Tray Bake

# Ingredients

# Time

# Tools

# Instructions

Co-writing with AI, without the slop

# How I do it

# Is that shocking? Does it kill the human element?

# The hot take

# The practical upside

# Related

# References

My take on using AI for coding

# What I actually use

# The bottleneck moved

# Prompt steering and guardrails do most of the work

# "Hey Claude, design a full-blown fullstack knowledge base. Make no mistakes."

# What works better: specs and RALPH

# What I'd tell someone starting today

# References

Fixing Chromium virtual backgrounds on NVIDIA + Wayland

# Why it breaks

# Fix

# Option 1: --ozone-platform=x11 (preferred on a desktop with same-scale monitors)

# Option 2: --disable-gpu-compositing (preferred on laptops or mixed-scale monitors)

# How to apply (Flatpak Chromium)

# Things I tried that didn't work

# The real fix lives upstream

# Related

# References

Making CoolerControl's GUI start on login

# Why it doesn't autostart

# Fix (Plasma, click path)

# Fix (any DE, file path)

# Get it to start in the tray

# When it still doesn't work

# Why not just the system desktop file

# Related

# References

Making KopiaUI start on login when installed as a Flatpak

# Why it breaks

# Fix

# When it still doesn't work

# Why not the in-app toggle

# Related

# References

Running rsync from a systemd timer on Bazzite (SELinux rsync_t domain)

# Confirm the transition is happening

# Two ways to fix it

# A. The blunt boolean

# B. A scoped local policy module

# Debugging traps that ate hours

# audit2allow only sees AVCs that already happened

# dontaudit rules silently hide denials

# Bazzite's default audit rule suppresses a class of events

# Files inherit the label of whichever process created them

# Authoring a .te file by hand

# Bazzite specifics worth flagging

# Why bother with the module instead of the boolean

# Related

# References

Escaping the AWS SSM AppArmor profile with systemd-run

# Confirm it's AppArmor

# Escape via systemd-run

# Better alternatives

# Why bother

# Related

# References

Why your MCP server cannot see env vars from .bashrc

# The mechanic

# Where to put env vars instead

# Confirming the failure mode

# Child processes not seeing what you'd expect is a recurring failure mode

# References

# Option 1: `--ozone-platform=x11` (preferred on a desktop with same-scale monitors)

# Option 2: `--disable-gpu-compositing` (preferred on laptops or mixed-scale monitors)

# Authoring a `.te` file by hand