[linux-l] Re: belug lernt nicht dazu!

[Oliver Bandel]

On Wed, Nov 23, 2005 at 09:52:21AM +0100, Volker Grabsch wrote:
> On Mon, Nov 21, 2005 at 09:05:40AM +0100, Oliver Bandel wrote:
> > Ausserdem: die Suche nur im Wiki macht noch keine Server-Suche.
> > Man sollte die Möglichkeit haben, alles was auf dem Rechner in den
> > dafür vorgesehenen Verzeichnissen (piblic_html und ftp) auch suchen
> > zu können.
> 
> Auch wenn ich ebenfalls kein Fan davon bin, Google zu sehr zu
> vertrauen, würde ich sagen, eine Google-Suche mit "site:..."
> wäre das KISS unter alles Möglichkeiten. Und es ist erstmal
> sehr viel leistungsfähiger als z.B. grep.

hmhhh... könnte man ja mal für das Berlinux-Dokument ausprobieren...
...ob das klappt?

 
[...]
> > Warum über google gehen, wenn man lokal suchen könnte?
> > Seltsame herangehensweise.
> 
> Weil's nur ein Link ist, und kein CGI-Script, das man erst entwickeln
> muss, und das alle Besonderheiten (Wiki, public_html, etc.) verstehen
> und in URLs zurückverwandeln muss.

Naja, wenn lokal eine brauchbare Suchmaschine läuft, braucht man ja nix
mehr von Hand machen.


[...]
> > Aber sie sind IMHO oftmals zu aufwendig.
> > Klar, besser als HTML schon. Aber was sagt das schon?
> 
> "oftmals", schon wieder so ein schwammiges Wort. Warum pauschalisierst
> du über alle Wikis?

Gut: also bei den Wikis, die mir begegnet sind fand ich meistens
keine sehr bequeme benutzung.
Ich habe mir aber nicht immer gemerkt, _welche_ Wiki-SW dahinter steht.

Deswegen so allgemein gesprochen.

Kann ja nächtes mal drauf achten, welche Wiki-SW da benutzt wird.
Dann kann ich das konkreter benennen.


[...]
> > Wenn die Auszeichnungen, wie man sie in Mails üblicherweise macht,
> > nutzen kann, um daraus eine Doku aufzubauen, ohne dran herum
> > editieren zu müssen, um Layout-Schnickschnack zu nutzen, dann
> > ist es einfach.
> 
> Solche Wiki-Sprachen gibt es auch. reStructuredText zum Beispiel hat
> eine Syntax, die den Plaintext-README-Dateien sehr ähnlich ist:
> 
> Überschrift
> -----------
> 
> Das /ist/ hervorgehoben.
> Hier eine Liste:
> * Element 1
> * Element 2
[...]


Aha, klingt schon mal gut.
Das ist dann wirklich simpel bedienbar und "intuitiv".

Das ist dann für die meisten Sachen sicherlich ideal.
Man kann dann seine Infos einfach im plain Text schreiben
und auch alte Text-Dokus html-isieren ("aufmotzen").



[...]
> Dort gibt es (ähnlich zu Docbook, etc.) Konvertierungs-Tools, die
> reST nach HTML, LaTeX, etc. umwandeln.

Oha, muß man also doch nicht alles selber entwickeln.
OK, der Hinweis mit dem reST war gut. :)

> Sie haben sich also erst
> gar nicht an eine Weboberfläche festgedongelt. Wäre SubWiki so
> flexibel, dass es z.B. reST versteht, dann 

SubWiki ist etwas, das Du empfiehlst?
Aber man müsste noch reST "einbauen"?



> 
> > Man tippt am besten einfache Texte ein und diese werden in
> > eine gute Doku umgewandelt.
> > Wenn man es aufwändiger macht, kann man gleich laTeX nehmen und das
> > dann nach HTML konvertieren.
> 
> Wenn man es aufwändiger macht, möchte man LaTeX und HTML extra
> generieren. LaTeX -> HTML ist nicht wirklich wünschenswert, vorallem
> dann nicht, wenn man, wiegesagt, "aufwändigere" Sachen macht.

