mrkurt

Inputs for the ui might be me talking, or typing, or having someone else talk or type. They might also be GPS, temperature, BLE devices nearby. Or maybe a button I smash because I don't feel like re explaining something.

What happens after an input is still the best part of a UI. We like seeing/hearing/feeling things in different ways.

Hardware is still constrained by compromise. If I want a screen for movies with a battery that lasts and doesn't burn my leg when it's in my pocket, I give up a physical keyboard and nice speakers and a bigass physical camera lens.

The physical device that is best for me is probably the best car compromise for several million other people.

if my ex calls and I want my glass brick to flash the "help me" in SOS on the screen, play Hector Berlioz, and dim all the lights in the room – I can have that. I don't have to want the same thing a million other people do.

What does it mean?

I love that you've said this to me more than once.

You will be astonished to know it'a a whole lot of sqlite.

Everything I want to pay attention to gets a token, the server goes and looks for stuff in the api, and seeds local sqlites. If possible, it listens for webhooks to stay fresh.

Mostly the interface is Claude code. I have a web view that gives me some idea of volume, and then I just chat at Claude code to have it see what's going on. It does this by querying and cross referencing sqlite dbs.

I will have claude code send/post a response for me, but I still write them like a meatsack.

It's effectively: long lived HTTP server, sqlite, and then Claude skills for scripts that help it consistently do things based on my awful typing.

All the time with a bunch of different sandboxes.

This is, in fact, the biggest problem to solve with any kind of compute platform. And when you suddenly launch things really, really fast, it gets harder.

For what it's worth, I do this from about 50 different IPs and have had no issues. I think their heuristics are more about confirming "a human is driving this" and rejecting "this is something abusing tokens for API access".

Sandboxes with the right persistence and http routing make excellent dev servers. I have about a million dev servers I just use from whatever computer / phone I happen to be using.

It's really useful to just turn a computer on, use a disk, and then plop its url in the browser.

I currently do one computer per project. I don't even put them in git anymore. I have an MDM server running to manage my kids' phones, a "help me reply to all the people" computer that reads everything I'm supposed to read, a dumb game I play with my son, a family todo list no one uses but me, etc, etc.

Immediate computers have made side projects a lot more fun again. And the nice thing is, they cost nothing when I forget about them.

> Sprites for suspendable, iterative, sandboxed compute sessions (with disk)?..

Yes.

They won't horizontally scale. They're pretty good for hosting my side projects! Not good for, eg, hosting the API that orchestrates Sprites.

Shell environments are by far the most difficult part of building a stateful sandbox with checkpoints and restores. It's bananas. This will be fixed soon.

FUSE is full of gotchas. I wouldn't replace NFS with JuiceFS for arbitrary workloads. Getting the full FUSE set implemented is not easy -- you can't use sqlite on JuiceFS, for example.

The meta store is a bottleneck too. For a shared mount, you've got a bunch of clients sharing a metadata store that lives in the cloud somewhere. They do a lot of aggressive metadata caching. It's still surprisingly slow at times.

`cat file.txt | sprite exec -s <name> bash -c "cat > ~/file.txt"` is my go to.

It's tiered, they have local nvme that gets written back to object storage.

npm install hasn't bothered me, but I know of people with massive npm issues that would like faster first installs. Fortunately, it's incrementally quicker after that.

The storage performs pretty well for running claude + my dev. It'll improve immensely in the next few months, though. We should be able to get near native NVMe speeds for the working storage set on reads/writes/flush/fua.