Bernds Blog

Heute bin ich über alten Sourcecode gestolpert, den ich teilweise vor langer Zeit erstellt hatte und auch diversen Leuten versprochen hatte, das "irgendwann" als freie Software zu releasen.

Im Zuge eines Warum eigentlich nicht jetzt?-Anfalls habe ich jetzt mal zwei git-Repositories erstellt und den Code dort eingespielt und gebe diese hiermit frei.

Für beide Projekte gilt: Das war Software die ich selbst gebraucht habe und sie ist in genau dem Zustand in dem ich sie bei mir momentan benutze. So ist meist die Konfiguration im Code, auch wenn ich hoffe, dass keine Zugangsdaten mehr irgendwo enthalten sind. Die Software ist vermutlich in dem Zustand in dem sie hier angeboten wird für niemanden nützlich.

Folgende Projekte gibt es hier:

Bib2011 steht für "Bag-in-Box-Kassenprogramm". Ich verwende für unsere Mosterei schon länger ein eigenes Programm zur Kassenverwaltung. 2011 habe ich dies von Grund auf neu gemacht, gedacht für die Nutzung auf einem Touchscreen.

Der Code basiert auf Python und Qt4. Die UI-Designer-Dateien sind auch dabei.

python-solarmax ist eine Bibliothek um Ertragsdaten aus Solarmax-Wechselrichtern auszulesen. Das Paket besteht aus einer Python-Bibliothek zur Kommunikation mit dem Gerät und einem kleinen Programm das diese Bibliothek nutzt um die Ertragsdaten regelmäßig in einem SQLite-Datenbank zu speichern.

Das (proprietäre) Kommunikations-Protokoll habe ich zunächst reverse-engineered, indem ich die Hersteller-Software in einer virtuellen Maschine benutzt habe und dann im Netzwerk die Daten ausgewertet habe. Nachdem ich das praktisch fertig hatte, bekam ich vom Hersteller doch noch eine Dokumentation des Protokolls, allerdings mit unbrauchbaren Lizenzhinweisen (keine Veröffentlichung des Protokolls und keine Herstellung von Software die veröffentlicht wird). Ich habe also die Bibliothek ohne die Dokumentation fertig geschrieben.

Wenn jemand die Software interessant findet und für irgendwas eigenes brauchen kann, würde ich mich sehr über eine Nachricht freuen.

Bedingt durch das neueste Ubuntu-Release vor gut einer Woche musste ich in den letzten Tagen ein paar Rechner aktualisieren. Dazu empfiehlt sich natürlich vorher ein möglichst gutes Backup.

In einem Fall musste ich einen Rechner komplett sichern, den ich nachher 1:1 wieder herstellen möchte (auf ähnlicher aber anderer Hardware). Damit das Restore nachher möglichst schnell und einfach funktioniert, entschied ich mich dazu, dass ich /dev/sda als Komplettimage sichern möchte. Leider habe ich keinen Rechner, auf dem ausreichend Platz für das komplette Image ist. Die Festplatte ist aber nur zu einem kleinen Teil wirklich belegt. Die Erwartung war also, wenn ich das Image sofort komprimiert abspeichere, dann müsste es auf jeden Fall passen, denn leerer Platz sollte gut komprimierbar sein.

Der Transfer sollte über eine netcat-Pipe laufen (ssh-tunnel wäre auch möglich, hat aber mehr overhead).

Das Problem an der Sache war, dass ich keine Informationen über den laufenden Fortschritt der Aktion sehen konnte. Auf dem Quellrechner kann man nicht sehen, wie viel von dem Device schon ausgelesen ist und auf dem Zielhost habe ich keine Ahnung, wie groß die endgültige komprimierte Datei werden würde.

Ein kurzes Überlegen brachte mich zu der Idee, dass es eigentlich eine triviale Aufgabe sei, ein Programm zu erstellen, das einfach Daten auf stdin liest, nach stdout schreibt und dabei mitzählt und die Zahl regelmäßig ausgibt.

