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.'"

Comments

This would be easy

[CRCulver]

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

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.

Re:This would be easy

[tolan-b]

So like Tracker that comes installed by default on Gnome based distributions then?

Or Beagle, that was released somewhat before Spotlight.

Re:This would be easy

[jonaskoelker]

"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/. 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

[node 3]

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.

Expansive syntax, and the work required....

[ka9dgx]

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
login.com;2
login.com;3
.. etc.

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:In other news,

[woot account]

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.

Re:identify the wrong problem get the wrong soluti

[dkf]

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.)