Aus dem Leben eines Szlauszafs

Uiuiuiuiuiuiui, hier weht es inzwischen aber auch ganz schön! Sturmtief “Xynthia” will offenbar keine halben Sachen machen ... und ich darf dafür irgendwelchen losen Teilen von unserem Balkon nachjagen, die den Abflug gemacht haben. Aber immerhin bin nicht ich derjenige, der mitten im Sturm beschlossen hat, den Hof zu kehren, weil eine Große Kehrwoche schließlich ordentlich erledigt werden muß.

Ein weiteres nettes Feature von git sind die Möglichkeiten, die git archive bietet. So läßt sich der Inhalt eines git-Repositories leicht in ein tar-File packen, bspw. für ein Release.

Voraussetzung dafür ist beim Zugriff über git-daemon, daß der entsprechende Service aktiviert ist; für das Debian-Paket bedeutet das die Erweiterung des Aufrufs in /etc/sv/git-daemon/run um den Parameter “--enable=upload-archive”.

Dann aber kann mit einem Aufruf wie

git archive --format=tar --remote=git://git.domain.example/$REPO.git --prefix=$PREFIX/ $TAG | gzip > $REPO.tar.gz

aus dem Repository $REPO.git dessen Inhalt bei Commit (oder an der Spitze des Branches, oder an dem Tag) $TAG in eine .tar.gz-Datei gepackt werden, wobei die Dateien ein $PREFIX vorangestellt bekommen.

git archive --format=tar --remote=git://git.domain.example/myprog.git --prefix=myprog-2.17/ 2.17 | gzip > myprog-2.17.tar.gz

erzeugt also aus dem Repository myprog.git in der mit “2.17” getaggten Version eine Datei myprog-2.17.tar.gz, die alle im Repository enthaltenen Dateien mit dem Verzeichnis-Präfix “myprog-2.17/” enthält.

Das ganze läßt sich noch etwas aufpeppen, wenn man bspw. bestimmte Dateien (.gitignore, ...) aus dem Repository nicht im Tarball haben möchte und/oder noch andere Änderungen vornehmen will, wie bspw. die Erzeugung eines README aus der eingebetteten POD-Dokumentation:

#! /bin/bash
# do a release of myprog
# $1: version number

# make tempdir
tempdir=`mktemp -td myprog-XXXXX`

git archive --format=tar --remote=git://git.domain.example/myprog.git --prefix=myprog-$1/ $1 | (cd $tempdir && tar xf -)

cd $tempdir/myprog-$1/
pod2text -l myprog.pl README
rm .gitignore

cd $tempdir
tar -czf /var/www/myprog/download/myprog-$1.tar.gz myprog-$1/
rm -r $tempdir

Und schließlich kann man auf diese Weise auch nur eine einzelne Datei aus dem Repository extrahieren:

git archive --format=tar --remote=git://git.domain.example/repository.git master beispiel.txt | tar xf -

extrahiert die Datei beispiel.txt aus der Spitze des Branches master des Repositorys repository.git.

Ich finde das alles ausgesprochen praktisch.

Wie am Wochenende schon angekündigt, habe ich yapfaq in den letzten Tagen etwas weiterbearbeitet. Version 0.6 (bzw., aufgrund einiger kleiner Fehler im ersten Release, Version 0.6.2) enthält neben einigen kleineren Änderungen vor allem folgende Erweiterungen:

Variabler Expires:-Header

Die bisherige Version hat einen Expires:-Header von drei Monaten gesetzt; dieser Wert ist nunmehr konfigurierbar.

Kommandozeilen-Parameter

yapfaq nimmt jetzt einige Kommandozeilen-Parameter entgegen. So können mittels “-v” Informationen über den Programmablauf ausgegeben werden; mit dem Parameter “-f” kann die Abarbeitung auf die genannte FAQ beschränkt werden, yapfaq arbeitet dann also nicht alle FAQs ab. Außerdem kann mit “-p” das Posten aller - oder einer - FAQ(s) erzwungen werden, auch wenn diese eigentlich noch nicht fällig ist; am sinnvollsten ist das im Zusammenhang mit “-f”. Die Parameter “-d” und “-t” ermöglichen Tests: “-d” führt zu einem reinen Simulationslauf, bei dem nichts gepostet wird, so daß bspw. getestet werden kann, welche FAQs zum Posten anstehen würden. “-t” ermöglicht es, die FAQ nicht in die eigentlich vorgesehene(n) Gruppe(n) zu posten, sondern stattdessen in eine Testgruppe oder auf die Konsole auszugeben, um zu prüfen, wie ein Posting aussehen würde.

Die aktuelle Version steht jeweils auf meiner Downloadseite zur Verfügung.

