Extended Memory on Carl Myers

Lenovo ThinkPad P72 Setup, and the Sad State of Linux Laptops

Fri, 17 Jul 2026 00:00:00 +0000

A decade ago I wrote up setting up a System76 Oryx Pro. Time to play the laptop setup game again - except this time the interesting part isn’t the setup, it’s how little the setup has changed and how few good options there are to set up in the first place.

My daily driver is now a Lenovo ThinkPad P72 mobile workstation, hostname lasersword. The specs, for posterity:

CPU: Intel Xeon E-2176M, 6 cores / 12 threads (Coffee Lake, 2018-era)
RAM: 128GB, across four SO-DIMM slots
GPU: NVIDIA Quadro P4200 Mobile (Pascal, 8GB GDDR5)
OS: Debian 13 (Trixie), running btrfs-on-LUKS full disk encryption
A 17-inch chassis you could stop a door with, and the best non-Mac keyboard I have ever used

That is a seven-plus-year-old machine and I am still using it as my main computer in 2026, which should tell you something. Some of that is that it’s overbuilt - 128GB of RAM in a laptop is absurd and I love it - and some of it is that when I go shopping for a replacement, I keep failing to find one I actually want to buy.

The Dock Told My Mac to Unplug a Monitor That Was Still Plugged In

Thu, 16 Jul 2026 00:00:00 +0000

I have a CalDigit TS5 Plus. It is a nice dock, genuinely. It was one of the few I could find that does 10GbE and drives two monitors and delivers the full 140W to charge my laptop, all over a single cable. That single-plug convenience is the entire reason you buy a dock like this in the first place. It is also, right now, occasionally taking my whole OS session down with it. I want to be precise about that, because “dock problem” undersells it: this is not a monitor glitch you shrug off. It is the kind of failure where the machine freezes solid, you lose whatever you were in the middle of, and you reboot. If it catches you mid-demo or mid-screenshare, you also get to explain to a room full of people why your screen just turned into a still photograph of itself. Getting that taken seriously by CalDigit took more pushing than I think it should have, which is the other half of this post.

Ranked Skills

Sat, 10 Aug 2019 00:00:00 +0000

Technical resumes are challenging to produce, and challenging to accurately interpret. One of the biggest obvious challenges is that candidates are highly motivated to exaggerate, and interpreters of resumes are highly motivated to make a quick decision erring on the side of rejection so as to waste a minimal amount of their precious time. Another big challenge, however, one which I think might be solved, is the difficulty in communicating exactly what the resume author means by how skilled they are in a particular technology or specialty. Even if one were to assume candidates are 100% truthful and resume readers give 100% effort to read and parse every word of every resume that comes across their desks, what does “Expert at Python” or “5 years experience C++” really mean? Worse yet, someone says (or writes on their resume) “I am 8 / 10 at Ruby” - what does that mean? Eight what? Years? Projects? This person thinks they know 80% of everything there is to know about Ruby? Or are in the 80th percentile for Ruby programmers?

Integration Tests Across Repositories

Mon, 03 Oct 2016 00:00:00 +0000

Looking back from 2026. The monorepo-versus-multirepo fight I am dancing around here never got settled, it just got tooling. The industry split into two camps that each solved half of this post. If you go monorepo, a graph-aware build tool - Bazel, Meta’s Buck2, Pants - IS the “virtual repo” I describe below: one commit pins every version, and the tool rebuilds and retests only the affected slice of the graph (landscape). If you stay multirepo, the language dependency managers grew up: Go modules with Minimal Version Selection (default since Go 1.16, 2021), Cargo, npm workspaces, all lockfile-driven and reproducible. What still basically does not exist in the open is the specific thing this post is really about - a manifest that is the authority across repositories you do not necessarily own, with a real cross-repo merger. QBT’s answer to that (pins, cumulative versions, the custom merger) is still online at qbtbuildtool.com and in the TerabyteQbt org, and it still holds up technically. It just never got adoption, which is its own lesson.

Objective Morality and The Moral Landscape

Thu, 29 Sep 2016 00:00:00 +0000

