The OS X Filesystem is Disappears

If you’ve ever looked at the iPhoto application in Finder, you’ll know that iPhoto and the photos it stores are one in the same. They’re a ‘package’ that you can’t break apart. This is fundamentally different from how iTunes and all other OS X applications work; they store their files in folders somewhere separate from the application itself.

The iPhoto ‘package’ is a sandbox that contains everything iPhoto wants to play with. In Lion, apps will only be able to modify their own sandboxes, which is great for security. iOS apps already use sandboxes, and that’s why there’s no way you can screw up your iPhone just by installing an app.

iPhoto just is the first OS X app to work the way iOS apps work. Soon, most OS X applications will work that way. Yes, the filesystem is going away.

When I say it’s going away, what I mean is that most users will never need to know about it ever again. Documents will be visible within the applications that created them, and that’ll be it. As Gruber said on The Talk Show, the data for the app is in the app, not the filesystem. Anyone who uses Evernote or Google Docs or any iOS app is familiar with how this works. It’s very straightforward & logical.

If you already use Smart Playlists in iTunes or Smart Searches in Finder, you already have a taste of how the filesystem will “feel”. Apps will essentially see the filesystem through a Smart Search set to only show documents with a certain file type. You’ll still be able to sort them by date created, modified, and last opened.

The Post-PC Era is about non-computer users becoming computer users, and making computers more appliance-like, such that how they work will be self-explanatory. These non-users will soon represent 99% of all computer users, and they will not be power users.

Of course, Apple’s programmers will continue to use OS X as their primary operating system, so they’ll want to keep the ability for other power users to get down and dirty with the filesystem.

I said this over a year ago, and i’ll say it again now: OS X will achieve this by having two types of user accounts:

  1. User (average person, iAccount?)
  2. Power User (nerd, developer, administrator, Pro Account?)

All accounts will be created as normal “User” accounts by default, and you will be able to change them to Power User accounts in system preferences.

  • If you have a User account, you will interact with OS X exclusively through Lion’s Launchpad app and iCloud. You won’t have a dock, and you won’t have a Finder.
  • If you have a Power User account, you will interact with OS X through the dock (with stacks), iCloud, the Finder, and the filesystem. You’ll be able to use Launchpad if you want to, but you certainly won’t have to.

There are still lots of unanswered questions about when this will happen (Lion? OS 11?), and how we’ll deal with groups of related files of different types (i.e. my project uses pages documents, powerpoints, images, and video — can i still zip them up together? can i tag them with the same project name?).

The future is very different, but I think it’s bright.

About Derek

Born & raised in Petrolia, Ontario. Birthplace of global oil industry. Educated at Trent University in Peterborough, Ontario. Webified at Humber College in Etobicoke, Ontario. Inspired at TakingITGlobal.org, and in Zagreb, Croatia. Recognized by www.ILoveRewards.com
This entry was posted in geek and tagged , , , . Bookmark the permalink.

2 Responses to The OS X Filesystem is Disappears

  1. Ian says:

    Agreed on the app versus the filesystem. Arguably, iTunes is pretty much like this as well, since you need to manage it using the app and not files. I agree, they are tending more towards ‘databases for an app’. iTunes is more natural to browse using albums and songs than folders and files. The whole appliance thing is exactly right. Anyone who disagrees should switch to a thermostat where you have a folder full of various configuration files to select your temperature. And then give it to grandma. It’s absurd. Sure, files can be there behind the scenes, but regular people shouldn’t need to deal with them. The UI needs to be tailored to the appliance.

    It is true that sometimes it makes sense for two different apps to interact with the same data. But it is instructive to look at how iOS partially deals with this problem. They make most of the function in the music app accessible via an API to other apps. So, other apps can just see the albums and songs as if they were part of that app. How would that work in the old PC days? You’d go through your folder hierarchy until you found your music folder, than drilled down and ‘opened’ the appropriate files with the different app. That stinks even for power users. Look for this notion to be extended as time goes on. App specific databases that other apps could access if you make something like an API.

    The whole ‘power user’ idea may come to be. It seems possible that only a power user could install stuff not from the app store, etc.. As a power user type, I’m ok with all of this (in fact, I think it’s better) as long as there is a way to see the files in some fashion if you’re an expert. I’m fine with most of my documents being in the cloud too, as long as I feel like I own the data. And for me, owning the data means, it is stored somewhere (probably sync’ed with the cloud) on my machine, and I can get at it, with Finder or Terminal. But I suspect, and I’d totally be ok with, those two apps being hidden away somewhere and not on the dock by default. The ‘power user’ idea would be one way of taking care of that. Or at least, stuff Finder and Terminal in the Utilities subfolder.

  2. Zaid Rasid says:

    Wow, great post. You nailed this head on.

    I actually think that Power User will have there own OS totally separate from the dumb down machines. They’ll work with more powerful machines for the niche audience. I don’t think it will be combined in one.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>