Bevor ich selbst Hand anlegte, suchte ich kurz im Netz und fand auch recht schnell eine Lösung: pv, steht für »pipe viewer« und macht exakt genau dieses. Das Tool kann entweder einfach mitzählen oder man gibt ihm per Parameter die erwartete Gesamtgröße der Daten, dann erhält man eine wget-ähnliche Ausgabe mit Restzeit und Prozentbalken.

Das Tool gefällt mir so gut, dass ich es sogleich für diverse andere Aktionen ebenfalls einsetze.
Dies kann dann etwa so aussehen (bei einer tar-Pipe über netcat):

$ nc -l 10.0.0.2 1111 |gunzip| pv -s 40053354750| tar x

14,6GB 0:53:34 [ 5,2MB/s] [=========>                    ] 39% ETA 1:22:55

In diesem Beispiel habe ich auch gleich das gunzip vor pv gesetzt, damit ich die wirklichen Daten zähle und nicht die komprimierten. Auf dem Quellhost arbeitet hier ein einfacheres tar xz . | nc ....

Ach ja, Fußnote: Für das eingangs genannte Szenario sollte man das gute alte gzip benutzen. Da ich möglichst gut komprimierte Daten wollte (schließlich hatte ich wenig Platz), entschied ich mich für xz als Kompressionsprogramm. Das ist aber so dermaßen langsam, dass es auch auf meinem DualCore-Rechner nur etwa 1 MB pro Sekunde komprimierten konnte und damit den ganzen Vorgang auf viele Stunden ausgedehnt hat. Leeren Platz komprimieren hätte aber auch gzip hin bekommen.

Seit geraumer Zeit haben sich bei uns neben einer beachtlichen DVD-Sammlung auch einige Filme angesammelt, die z.B. vom Fernsehen aufgezeichnet wurden.

Ich bin dagegen, für solche Filme krampfhaft ein Original-Cover zu suchen bzw. die DVD kaum vom Original unterscheibar zu machen. Im Gegenteil, ich möchte die Chance nutzen, die Filme dann einheitlich, sachlich und erkennbar zu positioniren.

In unserer lokalen Installation von VideoDB haben wir alle Filme erfasst. Sowohl die Kauf-DVDs als auch die selbst aufgezeichneten.

Um aus den dort hinterlegten Daten automatisch Cover zu erzeugen, habe ich mir gestern ein kleines Script zusammengebastelt.
Teile des Sourcecodes stammen aus einem anderen Projekt, daher auch die unsinnige Aufteilung auf zwei Dateien. Das Script ist aus der Not entstanden und so sieht es auch aus. Aber es dürfte leicht sein, daraus was eigenes zu erstellen.

Python-Code ist zugänglich unter https://svn.bwurst.org/software/dvdcover/, Lizenz: Public Domain.

Als Dateneingabe fungiert ein XML-Export (von phpMyAdmin) der "videodata"-Tabelle aus der VideoDB-Datenbank.
Ausgabe sind einzelne PDF-Dateien für die einzelnen Cover.

Nachdem ich jetzt doch von einigen Leuten weiß, die meinen greylisting-Filter bei sich einsetzen, kann ich das auch grade mal hier announcen... ;-)

Es gibt davon eine neue Version. Es gibt einen ziemlichen Bruch, es wird jetzt MySQL anstelle von SQLite als Backend benutzt. Das liegt daran, dass ich vor habe, eine selektive Whitelist (»Mails an diese Adresse bitte in den nächsten 10 Minuten nicht greylisten«) für unsere Kunden zu ermöglichen. Dazu muss es eine gemeinsame Datenbank für das webinterface und das greylisting geben, was hiermit geschehen ist.

Die offizielle Release-Seite enthält auch ein detaillierteres Change-Log.

Peinlicherweise habe ich erst ein paar Minuten nach dem Release festgestellt, dass die neue Version von courier, für die ich grade ein ebuild erstellt habe, eine kleine API-Änderung hat. ich habe mit einem Bugfix-Release der Version 2.0.1 darauf reagiert.

Wie vor einer Weile schon einmal schrieb, hat mein Handy (oder obexftp, keine Ahnung wer schuld ist) leider besondere Anforderungen, wie man Dateien für den OBEx-transfer spezifizieren muss.

