dpc - dev

I don't want your PRs anymore

2026-04-06T00:00:00+00:00

I really appreciate that you're enjoying the software I'm maintaining and want to help. But we need to rethink this collaboration, because I feel like we're increasingly wasting each other's time.

Why I don't want to merge your PR

`nixos-hardware</code></a> early on. All the devices I cared about worked well.`
`I loved (and still do) the ease of being able to open, inspect, dedust, replace parts, etc. E.g. I added an NVMe radiator because I had a spare one around, and it fits, so why not?`
`I had to replace the input cover though, as I was affected by` `keys intermittently not working</a>. Replacement was super easy, the part was about $100. But it was quite an annoying problem to debug until the FW Team published their findings.`
`The second complaint would be the BIOS update situation for 12th Gen Intel, which turned out to be hopeless</a>. I personally didn't care much, but between 3rd party BIOS vendors and other complications, the BIOS update story went quite wrong for this model.`
`The last complaint would be the wobbly lid hinge. It was annoying sometimes: at steep angles the lid would not hold position and when unstable or moved it would wobble a little.`
`The battery life was mid. It did improve due to some firmware fixes, etc. but it was never good. I'm not much of a traveler, and mostly need the battery to move the laptop from the dock to the dinner table or a couch, so I was aware of that before buying and didn't care.`
`I was very happy about the hardware battery charge limit. Except when traveling, I kept it set to 60%, and didn't notice any battery degradation over the years, despite having it plugged in 99% of the time.`
`I love the physical toggles for microphone and camera. That feature alone always made FW13 feel like a laptop for people like me — the kind who join morning calls in their underwear. Just kidding (or am I?). People who care about cybersecurity, privacy, etc.`

The new#</a>
</h3>
It might sound weird, but I really appreciate that the new laptop... is in the form factor exactly the same as the old one. Maybe I'm too much on the spectrum, heh. No need to adjust to a new key layout, everything feels familiar, the microphone and camera physical switches are still there. No negative surprises.</p>
The new higher DPI screen is soo nice. Immediately noticeable improvement.</p>
The hinge is fixed. Now it is very high-force, maybe even a bit too much.
Does opening the lid count as exercise?</p>
The specs are a significant improvement, at least for my needs (compiling Rust code).</p>
The desktop UI feels even smoother than before, especially with an external
monitor attached. Overall, probably a combination of the improved built-in
screen at 120Hz (60Hz on the old one) and better specs.</p>
The old laptop under load ran quite hot and spun the CPU fan like
a lawn mower. So far, the new one handles the load much more gracefully: cooler and quieter.</p>
Looks to me like the fwupdmgr dealt well with firmware updates
right away, so hopefully the BIOS story will be better this time.</p>
I'm not sure about the battery yet. Again - I don't really use it much,
and I capped it at 60% right away too. I don't expect miracles.
There is plenty of info online with proper measurements.</p>
Summary#</a>
</h3>
As you could see, I was somewhat of an early Framework adopter,
and fine with some bumps along the way. I need a laptop that is
a bit like a desktop: good power, open, repairable, and I don't
care much about battery capacity.</p>
I'm happy to see that everything that was not ideal
in the previous version is now fixed, and the whole
laptop is just a more polished and capable version
of what I already liked.</p>
Benchmarks#</a>
</h3>
The main project I'm working on has a compilation benchmark</a>, so I'm going to use it for real-life performance.
It's a relatively large and heavy Rust codebase.</p>
ren - my desktop#</a>
</h5>
dpc@ren</span></span>
-------</span></span>
OS: NixOS 26.05 (Yarara) x86_64</span></span>
Kernel: Linux 6.19.9</span></span>
CPU: AMD Ryzen 9 7950X3D (32) @ 4.04 GHz</span></span>
Memory: 26.22 GiB / 62.01 GiB (42%)</span></span>
Swap: 5.26 GiB / 31.00 GiB (17%)</span></span>
Disk (/): 11.47 MiB / 31.00 GiB (0%) - tmpfs</span></span>
Disk (/bin): 2.61 TiB / 6.84 TiB (38%) - bcachefs [Read-only]</span></span>
</span>
</span>
Date: 2026-03-30</span></span>
Commit: 08fb6c1b613</span></span>
                       total    user     sys</span></span>
