[linux-l] Warum gibt es keine einheitliche Dokumentation? (war: dwww)

[Volker Grabsch]

On Thu, Jan 04, 2007 at 01:54:33AM +0100, Steffen Dettmer wrote:
> > Ich meinte, dass du diese Umstrukturierung, Korrektur, etc.
> > mit dem Wiki-Quellcode machen könntest. Und diesen dann wieder
> > anderen zugänglich machst.
> > 
> > Erst danach bräuchtest du dann HTML- oder PDF-Konvertierung anwerfen,
> > zusammen mit irgendwelchen optischen Korrekturen.
> 
> Ja, schon klar; die Wiki-"Markup Sprache" (oder reST) als Sourcen. Aber
> ich kann mir nicht vorstellen, daraus automatisch ein Buch zu generieren
> (das ist ein Beispiel, nicht, dass ich unbedingt ein Buch bräuchte!).

Daraus kannst du aber nicht schließen, dass ein Wiki nur zum groben
Sammeln von Informationen taugt. Und darum ging es mir.

Dass beim professioneller Buchdruck am Ende immer noch etwas manuell
gemacht werden muss, ist doch normal. Den Effekt hast du bei Docbook,
TBook, Wiki-Sprachen, reST, ...

> > > DokuWiki? Was deutsches? Ich nutze noch ein altes Perl Wiki "TWiki" aus
> > > 2000, das nutzt auch RCS. Könnte man ja vuielleicht mal updaten BTW :)
> > 
> > Ich weiß nicht, woher DokuWiki kommt. Aber es ist recht gut. Ein Freund
> > von mir benutzt das intensiv. Ich benutze eher MediaWiki. Die beiden
> > haben jeweils ihre Vor- und Nachteile.
> > 
> > (DokuWiki hat viel schickere Tabellen. Dafür kann MediaWiki E-Mail bei
> > Seitenänderungen verschicken.)
> 
> DokuWiki kann keine eMails schicken?! Windows-Programm?

Damals konnte DokuWiki das nicht. Vielleicht mittlerweile doch, dann
wäre es wieder für mich interessant.

Mit einem Kommentar "Windows-Programm?" kann ich nichts anfangen.

> > TWiki habe ich mir mal angesehen, ist aber nichts für mich.
> 
> Sind da so riesige Unterschiede? Dachte, kommt man mit einem klar, kommt
> man auch mit den anderen klar? Gut, Funktionalitäten unterscheiden sich
> natürlich, Umfang etc.

Du hast dir deine Frage soeben selbst beantwortet. ;-)

> > Ich wollte eben nur einen Webzugang haben. Und weil dort noch
> > SVN-Repositories liegen (Überbleibsel von damals, als ich SVN noch
> > über HTTPS gemacht habe), habe ich mich für SSL entschieden, und
> > das konsequent umgesetzt.
> 
> ach so, schlichte Altlast, kenn ich, hab ich auch überall... 

Nö, nicht unbedingt. Öffentliche Projekte mache ich lieber via SVN
verfügbar. Dafür gibt's einfach mehr Clients, u.a. einen ziemlich
guten SVN-Client namens "Tortoise", der sehr gut in Windows integriert
ist.

Zudem kann man SVN-Repositories, via HTTP/DAV/SVN aufgesetzt, auch
direkt mit dem Browser ansteuern. Dies kann man mit entsprechenden
CGI-Scripten natürlich auch bei Mercurial & Co.

> > Das auf jeden Fall. Aber Programmierer kennen eher reST. Genauer: Sie
> > kennen README-Dateien und haben sicher sehr oft Überschriften etc.
> > in Plaintext gemacht, und dabei intuitiv genau das gemacht, was reST
> > in Regeln fasst. (z.B. Kapitel mit "====" oder "----" unterstrichen)
> 
> Ja, vermutlich. Muss man nur aufpassen, dass nicht ausversehen "syntax"
> erkannt wird, die gar nicht so gemeint ist :)

Die Gefahr ist relativ gering, wenn man nicht gerade ASCII-Art benutzt.
Und selbst die geht, wenn man gut genug einrückt, weil's dann 1:1
übernommen wird. ("Code-Blöcke", "Verbatim", oder wie auch immer man
das nennen mag)

