[HN Gopher] FUSE is All You Need - Giving agents access to anyth...
___________________________________________________________________
FUSE is All You Need - Giving agents access to anything via
filesystems
Author : jakobem
Score : 21 points
Date : 2026-01-11 21:12 UTC (1 hours ago)
(HTM) web link (jakobemmerling.de)
(TXT) w3m dump (jakobemmerling.de)
| heavyset_go wrote:
| IMO, for real file systems, just give a view via
| cgroups/namespaces.
|
| Implementing a database abstraction as a file system for an LLM
| feels like an extra layer of indirection for indirection's sake:
| just have the LLM write some views/queries/stored procs and give
| it sane access permissions.
|
| LLMs are smart enough to use databases, email, etc without
| needing a FUSE layer to do so, and permissions/views/etc will
| keep it from doing or seeing stuff it shouldn't. You'll be
| keeping access and permissions where they belong, and not in a
| FUSE layer, and you won't have to maintain a weird abstraction
| that's annoying/hampered with licensing issues if you want to
| deploy it cross platform.
|
| Also, your simplified FUSE abstraction will not map accurately to
| the state of the world unless you're really comprehensive with
| your implementation, and at that point, you might as well be
| interacting directly in order to handle that state accurately.
| jakobem wrote:
| Agree that to far fetched mappings to files don't really make
| sense. The email example is more illustrative then real world
| inspired, thought it might be good to show how flexible the
| approach is.
|
| I think there is a gap between "real file systems" and "non
| file things in a database" where mapping your application
| representation of things to a filesystem is useful. Basically
| all those platforms that let users upload files for different
| purposes and work with them (ex Google Drive, notion, etc). In
| those cases representing files to an agent via a filesystem is
| the more intuitive and powerful interface compared to some home
| grown tools that the model never saw during training.
| everlier wrote:
| I've implemented agentic framework exactly like this for my
| current employer.
|
| It opens up absolutely bonkers capabilities.
| moonlet wrote:
| I am so sick of the 'sandboxed' AI-infra meme. A container is not
| a sandbox. A chroot is not a sandbox. A VM is also not a sandbox.
| A filesystem is also also not a sandbox. You can _sandbox_ an
| application, you can run an application in a secure context, but
| this is not a secure context the author is describing, firstly,
| and secondly they haven't described any techniques for sandboxing
| unless that part of the page didn't load for me somehow.
| jakobem wrote:
| Didn't mean to say this is a sandbox, it certainly isn't, this
| is just an illustration on how to bridge the gap and make
| things available in a file system from the source of truth of
| your application.
|
| There is tons of more complexity to sandboxing, I agree!
| tptacek wrote:
| Wait, can you provide the positive definition for "sandbox"
| you're relying on here?
| Eikon wrote:
| For ZeroFS [0], I went an alternate route with NFS/9P. I am
| surprised that it's not more common as this approach has various
| advantages [1] while being much more workable than fuse.
|
| [0] https://github.com/Barre/ZeroFS
|
| [1] https://github.com/Barre/ZeroFS?tab=readme-ov-file#why-
| nfs-a...
___________________________________________________________________
(page generated 2026-01-11 23:00 UTC)