OK, macht Sinn.


[...]
> Und je nach Anwendungsgebiet sind meine persönlichen Favoriten
> reST und MediaWiki, aber auch DokuWiki hat was.
> 
> Oliver, was du kritisierst, ist nicht das Wiki-Prinzip an sich,
> sondern die Wikisprache.

Ja, genau.


>  (derer es aber viele gibt, sodass deine
> Pauschalisierungen nichts aussagen, lieber konkrete Sprachen
> kritisieren!)

OK, da ich mir nie gemerkt habe, welche Wiki-SW da benutzt wird,
kann ich da keine konkreten Sachen ablassen, nur, daß ich vieles
nicht besonders sinnvoll finde. Manches ist gut, manches nervt.






> 
> > > > Jedenfalls gibt es auch zu viel Webbasierten schnickschnack.
> > > 
> > > Typo3 ;-)
> > 
> > Ist doch noch schlimmer... wenn man erst programmieren können muß,
> > um seine Doku zu schreiben - noch eine weitere Sprachvariante...
> > ...oh jeh.
> 
> Das reicht aber. Genau wie bei den Wikis übertreibst du heftig.
> 

*grins*


> Mag sein, dass man für die Templates etwas mehr Ahnung braucht,
> u.U. auch mal was programmieren muss, aber das betrifft ja nicht
> die Doku-Schreiber.
> 
> Diese klicken sich ein paar Seiten-Elemente zusammen und füllen
> Textfelder aus. Dafür muss man nicht programmieren können, und
> es gibt genug Leute, die das einfacher finden als HTML. Wäre
> Typo3 nur was für Programmierer, hätte es niemals diese Verbreitung
> gefunden.


Nun, beim Ausmisten der alten LM-hefte habe ich irgendwo nen
Artikel zu Typo3 und den weitergehenden Features gesehen.
Die Syntax sah grauselig aus...
... als ich das sah dachte ich dann: Oh jeh, yet another PHP! :(


[...]
> > Eben, bei Wikis und daß sie nicht so gute Arbeitswerkzeuge sind,
> > weil sie möglicherweise keine sehr guten Suchfunktionen haben.
> 
> "nicht so gut", "möglicherweise", "keine sehr guten", ...
> 
> Was soll das? Werd doch mal konkret!


Also: entweder ich programmiere etwas selber.
Dann weiß ich, was da passiert und dann baue ich es nach meinem
Gusto (oder wenn es bezahlt ist nach dem Gusto des Auftraggebers).

Oder ich programmier nicht etwas selber, dann schaue ich mir an, ob das
brauchbar ist, und wenn nicht, vergesse ich den Kram gleich wieder.
Ist es brauchbar, dann wäge ich also noch ab, ob der Installationsaufwand
sich lohnt, das Teil zu installieren (Vorteile vs. Aufwand).

Wenn ich also Wiki-Sprachen (die realexistierenden Wiki-Sprachen/-Implementationen)
kritisiere, weil die nervig sind, dann tue ich das aus der Benutzer-Perspektive
und nich aus der programmierer-Perspektive.

Kommt da nun jemand daher, der selber an Wiki-SW entwickelt oder dies
vor hat, dann muß er/sie/es sich schon um die Marktanalyse (um mal ein
ketzerisches Wort zu benutzen) selber kümmern.
Meine bekundungen über miese Software sind rein aus der Benutzerperspektive
und eine Software die nicht DAU-tauglich ist, ist aus benutzerperspektive
Mist.

Hätte ich vor, mir einen eigenen Wiki zu bauen, würde ich mich
mit dem Zeugs vermulich näher auseinandersetzen. Wenn das Dein/Euer
anliegen ist... bitte, nur zu.

;-)


