Computeritis

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)

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.

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.

Schon seit einer Weile stört mich, dass ein handelsüblicher Desktop-PC mit etwa 80 Watt Stromverbrauch und einem Geräuschpegel Marke »Kopfschmerzen« so viel Leistung erzeugt, dass man damit prinzipiell alles machen kann was man nie machen wird.

Daher habe ich versucht, mich an diversen Quellen über die neuen Minimalrechner, genannt »NetTop«, zu informieren. Nachdem das mehrfach missglückt ist und keiner Erfahrungen dazu hatte, habe ich mir jetzt einfach mal eine ASUS eeeBox B202 gekauft um damit selbst zu experimentieren.

Vor dem Kauf fällt auf, dass es dieses Gerät (wohlgemerkt unter der selben Modellbezeichnung) entweder mit einer Ausstattung von 2 GB RAM und einem Linux-Betriebssystem oder mit 1 GB RAM und Windows XP Home verkauft wird.
Eine RAM-Erweiterung ist zwar (nach diversen Berichten) nur mit Schraubendreher und sanfter Gewalt beim Öffnen des Gehäuses möglich, aber es stehen zwei Slots zur Verfügung.
Um das 1-GB-Modell also auf 2 GB zu erweitern benötigt man kostenverursachenderweise nur einen 1-GB-SO-DIMM-Riegel, der im freien Markt momentan ca. 10-15 € kostet.

Wenn man jetzt also unterstellt, dass das Linux-System keine nenneswerten Lizenzkosten verursacht und der Aufwand, en ASUS zur Anpassung von Windows betreibt in etwa gleich ist wie der, den ASUS zur Anpassung ihres Linux-Systems treibt, dann ist zu erwarten, dass das Windows-Modell um die Windows-Lizenz minus 10-15 € teurer ist. Da man natürlich nicht weiß, was eine Windows-XP-Lizenz für einen Großabnehmer kostet, muss ich das empirisch herausfinden.

Da sich das Angebot bzgl. der Verfügbarkeit und der Preise momentan mehrmals täglich ändert, ist der Preisspiegel meiner Bestellung jetzt nicht mehr so extrem nachzuvollziehen:
Letzte Woche wurde die Linux-Variante mit 2 GB RAM um etwa 20 € teurer verkauft als die Windows-Variante.
Das macht einen Windows-Lizenzpreis von -5-10 € pro verkauftem Gerät.

Da bei mir noch nicht absehbar war, wo genau das Gerät später eingesetzt wird und ob dafür die Windows-Lizenz eine Relevanz hat, habe ich mich für diese entschieden, da es mich insgesamt einfach billiger kommt, selbst wenn ich das RAM-Upgrade noch machen möchte.

Schließlich ist es also so, dass sich keiner wundern braucht, dass sich die Windows-Version so viel besser verkauft, da die Linux-Version wirtschaftlich einfach keinen Sinn macht. Und auf einem Desktop-Rechner den man für die tägliche Arbeit einsetzen möchte, würde ich auch ungern das on ASUS vorgekaute Minimalsystem einsetzen sondern lieber ein aktuelleres, Community-gepflegtes System.

Gestern habe ich den ersten wirkliche Praxiseinsatz meines neuen eTrex Legend als Auto-Navi mit OpenStreetMap-Daten hinter mich gebracht.

Zuerstmal: Nach Chemnitz an sich hätte ich natürlich auch ohne Navi gefunden, das ist jetzt nicht so wahnsinnig schwierig. Am Ortseingang Chemnitz fiel uns aber (spontan) auf, dass wir ja noch was essen müssen. Da wir grade an einem amerikanischen Fast-Food-Restaurant vorbei gefahren sind, brauchte es kein Navi um das zu finden. Allerdings haben wir dann eine Tankstelle gesucht, eine spezielle Kette sogar, da wir noch einen Tank-Gutschein dabei hatten. Das hat das Navi mit Bravour gemacht.
Von irgendwo in einem Industriegebiet in der Chemnitzer Vorstand dann das Hörsaalgebäude der TU zu finden ist dann wirklich etwas bei dem sich ein Navi als extrem praktisch erweisen kann.

Mein persönliches Fazit:
Es ist gewöhnungsbedürftig, ein Navi ohne Sprachausgabe zu haben. Das Gerät schaltet das Licht in der Standardeinstellung zu schnell wieder ab, so dass man z.B. nicht mehr bequem lesen kann, wie lange es noch bis zum Abbiegen ist. Die Beleuchtungsdauer kann man einstellen (auf Kosten der Batterien). Für die Auto-Navigation an einemtrüben Tag wäre es vermutlich sinnvoll, das Gerät mit dauerhafter, gedimmter Beleuchtung (evtl. mit externer Stromversorgung) zu betreiben. Ist Einstellungssache.

Dennoch kommen die Ansagen rechtzeitig.

Bei der Fahrt fiel auf, dass das Navi in Autobahnkreuzen viel zu wenig redet. Es wurde teilweise nur angemerkt, dass man jetzt nach rechts auf die andere Autobahn abfahren soll. In einem normalen Kleeblatt-Kreuz ist das zu wenig, da man mindestens zweimal rechts abbiegen muss.
Die Lösung des Problems liegt in den Daten, denn bisher arbeitete der Konverter mkgmap mit den selben Straßentypen für Autobahn und Autobahn-Rampen. Die Rampen haben im Garmin-Format aber einen separaten Typ, mit dem die Ansagen gleich viel brauchbarer werden. Die passende Änderung im mkgmap-Default-Style kam mit mkgmap-r975 am Mittwoch. Eine Trockenübung der selben Route mit neu erzeugtem Kartenmaterial zeigt, dass die Anweisungen jetzt korrekt ablaufen und verständlicher formuliert sind (z.B. "rechts abfahren" anstelle von "rechts halten").

Die Entwicklung bei mkgmap ist eine wahre Freude und ich bin mir sicher, dass auch die Adress-Suche bald funktionieren wird.

Nachdem wir seit ein paar Wochen mehrmals täglich mit einem bestimmt ganz interessanten, nur leider total unerwünschten Newsletter beglückt wurden, habe ich heute mal den Abmelden-Link betätigt. Ich möchte nicht sagen, um welchen Anbieter es dabei geht.

Der Link besteht an personenbezogenen Daten nur aus einem Hash, also eine zufälligen Zeichenkette. Üblicherweise legt man in einer Datenbank diesen Hash als einseitiges Identifizierungsmerkmal bei den Kundendaten ab. Eine löbliche Praxis, so wird keine E-Mail-Adresse übertragen.

Durch Aufruf der URL wurde mir meine E-Mail-Adresse angezeigt, zusammen mit der Meldung

Abmeldung

Ihre Abmeldung war erfolgreich. Wir bedauern sehr, Sie als Leser unseres geld.de-Newsletters verabschieden zu müssen.

Empfängerdaten gelöscht. IIhre persönlichen Daten und Einstellungen wurden erfolgreich aus unserem System gelöscht. Sie nehmen zukünftig nicht mehr am Empfang des geld.de Newsletters teil.

Klingt gut? Ja, tut es.

Aber es verliert seine Glaubwürdigkeit, wenn die selbe Meldung mit der selben Klartext-E-Mail-Adresse (die, wie wir wissen, nicht von mir in der URL übertragen wurde) nach einem Reload der Seite immer wieder gezeigt wird.
Noch immer weiß die Datenbank meine E-Mail-Adresse. Das sollte aber nicht so sein, wenn (wie geschrieben wurde) der Löschvorgang wirklich funktioniert hat.
Ein Löschvorgang auf die selben Daten, der wiederholt "erfolgreich" verläuft, ist keine gute Idee!

Übrigens erhält man die Abmelde-Bestätigung nur, wenn man AdBlock Plus abschaltet. ;-)