Linked by Thom Holwerda on Wed 25th Jul 2012 22:18 UTC
OSNews, Generic OSes The article I'm about to link to, by Oliver Reichenstein, is pretty terrible, but it's a good way for me to bring up something I've been meaning to talk about. First, the article: "Apple has been working on its file system and with iOS it had almost killed the concept of folders - before reintroducing them with a peculiar restriction: only one level! With Mountain Lion it brings its one folder level logic to OSX. What could be the reason for such a restrictive measure?" So, where does this crusade against directory structures (not file systems, as the article aggravatingly keeps stating) come from?
Thread beginning with comment 528385
To view parent comment, click here.
To read all comments associated with this story, please click here.
Alfman
Member since:
2011-01-28

galvanash,

"The thing that is wrong about directories (from a UI perspective) is that they are location specific taxonomy, and they are exclusive. It is an artificial limitation - it is taking power away from you and making you waste braincells."

Oh you are hopeless, maybe this will help: DIRECTORIES ARE NOT EXCLUSIVE TO TAGGING AND METADATA!!! You seem to be wilfully ignorant of this fact and every single one of your arguments thus far has relied upon that ignorance to make a case in favour of metadata and against directories. You prefer tagging, fine, however you don't speak for me or anyone else. The big pile approach is a regression for millions of users and professionals. It's an arbitrary decree that computers shouldn't enable us to organise our digital files as we would in the physical world, all because you can't spare the brain power.


"Im just saying why not let your computer keep things organized for you? That way you can, I don't know, go do real work."

To the extent that works, then sure, but nobody here has argued against that.

Read DeadFishMan's post:
http://www.osnews.com/thread?528371

If a user uses a device to download music and movies, then metatags should work great. No user brain cells wasted here. Though it is still not an argument against *allowing* for directories. Permitting both is a simple solution that works for everyone, there's no reason to get authoritarian over how other users choose to work.

Edited 2012-07-26 17:27 UTC

Reply Parent Score: 1

jigzat Member since:
2008-10-30

Yeah I know, Einstein said once that he never learned by memory any telephone number because brain connections are scarce, that's what telephone guides are for.

Reply Parent Score: 1

galvanash Member since:
2006-01-25

Oh you are hopeless, maybe this will help: DIRECTORIES ARE NOT EXCLUSIVE TO TAGGING AND METADATA!!!


For the 2nd time - I know that already.

How do applications access files? By directory path. Its baked into the file system. Its baked into the APIs. Its very, very hard to change. The point is you don't have to change it - you just have to make it difficult for users to muck up.

If you build a system that is designed to manage the taxonomy of files with metadata, and build applications that are designed to use this taxonomy to access the files, how do you maintain system integrity when uses can just willy nilly change the primary key of a file behind the systems back? Sure, you could use some sort of other metadata and graft it on top and let the system use that instead of the primary key - but that is horribly inefficient...

You end up with a system where only the user really knows how to find anything - the system has to do all searching because it cannot establish any meaningful rules as to where things should be put. We have that now - it sucks. Every hard drive looks different. Things are invariably a mess. Sure, you can find your stuff - but no one else can.

Im sorry but it is not as simple as grafting on metadata. We have already done that - its been done for years. It hasn't worked, because it is not a fundamental change - the primary mechanism for accessing files is still by directory path, and we let users play with it to their hearts content.

Look, there are compromises that can be made - I get that. But I am trying to convince you that you don't need directories, not that you can't have them. Hierarchal storage is efficient. It works. There is no need at all to get rid of it. What is needed is to make it impossible for inexperienced users to break system defined storage hierarchies, once you do that the number of interface paradigms you can use to present things to users drastically increases, because from the computers point of view things stay where they are put.

If you graft some form of hierarchial metadata (which can be easily done with simple tags) onto the filesystem to let user organize things for their own purposes, that is perfectly fine. But it shouldn't be the primary key!

A system admin or developer need not worry about what I am describing. File systems will more than likely always offer hierarchal storage - but you don't need to actually expose that to your average user at all. In fact, what I am saying is that it is counter-productive to do that - it creates an insurmountable obstacle to improving the status quo. You cannot reliably create a system like I am describing if you let users muck with the primary keys...

WHERE things should be stored should be left up to the system. User file organization and and the primary access mechanism for files are two completely orthogonal concepts. THEY HAVE NOTHING TO DO WITH EACH OTHER! The first is a completely arbitrary concept that matters to know one but the user, the 2nd is quite the opposite.

Reply Parent Score: 2

Alfman Member since:
2011-01-28

galvanash,

"How do applications access files? By directory path. Its baked into the file system. Its baked into the APIs. Its very, very hard to change."


That's a problem with the implementation, not a problem with the directory concept. I completely agree that it's difficult to enhance the paradigm on existing platforms. Even if you provide the API's, legacy software and conventions will be a sore point and it's unlikely for a unified paradigm to emerge without compromises. These wouldn't be a problem for a new platform, but that may not be a luxury we have now.

As such, we should be asking ourselves ways we can get there, but not by eliminating organised directories.

"how do you maintain system integrity when uses can just willy nilly change the primary key of a file behind the systems back? Sure, you could use some sort of other metadata and graft it on top and let the system use that instead of the primary key - but that is horribly inefficient..."

I'm confident all the technical problems like indexing multiple criteria are solvable, and actually many file systems already use surrogate keys. In linux for example we have an inode which serves as a primary key. The user doesn't handle these directly of course because of the file naming abstraction. I'm happy to discuss technical designs, if you want to, but it shouldn't be relevant to a user.



"But I am trying to convince you that you don't need directories, not that you can't have them. Hierarchal storage is efficient. It works. There is no need at all to get rid of it."

Is it possible that we have nothing more to argue about? ;)


"What is needed is to make it impossible for inexperienced users to break system defined storage hierarchies, once you do that the number of interface paradigms you can use to present things to users drastically increases"

I don't think the number of paradigms is as important as being usable. But I agree with hiding OS details from the user at least by default. Normal non-admin users should never have to see or deal with system directories, so there's no reason to needlessly distract users with them.

As an example: On android, I find it gnawing that I need to navigate through the root directory full of system directories just to get to the sd card. It's not difficult, but those steps seem unnecessary and ugly to me, especially having to scroll down to find "/mnt/". Each application seems to implement it's own file browser, so there isn't really a clear way for android to fix it now.



"If you graft some form of hierarchial metadata (which can be easily done with simple tags) onto the filesystem to let user organize things for their own purposes, that is perfectly fine. But it shouldn't be the primary key!"

It's how extfs already works. Each directory is in essence an index pointing to inodes, for other meta data you could just add more indexes that work in a similar way. Or you could rebuilt the FS from the ground up, or you could stick the metadata in an SQL database...the implementation shouldn't really matter to the user. If I can navigate my directories and search my metadata, I'm happy.


"You cannot reliably create a system like I am describing if you let users muck with the primary keys...WHERE things should be stored should be left up to the system."

Primary keys can be surrogate keys, it isn't anything that's insurmountable and in fact we can't change the inodes directly in linux. Again, I'm confident we can solve all technical problems.

Reply Parent Score: 2