I've always been interested in the concept of using the filesystem more thoroughly like this, but sometimes I wonder about the value of it, and if pulling on that thread could get us something even more interesting.
The S3 call is tooling over an already lower level operation - an HTTP PUT request. The function tooling is added /because/ it makes it easier to call correctly. You could choose to use the underlying HTTP request directly if you wanted to. The function approach may add type safety and additional client-side validation/logic that can't be expressed in the underlying API (HTTP or FS).
In some ways we can think about the FS as an RPC mechanism with service/resource discovery (LIST operations) and a fixed/limited set of functions (READ, WRITE, SEEK, etc). Perhaps a more interesting 'universal interface' would be a broadly supported RPC mechanism with the FS operations as an adoptable interface that any given resource could support. That way an S3 implementation could choose to implement the FS interface if it wanted to, and an AI agent could discover the additional functionality offered by the other interfaces it supports. Probably a pipedream .
The Polymorphic Identifiers and storage combinators of Objective-Smalltalk do exactly this.
(not sure why the certificate expired...will have to check up on that.)
This is core to plan9's "everything is a filesystem", a generalisation of Unix "everything is a file" and surprisingly a direct analog of Sun Spring OS RPC+Namespace model
No exactly! You’re describing a microkernel and a bunch of userspace servers. Look into Fuschia, Mach, or Android’s Binder if you’re interested it this
I may interpret this wrong, but the 9p protocol describes transfer protocol operations not data structure.
This project replaces those with RESTfull (CRUD?) operations. But this repository also seems to define what 9p does not, the structure of the data. It defines what files to write to and what to write to them. That seems outside of the 9p scope as you are defining the service behind the transfer protocol.
A RESTfull API to attach to a 9p backed does seem useful since the support for RESTfull API's is so huge. To me it's unclear how this monolithic approach is beneficial above a "RESTfull to 9p" proxy and a 9p service.
People building these Rube Goldberg contraptions: Do you actually run evaluations if this is any better at all than eg. giving it access to a Python REPL, or just toughing it out with random tools composed via shell scripts?
Why would an LLM be better trained to access Redis via a FS vs. a native library API?
Makes no sense.
> Why would an LLM be better trained to access Redis via a FS vs. a native library API?
Limiting the potential blast radius.
If you give an agent "access to a Python REPL" (your words), you're giving it access to all of Python. i.e. you're paving the road to your own destruction when the agent goes awry. In the case of a Python interpreter, you're basically handing it an eight-lane highway upon which all sorts of pile-ups and havoc can happen.
By limiting its access to specific operations via well-defined endpoints (which is what the AGFS approach is), you're trimming that eight-lane highway back to a bicycle path.
That didn't answer or reply to the original question... Security is orthogonal to performance.
My question was, how is the performance better? (as implied by the word evaluations)
(also the original post was about exposing all sorts of random ops via a file system which are accessed via general shell tools most of the time, so pretty likely there's basically zero added security...)
then again with plan9 namespaces it's trivial to build sandboxes.
I've always been interested in the concept of using the filesystem more thoroughly like this, but sometimes I wonder about the value of it, and if pulling on that thread could get us something even more interesting.
Take this, for example:
> s3.put_object(bucket, key, data) -> cp file /s3fs/bucket/key
The S3 call is tooling over an already lower level operation - an HTTP PUT request. The function tooling is added /because/ it makes it easier to call correctly. You could choose to use the underlying HTTP request directly if you wanted to. The function approach may add type safety and additional client-side validation/logic that can't be expressed in the underlying API (HTTP or FS).
In some ways we can think about the FS as an RPC mechanism with service/resource discovery (LIST operations) and a fixed/limited set of functions (READ, WRITE, SEEK, etc). Perhaps a more interesting 'universal interface' would be a broadly supported RPC mechanism with the FS operations as an adoptable interface that any given resource could support. That way an S3 implementation could choose to implement the FS interface if it wanted to, and an AI agent could discover the additional functionality offered by the other interfaces it supports. Probably a pipedream .
The Polymorphic Identifiers and storage combinators of Objective-Smalltalk do exactly this.
https://objective.sthttps://dl.acm.org/doi/10.1145/2508168.2508169
https://dl.acm.org/doi/10.1145/3359591.3359729
(not sure why the certificate expired...will have to check up on that.)
This is core to plan9's "everything is a filesystem", a generalisation of Unix "everything is a file" and surprisingly a direct analog of Sun Spring OS RPC+Namespace model
No exactly! You’re describing a microkernel and a bunch of userspace servers. Look into Fuschia, Mach, or Android’s Binder if you’re interested it this
I may interpret this wrong, but the 9p protocol describes transfer protocol operations not data structure.
9p defines filesystem operations: attach, walk, open, create, read, write, clunk, remove, stat. And some additional handling operations: version, auth, error.
This project replaces those with RESTfull (CRUD?) operations. But this repository also seems to define what 9p does not, the structure of the data. It defines what files to write to and what to write to them. That seems outside of the 9p scope as you are defining the service behind the transfer protocol.
A RESTfull API to attach to a 9p backed does seem useful since the support for RESTfull API's is so huge. To me it's unclear how this monolithic approach is beneficial above a "RESTfull to 9p" proxy and a 9p service.
People building these Rube Goldberg contraptions: Do you actually run evaluations if this is any better at all than eg. giving it access to a Python REPL, or just toughing it out with random tools composed via shell scripts?
Why would an LLM be better trained to access Redis via a FS vs. a native library API?
Makes no sense.
> Why would an LLM be better trained to access Redis via a FS vs. a native library API?
Limiting the potential blast radius.
If you give an agent "access to a Python REPL" (your words), you're giving it access to all of Python. i.e. you're paving the road to your own destruction when the agent goes awry. In the case of a Python interpreter, you're basically handing it an eight-lane highway upon which all sorts of pile-ups and havoc can happen.
By limiting its access to specific operations via well-defined endpoints (which is what the AGFS approach is), you're trimming that eight-lane highway back to a bicycle path.
That didn't answer or reply to the original question... Security is orthogonal to performance.
My question was, how is the performance better? (as implied by the word evaluations)
(also the original post was about exposing all sorts of random ops via a file system which are accessed via general shell tools most of the time, so pretty likely there's basically zero added security...)
then again with plan9 namespaces it's trivial to build sandboxes.
Why are you upset?
(I'm not upset at all, I'm confused.)
More LLM focused crap.
[dead]