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

[Volker Grabsch]

On Wed, Nov 23, 2005 at 01:10:49PM +0100, Oliver Bandel wrote:
> [...]
> > > 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.

Ja, aber das macht dein Argument auch nicht besser. Immerhin sind
Wikisprachen bisher das beste, was wir haben. Sicher werden nicht
alle Syntaxdetails jedem gefallen. Aber das ist Geschmackssache,
bisher waren alle Wikisprachen, die ich gesehen habe, gleichermaßen
"einfach" bzw. "schwer". Aber zu den Sprachen weiter unten.

Falls du mit "unbequemer Benutzung" auch die Wiki-Weboberflächen
meinst: die standen für mich gar nicht so im Vordergrund, da ich
sie ohnehin nur als "zusätzliche Option" zu den im SVN gelagerten
Wiki-Textdateien vorschlug.

Um die Diskussion mal voran zu bringen: Wie sollte deiner Meinung
nach eine Wiki-GUI aussehen? Was sollte man an den Weboberflächen
verbessern? Ist SVN eine gute Alternative? Oder schwebt dir noch
eine ganz andere GUI vor?

Ich denke da an GTK- oder ncurses-Applikationen, aber die würden
ja letztlich doch wieder nur einen Texteditor nachbauen. Und Plugins
für die bisherigen Texteditoren (vi,emacs,...) - außer SVN-Plugins -
würden mir auch nicht groß einfallen.


Nun zur Sprache:

> > 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".

Naja ... für *dich* vielleicht. Jemand, der seine Erfahrungen nicht
mit Textdateien, sondern nur mit Word, OpenOffice, etc. gemacht hat,
und zuerst mit der Wikipedia ein Wiki kennengelernt hat, der wird
lieber

	= Überschrift =

statt

	Überschrift
	-----------

schreiben. "Simpel" und "intuitiv" sind sehr subjektive Begriffe.
Kennst du irgendwelche Maßstäbe, mit denen man sie objektiv
bewerten kann?

Ein Maßstab wäre z.B., dass die Textdatei als solche gut lesbar
sein soll, also nicht wie ein Quellcode, sondern wie ein Dokument
(z.B. ne Readme.txt) ... in dem Fall ist reStructuredText eindeutig
das beste, und genau solch ein Format zu unterstützen, ist das
explizite Ziel dieses Projektes.

Geht es hingegen um einfachere Bearbeitung (im Sinne von Quellcode),
so sind DokuWiki und MediaWiki geeigneter. Beispiel:

	= Überschrift 2003 =

erfordert nur ein Hinztippen von " 2003". Hingegen:

	Überschrift 2003
	----------------

erfordert neben der " 2003" noch ein "-----" darunter. Sowas kann
auf Dauer nervig sein.


Jenachdem, worauf man mehr Wert legt, sagen also selbst solche
"objektiven" Kriterien nicht viel aus.


> 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").

Das ist wahr.

Aber ich persönlich z.B. würde lieber in einer MediaWiki-artigen
Sprache schreiben (weil ich das besser anpassen/bearbeiten kann),
und dann *daraus* unter anderem *.txt-Dateien generieren.

Dafür als Tipp: HTML generieren, und dann mit "w3m -dump ..."
in Text umwandeln. Ich habe damit schon gearbeitet, macht sich
ganz gut.


Ich will nicht sagen, dass MediaWiki besser als reST ist, sondern
nur, dass man das nicht pauschal entscheiden kann.

Oder fällt dir ein grundsätzlich anderes Konzept für das Verfassen
von Dokumentationen ein? Dann wäre ich sehr interessiert.


Du redest immer von "zu kompliziert" oder "muss einfacher gehen"
... werd doch bitte mal konkreter. Was würdest du anders machen,
und vorallem: Wie? Falls du da besonders neue kreative Ideen hast,
wäre ich sehr interessiert. Aber bisher lief alles auf Sachen hinaus,
die es längst gibt. Deshalb verstehe ich nicht ganz, wieso du den
Status Quo so verteufelst.

> > 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. :)