[...]
> > (Jetzt komm nicht wieder mit Google und so...)
> 
> Wieso? Weil es nicht auf dem eigenen Server geschieht?

ja, auch das.


> 
> Solange Google bessere Resultate liefert als Grep (und das ist
> bei Wikis allemal der Fall), stimmt deine Argumentation hinten
> und vorne nicht.

Solange es das tut.
Also auf meinem lokalen Rechner will ich nicht alles via
Google suchbar machen.

Nimm grep und glimpse zusammen, z.B.

Was bei grep der Vorteil ist: kein herum Geklicke und
einfache Bedienung.




> 
> > > Nenn mir bitte auch nur *eine* im Netz stehende Seite, die du mit
> > > grep durchsuchen kannst.  :-)
> > 
> > Eben, gibt es nicht.
> > 
> > Web ist eben nicht die richtige Schnittstelle...
> > ...oder jedenfalls nicht ohne gut gebaute Suchfunktion.
> > Daran hapert es meist.
> 
> Bisher hast du keine brauchbare Alternative genannt.

Vielleicht, weil es da noch keine gibt.

Mir schweben Möglichkeiten vor, wie sie folgende Tools/libs anbieten:
 - grep
 - glimpse (von mir aus auch webglimpse)
 - sgrep
 - pcre-like


Insbesondere sgrep ist schnuckelig... kann aber keine Regexps.

Auch Kaskadierung von Teilsuchen (da kommt dann, was rapid prototyping
angeht, FP ins Spiel: List.filter usw.) wäre fein.


> Kennst du
> eine?

Es gibt viele Einzelteile, die ein bischen was können,
aber noch nix wirklich Knaller-mäßiges, was die Sachen
zusammen anbietet.

...obwohl es ja einen Browsr gibt, der ja sgrep-like
arbeitet (habe ich aber noch nicht ausprobiert).


> "grep" allein ist es jedenfalls nicht, denn das setzt,
> wie du selbst sagst, eine andere Schnittstelle voraus.

Eben.

Bei Heise hatte ich mal nachgefragt, ob die einem nicht
eine echte oder virtuelle SQL-Anbindung an die Job-Datenbank
ermöglichen... oder eine Volltextsuche ...
wollten die aber nicht machen. (Ist aber schon länger her.)

Als ich mich nun letztens wieder mit dem
Webkäse herum geplagt habe bzgl. Recherchen,
ist mir in dem Zusammenhang ist mir dann letztens das Stichwort
SOAP untergekommen.
Das scheint aber fast nur aus Overhead zu bestehen...
...aber ansonsten ne nette Idee erst mal.


Man könnte sonst auch eine pseudo-shell anbieten,
wo man statt dem typischen geklicke eine virtuelle
Shell anbietet, wo ich - mausfrei :) - ne Suche
abgeben kann - am besten mit Tools, die grep/glimpse etc.
noch übertreffen.
Da könnte man sowas wie eine Pseudo-SQL oder Mini-SQL
Möglichkeit anbieten.

Man hat dann SELECT und WHERE usw. zur Verfügung.

BTW sollte man nntp um solche Features erweitern.
Dann kann man Newsgoups nach regexps abscannen,
statt sich ewig durch den Krempel durch zu suchen.



> Also
> höchstens ein CGI-Script um grep herum, das die Suchtreffer
> (lokale Dateipfade) wieder in Links zurückverwandelt.

häng' Dich nicht am grep auf.

Das war ein beispiel für einfache Bedienbarkeit und effizienz.

Es könnte auch SQL-ähnliche Syntax sein.


docfind -ititle=".*"berlinux.*|.*vorbereitung.*" \
         -searchcategories=web,ftp -doctype=html,pdf \
         -reportformat=text

sucht dann case-insensitive nach Dokumententiteln,
die "berlinux" oder "vorbereitung" enthalten,
in den Web- und FTP-bereichen,
such dabei nach html und pdf Dokumenten
und konvertiert das Ergebnis dann nach Text.


