Sure. It just fails to be atomic. Which is a property I really like.
Your File System Is Already A Graph Database
71–80 of 85 posts
Re: Your File System Is Already A Graph Database
#72Earlier quoted context omitted.
If it has hard or soft links, its a proper graph.
On Linux at least, hard links can't be made to directories, except for the magic . and .. links. So this only allows for a DAG. Symbolic links can form a graph, and you can process them as needed using readlink etc. to traverse the graph, but they'll still be considered broken if they form a cycle.
I guess technically you could do bind mounts but that's messy
Re: Your File System Is Already A Graph Database
#73I will always be in awe of people who can remain diligent doing this level of journaling/personal information management.
I've got scraps of paper and legal pads and post-it notes and just throw them away after they've been sitting around for a while and I forget what they are about.
Re: Your File System Is Already A Graph Database
#74Earlier quoted context omitted.
> I use dir trees for code ofc, but everything else is flat in my ~/Documents. Which is great, but on all major OSes you'd eventually hit performance issues with flat directories like this. Might not be an issue in month one, or even year one, but after 10 years of note taking/journaling that approach will show the issue with large flat directories. So eventually you'd need to shard it somehow, so might as well start…
If it's just performance, cd ~/Documents && mkdir old && mv ./* old/ (or today's date instead of old). I actually have that layout on one PC. If real organization is needed, seems like that'd be easier in hindsight than having foresight
So then you have one intentionally slow directory ("old/" in this case) and one fast directory?
Personally I'd categorize stuff, but you do you, there really isn't any wrong way to do it, if it works it works :)
Re: Your File System Is Already A Graph Database
#75Earlier quoted context omitted.
If it's just performance, cd ~/Documents && mkdir old && mv ./* old/ (or today's date instead of old). I actually have that layout on one PC. If real organization is needed, seems like that'd be easier in hindsight than having foresight
So then you have one intentionally slow directory ("old/" in this case) and one fast directory? Personally I'd categorize stuff, but you do you, there really isn't any wrong way to do it, if it works it works :)
I meant you mv into old before it gets too big. I've never actually seen a dir get slow like this. Only seen that with programmatic things like making 1M json files.
Re: Your File System Is Already A Graph Database
#76Earlier quoted context omitted.
His argument is that the LLM is the query engine. By that logic you can approximate anything since LLMs can.
Indeed, what is the point of links/edges when the llm can figure out the relations by itself?
>what is the point of links/edges when the llm can figure out the relations by itself
Making it work less, faster, and saving tokens. Duh!
Re: Your File System Is Already A Graph Database
#77I keep harping on this, but the question is not "can you use your filesystem as a graph database" - of course you can - but whether this performs better or worse than a vector database approach, especially at scale. The premise of Atomic, the knowledge base project I'm currently working on, is that there is still significant value in vectors, even in an agentic context. https://github.com/kenforthewin/atomic
Cool project.
thanks for checking it out!
Re: Your File System Is Already A Graph Database
#78I thought he was gonna talk about inodes: https://en.wikipedia.org/wiki/Inode
Maybe someday someone will expose these in the form of a graph database API (just for fun).
Re: Your File System Is Already A Graph Database
#79Earlier quoted context omitted.
On Linux at least, hard links can't be made to directories, except for the magic . and .. links. So this only allows for a DAG. Symbolic links can form a graph, and you can process them as needed using readlink etc. to traverse the graph, but they'll still be considered broken if they form a cycle.
Considered broken by what?
As in, they'll appear highlighted as broken symlinks when running `ls` with colour enabled (or at least it's so on my system).