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.
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--
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?
Not really. It will just make systems appear childlike in nature to those who are willing to learn, and generally unpleasant to use. Of course, I started out in 1975 on a mainframe and spent a lot of years after that at the command line, so perhaps I'm not the best person to ask. But, like most other things in life, there's a balance that has to be struck, and no matter what you do people will still be required to learn something about their machines.
A lot of that goes to motivation: people learn some pretty damn complex activities when it comes to earning a driver's license, for example. Yet, when it comes to a computer many of those same people can't be bothered to put forth one iota of effort.
The higher the technology, the sharper that two-edged sword.
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?
Making all music-related apps open up a "My Music" directory by default is fine. (Although assuming that everybody keeps all their music-related files under one directory and never mixes them with other kinds of files is IMO oversimplistic.) Letting the user change the default directories and create their own symlink shortcuts would be an additional requirement.
The problem, which has been popularized by Microsoft's Windows Explorer and gets worse with every new OS they create, is making the default directories *look* like roots, even though they aren't. You can't navigate upwards from the "My Foo" folders in the GUI, and therefore you usually have no earthly idea where the files actually reside in relation to everything else. Thus, when you want to do something with a music file from an app that doesn't usually deal with music, you might not be able find it in that app's GUI. (Unless, for example, all the apps in Windows are changed to use the same obscure wishy-washy APIs that Windows Explorer uses to kludge up fake roots. But I think that approach is just making the problem worse instead of fixing it.)
Not that well, you can see many problems right there.
For instance, photos about DragonCon in 2008 are going to be tagged as: "DragonCon 2008"; "dragoncon2008"; "dragoncon" and "2008", "dc2008", "dc", "dragon", plus include typos ("dargon"), and so on.
And this is an easy example, with a distinctive name. Searching for keywords that are not so unique is a lot more challenging.
Also, the first convention was probably just tagged as "dragoncon", making it hard to filter out of the rest. And which such a large amounts of variations you never can be 100% sure you searched all that's searchable, because maybe that one cool photo of Dr. Octopus was tagged as "dc2008" and you didn't think to try that one.
With personal files you also have the problem that you need it to work 100%. It is fine if my search for convention photos, or some landmark misses 10% of them due to them being badly tagged. It's NOT fine when that happens with my office documents, however.
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
{} \; 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'!"