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.gzaus 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.gzerzeugt 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:
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:
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.
"Was mir an git gefällt" vollständig lesenDieser Text ist überholt und nicht mehr aktuell. Ich nutze bereits seit Mitte 2010 TortoiseGit nicht mehr. Eine Anleitung für die Installation von git for Windows, dem Nachfolger von msysgit, zusammen mit plink aus dem Putty-Paket findet sich auf meinen Webseiten.
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.
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:
""Besitz" von Kinderpornographie durch Ablegen im RAM" vollständig lesenDamit 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.
Leider habe ich in den letzten Wochen - wie schon befürchtet - inhaltlich nicht mehr viel zur Liste der deutsch(sprachig)en Usenet-Hierarchien beitragen können, aber immerhin habe ich heute ein Update der Liste nach news.admin.hierarchies posten können. Bei deren Erstellung habe ich dann direkt noch einige Fehler - namentlich eine falsche Datenbankabfrage, die zu inkorrekten Angaben beim Aktualisierungsstand der Daten zu den einzelnen Hierarchien führte - im Code behoben.
Dieses Wochenende war Valentinstag, und dem Anlaß angemessen habe ich für uns ein (Heim-)Kinoprogramm mit Stieg Larsson organisiert: für Samstag stand "Verblendung" als Teil 1 der Millenium-Trilogie auf dem Programm, zu absolvieren per DVD auf der heimischen Fernseh-Couch, am heutigen Sonntag schloß sich dann ein Besuch im UFA-Kino für "Verdammnis" an, der eigentlich von einem gemeinsamen Abendessen gefolgt sein sollte. Der samstägliche Part funktionierte auch gut, aber der Kinobesuch heute! Lieber Himmel.
Unser "heimisches" Kino hatte den Film dummerweise nach nur einer Woche (!) schon wieder abgesetzt, daher mußte das UFA ran (in dem ich bisher noch nicht war); praktischerweise konnte man die Karten direkt übers Internet buchen und ausdrucken. Den ausgedruckten Wisch sollte man dann im Kino vor einen Automaten halten, der die Karten produziert; einfach und übersichtlich, sollte man denken. Nur war dem nicht so.
Es ging schon damit los, daß wir bereits in der Anfahrt in einem längeren Stau standen; wer kommt auch auf die Idee, die Einfahrt zum Parkhaus neben dem Kino wie auch dessen Ausfahrt so zu legen, daß der komplette Fußgängerverkehr von und zum Kino sie kreuzt?! Und dazu noch an zwei Stellen? Nachdem wir unter Verbrauch eines Großteils der Pufferzeit dieses Problem gemeistert hatten, standen wir dann komplett fassungslos am Ende der Eingangshalle. Die war nämlich voll. Voller Menschen. Und man war nicht in der Lage, einzelne Warteschlangen für die Kassen, die Info-Theke und den Zugang zu den Kinos abzutrennen, so daß niemand so recht wußte, wer wo hin wollte. Glücklicherweise mußten wir unsere Karten ja nur noch ausdrucken, und nach etwas Orientierungslosigkeit fiel ein Transparent auf, daß auf den entsprechenden Automaten an der Seite "neben dem Aufzug" verwies. Dort angelangt stellte sich allerdings heraus, daß dieser derzeit nicht betriebsbereit war. 
Nun war guter Rat teuer. Wir stellten uns mal "in Richtung" Infopoint an, kamen aber nicht so recht voran … Glücklicherweise bemerkte ich etliche Zeit später, daß offenbar jemand den Automaten wieder instandgesetzt hatte, eilte dorthin, druckte erfolgreich unsere Karten aus, und dann stürmten wir in aller Eile - unter Verzicht auf Popcorn, Getränke und sonst etwas - aufs Ziel los und kamen sogar noch rechtzeitig.
Kurz und gut: die Filme waren beide sehr gut - ich kann sie nur empfehlen, wenn sie auch, wie ich hörte, die Bücher stark verkürzen! -, aber dieses Kino wird uns nicht wiedersehen, wenn ich es vermeiden kann. (Den Versuch, das im selben Komplex befindliche Restaurant zu frequentieren, von dem man aus den letzten Monaten online ohnehin nur furchtbare Verrisse lesen konnte, haben wir nach einem Blick hinein dann auch abgebrochen; dort sah es ähnlich chaotisch aus. Dann lieber auf dem Heimweg eine Pizza mitnehmen.)
Nachdem es jetzt - schon wieder! - Winter ist, muß ich doch einmal meinem Unmut über die Tücken des Autofahrens bei Schnee Luft machen. Das Problem ist dabei nämlich weniger die Witterung (zumindest die Haupt- und Durchgangsstraßen sind in der Regel ausreichend geräumt, gestreut oder jedenfalls befahrbar), sondern vielmehr die automobile Kompetenz der meisten Verkehrsteilnehmer. Es gibt auch bei Schneefall oder gar schneebedeckter Straße wenig Grund, zu schleichen oder seltsam Fahrmanöver vorzunehmen, und es gibt gar keinen Grund, bei weitgehend schneefreier Straße eine Geschwindigkeit von 30 km/h nicht zu überschreiten und zumeist mit nur 20 km/h zu schleichen! grrrr Selbst dann nicht, wenn der Fahrer optisch den Eindruck vermittelt, die Erfindung des Automobils noch persönlich miterlebt zu haben …
War ich einige Jahre lang täglicher Fernpendler und danach noch länger immerhin Wochenpendler, so bin ich seit Ende 2008 kaum mehr Bahn gefahren (unter anderem auch deshalb, weil Fahrten in die alte Heimat jetzt aufgrund geographischer Lageveränderungen mit dem Auto nicht mehr wesentlich länger dauern), was mich in nächster Zeit auch meinen bahn.comfort-Status kosten dürfte. Daher habe ich die wohl teilweise chaotischen witterungs- und wartungsbedingten Verhältnisse in der letzten Zeit bisher nicht aus erster Hand miterleben dürfen. Heute aber hatte ich eine Fahrt nach Mannheim - samt Sitzplatz - gebucht, und das hat sich in dieser Hinsicht richtig gelohnt. Ein ohnehin erfahrungsgemäß gut gefüllter ICE wird nämlich dann, wenn er nur aus einem Zugteil besteht, überraschenderweise noch deutlich voller. Zwar hatte ich (wenige Stunden vor Abfahrt!) reserviert, aber natürlich war diese Reservierung in dem nichtexistenten Zugteil. (Ist es so schwierig, entfallende Zugteile zumindest ab Kenntnis von deren Fehlen für Reservierungen zu sperren?)
Ich habe - mit Glück - noch einen Stehplatz im Eingangsbereich zwischen 1. und 2. Klasse bekommen; ein Durchkommen weiter in die 2. Klasse war unmöglich, und ein Ausweichen in die 1. Klasse nicht nur tariflich unzulässig, sondern auch eher schwierig, weil das Zugbegleitpersonal dort bereits etliche Fahrgäste - ohne Rücksicht auf die gelöste Klasse - im Gang untergebracht hatte. Die entsprechende Mitarbeiterin beschied allerdings auf Nachfrage, bzgl. nicht möglicher Reservierungen nicht der korrekte Ansprechpartner zu sein; man möge sich an das Zugbegleitpersonal wenden. Aha? Was sie dann wohl gewesen sein mag? *kopfkratz* Am-Platz-Service für die 1. Klasse? Oder nur lustlos? Anyway, nach einer kurzweiligen *hüstel* Fahrt war ich sehr früh in Mannheim, was mir dann hinreichend Zeit ließ, mein Anliegen am ServicePoint vorzutragen (der mir den Entfall des Zugteils mit dem reservierten Platz bestätigte), dann mit der Bestätigung ins Reisezentrum weiterzuziehen, um mir das Reservierungsentgeld erstatten zu lassen (was sich etwas hinzog, weil die Dame ihren Computer nicht verstand und die Mitteilung über den Ausfall eines Zugteils so interpretierte, daß dieser vorhanden gewesen sei, der andere aber nicht - glücklicherweise konnte ihr dann eine Kollegin weiterhelfen) und die 3,- € sodann unverzüglich ein Stockwerk tiefer in einen Doppel-Cheeseburger umzusetzen. Auch nicht schlecht.
Nur eine knappe Woche nach der Beihilfe hat nun auch die private Krankenversicherung ihre Erstattungszahlung überwiesen und mir die Abrechnung geschickt; gestern ging überdies auch der noch ausstehende Beihilfebescheid ein (ich finde es ja sehr angenehm, daß erst die Zahlung und dann der Bescheid kommt 
). Insgesamt empfinde ich 10 Tage für die Bearbeitung meiner Abrechnungen bei zwei verschiedenen Stellen einschließlich der Überweisung mehrerer tausend Euro als ausgesprochen schnell. Da könnte sich die eine oder andere Behörde, Firma oder Institution eine Scheibe von abschneiden.
Gestern erhielt ich per E-Mail eine Antwort auf meine nach dem scheinbaren Serverausfall vor gut einer Woche gestellte Anfrage an den Support meines Providers (gefolgt von einer Entwarnung meinerseits, daß das System wieder zur Verfügung steht), die mich mit Hinweisen beglückte, wie ich einen möglichen Hardwareschaden eingrenzen könne. kopfkratz Offenbar hat man da immer noch nicht gemerkt, daß es sich um keinen Ausfall, sondern einen Serverumzug handelte. Das schockiert mich jetzt doch etwas.
Nachdem ich inzwischen einmal systematisch die vorgenommenen Änderungen geprüft habe, bin ich im übrigen einigermaßen versöhnt (von der fehlenden Ankündigung, die wohl durch interne Kommunikationsprobleme beim Anbieter bedingt ist, einmal abgesehen). Alt scheinen bei der Maschine nur noch die Platten zu sein; der Server hat einen schnelleren Prozessor und doppelt so viel RAM bekommen, außerdem ist eine serielle Konsole angeschlossen (vermutlich hat man also nur die Platten umgeklemmt). Offenbar standardmäßig hat man dann einen neuen Kernel eingespielt und damit verbundene Konfigurationsänderungen (von /dev/hdX zu /dev/sdX und bzgl. der seriellen Konsole) vorgenommen, um sicherzugehen, daß die neue Hardware angesteuert werden kann (ursprünglich war die Maschine mit einem Debian Sarge oder Etch initialisiert worden); inzwischen habe ich den Kernel wieder durch den Debian-Kernel ersetzt, und alles läuft.
Dennoch: ich hätte lieber eine Vorwarnung vorher und/oder eine Erläuterung der Vorgehensweise hinterher gehabt, und das habe ich auch - hoffentlich hinreichend deutlich - per Feedbackformular kundgetan.