
Files and folders - ukd1
http://jansen.co/files-and-folders#
======
ebbv
This again?

Nonsense like this comes up every so often and it's always based on a myopic
and naive view of computing, and of the general public's use of computers.

File systems are necessary because files need to move between applications and
devices. File systems are already an abstraction, and they will continue to be
useful until someone comes up with a better one. Which, at this point, seems
unlikely.

Yes, your exposure to the file system on an iPad is much lower than on a
MacBook Air. But it's still present. Try saving an image from the web, an
email attachment, or using the Drop Box App. You may not be at a command
prompt but you're dealing with the file system.

The more complicated things you want to do with a tablet, the more you're
going to have to interact with the file system. A better abstraction does not
yet exist, so the file system persists.

Declaring its death prior to the appearance of a better abstraction is silly.

~~~
kunai
Exactly. Who the hell writes this? I'm 15 years old, possibly part of the
"generation" this author is referring to, and I _do not_ want my information
stored on remote servers that I have to access with high-latency and low-
throughput connections. I _do not_ want to launch an app to find one file I
can get to easily with search. I _do not_ want a curated application
experience.

All these things should be reserved for auxiliary machines like tablets. On a
general-purpose computing device such as a laptop or desktop PC, I do think
that file hierarchies will be deprecated, but they won't die completely.
Search will be king on the desktop, and eventually will integrate both locally
and remotely on the Web.

Cloud computing's uptake upshoot is ephemeral. Once it's gained as much ground
as it has to, the growth rate will stagnate and the cloud will plateau.

I don't see SaaS being successful much either.

~~~
zanny
Of note, even if you store your information remotely, it still makes more
sense to organize it in a file system. That photo app is best done with
folders and hierarchies, you organize your email in the same way, discrete
information is best organized in groups, and that is all a filesystem is.

~~~
JamisonM
I emphatically disagree on the photo app example. The only folders I use for
my photos is by date and the only reason I do so is because of the limitations
of the design of the computer on which those files are stored. Photos do not
particularly lend themselves to hierarchies - one person's "Family and
Friends" grouping might be arbitrary to someone else, that's why tags came
along - they add information instead of putting items in silos.

~~~
andrewflnr
I hope what makes the traditional filesystem obsolete is something with better
support for non-treeish data, including tags.

~~~
ori_b
A tag based file systems are equivalent to a hierarchy with symlinks (or
directory hard links). If you don't allow tagging of tags, it's equivalent to
restricting your hierarchy to one level.

Tags and directory DAGs are the same.

~~~
andrewflnr
True. Maybe we just need better interfaces for managing multiply-referenced
files.

------
kintamanimatt
The file system isn't going away.

Even when I'm in consumer mode I access the file system on my phone daily.
Maybe I've just transferred a file to my phone that I want to read. I'll look
in the appropriate folder where files that are transferred by Bluetooth are
saved, this being the easiest way to open such a file. Or perhaps I'll open up
the Dropbox app and use its pseudo-filesystem to find a file. I delete large
folders manually and I sometimes dig out a profile photo that Grindr cached if
I'm creating a new contact in my phone and don't want to forget who they are.

Also, the desktop isn't going to disappear, it's just going to be used in more
niche cases, like development, graphic design, and even gaming. Some people
just have a preference for that form factor, especially because it can be more
comfortable for longer stretches. For casual users? They'll probably just have
a laptop, a tablet (or a tablet with a decent keyboard), and a phone. People
love to consume on phone and tablets and create on laptops and desktops with
real keyboards. As long as a real keyboard is necessary true mobile devices
are going to be a supplement but not a replacement.

~~~
andybak
Files obviously aren't going anywhere as even document-based metaphors are
files by another name.

Folders? Well - maybe tags but hierarchical tags are essentially the same
thing as folders with one restriction relaxed (a 'document' can be in more
than one place). But removing them altogether is a step back to MS-DOS 1.0
with a single flat hierarchy and I don't see that helping anyone.

The desktop however - I'm not even sure what you mean.

A surface on which multiple overlapping windows are arranged? I don't think
overlapping windows is anything other than a Xeroc PARC-induced collective
mistake. I'd much rather have a tiling window interface of some kind.

The only thing left for the desktop to provide is some kind of launcher and
location for recently used files. It doesn't do a very good job of that when
combined with overlapping windows (they tend to be blocking the desktop most
of the time...) so I think that is something we can happily improve on.

~~~
kintamanimatt
Desktop = desktop computer. I put forward a counterargument to a point made in
the second half of the article regarding desktop computers.

Some people like tiling window managers, other people prefer stacking window
managers. I feel constricted by tiling windows managers which is why I don't
use them. I readily stack and deliberately overlap windows daily, and it's
part of my workflow. But, at least with a *nix based system you have your
choice.

Replacing folders with metadata would make it more unwieldy. Files and folders
are a familiar, logical, and easy metaphor that readily lends itself to a
graphical environment. Heaps of data (at least in the non-programming sense)
with excellent metadata is a second rate version of the former. It's been
proposed and tried many times with little success because it doesn't lend
itself to easy access of data, except when there are few content blobs
("files") in existence.

~~~
icebraining
_except when there are few content blobs ( "files") in existence_

Or many. Isn't that why search engines won to "directories"?

~~~
kintamanimatt
Well, no, they didn't.

Search engines are useful when you've got a haystack of stuff and you're
looking for a needle. They're particularly useful when you're looking for
something novel, usually an answer to a question. Often you don't know where
the content is and you probably didn't create it either. They have two
benefits: removing the tedium of hunting intelligently through an unknown
haystack for some content, and doing it faster than could be done manually.
They also come with the benefit of returning alternate results.

