hrbrmstr's Daily Drop

Drop #714 (2025-10-06): Monday Morning Grab Bag

hrbrmstr

The Garage; wxpull; faup-rs

No theme today, but I will take up some intro time to jot down a thought I’ve had since January of this year.

One would have thought the “vibe coding revolution” would have resulted in scads more resources to include in these Drops. I mean, the LLMs 10x’d all of the professional and recreational coders out there, right? Did not Claude Code, Cursor, et al. make it possible for the everyman (“everyperson”, to bring the term up to modern times) to finally wrest the coding reins from seasoned programmers to finally put us all in our places and control their own AI-augmented destinies?

As someone who strives to produce these modest tomes on as daily of a basis as possible, I can assure you that—unless I’ve lost a considerable swath of my internet-scouring mojo—they have not.

I note this specifically after reading about Replit’s one-year jump from $2.8 million USD in annual revenue to $150 million. Last year, Replit garnered the ire of the coding community with their newfound focus on enabling corporate everyperson vibe coders, but there are still many Replit users who are coding for fun/learning. So, where are the apps/tools/utilities? Please, scour the showcase yourself and tell me what shockingly good resource I’ve failed to deem broadly useful enough to include in these newsletters?

If the “vibe coding revolution” is just locking up LLM generated code behind corporate walls, I’m (a) not sure it’s much of a revolution, and (b) it shows we have, perhaps, failed to carry forth the coding principles and community that made it possible for our AI overlords to garner the power they presently have.

I keep thinking about this situation and shaking + peering into the Magic 8 Ball on my desk (which seems regularly more accurate than the probability draws from our ubiquitous LLMs), and it just keeps coming up “Outlook not so good.” I tend to agree.

TL;DR

(This is an LLM/GPT-generated summary of today’s Drop using Qwen/Qwen3-8B-MLX-8bit with /no_think via MLX, a custom prompt, and a Zed custom task.)

The Garage

If you caught the whiff of a possible undercurrent theme across future Drops, you were right. I’m going to do my best to provide at least one resource per Drop that involves making the most of the least, and it goes far beyond just avoiding subscription expenses.

Today’s foray into savings + utility is The Garage, an open-source, self-hosted, geo-distributed object storage system that speaks enough of the S3 API to be useful, but not so much that it collapses under its own weight. Think of it as a minimal, resilient object store designed to live across your homelab nodes without demanding Kubernetes clusters or a Ph.D. in consensus algorithms.

Garage’s creators set out to make something practical for real-world networks, not pristine ones. They assume you’ll have intermittent connectivity, shifting IPs, and nodes that occasionally go bonkers. Instead of chasing strict, linearizable consistency, Garage opts for configurable replication and “eventual harmony.” It also doesn’t use complex consensus mechanisms; the design goal was to avoid a single “leader” or ordering bottleneck that punishes multi-site setups. What you trade away in theoretical guarantees, you gain in simplicity and performance that scales over plain Internet links.

The system stores data in chunks, hashes them for deduplication, and can compress them with good ol’ zstd. You can define how many replicas you want and where they live. Add or remove nodes, and Garage will rebalance data automatically. It’s not built for raw throughput heroics, but it’s built to survive. There’s no erasure coding, just straightforward duplication. There’s also no attempt to mimic POSIX filesystem semantics. You interact through S3 clients, REST, or a small CLI, and you can even serve static websites straight from a bucket.

The quick start experience feels refreshingly old-school. Drop in a single binary or Docker container, point it to a simple garage.toml (YAY NO YAML!) config with metadata and data directories, choose replication parameters, and launch. Within minutes you can create a bucket, generate credentials, and use familiar S3 tools like awscli or s3cmd to push and pull data. The simplicity, though, is deceptive; under the hood it’s coordinating distributed metadata, replication, and recovery. But it does so without dragging in an alphabet soup of dependencies.

Feature-wise, Garage covers the essentials: multi-site distributed replication, compression, deduplication, cluster rebalancing, and metrics via Prometheus or traces via OpenTelemetry. It can host static websites, alias buckets, and even experiment with a key-value API called K2V for workloads that need to store many small items. It doesn’t pretend to be AWS S3, and that’s intentional. Missing features like ACLs or complex IAM policies aren’t oversights; they’re exclusions in service of clarity.

The result is a system that feels plainspoken and honest. You know what it does and what it doesn’t. It’s not trying to win benchmarks or replace enterprise storage; it’s trying to make distributed object storage comprehensible, hackable, and reliable enough to trust. Garage makes sense when you want to spread data across a few sites, stay independent of big-cloud object stores, and avoid the maintenance gravity of MinIO clusters. What’s more, you can finally combine all those SSDs and legacy spindle disks into a cheap “just a bunch of disks” (JBOD) across some Raspberry Pis and have a multi-TB cluster up in no time. Perfect for storing the emergency copy of Wikipedia (et al.) we mentioned in a recent Drop.

It’s a great project and works super well.

wxpull

