Slashdot Mirror
Database File System
ozy writes "With all the fuss about searching and Spotlight and WinFS, check out the Database File System a completely different interface for your files, implemented in KDE. There is actually a request for developers to join a project to implement this under GNOME and leave how we use the desktop today behind."
Such thing should be implemented at kernel level to be transparent for *any* aplication. Without this it will just lead to a mess (like 4 different implementations) and some apps working with it and most not. As f.e. you can browse SMB network with Nautilus but when you actually try to open a file (from SMB via Nautilus) in OpenOffice.org you will get a info that viewer does not support this method... It must be a standard system routine not another level between system and GUI.
So now, you will lose access to your file system if you use a simple window manager instead of KDE?
Great idea.
Article doesn't address whether or not we can turn DBFS off and use the more traditional hierarchical method of file placement. Will we be dragged into this kicking and screaming?
How much permforance overhead will this cause? The 'Desktop Environments' already eat a lot of RAM and CPU.
How much disk space will you lose over this? All the metadata has to be stored somewhere, and just glancing over the link I read something about a versioning system, which will definently take up quite a bit of space. Will a 20gb hard drive become 15gb with DBFS?
The database file system originated from the ideas of an object-orientated database. Keywords and references are all part of the orientation objects of the database to index to files or other objects. It does away with the traditional hierarchal view, being rooted at some place. The OODB does not need to be rooted as it is more like a web. The DBFS seems to try to implement part of the concept of the OODB. Good. There are many more features an OODBFS can offer: dynamic organization, classification, and mutliple "skeletal" views to name a few. I hope that this DBFS will give a taste of what an OODBFS offers.
Depends on what you are using your computer for of course.
You can say the same thing for a GUI, and its correct for certain applications of computers, but wrong in others.
Isn't this thing with DB's getting a little excessive? You're adding another layer and step to storing data which will in all likely hinder performance. I'm not sure the benefit out weight the cost.
Well, if it's only a name-translation thingy, then it shouldn't affect performance of file reading (when operating on sufficiently big files), only file opening/stat:ing.
fucktard is a tenderhearted description
Maybe we could call it a "filing" system since it indexes files that are on another file system. Really, a file system IS a database, not an add-on that indexes files. Still, perhaps this is a better approach than trying to redo all the file-system internals. Although to be truly useful, this needs to be an API that is GUI-independent, with GUI-bindings as needed.
Why not just run in console mode? All this GUI stuff is just getting in the way of absolute performance.
If it adds 0.5 seconds to every time you save a file, but saves you 20 seconds of filesystem navigating every time you open the file, that's a worthwhile tradeoff. Add to that the fact that copmuters don't get tired or bored, while humans do, and it makes even more sense to shift as much of the burden of working onto the computer as is practical.
Not necessarily. Consider the performance of finding a document you wrote two years ago. How long does it take you to walk through the directory hierarchy browsing file names? How fast is the file search tool? Wouldn't it be faster if you could say "Show me the documents I wrote two years ago" and the refine the search or browse the results?
Storing data in a relational database is natural because it is more like the way we store data in our minds than the hierchical structures of traditional file systems.
Also, we allow a complete abstraction of the underlying database in relational systems. The database can store the data however it sees fit, and can arrange the data on disk without the users noticing a change.
I look forward to experimenting with a relational filesystem. I think it would be a wonderful thing to try out and see if it actually has the advantages I outlined above. I'd also like to see the actual disadvantages.
The radical sect of Islam would either see you dead or "reverted" to Islam.
Sorry, but I have to say it, you are an idiot!
...
Did you even care to RTFA?
This has nothing to do with the gnome or kde devs. Some developer invested his time to come up with something he thought was useful and all you can do is complain?
And if you look at the project, it is something completley different then a plugin for the admittedly great ReiserFS4 and it is here and usable right now.
So friggin stop your stupid whinig.
And to the mods who modded parent interesting
Btw., why don't you whine to the Reiser people that they should stop developing now? It would be as justified as your whining aboutt this project.
I find that a spacial interface to a hierarchical storage layout makes it very easy when I want to find my files. This kind of thing is more useful when trying to find files you didn't create / save.
I am TheRaven on Soylent News
People can offer their opinions for or against this, but I think that any innovation benefits linux. I've read about WinFS and it sounds like a good idea, but who knows when it will be ready. If people working in their spare time can get something like this working in linux before Microsoft can get it out, I think that would just be another reason to trust the open source model of developing code and squash Ballmer's FUD.
I don't have too much trouble using a hierarchy file system. I keep my stuff pretty organized, but computers are supposed to save time, not create more problems. If this database can do a good job, I'll give it a shot.
I wouldn't normally jump in except this is modded +4, even though the poster doesn't appear to have read the article.
The article doesn't talk about an actual "file system" (it admits its a bit of a misnomer itself), merely a way of referencing files with "keywords" in database that, according to the author, will make it easier to find your files. The author has written a file browser and file selector dialogs for KDE that use this, then goes on to say that he's planning to make a GNOME implementation soon, but nowhere does anyone start any name calling.
Since this article essentially discusses a GUI and not a file system (which could be implemented at kernel level), it would be a little silly to use the same tool for GNOME and KDE, since they have different look-and-feel. That said, a common library of functions needed by both the GNOME and KDE versions would obviously be sensible, and would speed up porting to other desktops.
Furthermore, this idea claims to work on top of existing heirarchical file systems (removing the idea of a hierarchical FS completely would involve a major restructuring of the whole operating system and everything that works on it), so just saying that it should use reiser 4, I suppose because its just l33t, is a little redundant. This should work on top of just about any FS, ext2, reiser, or even an NFS mount.
The problem with find is that it doesn't scale because it has to do a sequential search. locate is faster than find, but the index is not always up to date. A database could keep various indices always up to date.
Did you work on that file last month? Find all files you worked on last month. Was it a word document? Find all word documents you worked on last month. Was it for a certain project. Find all word documents from that project you worked on last month. That is the thinking the DBFS supports.
What a coincidence. That is the thinking that "find" supports, too. And I don't have to run a bloated desktop environment to use it. Cool.
Why not just run in console mode? All this GUI stuff is just getting in the way of absolute performance.
Although this is a KDE related project the concept itself has nothing to do with whether you use a GUI or not and the performance hit comes at the level of the DB, not the GUI.
As for shifting the burden to the computer it doesn't really do much of that either as a human mind still has to formulate and input the query terms as well as judge the validity of the query result.
The DB as filesystem has a lot of merit, but really only in those situations where you have a massive number of files distributed across many systems. Take Google and the internet for example.
Now imagine having to google your local system to find every damned file.
Now, maybe I'm just different, but I've got 45,000 files spread across 1300 directories in my Home directory, and I can find any one of these by navigation in under your hypothetical 20 seconds saved, but then I'm the sort of person who sorts his laundry by placing it in seperate hampers in the first place instead of later spreading it across the basement floor and sorting it out. I know exactly where all my dirty whites are up front.
And the latter sort of person isn't likely to do a very good job of entering the metadata necessary to make a DB based filesystem work well anyway. The brain is a wonderful DB in and of itself and knows the "meaning" of things as well. I already know what 14t.jpg is all about. I'd have to tell my DB what it means.
Sure, let the computer do the work that it's better at, like recalculating spreadsheets or finding redheads with big ones on the web, but that doesn't replace the brain.
I already know which redheads have big ones on my local system and where to find them no matter what the file is named and the computer can't find all of the redheads with big ones on the web unless they all have the proper metadata attached to them. Some file out there somewhere named 1038754875747.jpg is just as anonymous to the computer as it is to you.
KFG
Think of a directory structure as just one instance of a relational structure - a heirarchical or location-based one. Directories (or locations, or relationship to other files), even nested ones, are just another type of metadata. Once you have that concept in mind other things become obvious. For example you may group files by type (Image, Text) or by project, or by author. With a directory structure you either have to make multiple directories and symlink everything, or you're stuck with one view of your files.
In short it gives you multiple, simultaneous groupings of your data.
Lump lingered last in line for brains, and the ones she got were sorta rotten and insane.
Joel on Software said it best:
For example, WinFS, advertised as a way to make searching work by making the file system be a relational database, ignores the fact that the real way to make searching work is by making searching work. Don't make me type metadata for all my files that I can search using a query language. Just do me a favor and search the damned hard drive, quickly, for the string I typed, using full-text indexes and other technologies that were boring in 1973.
Laws do not persuade just because they threaten. --Seneca
It's Microsoft Java and it's awful. There may be patent problems, not with C# or CIL but the 'excellent standard library' as you say. How do you know what Microsofts long term strategy regarding .NET is? Why are .NET people .ALWAYS so defensive over vague comments that they interperet as being negative, yet .NEVER respond to questions about patents on the supporting libraries? I don't have a JVM or Flash installed either, is someone going to start jumping up and down about that?