staging.inyokaproject.org

Hallo alle, ich habe gerade folgende Baustellen-Seite fertiggestellt: Baustelle/DocFetcher. Es handelt sich um eine Desktopsuchmaschine, von dem ich (ganz zufällig 😉) der Projektleiter bin. Kommentare/Kritik/Fragen usw. erwünscht ☺

Bilder ? 😉

Philipp B schrieb:

Bilder ? 😉

Soll ich irgendwo Bilder posten? Oder war nach einer Seite mit Screenshots gefragt?

Hallo,

wir möchten das Programm im Einsatz sehen, d. h., du sollst ein Bildschirmfoto des Programms in den Artikel einbauen, siehe Wiki/Bildschirmfotos. Außerdem noch ein Hinweis auf Wiki/Begriffe. Bitte Wörter wie Feature, Button usw. austauschen. Außerdem plenkst du. Interessant ist auch die Frage, ob DocFetcher mit jeder Java-Version funktioniert? Viele Programme setzen leider Sun Java voraus.

Gruß pippovic

ich hab dann mal ein paar Fragen zu dem Programm. In der Einleitung steht ja, dass es eine Volltextsuche ist. Bei den unterstützten Dateiformaten ist aber MS binär Zeug wie .doc und .ppt aufgeführt. Da wird wohl keine Volltextsuche angewendet, oder haben die Entwickler tatsächlich einen Parser für die MS Formate entwickelt (Was bisher noch keine andere Volltextsuche hat)?

Zur Benutzung würde ich mir im Artikel ein bißchen mehr wünschen als nur "Es gibt ein Handbuch". Man möchte ja vllt. auch sich das Programm im Wiki zuerst anschauen und danach entscheiden ob man es nutzen will.

Ach und ich kann jetzt einfach nicht widerstehen 😉 Java als Suche ist nicht performant. KDE hat darauf aufgebaut und im kommenden KDE SC 4.4 ist eines der wichtigsten neuen Funktionen, dass die Suche nicht mehr Java als Backend verwendet. Eine Anwendung zur Suche ist auch nicht optimal, Suche will man im Dateimanager 😉 Aber das muss jeder für sich selbst entscheiden und hat natürlich nichts mit dem Artikel zu tun.

@ pippovic:

Danke für die Hinweise, ich werde mich demnächst um die Mängel kümmern ☺

martingr schrieb:

ich hab dann mal ein paar Fragen zu dem Programm. In der Einleitung steht ja, dass es eine Volltextsuche ist. Bei den unterstützten Dateiformaten ist aber MS binär Zeug wie .doc und .ppt aufgeführt. Da wird wohl keine Volltextsuche angewendet, oder haben die Entwickler tatsächlich einen Parser für die MS Formate entwickelt (Was bisher noch keine andere Volltextsuche hat)?

Zur Benutzung würde ich mir im Artikel ein bißchen mehr wünschen als nur "Es gibt ein Handbuch". Man möchte ja vllt. auch sich das Programm im Wiki zuerst anschauen und danach entscheiden ob man es nutzen will.

Ach und ich kann jetzt einfach nicht widerstehen 😉 Java als Suche ist nicht performant. KDE hat darauf aufgebaut und im kommenden KDE SC 4.4 ist eines der wichtigsten neuen Funktionen, dass die Suche nicht mehr Java als Backend verwendet. Eine Anwendung zur Suche ist auch nicht optimal, Suche will man im Dateimanager 😉 Aber das muss jeder für sich selbst entscheiden und hat natürlich nichts mit dem Artikel zu tun.

Zu den Fragen:

1) Ja, es handelt sich um Volltextsuche, und das Programm enthält tatsächlich Parser für Microsoft Word & Co. Das bieten aber andere Desktopsuchmaschinen (Beagle, Strigi, Google Desktop, usw.) auch.

2) Handbuch: Okay, ich werde unter "Bedienung" demnächst mehr reinschreiben. ☺

3) Java und Performance: Als Programmierer kann ich dir versichern, dass Performance-Probleme nichts mit Java zu tun haben. Es ist zwar wahr, dass Java üblicherweise mehr Arbeitsspeicher verbraucht als vergleichbare C++ Programme, und vor vielen Jahren war Java auch deutlich langsamer als C++, aber mittlerweile ist Java fast genauso schnell wie C++, weil nämlich über die Jahre hinweg viel an der Java-Laufzeitumgebung herumoptimiert wurde.

qforce schrieb:

@ pippovic:

Danke für die Hinweise, ich werde mich demnächst um die Mängel kümmern ☺

martingr schrieb:

ich hab dann mal ein paar Fragen zu dem Programm. In der Einleitung steht ja, dass es eine Volltextsuche ist. Bei den unterstützten Dateiformaten ist aber MS binär Zeug wie .doc und .ppt aufgeführt. Da wird wohl keine Volltextsuche angewendet, oder haben die Entwickler tatsächlich einen Parser für die MS Formate entwickelt (Was bisher noch keine andere Volltextsuche hat)?

Zur Benutzung würde ich mir im Artikel ein bißchen mehr wünschen als nur "Es gibt ein Handbuch". Man möchte ja vllt. auch sich das Programm im Wiki zuerst anschauen und danach entscheiden ob man es nutzen will.

Ach und ich kann jetzt einfach nicht widerstehen 😉 Java als Suche ist nicht performant. KDE hat darauf aufgebaut und im kommenden KDE SC 4.4 ist eines der wichtigsten neuen Funktionen, dass die Suche nicht mehr Java als Backend verwendet. Eine Anwendung zur Suche ist auch nicht optimal, Suche will man im Dateimanager 😉 Aber das muss jeder für sich selbst entscheiden und hat natürlich nichts mit dem Artikel zu tun.

