Chameth.com - posts not break-everything-fuzz-testing, debugging-beyond-the-debugger, g15-ram-upgrade, how-i-use-tailscale, reverse-engineering-arctis-pro-wireless-headset, tracking-pbs-without-the-dark-patterns, why-you-should-be-using-https

Lego, ACME DNS-01, and negatively-cached surprises

2026-09-09T00:00:00Z

Recently a friend was deploying Centauri, my reverse proxy service that can obtain TLS certificates using ACME DNS-01 challenges. He asked a seemingly innocent question: “When Centauri is ‘waiting for record propagation’ is there an option to increase the time?” But that’s a question with a hidden, concerning XY problem. We both use the same DNS provider, and it definitely shouldn’t take more than a minute to see a DNS record after it’s been created. Plus, I don’t have issues with it timing out!

Centauri uses the excellent lego library to do the actual ACME dance, and I’ve dug into it before pretty extensively to debug other DNS issues. When I last looked, it used the local recursive DNS resolver to check for CNAMEs and find the authoritative server, then checked for record propagation there. So, naturally, I blamed Simon’s local resolver doing something weird. Turns out that was surprisingly close to correct, but not for the reasons I thought.

Unfortunately for my snap judgements, Simon had a perfect rejoinder: he’d deployed the exact same VM image before and Centauri worked fine. And also while we’d been speaking it had managed to get a certificate after waiting 58 seconds for DNS propagation. Simon suggested that maybe it was systemd-resolved caching something stale, but I dismissed that based on what I knew of how Lego worked.

Diving back into Lego

Of course, after I dismissed the idea, I immediately started doubting myself. Last time I was looking at DNS issues I traced the code all the way across the Lego codebase. This time I just had a coding agent explore and summarise for me. Turns out it DOES use the recursive resolver to check for the TXT challenge record.

The DNS functionality looks like this:

CNAME query on the _acme-challenge record using the recursive resolver.
Maybe an SOA query on the same, depending on the DNS provider, using the recursive resolver.
Actually create the challenge record using the DNS provider.
Query records recursively to discover CNAMEs using the recursive resolver. It doesn’t matter if this fails.
Query the TXT record on every configured recursive resolver, blocking until they all work.
Query the TXT record on the authoritative nameserver.

So yes, a stale response from the recursive resolver can indeed ruin the whole thing. Simon’s domain had a minimum TTL of 60 seconds, so that links in nicely with it working at 58 seconds and failing most of the time: the 1 minute timeout is racing the 1 minute TTL, somehow. But my domains use a much longer TTL and I can see renewals happening in my logs basically immediately. What gives?

NXDOMAIN caching and RFC fun

So I had a theory as to what was happening, but it still had some loose ends that I didn’t understand. I did get a pretty big hint when I started doing lookups from various locations, though. On my desktop if I do a CNAME query then a TXT query for a record that doesn’t exist, I get this:

$ drill CNAME nonexistent.chameth.com
;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 12630
chameth.com.	3600	IN	SOA	chameth.com. root.chameth.com. 2026339162 7200 3600 86400 3600

$ drill TXT nonexistent.chameth.com
;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 56402
chameth.com.	3590	IN	SOA	chameth.com. root.chameth.com. 2026339162 7200 3600 86400 3600

And from my server:

$ drill CNAME nonexistent.chameth.com
;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 7807
chameth.com.	3600	IN	SOA	chameth.com. root.chameth.com. 2026339162 7200 3600 86400 3600

$ drill TXT nonexistent.chameth.com 
;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 5069
chameth.com.	3600	IN	SOA	chameth.com. root.chameth.com. 2026339162 7200 3600 86400 3600

Notice how the TTL (the first number) decreases locally, but not on the server? That implies my local resolver is reusing the same result when I do the second query, and the resolver on the server isn’t. It turns out that on my desktop I use systemd-resolved, which sends requests to Tailscale, which passes them off to NextDNS. On the server they go straight to Tailscale and then onwards to NextDNS. So systemd-resolved is what’s causing the behaviour. Like Simon guessed right at the start.

But why is it actually doing that? It’s kind of annoying. Well, it’s doing what it’s meant to. RFC2308 says:

A negative answer that resulted from a name error (NXDOMAIN) should be cached such that it can be retrieved and returned in response to another query for the same <QNAME, QCLASS> that resulted in the cached negative response.