Looking back from 2026. I’m keeping this essay as-is because it’s an honest record of how I argued this in 2016, and I still find the moral-solipsism parallel genuinely useful. But I’d be doing you a disservice to let it stand as if the argument went unchallenged, because it didn’t. Harris’ core move - that you can cross the is/ought gap by defining morality as the well-being of conscious creatures - has taken a decade of serious, and in my view partly successful, philosophical fire. The sharpest version: physicist Sean Carroll argued that “well-being” is doing all the smuggling here, that it’s a fuzzy concept that isn’t obviously the thing morality is about, and that you can’t get there by experiment even in principle (Carroll, 2011). Harris was confident enough to run the Moral Landscape Challenge in 2013-14, a $20,000 prize for anyone who could change his mind; the winning essay by Ryan Born pressed exactly this point - that “the well-being of conscious creatures” is not itself a scientific finding and has to be justified from outside science - and Harris conceded it was the best rebuttal without conceding the thesis (Clarifying the Landscape). Where I land now: I think the choice of well-being as the axis is a value choice, not a scientific one, and my 2016 essay leans on the solipsism analogy to wave that away a little too smoothly. Read the below as “the strongest form of the case I could make then,” not as a settled result. The axioms are load-bearing, and axioms are exactly where the fight is.

Public Service Announcement: Multi-Step Releases Considered Harmful

Tue, 03 May 2016 00:00:00 +0000

Looking back from 2026. The thesis holds up completely: a release you cannot reproduce locally in a single step is a liability, no matter how fancy the pipeline around it looks. What dated is the villain. In 2016 the offender was always a Jenkins job full of undocumented parameters running on a special snowflake slave. The offender today wears different clothes. Now it is a release that only exists as a GitHub Actions workflow (GA’d November 2019, and per JetBrains it is now the most-adopted CI system at roughly a third of orgs, State of CI/CD 2025), or a GitLab CI .gitlab-ci.yml, or a CircleCI config - and only runs green because of org-level secrets and a runner image that you cannot stand up on your laptop. Same anti-pattern, new YAML. If the only way to cut a release is to push a tag and pray to a workflow you cannot execute anywhere else, you have the exact problem this post is about. The test is unchanged: can you run it locally? Also, Joel’s single-step-build point I cite below turns 26 this year, not 16, and somehow this is still not universally understood.

What is Engineering Work Product?

Mon, 21 Mar 2016 00:00:00 +0000

Looking back from 2026. The thesis got more true, not less, though not for the reason I would have guessed. In 2016 the argument for treating your commit graph as work product rested entirely on a future human, possibly you, reconstructing intent from it. Now a second reader shows up on nearly every change: an LLM reviewing a diff, or trying to understand the history before it edits the code. I assumed sloppy history would cripple it. It mostly does not. A model that cannot get your intent from a commit message will just read the code and work it out, which is something it is genuinely good at. What bad history costs it is tokens and time, not comprehension.

The Importance of Build Reliability

Thu, 28 Jan 2016 00:00:00 +0000

Looking back from 2026 (draft note, needs my sign-off). Two things about this one have aged and need saying up front.

First, the credit. Reading this back, it sounds like Palantir is where I learned that unbreakable, reproducible builds change how engineers work. That is not quite right. Amazon’s Brazil build system is where I learned it - it was the gold standard, the thing that showed me what a build ecosystem could be (I wrote up how Brazil works here). Palantir is where I tried to rebuild that magic after leaving Amazon, and where I helped birth QBT chasing the same goal. The unbreakable-builds rollout described below was real and it genuinely did change how people worked there. But it was an attempt to recreate something I had already seen work, not the place I discovered it. The QBT effort itself eventually got dropped. So read the Palantir praise below as “the tooling was good and the effect was real,” not “this is the mountaintop.”

Better Debugging Through the Socratic Method

Wed, 27 Jan 2016 00:00:00 +0000

Looking back from 2026. Ten years on, the method holds up completely, but the dialogue has a second participant now, and that changed more than I expected.

The bottleneck was never the reasoning, it was stamina. Every “how could this hypothesis be wrong?” spawns grunt work: grep a log whose format you half remember, write a throwaway repro, trace a call into a dependency you have never read, print a type you assumed you understood. Each step is cheap and there are a great many of them, and most tough investigations die not because the engineer ran out of ideas but because they ran out of patience and settled for “eh, probably a flaky cable.” An assistant collapses the cost of those steps hard enough to change which investigations are worth finishing. I wrote up a real one recently, a phantom monitor-unplug event that froze my Mac, where I handed over the kernel logs and worked the problem as a partner. The part that used to be an afternoon of squinting at log show output was more like twenty minutes of back and forth.