Selbst wenn du was selbst entwickeln würdest: Was konkret würdest
du anders machen, und wie? *Das* würde mich interessieren. Nicht
einfach dieses "ist mir zu umständlich".

> > 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"?

Eben, genau das habe ich gerade gesagt. :-)
SubWiki ist ein guter Ansatz. MediaWiki übrigens auch. Und auch
DokuWiki. Alle haben wunderbare Ideen und bieten coole Vorteile.
Aber solange man diese nicht kombinieren kann, ist man an die
Nachteile jedes einzelnen dieser Wikis gebunden.

> >  (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.

Dann sag doch wenigstens mal konkret, *was* dich nervt. Bisher
nur eine "zu umständliche Wikisprache" (ohne dass du genauer
wurde, welche Sprachelemente dich stören) .. und "fehlende
Suchfunktion". Ist das alles, was dich stört? So, wie du fluchst,
hätte ich mehr erwartet. ;-)

> > > 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.

Es gibt aber in sehr vielen "unbrauchbaren" Projekten auch einen guten
"Kern", d.h. wenigstens eine wirklich gute, innovative Idee. Und eben
solche Ideen muss man zusammentragen. Nicht einfach nur: Software-A
genügt gerade so meinen Ansprüchen, deshalb nehme ich es. Software-B
genügt ihnen nicht, also ignoriere ich es. So kommt man doch nicht
weiter. Wenn Software-B eine gute Idee enthält, die eine radikale
Verbesserung ermöglicht, würde ich z.B. lieber Software-B unterstützen,
als weiter mit Software-A rumzudümpeln.

> Ist es brauchbar, dann wäge ich also noch ab, ob der Installationsaufwand
> sich lohnt, das Teil zu installieren (Vorteile vs. Aufwand).

Ja, aber das musst du auch gegen deinen eigenen Programmier-Aufwandt
abwägen. Auch die Möglichkeit, das bestehende Projekt zu verbessern,
sollte immer in Betracht gezogen werden.

Da hast du schon ein paar mehr Sachen, die du gegeneinander abwägen musst.

> 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.

Gut. Deshalb ja auch meine Frage: Was *genau* nervt dich daran?

> 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.

Full Ack. Wiegesagt: Wikis ist (auch rein vom Konzept her) in dieser
Richtung IMHO das beste, was wir haben. Mir scheint aber, du willst
nicht bessere Wikis, sondern noch völlig andere Konzepte. Dann jedoch
verlierst du dich in Anspielungen und schwammigen Formulierungen. Das
bringt doch nichts. Entweder du hast ne Liste von
Verbesserungsvorschlägen für Wikis (und *bitte* etwas konkreter als
"bessere Wikisprache" ;-)), oder du hast ein besseres Gesamtkonzept.
Genau an dieser Stelle wünsche ich mir mehr Klarheit von dir, sonst
gibt es keinen Anhaltspunkt für irgendeine Diskussion.

> 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.
[...]
> > 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?

Nee, das Wiki ist mehr ein Nebenprodukt. Mir geht es darum, überhaupt
neue Wege aufzuzeigen (bzw. vorhandene Wege, die noch keine Wege, aber
schon breite Trampelpfade sind).

Meine (alles andere als neue) Kernidee war: Packt die Dokumente in
eine Versionsverwaltung, gebt den Leuten Accounts darauf, und bietet
ein Wiki-artiges Webinterface dafür an. So kann man zwei vertraute
Konzepte zusammenbringen ohne unnötigen Administrations-Overhead
(doppelte Accounts etc.):

Auf der einen Seite das lokale Arbeitsverzeichnis, an dem man größere
Überarbeitungen mit den Tools seiner Wahl (z.B. Emacs, vi, ...)
vornehmen kann, mit den Subversion-Tools seiner Wahl (Kommandozeile,
GUI, ..). Also genau das, was sich auch in der SW-Entwicklung bewährt
hat.

Auf der anderen Seite ein Webinterface, durch das man "mal eben schnell"
ein paar Änderungen vornehmen kann. Jederzeit, auch im Internetcafé, mit
einem beliebigen Browser. Auch für Anfänger gut geeignet, die bereits
Wikis und/oder Webforen kennen.


