Your coworker/other account, messed it up last time you submitted it too: We made our sandbox filesystem 47× faster by deleting it https://news.ycombinator.com/item?id=48195883
> Otherwise please use the original title, unless it is misleading or linkbait; don't editorialize.
You're linkbaiting.. the opposite of the guideline
[deleted]
[deleted]
we've played with some chunking ideas on our end but haven't landed on a format. drop a link when it's out.
I don't know the purpose of microsandbox, but such an article doesn't give me great confidence in exploring it further.
Small files seem like the perfect case for a user space fs... depending on what you mean by user space fs. If you mean interfacing with a FUSE (or similar) filesystem by using syscalls in your program to context switch into the kernel, then context switch to the userspace FUSE layer, then send it back to the kernel and then back to your program ... that will be especially slow with small files where date bytes per context switch is small. OTOH, if you mean a user space fs where your program has a built in filesystem it can access without context switching, then that will be of benefit ... especially if the files are small enough that you can pack multiple files into a single page.
Also, it's a great illustration of the benefits of layered, modular design that Linux sports: it allows to mix and match parts to build what you need.
[deleted]
Lol, yeah that was your mistake. FUSE is a phenomenal idea but anyone who has used it knows how slow it can be.
Have you tried the sync feature?
Edit: FML why is this being downvoted? At least have the decency of explaining, I'm happy to adjust my conduct but I can't do so if I don't know what I did wrong.
if you're building a harness, the SDK provides better integration. let me know if you hit any blockers.
for sync, it's currently in the works.
A filesystem is a database, it is a type of key value storage. there is a hierarchical lookup key that points you to an unstructured block of data.
Many databases(berkleydb, postgresql, sqlite) are then built on this unstructured database. There is absolutely nothing indicating that putting putting a key value database with hierarchical keys and unstructured blocks in a single file will be slow.
It could be, naive indexing or rebalancing could be very slow. But it does not have to be. In fact berkleydb is a neat case study here. superficially it is a ridiculously simple key value store, why does such a simple thing even need to exist, or have such a long lived presence. It turns out building the efficient structures needed to work with slow non-volatile storage is non-trivial. Early mysql used berkleydb as a low level storage engine. Note that mysql main selling point was speed before correctness.
See also: Virtual machines another ubiquitous case of a filesystem in userspace.
All the filesystem calls go through the kernel. A userspace file system is another process.
It's not like SQLite, it's more like Postgres. Try sending a few hundred thousand small queries to Postgres, and be surprised how slow it's going to be.
The file system api is not like sql that allows complex queries. It's a lot of tiny and simple requests that assume very low latency.
[dead]
If I run the agent outside and use the MCP, is it the model's responsibility to actually develop in the sandbox or are there deterministic guardrails against performing activities outside of it?
The article is really about solving a particular problem with the backend of their infrastructure. Discussion about VMs, Linux kernel syscalls, file systems (virtual, FUSE, etc) would all be relevant.
Your comment is a question about whether and how people use the software itself, which is pretty unrelated to the article.
It’s a bit like an article about Porsche identifying a particular engineering nuance in their fuel injectors, and how things didn’t work the way they thought at a low level, and how they solved it once they realized it. And then you come in with a comment about what people like to do with their Porsches. Like, sure, it involves the same company but what would that have to do with the underlying article on automotive engineering?
Combine that with a growing disdain for the insistence of certain segments of the tech scene to make everything about agentic workflows, (an echo to the constant evangelism of cryptocurrencies or blockchain in the recent past) and you have a recipe for downvotes.
Oh well. :) Thanks for your insight anyway.