Da ich ein Freund der Konsole bin und daher meine GPX-tracks immer mittels obexftp auf meinen Rechner kopiere, ist das doch etwas lästig.

Aber jetzt gibt es Abhilfe. ;-)

Um mir diese Aufgabe zu erleichtern, habe ich ein kleines Python-Programm erstellt, das zuerst obexftp aufruft um ein Verzeichnis-Listing zu erhalten und dann alle Dateien mittels obexftp -G herunterläd (-G bedeutet, Dateien werden auf dem Handy gelöscht).

Zur Verwendung muss zuerst das Python-Modul »ElementTree« installiert werden. Danach müssen die Bluetooth-Hardware-Adresse des Gegenüber und der OBEX-Datei-Pfad im Script eingetragen werden.

Download: obexget
Lizenz: GPL >= 3

Neulich konnt eich mich endlichmal aufraffen, mich um automatisiertes Onlinebanking zu kümmern um nicht immer alle Lastschriften für schokokeks.org manuell machen zu müssen.

Die gute Nachricht zuerst: Es geht einfacher als ich vermutet hatte. Ich benutze jetzt diese Kommandozeile:

aqbanking-tool debitnote --bank=60291120 --account=671279017 --rbank=12345678 --raccount=192837465 --rname="Kundenname" --value="123,00:EUR" --purpose="schokokeks.org" --purpose="Re-Nr. 1234, Kd-Nr. 05" --purpose="vom 2007-12-01" --force-check --exec

Diese Zeilen lasse ich mir von einem Script zusammen bauen, das die Daten der aktuell offenen Rechnungen aus der Datenbank liest.


Aber nun zum Ernst der Lage:
Ich hatte vor einiger Zeit in einem Blog-Posting dazu aufgerufen, dass man an das AqBanking-Projekt spenden sollte, damit der Entwickler die Spezifikationen für die neuen Volksbank-Karten kaufen kann.

Ich hatte diesen Aufruf nicht gelöscht oder geändert, weil ich der Meinung war, auch wenn diese Spezifikationen jetzt beschafft wurden, sollte der Autor einen Anreiz haben, den Code auch zu schreiben.

Jetzt allerdings muss ich diesen Aufruf entschieden zurücknehmen. Der Grund dafür ist hier zu finden:
http://www.aquamaniac.de/sites/aqbanking/user.php#aqbanking-cli

Eben dieses Kommandozeilen-Programm, mit dem ich obigen Kurztipp durchführe, wird aber der kommenden Generation der AqBanking-Schnittstelle kommerzielle Software werden und nicht mehr frei zur Verfügung stehen.

Natürlich ist das keine komplette Katastrophe, man kann (vermutlich) eines der auf AqBanking aufbauenden Programme als Vorlage für ein relativ minimalistisches, neues Kommandozeilen-Programm benutzen. Aber alleine das Vorgehen, dieses Programm ohne Erklärung, mit der fadenscheinigen Begründung "Da dieses Tool hauptsächlich professionell benutzt wurde, ist es nun nicht mehr frei verfügbar", kommerziell zu machen, finde ich sehr bedenklich.

Kombiniert mit der Erkenntnis, dass dieses Projekt nur Code annimmt, wenn die vollständigen und uneingeschränkten Verwertungsrechte an Martin Preuss übertragen werden, finde ich dieses Projekt ab sofort nicht mehr unterstützenswert. Trotz der unbestrittenen Leistung, die Martin Preuss in dieses Programm investiert, finde ich diesen Umgang mit Code-Beiträgen Dritter nicht angemessen für ein freies Projekt.

Ich hatte vor einiger Zeit den Tipp erhalten, dass man mit »Disconnected IMAP« (oder auch »Cached-IMAP« genannt) bei KMail das Verhalten hin bekommt, das ich so lange gesucht habe: IMAP aber ein Cache, der mir erlaubt, zumindest die neuesten X Mails jederzeit schnell und ohne Netzverbindung verfügbar zu haben.

Gehört, getan, habe ich mein IMAP-Konto erstmal mit einem Rotations-script ausgestattet (alle Mails älter als 1 Monat wandert in eine andere Mailbox) und das was noch da geblieben ist dann per »Disconnected IMAP« eingerichtet. Erst einmal klang das alles recht gut, die Mailbox war extrem schnell da, man kann ständig jede Mailbox öffnen, auch wenn grade eine andere abgeholt wird.

