Death to Filesystems

What exactly is this guy arguing for? How is the OS supposed to "make higher-level APIs like these"? It seems like he hasn't completely thought through his suggestion: he's saying that we should move the filesystem into the OS and then hide it. Ok that's probably fine if you're not doing anything serious and all you need are ints and dicts. But what about a database? The only way the OS can provide a database abstraction is by taking over database functionality from applications.

And I'm pretty sure that exactly not what we want, and why the original designers decided to go with flat byte streams rather than structured data on disk. Yes, maybe you don't work at the level of abstraction of files and bit streams. But someone has to! The author is suggesting making that impossible except inside the OS...?

I think instead of "Death to Filesystems", the author should have made the claim that we should produce and standardize an abstraction level above the FS, and then everyone should start using it (which is a valid and very justifiable suggestion). As is, this post has come off as unreasoned.

It's nice, and user friendly, until you want to switch. One of the reasons the Mac vs. PC debate is almost moot is because of how easy it is to move from one to another. A JPEG is a JPEG, no matter where it is. A folder of JPEG files can move back and forth no problem. But moving from iPhoto to Picasa on a PC? Not so easy, esp since you may need to write a specific routine to handle each programs individual "filesystem".

First is lack of metadata intrinsic to the system. A lot of filesystems have such capability, but there are no standard APIs to access it. I think that if a standards body (cough POSIX cough) were to distill out a minimum set of searchable metadata functionality, a lot of fun could arise.

The other part is the file metaphor itself. This leads to a lot of focus on moving, and putting, and copying. There is a largely under-utilized bit -- linking. We tend to associate filesystem trees with their paper counterparts, hence the above focus. However, with ln, you can create multiple hierarchies for the same set of files, organizing them different ways. Similarly this doesn't allow for easy reasoning about things like unionfs.

All that being said, I don't thing this calls for a removal of the stream of bytes notion of files, in the end, such a thing pretty necessary. A good api/file format on top of the stream of bytes solves the problem just as well.

File systems don't need to die, they need to grow up and provide the things that apps always have to implement over top of them:

- user-centric interface that shows data in a way that makes sense to them: documents, apps, messages, contacts, etc.

- non-hiearchal structure, views based on search, filter, sort

- database-like performance and semantics e.g. indexes, transactions

- structured data that is trivial to load/save from any programming language

I believe that all this can be had while preserving the benefits of flat files, but it's an enormously ambitious undertaking and the only sort-of-attempt that I'm aware of (WinFS) never even shipped, let alone caught on.

Earlier discussions on this subject usually got into ideas like "pointer swizzling", virtual memory management, mmap'ing such files, etc. as the way to actually implement such a document store was considered.

when you add music to itunes, you keep it around for a long time and it doesn't really move out of itunes. when you add pictures to iphoto, you import them from your camera and they stick around forever.

when you work with word documents and spreadsheets, they don't stick around forever. they're stored on a network drive at work, or a usb drive, or opened once from an email attachment, and are gone as soon as they came.

surely some "favorites" or "bookmarks" can be made to reference documents used commonly (which these applications and file open dialogs already support), but i'm sure the usage patterns of these "work" applications dictate keeping the filesystem hierarchy. i'd rather apple stick with what is appropriate rather than change it just to unify everything.

http://diveintomark.org/archives/2006/06/02/when-the-bough-b...

Face it, hierarchical file systems have been around for decades, and if this proves anything, it proves that hierarchical file systems are successful and are the way to go. If there is anything we need to change in file systems then it's things under the hood, i.e. speed it up, prevent fragmentation, etc.

While fundamentally necessary, files are not the answer to everything. There are designs such as file attributes to cater for file metadata. I suggest reading on ReiserFS ideas.

Filesystems have to be there though. They are complex and have done a good job at hiding the complexity such that people like the original poster may even start to think they're unnecessary.

There is a reason, after all, that *nix has shipped some dbm variant basically forever. Or that SQLite is pretty popular nowadays.

this is absurd. "horizontal" should be replaced with "no".