Das ist aber ein generelles Problem, das du mit jeder Wiki-Sprache hast.
Ich denke nicht, dass reST dafür besonders anfällig ist, nur weil dessen
Syntax "intuitiver" ist. Eher im Gegenteil.

> > > Kommt sicher drauf an. Wenn nur 1% der Felder belegt sind, sind Linien
> > > bestimmt eine Gute Idee :)
> > 
> > Aber dann ist die Tabelle selbst schon die schlechte Idee, oder?
> 
> Wenns eine Feature-Enthalten-In-Matrix mit 20x20 ist?

Zu unübersichtlich.

Schau mal in Computerzeitschriften, wenn derartige Tabellen abgedruckt
sind. Da sind professionelle Designer am Werk, und du wirst sehen, dass
sie z.B. bewusst auf vertikale Linien verzichten.

Horizontale Linien bleiben, damit man nicht in der Zeile verruscht.

Stattdessen kommen in die Zellen eben keine Farben (rot/grün) oder
"X" / kein "X", sondern es wird dort nochmal der Featurename gekürzt
eingetragen. Oder es kommen Worte wie ja/nein/teilweise vor.

Tabellen übersichtlich zu gestalten ist ein großes Thema. Ich lerne
da ständig etwas Neues hinzu.

> > > Man bekommt aber Warnungen, wenn was nicht hinhaut (kann man natürlich
> > > ignorieren, klar).
> > 
> > Genau, dann darf man Hand anlegen. Aber LaTeX-Warnungen sind doch
> > meistens Fälle, die man erst kurz vor dem Druck korrigieren will,
> > und nicht in einer Arbeitsversion, bei der sich der Text noch ändert.
> 
> "Hand anlegen" geht doch aber absolut nicht, wenn das automatisch
> erzeugt ist!

Das ist leider die Crux an der Sache. Wenn *ich* aus einem *eigenen*
Format LaTeX erzeuge, kümmere ich mich darum, dass übersichtlicher
Code generiert wird. Gerade *weil* ich ihn noch nachbearbeiten möchte.

Docbook-Stylesheets und Konsorten sehen das leider anders. Der von
ihnen erzeugte Code ist unübersichtlich und kompliziert. :-(

> In Doxygen kann man \latexonly nehmen, um Spezial-Code
> einzubauen. Aber sowas will ich ja nicht, vor allem nicht in einem reST
> Dokument.

Das ist IMHO auch der falsche Weg. Direkter LaTeX-Code sollte nichts
Inhaltliches klären, sondern dem *Aussehen* des Buches den letzten
Schliff verpassen. Und das kann man ohnehin erst dann, wenn sich der
Inhalt nicht mehr ändert.

> Ausserdem möchte ich gar kein LaTeX können müssen :)

Das ist ein weiteres Argument.

Obwohl der, der LaTeX kann, ruhig ermuntert werden sollte, am
generierten Dokument den letzten Schliff vorzunehmen.

Oder dass der LaTeX-Anfänger seinen Text erst in reST/... tippt, und
dann nach LaTeX konvertiert, um eine Vorlage zu haben. Dann hätte die
Generierung sogar einen didaktischen Wert. Aber das ist noch weite
Zukunftsmusik.

> > Ich sehe daher nicht, wieso dieses Argument dafür spricht, gleich alles
> > selbst in LaTeX zu tippen oder in OpenOffice oder so, und dann nach
> > PDF zu konvertieren.
> > 
> > Nur, weil du in LaTeX kleine End-Korrekturen machen musst, schreibst
> > du lieber den ganzen Text mehrfach?
> 
> Nein, das Problem ist doch, dass ich nach jeder Änderung im reST das
> LaTeX neu erzeugen muss (also via make oder so, egal).

Ich sprach von End-Korrekturen!

Manuelle Zeilenumbrüche etc. werden sowieso hinfällig, wenn sich der
Text ändert.