Zu den Fragen:

1) Ja, es handelt sich um Volltextsuche, und das Programm enthält tatsächlich Parser für Microsoft Word & Co. Das bieten aber andere Desktopsuchmaschinen (Beagle, Strigi, Google Desktop, usw.) auch.

AFAIK kann Strigi/Nepomuk das nicht. Ich frage mich wirklich wie man z.B. aus visio was sinnvolles rausholen soll für den Index. Aber kann mir egal sein.

3) Java und Performance: Als Programmierer kann ich dir versichern, dass Performance-Probleme nichts mit Java zu tun haben. Es ist zwar wahr, dass Java üblicherweise mehr Arbeitsspeicher verbraucht als vergleichbare C++ Programme, und vor vielen Jahren war Java auch deutlich langsamer als C++, aber mittlerweile ist Java fast genauso schnell wie C++, weil nämlich über die Jahre hinweg viel an der Java-Laufzeitumgebung herumoptimiert wurde.

Nun ich bin selbst Programmierer, kann das auch einschätzen 😉 Ich kann dir jetzt nur sagen, dass die Java Implementierung viel zu langsam war (z.T. verursacht durch falsche Standardeinstellungen für die JVM bei den Distributionen) und die Distributionen Probleme für die Paketierung hatten. Naja vllt. hat die Engine das Problem nicht, aber ich persönlich kann es mir nicht vorstellen (ist natürlich auch ein Unterschied ob man das für einen kleinen Nutzerkreis implementiert oder für die Millionen KDE Nutzer)

martingr schrieb:

Nun ich bin selbst Programmierer, kann das auch einschätzen 😉 Ich kann dir jetzt nur sagen, dass die Java Implementierung viel zu langsam war (z.T. verursacht durch falsche Standardeinstellungen für die JVM bei den Distributionen) und die Distributionen Probleme für die Paketierung hatten. Naja vllt. hat die Engine das Problem nicht, aber ich persönlich kann es mir nicht vorstellen (ist natürlich auch ein Unterschied ob man das für einen kleinen Nutzerkreis implementiert oder für die Millionen KDE Nutzer)

Ah, bin also in guter Gesellschaft 😉. Meiner Erfahrung nach macht es auch einen wesentlichen Unterschied, welche Implementierung der Java-Laufzeitumgebung man benutzt. Ich habe DocFetcher sowohl mit OpenJDK (welches auf Ubuntu vorinstalliert ist) als auch mit dem Standard-Java von Sun getestet; mit Sun lief alles butterweich, während OpenJDK ziemliche Performance-Probleme hatte. Liegt vermutlich daran, dass das OpenJDK noch relativ jung ist (2008) und die Entwickler noch nicht so viel Zeit hatten, es zu optimieren.

Vielleicht kann ich dich ja mit diesem Artikel davon überzeugen, dass Java nicht grundsätzlich langsam sein muss. In dem Artikel schneiden Recoll und Tracker hinsichtlich der Indizierungsgeschwindigkeit am schlechtesten ab, während DocFetcher mit "Fast and CPU-sparing indexing" kommentiert wurde.

Also wie gesagt, OpenJDK ist langsam wie eine Schnecke, vielleicht hat das ja deinen Eindruck von Java vermiest 😉

Hallo,

letztendlich ist die Art der Implementierung ja auch nicht Gegenstand der Diskussion zum Wiki-Artikel.

Na ja, jedenfalls ist die Indizierung von MS-Formaten AFAIK ein Alleinstellungsmerkmal. Beagle, Tracker und Striki können das IMHO nicht von Hause aus (wobei das auf einem Linux-System auch eher nicht sein muss 😉 ).

Der Artikel ist noch zu kurz. Wie oben gesagt: Ein Bildschirmfoto und etwas mehr zur Benutzung wären sehr gut.

Gruß, noisefloor

Hallo,

Ich habe nun den Artikel fertiggestellt. Ist alles okay so?

Oben hat pippovic kritisiert, dass ich in dem Artikel "plenken" würde. Ich weiß aber ehrlich gesagt nicht, was damit gemeint ist. Dem Wikipedia-Artikel zufolge bedeutet Plenken, unnötige Leerzeichen vor solchen Satzzeichen wie ? oder ! einzufügen, was aber meiner Ansicht nach in meinem Artikel nicht der Fall ist.

Sieht gut aus. Hab noch das Logo von der Webseite eingefügt. Wenn nix mehr kommt, verschieb ich nächste Woche.

Schönes Projekt. 👍

noisefloor schrieb:

Na ja, jedenfalls ist die Indizierung von MS-Formaten AFAIK ein Alleinstellungsmerkmal. Beagle, Tracker und Striki können das IMHO nicht von Hause aus (wobei das auf einem Linux-System auch eher nicht sein muss 😉 ).

Office-Formate, inkl. MS-Office, sind schon üblich, zumindest Tracker unterstützt das. Andere vermutlich auch.

Liebe Grüße
Fredo

Beagle ebenfalls.

Hallo qforce,

Plenk bei GNOME / Xfce. Bei einem Slash/Schrägstrich werden keine Leerzeichen gesetzt. ☺ Ansonsten schöner Artikel.

Gruß pippovic

So, die "GNOME/Xfce" Sache habe ich behoben. Ansonsten habe ich dem Artikel nichts weiter hinzuzufügen. ☺