KDE Plans 'Google-like' Search Capabilities

CoolFX writes "Developers of KDE have announced plans to simplify searching for files on the open-source Linux desktop environment by adding a Google-style search feature. The next version of KDE, which will either be called 3.4 or 4, is expected to include the new search feature... Aaron Seigo, a KDE developer, said the community has already been discussing and writing code for the new search engine at the KDE Community World Summit."

Comments

How will this work?

[SeanTobin]

Now, how is this going to work? First off, when I do a search on google there are dozens if not hundreds of PC's involved in various aspects of the search. I get my results in under a second. My computer - although fairly decent itself - is only a mid-tower. There is no way I can support even one PC to assist in searching.

Aside from the logistics problems, where the heck am I going to get the pigeons anyway?

Re:How will this work?

[barcodez]

Now, how is this going to work? First off, when I do a search on google there are dozens if not hundreds of PC's involved in various aspects of the search. I get my results in under a second. My computer - although fairly decent itself - is only a mid-tower. There is no way I can support even one PC to assist in searching.

Having played with and done some work on the open source Nutch search engine I know from experience that you can return search results from ~10,000,000 pages in much less than 1 second on a mid-range desktop. It's all done with indexes in much the same way as relational DB have been doing it for years.

Re:How will this work?

[Anonymous Coward]

Reading the link will help you understand what it is (and is not).

Re:How will this work?

[FlipmodePlaya]

I'm wondering why they're saying it's 'Google like'. Do they just mean 'search engine like', and got caught up in the brand name (like they do with the iPod so frequently)? Or is there something about it comparable only to a Google technique?

Re:How will this work?

[barcodez]

To many people google == search engine. The word is in the Oxford English Dictionary ffs. So like xerox, hoover and escalator the brand name has become (is becoming) the generic word too.

Re:How will this work?

[Jarlsberg]

Exactly, my mysql database on my 450 MHz Pentium II computer has thousands, if not tens of thousands, of key words in its database, and easily manages to serve up query in less than a second. And what's a mid tower anyway? For all that means, you can have a mini-itx cluster going on in that tower, or you can have an old 286. ;)

I've been waiting for a decent search engine app for the desktop - for both Linux & Windows. Grep is fine, but it's not always the best tool for the job. Alta vista had a decent app for the Windows desktop a few years back, but I don't know if it supports newer Windows OS's. (And not having RTFA, I don't know if my example even applies.)

Re:How will this work?

[kg_o.O]

If they used some kind of indexing daemon which would run with a low priority, watching for file changes (at least in $HOME) using famd (which a part of KDE already) this wouldn't be so bad. First indexing could be a long process, but after that the daemon would take care of changing the info about files on the fly (or some configurable interval).

Just a first-thought idea.

Re:How will this work?

[shawb]

Oh, this wouldn't be run on pigeons. KDE is of course working on PenguinRank, in which a flock of penguins (volunteers, naturally) would run the analysis. Although one technical difficulty will be in maintaining the cooling systems necessary to keep the penguins at a comfortably temperature.

Re:How will this work?

[eclectus]

not to be pedantic (or a karma whore) but 'google' is not a word. Googol, however, is a word representing the number 1 followed by 100 0's.

Re:How will this work?

[Anonymous Coward]

I'm sure that post was a lot funnier in your head.

Re:How will this work?

[Billy69]

No to be even more pedantic, but as the parent noted, the action of 'googling' or 'to google' was indeed added to the last revision of the Oxford English dictionary, and therefore by definition it is a word.

Re:How will this work?

[athakur999]

It sounds like they're just capitalizing on a buzz word. Google's big claim to fame is that their search algorithm looks at the links between pages in addition to the pages themselves. Files on your hard drive, for the most part, aren't linked between each other (aside from stuff like source code), so the Google comparison is fairly bogus.

Re:How will this work?

[Ignignot]

This is of course the kind of knee jerk reaction that any programmer would think of when confronted with the problem. You can already see it implemented in windows. Of course, every user's first reaction is to disable the searching because no one cares about fast searches of their computer, and everyone cares about their system resources. So this is a terrible tradeoff.

OTOH I think Hans Reiser has it right, just look at his vision. Built search from the filesystem up, and it will revolutionize how we think of data.

Re:How will this work?

[slutsker]

Maybe it will try to mimic Google's layout somehow? Like, when I search for a file, it will come up with 10 results with links/descriptions that make it look exactly as though I am searching Google.

Re:How will this work?

[jd142]

I would assume they'd do something like locate does, where you build the database of files first and that speeds up the searches. Combine locate's generally nice ease of use with full text searching and you could have a nice project. Even better combine it with software that let's you search your pictures based on another picture or a picture you draw. I forget the name of this software, but it's installed on my home computer and it's really cool. It indexes your pictures and then you draw a picture of what you are looking for and it will find matches based on your drawing or based on another picture.

This picture matching and the Neuros's HISI feature that will search for songs based on a 30 second snippet are the real future of search on the desktop. The big ticket is still video search, but that won't be needed on the home desktop for a couple of years.

There's plenty of processor downtime that could be used to inventory and index all the files on a computer. Many programs do this now. The only real difference is that this time it's built in to the wm. Microsoft's fast find for office, and indexing service does this as does WordPerfect's Quick Find. I find these 3 products annoying though. Mainly because they aren't (or at least weren't) smart about doing their indexing during low usage periods.

Re:How will this work?

[An Onerous Coward]

You need to ratchet up your pedantry even further. There is no specific group or organization charged with deciding what is or is not part of the English language. While the Oxford English Dictionary bears a great deal of prestige, and their decisions can be taken as strong evidence of the "wordiness" of google(verb), there is no single litmus test for inclusion/exclusion of a word from the English language.

Now, the French have an entire division of the government devoted to defining the French language, with expectedly hilarious results. Use your preferred search engine to google for "couriel". :)

Maybe it's best to keep English a little loose.

Re:How will this work?

[jongleur]

While we're exploring pedantics, it should be noted that Googol was not a word either, until it was coined about 65 years ago as an example of a non-infinite number that was nonetheless unimaginably large.

Re:How will this work?

[bullitB]

It's all done with indexes

Not indices, but indexes.

What's up with that? Why is everyone using "indexes" now?

Re:How will this work?

[BiggyP]

well, the important aspect behind a search engine style file search is surely going to be speed, to get pages of results as quickly as something like google you'll need a database containing information about your entire file system, something like locate. The problem there is that you then have to rebuild or update the database frequently for it to remain useful(windows indexing service, updatedb running on a cron job on linux, both very annoying). or will KDE sit and dogedly monitor all file system activity? I guess they want to emulate a database driven filesystem.

Re:How will this work?

[adrianbaugh]

I suspect they mean this will be a search engine using google-like algorithms, but returning results from your own computer. Though, offhand, the only files I can think of that refer to each other on my computer are local copies of websites and C header files. Perhaps they intend to introduce some kind of autogenerated data to build up some kind of statistical probability of links between other kinds of local files. Alternatively, perhaps I'm talking out of my ass - I didn't read the article any more than most other /.ers will have done...

Re:How will this work?

[XbainX]

Because saying it's 'Google like' means that they're taking a search capability for one environment (WWW) and translating it to another environment (user desktop system).

That makes it sound like they're coming up with something new rather than simply copying Apple's new Spotlight feature that will be debuting in OS X 10.4.

I don't think there's anything wrong with implementing features of your competition's product, but come on, no need to tiptoe around the fact.

Re:How will this work?

[otisg]

Exactly. Nutch really uses Lucene under the hood for all the indexing and searching. See my other post in this thread about Beagle (Gnome's file indexer/searcher, which uses Lucene.Net to do file system searches).
Obviously, there are inverted indices in the game here, so searches can be very fast. There are no grep-like sequential scans.

Re:How will this work?

[Telex4]

Hah, well here's a lesson for people being interviewed: never mention a buzzword!

Short answer: KDE plans pervasive search.

To put it in context, Aaron was being interviewed about usability in the KDE desktop, and talked a little about some plans for pervasive search technology in the KDE desktop. We're talking about putting meta-data and search technology everywhere, from the help center to the browser to the file dialogue.

Aaron unfortunately mentioned Google, and hey presto, the Internet lights up with silly rumours ;-)

Re:How will this work?

[ghum]

Hmmm... and what is "to google" on french????

Re:How will this work?

[osvejda]

Googol was not a word either, until it was coined

By nine-year-old kid!

Re:How will this work?

[Adam9]

From my experience, most people turn off Windows' indexing feature because it does not run at the lowest priority, does not exit when I need the computer, and seems to run randomly without any kind of good scheduling time. I'm sure there's a way to run it at a certain time, but it prevents me from doing any other work.

Re:How will this work?

[modecx]

No doubt.

When I hear a middle aged waitress (who's not known to be especially computer savvy) use the term "google" as a verb--and in the right context--well, let's just say that google has become a word. Just like xerox, kleenex, or any other widely used trademarks.

Welcome to our lexicon, the word "google".

Re:How will this work?

[osvejda]

Maybe the results will be sorted by FileRank(TM) determined by number of symlinks pointing to that file :)

Re:How will this work?

[ricotest]

Ah, but they are. Why else would we have directories?

Re:How will this work?

[sploo22]

Do the penguins go on strike if you try to overclock them?

Re:How will this work?

[Donny Smith]

>I'm wondering why they're saying it's 'Google like'.

I'd say it means what it says - its GUI will _look_ like Google's.
It may not work as well, though.

Re:How will this work?

[Minna Kirai]

Why else would we have directories?

That's still meaningless. Yes, one valid way to visualize a disk filesystem is with directories being a kind of file that links to other files.

But Google's trick is to classify the subject of a page not just by it's own content, but by the links that point to it- on the theory that 3rd parties are less likely to mislead about a page's true subject.

That just doesn't map to a single-user PC. Searching for file according to the directory they come under is barely different from hunting for them manually.

Re:How will this work?

[Minna Kirai]

I'm wondering why they're saying it's 'Google like'

Because, like Google, this feature will parse through various filetypes to index only human-readable text. Google can extract the text from HTML, PDF, ASCII, Powerpoint, DOC, and other files.

This will need to do that too. Otherwise searching for "font" would hit on every HTML file that changes a font, and not only those which have "font" in the body text.

Re:How will this work?

[Pentagram]

Maybe they mean that they'll be adding heuristics to return the best results first (e.g., you're probably more likely to want to see files in ~ than in /tmp). I'm not sure how the most famous Google heuristic - linked files translates (most-accesses?)

Or maybe they mean to make it ubiquitous in use, in the way people will often go to a site by typing the name into Google rather than typing the URL; I can see this being popular if you can search from the toolbar.

Re:How will this work?

[mrider]

I've been tinkering around with my own system (called POPsearch) for a few years now. The initial indexing process takes awhile, but routine index maintenance is done at a lower priority.

Re:How will this work?

[Anonymous Coward]

Simple. 1. Install Apache www.apache.com 2. Point your domin "www.[your name here].com" to PC's IP Address. 3. Avertise with google..... 4. A few days later you can serach for things on your pc by seraching google with "site*.[your name here].com [search trems here]" on google.com. Dummy (see parent post)

Re:How will this work?

[mrider]

That's partly how my system (POPsearch) does it. The search ranking is determined by a file's popularity.

Re:How will this work?

[ryanw]

Now, how is this going to work?

Probably something like Apple's Spotlight which will be released in OSX 10.4 (Tiger). Like others are pointing out, it seems that Apple brings out all the new ideas and everyone else follows suit.

Re:How will this work?

[jkovacik]

Flock of Penguins?! I LOVE that band!

"And I swam... I swam so far away... I just swam, I couldn't get away... MS has ruined my day."

Re:How will this work?

[dmomo]

How about if all KDE apps kept track of files that they opened? This could be analagous to linking to another file. So, not only do we know how often a file is accessed, but we also know how many apps access it. Now we have a context as well.

Re:How will this work?

[trentblase]

When was escalator ever a brand?

Re:How will this work?

[chris_mahan]

I have a very simple solution: put your document drive as an apache path, then let google index your hd. Then search within your domain name (you do have a fixed ip and a domain name right?)
Alternatively, copy all your files on your hd to your host.

Of course, there's a glaring security hole, but that's never stopped innovation.

Re:How will this work?

[JabberWokky]

You need to ratchet up your pedantry even further.

And you need to crank yours up even more. The OED is accepted by many institutions to define the English language. Words in use that are not in the OED are considered slang and/or technical language. While you are correct that there is no royally or federally defined definitive language, the OED is, by common agreement, the definition of the language.

--
Evan

Re:How will this work?

[littlem]

Not to be more pedantic yet, but what dictionary defines a word as something included in the latest revision of the OED?/p?

Re:How will this work?

[Anonymous Coward]

It sounds like they're just capitalizing on a buzz word.

The KDE project... using buzzwords and announcing vapourware that's quietly been developing in GNOME for a couple of years... surely not. The KDE project does not indulge in hype and bullshit... absolutely not... no... not at all.

Re:How will this work?

[Anonymous Coward]

See also: Medusa, GNOME storage.

As always, GNOME has been quietly working om this stuff while KDE jumps in now and starts announcing vaporware.

Re:How will this work?

[Anonymous Coward]

The grandparent said "by definition" not "by authoritative body"

Re:How will this work?

[AhBeeDoi]

Make that 1,000,000 zeroes.

Re:How will this work?

[AhBeeDoi]

Oops, disregard my brain fart.

Re:How will this work?

[Ricwot]

Try the Bank of English, and the Oxford English dictionary is regarded as the definitive guide to the English language

Re:How will this work?

[Anonymous Coward]

Miguel... Is that you?

Re:How will this work?

[puddpunk]

Please, just stfu now. I can tell you now why we have the "Desktop Divide" between KDE and GNOME. It's morons like you man.

The KDE project has it's share of followers like you as well, but your all the same. The only reason the desktop wars rage on is because you open your mouth with your opinion that you think everyone wants to hear.

Yes GNOME has been working on similar projects, heck it was even mentioned on Slashdot front page a while ago you idiot. KDE is getting a lot press at the moment because of aKadamy and the 3.3 release so why don't you shut up and let KDE have it's moment.

Re:How will this work?

[Trailwalker]

The OED is accepted by many institutions

Mental, industrial, vocational or one of these?

Re:How will this work?

[Anonymous Coward]

Yes GNOME has been working on similar projects, heck it was even mentioned on Slashdot front page a while ago you idiot.

Ummm... I don't remember hyped up stories about GNOME bringing google-like search capabilities to the desktop. I do remember a story full of idiot KDE flamers claiming that GNOME suxx KDE r00lz, and that KDE didn't need anything like structured storage for document metadata (GNOME storage).

KDE is getting a lot press at the moment because of aKadamy and the 3.3 release so why don't you shut up and let KDE have it's moment.

Pointing out that the KDE project is full of ignorant, stupid hype-mongers who don't know a debugger from a chisel yet still feel qualfied to comment on technical issues, is a valuable job. It's even more important when the KDE hype/vapor machine is in full flow, as it is now. So no, I won't shut up.

Re:How will this work?

[jesterzog]

I haven't used Windows for some time, but the main reasons I disabled FastFind (is it still called that?) quickly were:

