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.

It backs its metadata up to S3. You do need metadata to map inodes / slices / chunks to s3 objects, though.

Tigris has a one-to-one FUSE that does what you want: https://github.com/tigrisdata/tigrisfs

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.

Ok so, "running" sprite status has had some cache consistency issues. You're not being charged for idle sprites, but they may show as "running" even when you're not using them. The UX has improved, and it reliably shows what you expect. Some of the existing sprites need an environment upgrade, but you'll see those improve over the next few days.

For what it's worth, CPU pricing is based on CPU util. A sprite sitting idle CPU costs almost nothing, even when "active".

Good point about quietly grabbing env vars, we can warn about that on first run. All it's getting are these:

  var envVars []string
    shellEnvVars := []string{
    "BASH_VERSION",
    "ZSH_VERSION",
    "FISH_VERSION",
    "KSH_VERSION",
    "tcsh",
    "SHELL",
  }

It's also reading terminfo. It's not handling absolute paths to shells properly, though.

If you want to skip this, running `sprite exec -tty /bin/bash --login` or similar avoids the magic.

This is on the roadmap. The open question right now is if we can just do "fork from checkpoint" for customized template environments, or if we need all the docker infrastructure.

If the fat bundled environment harmful for you, or just extra stuff you don't care about?

flyctl is complicated and, unfortunately, needs pretty aggressive auto updates. The sprite CLI should be much better in this respect.

Believe it or not, that's the only example that's not autogenerated from tests (yet).

https://github.com/superfly/sprites-js/tree/main/examples https://github.com/superfly/sprites-go/tree/main/examples https://github.com/superfly/sprites-py/tree/main/examples https://github.com/superfly/sprites-ex/tree/main/examples

I have a Sprite with an auth token to an isolated Sprite org, it works really well for this.

SQLite works great for my apps. I haven't needed object storage yet, storing files on disk is enough.

It stays awake if you have an open connection (like sprite console) or an exec session if running and producing stdout.

You can specify a max exec time for a process when you launch it via the API.

Intended typo so you can see restore happen ;)

If you `sprite console` to it, it'll forward any ports you open to localhost. You can tunnel almost everything through the CLI with the `sprite proxy` command.

sprite url update --auth public

It requires your api token by default.

Claude Code is an obfuscated javascript app. You can point Claude Code at it's own package and it will pretty reliably tell you how it works.

I think Claude Code's magic is that Anthropic is happy to burn tokens. The loop itself is not all that interesting.

What is interesting is how they manage the context window over a long chat. And I think a fair amount of that is serverside.

I am confused. Are we not supposed to pay zoomers.

Please don't encourage him.

dm-cache writeback mode is both amazing and terrifying. It reorders writes, so not only do you lose data if the cache fails, you probably just corrupted the entire backing disk.