[...]
> Dass Google auf den Belinux-Seiten keine guten Resultate liefert,
> liegt wahrscheinlich daran, dass die ganzen PDF-Dateien etc.
> zu versteckt liegen.

Liegen doch im ftp-Bereich... wieso zu versteckt?
Ins ftp legt man doch Sachen, damit man sie verteilen kann.
und wenn das Sachen sind, die nicht für alle gedacht sind,
dann verschmälert man halt die Permissions. Der Sucher
sollte dann auch nur die Anzeigen, die verteilt werden sollen
(links auf rwx------ macht ja keinen Sinn und nervt nur),
die aber bitte auf jeden Fall (oder dann, wenn man den Bereich
auch gerne mit drin hätte)!



> Da hätte Grep dann genauso Probleme, wenn

Wie gesagt, grep war nur ein beispiel.

Nimm obiges Beispiel eines "docfind"-Tools.

Auch das: nur ein beispiel, wie es sein könnte.
Wenn man da sgrep-Features mit einbauen könnte,
und auch kaskadieren könnte bei der Suche,
das wäre superfein.

(Wobei so Kaskadierungen zum Beipiel mit einer GUI
 gut handhabbar sind - da macht IMHO sogar ne GUI
 Sinn, und daß die bisherigen GUIs solche features
 nicht anbieten, zeigt, daß die Leute nicht wirklich
 gute Ideen haben, wenn sie was programmieren...
 deswegen hat man ja auch so viele Schreibmaschinen-Emulationen,
 die man dann Textverarbeitungen nennt... ;-))



[...]
> > > Der einzig halbwegs sinnvoll Vorschlag dieser Mail besteht darin,
> > 
> > Kannst Du Deinen tendenziösen Tonfall, den Du auch in der anderen
> > Mail (Haskell/OCaml/Python) schon benutzt hast mal bitte sein lassen.
> 
> Wie man in den Wald hinein ruft ...


Auch Du übersihst: Ich habe mich über beknackte Software ausgelassen,
bekam als Antwort aber einen persönlichen Anranzer.

Schlimm, wenn dieser feine, aber wichtige  Unterschied nicht auffällt.


> 
> > > Könntest du bitte deine Kritik
> > > nochmal genauer erläutern?
> > 
> > Wenn Du es immer noch nicht geschafft hast, meinen Kritikpunkt
> > zu sehen, dann hat es eh keinen Zweck, Dir das noch zu erklären.
> 
> Das hast du mit dieser Mail aber soeben getan. Vielen Dank.

Naja, wenn man den chronologischen Aspekt vernachlässigt (wann
wurde was geschrieben).

Aber gut, greife ich das doch nochmal auf.
Vielleicht macht es ja doch Sinn, darzustellen, was genau ich meine.
Ich hoffe, daß es diesmal endlich klar wird. Diesmal habe ich ein
Suchbeispiel angebracht, und wenn es jetzt _immer_ noch nicht klar
sein sollte...


[...]
> Nein, ich habe damit begründet, warum ich ein Subversion-basiertes Wiki
> für benutzerfreundlicher halte: Weil ich dann nicht auf den Browser
> angewiesen bin, sondern auch meinen eigenen Editor + SVN-Client nehmen
> kann. Es geht doch um Benutzbarkeit von Wikis.

Den Punkt mit dem subcersion-basierten Wiki habe ich jetzt noch
nicht gepeilt.
Kannst Du das mal noch etwas ausführen?


[...
> Nein, aber mir fehlt irgendwie der Alternativvorschlag bzw.
> Verbesserungsvorschlag. Und was du da mit "grep" erzählt hast, und
> wie das zu einer besseren Lösung führen, ist IMHO immer noch nicht
> aus deinen Ausführungen klar geworden.

Ist das mit dem docfind klarer geworden?


Ciao,
   Oliver