The idea that filesystems are not just a flavor of database management systems was always a mistake. Maybe with micro-kernels we'll finally fix this.
I’m a database guy, not an OS guy, so I agree, obviously… But what is the micro-kernel angle?
Show HN: VectorVFS, your filesystem as a vector database
11–20 of 150 posts
Re: Show HN: VectorVFS, your filesystem as a vector database
#12The idea that filesystems are not just a flavor of database management systems was always a mistake. Maybe with micro-kernels we'll finally fix this.
I’m a database guy, not an OS guy, so I agree, obviously… But what is the micro-kernel angle?
Likely the idea that filesystems should run as userspace / unprivileged (or at least limited privilege) processes which would make them, ultimately, indistinguishable from a form of database engine.
Persistent file systems are essentially key-value stores, usually with optimizations for enumerating keys under a namespace (also known as listing the files in a directory). IMO a big problem with POSIX filesystems is the lack of atomicity and lock guarantees when editing a file. This and a complete lack of consistent networked API are the key reasons few treat file systems as KV stores. It's a pity, really.
Re: Show HN: VectorVFS, your filesystem as a vector database
#13The idea that filesystems are not just a flavor of database management systems was always a mistake. Maybe with micro-kernels we'll finally fix this.
I can't agree with this. I like it that I can have all these tools which work with files and are tools which are not db-oriented, and the fact that there are different filesystems for different scenarios, that I can sandwich LVM between a FS and the block device. That /proc/ can pretend to be a FS because else we'd possibly end up with something like the Windows Registry for these operations, only managed through a database.
Would you store all your ~/ in something like SQLite database?
Re: Show HN: VectorVFS, your filesystem as a vector database
#14If VectorVFS obscures retrieval logic behind opaque embeddings, how do users debug why a file surfaced—or worse, why one didn’t?
Re: Show HN: VectorVFS, your filesystem as a vector database
#15this is actually a great idea
Assuming I understand it correctly, the idea is to be able to have LLMs get through file systems more easily with some interesting benefits to human users as well. The idea is interesting and I want to try it out.
Re: Show HN: VectorVFS, your filesystem as a vector database
#16The idea that filesystems are not just a flavor of database management systems was always a mistake. Maybe with micro-kernels we'll finally fix this.
Every single time this has been tried it has gone wrong, but sure.
Almost all of the operations done on actual filesystems are not database like, they are close to the underlying hardware for practical reasons. If you want a database view, add one in an upper layer.
Re: Show HN: VectorVFS, your filesystem as a vector database
#17If VectorVFS obscures retrieval logic behind opaque embeddings, how do users debug why a file surfaced—or worse, why one didn’t?
[deleted]
Re: Show HN: VectorVFS, your filesystem as a vector database
#18The idea that filesystems are not just a flavor of database management systems was always a mistake. Maybe with micro-kernels we'll finally fix this.
You could do a loopback network filesystem and make any user-space FS you want. That's what WSL does, and there's a Rust crate for it. Can't recall the name at all.
Re: Show HN: VectorVFS, your filesystem as a vector database
#19Files-as-vector stores is LanceDB's value proposition. How do you compare in performance, etc.?
Re: Show HN: VectorVFS, your filesystem as a vector database
#20The idea that filesystems are not just a flavor of database management systems was always a mistake. Maybe with micro-kernels we'll finally fix this.
Every single time this has been tried it has gone wrong, but sure. Almost all of the operations done on actual filesystems are not database like, they are close to the underlying hardware for practical reasons. If you want a database view, add one in an upper layer.
BeOS got it right with BeFS. An Email client was just a folder. MP3s could be sorted and filtered in the file system. https://news.ycombinator.com/item?id=12309686