In my post last year about my out-of-control single-board computer (SBC) collection which included my meager network attached storage (NAS) solution, I noted that:

I find that a lot of my fellow nerds massively overengineer their homelab NAS setups. I’ll explore this in a future post. For my part, people tend to find my homelab NAS solution slightly underengineered.

So here I am, exploring this is a future post. I’ve been in the home NAS game a long time, but have never had very elaborate solutions for such. For my part, I tend to take an obsessively reductionist view of what constitutes a NAS: Any small computer with a pool of storage and a network connection, running the Linux operating system and the Samba file sharing service.

Many home users prefer to buy turnkey boxes, usually that allow you to install hard drives yourself, and then configure the box and its services with a friendly UI. My fellow weird computer nerds often buy cast-off enterprise hardware and set up more resilient, over-engineered solutions, as long as they have strategies to mitigate the noise and dissipate the heat, and don’t mind the electricity bills.

If it works, awesome! As an old hand at this, I am rather stuck in my ways, however, preferring to do my own stunts, both with the hardware and software solutions.

My History With Home NAS Setups
In 1998, I bought myself a new computer — beige box tower PC, as was the style as the time. This was when normal people only had one computer at most. It ran Windows, but I was curious about this new thing called “Linux” and learned to dual boot that. Later that year, it dawned on me that nothing prevented me from buying a second ugly beige box PC and running Linux exclusively on it. Further, it could be a headless Linux box, connected by ethernet, and I could consolidate files into a single place using this file sharing software named Samba.
Continue reading →

Like many computer nerds in the last decade, I have accumulated more than a few single-board computers, or “SBCs”, which are small computers based around a system-on-a-chip (SoC) that nearly always features an ARM CPU at its core. Surprisingly few of these units are Raspberry Pi units, though that brand has come to exemplify and dominate the product category.

Also, as is the case for many computer nerds, most of these SBCs lay fallow for years at a time. Equipped with an inexpensive lightbox that I procured in the last year, I decided I could at least create glamour shots of various units and catalog them in a blog post.

While Raspberry Pi still enjoys the most mindshare far and away, and while I do have a few Raspberry Pi units in my inventory, I have always been a bigger fan of the ODROID brand, which works with convenient importers around the world (in the USA, I can vouch for Ameridroid, to whom I’ve forked over a fair amount of cash for these computing toys).

As mentioned, Raspberry Pi undisputedly has the most mindshare of all these SBC brands and I often wonder why… and then I immediately remind myself that it has the biggest ecosystem, and has a variety of turnkey projects and applications (such as Pi-hole and PiVPN) that promise a lower barrier to entry — as well as a slightly lower price point — than some of these other options. ODROID had a decent ecosystem for awhile, especially considering the monthly ODROID Magazine, though that ceased publication in July 2020. The Raspberry Pi and its variants were famously difficult to come by due to the global chip shortage from 2021-2023. Meanwhile, I had no trouble procuring these boards during the same timeframe.

So let’s delve into the collection…
Continue reading →

A long time ago, I dashed off a quick blog post with a curious finding after studying the ISO-9660 spec: The format stores multi-byte numbers in a format I termed “omni-endian”– the committee developing the format apparently couldn’t come to an agreement on this basic point regarding big- vs. little-endian encoding (I’m envisioning something along the lines of “tastes great! … less filling!” in the committee meetings).

I recently discovered another bit of compromise in the ISO-9660 spec: It seems that there are 2 different methods for processing the directory structure. That means it’s incumbent upon ISO-9660 creation software to fill in the data structures to support both methods, because some ISO-reading programs out there rely on one set of data structures while the rest prefer to read the other set.

Background

As a refresher, the “ISO” extension of an ISO file refers to the ISO-9660 specification. This is a type of read-only filesystem (i.e, the filesystem is created once and never updated after initial creation) for the purpose of storing on a read-only medium, often an optical disc (CD-ROM, DVD-ROM). The level of nostalgic interest I display for the ISO-9660 filesystem reminds me of my computer science curriculum professors from the mid-90s reminiscing about ye olden days of punchcard programming, but such is my lot. I’m probably also alone in my frustration of seeing rips of, e.g., GameCube or Xbox or 3DO games being tagged with the extension .ISO since those systems use different read-only filesystems.

I recently fell in with an odd bunch called the eXoDOS project and was trying to help fill in a few gaps. One request was a 1994 game called Power Drive for DOS.

I recently published a tool called MobyCAIRO. The ‘CAIRO’ part stands for Computer-Assisted Image ROtation, while the ‘Moby’ prefix refers to its role in helping process artifact image scans to submit to the MobyGames database. The tool is meant to provide an accelerated workflow for rotating and cropping image scans. It works on both Windows and Linux. Hopefully, it can solve similar workflow problems for other people.

As of this writing, MobyCAIRO has not been tested on Mac OS X yet– I expect some issues there that should be easily solvable if someone cares to test it.

The rest of this post describes my motivations and how I arrived at the solution.

Background
I have scanned well in excess of 2100 images for MobyGames and other purposes in the past 16 years or so. The workflow looks like this:

Image workflow

It should be noted that my original workflow featured me manually rotating the artifact on the scanner bed in order to ensure straightness, because I guess I thought that rotate functions in image editing programs constituted dark, unholy magic or something. So my workflow used to be even more arduous:

I can’t believe I had the patience to do this for hundreds of scans

Sometime last year, I was sitting down to perform some more scanning and found myself dreading the oncoming tedium of straightening and cropping the images. This prompted a pivotal question:

After all, I have always been a huge proponent of making computers handle the most tedious, repetitive, mind-numbing, and error-prone tasks. So I did some web searching to find if there were any solutions that dealt with this. I also consulted with some like-minded folks who have to cope with the same tedious workflow.

I  came up empty-handed. So I endeavored to develop my own solution.

Problem Statement and Prior Work
Continue reading →