Full  check   debug:   62.21  986.43  145.05</span></span>
Incr  check   debug:    4.38   10.46    8.01</span></span>
Full  build   debug:  111.77 2129.55  213.69</span></span>
Incr  build   debug:   13.69   38.91   27.34</span></span>
Full  check release:   54.47  566.00  132.61</span></span>
Incr  check release:   15.77   39.94    7.89</span></span>
Full  build release:  448.37 12471.30  674.43</span></span>
Incr  build release:  371.44 10790.08  399.68</span></span></code></pre>tlb - new Framework 13#</a>
</h5>
dpc@tlb</span></span>
-------</span></span>
OS: NixOS 26.05 (Yarara) x86_64</span></span>
Kernel: Linux 6.19.9</span></span>
CPU: AMD Ryzen AI 9 HX 370 (24) @ 1.95 GHz</span></span>
Memory: 14.24 GiB / 93.59 GiB (15%)</span></span>
Swap: 0 B / 46.80 GiB (0%)</span></span>
Disk (/): 10.86 MiB / 46.80 GiB (0%) - tmpfs</span></span>
Disk (/bin): 91.67 GiB / 6.69 TiB (1%) - bcachefs [Read-only]</span></span>
</span>
</span>
Date: 2026-03-30</span></span>
Commit: 08fb6c1b613</span></span>
                       total    user     sys</span></span>
Full  check   debug:  162.62 2473.10  164.12</span></span>
Incr  check   debug:    7.66   21.89    8.53</span></span>
Full  build   debug:  317.64 5398.69  252.56</span></span>
Incr  build   debug:   19.44   69.70   21.61</span></span>
Full  check release:  129.30 1324.88  144.16</span></span>
Incr  check release:   37.23   95.91    9.08</span></span>
Full  build release: 1488.11 31536.63  726.96</span></span>
Incr  build release: HANG? cargo bug?</span></span></code></pre>mutex - old Framework 13#</a>
</h5>
dpc@mutex</span></span>
---------</span></span>
OS: NixOS 26.05 (Yarara) x86_64</span></span>
Kernel: Linux 6.19.9</span></span>
CPU: 12th Gen Intel(R) Core(TM) i7-1280P (20) @ 3.60 GHz</span></span>
Memory: 3.76 GiB / 62.51 GiB (6%)</span></span>
Swap: 0 B / 40.05 GiB (0%)</span></span>
Disk (/): 11.96 MiB / 31.26 GiB (0%) - tmpfs</span></span>
Disk (/bin): 755.77 GiB / 906.66 GiB (83%) - ext4 [Read-only]</span></span>
</span>
Date: 2026-03-31</span></span>
Commit: 5272f1734c4</span></span>
                       total    user     sys</span></span>
Full  check   debug:  226.67 2951.83  196.04</span></span>
Incr  check   debug:    8.78   25.72   10.34</span></span>
Full  build   debug:  433.46 6511.59  309.13</span></span>
Incr  build   debug:   28.67   81.74   27.63</span></span>
Full  check release:  157.38 1606.74  183.38</span></span>
Incr  check release:   42.21  107.07   12.39</span></span>
Full  build release: 2062.62 38336.06  860.68</span></span>
Incr  build release: HANG?</span></span></code></pre>



BubbleWrap your dev env and agents
2026-03-25T00:00:00+00:00
OK, so the world is collapsing, everything is getting hacked,
all dependencies are probably stealing keys and mining crypto,
slop is everywhere, and I'm part of the problem.</p>
So what do I do? I'm going to isolate!</a></p>
I had this in mind for a long while, but only recently
LLM agents became good enough that I actually find it
really useful to let them go without babysitting every
command they are trying to run.</p>
So the goals are:</p>

protect my systems from the slopus,</li>
protect my systems from malicious dependencies (at least somewhat),</li>
retain the usual UX.</li>
</ul>
Because of the last point, I am not going to be doing
separate user account, or a separate VM, or play with dockers.</p>
What I'm going to do is to use the BubbleWrap</a>,
to remount only parts of host system and home directory, and most
of them in read-only mode. This way my tooling
and general DX remains almost exactly the same,
but if the Slopus has an episode of psychosis,
or pulls in a cryptomining malware, there is
only so much damage that it can do.</p>
So the core of this system is the isolate</code> script:</p>
#!/usr/bin/env bash</span></span>
</span>
set</span> -euo</span> pipefail</span></span>
</span>
# Skip re-isolating if already inside an isolated environment</span></span>
if</span> [[</span> -n</span> "</span>${</span>ISOLATE_ENV</span>:-}</span>"</span> ]];</span> then</span></span>
	>&2</span> echo</span> "warning: already isolated"</span></span>
	exec</span> "</span>$</span>@"</span></span>
fi</span></span>
</span>
tiocsti_path</span>=</span>"/proc/sys/dev/tty/legacy_tiocsti"</span></span>
if</span> [</span> ! -f</span> "</span>$tiocsti_path</span>"</span> ]</span> ||</span> [</span> "$(</span>cat</span> "</span>$tiocsti_path</span>")"</span> !=</span> "0"</span> ];</span> then</span></span>
	>&2</span> echo</span> "warning: TIOCSTI not disabled"</span></span>