The file/directory model is useful when you know roughly (or exactly) where
something is. It's easier and often quicker to clicky clicky all the way to
your content than it is to describe what you're looking for, waiting, wading
through possibly irrelevant results, and then refining your query if you
didn't succeed first time around. This model also has the benefit of returning
related content (other files in the same directory), as opposed to alternate
results. It's for this reason the file system is going to live on, simply
because there are many daily situations in which clicking or tapping on
directories to get to a file is easier and perceptually quicker.

Both filesystems and search engines are useful in different scenarios, which
is why we use both depending on which is easier in a given scenario.

~~~
seanmcdirmid
Very few users are organization savvy enough to use deep hierarchies of
folders and files to organize their data. They are lazy and just throw it in
one place, relying on LRU caches (when new and active) and search (when old
and inactive) to find what they need.

Developers are quite a different breed from mass conventional users. We still
need file systems if only because we are more savvy enough to use it. Also,
our tools tend to be low level and file oriented.

~~~
kunai
Not quite; my parents both organize pictures into folders very well and
organize them by date and tag them with metadata. They don't do the same for
documents, but because every document of theirs tends to be unique, there
really isn't any need to.

Also note that these are the same parents who haven't the slightest idea of
what a kernel is.

~~~
seanmcdirmid
However, I bet your parents know what filing cabinets and floppy disks are,
while your kids most definitely do (or will) not! Pictures and music were also
some of the first content classes to be de-filed [1] with apps like iTunes and
iPhoto (the file hierarchy is still there, its just hidden from most users).

I think this is one of those rare cases where the future is just staring us
right in the face, like when Apple got rid of the floppy disk on the imac, or
when CD ROM similarly went away. It doesn't mean file systems die right away,
but they will become invisible to most users in one or fewer generations.

[1] A funny punny

------
Millennium
People have been saying this for years. I remember in 2003, when people whined
about how the nascent Mac OS X (as it was called at the time) still had a
concept of folders and files that needed to be in specific places. They wanted
to "keep everything in a database" instead, like BeOS (never mind that BeOS
also had files and folders in specific places; that was beside the point).

Ten years later, the filesystem hierarchy is still around. Nowadays, with the
Internet's hierarchical domains and URI paths, I don't think there's any risk
of it going anywhere. That notion of files in a space hangs around because,
simply put, it works. People know what files and folders are, and hardlinks
notwithstanding, they generally behave the way people expect them to. It's too
easily-understood to throw away, not matter how hard people try.

~~~
sliverstorm
The file system is just, IMO, too fundamental to replace. It isn't that we
haven't thought of alternatives- it is that there aren't any! Or, well, there
is one- a flat database, which is just a flat filesystem- but as soon as you
start using it, you will start wishing for some organization...

In summary: If you give a mouse a cookie...

~~~
foobarbazqux
The problem is that digital file systems are digital versions of the physical
file systems that we are all familiar with. Most notably these don't let one
file be in two folders at the same time. But our mental file system does work
like this. By this I mean that the same memory can be reached by multiple
routes. Couldn't you design a filesystem that was a flat database with file
metadata being used to both browse and search for files, thus avoiding the
need for tree hierarchies in current systems? Wouldn't this be closer to our
mental model? Crucially, could you develop software like this?

~~~
krichman
But you can (on Unix) put the same file in two places using ln[1].