We, in the U.S. (and I guess elsewhere if you use our open weather data), are on the cusp of losing our multi-decades-long access to free and open weather data. The singularly good thing this will accomplish is the removal of thousands of useless weather apps from Google and Apple app stores.

Thankfully (until the rest of you succumb to billionaire-backed authoritarianism), we have other places to get weather data from, and I came across a very interesting project that embraces forecast uncertainty, leans into design minimalism, and uses the spiffy ECMWF open (ensemble) data.

wxpull is a text-based weather forecast that runs in your browser and shows you what the weather will probably do over the next week or so. The forecasts, as noted, come from ECMWF, which is the European weather model that meteorologists generally consider one of the best. Specifically, wxpull uses their “WMO Recommended” dataset, which is the subset they make freely available under a Creative Commons license. The data has a resolution of 0.5 degrees, meaning each grid square covers about 55 kilometers at mid-latitudes. That’s coarse enough that local terrain and coastline details get smoothed out, but fine enough to give you a decent sense of what’s coming.

The really cool part (to me) is that instead of telling you it will be exactly 18 °C at 15:00, it shows you temperature ranges and gives you the probability that precipitation will exceed certain thresholds. The precipitation forecasts come from ensemble data, which means ECMWF runs the same model dozens of times with slightly different starting conditions and counts how many of those runs produce rain. If 47 out of 100 runs give you more than a millimeter of rain tomorrow, wxpull shows you 47%.

The temperature handling is a bit more complicated because the open ECMWF data doesn’t include full ensemble statistics at ground level. wxpull works around this by combining the high-resolution surface forecast with ensemble mean and standard deviation at 850 hPa, which is roughly 1,500 meters up in the atmosphere. This isn’t perfect since temperature can behave very differently near the ground due to inversions and local effects, but it’s a reasonable proxy for uncertainty when better data isn’t available.

The interface itself is, refreshingly, just a plain text table. Times run across the top in UTC, days run down the left side, and the columns show you temperature ranges, precipitation probabilities for exceeding 1 mm and 10 mm, wind speed, and cloud cover. The temperatures are printed in Kelvin (O_O) but with the leading digit dropped, so 284K shows up as 84. If you know that 273K is freezing, you can do the mental math, or you can just get used to the scale (or code up your own display). Stockholm’s current forecast might show something like 78-82 in the morning and 83-87 in the afternoon, meaning roughly 5°C to 14°C.

The technical side involves downloading GRIB2 files from ECMWF’s open data portal and using wgrib2 to extract values at specific coordinates. The tricky part is that many of these files use JPEG2000 compression, which means you need to compile wgrib2 with the right libraries, or it will just error out. Once you have that working, you can query any latitude and longitude and get back the nearest grid point’s forecast. The files follow WMO naming conventions with codes that tell you what variable, level, and forecast hour you’re looking at.

If you wanted to make your own version (I am hacking on one for Maine, though I am woefully behind on everything due to being down-and-out last week), you would download the TPG1 and TPG10 files for precipitation probabilities, the ensemble mean temperature at 850 hPa, and the HRES surface temperature forecast. Then you extract the values for your location at each forecast time step, do some unit conversion, and format it into a table. The original code is apparently written in a way that makes this fairly straightforward once you understand the data structure.

The whole thing feels like weather forecasting from an earlier era of the internet, before everything needed to be an app with push notifications and animated radar loops. It provides you the information you need to make decisions and trusts you to interpret it.

You will most assuredly have to roll up your sleeves to make this work, but I suspect it will be time well spent, and you’ll likely learn quite a bit in the process.

faup-rs

Since the previous two sections were long-ish, we’ll keep this short.

The outstanding folks over at the AIL (Analysis Information Leak framework) Project needed faster URL parsing for one of their projects and decided to take the parsing principles in faup and rebuild it in Rust.

Thus, faup-rs is now a high-performance, zero-allocation URL parser:

  • Hostnames (with subdomains, custom TLDs, and IDNs)
  • IPv4/IPv6 addresses
  • User credentials (username/password)
  • Ports, paths, queries, and fragments
  • UTF-8 and URL-encoded characters

It also groks the Public Suffix List and correctly identifies domain suffixes while supporting custom TLDs via a CUSTOM_TLDS configuration.

It is super fast, and does what it says on the tin, but I haven’t tossed it at some of the real-world use cases Daniel Stenberg (of curl fame) has to showcase how different URL parsers handle in-the-wild gnarly URLs.

If you require guaranteed curl-faithful parsing, I suspect you’ll need to stick with the library that comes with the curl project. But, for my work, I’ll be switching out all my existing code to use this.

FIN

Remember, you can follow and interact with the full text of The Daily Drop’s free posts on:

  • 🐘 Mastodon via @dailydrop.hrbrmstr.dev@dailydrop.hrbrmstr.dev
  • 🦋 Bluesky via https://bsky.app/profile/dailydrop.hrbrmstr.dev.web.brid.gy

☮️

, , , , , , ,

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.