Bring back inertial navigation Going deep on Etak and pre-GPS navigation tech got me thinking about what an inertial navigation approach might look like today. Sensors have only gotten more sophisticated and having to map-match yourself onto the route really doesn’t sound like that big of an inconvenience in exchange for tossing all the surveillance potential of GPS and tower triangulation-based geolocation tech. This is the only technical idea that I actually think could be cool and useful.

this idea from @lifewinning is so cool, i had not heard of inertial navigation https://placing.technology/i-was-in-a-bad-mood-and-i-wrote-down-my-worst-ideas-for-fixing-geo#bring-back-inertial-navigation https://en.wikipedia.org/wiki/Etak

I wrote an exporter from my artificial pancreas loop system to the database. I can monitor glucose readings, automated insulin doses, etc., along with summary stats. I use tailscale to send data from my phone to the server, and can view from any machine connected to the VPN (like my laptop). #t1d

These formats tend to trade core metrics for a long tail of features. I'm not totally convinced WASM is worth it here for most data, but could be useful for large datasets where data-to-header ratio is favorable & future accessibility is paramount (ie: census data or climate data).

"F3: The Open-Source Data File Format for the Future"
db.cs.cmu.edu/papers/2025/...

A new contender to parquet. The most unusual aspect of the format is that it can embed WASM decoders directly in metadata, aiding portability and future-proofing. WASM is optional - perf looks OK, but size is meh.

Screenshot of database dashboard with network debugger open showing 7.41KB per request

Database binary format sketch with bytes per component

I built out a binary format for the database, along with gzip/zstd compression (using gzip for now because safari is slow to adopt). A fully loaded channel is now 7.41KB per request. Can probably trim down slightly more with zstd dictionary training, but it's already very compact before compression.

Vanillajs is a thing, and it works great for me. Installing half the internet is a project-by-project problem and I expect we'll see the same supply chain attacks occur in any ecosystem with similar package governance, once they get big enough and old enough for widespread bitrot, ie: rust/cargo.

Added t-digest to the db, which allow percentiles to be estimated with a fixed memory footprint per channel. This is useful for key stats like medians, but also allows me to generate approximate CDF/PDF plots for understanding value distributions. Aiming for ~4KB total footprint per channel sketch.

I also use uplot, which has an edge in practical performance, but with less features and documentation. I find myself struggling with overlapping labels and value text formatting using either lib. While uplot is faster, the API is still memory heavy (array-of-structs data representation).

I've used observable plot for a few projects now, and can basically endorse it with a few caveats. It provides excellent charts out of the box, with minimal configuration, free of chartjunk/widgetjunk common in python viz world. It's surprisingly fast, but could be faster w/ a simpler feature set.

First pass at a batch POST endpoint; benchmarks for single batch, single channel, best of 5 samples each:

- 1 week @ 1hz: 12ms
- 1 month @ 1hz: 27ms
- 1 year @ 1hz: 221ms

The implementation is similar in timeseries features/function to Windows Task Manager, which is 5.6MB on Windows 11, vs 37KB (uncompressed) for this application - 2x smaller than the OG Task Manager for Windows NT 4.0 in 1996!

Now I'm adding batch endpoints for high throughput / high cardinality.

Added a search bar and a number of demo feeds I'm using for testing the database. Here's me searching for ISS telemetry, then checking a channel that tracks the volume setting on my macbook, which updates in real-time.

I made a video showing all aircraft within 100 miles of the EC president's aircraft during its flight to Plovdiv. One other aircraft exhibited symptoms of GPS interference at around the same time.

Put it on the pile next to "I need to pay for a fresh prescription for insulin every few months for the last 30 years" I guess.

Beautiful symbology on these! Also, TIL SF was full of horse race tracks.

I have a docker-compose I use everywhere for spinning up and orchestrating prometheus and grafana instances. Those tools feel like magic for understanding systems, however, docker + go server + grafana server is a lot of variable overhead. Hoping this will be a more simple & predictable golden path.

"Hello World!" from a new (very WIP) lightweight embedded database focused on online real-time statistics. The standalone executable is currently *9.94KB* compressed.

endorse

Cubemon - Real-Time openGL rotating .png images from RRDTool. Images generated by stats from monitored devices rotate in cubes. This example showing 26 devices at once - Hamish Marson 2008/4

I was exploring RRDtool, a round robin timeseries database / plotting system, and came across this beauty. It's been around a while, so the gallery has many interesting examples: oss.oetiker.ch/rrdtool/gall...

Loading a directory on a github repo with a single 140 line file inside:

161 requests
duration: 6.17 s

Contemporaneous speedtest:

down: 917.8 Mbps download
up: 841.5 Mbps upload
ping: 2 ms

edits:

- b&w basemap
- additive RGBA composite rendering
- each line has low opacity (<10%)
- hue scaled to some interesting value, like heading equal interval

*glow map magic*

How I write fast web pages for displaying data:

morganherlocker.com/post/Fast-da...

Initial download sizes:

foxnews (21.62 MB)
wapo: (10.96 MB)
reuters: (9.28 MB)
nytimes (9.16 MB)
apnews (6.81 MB)
usatoday (336 KB)

This is a fair comparison to raise, but Java '96 had unforced errors IMHO:

1. insanely long start time
2. requires non-default OS dlls - if packaged together, exe's would have been huge (latest java download is 40MB compressed - maybe it was smaller back then?)
3. legendarily shitty installer

Silly example, but:

What if instead of sending a `meme.gif` (20KB) or a URL to a gif (1KB) to be viewed in a browser (300MB),

...we sent a `meme.gif.exe` to be viewed in a self-contained standalone viewer (20KB gif + 80KB exe).

The standalone executable GUI/graphics program I'm working on currently weighs 289KiB, with minimal effort to optimize it so far. I love the shareability of web apps (just copy+paste a URL), but maybe there's a tipping point favoring the shareability of tiny exe's at some point on the size spectrum.

"Program Files (x86)" vs "Program Files" has major report_final_final2.xlsx energy.

This is my read as well. The core principle is to avoid marks that don't convey intentional information, because they are distracting or actively misleading. Go wild with ink that does convey information. The last chapter even praises *maximizing* ink w/ high data density displays.

I'm in the process of setting up a cross-platform cmake setup for a project, and getting Windows working is... interesting. Even the projects trying to be "unix-y" like Cygwin are still heavily GUI driven and full of jank. I guess most devs just accept Visual Studio and heavy GUIs as a necessity?

It is 100% worth making this cultural shift, but its not a technical problem that gets solved with WASM. If every web dev started writing pages with C++/emscripten tomorrow, we'd be flooded in 300MB Qt pages before long.