eblume

If that's correct, then yeah, I struggle to find much to be upset about with this list. $106M federal loan against what they've built feels, I don't know, about correct for a telecom. Light even. The tax abatement stuff sounds gross but not surprising.

(There are other forms of subsidy than this list would show, though! So, yeah, always going to be an argument.)

You won't hear back from them, though. But, at least for US citizens (and possibly for anyone?), this is as far as I know the closest thing there is to an "Internet 911".

So yes. It's off by default. You have to affirmatively use the feature. (This is purely based on what I remember from the demo, mind you. I have not used the feature.)

And the entire English wikipedia with no images is, interestingly, also 43GiB.

I have this configured to feed in to an agent for large changes. It’s been working pretty well, still not perfect though… the tricky part is that it is very tempting (and maybe even sometimes correct) to not fully reset between mikado “iterations”, but then you wind up with a messy state transfer. The advantage so far has been that it’s easy to make progress while ditching a session context “poisoned” by some failure.

Unrelated note: this was the first time I've linked to my static generated docs for this project and it was really fun watching the grafana dash of my fly.io nginx proxy pick up all the scraping traffic. Thanks for warming my cache :) I work with this tech all the time at my day job but this is the first time I've hosted something from my home, it's genuinely made my afternoon to see it light up.

I've documented the recovery process here: https://docs.eblu.me/how-to/operations/restore-1password-bac...

Basically, I have a borg backup job which runs every day, in a 3-2-1 replication strategy with the backups being sent both to a locally encrypted NAS (backups themselves have an additional layer of encryption via borg) as well as off-site with BorgBase. Those backups scoop up an export of 1password that I have a reminder to kick off manually about once a month via this script: https://github.com/eblume/blumeops/blob/main/mise-tasks/op-b...

The password that decrypts the key (along with the password that decrypts the backup) is stored on a piece of paper in a fireproof safe in my house. I've got a reminder to practice the entire DR process every six months, although I've only done it once so far as this is all pretty new.

It was fun to build!

Of course the reality is that this tech won't ever see adoption used that widely, but where is the break-even point?

TBH it's getting a bit exhausting watching us go through this hamster wheel again and again and again.

tmux, to me, feels like "modern screen". It has some cool features, but at the end of the day, it just wants to be a terminal multiplexer. Great!

Zellij on the other hand seems to offer terminal multiplexing as an obvious first-class use case but "not the whole point". At the surface, Zellij is an opinionated terminal multiplexer that uses a nice TUI to give discoverability which you can turn off when you're ready to gain screen real estate. It's easy to make Zellij behave exactly like tmux/screen, and it's easy to configure via a single config file.

Where Zellij takes a turn in to a different direction, however, is that the workspaces you can configure with it can do all sorts of interesting things. For instance I once built[0] a python cli app which had a command that would launch a zellij workspace with various tabs plugged in to other entrypoints of that same python cli, basically allowing me to develop a multi-pane TUI as a single python Typer app. In one pane I had the main ui, and then in another stacked pane I had some diagnostic info as well as a chat session with an llm that can do tool-calling back out to the python cli again to update the session's state.

I think wrapping up a project's dev environment as a combination of mise (mise.jdx.dev) and zellij or nix+zellij to quickly onboard devs to, say, a containerized development environment, seems like a really neat idea.

0: https://github.com/eblume/mole/blob/main/src/mole/zonein.py -- but this is mostly derelict code now, I've moved on and don't use zellij much currently.

The "Kessler syndrome" worst case scenario - I'm just recalling stuff from Scott Manley videos here - I think is a 'really bad decade' where a cascade of collisions makes launching in to LEO impossible until everything settles down in 10ish years. Bad, yeah, terrible even, but possibly worth it in some sense? I mean, it makes about as much sense to me as growing subsidized corn for ethanol gas, I suppose. I'm sure someone is making money.