Nazi bar as defined by Wiktionary:

(Internet slang) A space in which bigots or extremists have come to dominate due to a lack of moderation or by moderators wishing to remain neutral or avoid conflict.

Justin M. Keyes (justinmk) on the neovim.github.io project for an issue¹ asking to remove a quote by noted racist DHH:

You are trying to draw a response so that we can have a debate. Sorry, I'm not going to spend time on this. And that includes whatever demands you're making of me.

And

You all have embarrassed and shamed yourselves.

Most of you aren't Neovim users, but a drive-by mob, swirling from one mindless vomit-party to another, like the pacific garbage patch.

A PR to remove the quote was eventually merged.

1. Archived copy: https://jacroe.com/tools/files/neovim-neovim.github.io_issue-501.pdf ↩

A great how-to on moving from a Docker volume to a bind mount.

That being said, I don't necessarily agree with their benefits breakdowns for each? For example, as a benefit of using Docker volumes, they say:

Persistence: Even if the Docker container is deleted, the volume persists, which is crucial for non-temporary data.

For reasons listed in my previous post about Docker volumes, I actually find that as a negative. I greatly prefer unsurprising and in-plain-view locations¹ of my container data. Also, you know what else will persist data if a container is deleted? A frickin' bind mount! And I usually keep mine in the same directory as the docker-compose.yml.²

But I successfully, easily migrated a Postgres data volume to a bind mount³, and I'm going to bookmark it (via this blog post) and archive it in several places so I'll always have it.

That's how nice it is.

1. An unfair set of adjectives, perhaps, but I'm sticking with 'em! ↩

2. I can definitely see me having a different opinion if I had to do enterprise things with Docker containers, and that's almost certainly what volumes are for. But that still doesn't explain why quite a few software projects aimed at self-hosters keep using volume mounts over bind mounts. ↩

3. For a project that quickly switched from "Let's just try it out" to "This is now essential, and I need to back it up." ↩

A page categorizing all of the many, many reasons to buy, use, and store physical media.

The big one for me was:

Google Play Music shut down in December 2020 and was replaced by YouTube Music. Not all user libraries survived the transition intact.

This lead to me spinning up my first self-hosted service, Airsonic¹. Since then I've got dozens of services running with 73 TB of spinning metal for backups. I archive all of my purchased books, music, photos, games, and beloved online videos daily. Between all the services and tools that Google has killed and all the content censorship and removal that the linked page has documented, I don't trust anything online at all. "The internet is forever"? Well, not lately, no.

Join us at /r/datahoarder. We have cookies.

1. Though I have since happily transitioned to Navidrome. ↩

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. ↩