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 528421
To view parent comment, click here.
To read all comments associated with this story, please click here.
hhas
Member since:
2006-11-28

The problem is not that users use directories to organize files. The problem is that users organize files. It is totally pointless... It serves absolutely no real purpose. It is a distraction. It is stupid. It is nonsensical.


The phrase you want is "make-work". Like recompiling a kernel to add a new driver; itself an exercise that has only recently fallen out of the category of "positive ways to spend one's life" (and even so this probably only applies to the mainstream distros).

A simpler way to put your argument might be: "I am not my computer's secretary".

The problem is, the typical computer nerd/geek is a pathological hoarder: always happy to absorb shiny new toys, but never, ever throws away what they already own, no matter how clapped out or broken down it might be.

I suspect a lot of folks here, while enthusiastic about computers, just don't know much history beyond their own direct experience, so don't appreciate just why the proto-greybeards invented the terms 'primary storage' and 'secondary storage' in the first place. Disk drives - and, by extension, files and folders and whatever other related abstractions you care to mention - are just a workaround for the historical limitations of primary (currently RAM) storage: i.e. severely restricted capacity and limited persistence. As a workaround, those early 'users' invented mechanisms for serialising live program data so it could stored away in a more capacious and durable (but too slow for live use) system, and transferred back to main memory the next time it was needed. I daresay if those old valve-based guys had invented high-speed, high-capacity holographic memory instead, such a split would never have occurred. All data would spend its entire lifetime as live objects within permanently running processes, with any cross-process data exchange conducted via IPC, and we wouldn't even be having this argument today.

Folks are now so used to the myriad kludges and abstractions layered on over 60-odd years of ad-hoc evolution, they just assume it's how things ought to be and never think to doubt or challenge those assumptions. Don't get me wrong: organising data hierarchically is a mighty fine tool for certain types of problems (e.g. it makes a lot of sense for stuff like OS and application files), but for user data it is an absolute tyranny.

Straight off the top of my head: consider backups. Backups are an evil, brain-damaged solution to a very real problem: how to ensure the safety of the user's data? There was a time, way back when, that the traditional 'copy to external media/server/whatever' strategy was unavoidable: the technology of the time was too limited to permit anything better. Yet the problem still exists today, at least a decade after that is no longer a hard limitation. Recast the problem in modern terms that better reflect users' actual needs and expectations - redundancy, replication, historical timeline, easy access from more than one hardware device - and you start to see what the real problem is: data being bound to a single point in space and time. And the only way to break that bind is by decoupling the user from the physical storage process and location.

Suddenly, all sorts of ghastly convoluted crap collapses into a far simpler and elegant conceptual model. Not that there aren't all sorts of practical problems still to be solved, but at least now you know where you want to be in the near future, not merely fighting to stay where you were 20 years ago.

(Incidentally, once user data storage and presentation is fully decoupled, you can provide any view onto that data you like, even old-skool hierarchical if that's what tickles your fancy. Ah, the joys of good abstraction. And anyone here who isn't aware that a file system is itself a thick abstraction over a bunch of other thick abstractions - half of which don't even have anything to do with actual files if you're on the likes of Unix or Plan9 - needs a healthy clout from the LART stick; and I do mean that.)

Good luck with effecting any sort of change though. There are all too many folks who'll fight to the death to maintain a nasty, ugly, crippled status-quo where they are the undisputed kings than sweep it away to stand shoulder-to-shoulder all the little folk in a brave new world. OSS/*nix folks should be taking the lead in shaping the future to everyone's best interests. Instead they bicker and whine and refuse to let go of what they already know and step into the unknown, allowing the big self-serving vendors like Apple and MS all the time they need to shape it primarily to suit themselves.

It's a bit frustrating.

Reply Parent Score: 3

galvanash Member since:
2006-01-25

Ah... Someone who both appreciates where I'm coming from AND knows what a LART stick is. Kindred spirit ;)

Reply Parent Score: 2

Alfman Member since:
2011-01-28

hhas,

Thank you for that insightful post. I agree with your ideas. I've given the same thoughts to the duality of documents on storage and documents on display. That duality isn't inherent, it was evolutionary just like you said. I think there are some platforms that tried to treat all documents as active documents and eliminate the notion of opening & saving them. It's unfortunately such projects have been relegated to obscure niche usage since I think it's a nice alternative.


"Don't get me wrong: organising data hierarchically is a mighty fine tool for certain types of problems (e.g. it makes a lot of sense for stuff like OS and application files), but for user data it is an absolute tyranny."

I still have to disagree with you here though, even once we've expelled the disk-saved/memory-loaded duality, which was invented for the computer's sake so to speak, it hasn't eliminated clutter nor the user's desire to keep certain documents organised in relative hierarchies, metadata only takes you so far and works much better in some cases than others.

