Storage is an exciting project to replace the traditional filesystem with a new document store, database-based. It is part of a larger design for a new desktop environment, more details on that to come in the future by GNOME’s Seth Nickell. The current implementation, built under Gnome for now, offers natural language access, network transparency, and a number of other features. Some additional info is here. Update: Seth is replying at Slashdot about Storage.
Where Innovation Happens: Storage
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
This actually claims that i’ll be able to search for files by typing things like “that picture of a goat on my roomate’s computer”.
Unfortunately, gnome doesn’t have any idea who my roommate is, so who knows what I’ll get.
Secondly, how does this filesystem know it is a goat? Do I have to hand code metadata for every file?
Thirdly, I misspelled “roomate”.
This “natural” language interface would be more irritating than useful, as the technology won’t be there for several years.
-Hugh
Regarding mispelling, there are 4 simple rules that you can easily implement to your code to catch mispellings. Google is using them, and I used them in an AI project I used to work back in the ’90s.
Speaking about Storage in general, I hope it comes to life soon, it really sounds exciting. It reminds me of BeOS’ BFS on some features it has (e.g. live queries (“Storage objects are “alive”) and metadata), but the Storage implementation really takes the idea much far ahead than BFS ever had. So yeah, it is innovative and stuff.
I laughed on Seth’s remark on “funny hacks with .desktop files…”. Hehe… I agree with him 100% on that.
I mean, if you sort your files properly on your computer, you won’t really have that problem. IMO, a program like that will only encourage laziness… Still, it might be interesting for many people. I guess I just don’t see it as useful for me.
That’s what people were saying before hierarchical filesystems came about, in the 60s. They were saying “who needs directories? If you properly name your files, you can find them easily”.
Secondly, how does this filesystem know it is a goat? Do I have to hand code metadata for every file?
People already give images metadata — meaningful filenames. If people put them in meaningful contexts, like photoalbums with captions, all the better.
But maybe you can do a fuzzy search of “blobs of white and green, ignoring files in porn folders” if anyone has a handy free library that can do this.
I mean, if you sort your files properly on your computer, you won’t really have that problem. IMO, a program like that will only encourage laziness… Still, it might be interesting for many people. I guess I just don’t see it as useful for me.
Don’t forget a nearly identical argument applies to garbage collection.
Um… Well, I guess people had fewer files in those days than now…
I’ll try it when it’ll come out. Perhaps I’ll find it more useful than I think.
I would rather the computer put the photos into albums with captions on its own.
But the problem with using captions as the canonical semantic representation for the meaning of the file is that with natural language, there are multiple ways of saying the same thing.
Like if I caption a photo “my female horse”, and then ask for “my photo of a mare”, the computer would have to know they are the same thing. I personally would rather not fill up my disk with possible mappings.
And since this is a file system, there is no way to cover all possible meanings of every phrase. The domain is way too open.
We’ll end up with the google approach, where you do multiple different searches with different words, all expressing the same idea. how natural.
-hugh
I personally would rather not fill up my disk with possible mappings.
Hmm, this might not be a problem. Various servers would hold these association lists; and if you ever lost your internet connection, mappings from previous searches would be cached locally. Cycorp could make revenues from this tiniest application of their technology, like Google does. A lot of AI techniques are overkill if you’re looking at a useful 20% of what you want from an AI system. Of course, people who expect 80% will be shafted…
Now that Google has Peter Norvig, I’m sure they’re eyeing things like this.
I haven’t readit full (I’m in a cyber cafe, I don’t have much time), but this sounds awfully like Longhorn. Would it go to Free Desktop? Hopefully KDE would pick this up, it sounds nice. And I wonder, would this be available to other OS besides linux?
relivant back in the 8.3 days of DOS, when you had to call your files something completely weird and obscure, however, one can call their file anything up to 255 characters long, which can include spaces etc.
For me, I have stuck with the Mixture of small and upper case letters, aka, CPlusPlus-ProgrammingAssignmentOne.doc, as one example. The number of people I see calling their files pathetic and undescriptive names is terrible. It is rather funny however that these same people could organise a filing cabnet without any problems.
funny thing being that seth is halfway in over at google…
Where will this all go ? I mean the idea behind it is worth a thought but it’s questionable if these technological ideas make sense at all for daily usage. Things are complex and complicated enough these days and adding another complexity to GNOME itself makes things not easier afterwards. Wouldn’t it make more sense to concentrate on making a good, easy to use, simple but effective GNOME Desktop rather than stuffing NEW ideas with questionable benefits into it ? Yet another layer ontop of another layer ?
What I mean is, concentrate on the Desktop only, make it become good, make it become usable and make it become nice, make apps become better and less buggier and so on. Try to merge a few libraries with duplicate stuff into one common library and reduce complexity for maintainance (so far this is more or less happening .. in a slow speed but it’s happening). Now adding such a thing ontop of it makes maintainance complex again and the only benefits for the public is ‘look we have proven that this is possible’. Real life benefits are not there.
GNOME should stay usable for the NEW user as well as the OLD users. Users that use computer for over 20 years and longer, who are used to managing files (after all the years). I bet this stuff will start to confuse these people because things are being done yet differently again from what they were used for all the years. It would totally nerve those people if they can’t store the files in the same effective and fast way as they were used to. I fear that GNOME is not just going a different new way, no I fear that it’s going a TOTAL different way trying to achieve new things and throw proven and effective concepts that people got used to for all the years over board. All this ontop of Linux (or GNU System in general). There is a lot of work to be done in what is there now, once these things have been solved one can think about new technologies.
From what I understand:
old:
Linux native filesystem
GNOME ontop of it
new:
Linux native filesystem
GNOME’s storrage filesystem
GNOME ontop of it
Ok there is also GNOME-VFS between it but it’s more a service layer for all sorts of protocols ftp: http: and so on which again deals with the native filesystem.
I have to share the view of the person with his ‘goat’ picture. If I have a goat.jpg and have it stored in ~Desktop/MyPictures amongst 20 other pictures then I have a thumbnailing feature which quickly guides me to the picture not to mention that I may know the picture anyways because I have stored it there. Same with mp3’s if I have a ‘Motelday.mp3’ and I know it’s from the group ‘MyGroup’ then I simply store it in a MyGroup dir and know what it is.
It’s even proven in Human research that people are quicker in finding stuff by looking at symbols (colored signs such as pictures, objects, elements) rather than reading textfiles ‘This is a goat picture from june 2001 which I have taken with my parents on blah whatever blah’. There is no need for such explainations because everybody knew who his parents were and what a goat is
Storage is a very good concept. I can’t use directory structures to organize my files anymore, they are too many. So using something like Storage would help me to use relational database techniques, instead of hierarchical structures.
Has anybody tried using this yet? It at least sounds cool. BeOS needs something like this to make it even easier to use!
This is not a new concept, far from it.
Hummingbird – http://www.hummingbird.com – have done document management for many years.
KnowledgeTree – http://www.jamwarehouse.com – is a good Java-based GPL document management system.
It does look like it has a few useful ideas. But at the moment is seems far too geared towards personal use.
Searching by phrase when you have 100s of 1000s of documents is just not going to work overly well. I’m going to email the author with some suggestions, because this is potentially a groundbreaking project simply because it brings Document Management to the consumer – it’s an Enterprise only thing at the moment.
Doesn’t seem like much to get excited about, however I’m glad that Gnome is going to add new features, why not.
It seems these natural language queries are providing a search layer similar to the clue packets in nat et al’s Dashboard http://www.nat.org/dashboard
However, not only does dashboard provide a way to see associated items with whatever the user is doing at the current time (eg a Gaim conversation, Evolution folder browsing, etc), it also has a Query interface.
Now, imagine integrating Dashboard with this natural language storage searching and you have one killer app for the Gnome desktop.
One day the King’s man is going to come to the GNOME House and there will be reckoning.
GNOME has shamelessly copied their entire architecture and functionality set from Microsoft, including this latest rip-off of WinFS.
The patent lawsuits are not going to be pretty.
If that were true than the patent imbeciles would have prevented .Net from existing because it is a rip off of Java. Damn near everything that Microsoft does including the Windows desktop and WinFS was taken from some other company. You can have as many software patents as you want in the USA but the rest of the world shouldn’t resort to dictatorship and Nazism.
You can believe that Microsoft invented everything if you like but I’m sure as hell not going to. And that’s where it ends.
What if i unpack a package with 500 videofiles and i want to watch them all. Do i write: “play all movies created in a hour”, then how about if i want to see those same movies at later time.. like a year after that when i have forgotten the date. What do i ask from the computer then? Maybe i could list all the movies by writing “list all movies” and start to browse them from there.. quite a chore.
Compare this to “goto directory, select all files, play” and “delete directory”.
So, as the only way to access files.. no. As an additional metadata system on top of the normal hirarchial system, yes.
But how do we save that metadata. How does it transfer to other computers? Maybe writing a small database in compressed packages. But if i want to send a singular file? Well.. the programs could have support for sending the metadata with the file even if it is saved separately.. yes. Could become quite complicated, but not really a problem.. hackish.. yes.
I think that the metadata controls are set in a data dictionary or cataloge. Different users would have separate views (schemas) of the filesystem.
I think that the data is decoupled from everything (processes that manage the data) so it can be ported.
“But how do we save that metadata. How does it transfer to other computers? Maybe writing a small database in compressed packages. But if i want to send a singular file? Well.. the programs could have support for sending the metadata with the file even if it is saved separately.. yes. Could become quite complicated, but not really a problem.. hackish.. yes.”
On the Amiga, many (but not all) files are accompanied by an optional metadata file, which has the name of the data file with .info as an extension. The .info file contains an icon image, stack size setting, and any other settings that the user might want to vary.
File management programs normally look for the corresponding .info file when copying or moving a binary, and transfer that too automatically. It works.
One advantage is that it is optional. For example, you really do _not_ want metadata for every single file in a directory of 5000 separate animation frames, or emails.
I thinks it’s a great project. The default search application in Gnome has always been a little confusing. I hope Storage can replace it. But I guess I have add a meta tag for my all my future docs for Storage to work 100%.
Another database file system would REQUEST the data from the source database file system, and than a process running on the source database would refer to the file system catalog which contains metadata describing all the data in the database. If there were no constraints set on that data being violated by the request, than at that point dynamic allocation occurs because metadata allows for more flexible (but slower) runtime handling. Not sure about the specific implementation defining how the data is packaged when it is sent.
Systems that index by metadata live or die according to the quality of the metadata provided. One approach would simply be to kill off the file browser window used for Open… or Save… style functions and to replace it with metadata search or specification tools. This would make filling in the metadata description the equivalent act to selecting a meaningful filename.
For example, when a secretary writes a letter into a template the wordprocessor could automatically set up the metadata for sender, recipient, date, my reference, your reference, subject or project etc. Searching these plus, perhaps, a free text content search would be plenty for locating the letter subsequently. After all, in the paper filing days these metadata were precisely the parameters that decided where the file went in the filing cabinets.
There are problems with this sort of scheme, of course. The trick is to come up with sensible sets of metadata for each of the collections of data and to have a mechanism to select which type of document you’re looking for. Creating new types also becomes quite intricate. But I don’t think these problems are insurmoutable.
I’ve been tinkering with trying to do something like this in OO.o but I’m still hitting limits with its bugs and my lack of time to work round them.
Sounds very interesting, hope it’ll be in KDE too..
But why don’t the GNOME devs just expose their API’s in a more sane way so KDE can use it directly?
(and thus not having another duplicated library and a lot of wasted efforts for the Linux desktop(s))
The DirectFB project does this as well (all internal code is done using Gnome-style functions, API functions are done using professional looking DoWhatever() functions), and those API’s are _really_ nice, while it’s just C!
(for the record; I’m a C++ freak, I really like the DFB API’s and I dislike Gtk/Gnome-style API’s)
Gnome API’s could be like that as well.. just keep everything the current style for the internal code, but give the exposed API’s a nice and professional ‘look’ and make it usable for other (non C) projects.
That way everyone gets what he/she wants and we’re all happy (and we’d see a lot more innovation on the desktop, instead of duplication).
GTK+ functions are not difficult to work with and they are localy named and ordered, but developers could use a special IDE for GTK+ that did code completion just like in Visual Studio, you type in the first few letters of the function and you get a list of possibilities to select from, because the GTK+ C function names are longer than C++ class names if you use namespaces.
With regard to the file system, I guess it depends on how far the developers are willing to go to write modules that support the handling of the data. How many different processes are needed to manage access to the data to support their requirements. What are the requirements? That would be nice to know.
How many levels of abstraction are there in the filesystem? There must be a physical layer and a conceptual layer, and there is a mapping between them (defined by metadata).
If you want to use StudlyCaps style APIs (which many find slower to read, btw) then you can always wrap them. The reasons behind using GObject are well documented, it makes creating language bindings a lot easier, for one. If anything that makes them far easier to use from KDE.
From another perspective a database file ssytem could consists of modules that support concurrency, logging, queries, etc. These management modules acting as live processes (daemons) stand between your data and your applications. In the past an application had direct access to the data in a file system through a static interface, but now there will be a management system (called storage or something else) in the MIDDLE, which will offer a more natural presentation (views/schemas) through the internal use of metadata and consequently runtime flexibility.
Seems to me that Gnome is following a bit to close on what Microsoft is cooking for Longhorn. Who will get it out first?
Windows filesystem (NTFS)
SQL Server (WinFS)
Windows Longhorn
Linux filesystem
Gnome storrage filesystem
Gnome 3.x?
Like I said, it’s not innovation, not this time.
Isn’t it the technology that M$ promises to be developed for Windows LongHorn ? I think that linux will have this implemented before Windows … 🙂
Except that this kind of systems have been on paper for a decade. I can remember even Linux developers talking about this long before anyone ever heard of any WinFS/Longhorn stuff. (BTW. For working implementation check BFS (Beos filesystem).. not exactly exactly what storage is but close.)
But maybe you are just trolling?
It is a nice dream that there could be a relational database of all the files you can access.
Google or similar search engines give access to the text (only) of the Web, and could be extended to cover the text in all local documents. This could be useful in an office for finding letters and reports.
The problem comes when trying to index images or sounds. How do you automatically index 1000 drum loops? Or several thousand images from a digital camera?
> You can have as many software patents as you want
> in the USA but the rest of the world shouldn’t
> resort to dictatorship and Nazism.
1) I have no idea how you made the Nazism connection,
2) the thing is that patents give US companies a competitive advantage, which is why the EU is in the last stages of “inventing” them for the European market, too… thank you, US! NOT!
Before you put something down give it a try why not? You might be pleasantly surprised. A lot of you are condemming this without even trying it. If hyperdata were such a repulsive idea then what on earth are we all doing talking about this now. Hyperdata is like hyperlinks right? Everything is ‘aware’ (though still largely unaware) of the existence of everything else and can be easily stored searched and referrenced just like hyperlinks? Seems more like a case of natural evolution to me.
But really, honestly, before you write it off, give it a go. Then if you feel you still hate it, come back and give your verdict. I really don’t see what all the fuss about it is in the meantime. No one is ever going to force you to use it.
Q
I’m with the first post. Need a backend gestalt to understand the objects and actions of natural language. An aggressive project indeed.
And keep your little baby terminator away from sharp objects.
The good: It uses metadata.
The bad: It uses metadata.
People will have to enter metadata, and that will be the downfall. The more people have to enter, the less people will use it. Most people are lazy.
Of course, if it was automated, it may be better. Like, if you could hit up IMDB’s information for Minority Report and have it automatically entered.
Otherwise, I don’t see it catching on.
If that’s the case then why is practically every MP3 most of us have lying around is embedded with ID3 tags? Writing metadata doesn’t need to be any more complex than naming a file does, in fact, it can be far more intuitive. If the Save dialog / underlying filesystem handles things properly, then it’s FAR easier for your average human to type something useful about the document than trying to type a really long file name which they can’t find later anyway. Instead of saving an image file with a file name, it would present you with ID3-like fields appropriate for an image, same thing for saving a movie, a word processor document, etc; Just like mime-types, once it becomes a standard, then you don’t need to manually modify it, it will most likely be done by somebody else, easy to look-up (ala CDDB type system), or natural to do when you create the file.
Like Charlie said. This is not a new concept. I have been on several projects (@ different clients) where we have built something like this. It really comes down to 2 main tables. One the actually file broke up into chuncks storaged in a binary(255) field. The other is a table to help orgainize the files and assign them to groups.
Systems like storage are great for serving content over the web and through browsers. You never have a physical file on the web servers. All you do it stream it back to the browser. It’s also a great way to store static reports that are generated by a nightly task.
Its a very cool (and faily easy to implement) system.
If you follow this UI paradigm to its natural conclusion, you get back to the shell. The easiest interface for accessing documents is a smart command line. Browsing is overrated; this business of moving files around is unneccessary if you have a reasonably well indexed document store.
I imagine a situation where I type (or say) “email that picture of the goat to asher”; the computer asks which of my multitude of goat pictures to send, and gives me the option of editing the email body.
This is the way computers should work, but I’m not sure that we’re there yet. In any case, Storage looks useful, if for no other reason than research.
Having an embedded ID3 tag in a MP3 is a thing. Having a valid one is completely another. I rewrote at least 80% of the tags I had on downloaded mp3 files because they were either incomplete or full of mistakes. I also corrected around 25% of the FreeDB queries I made for the same reason. Personally, I don’t think that bad practice would really change…
Btw, I believe there’s already something called EXIF for JPG files that basically does the same thing as a ID3 tag.
First off, I have to say that Apple was developing a feature SIMILAR to this w/ Copland. (IIRC) They were featuring dynamic folders. You would make a folder that would search for certain qualities of files (i.e. text contained by them, or metadata, name, et al.) It would maintain these folders, and refresh them.
Now, I have a comment about the effects of this on developers. I believe that developers would have to “get smart” about metadata. In other words, they would have to spend more than trivial amounts of time worrying about metadata in their products. They would have to think about metadata from the ground up. As a Comp Sci student, I may be slightly ignorant, but it seems that in many ways, metadata creation/management is not a high priority on the list of many developers. Perhaps in order for this system to work, it would require either more input from users, or more forethought and planning from developers in regards to metadata.
One thing of note I would like to mention is that a buddy of mine won some national science award for his projects involving computational linguistics, and visual recognition by computers. He started by giving the computer a few fundementals, and had the computer cross-reference a dictionary. Another project of his was to have a computer recognize and be able to identify certain physical objects by their characteristics. It is projects such as these, and artificial intelligences that will continue to refine, and polish these technologies.
One last thing I have to say, is that it’s amazing what kind of computing power we have now, and that if your needs are better met by this kind of technology, you CAN have it.
Finally, we’re getting computers closer to humans. I don’t know anyone who cleans up his whole room, including letters, CDs, DVDs and books in a hierarchical and alphabetical order. Current computer software forces us to do that, instead of trying to understand the way humans organize things.
Humans should not have to learn how to use computers but computer should learn how to understand humans.
Where in the original filesystem will a newly created file be placed? Would it be possible to navigate the original filesystem with the command-line? Or should we just lose the command-line, it is not like it is being used anyway 🙂
Most metadata is entered in by the application used in the first place.
Or should we just lose the command-line, it is not like it is being used anyway 🙂
Command line and GUI should cooperate, not compete. Wether I enter “resize photo #3 on my digicam to screen size” in the terminal or click appropriate buttons in a GUI, both should call the same backend routine for bicubic interpolation. I’m still waiting for the day when I can pipe the text of a web page viewed in a GUI browser into my GUI text editor via a shell command.
Sounds a lot like WinFS to me
Always playing catch up it seems.
The problem of performing queries with descriptions like “The song i was listening yesterday between 3:00 and 3:30” is an easy task considering data that is stored in file types such as MP3s and Word documents.
All these contain title, author, and among other information you can always retrieve when it was last accessed and the exact timestamp it was created.
IMO its a way to use all this extra disk space you get when bying one of these LARGE disks like 40,60,80,120 GB
Consider the space required to store every modification you do to a project and comments on every little change you perform just to be able to drag that slidebar and watch the projects history.
On the other hand such detailed recording of each project and action taken on a computer could be used in a variety of purposes. Its good to keep track of your work but it could be used as a monitoring tool too. And not only for your roomate.
For example:
“List all the files employer Bill was working on between 9:00 and 17:00 today”
So maybe Storage has a very narrow user target group….like 3d animation companies where the need to track the projects progress is high, or libraries, or schools.
Maybe Storage is not targeted for the average user.
OR it may create its own target group of new users who will be educated using such a filesystem and keep everything “IN ORDER” around them.
Catch up, except for the fact that Storage looks to be available long before any implementation of WinFS. And also, it’s not like WinFS was a revolutionary idea–<speculation>it’ll probably end up being a dumbed down version of Access.</speculation>
I’m really excited to see this. It looks very promising and usefull. I hope everyone who has their doubts at least tries it for a week once it’s ready.
Yes, most would be entered by the software, but what about when it cannot be.. like mp3s, divx, ogg, pngs, etc. People have to enter these, and they will only enter how much they want to. If they forget something or put it in wrong, then it won’t work.
Mp3s are a perfect example. They have metadata, but about 80% of the mp3s I have don’t have metadata. And of the 20% that do have metadata, I would say that 60% of them have errors. Filing by metadata becomes quite a chore to do then, because I’d have to fix all those mp3s and add the correct metadata.
Whenever something becomes a chore, then people avoid it as much as possible. Heck, most people I know barely can separate their documents (thousands of them) into folders. Most just keep them in My Documents… I doubt they’ll take the time to properly add metadata to everything.
I can see how this could make the situation better, but I just don’t feel that it will.
#1 Find the enivitable link to the same article on slashdot
#2 Filter for moderation of +5
#3 Copy the key phrases from those postings
#4 paste and post it here!
Some people here have clearly figured that out. Welcome to the realm of the pseudo-intellectuals!
IMHO I think this is a great (but not new) idea that should have been implemented years ago. I find it hard to believe that know one has recognized the implications for this type of file system combined with voice recognition. In the future of computing I would rather say “Computer, what files do I have on Chaos Theory” or “Pull up the file I was working on at lunch yesterday” than “Computer go to my documents folder” then “Computer go to my Theories folder” and “Computer go to my Chaos folder” then “Computer open my chaos theories document”. not only would I have to remember what folder I put it in with out any visual feedback, But I would have to find a logical place to save it in the first place (without any visual feedback). I think that before voice recognition could ever be used A file system like this would have to be in place.
Hmm.. question; does it support real queries?
eg. Not writing as Joe User, like: “Give me all photos with Britney Spears on it” but like “SELECT Britney Spears FROM photos” or something like that.
Could be faster for hardcore users, I think
Sounds like a fun project. Don’t know if it’s useful, but it is interesting.
I do have one issue. If this would be used in a multiuser env., would it be possible for one user (root?) to see another users metadata. I wouldn’t want my boss to be able to track the files I work with when I’m at work. Maybe metadata could be optionally encrypted?
>> If you want to use StudlyCaps style APIs (which many find slower to read, btw) then you can always wrap them. The reasons behind using GObject are well documented, it makes creating language bindings a lot easier, for one. If anything that makes them far easier to use from KDE.
It depends on the names of the methods..
Methods like HocCocoPock (or whatever
) are indeed quite hard to read.
(so it actually forces the programmer to use well chosen names, another big win)
Personally I think it looks more professional as well.
Using GObject may make the creation of language bindings easier, but it’s double as hard and it takes much more time to create something in the language they’re written in (C).
Wrapping them is not an option as there are already way too much wrappers out there
I rather fill up my memory with useful code (I think I’m not alone with that).
btw. I just noticed Autopackage does it the DirectFB-way as well, cool!
(much appreciated!)
I know how to program with different front-ends. My problem is, if you don’t dictate a position on the disk for the file you created, how can you run a command-line program on it. The command-line we have now use the old file structure, so where will the new file be? Should you use a query to find it?
ex:
rm “the essay I wrote yesterday about the computers interface”
I’m not trolling, I just can’t see how it will cooperate.
I wonder if he has looked at Reiser4, which will be in 2.6? Sure, it is Linux (or other GPL kernel OS) only, but it does do transactions, and many other handy DB type stuff. It looks like it would be a good fit.
Looks like the OSS developers are busy going where many others have gone before. I find it suprising that Bill Gates’ biggest concern about OSS is it’s ability to quash innoovation. I don’t think he has a thing to worry about, personally. I’ve never seen innovation from the OSS community. A lot of copying, maybe, but no innovation.
How do applications use data files on this filesystem?
They have no use for this kind of thing… So will a conventional filesystem remain for applications to use?
What happens when you want to interact with applications data files?
In fact, I’ve been doing the same thing with dynamic webpages for YEARS. It’s called a SEARCH ENGINE. It’s unfathomable how you people can call this thing new. Sure, it has a few new nifty features, but at it’s base, the files are still THERE, and you find them by typing a SEARCH TERM. Nothing new about that at all. I could implement all the features mentioned into the many intranet sites I’ve already built. Would that make it a new technology? Hardly!!!!
GNOME is certainly not playing catch up MS. If anything they’re both playing catch up to IBM who’s had something similar on their AS400’s for close to 20 years now, and it’s exsisted on paper for almost as long as there have been Relational databases. At any rate this is not the first such project, and it’s not a new or revolutionary concept and the theory isn’t hard. The problem is making an interface to the system that is better than the current system.
Hmm, itegrate CYC with this and it could be very very cool.
http://www.opencyc.org
Then again, the jury is still out on if CYC will work well in practise. I think it will.
IF this system were able to sync up with the internet, it could use a fingerprinting scheme on the audio to look up metadata. Additionally if metadata were available and you wanted to search for say “led zeppelin songs mentioning gollum” it would use the metadata to find led zeppelin songs and then using the metadata perform a lyric search on google or something to find the correct file. perhaps we need a better shell, or maybe one needs to have a most recent searches stack in their shell, then they could do something like
yourbox# search for led zeppelin songs mentioning gollum
yourbox# mpg321 $s1
or
yourbox# search for kung fu movies
found 10 matches
…
enter a number or refine your search: filter shaolin and soccer
yourbox# search for kung fu subtitles for shaolin soccer
yourbox# mplayer $s2 -sub $s1
I have a feeling that some sort of interface like this will speed up CLI usage, but I have doubts about situations like
yourbox# wget http://some.web.site/some.html
A user will still have to navigate the file system when creating files from the CLI. Additionally CLI programs will need to be updated to include metadata. Like the CS student said, metadata will become so important that many programs will need to be redesigned to take advantage and not break the system.
JAAC
Microsoft has been working on a SQL driven filesystem for almost 2 years now. Its part of longhorn.
and if they keep trying some OS might in a few years actually be where BeOS was in the mid nineties.
This sort of software may not be a geek’s dream, simply because most geeks are very familiar with how their own files are structured; I rarely do searches on my own computers because I know where everything is.
However, in a business environment, not everybody uses the same techniques for sorting files (and not everybody sorts their files, period). The result is, from an organizational standpoint, a sloppy mess of files being traded over email, with old versions colliding every now and then.
Integrating an application like Storage into the GNOME desktop would make it that much more attractive to businesses, where hundreds (if not thousands) of people need intuitive access to the same files. When I say “intuitive”, that means a minimum of three or four mouse clicks; otherwise users will get frustrated or confused.
Anyone who is unconvinced that this represents a step forward in user interfaces should read Seth’s HCI paper; it provides a very rational proof for why Storage (and apps like it) make a computer easier to cope with.
BeOS had this kind of feature but with a different design.
Instead of tons of libraries and user-space daemons it had a C++ API, 2 libraries, a kernel and some user-space servers.
This project is good, but it could be implemented better like every X Window desktop.
Want it NOW. I’m sick of chasing previous versions of word & excel documents for lusers. This would fix SO many problems for me, not the least being indexing & searching all the damn marketing shots (photos) taken over the years.
Our current filesystems work – but are DUMB (no inbuilt smarts). This is ok for a disciplined single user, but for an enterprise we need something better – most people dont care where the file is, they just want to get it back when they need it.
Going to watch this one carefully
Backquotes:
gimp `stq 1 “pictures & goats & date > ‘last week'”`
(feed path of first picture of goat more recent than last week to gimp)
Or someone could actually write a CLI shell that isn’t stuck in the 70’s and understands the storage system and queries natively.
http://developers.slashdot.org/comments.pl?sid=77333&cid=6884534
Yes the author gives some more info. Now were’s my karma?
BTW There are reasons we usually experience deja vu, with ideas from the past.
1-Economic.
2-Technological.
3-Political.
Has held many an idea back.
“reiserfind” will be one of them … SQL like queries on filesystem.
Those of you saying “I mean, if you sort your files properly on your computer, you won’t really have that problem…”
obviously don’t deal with large amounts of storage on a regular basis. It’s completely expected to hear that from somebody who only works with a few 10^9 bytes of data or less on a daily basis. You really have no idea how much you can(and how much people DO) store on a modern hard disk.
How many of you out there REALLY have a good handle on your MP3 collections?
This is no longer your dad’s 50MB drive with a ISA controller telling the drive what to do and where to go to get the data the controller(read system) wants. These are high-speed networked devices talking to each other through many layers of abstraction. Your data is already an amorphous EM glob spattered around the disk in whatever way makes most efficient sense to the disk. The old arrangement of track-and-sector is dead. Directories are like browser bookmarks; beyond a certain point they just don’t scale.
You need an intelligent interface, both under the hood and in the UI to make sense of it all.
We really need to stop looking at filesystems as “filesystems” and more as a pile of stuff thrown in a heap in the corner using a wicked-smart/fast search engine to plow through it.
File cabinets and folders are really an applicable analogy anymore. Instead we should be thinking haystacks and prescient magnets to pull out just the needle we want.