A negative answer that resulted from a no data error (NODATA) should be cached such that it can be retrieved and returned in response to another query for the same <QNAME, QTYPE, QCLASS> that resulted in the cached negative response.

Because the record doesn’t exist at all (there’s no other records for _acme-challenge: why would there be?) we get an NXDOMAIN response, and that “should” be cached for any query type. So when Lego queries for the CNAME record, we’re priming the cache with “_acme-challenge doesn’t exist” with a potentially huge TTL on that cache entry. When we then try and query the TXT record we created we get the cached NXDOMAIN back.

If the TXT record was created first then the CNAME query would get a NODATA response instead, which wouldn’t affect us as that is understandably cached per query type. But the point in Lego’s CNAME check is to decide where to put the TXT record, so it can’t just flip the ordering.

I apparently dodged this problem entirely on my servers, because nothing in that resolution path implements this particular caching behaviour.

But why now?

But Simon had this working before. It’s possible that his existing deployments are having this issue now, and are just retrying enough to win the race, but he would’ve noticed if they failed this much when he set them up.

So I did some archaeology. Here’s the timeline:

February 2016: CNAME check added to deal with, well, CNAMEs.
February 2016: Immediate follow-up making a failed CNAME check non-blocking.
September 2024: Option added to check propagation using custom recursive resolvers.
February 2026: That option now defaults to on.

And the mystery is solved: Lego v5 enabled the recursive check by default. That also handily explains why I thought its behaviour was different. It used to be! There were still two things I didn’t understand: why was it enabled, and why didn’t I realise when I upgraded to Lego v5? Looking back, I think this line of the changelog is meant to cover the behaviour:

[lib,dnsprovider] New approach of the DNS calls

The migration guide also mentions the flag being renamed, but not the fact that the default setting also flipped. Feels like burying the lede a little, but hey ho.

As for why, there doesn’t seem to be any documented rationale. Given the recursive resolver check was added to fix a fairly niche problem, it seems like an odd decision to me. The new defaults mean that any recursive resolver that caches NXDOMAIN responses across query types will delay the propagation check, and likely fail it entirely if the TTL is longer than the timeout. That’s… unfortunate to say the least. I opened a discussion suggesting the default gets flipped back but it doesn’t sound like that will happen before v6.

For Centauri, at least, I’ve fixed it by unconditionally disabling the recursive resolver check, taking it back to the Lego v4 behaviour. And after all this, Simon’s original hunch turned out to be spot on: it was systemd-resolved caching, but it was doing the correct thing. Pesky old-man Lego was the one responsible for dropping a rake on the ground then immediately stepping on it.

Monthly Meanderings: June 2026

2026-07-01T00:00:00Z

Writing these monthly posts is making me very aware of how quickly the year is going. I’m not sure I like that at all. June saw some truly horrible hot weather in the UK; it’s almost like murdering the planet with CO₂ emissions was a terrible, terrible idea.

My dodgy knee that I mentioned way back in the April post feels like it’s finally back to normal. I had low expectations of the physio service, and I’m glad to find I was utterly wrong. When I self-referred I got an e-mail the same day with some tailored exercise suggestions, and I’ve had two in-person sessions since. I managed to get some longer walks and a jog in this month, when I wasn’t camped in front of a fan to try and keep cool.

Website updates

Another month with no new posts. I’m just in one of those slumps where nothing quite takes my fancy. It’s a bit upsetting that the three most recent posts are all going to be monthly meanderings, though.

I did spend some time adding standard.site metadata and records for blog posts. In theory that means it’ll show up a bit nicer when presented on Bluesky, but I’ve not actually tested it in anger yet. As well as pretty embeds, having a standard schema for describing publications and posts feels like it could enable a lot of cool discovery/directory uses.

Other projects

Centauri, my reverse proxy, got a whole bunch of new features in response to some requests and problem reports from a friend. Mostly the changes were exposing more options for finer control over how certificates are obtained. Providers other than Let’s Encrypt require extra account details, have different rate limits, and so on.

The only other project of note this month is a new World of Warcraft addon called Who’s Got the Keys? that shows on-screen who has a keystone for the dungeon you’re currently waiting to start. I really like being able to scratch itches like that.

Entertainment

