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

[Steffen Dettmer]

* Volker Grabsch wrote on Wed, Jan 03, 2007 at 04:21 +0100:
> > Gut, mag sein dass meine Vorstellungskraft für ein "Buch im Wiki"
> > einfach nicht ausreicht. Natürlich könnte man ein "export" oder sowas
> > machen. Dann ist das für mich aber eher HTML und kein Wiki.
> 
> Nein, du hast mich immer noch nicht ganz verstanden.
> 
> 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!).

> Natürlich benötigst du dazu ein Wiki, auf dessen Seiten du auch per
> Editor+SCM zugreifen kannst, das ist klar. Aber darum geht es ja, dass
> wir das wollen. Außerdem ist eine Umstrukturierung mit dem Browser
> auch noch erträglich. Zumindest mit lynx, der dir bei großen
> Textfeldern den Lieblingseditor aufruft. :-)

mozilla 1.7.x und firefox 1.5 machen das auch, nur für firefox 2 geht
das mozex wohl nicht :-(

Klar, mit den eingebauten Browsereditoren kann man maximal noch seinen
Namen irgendwo eintragen... Falls das den Begriff Editor verdient,
vielleicht eher SimpleMultiLineReader lol

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

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

> > > Diese und weitere Gedanken habe ich mal zusammengefasst:
> > >     https://dev.njh6.de/wiki/index.php?title=Wikidok
> > > 
> > > Einen sehr interessanten Thread zu dem Thema gab's hier auf der Liste
> > > auch mal.
> > 
> > (Warum geht das nicht ohne SSL/TLS? Da suggeriert ja so Sicherheit, die
> > nicht da ist, weil selfsigned cert?! 
> 
> Erstmal: Die Sicherheit besteht in der Verschlüsselung. Und die ist
> erstmal da. Das schützt vor einem großen Haufen von Attacken.
> (Obwohl der Schutz vor dem Ausspähen von Daten, die ins Wiki eingetragen
> werden, nicht wirklich sinnvoll ist, zugegeben. ;-))
> 
> Vor Man-in-the-Middle-Attacken schützt es nicht. Das stimmt.

Ja, eben, damit macht Verschlüsselung ja keinen Sinn, weil der Angreifer
sich ja via MITM den Key aussuchen kann :-) aber egal

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

> Mittlerweile ist das Wiki umgezogen nach:
>     http://wiki.njh.eu/
> 
> (Man beachte unsere neue schicke kurze EU-Domain. :-))

:-) jo

> > ja, ich erinnere mich. Aber sowas muss sich dann auch erst
> > durchsetzen... MediaWiki ist das von Wikipedia? Fragt sich, inwieweit
> > das Standard ist, weil es am meisten kennen :)
> 
> 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 :)

> > > Lamport empfielt in seinem Buch, dass man in Tabellen möglichst auf
> > > Linien verzichten sollte, das macht sie übersichtlicher. Es widerspricht
> > > allem, was ich gewohnt bin, aber nachdem ich schon ein paar mal damit
> > > herumgehadert habe, muss ich sagen: Der Mann hat recht. 
> > 
> > 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?

> Außer dünn besetzten Matrizen fällt mir nichts ein. 

achso. ja, genau :)

> Und selbst die sind ohne Linien übersichtlicher.

mmm... naja

ist ja auch egal. Wenn ich Linien will, soll ich Linien kriegen ;)

> > > Man ist viel zu leicht versucht, Doppel-Linien, dickere Linien etc.
> > > reinzubringen, obwohl man die dünnen einfach weglassen sollte.
> > > 
> > > Das ist also eher ein Feature, kein Bug.
> > 
> > Ahh, Java-Argumentation. Geht nicht, also braucht mans eigentlich gar
> > nicht, weil man einen Fall gefunden hat, wo's ohne sogar besser ist.
> > 
> > Nee, sorry aber das akzeptiere ich nicht :)
> 
> Nee, nicht ganz. Lamport scheint mir nämlich ein *fähiger* Designer zu
> sein. (Im Gegensatz zu ...)
> 
> Von daher vertraue ich diesem Urteil, dass man wirklich sparsam mit
> Tabellen-Linien umgehen soll. Und wenn ich sie doch brauche: LaTeX
> hindert mich nicht daran. (Noch ein Gegesantz zu Java)

