Mountain Lion's new file system

I couldn't get past this part:<p><pre><code> Even geeks can’t handle folders in folders </code></pre> Hierarchical file systems weren't invented because it was ancient times and they were the easiest thing to produce. Hierarchical file systems were invented because they are a really, really good paradigm for storing and retrieving hierarchical data - which I strongly believe is still the case for the majority of files.<p>I didn't read further in to the article so perhaps I missed where this same idea was discussed, but I think a useful idea going forward would be meta-tagging of data. Something very basic like the ability to flag a file and later search or sort by those flags. Do it for specific folders, like the Documents folders. Done.<p>Now the 'non-geek's can deal with flat file structures and us 'geek's can do smarter things.

&#62; <i>Folders are not a feature that beginners muddle through but pro users require. No one can deal with deep folder structures. Our brain is simply not built for them.</i><p>This is ridiculous. I have computer files I've produced from over the past 20 years. As time goes by, I continually archive them in a big old hierarchical folder called "Archive". Broken down my life phase, school year, project, etc. Without folders-inside-of-folders that whole system would be a <i>mess</i>.<p>Or, programming projects. How can you even imagine organizing your stylesheets, plugins, libraries, components, endpoints, controllers, etc. without folders?<p>I'm sorry, but throwing away hierarchical folders completely is a monumentally stupid thing to advocate. Beginners might be better off without them, but pro users <i>absolutely</i> require them.<p>And our brain is most <i>certainly</i> built for them: <a href="http://en.wikipedia.org/wiki/Memory_palace" rel="nofollow">http://en.wikipedia.org/wiki/Memory_palace</a><p>Now, I'd love to have tags as well, but "keep your hands off my folders!" :)

Coming from Linux, you would think "new file system" would mean that: a new file system.<p>But its just the same smoke and mirrors Microsoft did when they scrapped WinFS: add magic folders, terrible ideas (translated folder names?) and missing hard features (links) in a limited fashion.<p>Thats sad, because the file system could certainly do with a complete makeover: metadata, builtin sync with the cloud, backup and encryption as a first-class citizen, etc. etc.<p>For now, thats only available in enterprise solutions like ZFS or in the still very alpha btrfs.

This is bullshit, in a lot of ways.<p>1) This isn't a file system. It's a file structure.<p>2) Presumably I can still make directories inside of other directories if I want to, right? Given that this isn't an actual "new file system", they can't stop me, right? This was totally unanswered by the article.<p>3) If they actually prevent heirarchical file structure, can OSX still be called Unix? I think you need root, /usr, /dev, /etc, et cetera.<p>4) In all my years of dealing with noobs, I've never seen anyone flummoxed by a heirarchical file setup. Yeah, when they first start out, many people open files by clicking the program and choosing "open". But it usually isn't long before they want to start transfering files between devices, folders and programs. And if you need to do anything like that, you need a file browser and heirarchical structure.<p>I guess I've read it enough to believe it, but I can't. How can computer professionals actually suggest it should be like this? For <i>everyone</i> and not just some training wheels I can take off?

I find the claim that <i>nobody</i> understands multi-level file systems a hard to swallow. Inside my Documents folder, I have a folder for one of each of several organizations I work with, inside of those a set of folders for one of several different things I do for those organizations, and within some of those, a folder for every project I have going on. I don't necessarily need to know the complete path to everything, but anyone can generally look at the directory listing and see what the next directory to look into is.

Is it a symptom of the fact that he believes himself to be an expert on the subject that he enjoys using the term "file system" over and over in a way that goes against 50 years or more of common usage? Or was it just link bait for those of us who thought there might be some new HFS+ implementation?

Information architecture from a neuroscience point of view.<p>Concept building: A bottom up hierarchy<p>Everything you know was learned in the context of prior knowledge. You combined prior experiences, refined them, and over time solidified them into new constructs which you then used to repeat the process for higher level concepts. Visual light and dark blobs become coherent shapes which get associated with meaning and eventually those meanings get associated with names like 'chair' or 'rabbit.'<p>Content access: A top down (and sideways) lookup.<p>In many cases we know what we want without bothering to think of the name. Being thirsty may mean you think 'glass','faucet','stream','bubbles', and 'water.' But you don't have to think any of those words to get a glass of water and take a drink.<p>Unfortunately in much of IT there is a textual interface so you first have to pick a starting word and then use that to find what you're looking for. Any time you think of a word it is physically connected to many other notions, memories, experiences, and other words built over a lifetime of experience.<p>When we try to describe what something <i>is</i> we access the hierarchy we have learned. A chair is a piece of furniture, which is a solid object, which is something I can touch. We may even use this description to create a hierarchical description.<p>The tension here is that how we describe things is at best a very limited subset of how our brain connects to information about that thing. These mappings differ from person to person and change over time. One system of hierarchical categorization cannot be intuitive to all people and probably won't be to the same person after 10 years.<p>IMNSHO The only interface which will 'just work' for organizing labeled objects is one that <i>knows you</i>. The best example of this is Google's one box which searches my computer, builds associations between content that are not directly related to the search terms I use, and modifies itself over time based on my behavior.

