Why is Everybody so clueless on the importance of Desktop Search to the Masses?



  • @DigitalXeron said:

    Yahoo is not a filesystem. Google is not a filesystem. SSDS is not a filesystem

    FAT 12/16/32, NTFS, EXT2/EXT3, ReiserFS THOSE are filesystems. Until you can write Operating Systems like Windows, Linux, MacOS, or at least minimum, filesystem drivers Quit trying to replace filesystems - It isn't any Desktop Search's job to replace filesystems, it is their job to SEARCH EXISTING FILESYSTEMS.

     

     

    but given his statement

    @SpectateSwamp said:

    The change I'd make would be to allow for a match on line 1 to result in the file on line 2 to opened with the originating program. If the original  data file had 10,000 lines then that would add 20,000 lines to the search file. 100 files that size would be 2,000,000 lines of text to search. When a match is found pop open that file. Very easy changes to do.

    it sounds like he is trying to re-invent filesystems. Admittedly in a completely dumb way but what else would you expect.



  • Copernic and Video - What's UP

    @wooter said:

    So how does SSDS tacke finding the middle appearance of a word that appears multiple times in a document?

    Tapity tapity tap tap on the enter key will move your through the file. The line number displays give you an idea where you are in the file. One thing I didn't see yet in Copernic. Maybe it exists. Is an equivalent for the HiLiteThis element. Control.txt line number 31. That element changes easily with 'HH' at prompt #2. Use it in your search to hilite local area code numbers or something?  I set Copernic to index my mpeg folder. It didn't take much time. I'll check what they do with video. I love video. 


  • Auditing TheDailyWTF Search - Counts Match SSDS

    I did a quick search for the number "3882004782" that was in my post. It shows 3 times in both SSDS and TheDailyWTF or the WTFDS search. Selecting the matches did take me to the right spot in the thread. But the match wasn't hi-lited. That should be fixed. Just checking to see if your search was working correctly. All systems need a little auditing once and a while. The previous Desktop Search contestants didn't provide match counts. Good going WTFDS. AND SSDS. Boo the rest.



  • @SpectateSwamp said:

    Good going WTFDS. AND SSDS. Boo the rest.
     

    It would be a huge step forward if you actually would learn what Desktop Search is.



  • @MasterPlanSoftware said:

    @SpectateSwamp said:
    Good going WTFDS. AND SSDS. Boo the rest.
    It would be a huge step forward if you actually would learn what Desktop Search is.

    And, most importantly, what is not.



  • How fast is Swamp Search

    @spenk said:

    it sounds like he is trying to re-invent filesystems. Admittedly in a completely dumb way but what else would you expect.

    Wasn't even my idea. My old Friend Grant C. Said in 1974 that if it was up to him all his systems would be based on plain text files. A great Desktop Search Engine makes it possible. How fast is SSDS. Don't know. Who has a fast fast computer with speedy hard drives? Maybe a SuperComputer... SSDS will just get faster and faster. I had to make it slow slow slow down for scrolling text. In the old days. The consol printer was about 1/4 the speed, of the demoed scrolling text and noisy.


  • @SpectateSwamp said:

    Who has a fast fast computer with speedy hard drives? Maybe a SuperComputer... SSDS will just get faster and faster.

    THAT DOESN'T EVEN MAKE SENSE YOU RETARD.



  • @SpectateSwamp said:

    My old Friend Grant C. Said in 1974 that if it was up to him all his systems would be based on plain text files. A great Desktop Search Engine makes it possible.
     

    Amazing. All of your videos are in plain text?



  • @SpectateSwamp said:

    Wasn't even my idea. My old Friend Grant C. Said in 1974 that if it was up to him all his systems would be based on plain text files.

    Things have changed since 1974, text isn't the be all and end all of file formats you know.

    @SpectateSwamp said:


    A great Desktop Search Engine makes it possible. How fast is SSDS. Don't know. Who has a fast fast computer with speedy hard drives? Maybe a SuperComputer... SSDS will just get faster and faster. I had to make it slow slow slow down for scrolling text. In the old days. The consol printer was about 1/4 the speed, of the demoed scrolling text and noisy.

     

    That is just nonsense as per usual, scrolling text isn't the point, searching file systems is the point of a desktop search - will you please understand this fairly fundamental point.




  • Spectate Swamp caught lying

    @derula said:

    @MasterPlanSoftware said:

    @SpectateSwamp said:
    Good going WTFDS. AND SSDS. Boo the rest.
    It would be a huge step forward if you actually would learn what Desktop Search is.

    And, most importantly, what is not.

    Yeah you are right WTF search is a net search. Like the rest of the indexers. Make one tiny mistake and you catch me.

    The next video will be to show off SSDS against Copernic. The 3882004782 not having line wrap is ugly. I'll emphasise that. don't expect me to be doing anything that will shine a nice light on Copernic. They had better get their biggest Gurus here to defend themselves. Old Copernic come on down. Where are they? Do I have to demonstrate their software. Is nobody doing anything here. Am I alone. Maybe.

    I guess it is my job to show desktop search to the masses. So I shouldn't complain. I'll have to award little prizes for those finding REAL fault with my statements. You 2 are becomming my faves.



  •  @SpectateSwamp said:

    With Swamp search it is like having X-Ray vision and the speed of the
    Flash.

    For me, SSDS feels like having to search for documents while wearing broken glasses in the middle of a storm.

    @spenk said:

    it sounds like he is trying to re-invent
    filesystems. Admittedly in a completely dumb way but what else would
    you expect.
     

    I like to visualize his "large text file" as a raw hard drive device where he simply shoves all his data, and when he needs something he just greps for it.

    @SpectateSwamp said:

    Who has a fast fast computer with speedy hard drives? Maybe a SuperComputer...

     Now you seem to fail at understanding the concept of "supercomputing". 



  • @SpectateSwamp said:

    The next video will be to show off SSDS against Copernic. The 3882004782 not having line wrap is ugly. I'll emphasise that. don't expect me to be doing anything that will shine a nice light on Copernic. They had better get their biggest Gurus here to defend themselves. Old Copernic come on down. Where are they? Do I have to demonstrate their software. Is nobody doing anything here. Am I alone. Maybe.

    I guess it is my job to show desktop search to the masses. So I shouldn't complain. I'll have to award little prizes for those finding REAL fault with my statements. You 2 are becomming my faves.

     

    Nobody at Copernic, Google, Microsoft or anywhere else takes you or your application seriously so they certainly aren't going to bother with your challenge. Then again you totally ignored all of our proposed challenges anyway - despite you demanding them over and over, as soon as a challenge was laid down you stopped mentioning the idea - I wonder why....

    Before you show 'Desktop Search' to the masses could you please do everyone here a favour and actually state for the record what you believe the term 'Desktop Search' actually means. I really do mean this as your definition seems to be different to everybody elses.

    Also now you have done your test searching large files (artificially large ones at that) could you attempt to do some tests where you search the file system for files - you know kind of using the tool how they are meant to be used and post your results for them. As a random example you could try searching some source code- a bit like I suggested repeatedly. Or if you are unable to do that at least state your reasons why - just ignoring the challenge makes you look like a loser.

     



  • @spenk said:

    Before you show 'Desktop Search' to the masses could you please do everyone here a favour and actually state for the record what you believe the term 'Desktop Search' actually means.

    Sorry, you mispelled that one. It should have read:

    Before you show Desktop Search to the masses, SpectateSwamp. sources.txt as well as search.exe. Could you please do us a favor. And tell us what you think Desktop Search means.

    Now there's a slight chance that he might read it. And understand it as well.

    Edit: I bet the answer will be "having control over your data" or something. Or "video is great" or "SSDS is the only app the masses need"



  • @SpectateSwamp said:

    @WWWWolf said:

    surely SSDS will show all of the relevant metadata about the message board post in question

    The metadata for mp3 can be found if you search for "temptag." in the source.txt. An external program doing a simple extract would probably be easiest. Given a list of files to catalog.  That way no directory coding would be needed.

    Ah, but I don't care if your search app has MP3 cataloguing - everyone has a MP3 cataloguing app. (For me, desktop search indexes them, but heck, I don't need it when the music player handles that better.)

    I'm asking you how good the Desktop Search Thread Search option in your application is.

    You know, Tracker is a wonderful desktop search app: it has metadata extraction modules for text, documents, sound, etc. But it sure as heck doesn't have a Desktop Search Thread Metadata Extraction (and I don't think the developers are interested in making such module). I bet GDS/WDS/Copernic/Spotlight don't have it either. You claimed you have such option in one form or another: Searching this thread is allegedly easy with SSDS.

    You claim your search app is good for searching this thread. So let me ask this again, this time in form of example questions. By using SSDS alone, how do you find answers to these fascinating trivia questions about this thread (favourite pastime in bars around year 2038, I bet):

    • Who used the tag "feeding the swampling" first, and when? How many times has this tag been used so far in this thread?
    • When did "SpectateShit" post the first post to this thread?
    • What specifically deserves a mention in the Museum of Modern Art?
    • Who was the first to mention vgrep?
    • In which thread page there was a cute picture of a dog FAILing to jump through a tyre?
    • Who did user "Benn" though your avatar resembled? (Hint: the exact wording was "Until MPS enlarged it, I thought it was...") What weekday was this fateful confession made?
    • What shall be in the plain? (My pronunciation in the video was awful.)

    Remember, I'm not as much interested in the correct answers as I am interested in how you find the answers using SSDS. If you're looking for a topic for your next video, how about these questions! How many keypresses to find the answers? How much looking around the files manually do you have to do? The real reason anyone wants to use Desktop Search is to use Web Search-like tools on Desktop. Answer to these question is, of course "google for them and look at the damn page", but since you have a local copy, shouldn't it be just as trivial to get an answer to each of them? These are ordinary research questions; if you have the notes these are simple to solve, right?

    My point is this: If there would be a Desktop Search Thread Metadata Extraction in any of the popular desktop search engines, you'd see "who, where, when, what" nicely listed in the application itself when you typed in a few search terms and browsed through the likely candidates. If you need poking around in SSDS to see "who, where, when, what", then your search isn't very good, is it?

    You have a local copy of the thread, but do you parse it?



  • @derula said:

    I bet the answer will be "having control over your data" or something. Or "video is great" or "SSDS is the only app the masses need"
     

     

    More seriously, by inference, SS's answer to "what do you think Desktop Search means?" is "all the dozens of weird bits of functionality that I managed to get SSDS to do".  He's basically created a CHUI version of The FileMatrix, and cannot imagine that anyone could do without 99% of the crap.

     

    Marissa Mayer (Marissa Mayer is God. But you knew that.) explained it absolutely perfectly in this one video I came across, ragging on the much more likely target of overcrowded portal pages:  basically "these things are like trying to use a Swiss Army knife with everything open; we try to make Google behave like a Swiss Army knife with everything closed, but appearing automatically when it would actually be useful" (her example was "Translate Page" for foreign languages; another one that comes to mind is "Display as HTML" for PDF/DOC files).

     



  • @derula said:

    THAT DOESN'T EVEN MAKE SENSE YOU RETARD.
     

    HAHAHAH that caught on fast!

    Thanks for standing in while I was away!



  • @SpectateSwamp said:

    It took about 40 seconds for the first part and about the same for the 2nd so a minute and 20 seconds for a very huge text file.
     

    Well that's great! More than one minute to search an 800MB file?? I bet - I BET - it could search it faster using the Visual Studio 2005 editor...

    @SpectateSwamp said:

    For Copernic it was 2 hrs and 19 minutes before anything could be looked for.

    Well, that's more than 5 hours faster than it took you to create the file... You had to do work to create the file, we'd have to merge our files (-> that is work) to be able to use SSDS. If I had the choice: work for hours and hours to use some program that is not intuitive or let the indexer run silently for 2 hours... I'd choose the indexer. Seriously.

    One final time, and you SHUT UP ABOUT IT: You can not count indexing time into search time. This is a preparation, just like you need to merge your files as a preparation.

    You may do a comparison. Take 500 random text files, all about 1KB in size. Start Copernic indexing on them and at the same time start to merge them manually for SSDS. Then tell us who was quicker. Note: you have to keep merging the files until you're done so we get numbers like: Copernic was done after x minutes, merging was done after y minutes.

     



  • @SpectateSwamp said:

    I guess it is my job to show desktop search to the masses.

    "Desktop Search" is the act of searching on or around your desktop.  In non-computer terms, you would be searching on your desk, in your file cabinets and around.  Can you explain me how your SSDS can search my virtual, digital desk, file cabinets and around?  How can your SSDS search my digital calendar book?  My digital contacts book?  My digital book of incoming and outgoing invoices?  Just like I would search the physical calendar book, contacts book and book if invoices if I were not to have a computer?



  • @tdittmar said:

    You may do a comparison. Take 500 random text files, all about 1KB in size. Start Copernic indexing on them and at the same time start to merge them manually for SSDS. Then tell us who was quicker. Note: you have to keep merging the files until you're done so we get numbers like: Copernic was done after x minutes, merging was done after y minutes.
     

    Make it 500 files spread over several directories - that way he can't just merge them (or use the copy command from a command window).



  • @spenk said:

    @tdittmar said:

    You may do a comparison. Take 500 random text files, all about 1KB in size. Start Copernic indexing on them and at the same time start to merge them manually for SSDS. Then tell us who was quicker. Note: you have to keep merging the files until you're done so we get numbers like: Copernic was done after x minutes, merging was done after y minutes.
     

    Make it 500 files spread over several directories - that way he can't just merge them (or use the copy command from a command window).

     

    Make it the "WINDOWS" directory. Although he's already claimed no-one would ever have to search that, ever.

     

    Or how about "Program Files"? Can SSDS search that? If not, it's pretty fucking useless. 



  • @rc_pinchey said:

    @spenk said:

    @tdittmar said:

    You may do a comparison. Take 500 random text files, all about 1KB in size. Start Copernic indexing on them and at the same time start to merge them manually for SSDS. Then tell us who was quicker. Note: you have to keep merging the files until you're done so we get numbers like: Copernic was done after x minutes, merging was done after y minutes.
     

    Make it 500 files spread over several directories - that way he can't just merge them (or use the copy command from a command window).

     

    Make it the "WINDOWS" directory. Although he's already claimed no-one would ever have to search that, ever.

     

    Well, I didn't want to make it too complicated. You know he's confused if you ask too much... As I'm pretty sure indexing 500 files is quicker than him merging 500 files it doesn't really matter where he takes them from. Let them be from the same folder if you like. Remeber: Nobody uses different folders!

    @rc_pinchey said:

    If not, it's pretty fucking useless. 

    Isn't it useless anyway? 

     



  • @MasterPlanSoftware said:

    @derula said:
    THAT DOESN'T EVEN MAKE SENSE YOU RETARD.
    HAHAHAH that caught on fast!

    Thanks for standing in while I was away!

    You're welcome. I've been waiting almost forever to place this sentence... and finally I saw the chance so I couldn't resist :)



  • Quit playing in Class

    @derula said:

    @MasterPlanSoftware said:

    @derula said:
    THAT DOESN'T EVEN MAKE SENSE YOU RETARD.
    HAHAHAH that caught on fast!

    Thanks for standing in while I was away!

    You're welcome. I've been waiting almost forever to place this sentence... and finally I saw the chance so I couldn't resist :)

    You two quit passing notes. Or I'll move you to the front of the class.

    While some of you are busy dreaming up more stupid search tests. 500 files here and there. SSDS has been quietly destroying search giants and myths. Pretty soon you will have nobody to turn to.  Others rattle off their long list of apps that have some of the features of Swamp search. Few understand the purpose of search. It is to find YOUR data. Not words data, not powerpoints data, not anything propriatory. Data that isn't easily portable is an anchor. Get rid of that deadweight by exporting it to text. Do screen captures or even the horrid Screen Re-Shoot. Free and share your data. Sharing your data does free it. Before; I never had the source.txt on my laptop, then it went opensource. I check it all the time now. Thanks. Few mention those large zipped Unbuntu files, since all the indexers have fallen to file size limits. How come these critical limits are not mentioned right off by them? What about text search and retrieval (to the clipboard) search with navigation and video video video. I'll just have to stick to video. Words seem to have failed me. Too much play in class. I will be more stern. 



  • @SpectateSwamp said:

    While some of you are busy dreaming up more stupid search tests. 500 files here and there. SSDS has been quietly destroying search giants and myths.

    You are an asshole. We are giving you the chance of proving your point and you don't even get it. You have not been destroying anything - you didn't even prove anything. Your software is completely useless, Coperic rocks. If you don't think so, prove otherwise, as for now you haven't. You've proven that your system is so slow it takes Copernic ages to index a simple text file, but apart from that - void!

    @SpectateSwamp said:

    Few understand the purpose of search.

    You sure don't. People who count search indexing time into the time it takes to find something fail by default.

    @SpectateSwamp said:

    Pretty soon you will have nobody to turn to.

    That does not matter as long as I know I have you to turn away from

    Give prove or shut the fuck up. 

     



  • @SpectateSwamp said:

    It is to find YOUR data. Not words data, not powerpoints data, not anything propriatory.

    I didn't realize SSDS can parse OpenDocument or other open standards.

    You're right, Swampy. I have stuff in text files, too. However, I can tell you where they are and what they say without searching them. Actually, I don't have the need for search at all, since all is structured pretty well. And when I search, I use Win Explorer. It does a fairly good job without the need to index anything. I never, ever felt the need to search through text files. Okay, I needed to search source files a lot, but that's what an editor is for.

    Oh, as others have mentioned, please make SSDS regular expressions aware and come back.

    By the way, please answer WWWolfs tough questions



  • DerulaSwamp was SearchLess too long

    @derula said:

    I didn't realize SSDS can parse OpenDocument or other open standards.

    More open standards I never knew (than plain text)

    @derula said:

    Okay, I needed to search source files a lot,

    Then give this a shot. the merge takes no time at all. So everybody quit complaining. It has to be faster than indexing. Just has to be.

    @derula said:

    . I never, ever felt the need to search through text files.
    Well now you got a reason. Search TheDailyWTF.txt file like I am. Search can be fun. There are only 30 pages or so to cut and paste. Re-Read some of this again. Now that you have an understanding of how to use search for fun and pleasure. You poor thing, SearchLess for this long.



  • @SpectateSwamp said:

    While some of you are busy dreaming up more stupid search tests. 500 files here and there.

    For the last time 500 files is normal for everyone but you, nobody other than fucking moron would ignore the invention of file systems and choose to storethings in one bigfile.


    @SpectateSwamp said:

    SSDS has been quietly destroying search giants and myths. Pretty soon you will have nobody to turn to.

    no it hasn't it has searched files bigger than anyone has (including you).

     @SpectateSwamp said:

     Others rattle off their long list of apps that have some of the features of Swamp search. Few understand the purpose of search. It is to find YOUR data. Not words data, not powerpoints data, not anything propriatory. Data that isn't easily portable is an anchor. Get rid of that deadweight by exporting it to text. Do screen captures or even the horrid Screen Re-Shoot. Free and share your data. Sharing your data does free it.

    You are an idiot, other apps do things far better and in a far saner way than ssds, searching for files is the point of search not searching inside a single file. If I have jpegs, mp3s, powerpoint slides, excel spreadsheets etc. they are my data - in a file type that suits me. Text would not work for most of these things. One big file certainly isn't the answer either.

    Sharing data does not free it, all that happens is my data is shared - what the fuck this has to do with a desktop search is beyond me.

    Please tell me how the fuck a screen capture of a powerpoint slide show is better than the actual fucking set of powerpoint slides!

    @SpectateSwamp said:


    Before; I never had the source.txt on my laptop, then it went opensource. I check it all the time now. Thanks. Few mention those large zipped Unbuntu files, since all the indexers have fallen to file size limits. How come these critical limits are not mentioned right off by them? What about text search and retrieval (to the clipboard) search with navigation and video video video. I'll just have to stick to video. Words seem to have failed me. Too much play in class. I will be more stern. 

     

    You completely refused the challenge with Unbuntu and ignored the subversion one I posted. The whole fucking point of them is they are an archive which gets extracted to several text files - try using your SSDS on a real world situation like searching source code; go on I fucking dare you to try using your tool in a situation like that. Do you even know what a zip file is?

    Video has fuck all to do with searching, random has fuck all to do with searching, show us your application searching a file system - that is what people want a search tool to do.

    When did source.txt go 'open source'? Do you have a proper repositry where people can connect using a proper source code control client? Can they download it and build it straight away without having to create a new project themselves? If not then you aren't going to be taken seriously. Doyou have proper revision control or documentation? If not you have simple given a link to a piece of code nobody can fathom the working of (or has the desire to understand either)

     

     



  • Copernic Slow Slow - Proof just in.

    @tdittmar said:

    @SpectateSwamp said:

    While some of you are busy dreaming up more stupid search tests. 500 files here and there. SSDS has been quietly destroying search giants and myths.

    You are an asshole. We are giving you the chance of proving your point and you don't even get it. You have not been destroying anything - you didn't even prove anything. Your software is completely useless, Coperic rocks. If you don't think so, prove otherwise, as for now you haven't. You've proven that your system is so slow it takes Copernic ages to index a simple text file, but apart from that - void!

    @SpectateSwamp said:

    Few understand the purpose of search.

    You sure don't. People who count search indexing time into the time it takes to find something fail by default.

    @SpectateSwamp said:

    Pretty soon you will have nobody to turn to.

    That does not matter as long as I know I have you to turn away from

    Give prove or shut the fuck up. 

     

    Maybe I would win the AssHole contest. But that's not the point. Your precious Copernic took "19" seconds to display the first match of '3882004782' in thedailywtf.txt file I have. The first match was 40,000 or so lines in. So I waited. Then the swamp search. ".6" seconds. Which almost rounds off to no time at all. How can such bad code be so fast? Is it the GoTo's? Must be. WOW that's like 40 times faster. Poor old Copernic.  


  • @SpectateSwamp said:

    @derula said:

    Okay, I needed to search source files a lot,

    Then give this a shot. the merge takes no time at all. So everybody quit complaining. It has to be faster than indexing. Just has to be.

    But why the fuck would we want to merge all our source files when we can search them without merging in other tools?  As soon as they are merged they are useless to everything but SSDS - having two copies and remerging after every change is a moron's solution.

    @SpectateSwamp said:

    There are only 30 pages or so to cut and paste

    Why? For the love of all that is holy and sacred would I want to cut and paste 30 pages when I can search from the top of the page itself? Give me a reason please. Is your life that empty cut and pasting fills an otherwise empty void?

     



  • The more I read this, the more it dawns on me that Swamp hasn't created a search tool - what he made is a bad graphical clone of less, except that it doesn't have the ability to just display the file.



  • Whiners to the front - Just not learning

    @spenk said:

    @SpectateSwamp said:

    @derula said:

    Okay, I needed to search source files a lot,

    Then give this a shot. the merge takes no time at all. So everybody quit complaining. It has to be faster than indexing. Just has to be.

    But why the fuck would we want to merge all our source files when we can search them without merging in other tools?  As soon as they are merged they are useless to everything but SSDS - having two copies and remerging after every change is a moron's solution.

    @SpectateSwamp said:

    There are only 30 pages or so to cut and paste

    Why? For the love of all that is holy and sacred would I want to cut and paste 30 pages when I can search from the top of the page itself? Give me a reason please. Is your life that empty cut and pasting fills an otherwise empty void?

     

    You do it so your search doesn't take 40 times longer on big files (18 seconds). You do it so you can examine your information rather than just archive it. You do it so you can show off what you have done, even if just to yourself. You do it because it is easy. 2 copies of text is extremely minor. I had to go and remerge and remerge to come up with a 1GB text file. So quit whining about 2 copies of all that text. The size is diddly squat and you know it.


  • @SpectateSwamp said:

    Then the swamp search. ".6" seconds.

    Ok, so Copernic won, because you need to add the time it takes SSDS to read the text file as well. As you said before, this would be another 1 minute and 20 seconds, so SSDS takes all in all 1 minute and 20.6 seconds to find the match, where Copernic only needs 19 seconds to search the term in the index, open the program window AND display the match.

    Copernic: WINNER

    SSDS: LOSER

    Case: CLOSED 



  • @rc_pinchey said:

    Or how about "Program Files"? Can SSDS search that? If not, it's pretty fucking useless. 

    Or just the Start menu? GDS indexes applications so you can start them by typing (even a part of) their name. I'm pretty sure other Windows desktop searches do that. Spotlight and Tracker also search installed applications.



  • @SpectateSwamp said:

    You do it so your search doesn't take 40 times longer on big files (18 seconds). You do it so you can examine your information rather than just archive it. You do it so you can show off what you have done, even if just to yourself. You do it because it is easy. 2 copies of text is extremely minor. I had to go and remerge and remerge to come up with a 1GB text file. So quit whining about 2 copies of all that text. The size is diddly squat and you know it.
     

    I can search my source code quick enough (and nowhere near as long as 18 seconds as you claim) either from visual studio or direct from explorer using WDS - so you have not given me a compelling reason to switch. The problem with two copies of the files is not the size you moron it is the effort required to remerge them after every change. Why should I bother having to merge all my source files when I get no percievable benfit but I am required to do extra work.

    If my source files are split over several folders how do I easily merge them anyway? Tell you what - why don't you download the subversion source I keep linking to and do a video showing how easy merging a directory structure of source code into one big file. Or is this something else you cannot do and so juyst keep on ignoring?



  • Copernic Wildly staggering about

    @spenk said:

    The problem with two copies of the files is not the size you moron it is the effort required to remerge them after every change.

    Next to no effort at all. I've done it. Obviously you haven't tried it. I have been using copernic. Every file change I make. I'm in makeing a new index. That takes longer than a merge. I often run a second version of Search ie search1 with the default settings pointing to the drives I want data from. It is quicker than indexing.

    If you do a search without re-indexing you are in just as big of a bind. What if indexing is down and they don't tell you? Anyway having the most most recent copy is seldom an issue. When you book out the code for changes that is the time, up to date is important. The rest is BS

    @spenk said:

    I can search my source code quick enough (and nowhere near as long as 18 seconds as you claim)

    My claim stands and others can verify it. The bottom line is that. Indexers don't do larger files. They don't warn you. So don't try and cut and paste info off the net like SpectateSwamp does. Because you can't. Your Desktop Search will hang.

    How to mess up a Copernicker. Slip a 1Gig text file and watch the indexer go wild. That would be too mean.

    If Copernic isn't down. Then it is wildly staggering about



  • @SpectateSwamp said:

    Next to no effort at all. I've done it. Obviously you haven't tried it. I have been using copernic. Every file change I make. I'm in makeing a new index. That takes longer than a merge. I often run a second version of Search ie search1 with the default settings pointing to the drives I want data from. It is quicker than indexing.

    If you do a search without re-indexing you are in just as big of a bind. What if indexing is down and they don't tell you? Anyway having the most most recent copy is seldom an issue. When you book out the code for changes that is the time, up to date is important. The rest is BS

     

    But indexing happens automatically in the background - I do not have to bother doing anything, why can't you get this simple point? Other tools build their index without user intervention - you tool requires the users to build the index themselves.

    'Next to no effort at all'means nothing - give me the steps I would need to merge all the source files from a directory tree into a single large text file. If it is more effort than doing nothing though you are requiring more effort than WDS, GDS, Copernic and just about every other search tool.

    I might want to search the code as it is now - after I've made changes but before I check in, how does your tool help me there? Searching with an index is quicker than searching without, many years of development and study have seen to this - learn about indexing and what it does before making these claims.

     



  • @SpectateSwamp said:

    My claim stands and others can verify it. The bottom line is that. Indexers don't do larger files. They don't warn you. So don't try and cut and paste info off the net like SpectateSwamp does. Because you can't. Your Desktop Search will hang.

    How to mess up a Copernicker. Slip a 1Gig text file and watch the indexer go wild. That would be too mean.

     

    How long would it take me to search a 1 Gig text file with SSDS?  Like SpectateSwamp does?



  • More Great Video Comming.

    @tdittmar said:

    @SpectateSwamp said:

    Then the swamp search. ".6" seconds.

    Ok, so Copernic won, because you need to add the time it takes SSDS to read the text file as well. As you said before, this would be another 1 minute and 20 seconds, so SSDS takes all in all 1 minute and 20.6 seconds to find the match, where Copernic only needs 19 seconds to search the term in the index, open the program window AND display the match.

    Copernic: WINNER

    SSDS: LOSER

    Case: CLOSED 

    You are good with numbers. So It's ShowTime again. The video just has to be made by me. Where are the Real Copernickers. When will they mount their defence videos? The .6 was the slow "c" full context search. The "s" single line matches only will show all 3 in ".3" seconds. I have my camcorder in hand and turned on. You'll see some of the proof about speed and relatively small files. Copernic doesn't have it. Swamp Search does. The CamCorder doesn't lie. Later


  • @SpectateSwamp said:

    You'll see some of the proof about speed and relatively small files. Copernic doesn't have it. Swamp Search does.

    Get it into your head - desktop searching is to find files not search inside them, you are completely missing the point and therefore failing to understand exactly what people are wanting from a tool.

    @SpectateSwamp said:

    The CamCorder doesn't lie. Later
      or stay in focus either when you're in control



  • @SpectateSwamp said:

    Where are the Real Copernickers. When will they mount their defence videos?

    They won't make any defence videos, because it's not neccessary. No one would place guards outside the fortress when some kiddies with sticks approach its walls. Except of course if SpectateSwamp was the emperor, but *cough* 209 votes *cough*



  • Copernic Take Down video posted

     

    Copernic take down video.

    http://video.google.ca/videoplay?docid=-8761501834934679010

     All they need to do is install Swamp search right at the preview stage. Then they could open and display text up to their 800MB limit. I wouldn't want to try and open any big files with their preview program. SSDS OK but not Copernic.

     

     

     



  • Swamp Search Wins showdown with Copernic

    @derula said:

    @SpectateSwamp said:

    Where are the Real Copernickers. When will they mount their defence videos?

    They won't make any defence videos, because it's not neccessary. No one would place guards outside the fortress when some kiddies with sticks approach its walls. Except of course if SpectateSwamp was the emperor, but *cough* 209 votes *cough*

    Hey I'm proud of those 209 votes I got.


  • @spenk said:

    Before you show 'Desktop Search' to the masses could you please do everyone here a favour and actually state for the record what you believe the term 'Desktop Search' actually means. I really do mean this as your definition seems to be different to everybody elses.
     

    Well Desktop Search is that special feeling you get when you hold hands with your best gal!

    It's cheering real loud for the home team!

    It's catching the perfect wave!

    It's obeying all the rules... NO WAY!



  • @SpectateSwamp said:

     Copernic take down video.

    http://video.google.ca/videoplay?docid=-8761501834934679010

     All they need to do is install Swamp search right at the preview stage. Then they could open and display text up to their 800MB limit. I wouldn't want to try and open any big files with their preview program. SSDS OK but not Copernic.

     

    Could you back up a bit and start from when you first open Copernic and SSDS?  You'd have to show how you find the file with Copernic, then you'd have to show how you open up the file with SSDS.  You're only showing one step of the process.  Could you show the whole thing?

    Also, could you please show SSDS searching an 800 MB file?  I want to learn about how fast sequential search is.  Try this:

    1. Make an 800 MB text file.  You don't have to make a video for this part.  I would only want to see a Windows Explorer display or something to confirm that the file is at least 800 MB.
    2. Put the following text at the very bottom of the file:  SPIRO_MULTIMAX_3000.  Give some video evidence that this string is actually at the bottom of the file, not at the top or in the middle.
    3. Record yourself starting SSDS (you can't set everything up ahead of time, that's cheating), then searching this file for SPIRO_MULTIMAX_3000.  Don't cut anything out of the middle or I'll think you're cheating.
    If you do this, I'll try to do the same thing with a Linux desktop search engine.  Or maybe just grep.  Then we can see who the real king of searching gigantic text files sequentially is.


  • @SpectateSwamp said:

     

    Copernic take down video.

    http://video.google.ca/videoplay?docid=-8761501834934679010

     All they need to do is install Swamp search right at the preview stage. Then they could open and display text up to their 800MB limit. I wouldn't want to try and open any big files with their preview program. SSDS OK but not Copernic. 

    Well, yeah, you just prove I was right. While Copernic had to open the file before it could display it, SSDS had it already opened and in memory. You can't compare that. Show me a video where you start a clean instance of SSDS and start the clock when you let SSDS open the file. Then we can talk, otherwise: Copernic won. 



  • What do Indexers miss?

    I have been checking for words in thedailyWTF.txt file. so far they seem to be able to find everything I look for. A lot slower than SSDS but still found. I have looked for "security is nuts" and found that string. What gets lost when creating an index. Something must. I know Swamp search looks at all the data, so it has to find the results. See!!! I don't have all the answers. Answer my question O smart ones.

    Off to the Creek for a walk with the Dogs and Kids. Video updates later. It's -24 celcius partly cloudy. No wind down on the creek, so it isn't that bad. If you have a heavy beard and mop of hair. Later



  • @SpectateSwamp said:

    A lot slower than SSDS but still found.
     

    As I said: IT IS NOT SLOWER! On the contrary: IT IS FASTER!!! Because FOR SSDS YOU HAVE TO ADD THE TIME IT TAKES TO OPEN THE FILE IN THE FIRST PLACE!!!!!

    @SpectateSwamp said:

    Off to the Creek for a walk with the Dogs and Kids. Video updates later. It's -24 celcius partly cloudy. No wind down on the creek, so it isn't that bad. If you have a heavy beard and mop of hair.

    Yeah, whatever... 



  • @SpectateSwamp said:

    I have been checking for words in thedailyWTF.txt file. so far they seem to be able to find everything I look for. A lot slower than SSDS but still found. I have looked for "security is nuts" and found that string. What gets lost when creating an index. Something must. I know Swamp search looks at all the data, so it has to find the results. See!!! I don't have all the answers. Answer my question O smart ones.

    Off to the Creek for a walk with the Dogs and Kids. Video updates later. It's -24 celcius partly cloudy. No wind down on the creek, so it isn't that bad. If you have a heavy beard and mop of hair. Later

    What question? When you write a question. Please indicate that it IS a question. By ending it with a question mark (?). Or at the very least. Use XML:

    <object class="Question">
         <property name="QuestionType">
             <value type="String">
                "rhetorical"
             </value>
         </property>
         <property name="Body">
             <value type="String">
                 "How do I asked question?"
             </value>
         </property>
    </object>

    Edit: Put random. Periods. In post. So SpectateSwamp can. Read it.


  • ♿ (Parody)

    @derula said:

    @MasterPlanSoftware said:

    @SpectateSwamp said:
    Good going WTFDS. AND SSDS. Boo the rest.
    It would be a huge step forward if you actually would learn what Desktop Search is.

    And, most importantly, what is not.

     

    No!  We can't allow that!  It would kill this thread. 



  • @SpectateSwamp said:

     Copernic take down video.

    http://video.google.ca/videoplay?docid=-8761501834934679010

     All they need to do is install Swamp search right at the preview stage. Then they could open and display text up to their 800MB limit. I wouldn't want to try and open any big files with their preview program. SSDS OK but not Copernic.

     

     

    Other than you still insist on searching single files rather than searching for files this is not a fair and balanced test. 

    Firstly the file is in all honesty going to be cached by the OS so subsequent reads are not going to be using the disk but will be coming from RAM, you need to do a complete reboot inbetween the tests to be totally fair.

    Secondly you are not showing us the steps required by SSDS to make this search work, if you want to be transparent and beyond reproach show us the clean copy of search.exe being installed and then any configuration or setup you are performing before searching with SSDS. If you are not showing these steps it proves nothing as you are in the habit of pre-configuring SSDS for each of your videos, this is not therefore a typical end user situation.

    Also, as a mad idea for this, show us how to search a fucking file system for files - this is the point of a desktop search application and one thing you are refusing to demonstrate. Show us how to search or merge or do whatever is required when you have a bunch of files in different folders from the beginning - phrases like 'merge them', 'it's easy', 'wow it is so fast I bleed from the eyes just watching SSDS' are not good enough. Either give a step by step guide or if you insist a video of this will suffice.


Log in to reply