Der Martin: Mailserver unter Linux - Rat erwünscht

Beitrag lesen

Hi,

... Zumindest nicht nach meinem Anspruch an Dokumentation: Doku muss vom eigentlichen Produkt losgelöst verfügbar sein,
Dann dürftest Du mit so ziemlich jeder kommerziellen Software ernsthafte Probleme haben.

mit so mancher, ja. Wobei mein häufigster Kritikpunkt der ist, dass dem Programm ein geheimnisvoller Installer beiliegt, der vollautomatisch und möglicherweise korrekt "irgendwas" tut, und man weiß nicht, was dieses "irgendwas" ist. Eine Anleitung, wie die Software alternativ manuell zu installieren wäre, vermisse ich tatsächlich oft.
Angaben zum Funktionsumfang, den nötigen Rahmenbedingungen oder der Interoperabilität sind aber meistens problemlos zu kriegen.

Da bin ich ganz entschieden anderer Meinung. Wenn mich schon die Dokumentation vom Umfang, von der Verfügbarkeit oder von der Art der Darreichung her nicht überzeugen kann, sehe ich mich halt nach Alternativen um. Lieber benutze ich ein weniger ausgefeiltes Produkt, das ich dafür bestmöglich verstehe, als ein Superduper-Highend-Produkt, das ich nicht kapiere.
Ich verstehe nicht, warum Du so ein Problem mit binc hast.

Nicht mit Binc, sondern mit dessen Friss-oder-stirb-Konzept. Das gilt für manche andere Software auch.

binc ist gepackt wie tausende anderer Projekte auch, ein gzip- oder bzip2-komprimiertes TAR, mit einem Verzeichnis auf oberster Ebene, darunter direkt die Dateien INSTALL und README, ...

Ja. Und diese beiden Dateien auch separat an prominenter Stelle bereitzuhalten (z.B. auf der Website des Projekts), wäre das absolute Minimum, was ich erwarte.

Wenn Du es Dir von einem Dritten als fertiges Paket herunterlädst, ist es dessen Job, die Dokumentation an passender Stelle zur Verfügung zu stellen. Macht er das nicht, hat er seinen Job nicht ordentlich gemacht. => Bug Report.
Das ist *noch* ein zusätzlicher Aufwand, das ist es nicht wert.
Was ist zusätzlicher Aufwand?

Das Sich-Beschweren. Da gehe ich lieber zum nächsten Anbieter, und gut is'. Es sei denn, ich bin auf eben dieses eine Angebot angewiesen, weil es nichts Gleichwertiges gibt. Das ist ja das Schöne an der Vielfalt: Es ist für jeden was dabei.

Dream on. Gerade bei Open-Source-Software besteht die Dokumentation oft nur darin, dass der Autor sich hinstellt und sagt, "Was denn, der Code ist doch frei einsehbar". Meist sind es Dritte, die sich, der Not gehorchend, die Mühe machen, die Software zu erforschen und ihre Erkenntnisse auch anderen zur Verfügung zu stellen.
[...]
Die großen, bekannten Projekte sind gut dokumentiert, und auch viele kleine. Vorbildlich sind z.B. Apache, Perl, fast alle bei CPAN gelisteten Perl-Module, PHP soweit ich es kenne, Subversion, CVS, nmap, Samba, rsync, und sehr viele GNU-Projekte. Immer noch gut ist exim, das allerdings wie auch z.B. die gesamte djb-Doku und auch binc etwas darunter leidet, dass alles nur einmal dokumentiert ist. Der Linux-Kernel ist etwas knapp mit Dokumentation.

Apache, PHP, mySQL, Samba sind tatsächlich vorbildlich dokumentiert; darüber hinaus sind sie so verbreitet (und schon so lange am Markt), dass es unzählige Bücher gibt, die entweder in Details noch weiter in die Tiefe gehen oder bestimmte Bereiche anfängertauglich aufbereiten. Die anderen Beispiele, die du genannt hast, kenne ich nur dem Namen nach.
Aber gerade Consumer-Ware erfreut sich teilweise eines nahezu völligen Fehlens jeglicher Doku, etwa die Mozilla-Produkte. Gäbe es da nicht Millionen von Anwendern, die immer mal wieder irgendwas herausfinden, oder Programmierer, die sich wirklich die Mühe machen, die Sources zu analysieren, um herauszufinden, was da wirklich abläuft ...

