> I have kids. They have devices. I wanted some control over them. So I did what many of you would do in my situation: I vibe-coded an MDM.
Wait, what?
Code and Let Live
51–60 of 195 posts
Re: Code and Let Live
#52Playing around with this for a small amount of time, it is very neat but also there are a bunch of things that are unclear / undocumented (I assume the documentation is coming so I'm not faulting them for it not being there yet). Some things that are unclear: - How should I auth to github? sprite console doesn't use ssh (afaik) so I guess not agent forwarding? - What on machine api's are available? Can I use the fly…
Don't think of this as in any way connected to the Fly Machines API. For now, just take it on its own terms. We'll have an open-source local version of it relatively soon, if that clarifies anything.
Re: Code and Let Live
#53AFAIK fly.io run firecracker and cloud-hypervisor VMs. This seems to have a copy-on-write filesystem underneath. Given their principled take on only trusting full-VM boundaries, I doubt they moved any of the storage stack into the untrusted VM. So maybe a virtio-block device passing through discard to some underlying CoW storage stack, or maybe virtio-fs if it's running on ch instead of fc? Would be interesting to he…
I have a post coming next week about the guts of this thing, but I'm curious why you think we'd avoid running the storage stack inside the VM. From my perspective that's safer than running it outside the VM.
My impression is that you (very reasonably) treat anything inside the VM as untrusted. If you want trusted rollback, presumably that implies that the VM can't have any ability to tamper with the snapshot?
But maybe you have parts of the stack that don't need to be trusted inside the VM somehow? Looking forward to the article.
Re: Code and Let Live
#54What is the criteria for a sprite being "idle"? Is it no network activity or is it cpu based?
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.
Re: Code and Let Live
#55This is seriously cool - it's exactly the DX and API I've been waiting for from sandboxed execution providers.
I'd love to be able to configure the base image/VM in a way that doesn't bundle coding tools or anything else I don't need, and comes with some other binaries installed (I'm more interested in using this as an API for a sandbox use-case I have). Is there a way to do this at the moment / is this on the roadmap?
Another option would be configuring the sprite via checkpoint and then cloning the checkpoint from a base sprite, but I don't see this option anywhere either.
Re: Code and Let Live
#56On one hand it sounds cool. On the other, I feel like I missed it.
Is this just a fancy VPS like digital ocean with, https endpoint, snapshot and restore?
(Same thing goes for exe.dev)
Re: Code and Let Live
#57On one hand it sounds cool. On the other, I feel like I missed it. Is this just a fancy VPS like digital ocean with, https endpoint, snapshot and restore? (Same thing goes for exe.dev)
Yes, plus:
* Near-instant creation
* Automatic spin-down scale-to-zero, so you're not paying for it when it's not in use.
If you're using these like we are internally, you've got like 2 dozen of them sitting around in the background sleeping. They're BIC disposable computers. "When in doubt just make another one."
Re: Code and Let Live
#58Playing around with this for a small amount of time, it is very neat but also there are a bunch of things that are unclear / undocumented (I assume the documentation is coming so I'm not faulting them for it not being there yet). Some things that are unclear: - How should I auth to github? sprite console doesn't use ssh (afaik) so I guess not agent forwarding? - What on machine api's are available? Can I use the fly…
To follow up on this a bit, something that I really want is a way to build and launch apps from an llm really easily. I am imagining and environment with a database, object storage, and a publicly reachable webserver. I think this could be that with OIDC auth to an s3 bucket and litestream. I was previously thinking about doing the same thing on my homeserver with tailscale to expose the web interface publicly and ta…
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.
Re: Code and Let Live
#59I might have missed this in the docs, but is there a way to fork/clone a sprite, or restore a checkpoint into a new one?
Use cases: set up my preferred env in one sprite and use that as a template for others; or fire off a few independent sprites with claude code exploring alternative solutions, then choose a winner and reap the rest.
Re: Code and Let Live
#60On one hand it sounds cool. On the other, I feel like I missed it. Is this just a fancy VPS like digital ocean with, https endpoint, snapshot and restore? (Same thing goes for exe.dev)
Yes, plus: * Near-instant creation * Automatic spin-down scale-to-zero, so you're not paying for it when it's not in use. If you're using these like we are internally, you've got like 2 dozen of them sitting around in the background sleeping. They're BIC disposable computers. "When in doubt just make another one."
I see.
Also "containers" always had the option to attach durable storage via bind mounts.
I still get confused by the "this isn't containers" but it's kind of similar.
Maybe I am just too caught up in semantics.
A VPS that is instant to boot, super simple automatic routing and https proxy, with snapshot and durable is a win regardless.