daal.cloud - articles

AirPods 5 vs AirPods Pro 3: sealed or open?

2026-10-11T00:00:00.000Z

airpods5.exe

AirPods 5$129$149 with wireless case

Open fit, no tips
59% less noise (lab)
5.1 h per charge (lab)

pro3.exe

AirPods Pro 3$249often discounted

In-ear seal, 5 tip sizes
90% less noise (lab)
8.7 h per charge (lab)

Apple finally put noise cancelling in its cheapest earbuds, which makes this a harder call than it used to be. In SoundGuys' lab, Pro 3 cut about 90% of the perceived noise around you against 59% for AirPods 5. They also run longer per charge and carry health features AirPods 5 don't have. None of that matters if you can't stand silicone tips in your ears, and plenty of people can't. No spec sheet will tell you which camp you're in, so start there.

Get AirPods 5 if

ear tips make you want to rip them out
your noise is office hum, not jet engines
buds go in and out of the case all day
$100 is $100

Get Pro 3 if

you fly or commute somewhere loud every week
you want hearing-health or heart-rate features
you listen for hours without a break
you run or train in them

Every number on this page is tagged: lab measured by an independent lab, estimate worked out here (method in the data section), apple Apple's own rating.

# How much noise gets through

AirPods 5 cancel noise in software. Pro 3 do the same job harder and add a physical seal on top. Start with what the labs measured.

lab59%less perceived noise, AirPods 5, ANC on. SoundGuys.

lab90%less perceived noise, Pro 3, ANC on. SoundGuys.

lab−28.7 dBoverall noise isolation, Pro 3, ANC on. RTINGS.

Put another way: of the noise that would normally reach you, about 41% still gets through AirPods 5 and about 10% gets through Pro 3. Apple's marketing says "up to 3x more ANC". The lab gap is closer to 4x, though CNN found it smaller in day-to-day use.

isolation-by-band.csv

Noise reduction with ANC on, in dB. Longer bar = quieter.

Bass engine rumble, traffic

AirPods 5−6 dBestimate

Pro 3−23.8 dBrtings

Mids voices, keyboards

AirPods 5−16 dBestimate

Pro 3−32.4 dBrtings

Treble AC whine, dish clatter

AirPods 5−18 dBestimate

Pro 3−30.5 dBrtings

Overall

AirPods 5≈ −12.9 dBfrom lab %

Pro 3−28.7 dBrtings

Scale 0 to 35 dB. RTINGS has measured AirPods 5 too, but those values sit behind its paid membership, so the AirPods 5 bands are estimated from what the labs have published. See how.

Now feel it. Pick a place, flip between the two, then switch ANC off to see what the seal does on its own. The meter shows how much of the perceived loudness still reaches your ear.

noise-room.exe

Noise around youWhat reaches your ear

Gets through

estimate

Noise cancelling on

Every value the noise room uses

Share of perceived loudness that reaches your ear. All four columns are estimates built from the band values above; the ANC-off columns are the roughest. Method in the data section.

Place (bass / mid / treble mix)	AirPods 5, ANC on	Pro 3, ANC on	AirPods 5, ANC off	Pro 3, ANC off
Office hum (30 / 40 / 30)	42%	14%	90%	54%
Train & traffic (60 / 30 / 10)	52%	16%	96%	70%
Plane cabin (50 / 35 / 15)	49%	15%	94%	65%
Cafe voices (10 / 70 / 20)	35%	12%	90%	49%

The pattern is consistent across both labs: AirPods 5 are decent in the mids and treble and weak in the low bass. That's why reviewers still heard engine drone on long-haul flights, and why a train's rumble survives. Pro 3 are strong everywhere, and strongest exactly where AirPods 5 are weakest. Pro 3 users wear theirs as earplugs.

One honest caveat on voices. Lab tests use steady noise, and on that AirPods 5 handle mid-range chatter well; RTINGS calls it "handily blocked out". Real conversations come and go, which is harder for any ANC to track, so expect a busy cafe to sound a bit worse than the table says.

# Comfort comes down to your ears

There's no objectively comfier pair. One rests in your outer ear, the other plugs the canal. Most people know within a minute which camp they're in.

# AirPods 5

Open fit, one size, no tips.

Good

No plugged-up feeling or pressure from a seal. Easy to wear for hours.
You still hear traffic on a run or a walk.
Light: 4.3 g per bud, and a pocket-friendly case.

Not so good

One shape. It fits your ears or it doesn't, and there's nothing to adjust. SoundGuys found their noise results swing with how the bud sits.
Less secure for sprints or fast head movement.
Some reviewers feel a faint pressure from the ANC at first.

# AirPods Pro 3

In-ear, foam-infused tips in five sizes (XXS to L).

Good

Tip sizes let you tune the fit, very small ears included.
Locked in for workouts and running.
The seal blocks noise even with ANC off.

Not so good

The plugged, sealed feeling never sits right with some people.
Some owners get sore on long sessions. Dropping a tip size often fixes it.
RTINGS notes worn tips may block less treble over time.