This argument does not make sense at all. Almost everything we do or own in the real world is based on one form of hierarchy or another. Work (CEO &#62; Executive &#62; etc.), Home (Parents &#62; Old Siblings &#62; You &#62; etc), House (House itself &#62; rooms &#62; closets in a room, etc.) These are not just labels and there is nothing geeky about them either. They imply a certain order or sequence of things that can not just be moved around. If there is one thing that we as people are good at, it must be hierarchies.<p>Tags on the other hand do not imply order of things. They are more about how you'd describe or how you relate to these things. For example you can have a 'favorite' tag and apply it both to your sibling as in 'your favorite sibling' and one of your closet as in 'your favorite closet in your room'. It says nothing about the order of these things just that your like them. Also, tags can be somewhat temporal as opposed to hierarchies. For example if we take a folders and files example, I can have a top level folder called projects which contains sub-folder for each project I've ever worked on. In each of these sub-folders I can then store the project-specific files. I can use 'current' tag to tag the project I'm currently working on. When I finish this project and get another project, I then remove the 'current' tag from the just finished project and move it to the new project leaving the hierarchy intact.<p>The point is not to use folders when you need tags or use tags when folders are required. The best files system would be the one that allows you to use both as situation demands.

When is someone in charge of such things for an OS vendor going to realize that for any of "my" documents, what I really want is to tag them?

So ... what happens if I drop to the terminal and:<p>mkdir -p /Users/username/folder1/folder2/folder3<p>... and then open the finder and navigate to my home dir ... do I just not see past the first nesting ? Is it hidden ?

Windows did it first... My Documents / My Downloads / My Movies / My Music / My Pictures. The author makes it seem like Mac's "default content folder" scheme was a novel idea.

I really don't understand what is being said here. How are folders a hard concept?

I'll have to see what this is like by actually using it. Right now, my biggest concern is that it usually makes for better usability if you allow the user to organize and group content in a way that makes sense to them. I don't feel this is an area where the OS should take control away from the user.

Wasn't the original Apple "filesystem", circa II, a flat one? That is, a list.<p>Not only is it easier to work with, as the article suggests, but, obviously, it's faster!<p>I use globbing on a daily basis over other later approaches, e.g. regex. But it works best with a relatively flat filesystem. Too deep, and it's off.<p>The simplest approach possible.<p>But before we can fix filesystems, maybe we need to teach people how to name files in ways to make their life simpler. Long filenames and ones with spaces and punctuation inevitably become a huge PITA. Yet we think of these as "must-have" conveniences.<p>I used to believe that too. But over time I've realized this slows things down immensely and introduces lots of unneeded complexity. Speed and simplicity is more important.<p>If you can get by with only a "list of files", you are better off.

I think funny that it's easier to dumbi-fy the user instead of creating something worth some like tagging and making metada easier and more useable.<p>EDIT: Also, I think he's referring to iCloud only.

Folders or tags are hard in the sense that both of them require a user to think about organisation, when in reality any of them just wants to find the file 'magically' where they last left it and do stuff with it. In most cases this is in some application or (in my opinion still a temporary stop gap) a one level deep file system.<p>The applications itself will serve the needed context or metadata (type of document, last modified time, access/sharing privileges) to find the files you're looking for.

For some reason I think the author is being overly wordy. The point if I understand it, is that Apple is once again moving OSX towards iOS by switching from a strict folder based filesystem to an App structured file system (from the user's point of view). This allows people to find content and files more easily because they will always be where they left them. In the app that uses them.

&#62; <i>We are the people that put salt and pepper on the pizza before trying it, because we just know best.</i><p>Salt and pepper... on <i>pizza</i>?<p>Is that a thing?

I guess we'll have to see how this holds up: Usually the problems arise not from one's own folder structure (most people know their way around what they've created) but when working together in someone else's structure. Does this approach solve that problem?

<i>&#62; But that’s not the real reason why geeks are skeptical. It’s because we are smart asses. We are the people that put salt and pepper on the pizza before trying it, because we just know best.</i><p>I couldn't have put it better. It goes double for us coders.

I'm sure this will add a lot of awesomeness to tasks like creating a web page or an application; all the pngs and jpegs mixed together in Photos, templates and styles in Documents...

Nothing to do with file systems, got bout half way before I realised this was just some tool talking about how hard it is to keep his shit organised.