Wenn du eine grundsätzlich andere, einfachere, benutzerfreundlichere,
was-weiß-ich-Idee oder -Lösung hast, nur her damit. Würde mich sehr
interessieren. Gerade, um darüber mal Meinungen zu hören, habe ich
meine eigene Meinung hier so ausführlich dargelegt.

> > 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.

Darum ging es ja nicht. Es ging darum, Seiten, die auf nem
Server liegen, durchsuchbar zu machen. Das heißt, egal ob du
nen Browser oder ein Kommandozeilentool verwendest: Das Ding
muss irgendwann einen Remote-Zugriff zum Server tätigen.

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

Hast du bei Suchmaschinen auch. Alles nur eine Frage des Browsers.

Zum Durchforsten von verlinkten Seiten finde ich z.B. "w3m" wesentlich
angenehmer zu bedienen als "info". Außerdem braucht w3m kein extra
Datei-Format, sondern versteht sogar HTML. Und es arbeitet vollständig
"remote".  :-)

So hat jeder, was er will: Der Newbie hat nette grafische HTML-Seiten
in seinem Firefox. Leute wie du und ich hingegen können sich dieselben
Seiten auch im Textmodus ansehen und zwischen den Links (d.h.
Suchtreffern) hin- und herspringen, wie sie wollen.

Um also mal einen konkreten Vorschlag zu machen: Man könnte ein
kleines Script basteln, das als Parameter die Suchbegriffe kriegt
(wie grep), daraus eine Google- (oder Yahoo-, oder ...) Such-URL
erzeugt, und w3m bzw. lynx mit dieser URL aufruft.

Andere Ansätze wurden hier auch schon in der Liste genannt.

> > > 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.

Ich meinte damit auch kein fertiges Softwarepaket, sondern überhaupt
einen konkreten Vorschlag, wie solch eine Alternative deiner Meinung
nach aussehen sollte.

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

... auf das gesamte Internet angewendet? Nee, sicher nicht.
Aber dass solche Dienste direkt vom Server angeboten werden ...
stimmt, warum nicht?

Serverseitig müsste ein CGI-Script entsprechende Funktionalität
anbieten (sicher nicht den vollen Umfang, vorallem bei Regex
und anderes Sub-Sprachen immer vorsichtig sein!), und per Client-
Seite steuert man das über w3m, lynx (siehe oben), oder wer's
lieber mag via Firefox oder Opera.

> Auch Kaskadierung von Teilsuchen
[...]
> wäre fein.

Ack. Gerade hier bietet sich erst recht ein Webdienst an. Vielleicht
noch ein schöneres Kommandozeileninterface. Gerade die Client-Seite
kann (und sollte) man dann sehr minimalistisch halten.

Mir kommt da folgende Idee:
Ein allgemeines CGI-Interface, das z.B. folgendes macht:
	httptool http://.../index.php param1=val1 param2=val2 ...

Das würde dann die entsprechende Seite aufrufen, und via
HTTP-GET oder -POST die Parameter übermitteln. Rückgabe geschieht
wahlweise "plain text" oder besser durch einen w3m/lynx-Aufruf.
Vielleicht gibt's sowas sogar schon. w3m und lynx haben jedenfalls
leider noch keine entsprechende Syntax.

Dann in der Shell ein paar Aliase der Sorte
	alias google='httptool http://www.google.com/search'
Und Aufruf via
	google q=Suchstring


Analog dann die Berlinux-Suche:

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

Was hältst du von obigem Ansatz? Dann wäre dein docfind
quasi ein
	alias docfind='httptool http://www.belinux.de/search'
oder so ähnlich.


>> > 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.

Eben. Also benennen wir doch einfach mal die Einzelteile, und schauen
uns ihre Vor- und Nachteile an, und schauen, wie man sie (rein vom
Konzept her) zusammenbringen kann. Um genau solche Ideen
zusammenzutragen, schreibe ich doch hier!

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

Vielleicht kann das w3m.  :-)

> 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.)