1\.
[http://en.wikipedia.org/wiki/Ln_(Unix)](http://en.wikipedia.org/wiki/Ln_\(Unix\))

~~~
foobarbazqux
You're right, and good point, I didn't think about hardlinks or symlinks. I
guess you could do what I was suggesting by having one directory that contains
every file and then creating links to them in different folders.

~~~
Millennium
That's what a lot of filesystems do behind the scenes, especially Unix-style
ones.

------
saidajigumi
I'll agree with this observed trend. Colleagues of mine at a top-tier
university are already seeing this in students. They have "computing"
experience, but no real sense of the file system as an organizational and
navigational tool. This poses a question in my mind:

Are we creating a world of perpetual intermediate users?

I think there are definite advantages to reducing cognitive noise in "casual
computing" found in current mobile experiences. What's less clear is the path
individuals will take from this world of per-app organization into one where
content creation, workflow, and eventually implementation details increasingly
take precedence.

It's not enough to say "the king is dead" until we also have a way to add ",
long live the king."

~~~
devcpp
We could increase the productivity of humanity in fabulous ways if we all knew
how to use computers efficiently. Instead, we go the other way and only use
them as entertainment platforms. Too bad education doesn't make big money.

~~~
saidajigumi
> We could increase the productivity of humanity in fabulous ways if we all
> knew how to use computers efficiently.

I'll argue that's not the problem. The problem is more of nurturing a social
culture of continuous learning and creation. How many of us knew folks when we
were in school who just couldn't wait "to be done with school forever"? How
did that travesty, a vast failing of human education, come to pass? It's easy
to be elitist and point to those of us who dodged the bullets as being
"superior" or "smarter" or whatever, but I've also witnessed too many
occasions where good environments, mentors, teachers, etc. lit the spark in
learners who might otherwise have been judged unremarkable.

I've also seen (and apparently there are now studies on) the positive skill
effect of having access to computers-as-making-devices as a kid can have.
IIRC, this relates to a substantial part of the successes that Harvey Mudd
College is having in bringing more women into computing programs[1]. In short,
changing education to embrace students who didn't have "deep" access to
computers prior to college is helping to close the gender gap.

Mobile or no, I'll ask: do children have sufficient access, role-models, and
mentors regarding computers (mobile or no) as tools of creation? What does the
changing profile of computer use in the mobile era imply for education towards
computing-enabled professions?

[1]
[http://www.npr.org/blogs/alltechconsidered/2013/05/01/178810...](http://www.npr.org/blogs/alltechconsidered/2013/05/01/178810710/How-
One-College-Is-Closing-The-Tech-Gender-Gap)

------
kryten
Not this again. I've heard this argument recycled for the last 20 years.

You can't abstract everything away into nothing. At some point the meat sacks
(like myself) operating the devices will need to reach a compromise that the
machine agrees with too, much as the compromise that I must turn the steering
wheel and press the pedals on my car.

The filesystem is a pretty good compromise.

Denying its existence is another step towards our future of epsilon semi-
morons operating mindless consumption devices.

------
ars
I hate this concept - the app doesn't own the data.

Apps that assume they do are rapidly removed from any system I use.

There are some single purpose apps that have data directly tied to them, but
everything else is not like that.

~~~
cstross
The app developers _would like_ the app to own the data.

That this isn't in the users' interests should be self-evident. Vertical data
silos with doors owned by gatekeepers who want to charge admission: just say
no!

------
jimbobimbo
"Accessing data on their own terms"?

Like in terms "I created a silo of valuable data with some obscure app and now
stuck with this app"?

------
dsr_
Of course the filesystem will soon be obsolete! That's why it's called ext4,
to distinguish it from ext3, which came before.

Oh, you think you're going to store all your data in a soup, pulling out
collections of bits based on tags? That's a nice feature, and users may like
it, but it's going to be implemented as an extension to a hierarchical file
system. The same evolutionary pressures that guarantee we will have desktops*
in ten years mean that filesystems will still be here: they've been tested in
battle, and they continue to function in odd situations.

*Desktops: they aren't going away. People like large displays; people like accurate and reliable text entry devices; people like expandability and the ability to plug new stuff in. These are all things that desktops are much better suited to than laptops, tablets, or phones.

~~~
r0s
Totally agree about desktops.

Previous employer asked me if I wanted a laptop, but I prefer a large display,
keyboard, etc. with a big fast machine and lots of working memory. Ergonomics
are important to me, I have friends with permanent damage from poor posture.
To see people hunched over laptops makes me cringe.

~~~
Tmmrn
On a modern powerful laptop you can easily connect three 2540x1440 or bigger
resolution displays.

Keyboard and Mouse, obviously. Best to have them at an usb hub so you only
need to plug in one cable (or a docking station).

Fast is relative. There are laptops where you can put in 6 core Xeons, but
they are rather expensive. A modern mobile i7 quadcore or equivalent AMD CPU
is rather fast. Try it.

On a powerful laptop you can easily have 32 Gigabyte Ram. If you need more,
then you need a highend workstation, yes.

Poor posture doesn't need to concern you more than on a desktop PC if you have
your laptop connected to the same peripherals than you would have a desktop PC
connected to.

Laptops _additionally_ allow you to take them with you and work with bad
posture.

~~~
r0s
Well if you're going to put it on a desk and plug it into the wall... it's a
less powerful, less expandable, vastly more expensive desktop. You buy special
adapters for your extra screens/peripherals, and spend time with
setup/breakdown every time. I personally hate to share wifi with a dozen other
people in my office so I need yet another adapter for ethernet (some notebooks
have this, some do not).

When you unplug you lose all that equivalent experience, and then you're on
battery power... which sucks for powerful laptops. Working from a couch or
whatever just seems ineffectual to my workflow. I can see media consumption
working in that case, (not the latest games of course) but then you don't need
the big beefy machine.

I really don't see the benefit of portability for a workstation. It's a luxury
to me when I have _less_ things to haul around. For work everything is either
in off site backup or version control systems. Obviously that wouldn't work
for something like video editing.. but then (and I'm not an expert) you'd want
a bigass power hungry workstation anyway.

Regarding apple notebooks: Bluetooth keyboards are pretty much equivalent to
Macbook keys, so most of my co-workers would just use that. The apple mice
suck, so most would again use the notebook trackpad. External screens were
used as expanded desktops with most work happening on the default notebook
screen. Everyone was hunched over the laptop like it wasn't docked at all.
This is my own limited experience, but it seems that in practical use, the
limits of laptops somewhat encourage poor ergonomics.

~~~
Tmmrn
Yea, it's more expensive and not so upgradeable and you lose a few seconds by
setting it up.

The display adapters should be only a few dollars, so maybe not ideal, but
hardly a really good reason.

There's not really a reason why a powerful laptop should be really bad on
battery power. Modern CPUs save power pretty well, especially mobile ones. And
any powerful GPU should have the capability to be disabled.

But still, it's mobile or "mobile". As long as it fits in a backpack and I
don't have to hike for hours I really don't see the problem. Maybe laptops
today are not completely feasible, but I suspect in one or two generations the
successor to USB3/4/? will be capable of driving everything from screens to
external GPUs or CPUs so you'd only connect one cable and have everything
attached there. But that's not now. For me it's just a minor inconvenience for
the big convenience of having everything with me. And everything is not only
stuff I have synced or in a version control system (by the way, don't you have
that moments where you are somewhere and remember that the code you want to
access is on a machine dozens of kilometers away and you forgot to push it?),
but really _everything_ and everything exactly how I left it. It's just the
feeling that I can just suspend and go somewhere, no matter where, get my
laptop out and continue exactly where I left off.

------
mitchty
For average users, maybe. But as long as I have source files, scripts,
executables/etc.... I don't think the filesystem is going anywhere. The other
thing is even if people get used to the "new" way of doing things, the old way
won't go away entirely.

Look at guis versus command line. Most people never use the command line, but
that doesn't mean its gone, or obsolete. It has just moved to being an
advanced tool.

------
freyrs3
Completely sensational, file systems will continue to exist as long as we use
storage devices. The end-user interacting with the low-level interface may be
phased out though.

~~~
icebraining
I think the argument was purely about UI semantics. People here seem to be
missing the point completely, in my opinion.

~~~
freyrs3
Then the author is conflating the term "file manager" with "file system".

~~~
icebraining
But it's not just the file manager, it's the file themselves _as user
interface semantics_. Right now, the file system is more than just a data
storage layer, it's also a set of concepts (files, directories, etc) with
which the user interacts through almost all applications.

For example, when I click on a link to a paper, I'm not just viewing an
abstract document, I'm downloading and opening a PDF file, and this is exposed
to the user as the UI to manage the content.

OP is talking about the file system as that set of concepts, and claims
they'll be obsolete and mostly replaced by more abstract views of the content
we use.

~~~
freyrs3
> Right now, the file system is more than just a data storage layer, it's also
> a set of concepts (files, directories, etc) with which the user interacts
> through almost all applications.

A filesystem is an API for making system calls to deal with data access on
storage devices. It isn't necessary for a filesystem to have the concepts of
directories or even files. Look at Plan9 for instance. The word "filesystem"
is being overloaded to mean something more general than what it means in an
operating system discussion.

~~~
icebraining
_A filesystem is an API for making system calls to deal with data access on
storage devices._

Yes, and that API involves certain core concepts, like files (and usually
directories), which are exposed to the user. You open files, you save them,
you copy them. The UI semantics are almost a 1:1 mapping of the base API.

 _It isn 't necessary for a filesystem to have the concepts of directories or
even files. Look at Plan9 for instance._

I don't get your last point; Fossil has both, and as far as I know, the whole
core of Plan9 is that everything is a file, achieving what UNIX couldn't.

And how can a _file_ system not have files? The very definition of the word
implies the storage and/or retrieval of files. There are other data stores
which don't depend on a concept of files (e.g., RDBMSs), but they aren't
filesystems.

 _The word "filesystem" is being overloaded to mean somethng more general than
what it means in an operating system discussion._

I disagree; the author is talking about the filesystem, _as it 's exposed to
the user_. Sure, it's not the layer we usually talk about, but it's the same
base concept.

------
VLM
The article assumes people don't like tree structures. What if they do?

There's a good analogy with a programmer blog reporting he likes linked lists,
therefore B-trees are going away. Or I prefer the syntactic sugar of
recursion, therefore iteration will disappear in the future (or vice versa)

I will say nothing screams "silo" like hiding metadata from the end user. Oh
that plain ASCII text file, that can only be opened in MS Word of course
because its a "word file" because MS Word opens when I click on it.

~~~
Nelson69
A filesystem engineer/professor at a top-tier university told me once (well he
told a whole class of us) that hierarchy is the only mechanism that the human
brain has for dealing with complexity. A few people balked, they don't like
'trees' or what have you but nobody could come up with an alternative. This
was nearly 20 years ago and I still haven't heard of a better idea.

So what's a filesystem? It's a very good and very scalable data structure for
storing lot's of items. It's pretty good at lot's of little things and big
things a like and a bunch of sizes in between. This problem remains.

Then be it tags, folders, something else, it's all just hierarchy to find and
store your stuff in that data structure.. Where it looks like everything is
going is having multiple overlay hierarchies, all your songs are in the music
folder but then you tag different things to help you sort it out. Then maybe
the computer can figure out some more optimal ways to store stuff. Take those
fancy hybrid drives, maybe songs you don't play too often, there is no reason
they can't be in part of the filesystem that is on spinning media and not in
flash.

~~~
lesedilino
>hierarchy is the only mechanism that the human brain has for dealing with
complexity. A few people balked, they don't like 'trees' or what have you but
nobody could come up with an alternative.

None of you could think of anything better because you're engineers, not
psychologists or philosophers.

The "human brain" deals with complexity through:

    
    
      * causation
      * hierarchy
      * chunking
      * association
      * ordering
    

Complexity in general is managed using all the tools of analysis:

    
    
      * drawing distinctions
      * drawing similarities
      * making definitions
      * transforming concepts using other concepts
    

And this is all off the top of my head. It's been years since I took
psychology of memory and philosophy of mind. But suffice to say your "top
engineer" commenting on stuff outside his specialty and using the stupidity of
undergrads to bolster his amateur argument is not convincing and is a pure
expression of bathos.

------
freework
I'v been working on a non-hierarchical filesystem (if you want to call it a
"filesystem") called Library Transfer Protocol. It created a new type of file
called a "library item" which is different from a file in the sense that
library items are immutable. An image, a video, or a finished blog post can be
a library item. Since all library items are immutable, we don't have to worry
about the CAP theorem, and therefore the "filesystem" can be distributed. You
can see the code here: [https://github.com/priestc/Library-Transfer-
Protocol](https://github.com/priestc/Library-Transfer-Protocol) Click on the
presentation at the bottom of the github page to see more info.

~~~
dharmatech
This is very cool. Do you know of any other comparable systems or past work?
You mention in the presentation that WinFS is a similar system (I agree;
sounds similar in some ways).

------
MortenK
With a metadata based file system, the metadata must describe the content in a
variety of ways for content to be searchable. Problem is until computers can
understand what a certain document is automatically, it's up to users to
manually categorize or tag each one, which is hugely time consuming. Better
approaches than the hierarchal file system has been researched for decades, so
far with no clear breakthroughs in sight.

------
abruzzi
The first think I think of when somebody (usually a developer trying to
predict the future) says the file system is going away, is:

So, without a file system, how do you organize the Linux kernel code? Or the
WebKit code?

The reality is the lack of a front facing file system (like iOS, even thou
there is still a file system down there) would probably work for 80% of users,
but what do the rest of us do? And the reality is that 20% are developers,
music editors, video editors, enterprise, and similar types of users where not
having the file system isn't an inconvenience, but a show stopper. I'm in that
20% for some of my uses, and I'll say that my #1 complaint about my ipad
(which I love) is the lack of a file system.

~~~
seanmcdirmid
One could build a development environment that was not dependent on a
filesystem for code organization. Actually, its been done at least once with
Smalltalk's class browser and persistent images. Also, music and video editors
really only care about their content, not fancy directory structures.

I've never wanted a filesystem for my ipad. What use would it be?

~~~
aidenn0
I don't own an i{Pad,Pod,Phone}; how would you (for example) open up an MP3 in
a music editor, make some changes, and then open up the same MP3 in the music
player?

The solution on the desktop is to give it a unique identifier in the form of a
hierarchical filesystem.

~~~
seanmcdirmid
This is a really niche use case, but let's try anyways since you can do it
with Garage Band [1].

Music exists in its own data space on iOS organized by artist, genre, album,
and so on...you know...what the user wants for playing music. Now, this
definitely wouldn't work very well for meta-data free content...but how many
users deal with data that lacks meta-data? File system path is just one
awkward form of meta-data that they could manually specify.

[1] [http://www.midnightmusic.com.au/2012/08/how-to-get-
garageban...](http://www.midnightmusic.com.au/2012/08/how-to-get-garageband-
songs-off-your-ipad/)

~~~
aidenn0
Separate viewing and editing applications isn't _that_ rare; perhaps every
single example of it is niche, but in aggregate I'm not convinced it is.

What you have described is just a non-hierarchic file-system which has been
tried in the past; it is possible that the time has finally come for it
though. Some issues are that a general-purpose one is much harder than a
special purpose one (e.g. music only) and getting vendor buy-in has been hard.
Apple is in a position to force vendor buy in so it will be interesting to see
how things play out.

------
batbomb
The file system isn't going anywhere. The file system as we know it is almost
effectively an extremely partitioned index organized table of BLOB
information, which actually makes it more efficient when handling permission
than a database would likely be. Without this hierarchical structure,
permissions are nearly a nightmare to go through with.

Furthermore, a database can also be implemented in a way similar to a
hierarchical file system, and in many cases have much more flexibility as you
get virtually unlimited extensibility (often at a cost of performance).

Additional layers built on top of filesystems will make the _way we interact
with files obsolete_ , but the file system will not become obsolete.

------
KaiserPro
But that assumes that the "app" is able to manage its assets competently.

the iphone deals with assets that lend themselves to simple organisation.
Photos work quite well as tiles, Contacts in name order. But what about text
files? How do I move from one product to another if it doesn't have a "export"
function.

If we go down this route, we are going to end up in the bad old days of lots
of small incompatible app with no way to share between them.

Its great while its still hip and fashionable, but what happens when everyone
stops using it? Whatsapp, voxer are a good example, how do I get my messages
out of that service?

------
jackmaney
Complete and total FUD. Desktops and laptops--which are merely older form
factors of the tablet, mind you--will be around for a long, long time. And
rooted phones and tablets will allow file system access. Hell, I regularly use
the file system in my (non-rooted) android phone.

~~~
icebraining
I don't think that have some kind of backdoor access to the underlying
filesystem makes it incompatible with the argument. The argument is about
normal UI and workflow, not implementation details.

Besides, the author is talking about _content_ , and what if that's stored
online? There's no files except for the server sysadmin.

And no, the fact that you and I may continue to use it is not an argument
either. The claim is "obsolete", not wiped from the face of the Earth.

------
MichaelGG
This is exactly the idea Microsoft had and demo'd at PDC 2003. Longhorn's
WinFS was supposed to deliver all this metadata searching and so on,
presenting a unified interface.

Also, as far as extensions, Windows has been hiding them forever. Because you
don't need to know the extension - that has nothing to do with the filesystem,
that's just because extensions became the standard way many systems decided
which app to associate with a file.

~~~
WalterGR
_This is exactly the idea Microsoft had and demo 'd at PDC 2003. Longhorn's
WinFS was supposed to deliver all this metadata searching and so on,
presenting a unified interface._

It is. It's a pity that WinFS never hit 1.0.

Interestingly, though WinFS was one of the "pillars" of the ill-fated
Longhorn, it didn't die with it. The team existed until 2006, and even
released a beta and a beta refresh. I was on the team, and most of us got
moved en masse to SQL Server. That was a heart-breaker.

The team's blog is still on the web:
[http://blogs.msdn.com/b/winfs/](http://blogs.msdn.com/b/winfs/)

I haven't kept up with Microsoft's post-WinFS storage initiatives, but it
sounds like Microsoft Semantic Engine may be keeping the spirit alive.

~~~
dharmatech
Question about WinFS. I saw a video presentation of it floating around the
web. They demonstrated various kinds of objects representing contacts,
documents, music files, etc. Where these object types extensible? I.e. were
the metadata fields static? For example, if the "song" type had the standard
fields (title, artist, album, year, etc) could I add another one (e.g.
"producer")?

~~~
WalterGR
_Where these object types extensible?_

Yes.

 _I.e. were the metadata fields static?_

Well, yes, but that doesn't preclude extensibility.

In WinFS terminology, object types were called Item types; object instances
were called Items. From the docs: "An item is the equivalent of an object in
object-oriented programming. It has a complex structure, specific behavior,
and operations described by the 'WinFS' schemas."

So one way to extend an Item type was to create a derived type (i.e. use
inheritance.) WinFS also supported what it called item extensions, which were
basically "small objects" that you could associate with existing objects. They
were for things like reminders, which don't mean much on their own and could
apply to many different Item types.

For your scenario, creating a derived type would probably have been the right
solution.

EDIT: Well, now that I think about it, what if every different music app
created its own Song subclass? So inheritance might not be the right choice.

Ahh, that's the kind of thing I deeply love thinking about! I hope that one
day I can rejoin the ranks of the lab-coated guardians of epistemology. (Nod
to "Metacrap: Putting the torch to seven straw-men of the meta-utopia" by Cory
Doctorow.
[http://www.well.com/~doctorow/metacrap.htm](http://www.well.com/~doctorow/metacrap.htm))

~~~
dharmatech
Thanks for the info!

What's your opinion of file-tagging systems like Tabbles and the new file
tagging feature in OS X finder? Tabbles is a far cry from full WinFS, but it
enables some interesting organizational techniques. I've been using it lately
and I like it. But tags don't always seem to be enough. In addition to tags,
I'd like to have genuine fields.

Seems like a NoSQL database would be a decent core for a poor-man's WinFS
implementation.

~~~
WalterGR
_What 's your opinion of file-tagging systems like Tabbles and the new file
tagging feature in OS X finder?_

Actually, I haven't been keeping up with new tools and techniques for
information management since WinFS died.

I took a look at the Tabbles website and watched one of the videos. It seems
good! You're right, it's not full WinFS, but with hierarchical tags you can go
a long way towards manually solving some of the same problems. I'll have to
take it for a spin.

I just did a quick Google search for OS X 10.9's tagging. It looks like it
doesn't support hierarchical tags? If it doesn't, then personally it's a non-
starter.

(I'd dig in to them more, but I have to be brief: I'm not sure when HN
disallows new replies to comments...)

 _Seems like a NoSQL database would be a decent core for a poor-man 's WinFS
implementation._

Prior to joining WinFS I was working on my own solution to kind of the same
thing as WinFS. I was going to use a traditional RDBMS - Perforce, actually.
In retrospect, I was basically looking to serialize a graph to/from the
relational model. At that time, I don't think I knew graph databases existed -
I'm definitely going to look into them when I pick up the problem again.

NoSQL + graph database? That could be very interesting.

In re. your other comment: Thanks for the link! I'll take a look at that.

 _If you love thinking about this sort of stuff, maybe you should get back
into it! :-)_

It's dangerous! One day I'm focusing on solving specific use cases, and the
next I'm a hermit in the woods asking, "What does it mean to _mean_?" ;)

But, you're right. For several years I've been working on self-employment,
with the goal of being self-sufficient so I could devote my time to solving my
"forever" problems - the #1 problem being this one. That didn't work out, so
I'm on the job market. This thread has re-inspired me. Maybe I can find a
position solving these problems full-time. That would be great.

It seems like you're interested in the same problem space? Definitely hit me
up via email: waltergr@gmail.com

------
Spooky23
This argument sort of has water because of the improvements in search. Look to
email as an example -- you have filers (ie people who maintain filing systems)
and pilers (people who use search for everything). Big inboxes and GMail made
piling popular.

Piling is the easiest way to operate, because many workers don't have a
natural filing methodology to use. Search fills the gap and lets you organize
on the fly based on standard metadata and content.

But depending in what you do, it breaks down quickly. If you are an attorney,
or a procurement agent or a project manager, you have a natural organizational
unit for content: the case, purchase opportunity, project. It's easy and
natural to break down information within the structure that you work with.
It's also hard to search for... How do you search for a NDA regarding case A
signed by party B?

Typically people predicting the death of folders are selling a solution that
doesn't lend itself to using folders. The author in this case is the founder
of a photo organization startup. This _is_ a use case where folders aren't
cutting it, digital photography created this situation wherr we're all
drowning in photos that are impossible to organize manually.

------
abelardx
How many kudos are from people who just wanted to see what the icon did?

~~~
jack-r-abbit
Oh that is sneaky. what a shitty thing to do. one of those kudos is mine now
and I am so NOT wanting to give this trash kudos. :(

EDIT: Looks like all the sites built on svbtle do that. What kind of jack-ass
"feature" is that?

~~~
to3m
He has a twitter account, so you can do what I did and tell him not to count
it :)

------
thenilly
What about the people who create content? Sure the consumer doesn't care but
what about the sound engineer, the digital artist, the film maker, the
architect?

------
stormbrew
The end of hierarchical storage has been heralded for as long as I can
remember. I doubt it'll ever happen. It's not like it was an abstraction we
were forced into by computers; hierarchies dominate every aspect of real world
information storage, digital or otherwise.

------
foobarbazqux
The conclusion here that the file system will soon be obsolete is overstating
the argument. A more accurate conclusion, in line with the rest of the
article, might be that the file system will soon no longer be directly
accessible by non-developers.

------
jiggy2011
The filesystem provides structure, even if it's not the perfect structure.
When I start a new project the first thing I do is create a folder and put
everything related into the folder.

What the filetypes are isn't important, it's the logical grouping of "things"
in a tree structure which is easily understood. If I zip and email that folder
then I know I have got the whole project.

Having a big gallery of every single image file on my computer isn't that
useful. Maybe I can break them down into galleries, but then do I have to tell
my other applications which gallery corresponds to which project?

~~~
incongruity
Exactly.

The counter to that (as discussed in this post) is that you can _just search_
for documents based on keywords, etc. which can definitely work well in many
cases – but I don't believe it is (or has to be) an either-or. Searching is
not infallible either - at least not until search becomes semantic and _truly_
smart, lest I misremember crucial keywords, substituting a synonym (or any of
a number of examples).

It's been my experience that organization becomes essential when tasks become
complex. This goes beyond computers. This is the case with human systems or
physical objects. I think the same goes here. Mobile devices have largely been
about consumption or simple creation, with simple workflows. To me, it's an
open question of whether or not their current interaction and organizational
scheme can hold up as content creation gets more complex.

~~~
jiggy2011
Keywords is an option, but then again if I send someone else my files what
happens if there is a keyword conflict on their system? So we need namespaces
or a way to track file origin/ownership across the entire planet? urgh.

Of course filesystem aren't the only way to organise data and there are
applications that already do this. An example that springs to mind are
playlists and media libraries.

The file/folder hierarchy is also pretty well ingrained in the web.

------
hadem
The apps the author speaks of uses the file systems he claims will soon be
obsolete. Maybe some enjoy not having to organize their data but I prefer
having access to decide where my files are stored on my system.

------
gryphon65
Whenever I see a post like this I think it's circling around a different
problem. It would seem that the overall task or project that a person is using
the computer for in a particular moment is important but there is no modern OS
(that I know of) that keeps track of this context.

Such a system might be a sort of metadata API for tasks or projects. The
system would have a built in task tracking application that would interface
with this API. (Which could be pluggable) The metadata for a task could hold a
lot of information. For example a default directory where files for the task
are stored could be created when the task is created. Other applications like
a word processor could query the API to find out where to store its files. Web
browsers could store what pages a user looks at for a task. E-Mail clients
could offer the current task as a folder to store messages in. When the user
switches tasks the currently open applications would be messaged and could
open files the user had open when they were perviously working on that task.
Finally when a user marks a task as completed all the files and messages
related to that task could be archived together.

For the novice user of this system things like the file system go away. Their
view is the projects that they are currently working on. The file system will
still be there under the covers but user doesn't need to see it. The power
user might have tools for developing common project workflows.

~~~
marcosdumay
From their early documents, it looks like the KDE4 developers got out to
create exactly what you describe. But they created something with very little
semblance with this. What you describe is hard, and may not be possible to
define well enough for implementing. It's good to know that some people try
it, maybe someday somebody will get there.

But, anyway, no you'll still need a filesystem to organize the data you use on
each task. Do you use only one level of directories?

------
egypturnash
I'd love to see how a post-filesystem device would organize the content for my
graphic novel.

I've got about a hundred Illustator source files, one for every page. A
similar number of pngs for posting online. A subdirectory full of source files
for my model sheets - mostly Illustrator files, and some 3D models for a
swoopy car. And another subdir for rendered copies of those model sheets. On
an external drive (space is at a premium on my Air) I've got print-res TIFFs
of each page, two for some pages due to crazy printing tricks I'm doing. And
an InDesign template that I use to generate an InDesign file that includes all
those pages, which I finally use to generate a PDF that I send off to the
printer.

This is not an especially sophisticated thing to do. People have been drawing
comics for ages, and have needed much the same kinds of organizations well
before the computer. A pile of illustration boards in a closet, labeled as
being this story or that story. A filing cabinet with my notes, models, and
reference. Et cetera.

As long as the OS and apps have no real global concept of "a project", we'll
need file systems to, well, give us a system to organize our files.

Or maybe I'm a Luddite who can't imagine the critical change in usability that
will result in being thoroughly free of directory trees. It's quite possible.
But I sure don't see it in what we have now.

~~~
XorNot
I tend to be of the notion that pushing data organization into the application
space is just asking for trouble most of the time. I'd prefer to have one big,
consistent way to organize things, then a few dozen applications each with
their own take on it.

To me the ideal system is one where the filesystem (or probably a very thin
abstraction layer) can be intelligent enough to do sensible things with files
when they get saved, and my applications work with whatever scheme I tell it
to enforce.

------
brisance
Don't know why the title was changed to use the provocative "obsolete"; the
blog post linked to reads "Files and Folders".

I do agree with the article in the general sense. That's not to say that the
file system hierarchy is going away. Just that a search field is _generally_
far more efficient when it comes to retrieving data (specific use case). Kind
of like how Google does it. Does Google drill down to a folder 3451 levels
deep to return a link? Maybe it does, I don't know. :)

------
shurcooL
I never use the prepopulated Music/Photos/Videos/Documents folders because
some apps pollute them with their settings and whatnot without my permission.

Instead, I make one folder and keep all my manually created content there.

I _used_ to try to organize by categories, but due inability to easily place
same file in many folders, and things become harder to find as time passes, I
shifted to my current favourite way to organize stuff.

It's inspired by Camera Roll. Just a single folder with folders for events,
sorted by time.

------
grannyg00se
"it’s a matter of time before the traditional desktop disappears and is
replaced by one interface regardless of device that just operates on apps,
metadata, and search."

If you have to tag your data with metadata, you might as well make a place for
it and put it in its place. I don't see a big advantage one way or the other.
Unless the meta information storage becomes automatic. But then I probably
wouldn't trust it to catalogue the information the way I want.

------
beat
For the application development side of this, see
[http://www.12factor.net](http://www.12factor.net). One of the tenets is that
processes should be stateless, and therefore filesystems are ephemeral. Don't
expect a file to stick around from invocation to invocation. This is
explicitly true on Heroku, where they guarantee that they will kill every
process sooner or later - and with it, the VM that it runs in.

~~~
groby_b
How is the filesystem ephemeral? The _local_ filesystem, yes. But a shared FS
is nothing but yet another backing service.

~~~
beat
A filesystem as backing service is a different problem (or more to the point,
a different solution). But the filesystem used to store the application
runtime is itself ephemeral. In Heroku, when the app shuts down, its VM goes
away permanently, along with any local storage, and any instance of an app can
be shut down at any time.

------
vy8vWJlco
The need for a filesystem is proportional to the owner's expectation of
control.

Filesystems are part of the general purpose computing toolkit. Assuming we
don't all turn in our _computers_ for appliances in a forced buyback to get
hacking tools off our streets, filesystems are here to stay, if only to allow
the Morlocks to create new jellybean interfaces for the Eloi.

------
lignuist
iOS n > 7 will have a file system browser.

Why?

Look at how many apps have built-in directory browsers to manage files. Moving
this functionality to the core, will look like a revolutionary and elegant
idea.

------
crazygringo
> _Kids today who start out with iPads and iPhones will never or rarely be in
> touch with a file or a folder._

On what planet? They're not going to be writing papers in high school and
saving them on their computer's SSD? They're not going to be putting them in
separate folders by year or subject? Even Google Drive lets you organize files
in folders.

> _The next generation wants to be able to..._

I'm not sure I've ever seen a writer start a sentence like this, and then end
it with something true. If there were any truth in what he was saying, he'd
actually be quoting "the next generation" directly and backing it up with
evidence, instead of putting his own words in their mouth.

~~~
NZ_Matt
>They're not going to be putting them in separate folders by year or subject?
Even Google Drive lets you organize files in folders.

I think the point is that this will be taken care of automatically based on
the metadata. A lot of people don't take the time to sort everything into
folders, instead they end up with one messy documents folder with all their
documents.

------
kaiwen1
The removal of the file system is anti-feature. Users with no knowledge, no
interest, and no need of a file system metaphor may do fine, but as it turns
many users do need this metaphor. They need to operate on files, and share
them between apps, and know things about their metadata. This is no just
programers. It's users create and consume diverse content.

I wrote about this more here:
[https://plus.google.com/100198164384432656847/posts/JUPAUCe8...](https://plus.google.com/100198164384432656847/posts/JUPAUCe8jQK)

------
_sh
For those who argue that the hierarchical filing system isn't going anywhere,
consider Yahoo vs Google. Yahoo was once a hierarchical filing system for the
web, Google's philosophy was 'search don't sort'.

For those that argue that tags aren't hierarchical filing systems, consider
that '/Documents/Theses/TagsVsHierarchies' is the same as tagging
'TagsVsHierarchies' with 'Documents' and 'Theses'. It's turtles all the way
down.

------
twald
I believe there will always be a file system NEXT to search. Think about it.

You're at home looking for your keys. First thing you do is ask your
girlfriend if she knows where the keys are. If she doesn't know you start
looking for it in a categorical way: Which rooms were you in today? Where do
you usually leave your keys?

I feel like search is the convenient way and will be number one. Folders are a
human's natural tendency to create backup plans in case of unexpected
uncertainty.

~~~
icebraining
But unlike your girlfriend, the machine knows about every single file in the
system, even if it can't recognize it. So you can ask it to find files that
match certain characteristics, instead of going through folders. To keep with
your example, you'd ask "the object is made of black plastic and metal", "I
used it last yesterday", "I use on my car", etc.

------
informatimago
I don't mind keywords ("hashtags"?). Until we start to have more than 7 of
them. Then I want to put some order on my keywords. I think I'll adopt the
following scheme: all the keywords for my private stuff will be prefixed with
private. (private.accounts, private.pictures, private.mail) All the keywords
for my software sources will be prefixed with src. (src.public.lisp,
src.pjb.test-project), etc.

Oops, I reinvented the hierarchical file system!

------
roamzero
The biggest issue of storage in the coming years will simply be the management
of personal files. How should people handle the accumulation of a lifetime's
worth of data as they migrate from older computing devices to new ones? Some
things are generic enough that you can assume you can pull them off the
internet buffet style as you need them, but there are also some things that
definitely do not fit that category such as family photos, etc.

------
r0s
Sure, focus on metadata... but then, the path and other data about a file
location on disk is just another facet.

This is as logical as saying file sizes are obsolete. Maybe storage gets so
cheap users don't need to know sizes, and only developers need that info. Does
that make file size information obsolete? No, absurd.

Just like all metadata, some is higher priority to lay users, and those doing
serious work need detail.

------
vonskippy
What I came away with from reading that drivel is - Kids today are stupid, and
they're that way because they use a iPad. Did I miss anything?

------
LoneWolf
I really hate this idea, one of the things that most annoys me is the lack of
a way to see my files in the filesystem on my windows phone 7. It is one of
the things I can't live without, the abstract idea of Pictures, Documents etc
doesn't work for me I want FILES not categories and types of files stored
somewhere I DONT know where or how.

------
malkia
I can see real books disappearing first, before files. This concept is so much
ingrained in the actual development of apps, that it can't simply go away.

Starting with scm, make/project files, editors, runtime functions, access to
devices - it's all file based, and it's the lowest common language between 99%
of the systems in this world.

------
vectorpush
So I have this group of bytes that generate a sound when processed by an
application.

You can call that group of bytes whatever you like, and maybe you can even
come up with a novel abstraction for it, but be you iPad novice or kernel
hacker, that group of bytes will always need to be recognized as a discrete
unit for it to be useful; that unit is a file.

------
Fice
“There should be no distinction between a file name and a file. A human mind
can more effectively use a fast, whole-text search engine, so that any word or
phrase from the file can serve as a key to it.... An unlimited length file
name is a file. The content of a text file is its own best name.” (Jef Raskin.
The Humane Interface)

------
ams6110
I guess I'm about as opposite as one can be from this point of view. I manage
all my files from the shell prompt. I don't use GUIs as they are just too
limited and slow.

------
jroseattle
Maybe from some UI, but underneath the covers -- this isn't happening anytime
soon.

------
hakcermani
The new OS X is kind of getting there isn't it with multiple tags for a file.

------
nvmc
In other news, trolling will soon be obsolete due to bloggers like this one.

------
drivebyacct2
Yeah, whatever. For practical purposes, it nearly has, and it won't really
technically go away, the interface to it will get progressively dumber. See
also: mobile (native) apps.