fi</span></span>
</span>
args</span>=</span>()</span></span>
</span>
args</span>+=</span>(</span></span>
	--dev-bind /dev /dev</span> \</span></span>
	--proc /proc</span> \</span></span>
	--tmpfs /tmp</span> \</span></span>
	--tmpfs /run</span> \</span></span>
 	--setenv PROMPT_ENV_INDICATOR "isolated"</span> \</span></span>
 	--setenv ISOLATE_ENV "$(</span>pwd</span>)"</span></span>
)</span></span>
</span>
for</span> p</span> in</span> \</span></span>
	/bin</span> \</span></span>
	/usr/bin</span> \</span></span>
	/etc</span> \</span></span>
	/nix</span> \</span></span>
	/run/current-system</span> \</span></span>
	"</span>$HOME</span>/bin"</span> \</span></span>
	"</span>$HOME</span>/.config"</span> \</span></span>
	"</span>$HOME</span>/nix/dot"</span> \</span></span>
	"</span>$HOME</span>/.gitconfig"</span> \</span></span>
	"</span>$HOME</span>/.nix-profile"</span> \</span></span>
	"</span>$HOME</span>/.local/share/direnv/allow/"</span> \</span></span>
	;</span> do</span></span>
	args</span>+=</span>(</span>--ro-bind "</span>$p</span>" "</span>$p</span>"</span>)</span></span>
done</span></span>
</span>
for</span> p</span> in</span> \</span></span>
	"</span>$HOME</span>/.cargo"</span> \</span></span>
	"</span>$HOME</span>/.claude"</span> \</span></span>
	"</span>$HOME</span>/.claude.json"</span> \</span></span>
	"</span>$HOME</span>/nix/dot/.claude"</span> \</span></span>
	"</span>$XDG_RUNTIME_DIR</span>/gnupg/S.gpg-agent"</span> \</span></span>
	"$(</span>pwd</span>)"</span>\</span></span>
	;</span> do</span></span>
	args</span>+=</span>(</span>--bind "</span>$p</span>" "</span>$p</span>"</span>)</span></span>
done</span></span>
</span>
if</span> [[</span> -n</span> "</span>${</span>NIRI_SOCKET</span>:-}</span>"</span> && -S</span> "</span>$NIRI_SOCKET</span>"</span> ]];</span> then</span></span>
	args</span>+=</span>(</span>--bind "</span>$NIRI_SOCKET</span>" "</span>$NIRI_SOCKET</span>"</span>)</span></span>
	args</span>+=</span>(</span>--setenv NIRI_SOCKET "</span>$NIRI_SOCKET</span>"</span>)</span></span>
fi</span></span>
</span>
args</span>+=</span>(</span></span>
 	--dir "</span>$HOME</span>/.gnupg"</span> \</span></span>
 	--chmod</span> 0700</span> "</span>$HOME</span>/.gnupg"</span> \</span></span>
)</span></span>
</span>
# Source extra config (e.g. set by auto-isolate) to allow</span></span>
# project-specific additions to args</span></span>
if</span> [[</span> -n</span> "</span>${</span>ISOLATE_EXTRA_CONFIG</span>:-}</span>"</span> && -f</span> "</span>$ISOLATE_EXTRA_CONFIG</span>"</span> ]];</span> then</span></span>
	source</span> "</span>$ISOLATE_EXTRA_CONFIG</span>"</span></span>
	# Hide the config file inside the sandbox by overlaying /dev/null</span></span>
	args</span>+=</span>(</span>--ro-bind /dev/null "</span>$ISOLATE_EXTRA_CONFIG</span>"</span>)</span></span>
fi</span></span>
</span>
exec</span> bwrap</span> \</span></span>
	"</span>${</span>args</span>[</span>@</span>]</span>}</span>"</span> \</span></span>
	"</span>$</span>@"</span></span></code></pre>