Ich hab den Eindruck, das Du aus dem Frust heraus gerade eine Lernresistenz entwickelst.
Frust - ja. Lernresistenz? Bedingt. Aber beides hat nichts miteinander zu tun.
Ich denke doch.

Nein. Wie gesagt: Lernresistenz liegt bei mir dann vor, wenn ich kein klares Ziel vor Augen habe. Ich bin gern bereit, Neues zu lernen, wenn ich absehen kann, wozu es gut ist, und dass dieses Ziel auch wirklich meinen Vorsellungen entspricht. Lernen nur aus reiner Neugier? Oder weil jemand sagt, "Hier, lies mal, ist interessant"? Nicht mein Ding. Ich bin zielorientiert. Erst wenn das Ziel steht, möchte ich auch den Weg ganz genau kennen.

Lernresistenz habe ich nur dann, wenn ich keinen Sinn in dem erkenne, was ich da lernen soll.
Das ist ein riesiges Problem mit binc und der djb-Software. Du mußt ein völlig neues Konzept lernen, wie Programme miteinander interagieren, nämlich die Geschichte, Kommandozeilenparameter nur teilweise auszuwerten und den Rest stumpf an exec() weiterzureichen. Erst dann kannst Du diese Software wirklich voll nutzen.

Okay, das habe ich so zur Kenntnis genommen und sage: Danke, aber es gibt andere Methoden, die offenbar das gleiche erreichen, und die mir bereits vertrauter sind. Ich sehe nicht ein, wieder etwas anderes zu lernen, ohne dessen Vorzug klar sehen zu können.

Dovecot IMAP, das ich nun verwende, ist schön kompakt und übersichtlich: Ein Daemon, eine Konfigurationsdatei, die Maildir-Verzeichnisse und das IMAP-Protokoll zur Kommunikation. Alles drin. Und alles (zumindest alles, was ich bisher gesucht habe) dokumentiert. So wünsche ich mir das.
Und wie steht es mit der Sicherheit?

Wenn man der Beschreibung glauben darf, ziemlich gut. Aber das ist auch für mich ein nebensächliches Thema - ich bin alleiniger Nutzer des Systems und muss mich nicht vor mir selbst schützen. Wichtig ist mir Stabilität (also störungsfreier Betrieb), leichte Administrierbarkeit und kompaktes Design. Die Tatsache, dass ich als Linux-Greenhorn das Teil in knapp drei Stunden fix und fertig zum Laufen gebracht habe, spricht für sich, finde ich. DAS sind Dinge, die mir wichtig sind, nicht ein Award für elegantes und ästhetisches Softwaredesign.

Aber Dovecot läßt permanent etwas Code mit Root-Rechten laufen, dieser Prozess ist u.a. auch für das Logging zuständig.

Ja. Na und?

Zum Mail Process Design liest mal nur FIXME.

Hehe, das habe ich auch noch nicht gesehen.

Natürlich gibt es zwei Wikis, wäre ja auch langweilig mit nur einem.

Zwei? Ich habe nur ein gefunden.

Das Source-Paket ist übrigens genauso organisiert wie bei binc. README und INSTALL, daneben ein doc-Verechnis. Letzteres ist übrigens nur ein Text-Dump des Wikis, noch nicht einmal verlinktes HTML.

Ja, mag sein. Aber diese Informationen sind eben auch zugänglich, ohne dass man das Source-Archiv bereits in der Hand hat. So wie ich das erwarte und voraussetze.

Immerhin habe ich -frei nach Edison- dabei wieder etwas gelernt. Nämlich dass dieser Weg für mich nicht zufriedenstellend ist.
Vielleicht liest Du trotzdem mal das irgendwo in diesem Thread verlinkte thedjbway. Das hilft, die neuen, aber eigentlich uralten Konzepte hinter den djb-Programmen, binc und zahlreichen anderen Tools zu verstehen.

Mach ich - wenn ich mal wirklich Zeit und Muße habe.

Ciao,
 Martin

--
Fettflecke werden wieder wie neu, wenn man sie regelmäßig mit etwas Butter einschmiert.
Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(