> Wenn ich das
> LaTeX geändert hab, sind aber meine Änderungen weg. Also darf ich keine
> abgeleiteten Files ändern. Ich ändere ja auch nur C sourcen, nie die .o
> oder .a/.so files :)
[...]
> IMHO ist dann sowas wie \latexonly das kleiere Übel - aber so richtig
> überzeugend auch nicht...

Grundsätzlich ja, und bei klassischen Codegeneratoren würde ich vollkommen
zustimmen. (Bin kein Fan von Roundtrip-Engineering)

Aber konkret bei End-Korrekturen ist aber die nachträgliche Änderung am
LaTeX-Code viel schmerzfreier als irgendwelche \latexonly-Aktionen. Die
wären nämlich tickende Zeitbomben. Sie werden dir in Zukunft sogar eher
auf die Fuße fallen.

Beispiel: Deine End-Korrektur sieht einen manuellen Seitenumbruch vor.
Einige Zeit später kommt an diese Stelle viel mehr Text. Also: Plötzlich
stehen wenige Zeilen allein auf einer Seite.

> > > Dass ist das ganz langsame Beta-SCM? ;) Kenn ich nicht, keine Ahnung.
> > 
> > Mercurial ist schon lange darüber hinaus. 
> 
> Ohh, also ist die 0.9er Versionsnummer auf falsche Bescheidenheit
> zurückzuführen?

Ich arbeite seit einiger Zeit intensiv mit Mercurial 0.9 und bin sehr
zufrieden.

> > Und es ist verdammt schnell. Es kann locker mit GIT mithalten.
> 
> mmm... soviel Alternativen... was nimmt man da nu :)

Wie immer: Kommt drauf an, was du brauchst. Ist es was sehr kleines,
spiel mit darcs herum, dessen Kommandozeilen-Interface macht am meisten
Spaß. Sehr gut designt, sehr benutzerfreundlich!

Willst du größere Sachen (ab ein paar MB) damit machen, nimm kein
darcs. Dann brauchst du was performantes.

Magst du es klein, mit gerade so viel Features wie man wirklich braucht,
nimmt Mercurial.

Willst noch ein paar mehr Features, also bei einem sehr großen Projekt
auf Nummer sicher gehen, nimm GIT.

Willst du etwas wirklich aufgedunsenes, mit unnötiger Komplexität ohne
mehr Leistung, also wie CVS, aber Changeset-basiert, dann nimm GNU Arch.

Monotone ist auch ganz nett, ich kann es leider nicht wirklich einordnen.
Es verspricht im Gegensatz zu Arch einfachere Benutzbarkeit, kann aber
in diesem Punkt IMHO weder mit Mercurial noch mit GIT mithalten. Auch
von der Performance her sind Mercurial und GIT kaum zu schlagen.

Arch und Monotone sind also IMHO keinen Blick wert, aber das ist nur
mein oberflächlicher Eindruck. Ich kann mich da auch übel täuschen.

> > Ditto übrigens auch für Tags. Mercurial hat eine .hgtags-Datei. Sehr
> > clever gelöst, finde ich. In CVS natürlich nicht machbar, weil jede
> > Datei ihre eigene Rev.-Nummer hat.
> 
> Versteh nicht, was eine .hgtags-Datei ist. Bei CVS sind Tags Symbole
> (strings), werden z.B. bei sticky-tags in CVS/Entries und CVS/weissnicht
> verwendet. Na egal, eher Implementierungsdetails.

Jedes Changeset, und damit jede Version des Codes, hat eine eindeutige
Nummer (einen Hash). Die .hgtags ist eine einfache Textdatei, die
einigen Changesets (genauer: ihrem Hash) einen Namen (ein Tag) zuordnet.

Ist aber wirklich nebensächlich. Du wirst die .hgtags nicht per Hand
bearbeiten, das macht "hg tag ..." für dich. Du musst nur wissen, dass
du die Datei nicht löschen darfst, und dass du sie im Notfall auch mit
nem Editor gefahrlos bearbeiten kannst.

> > Vielleicht hätte ich von Anfang an Mercurial empfehlen sollen. Aber
> > die meisten, die ich bisher kennenlernte, wollten lieber erstmal
> > Subversion haben. Und gröartige Keywords, Ignore-Datein etc. hatten
> > sie eh nicht.
> 
> Ja, hab auch den Eindruck, SVN ist gut wenn man keine bes. Anforderungen hat.