Perl bietet eine recht interessante und bequeme Art, die Dokumentation zu einem Script oder Modul in den Programmcode einzubetten: POD, “plain old documentation”.

Dieses Format ermöglicht es, die Dokumentation jeweils beim Code einzubetten oder doch zumindest am Ende des Programmcodes in derselben Datei zu speichern. Diese Dokumentation kann dann mittels perldoc angezeigt oder mit Hilfe von entsprechenden Tools in andere Formate - Klartext, HTML, man pages etc. - konvertiert werden, so daß die Dokumentation aus dem Sourcecode selbst erzeugt werden kann.

Mehr Informationen dazu:

• perlpod man page
• perldoc man page
• podlators (translators from POD to text and nroff from Russ Allbery)
• pod2text man page
• pod2html man page
  

Nachdem ich mich jetzt bereits einige Wochen mit git auseinandersetze, ist es vielleicht einmal Zeit für ein Fazit. Ich mag mir kein fachkundiges Urteil über git erlauben; dazu fehlt mir der wirkliche Vergleich mit anderen Versionsverwaltungssystemen und die Erfahrung mit (gemeinsamer) Softwareentwicklung, und letztlich auch der wirklich “fortgeschrittene” Umgang mit git. Ich denke aber, daß ich - obschon ich git bisher “solo” nutze, also zu seinen Stärken und Schwächen bei der Zusammenarbeit selbst nichts sagen kann - durchaus einige Punkte benennen kann, die mir an git gut gefallen.

Da wäre auf den ersten Blick bereits die Verzeichnisstruktur: wo SVN mich mit trunk, tags und branches verwirrt, gibt es bei git ein Verzeichnis .git, und das war’s.

Auch zunächst eher eine Äußerlichkeit, aber sehr bequem, ist die Möglichkeit, mit git “offline” zu arbeiten. Bei git wird die Arbeitskopie nicht aus einem zentralen Repository ausgecheckt; vielmehr wird das zentrale Repository im Normalfall komplett kopiert und steht mir dann auch offline mit der gesamten Versionsgeschichte zur Verfügung. Das ermöglicht es überdies, neben einem “offiziellen” Repository - das im Netz steht - beliebig viele “inoffizielle” Repositories vorzuhalten. Änderungen kann ich so zunächst nur in meiner Kopie des Repositories vornehmen (und sie ggf. auf andere eigene Rechner spiegeln und auch mit anderen Entwicklern austauschen) und sie erst dann veröffentlichen, wenn ich sie für veröffentlichungsreif halte. So kann ich bspw. immer nur bestimmte Zweige meines Entwicklungsrepositories in ein öffentliches Repository übertragen und andere, an denen ich noch bastele, nicht veröffentlichen.

Das problemlose Anlegen von Kopien (Zweigen, branches) ist aus meiner Sicht ein weiterer Vorteil; ein Entwicklungszweig (branch) ist trivial und schnell angelegt und ebenso schnell auch wieder entfernt. Das ermöglich ein schmerzloses Ausprobieren von Änderungen jeder Art; man kann für jede Idee einfach einmal schnell einen neuen Zweig anlegen, sie ausprobieren und dann ggf. verwerfen oder auf Eis legen kann - oder in die “eigentliche” Entwicklungslinie übernehmen. Auch lassen sich so verschiedene Ideen einfach in verschiedenen Branches entwickeln und dann jederzeit direkt in den Hauptzweig übernehmen, oder man kann sie erst noch etwas “köcheln” lassen; daneben können verschiedene Entwicklungsstränge bspw. für eine geplante neue Version und für Bugfixes älterer Versionen nebeneinander laufen.

Ergänzend dazu fasziniert mich die Möglichkeit, meine Commits nachträglich nachzubessern und neu zu sortieren. Die Möglichkeit fraktionierter Commits hatte ich bereits angesprochen; außerdem kann ich jederzeit per interaktivem rebase einzelne Commits zusammenfassen. Oder ich setze einfach nur den Index auf eine alte Version zurück, so daß ich dann die Änderungen in der aktuellen Arbeitskopie gegenüber diesem alten Zustand neu einchecken kann, auch in einzelnen Teilen. In diese Reihe gehört auch die Möglichkeit, mein lokales Repository - oder einzelne Entwicklungszweige darin - immer wieder neu auf den aktuellen Stand des “offiziellen” Repositories - oder des Hauptentwicklungszweiges - aufsetzen zu lassen. All das ermöglicht es - auch zusammen mit dem leichten Anlegen neuer branches - auf der einen Seite, nahezu beliebig “herumzuspielen” und dabei dem Motto “Commit early, commit often” zu folgen, auf der anderern Seite aber später, wenn das Feature gereift ist, eine logische Abfolge von einzelnen Patches zu committen, die die ganzen Sackgassen und Fehlversuche auslässt und möglichst einfach nachzuvollziehen ist.

