>>14642>But we can move back towards letting one program "do one thing well" by letting more then one program access a datastructue at once.>Something that block files don't allow.
Well, more accurately, something that the hardware doesn't allow.
The filesystems you're talking about reflect how the underlying hardware works
(i.e. by organizing clusters of bytes into sectors).
Sure, you could have a more sophisticated abstraction (e.g. what you've described), but
so long as people can access their files, there isn't much motivation (especially considering
what you're talking about would mean scrapping quite literally hundreds of thousands of lines
of functioning code).
Of course, if you were to come up with some compelling, killer feature(s) that couldn't possibly be
implemented with current filesystems, that would be a slightly different story (although this would
almost certainly be implemented as a new layer on top of the current stack, kind of like how
the X Window System tacked graphics onto an operating system written for line printers).
Also, this:>>14963>But this has a whole bunch of problems. Json files don't have space between the bits, so you have to recreate the file every time you make a change. You can't just append to a list without recreating the entire file.
Is not nearly as bad as you make it sound. Kernels in general are very, very, very smart about handling I/O, and, of course, nobody is
going to try to commit every change to disk as soon as it happens; Ancient Programmer Wisdom tells us that storage (including SSDs)
is slow, and memory is fast.