Nicht ganz. Guter Windows-Client, sowie Zugriff über nicht-SSH, das sind
schon *sehr* spezielle Anforderungen. Zudem hat die Idee einer
*zentralen* Versionsnummer auch eine gewisse Berechtigung bei einfachen
Projekten. Ich habe durchaus Projekte gesehen, bei denen Subversion
schon allein wegen des prächtigen Windows-Clients "Tortoise" einfach mal
erste Wahl war.

Es sind also schon Anforderungen. Bei größeren Firmen mit größeren
Projekten dürften aber andere Anforderungen dominieren. :-)

Dennoch: Ein anfängerfreundlicher Client, gut ins Dateisystem oder
ähnlichem integrierst, das ist schon ne Anforderung, ne ziemlich harte
sogar. Da rockt Subversion AFAIK gegenüber allen anderen.
(CVS/Darcs/GIT/Mercurial/...)

> > Ich habe übrigens ein Makefile für meine Java-Sachen geschrieben.
> > Gut, damals gab es auch noch kein ant.
> 
> Ich nehm einfach händische Regeln im automake. Hab auch paar Ideen, wie
> man das relativ brauchbar machen könnte, aber dazu hat's dann noch nicht
> gereicht. Aber "make distcheck" ist wirklich cool.

Automake, sehr schöne Idee. Obwohl ein handgestricktes Makefile auch
nicht der Hit ist, zumal sich javac (bzw. jikes, den ich nehme) ja
selbstständig um die Abhängigkeiten kümmert.

> Meiner Meinung nach sind das alles Bugs. Ich verwende schon lange make,

Cool. Dann hab ich mal ne Frage: Wie stehst du eigentlich zu der Frage
des Projektes mit mehreren verschachtelten Unterordnern:

a) Jeder Unterordner ein eigenes autonomes Makefile, und "make" rekursiv
   aufrufen lassen?

b) Nur ein einziges Makefile, und in den Unterordnern höchstens Include-
   Dateien für das Haupt-Makefile.

Siehe auch: http://www.delorie.com/gnu/docs/automake/automake_33.html

> aber hatte noch nie eine Idee, wie ich GNU Make patchen oder erweitern
> wollen würde. Es geht ja schon alles, was mir einfällt. Im Gegenteil,
> die make-Leute haben viel mehr gemacht, als ich brauche. Ich muss für
> make nix programmieren, es ist alles schon fertig, ich benutze es
> einfach.

Ja, da kann ich nur zustimmen. Eines meiner besten Scripte ist sehr,
sehr klein. Dank make. Als Shell-Script oder in Perl/Python/... wäre
es ziemlich umständlich geworden. Wenn's dich interessiert:

    http://oss.m-click.ws/index.php?area=make_crontab

Ich hab's vor ein paar Wochen nochmal weiter vereinfachen können. Und
trotzdem mehr Features unterbringen können. Auf der Projektseite ist
das noch nicht dokumentiert, aber in den README-Dateien im Subversion:

    https://ds.m-click.de/svn/m-click/make-crontab/trunk/

> Diese tollen ant "tasks" sind IMHO eine Krankheit. Es gibt eine jar und
> ein unjar task. Gut, make kommt mit Regeln, die viele Ausgaben erzeugen
> auch nicht sooo einfach klar (bzw. der Mensch, der es nutzt nicht ;)),
> aber es geht.

Man kann es mit ein wenig Mühe stark verbessern. Schade, dass es
automake noch nicht kann. Das Makefile vom Linux-Kernel ist ein sehr
schönes Beispiel dafür.

Seit ich das gesehen habe, bemühe ich mich ebenfalls, in Makefiles und
Shell-Scripten für eine übersichtliche Ausgabe zu sorgen. Er bei
wirklichen Fehlern braucht man Details.