1. My hardware was noisy -- frequently hearing the disk churning round and round at all sorts of random times was just annoying, especially when it'd often suddenly jump into action when I wasn't doing much and the room was otherwise quiet.
2. All of the extra junk that gets left around -- fastfind had a habit of storing its indexes as hidden files inside the directories it was indexing, which is annoying if you like to have control of what goes where.

These days good (and quiet) hardware is easier to obtain, and it shouldn't be too hard for a system to store data in its own repository instead of scattering it everywhere. If such a system could work in a way that I really didn't have to notice or care about it, it'd be fine.

Re:How will this work?

[shellbeach]

When was escalator ever a brand?

Did you even bother to try googling for it?? :) Have a look at the third hit, esp. the last paragraph ...

"Over the years, Otis dominated the escalator business, but lost the product's trademark. The word escalator lost its proprietary status and its capital "e" in 1950 when the U.S. Patent Office ruled that the word "escalator" had become just a common descriptive term for moving stairways."

Re:How will this work?

[Spy Hunter]

The people doing the capitalizing here are the journalists, not the KDE people. Probably what happened was a KDE guy mentioned Google once in the middle of a half-hour-long interview, and the reporter then decided to use it as the hook for his article title. And it worked, didn't it? If this article hadn't used the buzzwords "google-like" it would probably never have gotten on CNet and ZDNet, and maybe not even the Slashdot front page.

Re:How will this work?

[pnot]

The OED is accepted by many institutions to define the English language.

Please name a few of them, and give some kind of evidence. Most publications have their own style guide, which does not necessarily coincide with the OED.

Words in use that are not in the OED are considered slang and/or technical language.

Bollocks. The OED includes both slang (e.g. "bollocks") and technical language (e.g. "cyanacobalamin"). And that's just in the concise edition.

the OED is, by common agreement, the definition of the language

Once more -- whose? Americans, surely, would incline more towards Webster's. Scrabble players use Chambers.

A dictionary (at any rate an English one) is not a definition, it's a record. As such, it's always out of date. I suspect that even the compilers of the OED themselves would agree on this point :-).

Re:How will this work?

[JabberWokky]

Most publications have their own style guide, which does not necessarily coincide with the OED.

Actually, that's where I've seen it used the most. I work in the publication industry, specifically digital archiving and indexing, and I have seen dozens of style guides, several of which specify the OED.

Bollocks. The OED includes both slang (e.g. "bollocks") and technical language (e.g. "cyanacobalamin").

Yes, and if it is not in the OED, it is considered far enough outside common usage to require a definition within the article. In fact, several style guides specify this.

Style guides are horribly anal; I've sat in (and wandered out of) meetings that lasted for hours regarding the date at which the "to" in infinitives in titles should switch to the current style guide. Editors seem to really love butting heads over stuff like this. The OED is a common reference to agree upon, and is the closest thing to a standard out there.

As I said before, many institutions consider it the canon definition of the English language. You can deny it all you want, but I've spent the last six years flying around America and the Caribbean islands working with newspapers specifically on this kind of thing. The OED is a commonly (but not totally) accepted standard for the language.

--
Evan

Re:How will this work?

[pnot]

if it is not in the OED, it is considered far enough outside common usage to require a definition within the article.

I sincerely hope the converse doesn't hold -- you can't really expect your readers to be acquainted with every word in the full OED (you wouldn't really drop "cyanacobalamin" into a general article without a definition, would you)?

Do the institutions you're talking about use some well-defined subset of the OED as an inclusion test, or do they just use it as a fallback exclusion test?

As I said before, many institutions consider it the canon definition of the English language.

I agree that it's the closest thing to a standard we have, but my point was that (regardless of how many institutions use it) it doesn't have any official weight outside those institutions. It's not a definition of the language, no matter who chooses to use it as one. You can't meaningfully say, as Billy69 did, "x is by definition a word", because the OED isn't a definition and doesn't pretend to be one.

Re:How will this work?

[puddpunk]

You sir are a sad, sad man.

I do remember a story full of idiot KDE flamers

It sure is a pain having to read that garbage isn't it.

Pointing out that the KDE project is full of ignorant, stupid hype-mongers who don't know a debugger from a chisel yet still feel qualfied to comment on technical issues, is a valuable job.

Thats an interesting point of view. More importantly it proves the fact that you are just a troll bent on stirring things up, so I won't reply to any more of your posts. Also, I guess you wouldn't want people finding out about brilliant projects such as this. Pretty good for a bunch of developers that don't know what a debugger is.

And be sure, if you had the courage to post as a logged in user you would be on my foe list for sure. I've read almost half a dozen AC posts along the same lines. Also, do not write me off as a KDE fanboy, I am an enlightenment user and use a mix of GTK/GNOME Qt/KDE apps.

Re:How will this work?

[Anonymous Coward]

What the fuck has valgrind got to do with KDE? The most you could claim is that one of the few non-lame KDE developers wrote it -- and it's hosted on a KDE domain. Oh wow... how does that make up for the legions of numbnut KDE developers who plague most linux websites? Have you ever read kde developer websites? I have... or I tried. I rapidly got tired of reading the text equivalent of the high-five, and the constant need to state that anything GNOME does, KDE does better. Even the supposedly neutral freedesktop lists had to suffer the touchy childish and unprofesional KDE developers who were unable (with a few exceptions) to cooperate with any who didn't bow down to the QT master and constantly state that KDE was gr8t.

And have we forgotten some of the, now legendary, KDE hissyfits: Ximian, Sun, Red Hat, UserLinux. You never know what's going to set them off.

Re:How will this work?

[edittard]

what is "to google" on french????

Googler, I suppose.

Re:How will this work?

[Moderatbastard]

Parent gets modded troll, and this gets insightful. Ironically they both said the same thing. Go figure.

Re:How will this work?

[edittard]

And it worked, didn't it? If this article hadn't used the buzzwords "google-like" it would probably never have gotten on CNet and ZDNet,

You know, there used to be these people who filtered out errors, mistakes, and plain old bullshit that n00b journalists wrote - before it was published. Editors, I think they were called.

and maybe not even the Slashdot front page.

Now you really are exaggerating.

Re:How will this work?

[Spy Hunter]

If you think this practice is new, you must not have been reading newspapers for very long. Editors have always striven for catchy headlines, sometimes sacrificing a little accuracy in the process. They did it a hundred years ago and they do it today. It's not like there's any mistake or BS in this headline anyway. All they did was use a (reasonably on-topic) buzzword to increase the story's pull. And it worked, and there's nothing at all wrong with that. I'd expect this story to maybe make Slashdot's developer section if some KDE guy submitted it, but the story on CNet with its Google headline made the front page because it caught michael's eye. This is definitely Slashdot front page material, so what are you complaining about?

Re:How will this work?

[PastaLover]

couriel is actually a perfectly acceptable word for e-mail as far as I'm concerned (I'm not french though). I kinda like it actually. There are other words they come up with which are much more interesting (like the word for internet startup, but can't remember it).

Re:How will this work?

[Anonymous Coward]

Please, just stfu now. I can tell you now why we have the "Desktop Divide" between KDE and GNOME. It's morons like you man.

No, we *had* a desktop divide because the KDE project chose a proprietary toolkit on which to base KDE -- and we still have a desktop divide because KDE exists only to funnel the annual (and very expensive) license fees to TrollTech from commercial developers who don't want to be subject to the full GPL (as opposed to the LGPL used in GNOME/GTK).

Speaking of bloat...

[kpansky]

Why put this in a WINDOWING ENVIRONMENT? I mean, if he wants to do a project like this, graet! Just dont do it under a desktop banner.

Re:Speaking of bloat...

[cs02rm0]

KDE isn't just a window manager... it really is a whole Desktop Environment.

If you're after a slim window manager you should be using something like the beautiful openbox.

Re:Speaking of bloat...

[BenjyD]

Who said they're adding it to the windowing environment? They're not adding it to KWin.

It'll be part of KDE - where DE stands for Desktop Environment. KDE is much more than a window manager, it's an entire desktop system, so this is the perfect place to add it.

Re:Speaking of bloat...

[kpansky]

Poor choice of words -- was thinking desktop when I wrote windowing -- I certainly do understand the difference between the two.

Re:Speaking of bloat...

[Anonymous Coward]

This is the way desktops are going, and it doesn't have to be slow or bloat.

Searching for files is fundamentally a user interface feature, and should be included with a desktop. What other project could it possibly go under?

I for one, am looking forward to the new features planned for KDE.

(P.S: KDE is more than a windowing environment)

Re:Speaking of bloat...

[FlipmodePlaya]

Windowing environment? Is that between a window manager and a desktop environment? Because KDE is the latter (though it does have a former, obviously). A desktop environment should include a suite of apps to help you manage your activities on your computer. Hence the Control Panel, hence the PIM, hence KOffice, etc.

Re:Speaking of bloat...

[kisielk]

If you don't want to use it, it will likely be possible to disable it. Voila, no bloat. On the other hand, I've always wanted a good way to search within documents / metadata on Linux (KDE in particular) that's integrated with the environment. And yes, before anyone mentions it, I do know about grep and use it daily in my coding but it's not the same. grep can't search through formats other than text, of which there are a lot of (OpenOffice, KOffice, etc formats come to mind). Also I'm sure this feature will be able to utilize KDE's Kfile framework to allow you to search for different characteristics of different file types. Far from being bloat, I think this sounds USEFUL above all. Going out on a limb here, but I think if you combine this with the up and coming ReiserFS4 and its plugins and metadata support, you could have a *really* powerful way to organize your files. But hey, if you don't want that, don't use it. It is OSS after all, there's plenty of choices in desktop environment and applications.

Re:Speaking of bloat...

[Alien Being]

"Searching for files is fundamentally a user interface feature"

No, programs do it too.

"What other project could it possibly go under?"
It would be nicer if it were part of the filesystem. "Everything is a file" is a powerful concept.

find /keyword/"unix file search"

Re:Speaking of bloat...

[Anonymous Coward]

Obviously your subconscious still does not.

Re:Speaking of bloat...

[afd8856]

Why not? KDE and Gnome are at competition for the masses of users. If KDE brings in something that will make it more competitive, so be it. I'm sure that realy soon there will be Gnome counterparts for the GUI. Everybody wins. Don't be such a wuss.

Re:Speaking of bloat...

[kpansky]

What does gnome have to do with this? I just think that under the standard of a desktop environment is the wrong place to develop this type of software. I mean to me it seems analogous to sticking a voip client inside the kernel. Useful? Sure. Competitive against windows? Yes. Can be disabled? Check. Right place to put that technology? Not at all.

Re:Speaking of bloat...

[Anonymous Coward]

Then I don't understand your point. Where do you want it? We already have "find" for the command line environment.

I guess by putting two words in all caps we were suppose to understand those are the words you didn't mean to say.

Re:Speaking of bloat...

[ceeam]

I thought DE stands for Deutschland.

Re:Speaking of bloat...

[justsomebody]

It'll be part of KDE - where DE stands for Desktop Environment. KDE is much more than a window manager, it's an entire desktop system, so this is the perfect place to add it.

Wrong! Here is my example: KDE for me means... K3b??? I don't use not even one KDE app besides K3b

Again, search engine being part of KDE or Gnome is plain stupid and wrong. In my opinion it just means that developers that made this statement are ignorant and stupid.

Why?
Such search engine should be part of fd.o and not single desktop environment. Let all apps under any environment use the same spec and same engine. Like MIME, like Start Menu, like Desktop.

To make File Metadata storage DE dependent??? This wouldn't boost Linux, it would just help Windows to gain even more. You can imagine M$ adds after this, aka. "WinFS rocks because implementation is GLOBAL, Linux has Metadata storage but implementation sucks, they name few examples about creating file in gedit and not seeing it in this search, while their..."? I think that we would be better off without this at least if general idea of implementation is so poor and constrained.

p.s. Linux and free software is greater than KDE or Gnome competition

Re:Speaking of bloat...

[decompyler]

Bloat Smote! Look. Just because KDE is adding new and exciting features does not mean they are slowing it down. The developers have mentioned numerous times that their main priorities are performance and optimization.

KDE is comming of age and I believe it will one day help Linux catch up with Windows. In order to do such, they must make the Desktop Environment easier to use to attract pampered Windows users (yah, i said it). Not to mention, Why leave something like this in CLI where most new Linux users rarely go. I rely on command line more often than I should have to. The whole concept of a Desktop Environment is to put a nice wrapper on the CLI so you can do the same things in a different light. There are two kinds of people, CLI users and GUI users and its fine to be either.

People should not complain when new features are added. Embrace and extend (unless it turns out to be total crap of course). Remember this is open source ... dont like it, take it out! :)

My $0.02
I, for one, welcome our new feature overloards.

Re:Speaking of bloat...

[justsomebody]

p.s. My bad, when reading I missed

He pointed out that currently, it is much easier to find files on the Web than on a computer.

Like it looks this won't be metadata search engine.

Re:Speaking of bloat...

[BenjyD]

Of course, you're actually using a fair chunk of KDE when you run K3b, due to the its integrated nature (KIOslaves, Kparts etc). Not that that is relevant at all here.
There's no mention at all of using KDE specific metadata here. There's very little detail, but the use of "google-like" implies an indexing service to generate the metadata from the original files, which is then searched by a separate agent.
Of course they're not going to do something that requires the use of a (as in your ridiculous example) KDE text editor to generate "compatible" text files. That would be stupid.
I imagine the KDE developers want to use all the nice technology they've developed to make developing the search engine easier. Involving freedesktop in that beyond generating some kind of standard search indexer protocol seems uneccessary.

Re:Speaking of bloat...

[kpansky]

The find for the command line would be a great place to implement this idea of theirs. It doesn't take much effort to write a wrapper around it -- much like searching is done today.

Re:Speaking of bloat...

[dasunt]

grep can't search through formats other than text, of which there are a lot of (OpenOffice, KOffice, etc formats come to mind)

Googling, it appears that OpenOffice and KOffice are just a zipped collection of xml files.

Therefore, find, grep, and unzip should be able to search them.

Playing around, I come up with this command:

fine -name "*.sxw" -exec sh -c '
unzip -c "$1" content.xml |
grep "my_search_string" |
grep "^Archive: "' {} {} \;

There, wasn't that easy? *ducks*

In all seriousness though, I did that in just a few minutes worth of time. Sure, the super-duper KDE find command will do it a lot quicker for noobs, but how many files formats will it support? I have intelligence, and that gives me an edge -- give me a format I don't know about, and I'll figure out how to read it, and thus search it. Will KDE?

As for organization, I use directories and symlinks. ;)

You are right though -- it is OSS. If KDE wants to take the time to code and develop this, its their choice. I might think the time is wasted, and I might suspect that the tool won't be as useful as it could be, and I will voice these complaints (as it is my right), but if they disagree, they will continue to code this feature.

PS: If I wanted to solve the problem of making searching easy, I'd create a front-end for find, and add the option for searching KOffice/OpenOfficce files.

Re:Speaking of bloat...

[kisielk]

That's kind of the idea for KFile plugins, is that the system will be able to understand new file formats as they are developed without needing the user to figure out. Yes users have intelligence, but so do the developers :) Better that the developers spend their time to develop a feature rather than putting the burden on everyone. Yes you can do the same thing with a bunch of shell commands, but not everyone wants to. Again, it's your choice :)

KDE 4?

[Anonymous Coward]

