I had an odd situation today when building and pushing a container image to a registry.

I have a private registry in my homelab. I have an internal DNS server that can resolve it when in my home network, and my machines in my home network all use that internal DNS server. Great, fantastic, just works.

Except for some reason, when running a docker buildx build --push operation, it was unable to resolve the internal name... because it was using the wrong DNS server. It was trying to resolve via the 8.8.8.8 DNS server. The Google DNS servers. Which I've not even configured as an upstream in my recursive DNS server on the local network.

Somehow, I got a file in my tree that started with a null byte. I only discovered it because git status was noting it wasn't added to my branch, and wanted to know if I wanted to add it.

No, no, I did not. I wanted to delete it.

But, of course, you cannot reference such a file by name, so I had to learn a few tricks.

I'm a longtime zsh user. A colleague introduced me to it in 2009, and I was an instant convert, if nothing else than for directory aliases and simpler $PATH management. Within a couple of years, I discovered oh-my-zsh, which put my shell on steroids, giving me a ton of completion capabilities, better prompts, and more.

But a few years ago, I started noticing that my shell load times were getting worse and worse. At that time, I discovered I could easily switch to vanilla zsh with zplug managing a small number of plugins I used (nvm, fzf, and a few others). I also discovered starship, which gave me more prompt options, with faster startup times.

And yet...

I've been using Linux on the desktop for more than 25 years now. While I don't put icons on my desktop any longer (and haven't for probably around 15 years), I do use the gnome-shell launcher to quickly open programs, and this utilizes desktop files.

Recently, I wanted to create launchers for different Obsidian vaults. Obsidian provides a URL schema for this: obsidian://open?vault=VaultName. The application registers the schema handler with the system, so this should open, but evidently you can no longer use "Type=Link" in your desktop files.

What I found:

• You MUST have a "Version=1.0" line; gnome-shell just ignored any of my desktop files that omitted it.
• You can use xdg-open in your Exec line to open the URL.

[Desktop Entry]
Version=1.0
Name=Notes
Icon=/usr/share/icons/hicolor/256x256/apps/obsidian.png
Comment=My Obsidian vault for notes
Categories=Office;ProjectManagement;
Type=Application
Exec=xdg-open "obsidian://open?vault=notes"

Zoom used to have a strange behavior, one I'm sure they thought would be useful, but in reality was infuriating: if you moved between virtual workspaces, Zoom would minimize to a thumbnail window that followed you around to workspaces.

At some point, it went away, thankfully... but after a recent release, it turned back on, and it's been a huge pain for me. There's a bug in that the mini window follows me to the initial virtual workspace, but then doesn't follow around from there, requiring me to use the workspace tools to move it to the workspace I want, and then re-maximize it, only to have to do the whole thing again if I switch screens.

Wezterm has a utility for raising GUI system notifications, window:toast_notification(), which is a handy way to bring notifications to you that you might otherwise miss if the window is hidden or if a given tab is inactive.

However, on Linux, it's a far from ideal tool, at least under gnome-shell. (I don't know how it does on KDE or other desktop environments.) It raises the notification, but the notification never times out, even if you provide a timeout value (fourth argument to the function). This means that you have to manually dismiss the notification, which can be annoying, particularly if the notifications happen regularly.

So, I worked up my own utility.

In a previous article, I detailed how I use Wezterm. One goal I had when switching to Wezterm to was to ensure I was able to continue using a dropdown terminal, and in that article, I detailed using the tdrop utility to implement this... but with the caveat that it didn't work well under the Wayland environment.

Well, I've now found a better solution.

I use the terminal a lot. Until the past few years, I basically used only a browser and a terminal. (The primary changes in the past couple years are that I'm using Logseq for tracking notes and todos, and now use native apps for Zoom and Slack.)

Today I'm going to detail my exploration of Wezterm, my current daily driver.

I occasionally record screencasts for work — some of these are used for the website as demos/training material, and sometimes they're used internally by our various technical teams. When I record, I use OBS Studio, which works brilliantly.

However, since the last time I recorded, I've upgrade my operating system, as well as switched over to Wayland, and I discovered after doing a recording session that my audio was super choppy.

This is how I fixed it.