Ja, *so* klingt das prima. "sparsam" OK, der Rat eines Experten. Aber
man wird nicht dran gehindert, falls man mal ne Ausnahme hat, wo so ne
Linie der absolute Bringer ist :)

> > > > LaTeX ist ein Satz-System, kein automatischer Formatierer.
> > > 
> > > LaTeX ist beides. Um sehr, sehr viele typische Textsatz-Probleme
> > > kümmert es sich automatisch.
> > 
> > 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! In Doxygen kann man \latexonly nehmen, um Spezial-Code
einzubauen. Aber sowas will ich ja nicht, vor allem nicht in einem reST
Dokument. Ausserdem möchte ich gar kein LaTeX können müssen :)

Aber bei Doxygen hab ich öfter mal Unschönheiten im PDF. Also, es sieht
nicht liebevoll aus. Es sieht aus wie... wie... automatisch halt. :)

> > > > oder mein Fachbegriff nicht ungünstig getrennt wird
> > > 
> > > Du kannst LaTeX Tenn-Hinweise geben:
> > > 
> > >     LangesWort\-HierTrennen
> > > 
> > > Dann trennt LaTeX dort, wenn es sich anbietet, ansonsten lässt es das
> > > Wort ganz.
> > 
> > Ja, kann man, und genau das ist für mich händisch und nicht automatisch!
> 
> Ja, sicher. Aber das braucht man erst ganz zum Schluss. Aber das davor
> (von Manpage/reST/Wiki nach LaTeX) kann man doch automatisch
> konvertieren lassen. Besser gesagt: Man sollte es sogar, IMHO.
> 
> 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). 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 :)

Da hilft einem bei automatisch erzeugten Code meist auch kein merge
(CVS/SVN), weil sich u.U. schnell verdammt viel ändert, z.B. andere
Vorlage oder Präprozessor oder was weiss ich.

IMHO ist dann sowas wie \latexonly das kleiere Übel - aber so richtig
überzeugend auch nicht...

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

> Und es ist verdammt schnell. Es kann locker mit GIT mithalten.

mmm... soviel Alternativen... was nimmt man da nu :)

> > > Die Beta-Phase hat SVN längst überwunden. Mercurial, Darcs und GIT
> > > übrigens auch.
> > 
> > CVS auch.
> 
> Hab ich nie bezweifelt. Ich sage ja auch nicht, dass der CVS-Code
> Schrott ist. Nur die Konzepte sind überholt.

Bei SVN werden doch die gleichen Konzepte verwendet (also eben keine
ChangeSets). Ich würde eher sagen, dass Konzept von SVN und CVS ist
überholt aber oft reichts, aber der CVS Code ist Schrott :)

> > Der .cvsignore-Ersatz über Properties ist IMHO übrigens eine Krankheit.
> > Warum stört die meisten das bei SVN nicht?
> 
> Mich stört's. Mercurial hat eine .hgignore, das finde ich viel
> angenehmer.
> 
> 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.

Obwohl ich mich bei SVN wundere; man wechselt branch mit switch;
verhaupt man sich um ein Level, switcht man von d1/d2/d3 nach d1/d2 und
alles ist anders lol

> > Weil man behauptet, es sei besser, nicht per default alle Dateien im
> > Repo zu haben. Wo kommt das her? Find ich nämlich nicht.
> 
> Ich auch nicht. Das spricht aber mehr für Mercurial und GIT als für
> CVS.  ;-)

Für CVS aber gegen SVN meint ich. Zu hg und GIT kann ich ja nix sagen.

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

> > Warum stört die Java-Leute das nicht? Na, weil die kein automake
> > haben und mit dem "ant" leben müssen. Das macht üblicherweise keinen
> > Fehler, wenn ein paar .java Files fehlen. Die werden dann halt nicht
> > kompiliert und fehlen im .jar dann halt.
> 
> Das ist ja übel. Wusste ich gar nicht.

Ja, sind alles "Features" und "By Convention" und so. Naja, anderes
Thema.

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

> Dennoch: Das ist so einfach. Man hat ja auch viel weniger Detail-
> Probleme zu beachten als bei C oder C++ - Programmen. Wieso ant?
> 
> Hat ant wenigstens ein paar mehr Features als make, oder hat es
> lediglich eine umständlichere (XML-)Syntax?

<anti-ant-flame>

(Ant-Fans lieber nicht weiterlesen :))

