This is like saying that we should get rid of TCP because all we use is HTTP. Which, if it even made sense, would be a pretty bad idea.
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.
Sounds like he wants to just make the filesystem less transparent and handled solely by the application that uses it.
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".
I think that the current set of filesystem ops is a nice base. The "everything is a sequence of bytes" actually works very well given the access methods on a low level. However I think there are two separate things that need some serious addressing.
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.
We should also add transactions to file systems. Reiser4 also had some interesting ideas, like having aggregators, so that you could interact with e.g. /ets/passwd as one single file, or as a directory, where each record is one file. In a transparent manner.
Ignores the obvious benefit of the classical filesystem, which is that all data inherits an enormous amount of generic functionality from it: organization, interop, sharing, backup, versioning, etc.
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.
The original Palm Pilot had no file system. There were databases, which you could open and read/write records to/from. I feel it worked pretty well, but soon newer devices came out with so much more ram that it devolved into unusably long lists of databases.
Current filesystems and their hierarchical folder structures give an easy-to-understand layer of abstraction without a whole lot of complications.
The hierarchical filesystem was invented back when UI and API were the same thing and it hasn't moved past that.
You wouldn't tolerate a UI that was full of dangerous "system buttons" labeled with user-hostile jargon. You wouldn't use a user-entered mutable title field as an indexed unique key in a data schema.
FUSE is great but it abstracts the back end, not the interface. That's a seperate issue.
Platforms like J2ME with object persistence solve half the problem. Fast access to structured data is a breeze, but the user has no control.
All data is meaningful to the user at some level, even if it's as shallow as "Settings for the Blah app" or "The entire Blah app". If an object persistence platform forced all data to be wrapped in a user-meaningful container, which the user could manipulate atomically but not look inside, that would give you the best of both worlds. It would probably also encourage more modular and interoperable data design.
There is a lot of history to this sort of discussion. Windows 95 was supposed to have an "object file store" as was NeXTStep v4.0 ... I think the basic idea was you would have what we now call "tags" for each document you worked on; everything would go into a datastore similar to what we now call "NoSQL". A "soup" where you just pull out the document(s) you care about.
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.
You interact with your music via iTunes; iPhoto manages your photos. They can't trust third party apps to do the same, however, so they have the catch-all Documents directory. In fact, they can't even trust themselves. Apparently the iWork team doesn't talk to the iLife team much; iWork still uses the old school model: browse the filesystem to open a file and pick a folder and a name to save a file
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.
Another one of those disorganized people wishing the world can become disorganized as well so they can live in it.
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.
The problem is that adding structure to the default data means specialized APIs to access them. This is why a generic, object oriented data store would be very complex to maintain.
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.
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.