Bereits Anfang Januar hatte ich von Git berichtet und danach geschildert, wie man Git-Repositories mit gitosis und gitweb, offen wie auch paßwortgeschützt, aufsetzen kann. Seitdem habe ich eine ganze Reihe Projekte in Git-Repositories eingecheckt und gewöhne mich immer mehr an die Arbeit mit Git, zumeist allerdings unter Windows (weil ich auf Laptop wie auch Desktoprechnern unter Windows arbeite).

Dazu verwende ich TortoiseGit, eine Portierung des recht bekannten (und gelobten) TortoiseSVN, und zugleich Git on Windows (msysgit), das ohnehin als Voraussetzung für die Verwendung von TortoiseGit heruntergeladen werden muß. Beide ergänzen sich, wie ich finde, recht gut. TortoiseGit ermöglicht eine einfache Definition des Remote Repository und elegante Lösungen für die Darstellung von Diffs und Merges, ganz zu schweigen von der grafischen Darstellung des Dateistatus im Explorer; die Git-Bash und GitTk aus msysgit hingegen sind m.E. optimal für Branching und (inkrementielle) Commits sowie für die Darstellung der History. Störend allenfalls, daß die Tools teilweise - trotz der einigermaßen großzügigen Ausstattung an Rechenleistung und RAM - arg langsam wirken. Insgesamt aber, wie ich finde, eine sehr bequeme Lösung.

Wie ich bereits letzten Monat erwähnte, beabsichtigte ich die Liste der “German (language) regional hierarchies” zukünftig automatisiert nach news.lists.misc zu posten. Zu diesem Zweck habe ich jetzt ein wildes Shellscript gebastelt, das die aktuelle Liste, wie schon beschrieben, in zwei Teilen herunterlädt, um Einleitung, Überleitung und Ende ergänzt, prüft, ob sich seit dem letzten Download eine Änderung ergeben hat und postet das Ergebnis dann - vermittels yapfaq - nach news.lists.misc. Bisher scheint das recht gut zu funktionieren.

Es gibt eine ganze Reihe von Lösungen, um FAQs automatisiert und regelmäßig ins Usenet zu posten:

Zum einen kann man dafür auto-faq von Ian Kluft und Paul W. Schleck nutzen, ein Perl-Script, das ich seit Ende der Neunziger für das automatische Posten diverser FAQs verwende. Es besteht aus einer Konfigurationsdatei, in der für jede FAQ definiert wird, wie sie nach wo gepostet wird. Die einzelnen FAQs sind als Textdateien abgelegt, über die Konfigurationsdatei werden die einzelnen Header und Pseudo-Header festgelegt; Message-IDs, Expires:- und Supersedes:-Header werden automatisch erzeugt. Gepostet werden die FAQs, deren Namen bei Aufruf des Scripts übergeben werden; das läßt sich via cron automatisieren, wobei für jede FAQ ein eigener crontab-Eintrag benötigt wird. auto-faq bietet einen ganzen Haufen an Optionen, hat aber den Nachteil, zum Posten zwingend inews - aus dem INN-Paket - oder vergleichbare Tools zu verwenden; außerdem bietet es eine Unzahl von Funktionen, namentlich auch zum Posten vielteiliger FAQs, die aber - jedenfalls für mich - keine Relevanz hatten. Und auto-faq wurde 1992 entwickelt und hat seit 1999, also seit über 10 Jahren, keine Änderung mehr erfahren ...

Eine Alternative dazu stellt postfaq von Russ Allbery dar, gleichfalls in Perl implementiert. postfaq verfolgt ein anderes Konzept: hinterlegt in einer Textdatei wird hier nicht nur der Body der FAQs, sondern das komplette Posting einschließlich aller Headerzeilen. Konsequenterweise wird eine gesonderte Konfigurationsdatei nicht benötigt. Auch postfaq erzeugt die notwendigen Headerzeilen und postet die beim Aufruf angegebenen FAQs, was via cron automatisiert werden kann; es benötigt dazu aber keine externen Programme wie inews o.ä. Es wird aktiv gepflegt (letzte Änderung 2008).

Und eine weitere Möglichkeit ist yapfaq (“yet another postfaq”), ein Script von Marc Brockschmidt, das ich vor etlichen Jahren bereits einmal angetestet hatte, jetzt aber nirgendwo mehr wiedergefunden habe. Marc war aber dankenswerterweise so nett, mir die aktuelle Version (letzte Änderung: Februar 2003) zu überlassen; ich plane, yapfaq noch ein wenig für meine Zwecke zu bearbeiten und weiter zu entwickeln, as time permits. Einstweilen steht yapfaq über ein Git-Repository zur Verfügung.

