Aktivieren der Müllabfuhr in Cyrus

Jeden Tag bringt man den Müll raus, aber irgendwie stapelt er sich nur neben der Mülltonne. - Die Müllabfuhr kommt nicht.
So in etwa ging es mir mit unserem Cyrus-IMAP "Mailserver"… die Benutzer leerten ihre Papierkörbe, aber der Speicherbedarf der Mails stieg immer weiter an, 2 mal mussten größere Platten gebucht werden beim Provider.
Nach einigem Untersuchen stellte ich fest das Mails die eigentlich gelöscht waren zwar aus Sicht der Benutzer weg waren, im Dateisystem waren sie aber noch vorhanden.

Tatsächlich markiert Cyrus Mails und Mailboxen nur als gelöscht, löscht sie aber nicht.
Das liegt daran das dazu die Datenbanken neu aufgebaut werden müssen, was mit hoher CPU-Last und I/O-Operationen einhergeht.

Die Müllabfuhr manuell bestellen

Um Mails zu endgültig zu löschen kann man folgenden Befehl nutzen:

Read more…

Wieso eigentlich AsciiDoc

why

Subjektiv weil ich scheinbar den Drang habe nach besseren Lösungen zu suchen als die die am weitestverbreiteten ist.
Mir sind die ausgetrampelten Wege meist zu langweilig, ich muss einen neuen, eventuell besseren Weg finden, sonst wird es mir schnell langweilig.
Ein einfaches, so macht man das ist mir zu unbefriedigend, ich will mindestens wissen warum man das so macht und ggf. welche Alternativen es gibt…

Ach so… die Artikel in diesem Blog werden bisher in AsciiDoc erstellt, das wäre der Kontext für diesen Artikel ;)

Objektiv betrachtet weil…

Warum überhaupt Markup-Sprachen und nicht HTML

Um zu verstehen warum AsciiDoc muss man verstehen warum überhaupt Markup-Sprachen und nicht einfach gleich HTML schreiben.
Häufig wird die Markup-Sprache ja letzen Endes auch wieder nur in HTML umgewandelt (manchmal auch in PDF, ePUB oder irgendetwas anderes, aber das könnte man mit HTML auch machen).
O.K. technisch gesehen ist Hyper Text Markup Language - aka. HTML auch eine Markup-Sprache, aber ich meine hier Markup im Sinne von Markdown, ReST (reStructuredText), AsciiDoc.

In der Regel aus diesen Gründen:

Sicherheitgründe - Zum Beispiel in einem Forum möchte man Benutzern erlaubern ihre Texte in fest definiertem Umfang zu gestalten, Farbe, Fett schreiben, Schriftgröße, Italic. Ggf. lässt man noch das einbinden von Bildern zu.
Markdown (häufig in diesem Bereich genutzt) bietet (oder kann darauf beschränkt werden) diesen limitierten Umfang. Der Compiler übersetzt Zeichenfolgen wie **Something** in entsprechendes HTML mit den entsprechenden CSS-Klassen.
Bestimmte Zeichenfolgen werden also fest in bestimmte HTM/CSS-Strukturen umgesetzt.
Unbeschränktes HTML hingegen würde zum Beispiel erlauben CSS-Klassen zu überschreiben und damit durch einfaches Posten die gesamte Seite umzugestalten. Oder das einbinden von Scripten, die ggf. Cross-Site-Scripting-Angriffe erlauben und damit Benutzer-Daten stehlen
Man muss bedenken: Durch das Posten (oder anderweitige hinterlegen von Daten) in einer Web-Applikation ändert ein Benutzer die gerenderte Website, HTML unterscheidet nicht zwischen Daten die Teil der eigentlichen Web-Applikation sind und Daten die durch eine dritte Partei (Benutzer) eingebracht wurden, es ist alles Teil der gleichen gerenderten Website und hat die gleichen "Rechte".