I mentioned my wax-and-wane hobby cycle last month. This month apparently films are back in for me:

There were some big surprises for me in both directions: films I expected to like such as Disclosure Day and Good Luck, Have Fun, Don’t Die absolutely missed the mark; meanwhile Midsommar I didn’t have any particular expectations of and it ended up stealing the top spot on my watched films ranked list.

Most of my other entertainment is still coming from World of Warcraft. I’m now reasonably comfortable with my spec, and my regular group of friends is well on the way to reaching a Mythic+ score of 3400 before the end of the season. Amusingly I’m currently in the top 20 for my spec on my realm, but that says more about the low population of the server than it does about my skill, I think!

My character is now about as fully geared as they’re going to get this season. There are some minor upgrades I could make but it’s not really worth it with only weeks remaining. I now also don’t get any real benefit from doing the standard open world weekly activities, so I’ve been spending a bit more time farming mounts and transmog in old content. I’ve also levelled a whole bunch of alts, but I’ve failed to find a single DPS spec I actually like. I’m now trying alternative healers just to get some variety when we do runs where we’re not pushing keys.

Around the web

Suspicious discontinuities

An old article by Dan Luu that recently resurfaced on Hacker News. It’s an interesting look at various series that have discontinuities and the reasons for those. I’m easily won over by cool graphs, so it’s not a surprise I saved this link.

Incident Report: CVE-2026-LGTM

A very funny spoof vulnerability disclosure that pokes fun at all the failure modes of LLM security tooling and the possible consequences of that.

Help I accidentally a wigglegram

Fun article where the author describes how they automatically made a bunch of “wigglegrams” (stereoscopic animated gifs) from their iCloud photo library. It’s interesting how just taking multiple versions of a photo can result in something novel like this.

Finding the Best Dog Treat with Statistics

I’m pretty sure this is actually some devious attempt to make me learn statistics, but it features a dog called Bebop, so I’m going to allow it.

Monthly Meanderings: May 2026

2026-06-01T00:00:00Z

Another month, another wrap-up post. This is the first one I’ve felt reluctant to write, and I think it’s because I feel like I didn’t really do anything last month. Other than play a lot of World of Warcraft.

Website updates

No new posts this month, but I finished off the refactoring I mentioned in the last update. It’s been a very satisfying process, and working on the site feels a lot less like a chore now. Features are now entirely self-contained, instead of having bits and pieces scattered everywhere, and everything is wired up together with some automatically generated code. I’ll probably write a longer post about the architecture and the refactoring process at some point.

My World of Warcraft page got some updates, now showing achievements and stats about Mythic+ runs. It’s always nice to take a break from the game… and code things relating to it instead.

Other projects

I finished off glauncher, my native alternative to ulauncher and am now using it day-to-day, which is nice. I’ve never really liked making native user interfaces, but having an LLM generate code for Gio UI was pretty much pain-free. I’m now toying with replacing a few other simple apps I currently rely on that use Electron or Webkit with Go versions.

Entertainment

Let’s start with the non-World of Warcraft updates. I seem to be on a one-film-a-month cadence recently. This month’s was fine but not earth shattering:

This Is Spinal Tap

2026-05-30

Quite funny, and it’s interesting to watch something that’s become such a cultural touchstone, but coming to it 40 years on I find it a bit slow and meandering.

SNL UK wrapped up this month, but has thankfully been picked up for another season. I really enjoyed it, despite my initial misgivings about it. I’m now back down to exactly zero TV programmes I care about.

A few board game plays this month, but overall still in the “wane” phase of my wax-and-wane hobby cycle:

4 plays
3 plays

Then, finally, there’s World of Warcraft. I started playing a new class:

Level 90

Female Night Elf

Mistweaver Monk

312 average item level

Miraceth-Terenas

Professions

Midnight Leatherworking		100/100
Midnight Skinning		100/100
Midnight Cooking		100/100
Midnight Fishing		110/300

Mythic+

Altar of Fangs	+9	~~31:31~~	273
Den of Nalorakk	+10	27:22	325
Kings' Rest	+8	25:34	283
Murder Row	+10	22:37	333
Ruby Life Pools	+10	26:39	322
Temple of Sethraliss	+10	27:08	326
The Blinding Vale	+10	23:56	328
Voidscar Arena	+10	24:28	327
Total M+ rating	2516