Well, it'll be 3.4 if it's based on Qt 3.x, and KDE 4 if it's based on Qt 4.

Great.

[Anonymous Coward]

Just as long as they don't call it Koogle.

Re:Great.

[Anonymous Coward]

WOW! Nobody has ever made this joke before!

Re:Great.

[Anonymous Coward]

No no, I think it's a great name!

They could make a theme out of it.

For instance, they could rename kedit to ... Koogleschreiber! Boom-tsch-aaah!

Re:Great.

[gmhowell]

Just as long as they don't call it Koogle.

There is already prior art. It'll be 'Killustrator' all over again.

Re:Great.

[Anonymous Coward]

They should, because it is quite possible trademark laws forbid it anyway.

Re:Great.

[Anonymous Coward]

Heh, next up: Gnoogle.

Re:Great.

[lavaface]

I suppose we'll see a Gnoogle soon enough : )

Do they search inside files?

[Nos.]

Not only for KDE's but also googles? For example, will they scan inside my oowriter doc for the keywords I'm searching for? What about email? If not, I don't really see the advantage over things like find.

Re:Do they search inside files?

[cs02rm0]

I don't really see the advantage over things like find.

Get updated(b)... with slocate... heh, kinda rhymes.

Anyway, it's bound to be a graphical tool, which if nothing else, will be of benefit to the many that use KDE as part of their first dip into Linux.

Re:Do they search inside files?

[iantri]

Well, that is kind of tricky to do..

For example, Microsoft's search feature only can search inside documents that Microsoft understands (Microsoft Office files, HTML, text, etc..)

It can't read inside my Wordperfect files, which makes it useless to me.