50.1 mmAirPods 5 case, long side. 34.7 g.

62.2 mmPro 3 case, long side, with lanyard loop.

# What AirPods 5 give up

Tap a row for why it matters. The $129 model loses a few extra things, so pick which one you're weighing.

A sealed fit and much stronger ANC

The biggest gap. In SoundGuys' lab, AirPods 5 cut 59% of perceived noise and Pro 3 cut 90%. The difference lives in the bass: on a long-haul flight a reviewer still heard engine drone through AirPods 5. Pro 3 can double as earplugs. AirPods 5 can't.

Hearing health features

Hearing Test, the clinical-grade Hearing Aid mode, Hearing Protection, Conversation Boost and Loud Sound Reduction are Pro-only. If your hearing is slipping, this alone justifies Pro 3.

Heart-rate sensing in workouts

Pro 3 track heart rate on their own, no Apple Watch needed. AirPods 5 have no heart-rate sensor.

Battery life per charge

Lab-measured with ANC on: 8 h 42 min for Pro 3 (SoundGuys) against 5.1 h for AirPods 5 with the wireless case (RTINGS). That's the difference between a whole transatlantic leg and a mid-flight top-up.

Sound detail and Spatial Audio depth

Reviewers found AirPods 5 muddier in the lower mids, with flatter voices on podcasts and a shallower Spatial Audio stage. RTINGS measured their bass and treble about 5 dB under its target, against +1 dB bass and −3 dB treble for Pro 3. They also play quieter, so you turn them up and leak more sound.

Precision Finding for the case

The Pro 3 case has an Ultra Wideband chip that points you to it with arrows on a compatible iPhone.

MagSafe charging and a lanyard loop

Minor, but only the Pro 3 case snaps onto MagSafe and takes a strap.

Volume swipe on the stem$129 model only

The $149 model swipes for volume. The $129 model doesn't, so you reach for your phone or Siri instead.

Wireless charging$129 model only

The $129 case is USB-C only. The $149 case also takes Qi and Apple Watch chargers.

Find My speaker in the case$129 model only

Without it, a case lost under the sofa stays silent.

Every AirPods 5 keeps

Adaptive Audio
Transparency
Conversation Awareness
Live Translation
Hands-free Siri
Head gestures
Personalized Spatial Audio
IP57 dust & water
iOS 27 custom EQ

# Battery

Apple's ratings next to what the labs got, all with noise cancelling on. Faded bars are Apple's numbers, solid bars are lab runs.

Listening on one charge

AirPods 5 apple4 h

AirPods 5 labnot lab-tested yet?

AirPods 5 wireless apple5 h

AirPods 5 wireless rtings5.1 h

Pro 3 apple8 h

Pro 3 soundguys8.7 h

Pro 3 rtings~9 h

Total with the case

AirPods 5 apple20 h

AirPods 5 wireless apple22 h

AirPods 5 wireless rtings22.5 h

Pro 3 apple24 h

Apple's ratings hold up: the labs got the same or slightly more. Nobody has published a lab run for the $129 model yet. Hands-on, T3 had 12% left after about four and a half hours with ANC on, and CNN's pair gave out between four and five hours into a flight.

If your buds go back in the case between calls, AirPods 5 battery is a non-issue. If you listen nonstop, Pro 3 last about 70% longer per session than the wireless-case AirPods 5 in lab runs (8.7 h against 5.1 h).

# Side by side

	AirPods 5	AirPods 5 wireless	Pro 3
Price (US)	$129	$149	$249
Fit	Open, no tips	Open, no tips	In-ear, 5 tip sizes
Noise cut, lab (SoundGuys)	59%	59%	90%
Noise isolation, lab (RTINGS)	Members only	Members only	−28.7 dB
Battery, Apple (bud / total)	4 h / 20 h	5 h / 22 h	8 h / 24 h
Battery, lab	Not tested yet	5.1 h / 22.5 h	8.7 h
Stem controls	Press	Press + volume swipe	Touch + volume swipe
Case charging	USB-C	USB-C, Qi, Watch	+ MagSafe
Find My speaker	No	Yes	Yes + Precision Finding
Hearing health	No	No	Yes
Heart-rate sensor	No	No	Yes
Dust & water	IP57	IP57	IP57
Released	Sep 2026	Sep 2026	Sep 2025

Both AirPods 5 models use the same buds, so one noise result covers both. Eurozone list price for the base AirPods 5 is €149. Retailers discount Pro 3 regularly, which can shrink the gap a lot.

# Which one is yours?

Flip on whatever applies to you.

I fly or commute somewhere loud every week Silicone ear tips bother me I want hearing-health or heart-rate features I listen 5+ hours without a break Saving $100 matters more than the best ANC

verdict.txt

Pick what fits

Short version: if tips bother you or the $100 matters, AirPods 5 with the wireless case. Loud commutes, health features or long sessions point to Pro 3.

# Looking ahead

# Pro 3 won't go stale soon