View on blizzard.com View on raider.io

I’m still mostly playing as a healer, but this one is a melee fighter who heals while doing damage. I previously shied away from melee classes as being right on top of the enemies always felt too chaotic compared to parking at the back of the room, but I’m actually really liking it. Once you get used to it, it’s a lot easier to keep track of the fight when you’re in the middle of things instead of hanging out at the back. This spec is currently one of the flavours of the month, it’ll be interesting to see if I still enjoy it as much when it falls out of favour.

Around the web

Making an original Jubilee line door button into a Hue light switch

A really cool electronics project, that does exactly what it says in the title. The finished product looks stunning, though.

llama.ttf

“llama.ttf is a font file which is also a large language model and an inference engine for that model.”

Departure mono

This is a really nice looking pixel font, and the web page demonstrating it is well done as well. Definitely going to be using it next time I need to render text in a small space.

Mitigating floods of posts in Artemis

James has been documenting his development of Artemis, a ‘calm web reader’, and I’ve been enjoying reading along. This particular post is interesting to me as it deals with a common problem with RSS readers (“the website has altered their feed in a bad way, now there are 50 ’new’ posts that you’ve already seen”) in a novel way that just seems so obvious in hindsight.

Monthly Meanderings: April 2026

2026-05-01T00:00:00Z

It’s apparently been a whole month since the last edition of Monthly Meanderings. Not sure when that happened. This month I’ve been to a LAN party, had an MRI, and have been trying unsuccessfully to get my doctor to change a prescription. The latter two are not doing much to help shake that middle-aged feeling I mentioned last month…

Website updates

Another pair of blog posts for this month: The Case of the Unchanging Config about a problem I had with a bind-mounted config in a Docker container, and Migrating from GitHub to Forgejo, a write-up of… well… migrating from GitHub to Forgejo. That one’s been on my to-do list for a while, so it’s nice to finally get it written up.

It’s not visible when you look at the site, but I’ve been doing a lot of refactoring this month. The existing design had a package for database operations, a package for the stylesheet, a package for shortcodes, and so on. As I bolt more and more things on this gets less and less useful: those packages get bigger and bigger, and trying to understand how, say, the music import functionality works means hopping all over the place. Instead, I’m moving towards having each feature contained in its own package. It defines its own stylesheet, database operations, HTTP handlers, and so on. They’re then all wired together at the top layer. There’s still some more to do on that front, but it’s progressing in a good direction, and I’m happier with the code.

The only actual visible change is the addition of a page dedicated to World of Warcraft that automatically imports some data from the game’s API. We’ll come back to that later!

Other projects

I made a trio of new tiny projects: pdsps, a reverse proxy for a Bluesky/ATProto PDS that overrides the age verification response so you don’t need to hand over ID; irc-adze, a plugin for irc-bot that receives and announces adze webhooks; and wow-spec-switch, a super-simple addon for World of Warcraft that lets you switch specialisation with a command.

I’ve also been working on a custom app launcher in the style of ulauncher but without requiring WebKit to render things. I’ve not yet polished it up enough to open source it, but it’s not far off.

Entertainment

Another single film month for me. It was a great one, though:

Project Hail Mary

2026-04-01

A film adaptation of a book I loved that’s actually good. Huh!

Ryan Gosling does great in what is often a solo act. Early on I thought the film was trying a bit too hard to be funny, but at some point it started working and I enjoyed it.

There are lots of parallels to The Martian, Arrival, and so on, but it’s a sufficiently different mash-up of the concepts that it’s not a problem.

I’m still enjoying SNL UK a lot more than I expected to, although I keep forgetting what day it airs. They should put it in the name or something.

The rest of my “entertainment” time has been spent playing World of Warcraft. I played an awful lot about 6-7 years ago, and have dipped in and out occasionally since. I got an MMORPG itch again recently and jumped back in, and I’m enjoying it a lot once again. I’ve been playing a healer properly for the first time (after enjoying healing in Final Fantasy XIV):

Level 90

Female Void Elf

Holy Priest

280 average item level

Methrica-Terenas

Professions

Midnight Alchemy		100/100
Midnight Engineering		92/100
Midnight Cooking		1/100
Midnight Fishing		4/300

Mythic+