> > > > In Subversion kannst du mehrere Projekte in einem Repository haben,
> > > > und dann geht das.
> > > 
> > > Ich will ja ein Projekt mit mehreren Repositories haben. Nicht paar
> > > Unterverzeichnisse. Das das geht ist ja wohl selbstverständlich. (CVS
> > > kann das auch alles).
> > 
> > Wieso? Wo ist das Problem? Wo ist der Unterschied?
> 
> Der Unterschied ist, dass ich anfangs ja noch gar nicht weiss, aus
> welchen Repos ich Module benutzen möchte. Die Repos wissen (u.U.) nichts
> von einandern.

Kannst du ein konkretes Beispiel geben? Ich sehe immer noch nicht, was
der Sinn des ganzen ist.

Wenn ich ein Modul habe, das woanders gepflegt wird, dann packe ich es
doch in ein Unterverzeichnis, sauber vom Rest getrennt, und lasse es
dort in seiner eigenen Versionskontrolle. Es könnte sogar eine völlig
andere Versionskontrolle als das eigentliche Projekt verwenden.

Ich wüsste nicht, wieso ich in solch einem Szenario modulübergreifend
mergen wollte.

> > Egal, ob ganzes Repository oder Unterverzeichnis: in Subversion ist
> > das Auschecken dafür ein und der selbe Befehl. 
> 
> Ja klar, wie auch in CVS muss ich natürlich einmal pro Repo ein befehl
> verwenden, klar, das SVN muss ja die URL gesagt bekommen etc.
> 
> bei CVS geht jedenfalls ganz einfach:
> 
> $ cvs -d $repo1 module1
> $ cvs -d $repo2 module2
> 
> usw., danach geht ein cvs up, welches automatisch in beide Verzeichnisse
> wechselt.

Klappt mit "svn up" genauso.

Bei Mercurial ist das glaubich anders. Aber das weiß ich nicht, hab's
für so einen Zweck noch nie ausprobiert.

> > Das ist doch eine rein technische Entscheidung, ob man seine Daten in
> > mehrere oder in ein Repository steckt.
> 
> Na ja, wenn man mehrere hat, gehts Theater los, oder? Mit CVS hatte ich
> nie Ärger mit einem Repo. Erst, wenn es viele waren mit mehr als 5 Jahre
> Altersunterschied in der Versionen gingen die Probleme los.

> Atomares einchecken über mehrere repos kann ich mir jedenfalls nicht
> vorstellen. Wie auch immer. Hab ich nie so gebraucht.

Wozu auch? Ich würde die nacheinander committen, schon allein deshalb,
weil das Modul wahrscheinlich ne andere Log-Message als der Rest haben
würde.

> Notfalls branch.
> Aber die sind meiner Meinung naach mit SVN eher nerviger zu benutzen,
> finde ich. Gerade, wenn man mal ein File wechseln will, weil man da mit
> switch-super-long-URL hantieren soll. Na ja, vielleicht hab ich es nur
> noch nicht verstanden.

Es ist wirklich etwas nervig, aber die langen URLs brauchst du nicht
unbedingt.

In Mercurial ist das aber sowieso eleganter gelöst:
1 Repository = 1 Arbeitsverzeichnis = 1 Branch.
Jede Kopie ist ein potentieller Branch. Merging gehört zur Tagesordnung,
ist aber sehr schmerzfrei.

Willst du trotzdem aus irgendeinem Grund mehrere Branches in einem
Repository, geht das mit Mercurial auch. Es warnt halt nur, weil's
i.d.R. nicht das ist, was man will.

GIT hingegen ist wirklich darauf getrimmt, mehrere Branches in einem
Repository=Arbeitsverzeichnis zu halten. In meinen Augen ist das
Overkill, aber dieses Details in GIT vs. Mercurial ist ohnehin mehr
eine Geschmacks- oder Stil-Frage als alles andere. :-)

> > Will man die Repositories auf vielen verschiedenen Servern haben,
> > sieht das natürlich anders aus. Dann verstehe ich aber nicht, wieso
> > man dann dazwischen mergen sollte. Auf welcher Grundlage? Wie kommt es
> > überhaupt, dass Daten über mehrere Repositories hinweg dupliziert
> > werden?
> 
> Na, modul1 liegt auf repo1 (vielleicht ist das 5 Jahre alt und 4 nicht
> mehr benutzt worden), modul2 ist von jemand anders, anderes Land, repo2
> usw. Dann gibts Server mit open source repo3 und NDC sourcen repo4 nur
> intern erreichbar. Oder sowas.

