Comment by unoti | Hacker News Reader

Comment by unoti | Hacker News Reader

Anyone who thinks we're using programming technology of the 70's probably wasn't programming in the 70's. Today it's routine to create systems in a handful of days that would have taken a larger team a much greater amount of time to create in the 70's, 80's, 90's, or even 00's. In fact, for years now, power users do certain kinds of applications with spreadsheets and similar tools-- without programmer intervention-- jobs that were previously handled by systems analysts and development teams.

Interfacing different kinds of computer systems together today is orders of magnitude simpler than it was even in the 90's, much less the 70's.

Sure, we're not all talking to our computers while they program themselves and driving around in flying cars. But software development technology has come a long, long way. Users are tons more empowered to do their own work now than they used to be. And the amount of knowledge and training needed to make a developer effective today is nothing like it used to be.

C and Unix were invented in the 70's. Yes, things have improved a lot in the meantime, but underneath, it seems like a lot of the really basic paradigms are the same. We're mostly typing imperative code into a plain text editor, saved in a disk file in a tree-shaped filesystem, that probably runs on a Unix-like system. Maybe Windows, but in the space of all possible operating systems/environments, they're not that far apart.

When I got to learn UNIX in the form of Xenix, I was already comfortable with many GUI systems and IDEs.

Eventually I used most UNIX systems, commercial and free versions thereof, including the tools most HN folks love. However I am a mouse/keyboard person and love my IDEs.

Every time I look at someone using plain vim/emacs with a few text terminals open, I see someone working in a UNIX System V system.

I'm starting to think that the reason we keep building tree-like data structures is because that's how our minds work. We can intuitively grasp hierarchies of categories (a tree structure), with the occasional exception (a symlink to another location).

Because we intuitively see the world in this way, we are good at building and maintaining systems that work in this way.

Anything more sophisticated than that (algebra, relational databases) requires a lot of study and practice to get good at.

> [Maybe] the reason we keep building tree-like data structures is because that's how our minds work.

No. That's how physical space works. When you're a library, and you need your user to be able to find the books, you don't have a choice: any given book must be in one shelf, in one alley, in one room. And bam, you have a tree hierarchy that is three levels deep.

But our minds are better at dealing with tags. Just see how popular they are in blogs. I bet that a tag based file system would be vastly better at storing personal data than a hierarchical one.

We could just put all the books in one, big room, just aisles and aisle of shelves, everything numbered sequentially. We could even build a library as one long hallway -- one single line of books.

But we choose to divide our buildings up into rooms. We choose to create that hierarchy.

Edit: I suppose, though, that our minds evolved to operate in physical space. Go hunt some zebra, go climb a tree... things like that...

Even if you put the books on a single long shelf, chances are you're going to make the numbering system based on the content of the books, like say, the Dewey Decimal system. That's a hierarchy of at least two layers, right there. If you assign random identifiers, you'll probably end up creating that same hierarchy in the index instead, unless you do something more tag-based which is actually likely to be better.

Both is better. There is no reason for the navigation system to ignore groups and hierarchies, it just should also be able to deal with arbitrary tags.

Having watched people struggle with what is essentially a configurable search pane (specifically, the excellent thumbnail viewer in Windows Live Photo Viewer), there does need to be a simple default, probably one that looks just like a hierarchical file system. It just shouldn't be the only way to use the system.

I spent sometime yesterday thinking about what queries I would like a filesystem (layout) to be able to answer.

-installed programs

-files installed (except configuration) by a program

-files installed (including configuration) by a program

-libraries

-a users personal files (including configuration).

-all files except bare bones install

-all files

-files on a specific hard drive

My conclusion was that my preferred layout would be

/os/ - bare bones install

/home/ - users files

/home/im3w1l/.conf/firefox - my configuration for firefox

/programs/ - installed program and libraries

/programs/libfuse/.conf - configuration for libfuse

/programs/firefox/.conf/im3w1l - my configuration for firefox

C:/programs - installed programs on specific hard drive

And that if a file is deleted from one place it is deleted from all. So rm /home/im3w1l/.conf/firefox -rf

would be the same as

rm /programs/firefox/.conf/im3w1l -rf

But I think a general tagged system has some problems, most notable filename collisions. Adding a tag to a file could create a collision for instance.

For me a basic tag based file system needs several things: A unique ID for files (a strong cryptographic hash of the contents is probably best), a name for each file, and a list of tags for each files. And of course, a number of logical volumes on which the files are "located". Where a directory structure is actually needed, files could have special names, like "/os/glad/file_42" (that's a name, not a path).

A variation on this theme would be to do away with explicit names altogether, and only use tags. The "name" of the file would just need to be reasonably unique. That one is probably best.

Now, when you search for a file, you just query for tags. Can also be done through the shell: it's just that those two commands would have the exact same effect:

  cd /foo/bar
  cd /bar/foo

As for the volume, you need them to transfer files between your USB key and your computer.

Oh, thinking of using cryptographic hashes to name files… When you modify the file, the ID changes as well… that's a new file! By default, the old version should still be around. Imagine that: Git for the masses.

Reply on news.ycombinator.com