Shuttleworth On Redefining File Systems
moteyalpha writes "Mark Shuttleworth described the beginnings of what could a great step forward in making file systems more usable. I've personally had the experience of trying to find a file for a customer who had just finished editing a critical report, saved it, and then couldn't locate it to deliver to their client. Quoting: 'My biggest concern on this front is that it be done in a way that every desktop environment can embrace. We need a consistent experience across GNOME, KDE, OpenOffice and Firefox so that content can flow from app to app in a seamless fashion and the user's expectations can be met no matter which app or environment they happen to use. If someone sends a file to me over Empathy, and I want to open it in Amarok, then I shouldn't have to work with two completely different mental models of content storage.'"
Ooops, posting to remove mod
Merging the efforts of Nepomuk and new file systems like brtfs are the way to go with this. Handling of file events can be done better than what we have now with inotify. File systems should allows plugins to update indexes on files within the file system structure and file systems should allow queries and query monitors directly.
DBPedia shows the power of SPARQL and implementing an efficient storage for it into a file system is the first step forward. Then user interfaces in GNOME and KDE can take advantage of the queries that are currently very expensive to do.
Ubuntu is in a good position to help out on the Nepomuk effort. Mandriva is already sponsoring this work. More support for this desktop-independent project would be a boon for achieving the file system Mark is looking for.
DNA is the ultimate spaghetti code.
So...it seems that someone on Linux has realized the benefit of UI guidelines.
Linux: 30 years behind Apple on the desktop - but they're catching up!
I should be able to tag a file with "friends, birthdays, gifts" and be able to find that file again using any of the terms.
Hierarchical filesystems are ok for systems management, but they are crap for assigning meaning to user data. A hierarchy implies that any particular file can only have a single aspect when in fact it may have dozens of aspects.
Deleted
HAMMER provides similar capabilities; you can view files, directories, or entire filesystems as of specific versions. "hammer history foo" to find the history of a file, then look at foo@@[id] to view the file at any given point.
Why not in OSX a combination of OS and filesystem data allows me to move applications while they are in use. I can uninstall an application or change it's directory location and all files know how it gets opened again and where it moved to.
Literally you can move an application to a thumb drive, and the next time you open a file that launches said app it will try to mount the thumb drive if it isn't already done so. I get so frustrated in locating files under windows. Why can't the OS get out of my way so i can work? if it takes a file system, and OS to track them properly the so be it.
As for the missing file in the description. most applications include a recent file list as does windows(since 95) and OS X. if you can't remember where you put something, try checking those speed lists first. It is like people only want windows and then refuse to read the dialog box that pops up every time they click on the start button. It is as bad as bill gates with outlook open goes to the task bar to find a calendar.
i thought once I was found, but it was only a dream.
So the user decides not to pay attention to where the file was saved (I mean, you do get to choose where it goes, it does not just happen)
This isn't strictly true, as each program has a default action on saving a file. Some default to desktop, or to "My Documents" or ask for a directory by default. Others may do "smart" checking and try to sort the files depending on what file type gets detected. It's this wide variation that's the problem. Even for someone who is knowledgeable enough to handle the situation without help, it's still a pain in the ass (and waste of time) to dig out the setting and replace it with your preferred setting.
Yes, that is unpleasant, but is additional complexity in the file system really the best solution?
Probably not the best solution. Better would be for the OS developers to set a standard directory scheme and enforce other developers to comply with it. If you want to change the scheme you can dig in and do it yourself. Of course, this may not be practical, as it may prove more complex to enforce compliance (and still keep things customizable) than it would be to bolt on the same functionality in the file system.
that at some point there needs to be a minimum expectation of competence on the part of the user.
But who gets to decide what that expectation is? Don't forget, computers are not "for" hobbyists, developers, experts and geeks, they are for normal people to make their other tasks easier. The more time these people spend training and raising their minimum level of computer knowledge, the less time they spend doing their real work/play, the less value the computer has for them.
Is it really too much to ask of a user that they understand that it is a machine, an inanimate object, and it generally does only what they tell it to do (insert Windows jokes here), and that if they tell it to do something by mistake (like saving a file in an unintended location), the mistake is theirs and not the machine's?
Yes it is too much to ask, because it's not true. Computers as machines do what developers tell them to do. The amount of instructions given by the programmer vis-a-vis object code vastly outnumbers the number of instructions a typical user is going to issue to the machine. This is necessarily true since each instruction given by a user is a blind proxy for at least one instruction (and probably more like hundreds or thousands of instructions) given by a developer.
Users can't be expected to predict a) all the myriad directions that a programmer has given/is giving the computer and b) the effects of the user's instructions when interpreted in the context of the programmer's instructions and assumptions. Most users are bad at using computers effectively because they don't understand how developers think. You wanna try teaching them how you think?
If that is too much to ask, then what is a more reasonable standard? How far should we go to accommodate users who, to put it bluntly, refuse to take responsibility for their actions?
Well, in my opinion, I think we're pretty close to the reasonable standard right now. People can decide for themselves how much they want to learn, how much pain they want to suffer for their ignorance versus how much time they want to spend reducing their ignorance, and vote with their wallet. You're basically saying that you want users to learn more, to make developers' lives easier, but in fact developers get paid to make users' lives easier. Maybe the developers should do their jobs better.
It's like that Unix saying, (paraphrase) "Unix doesn't try to stop you from doing something stupid, because that would also stop you from doing something clever". I like that, not because I think it's witty but because in my opinion, it reveals a design philosophy that assumes that maybe this is new to you and you don't und
Rule of Slashdot #0: You and people like you are not representative of the larger population. - A.C.
It seems to me that we are trapped in an old way of thinking without even realizing it. Why do we follow a spacial model for storing things when we don't need to? Have we asked ourselves the question: "Is it beneficial that we have to remember a location for each file?" Perhaps it is. As humans we have become very good at remembering where things are for later recall. However, for storing media, it makes little sense. A traditional file system with nested directories allows you to organize files, but no matter how clever your directory structure, some files will defy your organizational model. With iTunes-like media interfaces we are moving away from location-based recall to CONTENT based recall. Unfortunatly ID3 tags are overly limiting, but it feels like a step in the right direction (at least for media files). Could this be a the right direction for the rest of our file system? Content based recall instead of an imposed location based recall?
- Captbaritone
Well, the real solution actually already exists, it's just so friggin' complicated that you need an army of consultants to install, configure and maintain it. It's called a 'product data manager'. ;) See these guys for lots of examples.
The key is to take the best of features of a PDM (good search and relationship management capabilities), combined with the best features of a source code control system (simple storage methods, low overhead), and combine those with an easy-to-use-yet-powerful search system like Google Desktop Search. Oh, make all of this transparent to applications. And make it really really maintainable without database experts.
And people wonder why Microsoft canned WinFS. ;)
My blog
Why did the user lose the file? Maybe it would be good for the user to learn how to remember filenames, ...
Funny example: A couple of weeks ago, while downloading and installing something, it asked where I wanted it saved. Naturally, I typed in a file name, starting with a couple of directories with slashes between them, and hit the Save button. Then I went to that directory to look at the file - and it wasn't there! I looked around in all the obvious places, and didn't find it.
Now, I can see some people snickering at a "dump Windows user". But this was on linux. So I did what y'all would eventually do, I ran a "find / "*foo*" command, where "foo" was part of the file name. After a good while, it found it. It was in my home directory (not the one in the save window's Directory widget), and its name had all the slashes changed to colons.
My reaction, of course, was "WTF???" I did a couple more tests, and got the same insane misbehavior. The app was obviously intentionally programmed (with malice aforethought) to do this to pathnames.
Lesson: On any system, linux included, an app can do utterly insane things like this that no sensible user would ever expect. Some apps seem designed to do such things in the worst possible way, perhaps to challenge the sucker^Wuser to figure it out.
It is, of course, all part of the popular GUI culture, in which the user isn't supposed to worry their pretty little head about such details. Users are assumed ignorant and illiterate, the details should be hidden from them, and the app can decide for itself what things are called and where they should reside.
It's part of why the more intelligent people eventually migrate to the CLI environment, which has far fewer such insanities as roadblocks to getting things done. But even there, the attitude that "the user is an idiot" is spreading. And the CLI environment isn't for everyone, since it requires a good level of literacy. So we can expect such things to continue, and probably get worse, for a long time.
Anyway, I have one more item on my long list of things developers can do to make life difficult for users.
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
The hierachrical system is an outdated concept based on traditional methods of meat-space organization.
I'm surprised no one else has mentioned this yet, but a metadata filesystem would save so much time. Tracks would be autotagged with timestamp, size, and filetype if possible, but allowing the user to set their own custom tags would bring out the real benefits.
It would work like Google, where every file is in a single folder. You would an ultra-fast filter window to narrow down to any criteria. Tags could be reused easily (the filesystem would save recently used tags in a dropdown menu on opening or saving), and a thesaurus would help detect near misses if need be. Here's a little more info:
http://www.skytopia.com/project/articles/filesystem.html
In any case, for all the hardened folder adherents, there's no reason why they two systems can't coexist.
Why OpalCalc is the best Windows calc