Algeth'ar Academy	+10	20:41	332
Magisters' Terrace	+10	24:58	330
Maisara Caverns	+11	29:31	339
Nexus-Point Xenas	+10	25:08	326
Pit of Saron	+11	29:32	336
Seat of the Triumvirate	+11	31:12	338
Skyreach	+10	19:21	332
Windrunner Spire	+12	19:09	380
Total M+ rating	2713

View on blizzard.com View on raider.io

Around the web

git-history documentation

The latest release of git added this handy-seeming history subcommand. It allows you to reword a commit, or split a commit up interactively, without having to go through the interactive rebase song and dance.

Git has acquired a bunch of new commands in recent releases, but I tend to ignore them in favour of the old ones I know well. This one will definitely get use from me, though.

Git Koans by Steve Losh

Sticking with the same theme, this series of koans about Git and its various quirks had me laughing. If you’re reading this blog, you’re probably part of the target audience for it.

SQLite prefixes its temp files with etilqs_

I think I’d come across this before, but it’s still a fun anecdote. It reminds me of Daniel Stenberg’s e-mail collection; as the author of curl his name is listed on basically everything with the inevitable influx of people contacting him.

A dot a day keeps the clutter away

I love this approach to tracking how frequently things are used, and the weird sort of archaeological record you get from rotating the colours of the stickers used.

The Case of the Unchanging Config

2026-04-09T00:00:00Z

Last week I was attempting to make it so I could share pictures on IRC directly from my client. This sounds simple, but it involves a bouncer¹ that proxies the request to a standalone image hosting service that I had to modify to be compatible. At one point my testing loop was:

Make a change to the hosting service
Commit it
Tag a new release
Wait for it to build
Update the version I’m running on my server
Reconfigure the bouncer to pass the new parameter or change the URL or whatever
Try uploading a photo from my phone
Realise I’ve overlooked something and go back to step one

I could have set up a local copy of everything and tested it sensibly. I should have set up a local copy of everything and tested it sensibly. But it seemed like such a trivial change, and setting up the whole environment seemed like such a pain. After the third or so iteration of failure I was pretty annoyed with myself, computers, and basically everything.

My biggest annoyance was that my bouncer would not pick up the new URL from the config when I changed it. It’s meant to reload the config when it receives a SIGHUP, and it claimed to in the logs, but I could clearly see it was still hitting the old URL. Restarting the bouncer to update the config is a pain, as it disconnects me from all the IRC networks, and has to reconnect to them all, reauthenticate, etc. It also mildly spams everyone who shares a channel with me².

When I finally got everything working I had a look at the bouncer source, and thought I’d spotted the issue. I raised a bug report, ending in this remark:

It looks like the config is reloaded properly, but the handler for uploads is created once at startup and has its own copy of the uploader, so effectively snapshots the config to whatever it is at startup:

fileUploadHandler := http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
    cfg := srv.Config()
    h := fileupload.Handler{
        Uploader:    cfg.FileUploader,
        DB:          db,
        Auth:        cfg.Auth,
        HTTPOrigins: cfg.HTTPOrigins,
    }
    h.ServeHTTP(w, r)
})

I’m not quite sure what I thought I saw there, but that’s not right. I want to call it a hallucination, but that feels like a very overloaded word these days. I guess I was just seeing what I wanted to see, and that was a good excuse to stop investigating. Still, even if I misidentified the cause, the bug was still present, right? … Right?

The Science of Deduction

When the developer got back and said he couldn’t reproduce my issue, I went back to my install and immediately reproduced it. With a calmer head, I figured it was probably something with my particular set up. First thing to check: am I actually running the version I think I am?

Unfortunately the bouncer doesn’t actually seem to expose the version anywhere that I can see. It’s not in the logs, it doesn’t have a -version flag, and none of the IRC-based status commands seem to include it. But I know it’s a Go app, and I know Go embeds the version information. go version -m <binary> will dump it all out, but the binary is inside a Docker image, and the Docker image is one of my nice, minimal, artisanal ones so doesn’t ship a go binary. No problem, docker compose cp bouncer:/bnc ./bnc yoinks the binary out of the container, and then dumping the version shows that, yes, I am running the version I thought I was. Hmm.