yapfaq arbeitet grundsätzlich vergleichbar zu auto-faq: in einer zentralen Konfigurationsdatei wird definiert, welche FAQs in welchen Abständen wohin gepostet werden sollen. Die einzelnen FAQs sind als Textdateien abgelegt, wobei die Header durch das Script beim Posten gesetzt und ergänzt werden. Im Unterschied zu auto-faq postet yapfaq aber nicht nur eine bestimme FAQ, sondern alle FAQs, die “dran” sind, die also zuletzt vor - mindestens - dem definierten Zeitraum gepostet wurden. Es ist also nicht notwendig, für jede FAQ einen eigenen crontab-Eintrag zu definieren; vielmehr kann man yapfaq einfach täglich aufrufen, und jede FAQ wird dann gepostet, soweit sie “fällig” ist.

Die letzten Tage habe ich zum Besuch der 4. Fachtagung “Betrug im Gesundheitswesen” der KKH-Allianz in Hannover verbracht. An- und Abreise mit der Bahn verliefen angenehm problemlos, das Hotel lag mehr oder weniger unmittelbar am Tagungsort, und die Tagungsabläufe waren gut organisiert. Auch die von Experten aus ihrem jeweiligen Fachbereich gehaltenen Vorträge waren mehrheitlich interessant und lehrreich, und es war ganz spannend, einige bisher nur per Telefon und Schriftverkehr bekannte Ansprechpartner auch einmal persönlich kennenzulernen. Insgesamt würde ich die Veranstaltung trotz der weiten Fahrtstrecke und des Zeitaufwands als Gewinn verbuchen.

Nicht zuletzt bot sich natürlich die Gelegenheit, den Aufenthalt zu einem Wiedersehen mit dem Sniet - samt Abstecher in eine Spielhölle, Verspeisen von Kuhbestandteilen und Wohnungsbesichtigung - zu nutzen. So gesehen sind Dienstreisen vielleicht doch nicht ganz schlecht.

Das Oberlandesgericht Hamburg hat am 15.02.2010 (- 1 Ss 86/09 -) eine bemerkenswerte - und sehr weitgehende - Entscheidung zu der Frage gefällt, wann jemand, der sich kinderpornographische Bilder oder Filme im Internet anschaut, an diesen Besitz erlangt (bzw. versucht, diesen Besitz zu erlangen). Die Frage nach dem Besitz ist deshalb entscheidet, weil das bloße Ansehen von kinderpornographischen Medien nicht strafbar ist, deren Besitz (genauer: das Unternehmen, sich Besitz zu verschaffen, also Versuch und Vollendung, § 11 Abs. 1 Nr. 6 StGB) jedoch schon (§ 184b Abs. 4 StGB).

Einfach ist der Fall, wenn jemand Fotos und Videos aus dem Netz lädt und dann ausdruckt, auf CD/DVD brennt oder auf Festplatten oder anderen Datenträgern speichert; solche Datenträger sind “Schriften” im Sinne des Gesetzes, § 11 Abs. 3 StGB, zumal das - in der Regel - nicht versehentlich zu geschehen pflegt, also der notwendige Vorsatz und Besitzwille gegeben sind (Ausnahmen sind allenfalls bei sehr großen Sammlungen pornographischer und/oder sonstiger Medien denkbar, unter denen sich eine sehr kleine Anzahl kinderpornographischer Abbildungen findet, weil dann alles dafür spricht, daß diese schlicht nicht bemerkt wurden).

Komplexer ist die Sachlage, wenn die Dateien sich zwar auf der Festplatte finden, aber nur im (Browser-)Cache (den das OLG Hamburg als “Internet-Cache” bezeichnet). Denn dann sind sie zwar faktisch im Besitz des Interessenten, die Frage ist dann aber, ob er das auch wusste und wollte. Wenn er gar nichts von dem Cache weiß - was meiner persönlichen Ansicht nach bei nicht besonders netzaffinen Benutzern der Regelfall sein dürfte -, fehlt es am Besitzwillen (und am Vorsatz). Schon das sieht das OLG Hamburg allerdings wohl anders:

Damit kann der Angeklagte über durchschnittliche Erfahrungen und Kenntnisse in der Internetnutzung verfügt haben, die nach der Auffassung schon des Tatgerichtes eine Kenntnis um das Internet-Cache einschließen. Ob ein solcher Durchschnittsstandard gegeben war, lässt das Amtsgericht unerörtert, obwohl er eher nahe liegt bei einem Internetnutzer, der sich jahrelang gezielt der Internet- und Computertechnologie zum Aufsuchen und Speichern von kinderpornographischen Dateien bedient hat und dem die Totallöschung früher gespeicherter Dateien gelungen ist.