Pro 2 lasted three years before Pro 3 replaced it. That's a pattern, not a promise, but buying Pro 3 a year in isn't buying at the end of its run.

# Software is closing the gap, hardware isn't

Live Translation, the new Siri, head gestures and iOS 27's custom EQ land on both. What keeps Pro ahead is physical: the seal, the sensors and the bigger battery. The bass gap in the band chart is a seal problem, and no update fixes that.

# Watch the price, not the calendar

Black Friday is a few weeks out. Pro 3 discounts can cut the $100 gap meaningfully, so if you lean Pro, wait for a deal.

# Where the numbers come from

Three kinds of number appear on this page, and each one is tagged. Here's where every one of them comes from, so you can check them or throw them out.

# Measured by a lab

Number	Product	Lab	How it was measured
59% less perceived noise, ANC on	AirPods 5	SoundGuys	Test head (B&K 5128) recorded with ANC on, ANC off and no earbuds, then averaged as a cut in perceived loudness. SoundGuys warns open-fit results vary with how the bud sits.
90% less perceived noise, ANC on	Pro 3	SoundGuys	Same method.
−28.7 dB overall; bass −23.8, mid −32.4, treble −30.5 dB	Pro 3	RTINGS	RTINGS' noise isolation test, ANC on. Taken from RTINGS' public comparison tables; RTINGS now shows these values to paying members only.
Bass and treble about −5 dB vs target	AirPods 5	RTINGS	Frequency response against RTINGS' target curve. Pro 3: +1 dB bass, −3 dB treble.
5.1 h continuous, 22.5 h total, ANC on	AirPods 5 wireless	RTINGS	Continuous playback until the buds die, then recharged from the case.
8 h 42 min, ANC on	Pro 3	SoundGuys	Music peaking at 75 dB SPL until the first bud stops (method).
About 9 h, ANC on	Pro 3	RTINGS	Continuous playback, ANC on.
About 20 dB in the mids and treble	AirPods 4 with ANC	SoundGuys	Not on the chart; used as a reference point for the estimates below.

# Estimated here

AirPods 5 per band: bass −6, mid −16, treble −18 dB. No public per-band measurement exists yet. The shape comes from what both labs say about them: SoundGuys found they work best between about 1 and 9 kHz and struggle below 500 Hz, and RTINGS writes that they "struggle to block out sounds like engine rumble" while whine and chatter are "handily blocked out". AirPods 4 with ANC measured about 20 dB in the mids and treble, which sets a sensible ceiling for an open-fit design. I then checked the three values against the lab: they average out to a 57% cut in perceived loudness, next to SoundGuys' measured 59%.

AirPods 5 overall: about −12.9 dB. Converted straight from SoundGuys' 59% with the rule below.

ANC off: AirPods 5 0 / −1 / −4 dB, Pro 3 −2 / −10 / −20 dB (bass / mid / treble). These are the shakiest numbers on the page. Neither lab publishes ANC-off results for these models. An open shell doesn't seal, so AirPods 5 block next to nothing on their own. The Pro 3 figures are typical passive isolation for silicone-tipped earbuds: little bass, a fair bit of treble.

Per-place results. Each place in the noise room is a mix of bass, mids and treble: office hum 30/40/30, train and traffic 60/30/10, plane cabin 50/35/15, cafe voices 10/70/20. Those mixes are my judgement of where each noise sits, not measurements.

# The maths

Rule of thumb from psychoacoustics: every 10 dB of reduction roughly halves how loud something sounds. So the share of loudness that gets through is 2^(−dB / 10). For each place:

gets_through = Σ mix[band] × 2^(−reduction[band] / 10)

Pro 3, train, ANC on:
  0.60 × 2^(−23.8/10) + 0.30 × 2^(−32.4/10) + 0.10 × 2^(−30.5/10)
= 0.60 × 0.192 + 0.30 × 0.106 + 0.10 × 0.121
= 0.16  →  16% gets through

Sanity check: run RTINGS' three Pro 3 bands through the same formula with equal weights and you get an 86% cut. SoundGuys measured 90% on a different rig. Two labs, two methods, one story. The noise room's moving wave is decoration; the meter and the percentages come from this formula.

# Sources

Lab data:

Specs, prices and hands-on:

Prices are US list unless noted. Lab figures checked October 11, 2026.

Co-writing with AI, without the slop

2026-05-13T00:00:00.000Z

I use AI to help write the articles on this site. 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 an article 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 article 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. An article 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.

These articles exist because the friction of writing one 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 article 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 article 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 /articles/ 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 articles 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 Pagefind override block at the bottom of css/style.css 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 - articles

AirPods 5 vs AirPods Pro 3: sealed or open?

# How much noise gets through

# Comfort comes down to your ears

# AirPods 5

# AirPods Pro 3

# What AirPods 5 give up

# Battery

# Side by side

# Which one is yours?

# Looking ahead

# Pro 3 won't go stale soon

# Software is closing the gap, hardware isn't

# Watch the price, not the calendar

# Where the numbers come from

# Measured by a lab

# Estimated here

# The maths

# Sources

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

# 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