Templating/Geschlossene Systeme - Redakionssysteme, Blog-Systeme oder Systeme zum Erstellen technischer Dokumentation nutzen Templates die in Teilen bereits definieren wie die eine Seite aussehen soll und grob strukturiert ist.
Ein Bild zum Beispiel kann immer von einem sichtbaren Kasten umgeben sein. Nach einer Überchrift ein Absatz kommen, Überschriften in ein Inhaltsverzeichnis eingefügt werden usw.
Damit sich der eigentliche Schreiber darüber keine Gedanken machen muss schreibt er in Markup, der Text Processor wandelt dann anhand von Regeln das Markdown in entsprechende HTML-Strukturen um, die die gewünschten zusätzlichen Elemente und Formatierungen enthalten.

Einfachheit - Autoren wollen sich auf das Schreiben konzentrieren.
Ein Markup-System sollte also so wenig zusätzliche Schreibarbeit wie möglich verursachen, einfach zu merkende Symbole nutzen (schnell ins Blut übergehen).

Fett schreiben in HTML:

Der folgende Text<span class="bold">ist fett geschrieben</span>

In AcsiiDoc:

Der folgende Text **ist fett geschrieben**

Oder bei Tabellen:

HTML
<table>
  <tr>
    <th>Erste</th>
    <th>Zweite</th>
  </tr>
  <tr>
    <td>Datensatz 1, Spalte 1</td>
    <td>Datensatz 1, Spalte 2</td>
  </tr>
  <tr>
    <td>Datensatz 2, Spalte 1</td>
    <td>Datensatz 2, Spalte 2</td>
  </tr>
</table>
AsciiDoc
|===
|Erste|Zweite

|Datensatz1, Spalte1|Datensatz1, Spalte 1
|Datensatz2, Spalte1|Datensatz2, Spalte2
|===

O.K, aber warum nun AsciiDoc?

Es gibt 3 größere Markup-Player:

Sprache Standardisierung Dokumentatiton Umfang Einfachheit Verbreitung Werkzeugmenge

Markdown

Gibt verschiedene Dialekte mit verschiedenem Umfang

+

-
Über Erweiterungen ggf. gegeben

++

++

++

ReStructured Text

++

-

++

-

+

+

AsciiDoc

++

++

++

+

-

-

Markdown ist gut für einfache Dokumentation, da leicht zu lernen und einfache Syntax. Es ist nicht sauber spezifiziert und es gibt sehr viele Varianten, die ggf. über Erweiterungen erweitert ;) werden können.
RestructuredText ist umfangreich, man kann damit so ziemlich alles machen. Die Dokumentation ist aber eher schwer zu verstehen für normale Anwender und die Syntax teiweilse kompliziert und zeichenreich.

Tabelle in reStructuredText:
======  ======  ======
 Eins    Zwei   Länger
======  ======  ======
Wahr    Wahr    Falsch
Falsch  Falsch  Falsch
======  ======  ======
Tabelle in AsciiDoc
|===
|Eins|Zwei|Länger
|Wahr|Wahr|Falsch
|Falsch|Falsch|Falsch
|===

Oben sind die einfachsten Versionen von Tabellen in reStructuredText und AcsiiDoc zu sehen.
Die reStructuredText erfordert sehr viel mehr Steuerzeichen (die Menge der == orientiert sich am längsten Wert in der Spalte). Das Problem das die Syntax "ausführlicher" ist gibt es bei reStructuredText öfter.

Hinzu kommt das die offizielle Dokumentation von reStructuredText sich eher zäh ließt, da sie sich vom Styl eher an Entwickler von Software, als an Benutzer richtet.

Pro

  • Syntax für Grunddinge einfach wie Markown

  • Syntax so kurz wie möglich gehalten

    • man wird also weniger vom Schreiben abgelenkt

  • Umfangreich/komplexe Möglichkeiten

  • gute Dokumentation

    • Dokumentation ist benutzerorientiert

  • Standardisiert

Contra

  • Nicht weit verbreitet

  • wenig Software unterstützt es nativ

  • es gibt im Prinzip nur einen Prozessor (asciidoctor)

    • alle anderen Implementierungen sind Übersetzungen in andere Sprachen oder nicht vollständig