Slashdot Mirror
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.'"
Was it a Word file? Locate all .docs, run them through antiword, grep for words from that critical report, and report back the matches. Less than a minute of Bash scripting.
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.
Unless you store it at very cold temperatures. In that case users expecting to be able to sip away at their water may be a little disoriented when someone hands them a block of ice.
Version control, searching, and all of the other advances since the first directory tree are good things to add, but they must be supported down to the application level.
VAX/VMS had a wonderful system of versioning baked right into things, if you worked on a file, it kept versions for you as you saved them....
login.com;1
.. etc.
login.com;2
login.com;3
The default was the last version, unless you explicitly chose a different one. This is an incredibly useful tool, and I still miss it to this day, 20 years after I last used it.
If you can't express an idea explicitly, your power of expression is radically limited. If we can get consensus and support a bigger set of expressions, we can do a whole bunch of cool new stuff. As long as we follow the leader, we'll never do anything this innovative, and we'll always be playing catch up.
It won't be easy!
To do even this simple thing with Linux, all of our applications would have to be re-written to enable a new file specification syntax, hopefully one reasonably compatible with the past. We're talking about a shitload of work, so it's important to agree on a set of goals first, to avoid having to re-do it later.
--Mike--
... just finished editing a critical report, saved it, and then couldn't locate it to deliver to their client.
Well, there are some people who can't find Pacific Ocean on the map. I dont see map makers running around in panic, thinking how to make their maps more accessible to the general population...
Comment removed based on user account deletion
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) and later has difficulty locating it. Yes, that is unpleasant, but is additional complexity in the file system really the best solution? I am honestly not sure how I feel about that. At the same time I agree that there are "user error" type of problems that better technology can either prevent or mitigate, I also feel like some of the proposed solutions I have heard are borderline ridiculous, that at some point there needs to be a minimum expectation of competence on the part of the user.
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? 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?
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 understand everything right now, but one day you do wish to understand how the system works and you do wish to achieve a degree of mastery over it. I really believe that just about anyone who really wants to understand something can do so, that gradually getting better and better at something over time is the most natural thing in the world unless you keep telling yourself that it's too hard. That's why I really don't understand these "permanent newbies", the people who can use a system for five years without grasping the basics. They claim that they are not interested in understanding, but it seems like they are strongly interested in not understanding. Is there something to be gained by accommodating this?
It is a miracle that curiosity survives formal education. - Einstein
Seriously, there are efforts in place for more advanced filesystems - but it's all to no avail when the linux kernel will neither merge these into its tree, nor provide a stable API for them to be maintained outside it. It's kernel politics that's the biggest thing holding back linux filesystem development.
I am trolling
...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...
None of this would be an issue if folks were competent and created directories themselves, and Word (or whatever) asked where to save stuff, as opposed to just assuming (or insisting on) some default system provided directory.
Am I the only person who hates those "My Documents" folders? Or on a Mac iTunes insisting on putting music in a certain weird place? I want to create my own folders, and maintain why own directory structure, and know exactly where stuff is because I put it there---not because Microsoft/Apple/Ubuntu think that's where I should keep stuff.
For the most part, maintaining my own folders for stuff works out just fine (easy backup, easy moving among environments, etc.), except when some program assumes it knows better, and saves a file "somewhere"; really hate it when that happens.
ie: The problem is caused by Microsoft/Apple (and Linux following) to cater to stupid users who just want to create a document and not care where it is saved. Those same users probably wouldn't be able to locate the file (for copy/backup, etc) unless they use the same program they used to create the file.
"If anything can go wrong, it will." - Murphy
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.
In Windows we have survived several such attempts. e.g. "Recent File" or "Documents" in Start menu; or the useless location buttons in open/save file dialogs.
Let's just hope I would be still able to open a file at random location. Because the statement makes me feel that eventually I would be able to find all possible files - system thinks I may need to find, but not the files I actually need.
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.
Orienting future development on full idiots worked well in past... Or not? Well, GNOME full of it already and another drop of inusability into the mix will not hurt much its rabid fans.
As they say, give man a fish...
P.S. rfc1925, ch 11.
All hope abandon ye who enter here.
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.
And you wouldn't have to, if every app would just show the frigging directory tree as it exists, instead of trying to fool the user with a random bunch of stupid fake roots in every GUI.
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.
Yet another abstraction layer.
The higher the technology, the sharper that two-edged sword.
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
My mother in law in upstate NY had a Windows box that she used for exactly two purposes: email, and playing online Scrabble. Her Windows machine got full of malware, to the point where it wouldn't even boot. While she was visiting us in California this summer, I set up a machine with Ubuntu for her to use, and she got fairly comfortable with GNOME and Firefox. I sent an Ubuntu install CD home with her on the plane, and she went ahead and installed it with virtually no problems. I only had to talk her through a couple of issues on the phone, the main one being non-Linux-related: her BIOS wasn't set to boot from a CD.
She got going with email, and then it was time to get her set up for scrabble. The one she plays isn't the famous facebook one, it's a java program that accesses a club's server in Romania. Well, I think I spent about an hour with her on the phone, and we still don't have it working. One thing that took us a heck of a long time was that when she downloaded the jar file for the scrabble app, neither of us could figure out where the file had gone. Probably if I'd been in the same room with her it would have only taken me thirty seconds to locate the file, but over the phone, it was more like I was experiencing it from her point of view, and it was completely confusing. She was clicking around in the Firefox download manager, in the GNOME file manager, all with no luck. It seriously took her about 20 minutes, *with my help*, to find the file. It probably didn't help that I use fluxbox myself, and am not familiar with GNOME or its file manager. (Now we're almost there, except that apparently she's got a completely dysfunctional version of the java runtime installed. You click on the widgets in the program's UI, and it doesn't respond.)
Anyway, what kind of indictment is it of Firefox/GNOME's usability when it's easier to install Linux than to find the file you just downloaded?
Of course now I have to slap a steel helmet on my head to withstand the inevitable onslaught of know-it-all slashdotters telling me what an idiot I am, and how I could have easily found the file. Of course that's always how it is with usability. To the person who already knows how to use the software, it seems painfully obvious.
Find free books.
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.
From the headline I thought this was going to be about lost/cross-linked clusters not idiotic users forgetting where something is saved. You can improve the problem in this story by implementing better and more intuitive search features through to overhalling the traditional file-browser window implimented on all OS's that I see.
These changes are independent on the underlying file system which could be anything from fat16 through to reiser ... heck it could even be PICK or a relational DB. Of course - some FS's naturally lend themselves to a particular style of search/browsing - but that simply makes it easer/harder for the interface developer. They are still very seperate things.
Changing the file system will NOT solve this problem
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
This is largely the idea behind GoboLinux I think. As a matter of fact, a lot of what's going to be said here has probably already been said here.
By what name do you wish to be mourned?
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
Tracker and Beagle already do this for Linux. They are very fast too, since they scan new/modified files and build an index of their content and metadata.
http://www.mhall119.com
Don't like #1, at all. Users already fear that they're going to break something. This would make it a certainty. Under this sort of paradigm, the user will accidentally delete the content or reformat it with some horrible font, and will find that even drastically uplugging the box doesn't prevent their changes from being saved.
So you introduce an undo history, now the file grows huge, plus anybody who gets the document now gets to see all the embarrassing mistakes made during the document's creation. Who wants their boss to see they spent an hour fiddling with fonts?
You also lose the distinction between good content and temporary content. Saving can be used to indicate that what is saved is good, your way will contain whatever was last there, including half done reorganizations and the cat walking on the keyboard.
Don't like #2. How do you identify a photo by content? By looking at a grid of 5000 photos and trying to find the right one? What if you're editing and made slight changes like size, cropping, red eye reduction, format changes that are hard to see on a thumbnail?
Don't like #3 either. In any office you'll end up with several screens worth of documents soon enough.
#4 partly implemented in KDE. Usefulness is limited for anything besides images or documents with very distinctive appearance on the first page
#6 already exists in multiple forms
{} \; forks and starts a grep for every file found. /media/disk1 /media/disk2 /home too. Or using rgrep, that saves you one more character to type.
{} + is rather what you might want to have - so it starts a grep with several files as an argument.
Although with GNU grep you can as well simply grep -rli "monkey"
HTH
"First they ignore you, then they laugh at you, then they attack you, then you win." -- Mahatma Gandhi
The problem is that the user couldn't find a file. The solution is a better INTERFACE - this has absolutly nothing to do with the file system!
I agree with you. To make file systems work for average users, what you want is this: full text searching on the contents (plus name, tags and other metadata) and an index that updates as soon as the file is saved. Possibly with some smarts on parsing the query, though Google demonstrates that you don't need that much there. This then needs to be integrated into the standard open dialog, and apps need to use the standard dialog rather than rolling their own (I suppose we ought to have a few open dialogs, e.g. one for "text" files and another for images). The vision then is that users can search for it using what they remember about it: this will work better than anything else since it doesn't assume the operator has a tidy mind.
BTW, the "update the index immediately on saving" part is important; too often I've seen users close a document and then immediately think "ooh, I didn't mean to do that". This means that you can't put off the update until a cron job, and you hence need incremental update of the search database. (It's this that Spotlight on OSX gets wrong too.)
As you say, none of this has anything to do with actual filesystems; you could even do it with FAT12 (though that's a horrible horrible FS!) This is all about applications and how they present the FS to the user. (I'd not present the actual directory structure by default; it doesn't help the untidy minded and the tidy can click/shortcut to reveal the structure.)
"Little does he know, but there is no 'I' in 'Idiot'!"