Looking Forward to a Hippy Trippy 2025

It is once again time to figure out what interesting projects I'm going to tackle in the next year. Having thought about the problems I'm looking to solve, there's a bit of a theme for 2025 that I am calling The D. Richard Hipp Cinematic Universe.

Saying Yes to SQL, but not No to NoSQL

Even though I've been on a Redis kick recently, it doesn't mean I've given up on traditional databases. I've done plenty of work in the last few years with Oracle and MySQL as well. But I will admit that, despite having used it since 2001, I've put SQLite a bit on the back burner. In my quest for minimalism, it just sort of fell through the cracks between basic data formats like CSV/JSON/YAML/XML and server-level data storage solutions.

No longer. I can't yet say exactly what all I'll end up using it for, though. One thing that has been bugging me about dealing with a lot of small files is that they are often less than the minimum block size on a modern disk (or, similarly problematic, just over it, with a single bit being used in the last block the worst case scenario). I don't want to be burning 4K for a 716 byte file, or the bulk of my external content archive, among countless other bite-sized byte sizes. While each file like that is a nearly insignificant waste on a 2TB+ hard drive, having tens or hundreds of thousands of them still adds up. There are certainly ways to reduce the slack space, but support is by no means universal. I'm particularly curious to see how usable something like a SQLAR FUSE mount might be.

Get, Git!

Related to archiving, many of the thousands of my smallest files are version controlled Git objects (code, configs, docs, etc.), which are often outdated historical copies that will likely never be meaningfully used ever again. Enter Fossil, which both uses and is used by SQLite. It does a bunch more than basic version control, too.

Right now I have all my software and sites as Git repositories. For my static sites, like Impossibly Stupid, they contain no secret info, so I could offer them up to the public either directly or via GitHub. I simply haven't because their development doesn't really fit the workflow patterns that Git supports best. The documentation for Fossil suggest it might be a better match for my smaller projects, so I do plan to check it out by converting my public Git repos to Fossil.

Search Me

This being a static site, one thing that's very difficult to support is searching through articles. I could do JavaScript tricks similar to the ones I do to get navigation and tag support, but when I started down that path, it became clear that it was going to turn into a large number of small index files I was going to have to create and maintain. Precisely the kind of thing I'm no longer interested in doing!

But SQLite has Full Text Search baked right in. Of course, it can't be done client-side with just JavaScript, but I'm already thinking of ways I might be able to offload those dynamic requests, the same way I do here for comments and polls.

And using Fossil presents another possibility: I may be able to convert this whole blog into a Fossil project that self-hosts the server! That gets me not only search, but a forum and potentially other useful tools. And while in certain respects that's moving away from minimalism, the argument could be made that it's all just a SQLite database that anyone can clone and access locally, which has its own sort of RAGtag appeal.