YouTube now adds a query parameter that discloses who shared a video. This is annoying, but thankfully there's a userscript that sanitizes and strips the tracking info from the URL.

You've almost certainly encountered Conventional Commits before. It may have reared its ugly head in the changelog of an open source project you've used. It may have been the enforced commit format for an open source project you contributed to. A lot of people swear by it. I swear at it.

Even though it is used by a large number of popular open source projects, Conventional Commits is an actively bad standard which encourages focus on the wrong things and fails to deliver on its promises.

I've recently tried to use conventional commits in some personal projects (mainly because Renovate Bot uses them), and I've got to say: I really don't think I like them.

The article gets into it, but e.g., if I expose additional functionality higher up that an already included library provides OOTB, is that a feat or a fix? I also could argue both.

But the argument that sealed it for me was the "if I'm debugging a PROD bug, do I care if it came about a feat or a fix or a chore?" No! I want to know what touched those subsystem's files, dependencies, or configs. chore(dep): upgrade doesn't give me anything; render: dependency upgrade tells me everything.

All that being said, throughout my professional life, I've had a ticketing system¹ back every change we made. So I've gotten used to, and have enforced on other projects, this commit message format:

[PROJ-123] a really good one-liner description

 - Additional comments about the change, usually delivered in grammatical English prose. I usually go with bullet points of changes, but that's optional.
 - Basically, I would say that your entire reasoning for the change should be placed in the commit. If it was obviously explained in the code, that's great. Otherwise, it's got to go in the code comments or the commit message.
 -- Another maintainer *hated* code comments because he argued that they quickly became out-of-date. I couldn't argue against that.
 - I then told the story of how I once made a commit message whose body began with "Grab a cup of coffee, and let's talk about this."
 - Commit messages can (and should) be long, y'all

1. Okay fine. It was always JIRA. ↩

I really don't get Docker volumes over bind mounts.

Docker says they're easier to backup/migrate over bind mounts¹, but I don't understand how rsyncing a single directory that contains everything is supposed to be harder than doing whatever this series of commands are in their documentation.

To me, Docker volumes make sense when you're dealing with temporary data, such as a cache. Or when you're needing to process data before making it permanent. Something like a /tmp.

docker compose down should remove volumes by default. I imagine Docker intends docker compose down -v as a full reset, but a single additional small (-v) flag is so easy to inadvertently lose data. Instead they should force the sysadmin to manually delete the data by specifying the volume name after an rm -rf. And by "volume name", I, of course, mean the bind mount.

docker compose down to remove all volumes. docker compose down --keep-temp-volumes to keep the (should be temporary) volumes.

Anyways. I use bind mounts. I prefer them over volumes. If volumes died tomorrow, I would feel nothing but elation.²

1. "Volumes" ↩

2. This whole piece came about because I was dealing with a 1TB server that was low on disk space, and I figured I would try docker volume prune to see if it cleared anything up. Reader, even after I brought every container down via -v, I cleared out 700GB+. That shouldn't be possible!!! ↩

Sonatype's Nexus is an artifact repository for a variety of formats (e.g., Maven, npm, Nuget, etc.), but I use it primarily for Docker. I cache all the images that I use¹ not only for speed but also to keep a copy that I can control the life of. Once it's set up, it usually enters into that "forget it" step. However for dumb-dumb reasons of my own doing, I needed to re-configure my install.

I ran into this last time, and I ran into it again this time. For a hot minute, I could not login to the repository from via docker login; I kept getting a 401 Unauthorized. From the last time I set it up, I remembered there was something completely unintuitive that I needed to do. I figured it out again, and it takes less than 30 seconds to fix. Why Sonatype doesn't set this up automatically when you add a Docker repo, I don't know.

Anyways, for both you and future!me:

You have to mark the Docker Bearer Token Realm as Active.

To do so,

1. Login as an administrator.
2. Click Settings, then expand the Security section. Click Realms.
3. Click the ➕ next to "Docker Bearer Token Realm". It should move to the "Active" column.
4. Click Save, then try to docker login again.

And that's it.

1. Maybe not all the images, but everything from Dockerhub (including, and especially, the library), ghcr.io, and lscr.io. ↩

The Age of the Encyclopedia began in 1751, with the first volume of the first edition of Denis Diderot's Encyclopedie, and ended in 1911, with the 11th edition of the Encyclopedia Britannica, shortly before the world went mad. An encyclopedia is a compilation of the world's knowledge; an encyclopedic age requires the twin beliefs that such a compilation is possible, and that it is worthwhile. By 1911 it was no longer quite possible, in truth, but the dream lived on. The advertisements for the 11th declared that it was "Everything Explained That Is Explainable." In any case, the firm conviction of the worth of such a project allayed any fears about its possibility.

Underlying these two beliefs, though not following them in strict logic, is the idea of progress, indeed of continuous progress. Compilation implies rational understanding, the purpose of which is to make further understanding, if not inevitable, at least possible. With further understanding we may expect further improvement of the human condition. The encyclopedic outlook is fundamentally Whig. However else Diderot's philosophes and the editors of the 11th might have differed, on this they were agreed. As J.B. Bury, a contributor, pointed out in The Idea of Progress, the very concept of continuous historical progress did not exist before the 18th century. After 1911, it could no longer be believed in.