The next tool I reached for in my toolbox was strace. Maybe it’s not actually reading the file for some reason? I immediately executed strace -p <pid> -e trace=openat,open,read,pread64 -f without having to look any part of that up. Yep. Definitely. Then I edited the config, HUP’d the bouncer, and saw that it was… reading the config file. As it’s meant to. By default strace truncates strings to 32 bytes, so I couldn’t actually see the line I’d changed. Some more definitely-not-RTFMing later, and rerunning it with an extra -s 65536 let me see the full config. Surprise! The config hadn’t changed!

To confirm my findings, I used docker compose cp again, this time yoinking the config file from inside the container. The inside config file was definitely different to the outside config file. What? My hypothesis at this point was “something something Docker nonsense”. I mount the config as read-only, and was wondering if that meant that Docker was doing something weird instead of just bind mounting it. A quick trip to /proc/<pid>/mounts showed that it was, in fact, not doing anything weird, and was just bind mounting it.

If the file is bind mounted, then surely it’s the same file? I ran stat on the file on the host, noted the inode number, then pondered how to actually run stat on the file inside the container, given the aforementioned awkwardly minimal image. The solution was easy: access it via /proc/<pid>/root/. I could’ve saved myself a bunch of docker compose cp if I’d thought about that earlier. Oh well. The inode of that file was different. What?

The answer was DNS. It’s always DNS. Oh, sorry, force of habit. I meant the answer was vim. I was editing the config in vim, and when it saves files, by default, it writes the new content to a temporary file and does an atomic rename. That’s normally a good thing: it prevents corruption if the write fails midway through³. In this case, though, that means the new file has a new inode. Bind mounting a file binds to the inode, so the container just keeps clutching onto the original config from when it was started, blissfully unaware that the party has relocated down the street.

This problem is likely to happen whenever you bind mount a file into a container. When I mentioned this to a friend, he immediately responded “oh yeah, never do that”, and went on to describe the horrible hacks he’s had to add to Ansible to sidestep the issue. The nicer solution is to just bind mount an entire directory if you can, as then it doesn’t matter what happens to the files within it. I really like having the config files sat alongside the Docker compose files, though; having to create a directory just to work around some bind mount weirdness upsets me.

Now I knew what the problem was, I found there was an issue raised against Docker twelve years ago⁴. The first response was “that’s expected”, and I fully agree with the author: “respectfully, that might be expected by you, but it was not expected by me”!⁵ As a result of the issue they added a nice note to the docs:

Note: Many tools used to edit files including vi and sed --in-place may result in an inode change. Since Docker v1.1.0, this will produce an error such as “sed: cannot rename ./sedKdJ9Dy: Device or resource busy”. In the case where you want to edit the mounted file, it is often easiest to instead mount the parent directory.

But in the intervening twelve years, both the note and the functionality described have gone missing. Ho-hum.

I found it interesting how I’ve only just hit this problem, given how long I’ve used Docker. But I realised that almost everything I run I’m happy to just restart. Cattle, not pets, and so on. My IRC bouncer is one of the few exceptions to that. The only other thing I regularly hot reloaded was Centauri, my reverse proxy, but that had a whole config directory mounted because it was shared between containers, so nicely sidestepped the foot-gun.

So lesson learnt: check for weird bind mount issues before raising issues about config hot reloading. It’ll join the esteemed company of “maybe the drive is full and causing completely unrelated problems?”, “perhaps everything is dog slow because the kernel ran out of entropy?”, and “did systemd sneakily take over that functionality while you weren’t looking?” in the troubleshooting checklist.

An IRC bouncer is basically an always-on proxy. It connects to the IRC networks for you, then your clients connect to your bouncer. The bouncer can then send incoming messages to all your different clients, cache them when you’re offline and replay them later, and lots of other nice things people take for granted in their chat apps these days. ↩︎
Join/part/quit spam is part of IRC, and clients have ways of handling it, but I still feel bad about doing it excessively. ↩︎
You can disable this in vim by setting backupcopy=yes. Good luck redoing all the debugging if you ever accidentally remove that from your vimrc, though! ↩︎
Which is weird, because Docker can’t possibly be that old. That would make me much older than I’m prepared to accept. ↩︎
If you read the thread they didn’t actually mean to sound so dismissive, but it’s still pretty funny. “Yes, it’s expected that the foot-gun causes your foot to hurt. Duh. What did you expect?” ↩︎