2024Q1 Update, or, my entire backlog I guess

About a year ago, as I was living off of savings having recently quit a job, I was trying to see if I could do open source development full-time and live the “Content Creator™ life” by launching a Patreon page. As you can see from the publicly visible stats, I currently get 21 USD per month (…unless that changes after publication? hint hint :3) so clearly the “full-time” thing didn’t work out. I ended up doing paid contract work, of course.

So what went wrong, why weren’t I able to join the ranks of the FOSS developers that get actually significant subscription revenue? Basically… I’m terrible at being a “content creator”, due to the way my brain works:

• I’m way better at starting projects than finishing them;
• I do great work when I get obsessed with something, but I normally get obsessed with a variety of small-ish things all over the place instead of having a single, coherent, marketable Big Project,
• and the things I get obsessed with happen to mostly be specifically obscure, I’m a huge fan of uncommon platforms—and sadly there’s no money in things like bringing up amdgpu on FreeBSD on aarch64;
• worst of all, a crucial part of “content creation” is public communication—and posting isn’t among the things I get obsessed with, posting is more like a chore for me…
• and I have a habit of wanting to surprise everyone with a cool end result rather than keeping the public updated throughout the process, which, as you might imagine, combines very well with the first issue on this list.

This is why I’ve been blogging so little. I’m probably not getting anyone to volunteer to be the official Manager & Spokesperson of Val Packett Labs any time soon, so I’m writing this post to break the silence by myself, to try to get into the habit of quicker, more frequent post writing, and to use the public as a bit of a “manager” and “therapist” i.e. let’s review my FOSS backlog/roadmap together!

Without further ado, here it is:

• In the background, there’s an overarching operating system megaproject, tentatively titled SoftBSD: building an atomic-image-based FreeBSD derivative that greatly simplifies All The Container Nonsense Of All Kinds into a unified software image management system.
  • It has spawned some various mini-subprojects such as an init system (yeah it would be reasonable to just use dinit but I have Opinions and Ideas about what “systemd the good parts” Actually means especially for This Kind of System) and a logging daemon (my take on the whole journald style binary files vs old school text files is just “SQLite”)… Those kinda deserve standalone “launches” of their own, and could be attractive by themselves to a wider audience, but I haven’t gotten around to doing that because… *looks at the rest of the list* ah yeah.
  • One of the planned subprojects, a fully logind-compatible session tracker that would finally let us run GNOME Shell on FreeBSD, I wanted to submit for FreeBSD Foundation sponsorship, and I’ve even discussed it with ed@…
  • Anyway, the BSD-work-in-general has been mostly blocked on setting up the cross-OS dev environment I want, for developing FreeBSD from under Linux and vice versa, sharing everything as much as possible, etc.
  • and the “key” part of that is filesystem sharing with VMs, so I went with the D41844 import of Juniper’s 9pfs client implementation that didn’t really work as-is, imported the absent more recent Juniper commits except the one that broke everything, added a missing method for mmap to work properly, overall got it to sort of a working state… only to hit a terrible performance wall? As I remember, building FreeBSD inside of a FreeBSD VM running off of virtio-9p with that driver would just spend the majority of time on lock contention rather than actually performing the work, making very little progress over time. I never quite got to trying to get my head around the concurrency implementation in that driver :/ and yeah right I could probably just use NFS but shhhhh
  • At least the Fixes to make bootstrapping from Linux/musl work that were also part of “the dev environment” have been met with plenty of interest and should end up merged eventually!
• Something way easier and more light-hearted… browsing through my package repository accounts I’ve recovered a “CSS framework” I wrote a literal decade ago that I’d already deleted from GitHub, but not from npm; last month I started writing a blog post about exploring it a bit, and somehow still didn’t come around to finishing it. I really need to cross this one out already.
• I definitely could (and should) come back to TiddlyPWA and work on some issues there.
• And speaking of tiddly things, when I saw heynote I realized I could also use math.js to build a “Soulver-like” inline calculator-notepad TiddlyWiki plugin.
• Now a big one! Soooo I don’t have a gaming PC anymore and the PC port of the sequel to a big graphically intensive game I absolutely loved came out on Steam recently, so naturally I started working on a Cloud Gaming Solution that would satisfy me. Yes I’ve seen docker-steam-headless; no of course it’s not how I’d build it, of course my solution would be Wayland-based :D
  • I’ve actually done a lot of research and made a lot of progress on this, I’m quite close to getting it done;
  • and I have actually been posting a little bit on fedi about nvidia and amdgpu and CloudFormation, hey look at that.
