I often find that imposed limitations make it easier to create things: it’s
easy to aim for perfection if you can expend as much effort as you like on
something and thus end up with nothing that you’ll ever call good enough to
share. Over on Cemetech in the final months of 2023,1 we held a programming
contest: write a
screensaver, any kind of screensaver. I’m not often one to do any kind of
competitive programming, but as a prompt for a constrained project this was a
good one for me. As a result, I wrote a program I called
WEB1999, that won second
place.
I’ve recently been asked to reduce the size of video files with some regularity, taking in a video file and generating something with reduced file size (“squishing” the video; hence “video squisher”). This is an easy task to accomplish with Handbrake, and since the transcodes I was asked to do were consistent in their needs, I was able to set up a preset in Handbrake to make these conversions very simple.
Unfortunately, there were a few steps that weren’t as easy to automate: namely, grabbing the original video and sharing the transcoded version later. Rather than need to do anything myself for each video, I sought to make my process available for “self-service”, probably as some kind of web-based tool instead. Since the imposition of receiving a file, running it through Handbrake, and sharing the result is fairly small though, I wanted to make this tool as simple as possible.
I believe I succeeded and that the results are interesting enough to share because I discovered a few new tricks that made it easier, so in this post I will describe what I built to meet this need and how it was made.
The Legend of Zelda: Tears of the Kingdom is an excellent video game, which I’ve only recently (about three weeks ago,
at the time of writing) played to a satisfactory conclusion; it took me around 90 hours of gameplay over nearly 150
real-time days to reach that point, representing a pretty significant amount of my free time. I
previously wrote about what I liked about Breath of the Wild, its
predecessor and although I found a few aspects of Tears of
the Kingdom’s (henceforth “TOTK”)
plot less compelling than Breath of the Wild (“BOTW”), the scale of the newer game and its overall presentation left me
extremely satisfied on its completion. Between them, I’d say these most recent Zelda games are strong contenders for the
title of “best videogame” with no qualifiers.
On a long-lived Linux server I operate, it has periodically been desirable to
move its root filesystem (containing core OS files and the like) to a new drive
for various reasons. Over the years it’s migrated from a conveniently
inexpensive mechanical hard drive to a series of increasingly capable and larger
solid-state drives (SSDs), first connected over SATA and later in the form of
M.2 NVMe cards. I recently sought to do another upgrade, swapping the current
NVMe drive for a larger one. Making things more interesting, I’ve developed strategies to do this without rebooting except to physically plug or unplug devices!
Earlier this year, I had a desire to capture time-lapse video of some construction that would take an unknown amount of time and occurred mostly during short periods of activity separated by intervals of inactivity with varying time. Because the overall recording time was unknown, this represented an interesting set of challenges that I wrote some software to address, using a Raspberry Pi and a USB webcam. (See the end of this article for the complete source.)
There is no shortage of articles around the web describing how to capture time lapse videos with a Raspberry Pi, such as Caroline Dunn’s article in Tom’s Hardware. I find that most of these involve some kind of script to take still images at intervals, and another component (usually using ffmpeg) to combine those images into a video.
Users who are accustomed to writing TI-BASIC on computers in plain text like any other programming language are probably familiar with sometimes needing to explicitly mark where token boundaries occur. I’ve been doing some thinking about this lately, and have arrived at a proposal for a way to improve the situation for some uses.
What enthusiasts often refer to as the TI-8x series of calculators is the TI-83+ and its variants, including the improved TI-84+ and color-screen CE (and happily abandoned CSE) versions. These are calculators sold by Texas Instruments and commonly used in middle- and high-school math instruction. The internal architecture of these calculators is based on a Zilog Z80 processor with 512 kB or so of Flash memory and 32 kB of RAM (with larger memories in the newer versions).
I recently had a bit of a problem with the files that had ended up in Google Photos on my account: the Google Drive desktop synchronization app seemed to have noticed the many (reasonably-high-resolution) thumbnails that my local photo management application (Lightroom) creates, and had uploaded many near-duplicate images.
It seems this wasn’t a problem with the old “Backup and Sync” application because it supported excluding some files from backup (so I could have it ignore the directory that thumbnails get put into), but the new Drive application lacks such a feature.
While Google’s sync tool does know how to avoid uploading exact duplicates of photos, it doesn’t do any similarity matching on image content, so thumbnails (with the same content but lower resolution) and alternate formats (sidecar JPEGs that go along with camera raw files) end up duplicated in the Google Photos library. I have previously ignored the duplicates in alternate formats because they weren’t too annoying, but when the sync tool uploaded a few thousand duplicate thumbnails I felt the need to do something about it.
It is fairly well-known among techies that hard drives used in server-like workloads can suffer from poor configuration by default such that they frequently load and unload their heads, which can cause disks to fail much faster than they otherwise would. While I have been aware of this in my home server as well, it is easy to forget to ensure that disks are not silently killing themselves by cycling the heads. Since I use Prometheus to capture information on the server’s operation however, I can use that to monitor that my hard drives are doing well.
The Prometheus Node Exporter is the canonical tool for capturing machine metrics like utilization and hardware information with Prometheus, but it alone does not support probing SMART data from storage drives. It does support reading arbitrary metrics from text files written by other programs with its textfile collector however, which is fairly easy to integrate with arbitrary other tools.
I sometimes find myself wanting to cross-compile programs with CMake on a Linux machine such that I get a standalone .exe that can be given to mostly non-technical Windows users to run. This isn’t hard, but finding the right options is a little bit of a challenge every time, so now I’m recording the procedure here; both as a reminder to myself, and to provide a quick recipe that future searchers can use.
Cross-compiling for Windows will of course need an appropriate toolchain, which these days tends to be mingw-w64. Many Linux distributions provide packages for it: mingw-w64 on Debian (including Ubuntu and variants), mingw-w64-gcc on Arch and similar for other distributions.
I’ve been doing some Django development lately, and was mystified why it seemed the debug toolbar on my local development instance wasn’t showing up, though it had been in the past. It turns out to have been a surprising interaction between browsers sometimes enforcing that resources be served with correct MIME types and the way Windows provides system-wide MIME type configuration (which seems to have major flaws)!