The problem I have with almost any computer system--from interfaces to libraries, programs to operating systems, databases to media players--is that I want to redesign it from the ground upwards. I don't think it's that I'm a perfectionist, more that I often feel that there are some obvious design flaws that probably ought to have been rectified at the time of development but are now just here to stay.

When I get most worked up about how I'd change things, I generally go right back to the operating system level. Building an entire operating system is a very difficult art, and you can't do it effectively by yourself, though it's possible to build an entire play system by yourself from scratch, and there are many Linux From Scratch type projects if you don't mind mainly reusing all of the parts. I'm interested in that, but not for this purpose: I'd like to rethink some of the obvious and less involved components such as files, and interaction therewith. The good thing about that is that you can simulate new designs at a much higher level.

So, the fundamental point of bryte: lately there is an increasing trend towards non-hierarchial, database backed filesystems. ReiserFS now enables metadata attributes for files--BeOS had done that years before--and projects such as GNOME Storage are well underway even providing NLP interfaces to data, which is all very promising. But the idea I had was what if we extended this to files themselves? Files can be thought of as hierarchial arrangements of bytes, just as current filesystems are hierarchial arrangements of files. They're pretty flat too, since they're just one-dimensional sequences. You have a series of bytes, 0 to n where n is between 0 and roughly the size of the disc or whatever the filesystem can manage, so you always know that byte 1, if it exists, follows byte 0. People don't tend to wonder what would happen if files could branch: what if both 1a and 1b followed 0? What if files could be composed of multiple loops? Why would we want this? Too much power?

Now, the introduction I've just given is rather contrary to one of my design principles, which is to avoid waxing theoretical when you've got a plethora of use cases that you ought to be seeing to first. Experimentation is always fine since there may be unexpected benefits that you didn't see, but the main point of my gedankenexperiment above is just to introduce the level of assumptions that I'd like to challenge in order to (possibly) find improvements to filesystems that can be prototyped.

@@ distracted, as usual