• Part of the aforementioned solution involves a little webapp (for spawning the instances of course) so of course we require more minerals web dev tools: I’ve long been a fan of the “bundler-less” way of doing things, and now with import maps shipped everywhere, importmap-rails came out to promote their usage in production. I’m going to build a Rust thingy that’s just the “download all the JS locally to avoid depending on the CDN in production” feature of importmap-rails plus some tiny extras like pre-compressing text assets as .gz/.br, to be used right before rust-embed in release builds.
• To help me with a paid contract project, I’m working on a thing to help with manually editing big OpenAPI spec files… specifically a FUSE filesystem that splits a spec into separate files per path, always converted to YAML even if the “mounted” file is JSON.
• As if I needed to add another item onto this list!! Just a couple days ago I decided to finally take a look at that pile of very old cheap Android tablets collecting dust in my local hackerspace, primarily looking for something to run 3D printer control on instead of an SBC… Well, I found a gem there, next to various broken junk there was a fully functioning tablet with a Rockchip RK3066 SoC and UART contact pads! I’m definitely getting mainline-powered postmarketOS onto this. Here’s the tablet with a newly added serial connection:

Ah, by the way, some things I have actually done:

• Took PaperWM for a spin and contributed the EDGE snapping mode to it… yeah that’s that;
• Fixed the firmware on my custom keyboard, as there was a bug with the keyboard not responding anymore after a sleep-wake cycle on the host; now that’s not an issue anymore and even the keyboard itself goes to deep sleep with a USB suspend, saving precious mW;
• One day—apparently 7 months ago already, wow—I stumbled upon wazero, a WebAssembly runtime written in Go. Immediately I thought: hm, golang, Caddy, a wazero based plugin for Caddy just should exist now, and with caddy-tailscale I could then build a funny little one-process “FaaS” server where I could just POST a .wasm binary and have it instantly appear as its own host in my tailnet. A CGI WASI binary specifically, of course, due to the “AWS Lambda is the new CGI” memes and such. Sadly the “final product” FaaS thing fell through due to caddy-tailscale’s experimental network listener mode not handling config reloads well, as well as due to me not having any actual use for this and losing motivation :D
  • But, but, but: caddy-wasm-wcgi, caddy-multi-dyna-config, and cgi.cr (the endpoint for accepting new wasm files and generating Caddy configs for them was to be written in Crystal) are all actually working published complete projects, just… not announced anywhere, as I wasn’t feeling like blogging just about them without the meme-FaaS thing, so I guess this is their announcement here and they’re not part of the backlog anymore! Granted, WCGI is not the actual future and caddy-wasm now exists for the proper WASI Component Model based HTTP stuff that is the future. But if caddy-wasm-wcgi ever helps someone with Wasm-ifying an actual legacy application I’d be very happy about it!
• Various build fixes landed for musl/Chimera: jemallocator, compio, aquatic
• Got sponsored (!) to do something with actually rather obscure stuff: rewrote a little Discord bot in Factor, also writing Flatpak build scripts for Factor due to running a non-glibc Linux.
• Also sponsored: resurrecting dav1d.js/avif.js due to old iPhones.

*exhales*

Okay, that’s… actually not too bad! Well, that’s only the open source stuff, while I also need to do paid work, do local political activism, participate in the local hacklab, hang out with friends, take care of myself, and sometimes just watch some damn YouTube :D But still, the scary huge backlog isn’t actually that scary nor messy. I will continue working on what I like and some things will be successful and some less so and there’s that!