I'm not going to spend time explaining every detail here,
please read the Bubblewrap docs, or ask your local LLM.</p>
But if you, dear reader, are planning to do the same/similar thing,
you'll probably want to go over each path and consider
implications. E.g. I'm using a fancy Yubikey SSH/GPG setup</a>
and I need to touch the hardware yubikey every time I ssh
somewhere. Because of that I'm not afraid of mounting the ssh/gpg
socket into the isolated environment.</p>
Anyway, in a nutshell: isolate</code> will run a given command
in an environment where almost only the current working directory
is writable, and rest are only the bare minimum parts needed
to get things working, mostly in read-only mode. Kind-a, mostly.
The goal here is a good enough security and robustness without
sacrificing almost any DX.</p>
Thanks to using Nix, the first thing I'm going to use this isolate</code>
script to wrap Slopus. That guy should never get a full
access to anything important directly.</p>
Inside my system's flake.nix</code> in the main overlay I have something like this:</p>
            claude-code</span> =</span></span>
              let</span></span>
                orig</span> =</span> pkgs-unstable</span>.</span>claude-code</span>;</span></span>
              in</span></span>
              final</span>.</span>writeShellScriptBin</span> "claude" ''</span></span>
                exec env CARGO_TERM_QUIET=true PATH="</span>${</span>final</span>.</span>not-git</span>}</span>/bin:$PATH" </span>${</span>./dot/bin/isolate</span>} ${</span>orig</span>}</span>/bin/claude "$@"</span></span>
              ''</span>;</span></span></code></pre>
This makes Slopus always start in an isolated environment,
so I can't forget about it. I also replace git</code> with a wrapper
reminding Slopus that we're using Jujutsu, and make cargo build</code> less
noisy by default to (maybe) save some tokens.</p>
Then I want to automate entering isolated environment
in every project I'm working on.</p>
For that I have auto-isolate</code>:</p>
#!/usr/bin/env bash</span></span>
</span>
set</span> -euo</span> pipefail</span></span>
</span>
if</span> [[</span> ! -x</span> "</span>$HOME</span>/bin/isolate"</span> ]];</span> then</span></span>
	>&2</span> echo</span> "warning: </span>$HOME</span>/bin/isolate not found, skipping isolation"</span></span>
	exec</span> "</span>$</span>@"</span></span>
fi</span></span>
</span>
dir</span>=</span>"$(</span>pwd</span>)"</span></span>
while</span> true</span>;</span> do</span></span>
	if</span> [[</span> -f</span> "</span>$dir</span>/.isolate"</span> ]];</span> then</span></span>
		exec</span> env ISOLATE_EXTRA_CONFIG="</span>$dir</span>/.isolate"</span> $HOME</span>/bin/isolate "</span>$</span>@"</span></span>
	fi</span></span>
	if</span> [[</span> "</span>$dir</span>"</span> ==</span> "/"</span> ]];</span> then</span></span>
		break</span></span>
	fi</span></span>
	dir</span>=</span>"$(</span>dirname</span> "</span>$dir</span>")"</span></span>
done</span></span>
</span>
exec</span> "</span>$</span>@"</span></span></code></pre>
auto-isolate</code> will automatically call isolate</code> for a given
command if it can find .isolate</code> in current working dir
or any ancestor dir.</p>
One could wire it in a shell startup file, but since I have
a whole system for working in the CLI heavily rooted in tmux,
I am going to put it in ~/.config/tmux/tmux.conf</code> like this:</p>
set-option -g default-command "$HOME/bin/auto-isolate ${SHELL}"</span></span>
# in case I want to actually do something outside of the isolated env constrains</span></span>
bind E new-window "${SHELL}"</span></span></code></pre>
This way every time I'm starting a new pane in tmux,
it will trigger auto-isolate</code>. Now I touch ~/lab/.isolate</code> and
since all my dev projects are always inside ~/lab</code> I pretty much
can't ever forget to isolate</code> my projects.</p>
If you haven't noticed before, the isolate</code> script supports ISOLATE_EXTRA_CONFIG</code>
which allows adding project-specific modifications to the isolated
environment. E.g. for a little GUI project I'm working on, I had to
create following .isolate</code> file:</p>
if</span> [[</span> -n</span> "</span>$WAYLAND_DISPLAY</span>"</span> ]];</span> then</span></span>
    args</span>+=</span>(</span>--ro-bind "</span>$XDG_RUNTIME_DIR</span>/</span>$WAYLAND_DISPLAY</span>" "</span>$XDG_RUNTIME_DIR</span>/</span>$WAYLAND_DISPLAY</span>"</span>)</span></span>
fi</span></span>
</span>
args</span>+=</span>(</span></span>
	--bind /dev/dri/ /dev/dri/</span> \</span></span>
	--bind /dev/shm /dev/shm</span> \</span></span>
	--bind /tmp/.X11-unix/ /tmp/.X11-unix/</span> \</span></span>
	--bind /run/opengl-driver/lib/ /run/opengl-driver/lib/</span></span>
)</span></span></code></pre>
so it can show me the UI, when I run cargo r</code>.</p>