People used hierarchies even before computers came on the scene because it was a natural approach for them to organise data - it's not like they were invented for the computer's own sake. They exist in all kinds of "human" contexts; my favourite computer part supplier, newegg, organises their website products in a hierarchy. That wasn't for the benefit of their web server, or their developers. No, it was for my benefit as a user. In addition to hierarchies, they also provide great metadata searching too, proving that both approaches are complementary. We should my own computer not permit me to work this way if I want to?

"Good luck with effecting any sort of change though. There are all too many folks who'll fight to the death to maintain a nasty, ugly, crippled status-quo where they are the undisputed kings than sweep it away to stand shoulder-to-shoulder all the little folk in a brave new world. OSS/*nix folks should be taking the lead in shaping the future to everyone's best interests."

I certainly hope you are not referring to me, because I agree with you. The status-quo really does impede progress sometimes. I don't feel user directories do that since they're entirely optional and don't interfere with metadata.

Reply Parent Score: 2

hhas Member since:
2006-11-28

""Don't get me wrong: organising data hierarchically is a mighty fine tool for certain types of problems (e.g. it makes a lot of sense for stuff like OS and application files), but for user data it is an absolute tyranny."


I still have to disagree with you here though, even once we've expelled the disk-saved/memory-loaded duality, which was invented for the computer's sake so to speak, it hasn't eliminated clutter nor the user's desire to keep certain documents organised in relative hierarchies, metadata only takes you so far and works much better in some cases than others.
"

I see no reason why parent-child and sibling relationships couldn't be expressed via metadata as well. Point is, users should neither be constrained by it nor forced to maintain it themselves. Heck, from a user's POV a file path is just degenerate metadata, e.g. /usr/local/bin/foo tells me that 'foo' is an executable tool that I installed myself. By its own nature a file path also implies that certain hierarchical relationships exist, but whether these are unique, optimal, helpful, necessary or even appropriate isn't something that can be answered without a lot more expert insight. Insight that the system should automatically provide as much as possible so the user (who has better things to do with their life) doesn't have to work at it themselves.

Once properly decoupled, users and applications can express and view whatever shaped graph(s) they like; they're all equal in the display system's eye. And it can be left to self-organise by default, according to whatever criteria the storage system deems most appropriate to a given data type; any additional organisational advice that a user might wish to contribute are merely icing on top.

It works better once you start thinking about how to decompose application functionality as well. Consider an email client, which consists of a functional core that knows how to talk POP/IMAP/SMTP, a big old data silo (which may be local, remote, or spread over both), and a bit of user interface for interacting with the both of them. Recast this though, and the core component stays the same, while the data store and UI become parts of an expert system for providing one 'intelligent' view onto a specific type of user data - essentially just one more plugin extension to the general-purpose data storage system you already have. You eliminate the closed-off data silo, along with all the dog-work needed to implement its foundation, benefiting both users - who have much freer access to their data - and developers - who can leverage far more shared architecture, leaving them much more time to invent other cool toys, go down the pub, etc.

""Good luck with effecting any sort of change though. There are all too many folks who'll fight to the death to maintain a nasty, ugly, crippled status-quo where they are the undisputed kings than sweep it away to stand shoulder-to-shoulder all the little folk in a brave new world."


I certainly hope you are not referring to me, because I agree with you. The status-quo really does impede progress sometimes.
"

Don't worry; they shall be known by their actions, not by mere words. Folks who really want to effect change will put their backs into it. Folks who stand to lose power and status and are unwilling to accept that will battle against it. While the majority will just bring popcorn, of course. ;)


I don't feel user directories do that since they're entirely optional and don't interfere with metadata.


A one-armed straitjacket is still a straitjacket; you've just gotten so used to living with it that it's never occurred you could take it off at any time. ;)

Treating one particular idiom/organisation/representation as a special case that is hard-wired into the storage system requires a duplication of effort, and will colour and constrain everything else that the system might want to do. Whereas if you treat your much loved tree structures as soft or 'virtual' relationships, you can express them just as easily within your general metadata-driven framework without imposing any of those disadvantages.

Meanwhile, since the system now has unimpeded control over how and where everything is physically stored, it can make whatever rule-driven arrangements it deems best: e.g. an application (executable plus various resources) may be written out locally as an old-school file system hierarchy for efficient performance; your favourite Rush tracks are replicated across your local devices for easy access; the hilarious cat pictures you just took yourself are replicated to your online personal cloud space for safe-keeping and perhaps from there onto your favourite public sharing sites as well; etc. While your 'smart viewers' can display that info from anywhere, to anywhere, in whatever way(s) you like.

Reply Parent Score: 3