Und an welcher Stelle musst du da zwischen verschiedenen Repositories
mergen?

> Beruflich haben wir so ein kleines "übersystem", was u.A. die sourcen
> auscheckt (im Wesentlichen ein Script, was jeweils eine konfigdatei
> benutzt) und irgendwann auch configure ausführt.

Was hat das mit dem Merging zu tun?

> > Dein konrektes Beispiel würde mich mal interessieren, das du im
> > Hinterkopf hat. Vielleicht bietet Subversion da ja was viel Eleganteres.
> 
> Also, mal was ganz blödes. Ich hab ein eigenes readline "rl2" auf Server
> opensrv. Wird vom Framework benutzt, sei closed source aber nicht
> geheim. Liegt auf server1. Der hat noch ein crypto.bin Repo mit
> binaries. Bestimmte Entwickler (Integrator, ...) dürfen auch davon die
> Sourcen benutzen, die kommen von secret1, ein besser gesicherter Server.
> oder was auch immer. Haste ne Sandbox wie:
> 
> my_system/
> my_system/readline2/...
> my_system/framework/...
> my_system/crypto.bin/...
> statt .bin haben mache auch:
> my_system/crypto/...
> 
> in my_system könnte jetzt ein Makefile liegen.
> 
> Macht das Sinn?

Ja, so würde ich das auch tun. (siehe oben)

Da musst du aber auch nicht zwischen verschiedenen Repositories mergen,
oder?

> > > Jedenfalls kann man ein SCM nicht einfach mal so wechseln, finde ich.
> > 
> > Richtig. aber bei neuen Projekten kann man neue SCM ausprobieren. Und
> > dazu kann ich heutzutage nur raten, wenn man bisher nur CVS und/oder
> > SVN kannte.
> 
> Ja, rumspielen wäre mal was. Mit einem ChangeSet-basierten. Stelle ich
> mir ziemlich genial vor, wenns denn so geht... Eine "Dimension mehr" als
> CVS und SVN (die IMHO dabei im Vergleich dann beide gleich alt aussehen
> :)).

Es ist auf jeden Fall ein Umdenken. Und von allen SCM fördert Darcs
dieses Umdenken IMHO am stärksten.

> > > Aber wenn man keine Anforderungen hat, ist SVN sicher ok.
> > 
> > SVN erfüllt auch Anforderungen, die CVS nicht hat.
> 
> Ja, ich weiss. Es kann http und basiert auf XML/SOAP.

Subversion kann HTTP(S) + WebDAV.

> > Ich starte dauernd mal was, für das ich ein SCM gebrauchen kann. Und
> > wenn ich für das SCM kein extra zentrales Repository einrichten muss
> > wie bei CVS und SVN, sondern das Arbeitsverzeichnis schon das Repository
> > ist, dann ist das sehr angenehm.
> 
> mmm... und wenn das weg ist? Platte kaputt oder so? Zentral hat auch
> Vorteile (besser für backup).

Wenn das Repository im Netz ist, ist das noch viel nerviger.
Davon abgesehen: Regelmäßige Backups tun's auch.

Bei CVS und Subversion war mein zentrales Repository von privaten
Projekten immer lokal.

Selbst wenn ich das aufspalten würde, Repository aufm Server,
Arbeitsverzeichnis bei mir zu Hause. Dann wäre das Risiko doch
viel größer, weil ich ein Problem kreige, wenn auch nur eines
der beiden stirbt.

Nein, von Sicherheit würde ich erst dann reden, wenn ich *zwei*
Rechner habe, auf denen *jeweils* alles drauf ist.

> > > > Stimmt. Auch eine gute Idee. Ich hab schon von Projekten gehört, die das
> > > > machen.
> > > 
> > > Ja? Cool. Ja, hat bestimmt Vorteile.
> > 
> > Firmenbesprechung im IRC ist was nettes. Zumal der Protokollant weniger
> > Arbeit hat.
> 
> Echt, man kann sogar ne fulltext suche machen, wäre das herrlich ;)