Personal AI usage disclosure
2026-02-04T00:00:00+00:00
Personal AI usage disclosure#</a>
</h1>
Since people have strong opinions about it and in an effort to keep things honest, let me write it once here so I can link to it from relevant README files and be done with it:</p>
✨ I use LLMs when working on my projects.</strong> ✨</p>
If you have problems with it you have been informed. Keep reading if you would like to know more details and some of my opinions on the matter.</p>
My history of using LLMs#</a>
</h3>
I've been relatively slow to start using LLMs, since they didn't have good integrations with CLI text editors (in particular Helix) and command line usage so they did not fit my workflow (I live in tmux, running fish shell and helix). Sometime in very late 2024 I discovered Aider</a> and that's when I started actually using LLMs for programming. Few months later I switched to Claude Code, and have been using it as a primary LLM ever since. There have been many significant improvements in how LLMs do as coding assistants during 2025, and somewhere in the second half of 2025 I was actually satisfied with their robustness and quality of what they produced.</p>
How I use them#</a>
</h3>
Just to get it out of the way: I do not vibe-code</strong>. By vibe-coding I mean largely unsupervised usage and not paying too much attention to the code AI produces. I believe vibe-coding can maybe work for very simple CRUD web apps and simple software, but at least at the moment LLMs are nowhere near producing really quality code without supervision. It seems definitely possible to build complex LLM-based agent loops and systems, that cross-check, verify, etc. to increase how far vibe-coding can be employed, but as things are right now I find it complex, wasteful and not very interesting.</p>
The way I use LLMs is largely treating it as a very sophisticated auto-completion and refactoring engine. I give it relatively small scope tasks, I like to point it at existing code with similar patterns and design, to ensure it produces exactly what I have in mind. Even with such a methodical usage it's quite common for the LLM to produce substandard code, overcomplicate or even break some adjacent stuff. It's been getting significantly better over time, but I fully recognize coding agents are a bit spooky in how unpredictable they can be. That's why I do review code the LLM produces and spend significant amount of time post-processing, refactoring and cleaning it.</p>
All in all, despite all the drawbacks and shortcomings of LLMs, they are still the most significant improvement for my productivity as a developer I've ever experienced. I build better, more ambitious things faster, and the quality is significantly improved. E.g. my projects now have way more tests - because it's faster to create and maintain them, and frankly - the flakiness of LLMs requires it. My code has more and better comments, examples and auxiliary stuff like that. Just the other day, I asked the LLM to scan a certain security-sensitive code for all attack vectors it can think of and write a unit test for each of them, and indeed AI found an important case that I missed. I screwed up, I wrote that code by hand. AI saved my bacon this time, repaying for all the dozen times when it did something really dumb that I had to tell it to correct.</p>
How exactly I use AI agents will evolve over time and I might not remember to update this document.</p>
Political concerns#</a>
</h3>
I know. The electricity and water usage, the ingestion of GPL-licensed code, the jobs that will be replaced, social repercussions, economic inequality. Yeah, yeah, I hear ya.</p>
I just don't think hiding your head in the sand and just refusing to use LLMs or even any code that was modified by an LLM is going to help anyone. The march of technological progress is kind of inevitable due to competitive pressures.</p>
Every technology brings important downsides and costs for all the benefits it makes. Such is the nature of civilizational progress. I guess the best we can do is to use political will and wisdom to increase the benefits, and mitigate the costs. And we will likely fail again to do so for a long time. But we did stop adding lead to car fuel eventually at least.</p>
From all the ways I could think of AI-like technology could have been developed, we got quite lucky. The LLM companies really have little moat, are a subject to heavy market competition from the get go, and even determined individuals can run their own LLMs locally. Much better than a hypothetical scenario where a single big-corp discovery gives it a patent and exclusive secret AI tech leading to impossible market advantage and universal monopoly over the whole economy.</p>
Software collaboration dynamic concerns#</a>
</h3>
So anyone can be a coder now, and produce terrible buggy code at the pace of 40 junior developers. And they are all very happy to open a PR to your project.</p>
And now that everyone is LLMing, how do you keep up and ensure the quality doesn't suffer, and people don't waste each other's time with slop.</p>
There are no easy answers here. We will manage, and we will see.</p>
I think the dynamics of SWE collaboration will drastically change. I predict teams will get smaller, and more projects will be developed by individuals leveraging their productivity. But only time will tell.</p>
And LLM-based solutions are desperately needed to help with vetting, reviewing, testing, ensuring code quality, etc. There's definitely a lot of potential and work to be done.</p>

dpc - dev

I don't want your PRs anymore

Reviewing my Framework 13 Laptops: the old vs new

BubbleWrap your dev env and agents

Personal AI usage disclosure