Könnte auch Datenschutzgründe haben.
Außerdem ist das ein riesen Aufwandt ist, sowas sauber abzutrennen.

Auf Wunsch eines einzelnen Herren würde ich sowas auch nicht
gleich integrieren.  ;-)

> 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.

Das gute alte CGI-Interface ist mir irgendwie sympatischer. :-)
Parameter via POST und GET, dann kann man zur Not sogar ein
HTML-Formular drumherum packen, wenn man will. Jeder kann
es via Kommandozeile abrufen (wget 'http://.../xxx?param1=val1&...'),
und wenn die Rückgabe unbedingt strukturiert sein muss, dann
entweder entsprechend formatierter Plaintext oder XML. Ini-Syle
hätte auch was :-)

Keinen Plaintext anzubieten, sondern "nur" Webseiten mit HTML-Content,
der auch in w3m & lynx gut aussieht, halte ich übrigens für einen
guten Kompromiss zwischen Aufwandt und Nutzen. Ich habe kein Problem
damit, dass ein Großteil der Informationen "auf Webseiten im HTML-
Format versauert", hauptsache, man kommt mit w3m und lynx daran.
Dann hat man nämlich automatisch auch sehr gute Kommandozeilen-
Clients, denen derzeit nur das von dir gewünschte i-Tüpfelchen
fehlt.

> 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.

Ja, aber wieso nicht die bisherigen Interfaces gleich
direkt ansprechen? Deine Kritik bezog sich ja AFACIS nur
auf die Client-Seite. Serverseitig kann das ja ruhig ein
ganz normaler HTTP-Dienst sein. Nur auf Clientseite müssen
entsprechende Tools her. Wiegesagt, vielleicht gibt's die
sogar schon.

> 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.

Das wäre dann ein serverseitiges Problem. Aber ich denke, mein
Ansatz würde deinem Wunsch nach mehr Einfachheit auf Clientseite
schon voll erfüllen. Was hältst du davon?

> (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...

w3m?  :-)

Dann bräuchte man die kaskadierte Suche nur noch Serverseitig
entwickeln, und bräuchte kein extra Protokoll etc. dafür, und
wer die Commandline nicht mag, kann auf dem selben Wege auch
via Firefox daran.

> [...]
> > > > 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.

Ich habe das Fehlen von konkreten Vorschlägen und Ideen kritisiert.
Wenn du das als persönliche Beleidigung empfindest, hast du mich
missverstanden. Ich habe ja nicht gesage, dass du keine sinnvollen
Vorschläge bringen kannst, sondern nur dass in besagter Mail zu
wenig davon waren. Den "Tonfall" hast du selbst hinein interpretiert.
Ich versichere dir, nichts davon war gegen dich persönlich gerichtet.

Die Ideen und die Ausdrucksfähigkeit von jedemanden zu kritisieren,
ist übrigens IMHO genau das gleiche, wie seine Software zu kritisieren.
(weil dort sehr ähnliche Fähigkeiten gefordert sind ... nur das einmal
in einer Maschinensprache, das andere Mal in einer menschlichen)

Wenn du also meinst, es ist eine persönliche Beleidigung, jemanden
darauf hinzuweisen, dass er sich nicht klar/konkret/verständlich genug
ausdrückt bzw. dass seine Ideen nicht klar rüberkommen, dann hast *du*
ebenfalls persönliche Beleidigungen rausgehauen - nämlich gegenüber
den Programmierern der Wikis. Aber wiegesagt, ich sehe das nicht so. :-)

> Aber gut, greife ich das doch nochmal auf.
> Vielleicht macht es ja doch Sinn, darzustellen, was genau ich meine.

Natürlich macht es Sinn. Schon allein deshalb, weil es sonst all dein
bisher geschriebenes umsonst wäre, weil's kaum einer verstanden hat
und du somit kein Feedback erhältst. Es ist immer ratsam, so zu
schreiben, dass man verstanden wird, sonst kann man es auch gleich
sein lassen.  ;-)

(Huch, hab ich da grad was gegen moderne Philosophen gesagt? ...)



Viele Grüße,

	Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR