Bernds Blog

Peter Pramberger hat gestern Abend auf der SKS-Devel-Mailingliste angekündigt, seinen PGP-Keyserver unter keyserver.pramberger.at abzuschalten:

Several weeks ago I got a complaint from a user getting his old PGP key
removed from my keyserver. He got the usual answer in such cases, but
unfortunately wasn't accepting it. Instead he insisted on his right to get the
key removed, in accordence to the Austrian Data Protection Act (DSG 2000).

Ohne das Österreichische Datenschutzgesetz im Detail zu kennen, gehe ich stark davon aus, dass es sich zu den anderen in Europa gebräuchlichen Datenschutzgesetzen nicht all zu sehr unterscheidet. Der Fall ist also im Grunde portabel.

Nach anfänglicher Empörung stelle ich mir allerdings schon die Frage, was an der Begründung eigentlich dran ist. PGP-Keyserver funktionieren nach dem Prinzip, dass man nur öffentliche Keys hoch lädt und diese Keys dann für immer öffentlich abrufbar sein sollen. So gibt es mehrere Keyserver-Netzwerke, die ständig die Keys unter einander austauschen. Löscht man einen Key auf einem Server, wird er umgehend von einem anderen Server wieder kopiert. Eine nachhaltige Löschung ist also nicht vorgesehen und in der Praxis auch nicht möglich.

Auch wenn es sich dabei um öffentliche Schlüssel handelt, stimmt es natürlich, dass der Eigentümer beim Hochladen nicht in rechtlich brauchbarer Weise über den Umstand aufgeklärt wird, dass das eine unwiderrufliche Veröffentlichung seines Namens, seiner E-Mail-Adresse und ggf. seines Fotos ist.

Ohne dass dies irgend jemand mal zu mindest zu einem erfahrenen Anwalt trägt oder gar eine Gerichtsentscheidung provoziert, bleibt der Betrieb eines PGP-Keyservers also vermutlich eine höchst gefährliche Sache, deren juristische Konsequenzen der einfache Admin nicht abschätzen kann.

Ich musste neulich einen Rechner vollständig neu installieren und haben daher vorab neben einer Sicherung der Dateien ein HDD-Image erstellt um für den Fall der Fälle alles nochmal verfügbar zu haben.

Danach, wie es eben so ist, stellte ich Inkonsistenzen der kopierten Dateien fest und wollte auf dem gemachten Image nochmal nachschauen und die Dateien von dort nochmal kopieren. Leider war ich nicht schlau genug, einzelne Partitions-Images der stark partitionierten Festplatte zu machen sondern habe nur ein komplett-Image, das sich so natürlich nicht als Loopback mounten lässt.

Doch nach kurzer Recherche fand ich heraus, dass das gar kein Problem ist. Man muss nur mittels fdisk -l sda.img die Start-Sektor-Nummer der gewünschten Partition bestimmen, diese mit 512 multiplizieren und hat dann die Startposition der Partition in Bytes.

Mit dem Befehl
mount -o loop,offset=12345678 sda.img /mnt/image
lässt sich dann das Dateisystem dieser Partition direkt mounten.

Vermutlich ist das mal wieder eine meiner Wissenslücken, die man eigentlich nach so langer Erfahrung nicht mehr haben sollte, aber das hatte ich bis gerade eben wirklich nicht gewusst (weil nie gebraucht). :)

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.

Wir nutzen bei uns auf dem Hof eine Gigaset 3060isdn-Basisstation mit einigen Mobilteilen.

Seit einiger Zeit hatten wir das Problem, dass ein spezifisches Mobilteil nicht mehr extern angerufen werden konnte. Intern war es erreichbar und wenn man auf dessen Externnummer ein anderes Mobilteil programmiert hat, war das auch anrufbar. Also eine eher unlogische Situation.

Heute konnte ich das Problem endlich mal lösen.

Und zwar erlaubt diese Basis 8 Mobilteile (plus 2 Analoganschlüsse). Seit einiger Zeit haben wir das 7. Mobilteil angemeldet. Und just ab dem Zeitpunkt traten die Probleme (mit einem anderen Mobilteil) auf. Das fiel mir heute bei genauerem Nachdenken auf.

Heute kam mir der Geistesblitz: Wir nutzen 2 Repeater. Irgendwo meine ich mal gelesen zu haben, dass die Basis für den Repeaterbetrieb je einen Mobilteil-Slot belegt. Leider kann die Basis das nicht intern verwalten sondern erlaubt fröhlich das Anmelden aller Mobilteile, was dann aber im Betrieb zu diesen schwer nachvollziehbaren Problemen führt.

Bei uns ist das 7. Mobilteil nicht wirklich wichtig, es lag nur so tatenlos rum und wir wollten es als Babyfon einsetzen. Aber wenn man sich auf die Angabe der 8 Mobilteile verlässt, kann man da böse Überraschungen erleben.

Wir haben vor Kurzem ein Upgrade von MySQL 5.0 auf 5.1 vollzogen. Nach dem Update fiel auf, dass beim Zugriff auf einige (wenn nicht alle) Views eine Warnung kommt: View [...] has no creation context

Die Meldung lässt sich am einfachsten dadurch beheben, dass man den View einfach mit sich selbst überschreibt. Da dies bei uns eine größere Menge Views war, habe ich dazu folgendes Stück Code geschrieben.
(Ich nutze dafür unsere SQL-Library, die einfach eine gewisse Abstraktion bereitstellt, z.B. die Zugangsdaten aus einem Configfile lesen, DictCursor initialisieren und db.query() als Wrapper für db.execute() und db.fetchall(). Diese Library sollten wir wohl demnächst mal veröffentlichen. :))

#!/usr/bin/python



import re



from sql import sql

db = sql()



views = db.query("select TABLE_SCHEMA `schema`, TABLE_NAME `name` "+

                 "FROM INFORMATION_SCHEMA.VIEWS WHERE VIEW_DEFINITION =''")



for v in views:

  print 'fixing %s.%s\n=========================' % (v['schema'], v['name'])

  vdef = db.query("SHOW CREATE VIEW %s.%s" % (v['schema'], v['name']))

  new = re.sub('CREATE .* VIEW (`?%s`?.)?`?%s`?' % (v['schema'], v['name']), 

               'ALTER VIEW `%s`.`%s`' % (v['schema'], v['name']), vdef[0]['Create View'])

  db.query(new)

Unser Sohn, Alexander, wurde gestern am 18.01.2010 um 17:34 Uhr geboren. Mutter und Kind geht es gut.

(Das Foto entstand im Alter von ca. 30 Minuten. Da hast DU auch nicht besser ausgesehen. :))

Mit großem Tam-Tam hat sich am Montag das Hamburger Abendblatt zum heiligen Samariter der Old-School-Journalisten empor geschwungen und verkündet, dass man zukünftig für einen Teil der Inhalte Geld haben möchte. Wenn man sich im HA-Online-angebot umschaut, sieht man dass quasi alle Artikel nur noch gegen Gebühr angeboten werden sollen.

Ob das eine gute Idee ist? Ich möchte darauf nicht eingehen. Es ist zu abstrus.

Warum ich den Artikel schreibe, hat einen anderen Grund. Und zwar die Offenbarung vor Google, die das Abendblatt hier abliefert.
Es ist noch nicht allzu lange her, da ging durch sämtliche Online-Medien eine Welle der Entrüstung. Man sah sich konfrontiert mit einer Ausgeburt des Bösen, nämlich Google News. Google scannt selbstständig eine gigantische Menge an Artikeln auf allerlei Nachrichten-Seiten und gruppiert diese anhand von Schlagwörtern.
Beim HA habe ich zugegebener maßen nichts finden können was diese Aufregung formuliert, aber z.B. beim Spiegel gibt es einen Artikel dazu: Wie Google News Redaktionen ausbeutet.

Man mag also Google nicht. Google ist böse. Denn Google bringt einem nur noch mehr Klicks von noch mehr Kostenlosfanatikern.

Kern meines Spotts: Man nehme einen UserAgent-Switcher (z.B. als Firefox-Extension) und schalte auf eine Kennung des Google-Bot um. Et voilà, die Website des Hamburger Abendblattes steht wieder sperrangelweit offen wie gehabt und man kann alle Artikel ohne Einschränkung lesen.

Was sagt uns das? Ich glaube nicht, dass hier die Programmierer der Website einen gravierenden Fehler gemacht haben. Es ist bestimmt kein Faux-pas, dass hier der Google-Bot die Nachrichten lesen kann, die man eigentlich nur im Abonnement erhalten sollte.
Aber warum? Wäre das jetzt nicht die längt herbeigesehnte Situation, dass man dem bösen Google News (der mit einem Seiten-Login nicht wirklich umgehen kann) endlich einen Riegel vorschieben kann. Dass endlich nicht mehr mühsam geschriebene Artikel in der Kostenloskultur verpuffen.

Aber nein, es ist recht klar, dass hier einfach die Werbe-Wirkung, der Klickzahlengenerator Google nicht geschädigt werden soll.

Das muss man sich mal auf der Zunge zergehen lassen: Da ist ein Unternehmen, das eigentlich nichts weiter macht als kostenlose Dinge aufwändig zu sortieren und wiederum kostenlos abzugeben. Dieses Unternehmen wird mit dieser Tätigkeit stinkend reich. Dann ärgern sich die Kostenlos-Content-Anbieter, dass das mit dem Kostenlos-Content ja gar nicht so gedacht sei, dass man das auslesen und sortieren soll. Man soll das nur lesen (im humanen Sinne) und nicht woanders speichern. Nun wird aber anders herum, genau der eigentlich nicht kostenlose Content zufälligerweise eben doch kostenlos nur in dieses böse Unternehmen gepumpt. Da stimmt doch irgendwas nicht an der Argumentationskette, oder?


Der Hohn auf dem ganzen ist ja, dass Google aus den mittlerweile lizenzierten Agenturmeldungen auch keine schlechteren Artikel produziert als die Journalisten. Im Gegenteil, die stupide Technik von Google schafft es im Zweifel sogar, verschieden tendenziöse Beiträge über das selbe Thema nebeneinander anzuzeigen. Eine Redaktion wird mindestens die für ihre Ausrichtung am besten passende Agenturmeldung publizieren, wenn nicht sogar noch das ein oder andere "unwichtige" Detail weglassen um einen vorher festgelegten Eindruck zu vermitteln. Objektiver (Endkunden-)Journalismus kann heutzutage von einer Maschine mindestens genauso gut erledigt werden wie von einer Redaktion. Na dann, Prost Mahlzeit an die Internet-Ausdrucker.

Vor einiger Zeit habe ich in einem längeren Artikel meine ersten tiefergehenden Erfahrungen mit Energiesparlampen kommuniziert. Damals noch völlig freiwillig ohne gesetzlichen Druck. :)

Die Ergebnisse damals waren wenig befriedigend. Dennoch oder grade deswegen habe ich dieses Jahr ein weiteres Experiment gewagt und zwei weitere Energiesparlampen angeschafft. diesmal ging es um meine Wohnzimmerbeleuchtung. Dort ist ein handelsüblicher Dimmer installiert um die Lichtstärke an das gewünschte Maß anzupassen.

Inspiriert von Hannos aktuellem Artikel teile ich auch gerne die neuen Erfahrungen mit.

Energiesparlampen ohne weitere Kennzeichnung sind nicht dimmbar. Das bedeutet, wenn der Dimmer der Lampe weniger Spannung gibt als vorgesehen, dann wird diese nicht dunkler sondern geht kaputt (genauer: sie flackert und geht daraufhin vermutlich kaputt. Bis zum ende ausprobiert habe ich es nicht). Ich habe mich daher schon vor längerem nach dimmbaren Energiesparlampen umgeschaut. Vor etwa 2 Jahren habe ich eine "Osram Dulux EL Dimmable" gekauft, die (wie im letzten Artikel schon erwähnt) beim Dimmvorgang ein deutlich hörbares Brummen erzeugt hat.
Diesmal kaufte ich "Dimmerable"-Lampen von Megaman. Die brummen nicht.

Das war's dann aber auch schon mit den Vorteilen. Denn brauchbar sind diese Lampen ebenfalls nicht. Schalte ich das Licht ein, brauchen auch diese Lampen ca. 1 Sekunde bis sich überhaupt etwas tut. Dabei muss der Dimmer auf maximale Spannung eingestellt sein, sonst beginnen die Birnen sofort zu flackern und gehen dabei ebenfalls kaputt. Nach dem Einschalten macht sich irgendwann Teelicht-gleich ein warmweißer aber kaum wahrnehmbarer Licht-Schimmer bemerkbar. Erst nach ca. einer Minute ist das Licht bei der Helligkeit angelangt, die man eigentlich gleich erwartet hätte. Und erst nach Ablauf dieser Minute darf man am Dimmer drehen. Reguliert man vorher das Licht herunter, dann flackert die Lampe und geht kaputt. So sagt es auch die Bedienungsanleitung.

Mit LED-Birnen habe ich bisher keine Erfahrungen gemacht, laut diversen Quellen sollen aber auch diese grundsätzlich nicht dimmbar sein.

Vom Preis abgesehen erscheint mir die aktuellste OSRAM-Erfindung eine bessere Zukunft zu versprechen.

Osram verspricht auch für Energiesparlampen eine "Quick-Light-Technologie", die angeblich am April 2010 verbaut wird. Da ich momentan schon wegen meiner Experimente als hoffnungsloser Hippe dastehe (ich kann in meiner Wohnung nicht mehr "mal eben" das Licht einschalten, ich muss immer eine Minute warten), werde ich das weiter verfolgen und dieser der Zeit hinterher hinkenden Industrie weiter Geld in den Rachen werfen. Wir werden sehen.

Seit einer Weile hatten wir vor, anstelle von Bildern fürs Fotoalbum auch mal ein Fotobuch drucken zu lassen. Das scheiterte bisher immer daran, dass die üblichen Verdächtigen eine reine Windows-Software anbieten, die noch nicht mal unter Wine zum Laufen zu bewegen ist.

Vor etwa 2 Wochen fand ich allerdings einen Anbieter, der explizit mit der Unterstützung von Linux wirbt. Das hat mich gleich fasziniert und ich beschloss, dieses Angebot wahrzunehmen. Am Montag kam dann das fertige Buch an.

Da ich sehr zufrieden war, nenne ich gerne Namen: Es handelt sich um die Firma fotobuch-profi.de, die das Java-Programm Photux benutzt.

Die Java-Software läuft auf vielen Plattformen, ich konnte und wollte nur Linux/x86 und Linux/amd64 testen. :) Für den einfachen Anwender gibt es zwei Stolpersteine, die der Hersteller noch ausräumen sollte.

1. Die Speicher-Beschränkung von Java. Normalerweise hat unter Linux jedes Java-Programm nur 64 MB RAM zur Verfügung. Das mag im letzten Jahrtausend bei der Erfindung von Java eine sinnige Idee gewesen sein, heute ich das zumindest für eine Bildbearbeitung wesentlich zu knapp. Das Programm selbst kann das Limit logischerweise nicht verändern, man muss dies in der Start-Kommandozeile machen. Der Händler nennt zwar die passende Kommandozeile, liefert für Linux aber eine blanke JAR-Datei aus. Ein einfaches Script zum Starten der Anwendung mit den richtigen Parametern könnte hier echt weiter helfen.

2. Das Programm erlaubt die Verwendung diverser Bildformate. Bindet man jedoch ein PNG mit indizierten Farben ein (PNG kann beides, indizierte Farben und RGB), so schlägt die Übertragung zur Druckerei fehl ohne eine eindeutige Fehlermeldung. Es hat mich einige Stunden experimentieren gekostet um diesen Umstand herauszufinden. Wandelt man das PNG in RGB um, klappt es.

Abgesehen davon lief alles reibungslos, die Designer-Software ist akzeptabel in der Bedienung (was nicht heißt, dass ich nicht Verbesserungsvorschläge hätte) und das Druck-Ergebnis exzellent (im Gegensatz zu meinem Display sind die Bilder etwas dunkler gedruckt worden. Das macht aber mein Farblaser hier auch, vermutlich ist mein LCD einfach etwas zu hell eingestellt).

Der Preis ist zwar nicht grade Dumping, aber die Qualität des Buches stimmt. Die Produktionszeit von etwa einer Woche (zzgl. Versand) ist auf der Internetseite gut dokumentiert und stört mich nicht.

Mein Garmin eTrex Legend kann im Lieferzustand nur Kartendaten bis maximal 2 GB Größe nutzen. Da man aus OSM-Daten sehr umfangreiche Karten erzeugen kann, tangieren aktuelle Europa-Karten diese Grenze bereits. Es ist also zu erwarten, dass mit weiterer Erfassung von Daten die Dateien größer werden.

Im neuesten Firmware-Update ist das Limit aber aufgehoben.

Dieses Update wollte ich also auf jeden Fall einspielen. Da ich bekanntermaßen kein Windows in Betrieb habe, gestaltet sich das aber schwierig. Vermutlich wäre das Update-Programm auch über Wine lauffähig gewesen, das habe ich nicht probiert. Da ich aus anderen Gründen neulich schon einmal ein Windows XP (Lizenz in Form der Microsoft-Steuer war ja beim Computerkauf eh dabei) in einem QEmu-Image installiert habe, benutzte ich das für das Firmware-Update.

Dazu kann man (wenn man den Parameter -monitor stdio angibt) auf der QEmu-Konsole ein USB-Gerät an das Gast-System durch reichen.
In meinem Fall sorgt der Befehl usb_add host:091e:0003 dafür, dass der Garmin eTrex durchgeschleift wurde. Das Update-Programm auf dem Gast-System erkannte dann auch das Gerät und startete das Update.

Kritisch: Während des Update-Prozesses trennt das Gerät ab und zu die Verbindung. Das erkennt man an folgenden Meldungen in der QEmu-Konsole:
husb: device 1.11 disconnected

Dann sollte man umgehend den obigen Befehl wiederholen, damit das Update fortgeführt werden kann.

Ich möchte niemandem empfehlen, das auf diese Art zu machen, aber wenn man die USB-Durchreichung schnell genug wieder herstellt, klappt das ganz gut.