Die erste Ernüchterung kam sehr schnell: Das Abrufen der Mailbox dauerte etwa 20 Mal so lange wie vorher. Jeder Ordner für sich dauerte fast so lange wie sonst der komplette Baum. Das liegt daran, dass KMail nicht nur nach neuen Mails schaut sondern auch lokale Änderungen (gelesen, ...) hochladen muss.

Ich habe als automatisches, periodisches Abholen eingestellt, sodass ich immer alle Mails sehe. Da man auch während des Abholens andere Ordner schon lesen kann, ist das kein Problem.
Was aber etwas störend war: KMail bzw. der ganze Rechner geriet etwas in Stocken, wenn der IMAP-Abruf-Vorgang lief. Erst fiel das gar nicht sonderlich auf, dann aber immer öfter (man erkennt irgendwann den Zusammenhang ;) ). Als ich bemerkt habe, dass man während des Abrufens keine Mail mehr vernünftig verfassen kann (das Fenster war oft für ~10 Sekunden reaktionslos), habe ich den Entschluss gefasst, wieder zurück auf normales IMAP zu stellen.

Da meine Mailbox jetzt sowieso relativ klein ist, geht auch da das Abrufen sehr flott.

Fazit: Disconnected-IMAP ist eine schöne Idee, funktioniert auch prinzipiell ganz gut, muss aber noch deutlich besser auf Nebenläufigkeit optimiert werden.

Eben bei Spiegel-Online entdeckt: Weg frei für Rollstuhlfahrer.

Der Artikel beginnt mit dem, was wir beim letzten LUG-Vortrag über OpenStreetMap gelernt haben und macht dann einen heiklen Bruch, indem darauf verwiesen wird, dass das ganze auf Microsoft-PDAs und Microsoft- oder Google-Karten aufbauen soll. Das Programm, dessen Website ich auf die Schnelle nicht finden konnte, soll angeblich umsonst angeboten werden.

Sollte es sich letztlich um freie Software handeln, dann gäbe es endlich einen Ansatz von freier Navigation, das fehlt bisher noch.

Nur, in Ihrer Übereifrigkeit scheinen diese Herrschaften Informatiker übersehen zu haben, dass es mit OpenStreetMap eine Karten-Basis gibt, die sich eigentlich hervorragend eignet um dieses Projekt darauf zu stützen. Vielleicht sollte man denen das sagen? ;-)

Auch würde mich interessieren, ob dieses Programm dann auch einen Brief von Google bekommt, dass man deren Karten bitte nicht verwenden mag.

OpenHBCI heißt heute AqBanking und unterstützt sicheres Onlinebanking über HBCI unter allen mir wichtigen Betriebssystemen.

Leider war es bis dato nicht möglich, Volksbank-Karten "VR-NetWorld"-Karten damit zu benutzen, da der Hersteller die Spezifikationen streng unter Verschluß hielt.

Seit Ende letzten Jahres verteilt die Volksbank neue Karten mit einem "SECCOS"-Chip. Dafür gibt es Spezifikationen. Allerdings ist der Hersteller nicht gewillt, diese allgemein zugänglich zu machen oder eine Lizenz für Programmierer springen zu lassen.

Kostenpunkt: ~120 Euro

Martin Preuss (AqBanking-Chef) hat angekündigt, dass er das gerne implementieren mag, er aber als nicht-Volksbank-Kunde nicht gewillt ist, diesen Betrag der Community zu spendieren. Klar. :)

Auf der Aqbanking-devel-Mailingliste haben sich mittlerweile ein paar Leute gefunden, die sich an der Finanzierung der Specs beteiligen möchten. Mich eingeschlossen.

Ich rufe hiermit dazu auf, dass die Leute, die auch ein Volksbank-Konto mittels freier Software nutzen möchten, sich mit einer kleinen Spende beteiligen!

Kontodaten gibt's auf aqbanking.de.


UPDATE 2007-12-10: ich nehme diesen Aufruf zurück. Eine Begründung gibt's hier.