Shuttleworth On Redefining File Systems 414
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.'"
Comment removed (Score:4, Informative)
Expansive syntax, and the work required.... (Score:5, Informative)
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--
Re:This would be easy (Score:5, Informative)
So like Tracker that comes installed by default on Gnome based distributions then?
Or Beagle, that was released somewhat before Spotlight.
Re:I think he failed to identify the problem (Score:3, Informative)
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.
Re:This would be easy (Score:5, Informative)
"duh just type ~rf - m" or something something, because yeah, a menu to do that would kill someone
For no one thing would a menu item to do that thing be particularly bad. But you can't put _every_ task in a menu, because there are infinitely many tasks.
If you find people often tell you to type in commands you don't understand, it's probably because it's the most efficient way to do something once you do master it. See for instance http://www.linuxquestions.org/questions/linux-newbie-8/modifying-functions-678643/ [linuxquestions.org]. I've built a 1650-byte podcatcher in #!sh [and that's including proper error-checking and all].
It's also dense communication-wise; compare "sudo ifconfig eth0 192.168.0.1" with "System -> Administration -> Network; unlock, wired connection, properties, enable, static ip, 192.168.0.1".
That being said, though, deskenvs should support the most common and important tasks in an easy-to-use way.
Re:This would be easy (Score:4, Informative)
Honestly, "I just saved a file and now I don't know where I put it" is more indicative of the human operating the computer, than it is of the computer apparently lacking facilities to find the files.
And this statement perfectly demonstrates why Linux is not now, and will not be for a very long time, a true Desktop OS.
The Interface Matters. Linux has the technology down pretty well. It's not always the best, but it generally has the most breadth. The problem is the interface is designed around the technology, and not the humans for which the technology exists.
Your statement is, essentially, "Linux can do this task just fine, the problem is most people don't take advantage of it." Simply leaving it at that, and blaming the user, is not going to improve matters. On the other hand, if you look into it further and ask, "why don't people use this functionality?" might lead you to a solution that people will use. However, such inquiry is anathema to the Linux ethos.
The problem lies not with the user, the problem lies with the Linux programmers who show clear disdain for the needs of their users[*], giving primacy to the nature of the technology instead.
Doing that gives Linux all sorts of flexibility and technological capabilities, while simultaneously making it a fundamentally useless desktop OS.
[*] Some people like to imagine the target users are not desktop users, but sysadmins and Linux programmers. Fair enough, but this whole thread is based on the premise of Linux as a Desktop OS. Designing a system for sysadmins and Linux programmers completely precludes any notion of it as a Desktop OS to anyone outside of those groups.
Re:In other news, (Score:5, Informative)
Re:Simple solution (Score:3, Informative)
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.)
Re:This would be easy (Score:2, Informative)
Re:We need a tag based filesystem (Score:3, Informative)
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.
Re:In other news, (Score:3, Informative)
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.
Re:This would be easy (Score:3, Informative)
Tracker and Beagle can. They can also search your email, IM logs, browser's bookmarks and history, installed applications, dictionary, Tomboy notes, open windows, and God only knows what else.
Re:In other news, (Score:3, Informative)
{} \; 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
Re:This would be easy (Score:3, Informative)
ever thought of "dpkg -L awesome-widget" ?
Re:identify the wrong problem get the wrong soluti (Score:4, Informative)
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.)