Na ja, das ant ist komisch. Die werben damit, dass alles so einfach ist.
Was macht Java meist? CLASSPATH setzen, javac, jar aufrufen. Machste mit
drei Zeilen in ant. Na, meiner Meinung nach auch in Makefile, aber man
nimmt lieber 10 Zeilen, die überall gehen, naja. Das ant braucht nix
"externes", hat also ein jar und alles eingebaut. Do not repeat
yourself. Do not repeat yourself. Do not repeat yourself. Selbst einen
eigenen ClassLoader, wozu auch immer (ich weiss das bloss, weil eines
meiner Tools seine resource-Icons unter ant nicht laden kann, weil der
ant ClassLoader nicht geht). Brauchste also jedenalls keine unportablen
tools ausser halt das ant und JDK selbst (falls man ein JDK ohne jar hat
oder was weiss ich). 

Na, und dann ist das ant "extensible" und alles. Da kann man sich in
Java was schreiben, kompilieren und ins laufende ant reinladen und
ausführen. Tolles feature.

Meiner Meinung nach sind das alles Bugs. Ich verwende schon lange make,
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.

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. Bei ant hat man da FileListen und weiss ich was. Die sind
nicht unbedingt untereinander gleichartig. Also kann sein, dass Du eine
FileListe aus einem Directory nicht als Liste für Task X benutzen
kannst, aber zum Classpath bauen. Man kann z.B. die Dateiliste aus einem
.jar Inhalt nicht iterieren. Brauchte ich mal. Da ich nicht mit
dynamisch nachladendem Code arbeiten wollte (ich möchte bei begin von
main() wissen, was ausgeführt wird und einen Fehler, falls ne Funktion
nicht definiert ist!), gabs nur eine Lösung: das jar auspacken in tmp
Verzeichnis (gibt ja unjar aber kein jar-t oder so), FileListe holen,
Iterieren, tmp-Dir löschen.

Na, und so weiter. Oder junit integration! Bei make hab ich "make check".
das klappt wenn alles klappt oder bleibt stehen wenn fehler (im
Verzeichnis). Gut automake könnte noch sofort abbrechen, das fehlt IMHO,
aber nah dran. Bei "ant test" bleibt nix stehen, falls der Fehler in
results.xml gepackt werden konnte. Dann brauchste nur noch mit einem
Webbrowser die results.xml (ich hab da insgesammt 50 oder so) händisch
durchiterieren und gucken, was da drin steht, oder so. Das finde ich
dermassen dämlich... naja. Dieser ant junit Kram ist auch so super
speziell, dass er natürlich "extensible" sein muss, will man bloss mal
ne schlichte Überschrift ändern...

Für mich ist das eine Sammlung von Ausnahmen, die nach Meinung von
Leuten (die make vielleicht nie verstanden haben, automake vermutlich
nichtmal kannten) wichtig seien. Am besten nimmst das so, wies ist -
oder hast viel Zeit. Gut, schnell ist das ant, muss man wirklich
zugeben. Gibt halt kein "make distcheck". Aber Ausnahmensammlung.
Platform-anhängige Pfade? Tja, nimmste halt verschiedene
toplevel-build.xmls (wie vor Automake-Zeiten).
SourceCode-generierung? Ha, vergiss es, aber das geht in Java eh nicht
so gut (wegen dieser Java-Disziplinierungsmassnahmen für
Aushilfsprogrammierer).  Source-Tarball? Nee, wozu, jar rules. Fehlen
files? Egal, sind im SVN ja auch nicht drin lol Man kann schlecht
automatisert testen (z.B. vor'm Taggen)? Man soll ja eclipse nehmen, ant
test knopf dürcken und XML bewundern. Taggen? Wozu, morgen ist eh alles
verändert, weil so schnell lebig lol Na ja, ist nicht so meine Welt. Ich
möchte ein Release reproduzierbar und "clean" haben. Muss dafür nicht
jede Woche eins geben, aber schön muss es sein :)

Bei uns heissen die Rules-Files echt "build.xml". Ist von ant so
empfohlen, soweit ich weiss. Meiner Meinung nach hat jeder, der
irgendwas .xml nennt, ein tiefes Verständnisproblem. Man nennt das
Makefile ja Makefile und nicht datei.txt oder datei.ascii. Nee, .xml
gehört verboten, dass ist kein Typ sondern ein Sammelbegriff (und gleich
ne Warnung)...

</anti-ant-flame> <-- auch XML ist   :)                   -->

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

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