Jap. Wenn gerade was richtig kommt/kam, hab ich schnell ein "PROTO"
in den Channel gesprochen. (PROTO = "für's Protokoll")

Die Protokollierung im Nachhinein beschränkte sich darauf, nach Zeilen
    mein_nickname> PROTO
zu suchen, die Zeilen rundherum nochmal zu lesen, und das dann zu
zitieren oder zusammenzufassen.

Natürlich habe ich auch zwischendurch schonmal Zusammenfasungen gegeben,
um die Diskussion etwas zu ordnen. Dann hab ich gleich etwas für's
Protokoll vorgearbeitet.

Ja, sone Sitzung per IRC hat was. :-)

> > > > Verschiedene Manpages kann man wenigstens aufeinander verweisen lassen,
> > > > *ohne* gleich Internet zu benötigen. Es müsste doch sogar *leichter* für
> > > > JavaDoc, EpyDoc, Doxygen & Co. sein, Manpages statt HTML-Seiten oder gar
> > > > PDF zu erzeugen. 
> > > 
> > > doxygen kann das schon ;)
> > > 
> > > Bloss macht man nicht, weil man bei HTML links kriegt und bei man nicht.
> > 
> > ... was aber nur an schlechten Manpage-Readern liegt.
> 
> Na, wenn ein page.1.gz link auf http://xyz/otherpage.pdf zeigt usw.,
> geht am Ende ja doch wieder bloss ein Browser *und* alles sieht anders
> aus - oder?

Ja, aber man hat dann *auch* die Möglichkeit, direkt auf ein anderes
Projekt zu verweisen, ohne sich eine URL für's WWW aus den Fingern zu
saugen.

> > > > Ich habe leider immer noch nicht erfahren dürfen, wieso es für API-Docs
> > > > und Howtos *besser* sein soll, als HTML statt als Manpages vorzuliegen.
> > > 
> > > hyperlinks.
> > 
> > Okay, das ist'n Argument. Aber interne Links (auf andere lokal
> > installierte Doku) sind ein graus. Also stimmt das nicht ganz.
> 
> müsste dynamisch / logisch sein. Also ein Link "auf irgendeine
> Installation von manpage page(1)" wenn nicht lokal, kann ja HTTP
> fallback gemacht werden. Sind wir wieder bei dwww? Kenn das nicht :)

Nee, ich glaube nicht, dass dwww das macht.

Aber würde man es implementieren, könnte man z.B. auf die CGI-Manpages
von FreeBSD verlinken. Oder irgendwo im Netz ein "vollständiges" Debian
aufsetzen, dwww rüberjagen, und jedermann zur Verfügung stellen. Dann
dwww dorthin linken lassen, wenn eine Seite auf eine Manpage verweise,
die nicht lokal installiert ist.

Naja, ist aber nicht wirklich sinnvoll, dann kann man gleich die
Resource im Netz nutzen. dwww ist ja gerade für lokale Pakete da.
Also wäre der einfachere Ansatz wohl der bessere, einfach zu sagen,
"Manpage nicht vorhanden, da dass Paket XYZ nicht installiert ist".

> > > Kannste mit'm Windowsbrowser drucken.
> > 
> > Ditto. Klar sollte es im WWW als HTML vorliegen. Aber lokal sollte
> > es doch was besseres als HTML geben.
> > 
> > Und die Konvertierung nach HTML oder PDF sollte nicht im Vorfeld
> > geschehen und die Pakete bloaten, sondern on-the-fly, z.B. mit
> > einem Manpage-Betrachter, der drucken und PDF/HTML-Export beherrscht.
> > (und entsprechende Kommandozeilentools natürlich)
> 
> Dann brauchste kein PDF, weil das eh nicht besser wird, als das HTML,
> oder?

Für Ausdrucke ... doch, da kannst du mit PDF, besser gesagt LaTeX, doch
einiges mehr rausreißen als mit HTML.


Viele Grüße,

    Volker

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