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

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