

Death to Filesystems - mrshoe
http://shoptalkapp.com/blog/2010/1/18/death-to-filesystems

======
kmod
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.

------
stuartjmoore
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".

------
sophacles
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.

~~~
eru
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.

------
extension
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.

~~~
fragmede
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.

For improvements on the hierarchical part, the expansive list of filesystems
using FUSE
([http://sourceforge.net/apps/mediawiki/fuse/index.php?title=F...](http://sourceforge.net/apps/mediawiki/fuse/index.php?title=FileSystems))
has some interesting filesystems.

Maybe the author can find some likable ideas there?

~~~
extension
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.

------
patrickgzill
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.

~~~
mwcremer
Newton had soups:

<http://en.wikipedia.org/wiki/Soup_(Apple_Newton)>

<http://www.dadhacker.com/blog/?p=948>

------
there
_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.

------
mwcremer
Counter-point

[http://diveintomark.org/archives/2006/06/02/when-the-
bough-b...](http://diveintomark.org/archives/2006/06/02/when-the-bough-breaks)

~~~
misuba
Counter to a different point entirely. You can stop making users deal with
hierarchy without being closed.

------
sarmad
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.

------
Aegean
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.

------
JoachimSchipper
The author is right that the filesystem is not always the best solution.

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

------
jpwagner
the article he links to on "horizontal organization":
[http://www.structuredprocrastination.com/light/organization....](http://www.structuredprocrastination.com/light/organization.php)

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