Buildsystem Rundown

Tue, 26 Jan 2016 00:00:00 +0000

Looking back from 2026. This one was always a “living document” - I posted it half-finished in 2016 with a couple of TODO sections I swore I’d get back to, and then didn’t for a decade. So this is the finished version. The original tool-by-tool writeups (Make, Ant, Maven, Gradle, QBT) stand as the 2016 period record with only typos fixed. What’s new: I actually wrote the Go and Docker sections I left stubbed, filled in Bazel, and added a whole section on the tools that showed up after 2016 - Buck2, Pants v2, Nx, Turborepo - plus a timeline so you can see the shape of the last fifty years at a glance. The through-line hasn’t changed: the interesting problem is still strict, reproducible, cross-project dependency management, and it’s still mostly solved only inside company walls.

A Tale of Two Build Systems

Wed, 20 Jan 2016 00:00:00 +0000

Looking back from 2026. I wrote this in 2016 and the framing has aged well, but the examples at the end are dated. The Go section in particular: godep was archived and made read-only in 2026, and Go grew its own real answer. Go modules landed in Go 1.11 (2018) and became the default in Go 1.16 (February 2021), with Minimal Version Selection as the algorithm that decides which versions you actually build against. That is closer to “the Amazon way” than anything godep managed - the versions are pinned in go.mod, the build is reproducible, and you upgrade on purpose instead of getting swept along with tip. So the specific dig at Go below is obsolete. The broader point is not.

New System76 Oryx Laptop Setup

Tue, 01 Dec 2015 00:00:00 +0000

Looking back from 2026. I’m keeping this one exactly as it was - it’s an honest snapshot of what setting up a Linux laptop felt like in late 2015, warts and all. A few things have aged: that “Skylake” CPU is ancient now; btrfs, which I hedged on below as “almost ready,” has been my daily-driver root filesystem for years (I run btrfs-on-LUKS and wouldn’t go back). The NVIDIA situation has shifted but not resolved - NVIDIA finally open-sourced their kernel modules in 2022 and Wayland is now the default on most distros, but “does the proprietary blob cooperate with my compositor this week” is still a live question in 2026, which is depressing. The full-disk-encryption rant below is, if anything, more correct now than it was then. See the companion post for my current machine and why the laptop landscape still makes me grumpy.

Telling Computers What To Do

Mon, 04 May 2015 00:00:00 +0000

Looking back from 2026. This post rests on one claim: computers are deterministic, predictable and reliable, so when they surprise you the fault and the fix are both yours. I still believe that about the machine. What changed is that the most common way I tell a computer what to do now is to ask a large language model, and an LLM is not deterministic by construction. The same prompt gives different answers on different days. Even pinned to greedy decoding at temperature zero, production inference still is not reproducible run to run, because the numerics depend on what else happened to be in the batch (Horace He and Thinking Machines Lab, “Defeating Nondeterminism in LLM Inference”, Sept 2025; Simon Willison’s summary). So the layer I now spend most of my day talking to is the one piece of the stack that genuinely does not do what you tell it.

Keep it Simple, Stupid (KISS)

Sun, 03 May 2015 00:00:00 +0000

Looking back from 2026. The thesis below aged perfectly. This site is still static, still simple, still boring, still a pile of markdown I commit and push. What changed is the plumbing behind it, and that change is itself a KISS story, because the old setup violated this post’s own principle in a way I did not fully own up to at the time. The 2015 post stands as the period record. The two takes after it are the reckoning.

Amazon's Build System

Wed, 26 Sep 2012 00:00:00 +0000

Looking back from 2026. I am keeping this one exactly as written, as a period piece. It describes Amazon’s build and deploy systems as they were when I worked on them between 2006 and 2009, written up in 2012. I have no idea how much of it still holds, and leaving it alone is the point: it is a snapshot of what a world-class build system looked like at a company that had solved this roughly a decade before the rest of the industry admitted it was a problem.