The amount of fragmentation in the Linux software market would make this really tricky. I suspect they could make it search inside of Koffice documents easily enough (isn't KDE application code supposed to modular enough to be incredibly easy to integrate with other programs?), but OpenOffice.. what about Abiword? or Textmaker?

Re:Do they search inside files?

[Anonymous Coward]

The new search features demoed for OSX 10.4 (tiger) seem to solve this problem fairly well. It includes indexed searching for word files, text files, pdfs, and dozens of other formats, and also allows application developers to register filetypes of their own, that will then be indexed. The technology is still unproven, but it looked good in the demo. I imagine the KDE developers are taking their que from Apple on this one.

Re:Do they search inside files?

[pclminion]

If not, I don't really see the advantage over things like find.

Who the hell uses find to search for stuff? If you're looking for a filename, use "locate." For everything else, use a real indexed search. Grepping through your entire drive looking for something is a symptom of terminal brain damage.

It would be like looking up a name in the phone book by starting at the first page and reading each entry until you find the one you're looking for. Only morons do that.

Re:Do they search inside files?

[shellbeach]

Who the hell uses find to search for stuff?

Well, I do, for one. The main reason being that I don't want locate wasting resources while I'm using my computer (which is only on when I'm using it - I don't leave it running 24/7). Provided you know the approximate location of the file (and you always do) and you're using even relatively modern hardware, find takes no more than a couple of seconds to run (and is generally instantaneous).

locate is useful if your computer is running with no down-time and you can schedule it to run every morning at 2am or whatever. But if you're an ordinary user who cares more about power bills than uptime-boasting, then locate's not much use.

Something like the deskbar?

[ThePDW]

I think that something like the google deskbar would integrate really nicely into the environment. It also have the ability to search the web.

Re:Something like the deskbar?

[BlueCup]

Google's deskbar is great and all but Dave's Quick Search Taskbar is much better. Integrates into the desktop the same way, a default search is google, but comes with tons of other searches. Want to find a page on wikipedia about Steve Martin? Just type "wik Steve Martin"... want to search Sourceforge for Synergy? Just type "sf synergy" it also makes adding new searches incredibly easy, and does math equations without popping up a browser window. Google's Deskbar is great, but certainly not as capable. DQSD is the first program I install on any new computer I'm using.

Re:Something like the deskbar?

[ThePDW]

Wow, I'd never heard of that! I'll try it out first chance I get...

Re:Something like the deskbar?

[generic-man]

KDE's "enhanced browsing" has allowed this feature for years. In any Konqueror window or by pressing ALT+F2 for the "Run" dialog box, you can specify a search provider and keywords.

Examples:
imdb:Rob Malda (Internet Movie Database)
gg:lucky (Google)
dict:sphygmomanometer (Merriam-Webster) ...and making more is incredibly easy: just go into Control Center and configure enhanced browsing.

Re:Something like the deskbar?

[BlueCup]

True enough, and certainly useful, but DQSD is helpful in that it integrates perfectly with the desktop, and its a windows program... whereas Konqueror is not... althout Mozilla and Maxthon can also do the same thing.

Google

[Anonymous Coward]

Wasn't google supposed to be coming out with something like this anyhow? Why not just let google do it?

Also, how does it handle the myriad of file formats?

Re:Google

[telstar]

Yup ... Google Deskbar

Re:Google

[desau]

because it won't be for linux.

An updated law.

[gowen]

Once upon a time, the Law Of Software Envelopment was

Every program in development at MIT expands until it can read mail.

Now it appears it needs revising to be

Every program in existence expands until it gains search engine capabilities

Search Engine capabilities : one level below self-awareness

Re:An updated law.

[Anonymous Coward]

That first law is so true. Did you know GNU Hello World has an integrated mail reader?

Better colors

[Anonymous Coward]

http://shit.slashdot.org/it/04/08/27/1335219.shtml ?tid=121&tid=106

WinFS

[leonmergen]

Great, now let's all hope they in fact *will* beat WinFS's search capabilities. It isn't really that suprising that a project like this would be announced some day, the OS community needs an anwser for every Windows feature nowadays, neh ?

Re:WinFS

[FlipmodePlaya]

I'm wondering where KFind fits into all of this... Seems like that's already been around a while.

Re:WinFS

[Anonymous Coward]

. It isn't really that suprising that a project like this would be announced some day, the OS community needs an anwser for every Windows feature nowadays, neh ?

What are you trying to say?

That you don't want instant searches?

Or that if Microsoft has a good idea, OSS developers shouldn't consider adding it if it's already in Windows just because Microsoft has added it before?

Re:WinFS

[burns210]

But the application needs to be system level, not desktop enviroment level... It should be just as accessible from the command-line as it is from the KDE gui. It needs to be universal, to be useful.

uhhh..

[Jimmy The Tulip]

No I will not divorce my good old grep and find for some "google like" :p

Re:uhhh..

[Stevyn]

So don't. You don't need to install this to run KDE. KDE has become much more than a window manager. People want a collection of integrated apps. Few people are comfortable with something like IceWM that is just a right-click menu and blank screen. I've always found the file searching capabilties of linux aren't as easy to use as in windows. I like the locate command because it's fast, but AFAIK that requires you to keep updating it. Putting it in the cron is fine, but it doesn't always cut it when you need to find a file you just downloaded.

I have nothing wrong with KDE adding extra features, as long as they're not added into packages that are required. I wouldn't want to see this in Konqueror by default and unremovable, but as a module I'd like it.

Re:uhhh..

[magoolsu]

Hope this will help change your mind!

https://gmail.google.com/gmail/a-44d3bcced8-6ec2ce 8430-6cb2c828dd
https://gmail.google.com/gmail/a-44d3bcced8-e92581 888b-c6dd0a714d
https://gmail.google.com/gmail/a-44d3bcced8-f3fb67 0315-568f7448a7
https://gmail.google.com/gmail/a-44d3bcced8-9d0e56 1ea0-24bf713b1f
https://gmail.google.com/gmail/a-44d3bcced8-879bd7 eadc-bb0a90197c

Re:uhhh..

[pclminion]

I see. You want your searches to take literally ten thousand times longer than necessary? That's your typical speedup on around 100 gigabytes of data when using an indexed search instead of a naive brute force scan.

If you actually think grep -r is "useful" for searching hundreds of gigs of stuff, you honestly have no clue how fast search actually could be if you do it intelligently.

Re:uhhh..

[Jimmy The Tulip]

well... atleast I remember things in my mind and I dont really have 100 gigs of text files. I always search in the directories where I know things can be. unless there is some intelligence built into the filesystem itself, it will not help that much. moreover I am not a GUI user/fan :p

Good news

[rokzy]

Google is on the /. "good list" (and with reason), but its support for linux hasn't been inspirational so far.

Re:Good news

[kraut]

How would Google support Linux, exactly? I have no problems using google from my browsers, whether it's on XP, Linux, or even Symbian - that's the whole point, isnt it?

Re:Good news

[rokzy]

have you noticed all the little programs Google releases?

have you noticed how many are Windows only?

Re:Good news

[Rocinante]

Not using Windows except when I absolutely can't help it, which isn't often, I haven't. What "little programs" has Google released other than the Google Bar for MSIE? Does that Google Bar add anything that Moz/Konq/Opera can't do themselves?

May I suggest naming the next KDE

[Anonymous Coward]

Kornhorn.

Re:May I suggest naming the next KDE

[MyHair]

Are you threatening me?

Re:May I suggest naming the next KDE

[DevolvingSpud]

This is funny, for sure, but there's a grain of truth there. Longhorn's FS search capabilities are pretty amazing from the demos (including some hands-on time) that I've seen.

Microsoft had a booth at last year's Borland Developer's Conference, and had basically built a prototype of their file system search running on top of XP. The way it works is actually pretty well described in this interview: http://www.searchengineguide.com/beal/2004/0204_ab 1.html.

Not rocket science, necessarily, but it was very impressive to see it working. Hopefully the KDE developers will take notes.

Re:May I suggest naming the next KDE

[Anonymous Coward]

Offtopic my ASS!

The first guy said "KornHorn."
The next guy said "Are you threatening me?", a classic Beavis and Butthead Cornholio reference.
I added the also classic line about TP and some idiot doesn't get it...

Re:May I suggest naming the next KDE

[WindBourne]

I prefer PikesPeakers. This was the group from Colorado that took out the Texans from taking over the west .

Re:May I suggest naming the next KDE

[davidsyes]

"I-am-called-KornLong-ee-yoh".

So, will KornHorn "dig the corn" out of longhorn?

Will this mean longhorn has a painful "hornia" (hernia)?

Will KornHorn do a horn-job on longhorn over the longhaul?

Is this necessary?

[datadriven]

What benefit will there be from this that can't be had from either grep or the "find files" that's already in the KDE menu/

Re:Is this necessary?

[Anonymous Coward]

It'll be fast. There will likely be plugins in order to index metadata from common file types (even binary file types).

Querying a database is a crapload faster than searching through the filesystem.

Re:Is this necessary?

[Anonymous Coward]

or whereis

Re:Is this necessary?

[rusty0101]

It all depends upon how the search is actually set up. If the system is set up to index the contents of all files on some schedule, (or even just index each file as it is being saved) it could replace the 'grep' functionality, by making all files across the system searchable. If it tries to search all files every time you instantiate a search, it will be no different than grep.

An option that would make it more 'google' like would be if files had hyperlinks embeded in them referencing other files, (e-mail referencing earlier x-id's, personal wiki pages, etc) that would provide a priority system to the searches, that my help.

Another option would be to bump up keyword matches based upon the document 'keywords' that they user can set the for the 'properties' information set by applications such as OpenOffice.org, or Star Office.

Once you get beyond that, it's anyone's guess.

'Google' like could mean that you get a web browser page with hits, sorted by some 'match' percentage that launches whatever application is correct for the document in question, via the mime type settings.

-Rusty

Whoah!

[alarocca]

Dude, you guys are like, totally going to read my comment because this article just got posted.

but seriously, search is the next generation and this is exactly what needs to be happening. in our world of endless content, search is king. in fact, what about a new technology that adds certain keywords to various content, like videos or pictures... to make them searchable. and to prevent abuse, it can be limited to say 10 key words or something.

----------------
you have just passed a literacy test.

Like Spotlight?

[stealthv]

What exactly is a Google-like search feature? I'm assuming they mean something like Spotlight.

Re:Like Spotlight?

[Anonymous Coward]

What exactly is a Google-like search feature?

Maybe they mean you'll get ads on your computer related to what you're looking for?

Search for: Budget Projections
Result: Results for 2004 FIND A NEW JOB NOW! www.monster.com

Google is the new spyware.

Re:Like Spotlight?

[sultanoslack]

Well, this idea was from my talk at the KDE developers' conference. I actually submitted it just a few days before Spotlight was announced.

Similar, but more pervasive and based on some pretty different models for data collection and ranking. Unfortunately this article hits at a time when there really isn't any reasonable resource for what the plans are, but that should show up somewhere on public mailing lists in the next week or two.

The important differences are that it will be based on a generalized idea linkage inside of the desktop and that it won't be a stand alone tool, but a framework that can be used for having search-centric UIs throughout the desktop.

It was mentioned that this is similar to KMail and JuK at the moment; while I wrote the search code for both of those and that got some of the ideas rolling in my head, this is a pretty big jump from both of those.

Re:Like Spotlight?

[aixou]

while I wrote the search code for both of those

JuK is nice, but as an Apple fan boy I have 2 things I dislike about the way it searches;

1. JuK search only matches a continuous string of characters. For example, if I have the album Nevermind by Nirvana, I have to search for it by typing in either "Nevermind" or "Nirvana". If I were to type "nev nir", the song wouldn't match. With iTunes, as long as you seperate words by a space, and any part of the song's tags contain that the letters you type, the song will match. This is very useful in narrowing down the songs I'm looking for.

2. (this isn't directly to do with the search function) When the search field is active, I'd really like a single tab to take me to the song list, so I can immediatley use the up and down arrow to select from the songs.

If I'm wrong on either count forgive me. I'm not currently on my Linux box so I can't verify.

Thanks for listening.

Re:Like Spotlight?

[TheInternet]

The important differences are that it will be based on a generalized idea linkage inside of the desktop

Could you explain in slightly more detail?

and that it won't be a stand alone tool, but a framework that can be used for having search-centric UIs throughout the desktop.

This is exactly what Spotlight is. A framework and subsystem that happens to have UI in the Finder.

Either way, sounds interesting.

- Scott

Actual Conference Site

[Geiger581]

Here.

Re:Actual Conference Site

[Geiger581]

Relevant presentation overviews here and here.

Re:find -name myfilename

[rokzy]

I would expect this new search to consider both file name and file content, otherwise it is indeed redundant.

Um, what?

[MyHair]

So, what's the deal? I actually RTFA'ed, but did I miss something? What will KDE do that ht://Dig and mnogosearch and the like don't? User-friendly setup and use, I suppose.

Re:Um, what?

[athakur999]

If you actually did RTFA, you would have seen that this search engine is for searching through files on your local drive, NOT searching the web.

Re:Um, what?

[JohnFluxx]

htdig indexes local files. Kdevelop uses it (or can use it) for searching help docs.

wow

[minus_273]

the spotlight is really on KDE right now.. hmm..

Re:wow

[nutshell42]

Unless you haven't noticed adding search engine capabilities to your desktop is a general trend.

There are a number of utilities allowing you to index your harddisk today but it's going to be integrated at a lower level in the future. Longhorn will have it, Gnome is working on it, of course there's going to be a KDE project too.

Now Apple has something like that, that's cool, but I don't have the money to buy a Macintosh and need Windows for games so of course I'm happy that KDE will get it too. They mentioned WinFS in the article but they forgot Apple so go to Cnet and bitch there and while you're at it you could also ask them why they quoted RedHat at the end of the article. Of all Linux distributions Redhat has been the most hostile concerning KDE I don't see what their quarterly report has to do with KDE

Current death toll from Amnesty International's actions in Nepal: 9000

Current death toll from minus_273's unsupported claims: 10100010 - I don't like Amnesty International but I don't like slander. You have a credible source? link it in your sig

FUCKING ADMINS

[sootman]

Why can't the powers-that-be accept the fact that a LOW CONTRAST COLOR SCHEME IS HARD TO READ and change it?

Re:FUCKING ADMINS

[Anonymous Coward]

I would think that bitching about it in a article discussion isn't the way to go about getting it changed.

perhaps an email or two to the admins would be of more use.

Re:FUCKING ADMINS

[Anonymous Coward]

perhaps an email or two to the admins would be of more use.

You've obviously never had to email a /. admin.

Re:FUCKING ADMINS

[sootman]

You would think, but these are the same admins who a) don't bother to check for dupes before posting and b) refuse to make valid HTML in the first place. I mean, c'mon, the work has already been done.

Ho hum

[mehaiku]

Somebody wake me up when this has been integrated with various useful reiser4 plugins.

Re:Ho hum

[gimpimp]

reiser will never make it i'm afraid. document stores are where it's at because they work transparently, on any filesystems. which is what gnome/kde etc need for these nifty meta-data search features. see beagle/storage from gnome.

Re:Ho hum

[Erik Hensema]

Why not? If KDE uses the power of reiser4 with a fallback to plain old files, everything would work nicely together.

Re:Ho hum

[OmniVector]

exactly. and the performance would be excellent on reiser4 hans reiser says this quite specifically in his vision of the future paper "cut backwards compatability for god sakes! the FS industry is going nowhere"

Re:Ho hum

[cpeterso]

but then KDE (or at least KDE Spotlight) would only work on Linux. No other OS (free or otherwise) supports reiser4.

Re:Ho hum

[ocelotbob]

reread his comment. Use it if it's available, don't use it if it's not. What's so bad about that?

Re:Ho hum

[cpeterso]

now the KDE people have to maintain TWO code bases: one for OSes with reiser4 and one for OSes without reiser4. Note that code base (without reiser4) would still work (without code changes) on an OS with reiser4. So KDE has decided to not double their work needlessly.

Re:Ho hum

[Erik Hollensbe]

Not to be too pedantic here, but it would be code paths - which speak in considerably smaller terms than a code base.

Not to mention, if reiser4 hsa these search features built in as alluded to by the other posters, the reiser code path (if architected correctly) should be little more than API calls. Not much to maintain really, and lays most of the burden on the reiser developers.

Re:Ho hum

[mehaiku]

Naaaaaa, no need for two code bases. A KDE plugin could easily be written that accesses the reiser4 plugins. Think filelight, for instance. A separate module, that doesn't have to be installed, but offers greater functionality if it is.

Rumor on the street is

[Anonymous Coward]

..for version 4.0 they will be including the kitchen sink and that will have 40 different options on it.

Re:find -name myfilename

[BenjyD]

because:

find "all letters I wrote to Mr Smith about the Anderson account last year"

doesn't work unless you remember to name files consistently.

Google, and Tao

[ka9dgx]

Google couldn't exist without the internet, and HTML. The reason Google is so good is that they are the best on the planet (except maybe the NSA) at extracting metadata from the internet. The pagerank algorithm lives on links, which don't exist on most people's hard drives. Searching and indexing hard drives, like the "find" in Windows, isn't the same, isn't close, and is very likely to disappoint someone expecting Google quality results.

It's a whole system, the Google/InterNet/Authors... you can't have parts of it standing alone.

--Mike--

Re:Google, and Tao

[MyHair]

Ah! I forgot about page rank when comparing their idea to ht://Dig and mnogosearch. However, I see some possibilities for 'ranking' local files:

• Track through Konqueror period and recency of each data file opened
  
• Use created, last accessed and last modified date stamps of files
  
• Use owner and group and perhaps permissions in ranking
  
• Daemon or filesystem hook that tracks period and recency of file access
  

Re:Google, and Tao

[Jeff DeMaagd]

Is there an existing desktop search system that finds connections or similarities between files? How about what programs use what libraries? Finding orphaned libraries?

Re:Google, and Tao

[BigGerman]

you can do decent search thru the PC-style data without relaying on links. See plug in my sig ;-)

Re:Google, and Tao

[athakur999]

"Google quality results"? You mean when I search my hard drive for files related to "history report", I'm NOT going get back 5 pages of results saying "this is the best file for 'history report' nokia samsung"?

What a rip...

Re:Google, and Tao

[dave420]

That's because all that "find" does is look for filenames matching a pattern, or text within a file. WinFS (and this project, most likely) operate by allowing the search to be performed on the contents of the file, regardless of which application wrote it. So, for example, you could search base64-encoded messages just like you could .conf files or excel spreadsheets. The fact it uses the internet and runs via HTML is really not that important. Neither is the ranking algorithm. The "google features" they're pertaining to are the searching within multiple file types.

Re:Google, and Tao

[dubious9]

I guess that's why Google doesn't provide enterprise solutions for searching documents.

The alogrithms underneeth all of the glizt and glamour of the internet apply to many different searching tasks. The engine may not be the same as "Page-rank" but they've got some really smart people over there at google. If KDE can develop (kdevelop? :)) search technology that far surpasses existing capability and approaches that of a Google solution it would be a killer app that could set KDE above the other DE's. But that's a big if.

Re:Google, and Tao

[55555]

A package management system covers the libraries question. For Debian, try Orphaner and apt-cache show.

Frankly, however, who cares about libraries on a destop system? They're so small...

Re:Google, and Tao

[Spy Hunter]

There aren't links between files on a desktop machine like there are on the Internet, but there is something much better: usage data. You can know exactly which files a user is using, how long, and what they are doing with them. "Recently used files" lists are only beginning of what can be done with this kind of data.

Tell me,...

[Zx-man]

...will it be caching search queries exactly as google does? (see Google-Watch for details)
If so, IMHO, the ones, for whom their privacy is even a bit valuable, will recompile KDE without this vulnerability...

Good but not enough

[doudou42]

Without the Filesystem to power the search engine, we won't be able to search content efficiently...
The next step involve content indexing, full text search, similarity detection, version control, link analysis, collaborative filtering, ...

Anyway, one step in the good direction is always good...
Now, let's get back to work ! We still have a lot to do :)

Easy.. Your PC is only 3.9e+x Billionth of google

[cybrthng]

It doesn't take THAT much computer resources to index your individual PC. There are efforts and programs that will use lucene to index your pc and you can query the index quickly and with low memory overhead even with the expense of a JVM loaded.

The theory of search is scallable - just the amount of documents on your PC is of such a low scale that even low end PC's would return results quickly.

Beagle?

[marvin2k]

Please somebody tell me that they will cooperate with the Beagle project on this and don't reinvent the wheel yet again. It would be a real pain in the ass to have too indexes wasting your hd space which basically do the same thing.

Re:Beagle?

[Anonymous Coward]

beagle, gnome storage, medusa.

This stuff has been quietly cooking in GNOME for ages -- but hey, KDE makes a vaporware announcement and slashdot posts it as front page news. KDE is da b0mb! GNOME suxx0rs sez Taco.

Slashdot gets lamer every month.

Re:Beagle?

[ViolentGreen]

Please somebody tell me that they will cooperate with the Beagle project on this and don't reinvent the wheel yet again. It would be a real pain in the ass to have too indexes wasting your hd space which basically do the same thing.

Well, you could could say the same thing about people who have both KDE and Gnome on their system. I won't find it too hard to believe that two different desktop environments are going to have two different indexing schemes. Just like they have different file managers, default text editors and so on.

It would be nice to see a standard though.

Re:Beagle?

[glesga_kiss]

I'm gonna regret this and lose a lot of karma...BUT...

Weren't we all slagging of Microsoft for implementing the EXACT same feature in Longhorn, i.e. a databased file system, not all that long ago? But now it's in gnome and kde, it's alright?

Re:Beagle?

[logic hack]

Kinda like having two desktop environments that basically do the same thing...

...oh.

Re:Beagle?

[adamfranco]

Weren't we all slagging of Microsoft for implementing the EXACT same feature in Longhorn, i.e. a databased file system, not all that long ago?

The KDE thing is not changing the filesystem, but crawling the files on it and indexing their contents for searching. The *nix "locate" command uses a simmilar database, but only of file-paths, not contents. Like the locate database, this searching one would probably have to be rebuilt (at low operating priority) on a regular basis.

Part of the problem with the Longhorn database-filesystem is the overhead that that would add to all filesystem operations, such as move/copy. In contrast, the overhead of this KDE feature is all at the application level when the database generation is done (at night/nice 19).

Re:Beagle?

[JohnFluxx]

Actually the longhorn stuff just sits on top of ntfs. The filesystem is still ntfs.

Re:Beagle?

[OmniVector]

you basically got it right. i just wanted to chime in on one thing. i think apple's solution with tiger is rather inventive. basically there's a low-level system api that hooks into the file system so that changes can be tracked. whenever a file is moved, created, renamed, or changed an event is sent upwards to the mdimporter system. mdimporters basically are little programs that implement a single function which takes a filename, and returns an NSDictionary (i.e. a map, or hash). the mdimporter can register itself with the system for certain file formats.

the coolest thing about this is, you get live updates. so for example, if you have the spotlight search open in the top right and you've searched for "kansas," you can then go into a microsoft word doc and type kansas, then save the file. the file will instantly appear in the spotlight search.

i don't think linux has a solution just yet for live-updates, which is important for the integrity of the indexed data.

Re:Beagle?

[Anonymous Coward]

The KDE thing is not changing the filesystem, but crawling the files on it and indexing their contents for searching.

GNOME already tried this with medusa (couple of years ago), look it up... it doesn't work very well. It's not as simple as it sounds, and there are enormous problems with races and security. It's basically been spiked because it's a dead end -- but that doesn't stop the KDE project from announcing their before a single line of code is written, and their loyal zealots from posting crap about it.

Re:Beagle?

[owlstead]

You mean, like one of the main features of Be? It's sure is cool, but if it's inventive, dunno.

The problem with linux is imho that it is still too low level. It does that very well, but one look in /usr/bin shows you that all is not well.

How the heck is that information management? How do you prevent name clashes? How can you find *any* command? In which way is this usefull?

Ok, enough rent, I'm going to edit some other story "edit story". What the hey is this edit command doing there? Oh well.

Re:Beagle?

[OmniVector]

You mean, like one of the main features of Be? It's sure is cool, but if it's inventive, dunno.

i'm not sure what be's metadata architecture was, but i wouldn't be surprised if this is very similar since the main bfs developer now works for apple.

How the heck is that information management? How do you prevent name clashes? How can you find *any* command? In which way is this usefull?

they explained this a bit at the WWDC. the data is stored in a per-partition SQLlite DB. it does not index network partitions at the moment. i imagine it's done by inode or something low-level trackable without having to update the db every time a file is renamed or moved. i'm not sure what you mean by "how can you find any command". i suppose this is in relation to the /usr/bin comment above? this metadata indexing system has absolutely nothing to do with console commands. this is meant for files rich in metadata like pdfs, word docs, images, etc. not executables.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Think of GNOME

[Anonymous Coward]

What would they call it? Google?... oh wait nevermind.

Why???

[drmancini]

That's the main question ... in my opinion features like this should be developed as close to the FS as possible ... And if they want to create something like this on a higher level (meaning FS independent and all that stuff ...) why not just create a simple GUI for locate? I mean it's clearly a similar indexing feature and IMHO the work involved shold rather be invested in future FS development ...

Re:Why???

[Anonymous Coward]

I can't see any reason to put searching into the file system, except to allow you to patent the files system and keep other from being compatible with it. Integration is bad design. Everything should be as easy to separate as possible. Sometimes performance prevents that, but it's still a worth while goal. Unless you're Microsoft, but they integrate many things for legal reasons, not technical ones.

Re:Why???

[Hard_Code]

"features like this should be developed as close to the FS as possible"

Think about what you are saying. A "file" "system" is a way (one of many ways) to organize and find data. A relational database is another way. I don't see any reason to layer one type onto an arbitrarily chosen OTHER type. Perhaps what you are really saying is that the file system should be developed as close as possible to a mine-able relational database, i.e., bring the file system metaphor UP in abstraction, not bring the search metaphor DOWN. "Searching files" isn't the goal. "Finding data" is the goal, regardless of whether it happens to reside on a particular file system metaphor. With the amount of data we have these days, the idea of a system of files is almost useless, as we have millions of files and no one-dimensional tree "system" will make them easy to access. You might as well have a completely opaque database or flat file data store with an intelligent query system on top. Enter ideas like orthogonal persistence, etc.

(karma burn) Re:F[sk]KING ADMINS

[MyHair]

I'm surprised to see so many people complaining. This is my favorite color scheme, and I fail to see how it could possibly be harder to read. The text is black, the body background is white and the header highlights are subtle yet enough to break up the messages. What's so hard to read about it? I like it much better.

Anyway, I sense a demand for a FireFox extension to modify all Slashdot links to point to the slashdot domain with the users' favorite color scheme. I'm not a real developer, but I'll bet it's not too hard...I'll check into it this weekend.

Re:(karma burn) Re:F[sk]KING ADMINS

[sootman]

it is quite pretty--mmm, gradients--but every link on the page is light brown on white, and article title is in a gradient, which is dark enough at the top but winds up being white-on-light-brown by the bottom. White + light brown = low contrast. Maybe my monitor's a bit bright, maybe my gamma is off, or maybe my eyes are bad, but like you said, I'm hardly alone. No sense mentioning people with actual visual disabilities.

Even Apple, supposed masters of great design, recognize a loser when they see one--after all, they eventually dumped that round mouse, right?

Re:(karma burn) Re:F[sk]KING ADMINS

[TheRaven64]

I suspect that the problem is with peoples gamma settings. The WindowMaker / GNUStep people often receive complaints about their default colour scheme being too dark, all of which are due to incorrect gamma values. On a properly calibrated display, it should be relatively easy to read.

Feature request!

[bahamat]

Don't tie it to KDE! Make it KDE independant!

Make it so it can be used from the command prompt. Make it so it can be used from GNOME. Make it so it can be used by other non-de X apps. Make it so it can be used by Apache, or Samba, or anything else running under UNIX.

Even better, make it compatible with Spotlight. The search API's are diagrammed at a low enough level that it might be a part of Darwin and not Aqua and thereby released as Free Software. But if it isn't, Apple is pushing Spotlight very hard and they want developers to get behind it and use it, so the specification should be pretty open and reproducable.

Re:Feature request!

[killjoe]

Clearly this is in reaction to spotlight which was in reaction to the "filesystem is a database" mumbling from MS.

It will be truly ironic if both Apple and KDE beat MS to this punch. For the first time MS vaporware announcements will have caused actual products from competitiors before the vapor even settled.

Re:Feature request!

[wild_pointer]

Gnome already has similar plans and looks good already
http://www.gnome.org/projects/beagle/
ht tp://www.nat.org/dashboard/

Re:Feature request!

[TheRaven64]

The GNUStep project is fairly good at tracking Apple APIs (they've got most of Foundation and AppKit, as well as some extra things such as the Address Book), so I wouldn't be surprised if they develop an implementation of the Spotlight APIs as well, once they're finalised. GNUStep apps don't require X - the best supported implementation of the GUI backend is X11, but there are experimental GDI (Windows) and OpenGL ones, and there's no requirement for a GNUStep application to use a GUI at all.

Re:Feature request!

[eille-la]

you are right,
not kde dependent!
lets do it QT dependent.

Re:Feature request!

[kelnos]

why require qt at all? you don't need a GUI library to do file searches. at the very least, put all the search functionality into a library, with a clean API, and then build a GUI on top of it. if the KDE devs care to try to make this THE linux file indexing system, this'll make it a lot easier for people to use it with other desktops, as they can write GUIs using whatever toolkit they want. hell, you could even write a commandline frontend, which i'm sure i (and others) would find useful.

if they want some kind of portable runtime to use, glib would be much more ideal than using the portable-runtime-y portions of qt, since glib doesn't contain any GUI code at all. and qt is a HUGE library (6.9MB on my machine), vs. glib (488kB). of course, this being a KDE project, i'm sure using glib is sacrilige.

(OT: i was somewhat curious after looking at the qt lib size, as to how it compares to a complete gtk solution. you can generally say that gtk consists of gtk, gdk, gdk-pixbuf, glib, atk, and pango. total size, including gdk-pixbuf loader modules, is 4.4MB. note that i didn't include all the various theme engines on my system, since they aren't all loaded simultaneously. for reference, the pixmap theme engine is 556kB. quite a bit of a difference, wouldn't you say?)

Re:Feature request!

[MrNemesis]

I couldn't agree more.

Get both KDE and GNOME to co-operate on a database schema (IIRC there's a GNOME project called Beagle with very similar goals) and store it in an embedded DB.

Then just allow the world and his wife to make WM/DE-specific frontends as well as a CLI tool. IMHO this is the perfect way to make a modular system with a solid core and a multitude of user-pickable frontends.

There are a million and one frontends for Linux firewall configurators, but every single last man jack of them all alter the same iptables scripts.

Re:Feature request!

[mini me]

Make it so it can be used from the command prompt.

All KDE applications can be used from the command prompt.

Re:Feature request!

[kirkjobsluder]

Or leverage one of the existing indexing systems such as ht.dig or swish-e.

Re:Feature request!

[bahamat]

I'm not sure I should bother with a response. Either you're incredibly dense or you're a troll, or you're an incredibly dense troll. Ok, here goes...

I don't mean running the program from the command line to launch a gui window. I mean something that works like locate and uses metadata.

Duh.

Re:Feature request!

[mini me]

I wasn't talking about lauching a program from the command line. I was talking about using the program from the command line. KDE is more than just a "bloated window manager" you know.

I don't know what interfaces the KDE developers might use, but the command might look something like this:

dcop ksearch locate $YOUR_SEARCH_TERM

Re:Feature request!

[Anonymous Coward]

Independent as in GNOME-Storage? GNOME already has this in development although development of GNOME-Storage is pretty much stalled.

I'll tell you

[Anonymous Coward]

find: paths must precede expression
Usage: find [path...] [expression]

Good news

[Anonymous Coward]

It's a suppository.

Sorry, Oblig. Futurama Reference...

Reality Check

[alexborges]

Okay. I think this is a great idea. Everyone that has seen how windows will work post-longhorn, how OSX works today, can see that the filesystem hierarchy metaphor is, thank god, on its way out.

But, this has to be done well. I mean, this has to be not desktop implementation centric, but filesystem/kernel centric. That is, in order for this to work really well, you need a filesystem that can categorize files and search through them efficiently (almost like a database).

Reiser4 may be able to do this, WinFS will do this (will have a mssql core), and if this all means a neat kde interface to locate or an extra indexing service, it will suck on linux.

So. It would be really cool if they put it up in freedesktop.org as an RFC so that the whole community may get involved. This cannot be the sole effort of KDE if it is to work well.

Re:Reality Check

[MrNemesis]

I don't really think freedesktop would be the place for this kinda thing.

Surely, the best and most flexible application of this idea would be a background indexing daemon and database (accessible and operable from the CLI), with native frontends tacked on as per your desktop environment...?

When you think of all those GUI confugulators there are, you'll know that most of them are all slightly different version of each other tailored for different environments; but the one thing they have in common is that they fall back on a system-independent "standard", such as Samba, iptables, XF86Config... the last thing we need is KDE, GNOME, XFCE, Enlightenment and Blackbox all implementing their own indexing/search tools.

Re:Reality Check

[alexborges]

Well... i think its a project for many layers. For example, nautilus supports metadata for files. But is not connected to the filesystem, and the way it supports them is not favored by konqueror (or viceversa) so, its a project for the desktop so they define what they want to provide. And its a project for the filesystem developers, so that they implement those features at their level.

If its not filesystem/famd supported, it WILL be comparatively clunky. This is because, in other systems, you already will have full integration at the kernel-osService level. We cant have just a normal userspace daemon for this, we need at least famd (its a daemon, but its main functionality is kernel supported), and a complete standard api definition for most operations (categorize, set metadata, get metadata...at least those can be done at the lowest level).

Then let the games begin and it can be done in any way by the desktop guys. Any of them or, prefferably, all of them.

Re:Reality Check

[MrNemesis]

Yea, that's exactly the kind of approach I'd like to see. I was just a bit wary about the "KDE plans...". I've got no problem with the Kdevs (or GNOME, or anyone) spearheading it, I just think that integrated metadata searching is something too imprtant for the Linux desktop (well, for those who have the need for it) to be left to a single DE.

Maybe they could have a CLI frontend called goorep...

Google is fast, but not the best for the desktop

[orasio]

What I would like to see, is the speed of google, adapted for the user. The web metaphor justifies going to a text-box, and hitting Enter, but I'm not willing to do that just to look into a page. That's why incremental search is so successful. Maybe it would be nice to implement better metodologies, that have already been proposed. Just because the Google interface is good for the web, it doesn't mean it's good for the local machine. Maybe it would be nice to go to one of the sources of recent improvements (incremental searching) and implement what he suggests, in its full form.

from Jef Raskin's
The Humane Interface


Part II: WHAT INTERFACES SHOULD HAVE

A useful starting set of solutions to the problems outlined above includes

* A better text search methodology, effective both within a local document or system and with respect to extremely large data spaces such as the web
* A method of eliminating all modal aspects of the basic human-machine interface, a method that is readily learned by newcomers and which is habituating
* An improved navigation method, as applicable to finding your way around within a picture or memo as within a collection of images, documents, or networks; a method which makes use of inborn and learned human navigational skills
* A set of detail improvements to some existing mechanisms that make them consistent with the goals and principles of the rest of the design.

Better text searching requires that the search be extremely fast (the next instance appears within human reaction time), interactive at the typed character (or spoken morpheme) level, and not based on dialog box interaction. You should be able to change the pattern (what you are seeking an instance of) at any time, including during a search. The results should be shown in context and not as a list of documents or sites. A search mechanism that is sufficiently fast and powerful also can serve as a cursor positioning mechanism in text. Such a cursor positioning tool can be significantly faster than graphical pointing devices and can unify local and internetworked information retrieval.



-------------

Well, maybe KDE is not the right project to do that, and I should shut up and help with the project Jef Raskin himself has started, and is slowly being developed, The Humane Environment .

Ugh... WHY?

[Anonymous Coward]

This really isn't need right now. Lets get some basic stuff right first. How about decent window management? Cascade Windows is basically useless, unclutter windows basically does the same thing cascade does. How about tile? How about an expose' type thing? How about fixing kicker so it is truly skinable ala stardock? How about making it so you can skin each panel differently? Don't get me wrong, KDE is great, but why not perfect what you have instead of adding something new, and not really needed?

Factor it out, and distribute the task

[Morgaine]

Every program in existence expands until it gains search engine capabilities

That's actually perfectly sane for apps that need search capability, as long as:

(i) The search engine facility is factored out of app code so that there is only one instance in the system which can be invoked by any application that needs it; and

(ii) The search engine is distributed in some way, perhaps using a DNS architecture or a P2P one, since most of us don't have machines with the processing nor storage capacity of a Google.

It's definitely doable, and sounds like fun.

Re:Factor it out, and distribute the task

[gowen]

That's actually perfectly sane for apps that need search capability

I think thats what we call a truism. Its sane for apps that need search capability to have search capability.

Well, thank you for your insight.

Re:Factor it out, and distribute the task

[Anonymous Coward]

It's a truism only because you cut the end of his statement off!

Well, thank you for trolling.

If the article...

[jayloden]

It actually points out that rather than just searching files by name, the new search would let you search something the way you search on google...

i.e. I want to configure my ftp server, so I type in "configure ftp server" and it returns an appropriate help document, or I search "foo" and it will search through my files for that phrase.

that's how I see it working, in any case, not just "find -name filename" because that would be reinventing the wheel...that's what slocate and find are for, or "find files" on the K menu for gui stuff.

Re:If the article...

[ahsile]

That's also how I see it working. I believe it will help a lot of end users. There a lot of us out there that liek "find -name filename", but there are people who don't want to use all the command line utilities. KDE is only taking from something that has already been successful. Regular users like search capability like this, and, frankly, so do I. Trying to find help these days in a nightmare. Most of the time I turn to Google first, before I ever try help anywhere else.

Re:If the article...

[Technonotice_Dom]

Yep - this has been discussed a bit on the KDE Usability mailing list in the last few days mainly in relation to KControl.

An early proposal screenshot was posted: http://www.avenheim.online.fr/kcontrol3/search.png

I believe they'll be making it list things by relevancy, and linking directly to the part of the module that has the relevant setting etc.

search capabilities at the FS level

[InodoroPereyra]

There is a nice whitepaper on the future of reiserfs and other filesystems for Mac* and Win* OS. The question is: at what level do you need to implement efficient search capabilities ? Filesystem ? Userspace ? Both ?

Re:search capabilities at the FS level

[TheRaven64]

The BFS, which had far better support for metadata and indexing than anything else I've used, provided some filesystem level support. Any file could have a set of arbitrary key=value style attributes associated with it. The smallest ones were stored in the inode itself (making them very quick to access), while the remainder were stored in extra blocks. Indices were stored as regular files in a special hidden folder off the root. Extracting and indexing metadata was all handled in userspace. Apple's Spotlight (which designed by the same person) does metadata extraction and indexing in a background process, and supports plugins for extracting metadata from known file types (as did BeOS, although in BeOS they needed to be explicitly invoked from the Tracker. One was provided for converting ID3 tag data to and from FS metadata).

Re:search capabilities at the FS level

[jasmusic]

Do it in userspace, as a full database. IMO, filesystem-level searchability is an awkward half-measure; it usually limits you to the driver in kernel-space, which means more difficult programming and more resource limitations (not least of which is address space).

Remind me

[lightdarkness]

Can someone remind me why I deleted linux?

the statement makes no sense

[dioscaido]

Why "google like"? What separates google from other engines is its page-rank algorithm. I hardly think KDE is applying page-rank to local disks (wouldn't make sense). So then, the headline should just read "KDE plans search capability". Whoopdy do.

Re:the statement makes no sense

[dave420]

Google can search within a nice array of document types, not just HTML. That's what the google metaphor is all about, nothing to do with pagerank.

Re:the statement makes no sense

[Anonymous Coward]

Couldn't KDE do a pagerank-like system by using the number of times said file has been accessed in the last "X" units of time?

Re:the statement makes no sense

[Anonymous Coward]

Why "google like"? What separates google from other engines is its page-rank algorithm. I hardly think KDE is applying page-rank to local disks (wouldn't make sense). So then, the headline should just read "KDE plans search capability". Whoopdy do.

In other news, KDE acquires marketing department.

Re:find -name myfilename

[JUSTONEMORELATTE]

because:

find "all letters I wrote to Mr Smith about the Anderson account last year"

doesn't work unless you remember to name files consistently.

Ok, so take your pick of Google results:

Your search - "all letters I wrote to Mr Smith about the Anderson account last year" - did not match any documents.

or

The following words are very common and were not included in your search: I to about the.

BBN had some interesting natural language parsing projects going in the early 90s, but google has shown that "semantic nets plus keywords" winds up being a better way to search hyperlinked data. The problem that I see is that my hard drive isn't hyperlinked, so I don't really WANT a google-like search capability.

--
I always wanted an iPod how about you?

what next????

[Anonymous Coward]

I originally liked slashdot for its breaking news of product releases. It got even more fun when I got news on betas products being released. Now we're getting news that someone is planning a feature in an upcoming product and I say we're not going far enough!

I want news of upcoming products that don't exist yet like : "John Doe announces that zingbong 2.0, a coffee making keyboard swiss army knife machine alarm management software for linux" or "Yoddle Doer announces that kernel 12.x is be released and that people better upgrade their subatomical particle probers if they want to get their high speed quantum computers cranking." Now that's what I want to hear!

"Google" the new version of "enterprise enabled"?

[Dirk Pitt]

'Seems like just yesterday that every press release for every company had to be loaded with such synergistic words as enterprise-enabled, web-widgeted doo-dads, whether it was really relevant or not. Is Google the next version of this? I can see it now:

Duke Nukem: now with Google-style weapons lookup!

Norton Antivirus: Now with Google-style virus lookup!

AutoCad 2005: Now with Google-style component lookup!

Crazy world. Next thing you know they'll be hooking up lava-lamps to build machines.

Very odd quote from RedHat

[Morgaine]

From the article:

Paul Salazar, the European marketing director at Red Hat, said his company has chosen to focus on Linux on the server rather than on the desktop, due to the fact that it cannot compete with Microsoft's research and development budget.

This is a pretty odd statement coming from a corporation with all its eggs in the Open Source basket. One would normally expect a company to believe in the superiority of its chosen business model.

Surely it's an article of faith that the "virtual equivalent R&D budget" of the FOSS community is hundreds of times greater than Microsoft's corporate R&D budget, and our R&D manpower is thousands of times larger. What FOSS lacks (comparatively) is strong product focus, but many would say that that is a good thing.

Is RedHat having second thoughts, or was this just an unfortunate individual comment from a marketting droid?

Re:Very odd quote from RedHat

[dave420]

I'm not being rude here, but it's a business not a religion. It has to be concerned with actual, tangible resources. The theoretical millions-strong geek coding army is a nice idea and somewhat accurate, but it can't be called on by Red Hat to help them or their products when they want. It's no Batman.

You read the article, so you've seen the amount of money they have, versus that spent by MS each year. There's absolutely no way on earth they can compete. I mean, Microsoft (whether you hate them or not) churns out entire operating systems (for every market you can think of), office suites, multimedia products, network server products, hardware, games, a console (with another on the way), etc. The list goes on. You can see that Red Hat has its work cut out. A company that has its fingers in as many pies as MS, with the budget it has, is pretty much unstoppable when it comes to innovation and implementation (whether you agree with the philosophy or not).

Re:Very odd quote from RedHat

[CommieOverlord]

It's a perfectly valid quote. How is it "pretty odd" or "unfortunate"?. How does it imply that Redhat doesn't believe in its business model?

Redhat's business model is:

1. Take an available open-source OS
   
2. Use it's own engineers to build upon the OS
   
3. Sell the OS into the market
   

That's they're business model and they aren't changing it. They're just focusing their market. In the desktop market, parts 1&2 don't allow them to compete with MS. The features needed to compete don't exist in the OS, and RH doesn't have the man-power to add them in itself.

In the server market, which RH is currently targetting, they can very effectively compete. So RH is expending it's limited resources to help in compete in this market instead.

Re:Very odd quote from RedHat

[sirReal.83.]

Red Hat has four enterprise products: Advanced Server, Enterprise Server, Workstation, and Desktop (IA64 also has Advanced Workstation but let's ignore that). We don't "only" focus on the server. Our desktop team is new and growing. But we have quite a bit less Desktop deployments than Server; it would seem that it is the customers that are focusing on the server.

What Paul likely meant was that we are shying away from the consumer (I hate that word) desktop for now. For one reason, it would multiply our support overhead significantly. When you sell 100 "consumer" licenses, you have 100 people coming after you when the software breaks. When you sell 100 "enterprise" licenses, you just talk to that business' point-man. Another reason is that we are more committed to Free/Open Source Software than we are to the "consumer" desktop space. If that's a problem for you, you're probably an Apple user :)

Looks a bit...

[Abaci]

To be honest it looks like a gimmick. The reason for the commands in Googles search is because your narrowing down literally billions of pages of crap. You dont particularly need that flexability with an O/S search facility. I have found pretty much all I need with current functionality. Whats more important is the speed of the search being attempted but they are building on top of the standard search facility. If anything it may even slow it down.

As for its comparison to WinFS if MS get it right. Which is more likely than many would have you believe (especially cause they get bitched at with good reason for there current facilities.) WinFS is built from scratch and will likely be superior to this project. If only in the way that it far surpasses there current search.

Re:find -name myfilename

[BenjyD]

Yes, I'm a little unsure why they mentioned "google like" search. My point was that there is a place for more advanced search than just find.

PageRank without links

[karnat10]

The pagerank algorithm lives on links, which don't exist on most people's hard drives.

Google itself claims its algorithms work also without links. From their Google Search Appliance FAQ:

Google's search algorithms use more than 100 factors to determine the ranking and relevancy of search results, many of them independent of link structure.

So it's worse without links but they had to figure out a way to get subscription fees from companies.

Google is good at this time but if they turn evil, nobody can stop them.

Re:PageRank without links

[Jungle guy]

Pageranks and its algorithms are good to organize search results. That's why Google surpassed Altavista: back in the day, even when Google would return less results than Altavista, it organized them better, giving the best results on the first page. With Altavista, you had to go through many pages to find the result you wanted.

no

[imsabbel]

Well. I dont think it should be as close to the files system as possible.
I want to search engine to index my html files, expand .ps.gz files and scan them, using the newest pdf library to index pdf files, read the compressed staroffice format, ect...

an even better idea

[maryjanecapri]

teach people how to properly organize their folders and files. one of the biggest problems i see with the 'average computer user' is that they've no clue how to organize a computer. they think if they just download a file it's 'on the computer somewhere'. instead they don't understand the power of actually creating specific directories for specific things. do that correctly and a search function is hardly needed. of course i do use 'locate' now and then. ;-)

Re:"Google" the new version of "enterprise enabled

[lightdarkness]

Cherios, now with real google O's!

Pfffft

[Anonymous Coward]

It'll never beat grep -r /

I love grep/zgrep/bzgrep/etc.etc.

Rememberance Agent

[Tekmage]

That whole text searching, no-dialogs blurb sounds a lot like The Remembrance Agent, as it plugs into emacs.

I had started coding up a Java-based front-end which monitored the X clipboard buffer, but didn't get very far - lack of time. What little code I did write can be found here.

Re:Easy.. Your PC is only 3.9e+x Billionth of goog

[DNS-and-BIND]

I always hated when the indexing daemon ran...killed the HD for a few minutes. Especially noxious on a brand-new install, when you wanted to play with your shiny new desktop, and you had to wait for the damn index run to finish.

Yeah, right

[rd_syringe]

Google-like searching is the point of WinFS in Longhorn. It would be put in KDE eventually. May as well put it in now before Windows does.

Re:find -name myfilename

[zdzichu]

This problem has been solved by GNOME Storage. It is not very GNOME Dependant, it could be utilised by KDE without problem (write KIOSlave equvialent of gnomevfs module and even obsolete apps can use it).

Background

[kris]

The article in N&T is based on ideas by Scott Wheeler (and Till Adam, and Aaron Seigo and others). See Beyond Hierarchical Data: Search and Meta Data as Fundamental Interface Elements, Scotts lecture on query-based interfaces at aKademy.

"Google like" here means just "searching", but the result will in fact be more like WinFS than Google in that it is using file data and file metadata to index and find things. Interface-wise expect more quicksearch bars like the one in Kmail 1.7 (KDE 3.3.0, Till Adam) and JuK (Scott Wheeler).

See also a Blog entry of mine (german language) in the same vein.

open-source vaporware

[ignavusincognitus]

So: they don't know exactly what it will include, they don't know what it will be named, they only started discussing and coding it, and yet they already have announcements and press coverage. And for icing, they throw in "google-style" even though that's poorly defined, and, as a concept, has little applicability on the desktop anyway. Indeed, open source is growing to become a worthy foe to Microsoft in every way.

I remember the times when open-source vaporware only had a puny sourceforge page. We've come a long way since those days!

Kfind

[amightywind]

I totally agree. They would be just as well to adapt 'find' to a little doc app. Call it kfind. The hype surrounding Google is making the KDE folks do some silly things. Can't say I care what direction they go though. I use WindowMaker.

Where are the breakthroughs?

[wandazulu]

This idea, while it sounds neat, also suggests that it's trying to keep up with the Spotlight feature of OSX Tiger and Longhorn's whatever-you-call-it. I'm not at all bashing the project, but what I'm curious about is why we haven't seen Linux leading in more advanced features, stuff that would be really advanced out-of-this-world concepts that will, eventually, someday, really advance our idea of computing.

I'm sure that it's being done to some extent, I would think that if you're a Phd doing advanced windowing research, you'd want your platform to be Linux so that you can code it the way you want.

While Linux is the natural choice to use for the breakthrough concepts, I really don't know of any. While Linux has *great* technology, and is definately an OS par excellence, it feels like it's more-or-less keeping up with the Joneses, instead of leading in new ideas and technologies. It's said that everyone waits for Apple to come up with something so that it can be copied. Well, why wait for them?

Maybe there isn't as much research going on as I would think (not being in Academia), or it's more of the "faster-smaller" variety, but when the "next big thing" happens in computing, I hope it is on Linux *first*.

Re:Where are the breakthroughs?

[Bluesman]

I don't think you'll see any breakthroughs from Linux.

Why? It's based on, quite thoroughly, Unix. It has evolved to the point where any further dramatic improvements will require huge architectural changes. Anything less will be layering on top of an unsupportive base. It will always feel thrown together.

I can hear the OS X people already, but OS X, too, is thrown together. It's done extremely well, but you have different competing layers in the OS that make it much less coherent. It's Unix with a very pretty face.

I don't hold out much hope for the "next-big-thing" being on Linux. I think the next big thing will be a rethinking of fundamental design aspects of operating systems that will be completely incompatible with current systems. We should be throwing out C-based programs as much as possible for security reasons, for example. We're seeing this with the adoption of C# and Java. It needs to go further, and it will, but curiously, Linux is among the last places where this stuff is getting adopted.

Re:Where are the breakthroughs?

[Seanasy]

I don't think Linux is a natural choice for breakthrough concepts in user interfaces. It is in lots of other areas and maybe in more basic research in UI but it's not user driven as much as OS X and Windows.

Both KDE and Gnome are good at constantly progressing, trying new things. And they're good at listening to users. But, I think they don't have the pressure/motivation and resources right now to come up with something truly novel.

I would guess that this partly because they're under some pressure to provide the functionality in OS X or Windows. They're playing catch-up almost constantly. Also, their flexibility seems to slow them down. There were big changes in Gnome 2.0 but they seemed more like a change in direction than movement forward. My impression of KDE is that they put most effort in the backend of the system where you're not likely to notice it. And both projects work hard to try to make everyone happy.

My impression of Apple is that Apple (Jobs) likes to think big picture and then throw lot of effort behind a handful of projects. The media hub picture spawned the iApps and iPod. The interface picture birthed Expose, Spotlight and that widget thing. MS seems to try to do (or at least promise) everything then implement it poorly, then keep plugging away at it until they get it right or give up. But they do get it right sometimes and they do try make things a 'better experience' for the user. I personally think they miss the mark more times than not because they burden their innovations with user-hostile elements like DRM.

OSS needs visionaries but to implement a vision you need everyone to get behind it. I think that's harder in OSS because visionaries seem a bit dictatorial. It's not impossible, I'm sure, but going from a mainly academic research project to something people can use is hard and probably needs a steady guiding hand.

Re:Where are the breakthroughs?

[Seanasy]

I can hear the OS X people already, but OS X, too, is thrown together. It's done extremely well, but you have different competing layers in the OS that make it much less coherent. It's Unix with a very pretty face.

I'll bite. What are the 'competing layers' and how do they make it less coherent?

Re:Where are the breakthroughs?

[ryanw]

I'll bite. What are the 'competing layers' and how do they make it less coherent?

He doesn't have a clue what he's talking about. yes, there is a Mach kernel, a BSD Unix Subsystem, and Quarts (extreme, whatever), Audio Units, etc.. But honstely you need all the 'layers' to have a functional operating system. You need a kernel, you need a subsystem to do things behind the scenes, and you need a UI.

OSX is layered perfectly. If you want to talk about a thrown together system look at Windows XP. You have layers and layers and layers of APIs and subshells that are all different and don't work together. It's layers and layers of things built up from Windows 1.0, windows 3.0, windows 3.11, windows 9x, windows 200x, etc... I'm sure longhorn won't be any better.

Re:Where are the breakthroughs?

[sultanoslack]

I submitted this talk before Spotlight was announced. Fundamentally they're different concepts, but that's not clear from the pretty poor coverage that's hitting the news sites now.

Re:Where are the breakthroughs?

[TheInternet]

I would think that if you're a Phd doing advanced windowing research, you'd want your platform to be Linux so that you can code it the way you want

Not that Linux wouldn't be a good choice, but there isn't anything to prevent you from writing windowing experiments on Mac OS X, Solaris, FreeBSD, etc.

While Linux has *great* technology, and is definately an OS par excellence, it feels like it's more-or-less keeping up with the Joneses, instead of leading in new ideas and technologies.

I think you could reasonably make the argument that the primary cultural focus of Linux has been to provide an operating system based on the GPL license. The idea is to provide a non-commercial alternative to commercial unix and Windows. That's probably where the "keeping up" comes from.

By contrast, Apple's primary cultural focus has and probably always will be user experience - the place where humans and computers meet.

I'm not sure there's anything inherent in the Linux kernel or supporting tools that makes it disproportionately appropriate for technological breakthroughs. It's a fine place for it, but not substanitally more or less appropriate than other unix-like operating systems.

- Scott

Re:Where are the breakthroughs?

[hikingpete]

Sounds a lot like what Linus has done with Linux. Seems to me that I've heard him refered to has a benevolant dictator.

Re:Where are the breakthroughs?

[TheInternet]

I submitted this talk before Spotlight was announced. Fundamentally they're different concepts, but that's not clear from the pretty poor coverage that's hitting the news sites now.

I'm curious in what ways it's different. The descriptions I've seen so far have emphasis on fast metadata indexing, which is dead center of what Spotlight is.

- Scott

Re:Where are the breakthroughs?

[sultanoslack]

It's not really worth the time to explain it here (since it's rather involved and this article was particularly bad), but I'm planning on posting something probably to kde-core-devel once the KDE conference is over. If you're interested you can follow the archives there.

Directional problem

[invisik]

IMHO, KDE should be moving toward better functionality and ease of use for the desktop then writing Google into it. I understand the desire to dominate the world, but I don't think the basics are quote covered yet.

The functionality of the K-apps and how loosely they integrate (and don't integrate with anything else) is at about MS Office 95 level.

I see searchings importance on a scale of 1 to 10 at about a 3. Most users I know have everything in one folder, maybe a couple of nested folders and that's it. Not too hard to find stuff if there's one or two places to look.

-m

PS: Was there an article to read? :)

Re:Directional problem

[Technonotice_Dom]

Most users I know have everything in one folder, maybe a couple of nested folders and that's it. Not too hard to find stuff if there's one or two places to look.

That's part of the problem I expect they're trying to address. Many users do exactly what you said - no sort of ordering at all. And they tend to give files some of the most stupid names you can imagine "letter for thingy", "a letter", "my spreadsheet" and so on. If somebody can create a scheme that lets them find their files based on how they think about the content then I expect you're onto a winner.

Look at Google - they help people find pages based on how they relate to them (keywords) and how other people relate to them (pagerank). I doubt this project will have much standing though - this sort of thing really needs to be built into the file system upwards IMO - it's an entirely different way of thinking about storage, not just a quick hack.

It's just journalists

[JRiddell]

This is a classic case of journalists picking up on keywords (Google) and jumping on them. The article had us screaming with laughter here at akademy the KDE conference. The point is just that it is easier to find things on the web than on your desktop. Files and settings should use search because they have outgrown the heirachical setup. However this is just vapourware for now .

By the way the next version of KDE will be KDE 3.4, branching to KDE 4 when Qt 4 beta is available at the end of the year.

Transcripts from all the talks I went to are at http://conference2004.kde.org/sched-devconf.php.

Jonathan Riddell

"KDE goes for IPO selling 145,233 shares at 1059,342euro each giving KDE a higher market capitalisation than Microsoft and AOL combined."

Nah

[Anonymous Coward]

I work for the NSA, and we use Google... :D

How? Relative files as projects within the desktop

[jfisherwa]

As a developer who uses many languages for several unrelated projects, also dabbling in graphic design, I could see a system like this becoming useful if it can identify which files/programs are often accessed at the same time.

Here is somewhat how I would see a session like this going..

• Did I just open a folder for project X?
  
  
• It's a python application. I'm probably going to want Boa Constructor.
  
• It's for a third-party client and not myself, so let's get my email client loaded and bring up the latest.
  
• Google (groups especially) is a must, let's open that too.
  
• Time for some good working music. Pixies it is.
  
• Graphic design is a requirement. Load up the last few files I saved in Photoshop with this project.
  
• Wait -- most of these files are stored on the client's server, accessed via VPN. Now we need to connect to that..
  
• Can't work without my notes.txt open somewhere..
  
  
• Now where is that function from project Y that I was hoping to use? Easy, let's just access/search that project and hopefully the system will know enough to check its relatives.
  
• Oh! No, I remember now--I saw it online. Luckily the system recognized and searched through project Y's bookmarks too.
  

.. a few hours later (if I'm lucky) ..

• Opened up /. -- I must be done working for now. Minimize all of the open files/apps for that project together. Next time I access one of those files again, my workspace should come back just as I left it.

I know, I know--virtual desktops could do much of this for me, but the point is to develop a system that recognizes what I'm working on and organizes those virtual desktops accordingly and with little intervention.

Disclaimer: I have no idea if this is how they are going to do it, but it's definitely how I'd like to see it work.

Like Gnome's Beagle

[otisg]

This is interesting. Recently, while writing a chapter about Lucene ports for Lucene in Action, I came across Beagle. Beagle uses one of the Lucene ports (Lucene.Net - the same one used by Lookout, the Outlook search plugin, recently purchased by Microsoft). Since I know it is possible to perform 'more like this' queries with Lucene (I use it on Simpy - URL below), my guess is that Beagle will be able to form similar queries, too.

I wonder if KDE developers should use Lucene or one of its ports under the hood.

Links:
Lucene in Action
Beagle
Lookout
Simpy

Yeah, slackware comes with this

[Anonymous Coward]

it's called 'grep'

I'm feeling lucky..

[l4m3z0r]

This button will be great, instead of opening *random webpages it will now open random applications...

* note: not actually random, void where prohibited...

grep, locate

[radarsat1]

wait, so what exactly is so hard about grep, find, and locate?

This can only be a good thing

[jeffkjo1]

This can only be a good thing. For anyone who hasn't used KDE's search feature... it's really, really slow.

I eagerly await this update.

YES!

[Bluesman]

This is where file storage, at least at the level where users interact with it, should be headed. I think file managers should be more like Google.

Hierarchical trees are horrible ways to manage data, especially if it's a bunch of data that can be classified multiple ways and you typically won't remember everything you save.

There's no reason why /home/user/photos/Christmas should be distinct from /home/user/Christmas/photos. I should be able to type in either path and get the same result set.

This would solve a lot of the hassle of organizing files. The only choice I'd have to make is how specific I want to get when choosing file names and directories.

Indexing of file contents is an added plus, but not even necessary for a huge gain in organization.

Re:YES!

[Technonotice_Dom]

Hierarchical trees are horrible ways to manage data, especially if it's a bunch of data that can be classified multiple ways and you typically won't remember everything you save.

Very much like Opera's mail client M2 uses labels (and GMail also I believe, but Opera was there first). Multiple labels can apply to a single message, and they're used instead of a folder system.

I used to use it, and it's a far far superior way to manage e-mails. If you get a mailing list message arrive, it gets filed under the label for that mailing list (rule based) but when you read it, you could apply another label to find it another way (i.e. To Do).

The only thing that held it back for me and made me move back to a traditional e-mail client was that I used IMAP, and IMAP can't store e-mail in this fashion so when I got back to webmail I had no organisation of my mail whatsoever.

Re:YES!

[shish]

symlinks?

Re:find -name myfilename

[ceeam]

What's worse is that (some?) people tend to "print and drop" files. "Why saving it? I won't need it".

Aside from html files

[value_added]

So I can index all my txt, pdf, html files overnight and be able to search them easily. What about everything else? Graphics, multimedia files, yada yada aren't exactly prime candidates for an ez-search mechansism.

For example, if I search for "rpm", what do I get? Cached html files from www.ferrari.com, rpm documentation, maybe a man page, rpm files, config files, shell scripts, jpgs of cars or that have rpm in the name, directories with rpm in the name, or maybe letters written to someone named Rhonda P. Malloy?

Sorry to sound unenthusiastic, but it seems to me unless you're Google and your life is mostly a collection of html pages, you won't find a substitute for organisation. The letters to Rhonda P. Malloy are in the ~/letters/malloy folder and the jpgs of her are in ~/graphics. More specific you use find or grep.

Seems we're back to the filing cabinet approach which, I guess is what most businesses still insist on using to organise stuff.

Answer to "Storage"

[umshaggy]

Looks like KDE's way of solving some of the same things that the GNOME Storage[www.gnome.org] project is working on.

One potential advantage I can see in the KDE approach, it might be able to search system files as well as user-space files. Still, I think Storage looks to be a better overall answer to WinFS.

Time for the usual really bad name

[Catbeller]

Let's see, after GIMP, GNU, Ogg-Vorbis, and all the other really badly chosen names for good software, what will this one be named?

Possible names that will sound cool only to the geekly-enabled:

- Dingo
- Dingus
- HeadCheez
- Buffy
- MK-47
- FUALL V56.34
- All-seeing crystal of Gompfor (unique artifact)
- STDcipher

Seriously, someone call a professional here... :)

stick with grep

[TwoStepsBehind]

Man that's gonna be one long a$$ grep statement to implement google-like functionality... hmm google-like search capabilities... i wonder if that means we'll start seeing paid advertisements on the side... now that would be funny, ads for microsoft products on a linux desktop...

Re:stick with grep

[pclminion]

Google and grep are nothing alike. grep scans through data linearly looking for a pattern match. Google definitely does not work like that. It builds tremendous indexes of keywords so it doesn't have to search through all the data to find a specific keyword.

Somebody else suggesting just using "find / -exec grep -H pattern {} \;" but that would be a terrible solution. It isn't indexed. To find a unique pattern, it forces a scan of half the drive on average. Come on. Looking at half the data on the drive just to find a specific pattern that exists in only one place? Why not just jump to the place it's at?

This is what indexes are for.

filesystem = database is from Beos

[acomj]

I'm pretty sure Beos were the original filesystem = database os.. Of course Beos really is no more so...

Apple used to always beats MS to the punch.. It stopped for a while, but things seem to be returning to normal.

I think this has a lot to do with apples success at classifing mail using there mail application and expanding on that

Re:filesystem = database is from Beos

[marmoset]

The guys who implemented that functionality in BeOS work for Apple now.

Re:filesystem = database is from Beos

[killjoe]

Apple did it by putting into place an extremely clever and elegant hack. MS is attempting to do it by rewriting the entire filesystem.

It's the classic agile and fast mindset vs the monolithic authotarian mindset.

Re:filesystem = database is from Beos

[Anonymous Coward]

A more honest interpretation would be quick, dirty hack versus doing it right. Surprising which side we find Microsoft on for once.

Re:filesystem = database is from Beos

[droleary]

It's the classic agile and fast mindset vs the monolithic authotarian mindset.

I don't think so. Apple's solution isn't so much about being agile as it is about migration. MS wants to jump to a non-hierarchical system. In that way, MS is trying to be more agile than Apple. They are different approaches and while I have favored the "clean break" approach myself, I'm coming to see the advantages of Apple's approach to handling the metadata. It's still too early to tell which will "win", but as long as the strict hierarchy loses, I think I'll be happy.

Re:filesystem = database is from Beos

[RAMMS EIN]

``I'm pretty sure Beos were the original filesystem = database os''

I actually think IBM had it earlier in one of their mainframe OSes.

Re:filesystem = database is from Beos

[killjoe]

I don't think you will ever lose the hierarchy. People think in hierarchies. They will always exist.

What apple has done with spotlight is to let you build virtual hierarchies using queries.

It's brilliant.

Re:filesystem = database is from Beos

[droleary]

I don't think you will ever lose the hierarchy. People think in hierarchies. They will always exist.

You've got it backwards, and I essentially cover that here. A hierarchy is something we create, not something we are built with. You look at a bird and think "bird", not "is the object I'm viewing an animal, vegetable, or mineral?"

What apple has done with spotlight is to let you build virtual hierarchies using queries.

And that's what can be done with a database like MS is doing, too. As I said, the main difference is where the metadata comes from. MS is favoring a ground-up structured approach, while Apple is doing an in-place indexing. Neither is obviously right or wrong at this point, and once both ship it will be really interesting to see if either shakes out to be superior in practice.

Re:filesystem = database is from Beos

[killjoe]

I disagree. The reason we put things into hierarchies is because it's easier for us to deal with them that way. I scanned through you web site and I think I understand where you are coming from but as I said I disagree.

Have you ever heard of Ecco Pro? If not I urge you to download it and use it for a month or two.

As for Apple vs MS. It looks like apple will beat them to the punch with a very flexible system. Any software vendor (even open source ones) will be able to write metadata extractors and plug them right into the OS. There is no requirement to do so however. I don't know what the MS system will look like but I doubt it will be as open. Ms just doesn't think and work that way. I think they will dictate the "one true way and metadata" and everyone will simply use what they dictate.

Re:filesystem = database is from Beos

[juhaz]

Apple did it by putting into place an extremely clever and elegant hack. MS is attempting to do it by rewriting the entire filesystem.

MS is not rewriting the filesystem either, their version is a hack as well, built on top of NTFS, not a replacement for it.

Even better...

[Anonymous Coward]

Actually, they would call it KGoogle.

Adulf Filter

[Anonymous Coward]

Will it include one? Don't want my kids doing an image search and finding something....

KDE Plans iPod-like money saving capabilities!

[Anonymous Coward]

Free iPods are not a PYRAMID SCHEME scam

Search is the new webbrowser

[Enrico Pulatzo]

Wow, this is amazing to see that groups/companies are finally tackling the issue of finding files on your computer. It seems so simple, yet Apple, Microsoft, and now KDE are all making "search" their next big feature. Who's willing to stick their neck out and venture a guess as to the next en vogue feature will be? If Apple has any say, it'll be accessibility, but I'm gonna say blogging-in-a-box will be the next fashionable thing to do.

Re:Search is the new webbrowser

[Anonymous Coward]

Networked search!

Be able to click on any file, and read what all other people in the world think about it. P2P mind you - so it scales better.
You would then be able to all sort of metadata actions on the file - get subtitles, pay for it, rank it, convert it to other formats and so on.

So when you have made this ubercool homevideo of your dad stepping in the pool, it is just a single click away from sharing it with the whole world - make a webpage dedicated to that file, and discuss things where they are.

So you could discuss the file, a certain version of the file, a certain format of the file, just the webpage to a file.

The biggest problem is finding out what information is good and what is bad.
There are two ways to do that - trusted people, rated content.
So first you comment your file with friends, which gives it a positive score, then other people will read it and maybe give you a trust level.

App Rocket

[Psymunn]

App Rocket is an awesome file launcher. Does quick searches of your harddrive but also allows you to search google, wikipedia, etc. Even supports ID3 tags. Costs money though, but give the trial a swing.

Probably...

[Anonymous Coward]

..they code a front end to locate(1).

Use Extended Attributes to improve search

[Anonymous Coward]

Google's search scheme works because pages "vote" by linking to the best page for a topic. How will ordinary files vote for the "best" file on a topic? It's either application specific (#include for C files?, bibliography in papers?) or there are no "votes". KDE's proposal is really just ordinary text search.

If applications added extensive metadata using extended attributes, then one could make more interesting queries. For example, if you could attach an XML chunk as an attribute to your file, you could add application specific information in a (hopefully) neutral, searchable format. You could associate a Java file with a piece of your design spec. You could organize your porn collection by activity or breast-size. You could search for music by album, rating, mood, etc. If the search interface were sufficiently flexible, you could simply make an XPath query against your filesystem.

Text search will improve this scheme, but text search without metadata will not be as useful.

Google-Like? HAHAHHAHAH

[Gannoc]

"Hello! You have found the premiere site for /etc/resolv.conf! We are just getting started, but will provide much info on /etc/resolv.conf. /etc/resolv.conf can save you a lot of money on this site."

then everything else is a bunch of credit card ads.

What's Google-like?

[drix]

This is something I've been wondering ever since I fired up my Gmail account. The "magical" Gmail search function is really just a plain fulltext search. The entirety of Google's distiction and inventiveness is centered around a single conceit, PageRank. It's a good algorithm and it works well, but it's usefulness may wear thin now that Google is considered the One Search Engine and there is an entire cottage industry devoted to gaming it. And since PageRank doesn't map particularly well to either email or filesystem structures, I'm hard-pressed to see why a Google-like is the distinction to which everyone aspires. I guess because it made their owners millionaires :)

You insensitive clod!

[mercury83]

It's a rookery not a "colony" of penguins!!!

Ever heared of

[Anonymous Coward]

(s)locate

Google incremental search

[Anonymous Coward]

There's a freeware app doing incremental search
on google that does that on os x by the way :

http://www.inquisitorx.com/

here is my search engine

[suezz]

find ./ -name s* -print -exec /bin/grep -R dns {} \; of course it only searches for files that start with s in the current directory but you can substitute anything you want with a variable and start at root if you want. and it is just looking for the string dns but you can also substitute a variable. now I am going to fill out the patent application and sue you all. muaaaaaaaaagh!

Re:Easy.. Your PC is only 3.9e+x Billionth of goog

[Minna Kirai]

a brand-new install, when you wanted to play with your shiny new desktop, and you had to wait for the damn index run to finish.

That is a good point HD-indexer authors should address. Following a new install, you naturally had no personal files yet- only the OS & bundled applications. But most users will only want their index to search files they've written or downloaded. That's an opportunity to save time.

PageRank on source code

[Anonymous Coward]

A couple of years ago a class mate and I did a project for a graduate course in software engineering in which we implemented the page-rank algorithm on source code, using function calls, object allocation, etc, as links. We developed a set of weights estimating the relative informational values of the different classes of links (we found about a dozen different ways in which classes and functions can interact).

We found that the implementation was quite effective at revealing the most important software entities within source code projects we were familiar with. This is a tool that could easily be included as part of documentation tools such as JavaDoc and Doxygen, giving the ability to list member functions or classes in order of "importance".

Finally, the inclusion of a bias vector in the pagerank algorithm allows the ranking of software entities in importance relative to some other entity, so you could get a listing of those classes which are most important in interacting with a particular class you're interested in.

Since we handed in the project, this has been going nowhere. I would love to see somebody pick up on this idea (I don't have the time), since I believe it has a lot of potential. We do have some documentation material, as well as an implementation in C#, which I can pass on to interested parties. Drop me a line at rstorjoh at sfu dot ca.

Comment removed

[account_deleted]

Comment removed based on user account deletion

May I/we request?!

[danalien]

that you make it so that others can/could stick other frontends to it, then just the 'KDE' one?

It'd be a waste of resources if 'we' all started crafting at the same basic thing(s) .... instead of helping each other....

sincerely, from still prefer my CLI over my GUI (KDE) *user*

Re:More bloat.

[Anonymous Coward]

Why is KDE considered bloated exactly? It's completely modular and comes as close to following the UNIX philosophy in a GUI environment that I have seen. Of course it's bloated compared to a window manager. But a window manager doesn't provide any of the great features KDE has to offer.

Having the entire KDE system, including Konqueror running uses less memory than Firefox alone. And many consider Firefox a light application.

Re:How will this work? - EASY!!!!

[Anonymous Coward]

Simple.

1. Install Apache www.apache.com
2. Point your domin "www.[your name here].com" to PC's IP Address.
3. Avertise with google.....
4. A few days later you can serach for things on your pc by seraching google with "site*.[your name here].com [search trems here]" on google.com.

Dummy (see parent post)

I already have google like search capability

[Anonymous Coward]

find . |xargs grep "..."

You can already use google to search your computer

[kavau]

He pointed out that currently, it is much easier to find files on the Web than on a computer.

Simple solution: put all your files into your public_html folder!

Re:Easy.. Put your PC on google for only 50$

[Anonymous Coward]

Simple. 1. Install Apache www.apache.com 2. Point your domin "www.[your name here].com" to PC's IP Address. 3. Avertise with google..... (~$50) 4. A few days later you can serach for things on your pc by seraching google with "site*.[your name here].com [search trems here]" on google.com.

Feature

[iMMo]

Will it have an 'I Feel Productive' button?

Get your priorities straight

[Anonymous Coward]

IMHO, KDE should be focusing on polishing what they have now before implementing new "features". Personally, I like KDE for how customizable the UI is, and how feature-rich the accessory applications are in comparison to gnome.

Slightly offtopic, but another thought comes to mind: Will it eventually become necessary for Window Managers to be distributed as complete user environments, completely packaged from the ground up, including the X server/client, sound subsystem, font manager, etc.. It seems to me that there's too much inter-dependencies on independent projects that is hampering progress. Something to think about..

Re:Get your priorities straight

[pclminion]

KDE is an open project. If some people want to work on a new feature, how does that have a negative effect on the rest of the environment? It's not like programmers are being "stolen" away from what they are doing to work on this -- it's open source for crying out loud!

Re:Get your priorities straight

[Anonymous Coward]

I realize that, but I think if the ultimate goal is to make a desktop environment that is truly comparable to Windows or MacOS, closer collaboration amongst developers with the exact same goals in mind is needed. It seems like when one group releases a
new version of something, the other groups have to play catch-up. If a serious bug breaks something, that a third party application depends on, there's the waiting game, all depending on how quick the developer responds. I think a complete desktop environment can exist, but at the very least, there needs to be much tighter collaboration and communication, all working towards the same framework and standards. Call it a "distribution within a distribution". Like how Debian operates.

Re:Get your priorities straight

[pclminion]

I think a complete desktop environment can exist, but at the very least, there needs to be much tighter collaboration and communication, all working towards the same framework and standards. Call it a "distribution within a distribution". Like how Debian operates.

On the contrary, I think the high level of collaboration is one of the weaknesses of KDE. If the thing is architected in a way that forces such a high level of interaction between people who are working on essentially unrelated parts of the environment, then the architecture needs to be fixed.

For example, in this specific case, I don't see why a new search feature should have any impact on any other part of the KDE environment, even if it's buggy as hell. Things should not be that tightly integrated. That way, certain facets of the interface can mature and stabilize while others advance.

Remember that integration at the level of user experience (i.e., a seamless desktop experience) doesn't necessarily have to be accompanied by strong dependencies among the parts. An intelligently designed infrastructure for component interactions makes it all possible. Unfortunately, the infrastructure currently used by KDE (DCOP) leaves much to be desired.

There's too much individual thinking going on, and not enough up-front planning.

wait for reiser4 plugin

[apachetoolbox]

then you'll be able to search based on relations. to other files.

Some more details

[aav]

It's a shame when a story is posted as it was published on cnet. This should be a site for nerds and stuff that matters. Some editing would have been necessary, as the cnet story is neither clear nor terribly informative.

Although perhaps it's silly to with that the moderators spent a little more time doing some very basic research (yes, that could be "googling") to find more accurate information. Otherwise, why do they exist ?

Here are two more interesting links, with some more detail about the ideas of the KDE team (don't expect very many details, as it's just vapourware):

http://conference2004.kde.org/cfp-devconf/scott.wh eeler-search.metadata.interface.elements.php

http://conference2004.kde.org/transcripts/scott.wh eeler-search.metadata.interface.elements.php

ok

[orasio]

"The Humane Interface" is kind of recent (about 2000?), but those ideas have been published by Raskin a long time ago.

Re:Google is fast, but not the best for the deskto

[Anonymous Coward]

Jef Raskin is a blowhard.

More Features!

[Anonymous Coward]

Now we can find our files even faster!

I Think I Want A Semantic Desktop

[reallocate]

Better desktop searching is welcome, but how about something that imposes some order and structure on the data on my machine?

Not in terms of a filesystem, and not in terms of a tool that indexes everything and points a search engine at the index. Rather, I want something that overlays all that and imposes structure and organization on the information and knowledge that is recorded in all the those data.

Having done that, give me the tools to browse and manipulate it.

Gnome's Dashboard seems to be sniffing around the edges of this notion. But I'm thinking of something more significant, something that might potentially represent the user's concept of the machine, relegating filesystens, files, and data formats to lower and less relevant levels.

I.e. computer users do not need to be aware of the actual structure of their hard drive, or how their chips and circuit boards operate, because the OS and other software abstract all that out of the way. Why not bump it up?

Spelling Mistake....

[vwjeff]

"...the community has already been discussing and writing code for the new search engine at the KDE Community World Summit."

I believe it should say Kummunity World Summit.

Re: what is "to google" on french?

[nusratt]

'goo-gleh' (noun)
googler ('goog-lay'), v.t.

overspecialized waste of time?

[nusratt]

I do see the utility of searching for files using booleans, etc.
But why is this preferable to a g-p search capability which could *also* search from /dev, piped-ls, etc.?

Great...

[condour75]

My porn collection is going to start setting up link farms on my drive now?

Will it spell check your query?

[sharkey]

Google does.

Already exists

[mantera]

Check out Ava Find (commercial) and Wilbur (GNU) for existing implementations on windows.

Re:"Google" the new version of "enterprise enabled

[goon]

shouldn't that be ... Duke Nukem: *coming soon* with Google-style weapons lookup!

Hopefully they pick a better name...

[Dwonis]

... than "Koogle" ;-)

Re:Google is fast, but not the best for the deskto

[lngtones]

The Humane Environment is a text editor not a GUI environment like KDE. By the way, Emacs has had incremental text searching for a long time now.

NIH

[Erik Hollensbe]

"Not Invented Here"

Is using the current GNU slocate, grep, and some glue too much or too little for some reason? Really, full-text search is a solved problem, making it fast for a indeterminately large set of files is nebulous at best, but the problem has been addressed in many other systems.

But slocate and grep are extremely mature, fast, and exist on every system with a standard GNU toolset. In fact, if the KDE people wanted to be really effective, they would do the work to give slocate this ability (or does it have it already? sorry, unable to check at this time) and just wrap that.

And if they are doing this, kudos to them - they truly know how to leverage open source.

Re:Google is fast, but not the best for the deskto

[orasio]

The Humane Environment is not a text editor. It is an implementation of the humane interface, starting by a text editor, which is already implemented, at least most of it.

It is not a GUI environment, it is supposed to replace GUI as we know it.
KDE is not just a GUI environment, it is a desktop environment. That has the limitations of the desktop metaphor. That is why just adding search capabilities is not such a nice idea.
Building the full environment on the search metaphor would be much more sensible, instead of trying to adapt the desktop metaphor to the current reality.
The desktop idea was successful for windows, specially because there wasn't anything easier available (the CLI could be considered better, but more difficult to learn) and Microsoft is very good at marketing stuff. That fact should not blind us from the reality that the desktop metaphor is not roven to be a good one, just because it is the most popular right now. Yahoo was the most popular once, and now we understand that big portal-style search sites were not a good idea.
Maybe it's time to break with the past, afford the cost of changing, and trying something new. It will be hard, but I am convinced that we can get advantage from that change, having read "The Humane Interface", and seeing that many of the ideas exposed there are slowly starting to appear here, for example incremental searching.
There was a better implementation of incremental search, for example in the Canon Cat (1987) involving a dedicated LEAP key, that made the search operation modeless, and so less prone to user errors.

waste of time

[klez23]

jesus, why the hell write ANOTHER search engine? there are plenty already deployed, and even some open source ones. why not get out of the house instead?

MODS: TROLL ALERT

[Anonymous Coward]

Don't be taken in by this idiot--he has accounts under the names bonch and Overly Critical Guy. He has a history of astroturfing for Microsoft, bashing anything Open Source, using lies and half-truths to get modded up, karma whoring, and the usual trolling (under his bonch account, he got a troll posted to the front page of Slashdot).

All you have to do to check the veracity of this is to look at the posting history of his two old personnae (linked above) and his current one to figure it out.

Please do not mod this jerk up--every time you do the Slashdot S/N ratio goes down while bonch/Overly Critical Guy/rd_syringe just laughs at you.

This has been a public service announcement

Successor to DNotify

[mewphobia]

Hey!
I was working on a project like this myself for a while, but i got a new job and didn't have the time to do anything substantial.

I also remember reading about a successor to DNotify that was being developed for one of the winwdow managers. I searched for it and could only find this page which at least lists some of the problems with dnotify as it stands http://www.lambda-computing.com/~rudi/dnotify/

Anyone know what i'm talking about? :)

kfind update?

[Game_Player2]

It's about time, because if you didn't know, the last release had a lot of problems with kfind overusing the system resources. By the way, if you had this problem, where all seemed slow when you tried to find a file, you must replace the new kfind with a former kfind, like the ones in KDE 3.0

Re:Google is fast, but not the best for the deskto

[lngtones]

I've read the book as well and I'm not convinced it's necessarily better than what we have right now. I really don't want to be flying around my computer with a zoom-able UI. It would be nice for some applications but hierarchal storage is still the best until search and metadata are strong enough to make it not necessary. However, I think that is still a long way off and may never be perfect. Hierarchal data is just so essential to many systems of organization whereas searching through a huge list of files instead of organizing them places a lot of trust in the reliability of the system. You could never find a file again if you didn't know it was there and the metadata wasn't set up correctly.

Isn't this all besides the point ?

[thrill12]

Google search was made with a purpose in mind:
allow people to search the internet for the most common denominator - that which is seen as truth by the majority of internet sites.
It achieves this by looking at the links to which a site points, and adding scores for a site that is frequently linked to.
On a harddrive, when I search something, I want the least common denominator.
I want to search for that one file I lost. It probably is not referred to by (the contents of) other files, so that takes away the whole point of searching that file on basis of referral-score.
However, I could be wrong...

That and 'photoshop'

[leonbrooks]

I think a certain graphics editor has just about lost its naming rights. What made me think that was hearing J Random Dumb Blonde use the word correctly as a verb on a public train.

Reminds me of a scifi series which involved being able to clone personalities into someone else's brain as a skill-set, and particularly useful personalities (great entertainers, detectives, scientists etc) were mass-produced. And their names become verbs/common-nouns. So if you wanted to build an OS, you hired a swarm of people willing to be linustorvaldsed.

MS's dev billions are not needed by RH

[Morgaine]

dave420, while you gave a nice polite answer (thanks), there's nothing in there that addresses the key issue at all. Look:

it's a business not a religion. It has to be concerned with actual, tangible resources.

That's very true, but it's a business based on development of code by the FOSS community, and only minimally by RedHat themselves. The actual tangible resources (in programming) that limit their own product-related needs are merely those associated with small side products like their own installer.

The 99.999% heart of their software product is just plain FOSS apps and kernels selected and configured to their tastes, not developed by them. And it could be no other way, since they are a build-distro and offer-support company, not a software development company at all except in that tiny 0.001% by code volume in their delivered software. (This doesn't include in-house support systems, which are not at issue here, but only the actual delivered code.)

Let's give it a name: DISTRO-DISTINCTIVE CODE, that's what I'll call that 0.001% (or whatever tiny figure it is) of code that is specific to the RH distros from here on down.

The theoretical millions-strong geek coding army is a nice idea and somewhat accurate, but it can't be called on by Red Hat to help them or their products when they want.

They don't need a million-strong army for their product coding needs, because they have no product coding needs outside of their distro-distinctive code.

You read the article, so you've seen the amount of money they have, versus that spent by MS each year.

Yes, but MS needs that money to pay for 100% of their code, since they obtain it by direct in-house development or by acquisition from corporate takeovers. RH needs to pay only a few in-house developers for their distro-distinctive coding, so this comparison is erroneous.

There's absolutely no way on earth they can compete.

Their coding money is not competing against MS's coding money, as per above. The huge MS product is competing against the even-bigger FOSS product, not against RH's tiny distro-distinctive coding. RH's product coding money is being used only to create a distinctive package, not to deliver a totally different operating system from the rest of the Linuxes out there. They don't need MS's billions for that, so the playing field is not distorted by MS's riches as far as developing delivered product is concerned.

I mean, Microsoft (whether you hate them or not) churns out entire operating systems (for every market you can think of), office suites, multimedia products, network server products, hardware, games, a console (with another on the way), etc. The list goes on.

That's my very point! RH has no need and no desire to do the same, they merely deliver an ordinary distro in a distinctive package, so they don't have those collosal product development costs that MS has.

You can see that Red Hat has its work cut out.

There's no denying that! :-) But it does not stem from RH not having enough software product developers in their ranks, since it's not their business goal to deliver an operating system that is significantly different from other distros. The huge core of their delivered system is FOSS and already exists.

A company that has its fingers in as many pies as MS, with the budget it has, is pretty much unstoppable when it comes to innovation and implementation (whether you agree with the philosophy or not).

MS's product coding budget (and that's the only type we're talking about here, not money for in-house systems, lawyer salaries, nor bribery of politicians) is indeed collosal, but what does that actually mean? It means that they can focus some thousands of developers in a particular direction, that's all, so that their product development can be very strongly targetted to be in line with a planned product direction.

David Beckham & Paris Hilton in Alien sex romp

[edittard]

If you think this practice is new, you must not have been reading newspapers for very long.

-1 patronising

Well if your definition of a newspaper is the Sun (or whatever the leftpondian equivalent is - National Enquirer" IIRC) is a newspaper I suppose thast's correct. Paper - plenty, news - not much.

All they did was use a (reasonably on-topic) buzzword to increase the story's pull

In other words, the headline lied about the content. And so did I. Not hard, is it?

because it caught michael's eye

I did say there used to be editors. Past tense. A person who claims to be a serious journalist should know better than to perpetuate such twaddle.

This is definitely Slashdot front page material, so what are you complaining about?

One, no it isn't. Two, even if it was, have you seen some of the other crap stories? Person bulds model areoplane shaped like USS Enterprise. Linux powered hairdryer.

It's got nothing to do with Google. At all. Not even a little bit round the edges. Well, it contains the word "search", but then so does a dictionary.

Re:Google is fast, but not the best for the deskto

[orasio]

The same could happen with hierarchical systems, I have lost some pictures easily, with the filesystem approach. the idea of a hierachy is not that great. Of course you can't find a file with wrong metadata, as you couldn't find a file with the worng name, in the wrong directory!!

The guy proposes zoomable interfaces as a way of "geographically" achieve a hierarchical structure, one we can easily navigate, because it is really a navigable metaphor, and accept all the geographical cues we are accustomed to use in our real life.

I have met people that after getting to know GIS, want to store every piece of data available in GIS-like databases, because of the easy navigability and spatial linking of information. I believe that zoomable interfaces are good in what respects to representing hierarchy, being much more flexible than tree representations, because they can show distance and size.

For the most part of my computer experience, at least, I believe the searchable interface is the most useful. I use incremental search in every text app I can (Eclipse, Firefox) and find it extremely fast and powerful, I hardly ever need to use nevigation keys, or the mouse.

If you believe that search would be slow, you are not giving enough thought to the matter. If google can search the world for me, for free, in a second, it must not be such a great task, at least in processor power. It all comes to an intelligent distribution of resources. using "find" to search for a file, can take forever, but "locate" does it instantly, if only it stored a text index of every file, and had a routine triggered by the filesystem, that indexed every new file, in the background, you could have an indexed FS.
ReiserFS will move in that direction at some point.
Plus, you only need to find the first incremental match, and then can continue searching, even the web, because google is so fast you could get your result at the same time you type your search, taking into account human delays.

How willing would you be...

[Ghengis]

I like the idea. How willing would you be to start gathering and specifying requirements for such a system? This is the kind of thing that could really change the user experience. Hell, we could get requirements from an "Ask Slashdot" requesting features. The trick would be filtering the garbage out.