Könnte man prima benutzen, hab ich auch, wenn CVS da nicht wieder einen
seiner komischen Bugs hätte (bei Conflicts UND SSH über mehrere
Server[namen] wird u.U. nicht vollständig geupdatet, insbesondere können
module fehlen - leider auch beim taggen!).

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

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

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. Da wird (vermutlich)
irgendwann CVS *und* SVN können. Muss man nur mit den Kommandos
aufpassen :)

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

> Genau. Mercurial und GIT sind grob gesehen etwa gleichwetig. Mercurial
> ist halt leichtgewichtiger. Das kann man mögen oder auch nicht.
> 
> Darcs ist ne Sache für sich. Aber dennoch ziemlich cool, für kleinere
> Projekte. Das hat ein phantastisches Kommandozeilen-Interface, an das
> GIT und Mercurial in 100 Jahren noch nicht rankommen werden. Aber die
> Performance und relativ kleine Community lassen Darcs (ungerechterwiese)
> etwas unattraktiv aussehen.

Danke, klingt nach einer prima Zusammenfassung. Mal sehen, ob ich mir
das merken kann :)

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

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

> Und selbst im Vergleich zu den "richtigen" :-)  SCM wie Mercurial,
> Darcs und GIT hat Subversion manchmal aufgrund seiner Einfachheit
> Vorteile.

Ja, Einfachheit kann - gerade bei kleinen Sachen - nett sein.

> > GIT oder so anzugucken nützt leider mir so allein auch nicht sooo viel,
> > weil allein brauch ich das ja auch nicht.
> 
> Du hast keine privaten Projekte?

Na, hier ja mangels Zeit (Lust?) nur CVS... Weil ich das kenne, und wenn
ich mal einen Tag Zeit habe, kann ich einen halben davon was machen
(wenn nicht wieder ein Netzteil stirbt oder so lol).

> 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). Ist irgendwie wieder einfach. Na ja, wie
immer. Die Summe der Nachteile ist konstant. :)

aber cool ist das mit dezentral, wenns denn richtig funktioniert.

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

[man, LDP/HowTO]
> Siehst du diesen Unterschied? Und genauo sowas würde ich gerne mal
> Abschaffen. Meinetwegen behalten wir das Manpage-Format, aber dann
> sollten auch die Howtos über "man" verfügbar sein. Und wer die HTML
> haben will, kriegt sie einheitlich von einem man2html-Tool präsentiert,
> mit funktionierenden Cross-Projekt-Links und allem drum und dran.

Ja, schon klar. Es sind andere Darstellungen, mehr nicht. Wäre schöner,
die Darstellungen nicht nach Art der Info zu wählen sondern nach der Art
der gewünschten Darstellung :) Wenn ich HTML will, soll ich das kriegen
(egal ob es Howto oder man page war). Eigentlich will ich offline
gucken, kriege ich auch das. Huch, was'n Satz. Der ist so komisch den
lass ich mal lol

> > Ja, oder man hätte eine Art übertool, was alles delegiert anzeigt oder
> > so, aber das Übertool sollte nicht einfach ein Browser sein. Obwohl
> > ziemlich genau das ja mal die Idee des Browsers war, der Name stimmt ja
> > noch.
> 
> Ein guter Manpage-Browser könnte das schon leisten.

ja, ein infoman2brower :)

> Aber die vielen HTML-Dokus sind nervig und unnötig schwer unter einen
> Hut zu bringen. Eine Notlösung, die das von dir beschriebene Übertool
> gerade darstellt, ist dwww. (womit wir wieder beim Aufgangsthema wären ;-))

Ja, endlich :-) lol

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

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

> > Websuche kann das auch gleich.
> 
> Websuche ist ne nette Sache, du meinst Google. 

Nee, sorry, war falsch, ich meinte Volltextsuche (glaube ich). Muss
nicht Web sein. Doxygen macht z.B. lokalen Index, suchbar (ohne Anfang
wissen zu müssen).

> Dass die API-Doc für die Veröffentlichung auf der Projekt-Homepage
> nach HTML konvertiert werden sollte, das ist mir völlig klar.
> 
> Aber lokal sind sie nicht wirklich gut durchsuchbar. Jedenfalls
> nicht so gut, wie das bei Manpages der Fall ist.

Na ja, doxygen und dann noch volltext Index drüber ist schon nicht
schlecht, finde ich.

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

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.