Hm, mag mein Google mich nicht mehr, weil ich auf meine Privatsphäre achte und seine Cookies blockiere? Oder mag mein Google keine Dateisystemverschlüsselung? Fragen über Fragen...
Transystem hat mit ihrem i-Blue 747 eine schnuckelige GPS-Empfänger/Logger-Kombination im Angebot. Nachdem ich bisher für OpenStreetMap immer mit einem GoPal getrackt habe, wollte ich mir endlich mal einen richtigen Tracker gönnen. Die Vorteile liegen auf der Hand: kleiner, leichter, weniger fehleranfällig. Mit dem GoPal lässt sich zwar im Auto etc. wunderbar tracken, aber wenn man es in die Jackentasche steckt, dann nervt es ein wenig, dass man den Bildschirm nicht ausschalten kann. Braucht unnötig Strom und macht das Gerät aufgrund der Touchscreenbedienung anfällig gegen Fehlbedienungen durch Berührung. Also für Wandern, Radfahren etc. ein eigener Tracker...
Ursprünglich hatte ich mich anhand der Hardwareliste von OpenStreetMap auf das Wintec WBT-201 eingeschossen, welches anscheinend genau meine Anforderungen erfüllt. Durch den Test bei kowoma.de kam ich zusätzlich noch auf den i-Blue als Alternative. Der hat(te) zwar wesentlich weniger Speicher (70k vs. 131k Datenpunkte), war allerdings auch ~30 billiger. Nachdem sich der Kauf nun noch ein paar Wochen hinausgezögert hatte, hat Transtec das Rennen gemacht: sie haben den i-Blue in einer neuen Variante auf den Markt geworfen, die den doppelten Speicher hat und damit ~150k Datenpunkte speichern kann. Mehr als genug für meine Ansprüche und deutlich günstiger als der Wintec. Anfang der Woche bestellt, heute bekommen.
i-Blue 747
So sieht das gute Stück aus. Zum Größenvergleich ein 20-¢-Stück daneben. Recht übersichtlich also und mit knapp 70g auch nicht schwer. Die Bedienung ist absolut simpel: entweder man betreibt ihn im Modus NAV, dann ist er ein reiner NMEA-kompatibler Empfänger und reicht die Daten via USB oder Bluetooth an PC/PDA/etc. raus. Betreibt man ihn hingegen im Modus LOG, dann zeichnet er zusätzlich zum Weiterreichen die Daten auch noch auf seinem internen Speicher auf. Mit einer Software kann man vom PC aus einstellen, was er aufzeichnen soll (Längen- u. Breitengrad, Höhe, Geschwindigkeit etc.pp) und unter welchen Bedingungen (alle x Sekunden von, alle x Meter oder über x km/h). Der Knopf in der Mitte des Geräte dient zum Setzen von Wegpunkten: drückt man ihn, dann speichert das Gerät den aktuellen Datensatz mit einem Vermerk und man kann das später als Wegpunkt auslesen. Sehr praktisch, wenn man beim Tracken was interessantes sieht und sich merken will, wo's war. Das war's auch schon am Gerät selbst. Geladen wird via USB, wobei ein Verbindungskabel zum PC, ein Netzteil und ein Stecker für's Auto beiliegen.
Ein kleines Problem gibt es (wie üblich) für mich: Software zum Auslesen des Gerätes liefert der Hersteller nur für Windows. Wäre ja auch zu schön... Als NMEA-kompatibler Empfänger stellt er kein Problem dar. Steckt man das Gerät per USB an, hat man plötzlich eine neue serielle Schnittstelle /dev/ttyUSB0 (oder äquivalent), die der gpsd mit Freuden abfragt und die entsprechenden Daten generiert. Damit funktionieren sämtliche linux-basierten Navigations- und Trackingprogramme. Das ganze soll auch problemlos via Bluetooth funktionieren, was ich allerdings noch nicht probiert habe.
An die Logs ranzukommen ist schon schwerer. Das Gerät präsentiert sich leider wie alle anderen auch nicht als USB-Massenspeicher, sondern will via serieller Schnittstelle dazu gebracht werden, die Daten rauszurücken. Die kanonische Antwort auf dieses Problem lautet: bt747, ein Java-Programm zum Auslesen und Konfigurieren der Geräte. Dummerweise konnte ich das bisher nicht ans Laufen kriegen, weil mit javax.comm fehlt, von dem mir Sun erzählt, dass es grad nicht zu haben sei. Glücklichweise hat sich jemand hingesetzt und ein Perl-Skript geschrieben, was das gleiche tut: mtkbabel. Funktioniert ebenso, auch wenn es nicht ganz so einfach zu bedienen ist. Wichtigster Aufruf: alle Daten vom Gerät laden: ./mtkbabel -s 115200 -l off -f track -w -t -a legt drei Dateien an. Eine binäre, die direkt vom Gerät kommt, eine track_trk.gpx, die den aufgezeichneten Weg enthält und eine track_wpt.gpx, die die per Knopfdruck aufgezeichneten Wegpunkte enthält. In JOSM geladen sieht das dann so aus:
Daten im JOSM
Zu sehen sind hier zwei überlagerte Strecken (Hin- und Rückfahrt) und ein Wegpunkt (das kleine Kreuz mit der Nummer 001). Die Aufzeichnungsqualität ist gut, das Gerät findet seine Satelliten schnell und arbeitet zuverlässig. Nur das Standardaufzeichnungsintervall von 5 Sekunden sollte man evtl. etwas kürzer einstellen (bspw. per mtkbabel). Ich bin im Moment bei zwei Sekunden. Mal noch ein wenig testen, was da brauchbar ist.
Insgesamt ein sehr schickes Gerät. Mal schauen, was die Zeit bringt und ob es im Dauereinsatz hält, was es bisher versprochen hat. Es gibt ja noch einige Orte hier in der Umgebung die getrackt werden wollen...
Johnny Chung Lee stellt auf seine Webseite einige Projekte mit der Wii Remote vor, die ziemlich cool sind. Das Wii Whiteboard musste ich mir gleich mal nachbauen. Andere Projekte wie das VR Display sind noch in Planung. Außerdem gibt es da noch so Ideen bzgl. Tracking von Personen und Objekten in der Pipeline...
Letztens hat mich ein aufmerksamer Leser nach einer mittleren Odyssee (jaja, ich werde mal sowas wie ein Impressum einbauen) kontaktiert um mir mitzuteilen, daß einer meiner Blogposts einen Skriptfehler beim Klick auf einen Link liefert. Ich hab mir mal etwas Zeit genommen, das ganze zu analysieren.
Konkret geht es um folgende Fehlermeldung (nur der interessante Teil):
Der Fehler zeigt die Verletzung der Eindeutigkeitsbedingung "serendipity_exits_pkey" an. Eine Eindeutigkeitsbedingung ist ein Konstrukt in einer Datenbank, welches verhindert, daß ein bestimmter Schlüssel in einer Tabelle doppelt vorkommt. Der spezielle Name dieser Bedingung hier zeigt, daß der Primary Key der Tabelle serendipity_exits gemeint ist. Um das zu verstehen muss man sich ein wenig tiefer mit dem Aufbau der Software beschäftigen: Externe Links in einem Blogpost zeigen nicht direkt auf das Ziel, sondern rufen die Datei exit.php auf, welche dann zum passenden Ziel weiterleitet. Ziel der Aktion ist es, nochmal eine Statistik erfassen zu können, welche Links im Blog besonders häufig angefasst werden. Dazu wird der Klick auf einen Link in einer Datenbank gezählt (eben in der Tabelle serendipity_exits). Nun hat diese einen Primary Key, also eine Sammlung von Spalten, die zusammen jeweils den eindeutigen Schlüssel eines Eintrags ergeben. Für diese Datei ist das bisher das Tupel (day, host, entry_id). Eindeutig identifiziert ist ein Link also dann, wenn man Tag, Zielrechner und Quelleintrag im Blog des Links kennt. Der geneigte Leser wird hier evtl. schon einen Fehler finden: was passiert eigentlich, wenn zwei verschiedene externe Links in einem Artikel auf einem Host liegen und am selben Tag geklickt werden? Richtig, Serendipity versucht, beide einzutragen, da sich der path (also der Teil nach dem Host) unterscheidet und fällt damit natürlich prompt auf die Nase, weil der Primärschlüssel nicht zweimal vergeben werden kann.
Ursache des Fehlers ist hier eine unterschiedliche Auffassung der Datei exits.php und der Datenbank über den Begriff der Eindeutigkeit eines Eintrags. Die Auffassung der Datenbank ist fehlerhaft, denn zu einem Link gehört nicht nur der Host, sondern auch der Pfad (erst dann hat man ja das konkrete Dokument). Ergo gilt es, der Datenbank das passende Verfahren beizubringen.
Dazu verwirft man ersteinmal den bisherigen Primary Key, da man den nicht ändern und auch keine zwei definieren kann. Man verbindet sich zu seiner Serendipity-Datenbank und gibt folgendes ein:
ALTER TABLE serendipity_exits DROP CONSTRAINT "serendipity_exits_pkey";
Danach funktioniert das ganze zwar theoretisch wieder, läßt aber zuviel Raum für fehlerhafte Doppeleintragungen. Ergo schränkt man das ganze wieder ein, indem man einen neuen Primärschlüssel anlegt:
ALTER TABLE serendipity_exits ADD PRIMARY KEY (entry_id,day,host,path);
Das ganze kann im laufenden System passieren und zerstört keine Daten. Es ist natürlich immer besser, man hat ein Backup rumliegen (sollte man ja aber sowieso). Nach dem Fix können in einem Artikel wieder ohne Probleme Links verwendet werden, die auf denselben Host zeigen, ohne daß die Nutzer dadurch immer nur auf einen klicken können und alle anderen Fehler liefern.
Den Fehler einschließlich Fix habe ich gestern bei den Serendipity-Entwicklern eingeliefert und bereits eine Antwort von Garvin Hicking. Die nächste Version der Software wird diesen Fehler korrigieren. Bis dahin kann man den vorgeschlagenen Fix von Hand einspielen.
Silicon Graphics, Inc. beantragt Gläubigerschutz nach Chapter 11 des US-Handelsrechts. Auch wenn sie's als geplanten Schritt zur Schuldenreduzierung darstellen, dürfte es wohl wirklich langsam Zeit für den Nachruf sein. Schade eigentlich, ihr habt nette Maschinchen gebaut. Da fällt mir ein: ich könnte ja mal wieder einen Blick nach meiner Octane werfen.
Vor vielen, vielen Jahren (1984 um genau zu sein) veröffentlichte Ken Thompson eine Dankesrede für den Turing Award. Dieses Paper mit dem Titel "Reflections on Trusting Trust" sollte als eins der grundlegenden Paper in die Geschichte der Computersicherheit eingehen (genau genommen beschreibt das Paper lediglich die Arbeit von Paul Karger und Roger Schell, die die vorgestellte Attacke bereits 1974 formuliert hatten). Thompson beschreibt darin ein Dilemma, dem die Analyse eine sicheren Systems unterliegt: Mensch und Maschine verstehen unterschiedliche Sprachen. Der Quelltext eines Programms, welcher vom Menschen zu lesen ist, wird von der Maschine nicht verstanden. Diese versteht lediglich einen Binärcode, den wiederum der Mensch nicht (bzw. nahezu nicht) lesen kann. Die Übertragung von Quell- in Maschinencode geschieht durch Compiler.
Thompsons Idee basiert nun auf dem Problem des Bootstrappings: irgendwann muss der Prozess des kompilierens mal gestartet werden. Es muss also mal ein erster Compiler existieren, der diesen ersten Vorgang vornimmt. Dieser muss wiederum in Maschinencode vorliegen, denn sonst könnte ihn die Maschine nicht ausführen. An dieser Stelle setzt Thompson an und formuliert die Idee eine "bösen" Compilers, welcher bei der Übertragung vom Quell- in den Maschinencode die entstehende Software infiziert (mit einer Hintertür oder was auch immer). Diese ist so ausgelegt, daß sie, wenn der Compiler sich selbst übersetzen muss, dazu führt, daß die Routine zur Erzeugung der Hintertür wieder in den Compiler eingebaut wird (für genauere Ausführungen schaue man einfach in das Paper). An dieser Stelle hat man bei der Analyse eines sicheren Systems nun ein Problem: entweder man vertraut diesem ersten Compiler und kann dann (theoretisch) allen weiteren Quellcode analysieren um so sicherzustellen, daß das System keine Hintertüren hat oder man kann ihn nicht verwenden (der paranoide Ansatz lautet dann hier: man kann keinen verwenden, denn es könnte ja jeder eine Lücke haben). Sicherheit, die auf Analyse basieren will, hat mit Vertrauen so ihre Schwierigkeiten. Das Problem des "bösen" Compilers blieb lange ungelöst. Bis jetzt...
Im Dezember 2005 veröffentlichte David A. Wheeler "Countering Trusting Trust through Diverse Double-Compiling", ein Paper, welches die Lösung des beschriebenen Problems darstellt. Schaut man sich an, wie trivial diese Lösung ist, so kann man nur den Kopf schütteln, das man nicht früher drauf gekommen ist. Die Idee ist folgende:
Nehmen wir an, wir haben zwei Compiler (als Binaries) A und B und den Quellcode Sa von A. Wir kompilieren nun Sa sowohl mit A, als auch mit B und erhalten Ca und Cb. Diese beiden Binaries dürften unterschiedlich sein, da sie mit verschiedenen Compilern erzeugt wurden. Durch unterschiedliche Optimierungsstrategien etc. können sie sich auf Byteebene unterscheiden. Sie sind allerdings funktional äquivalent, will heißen: sie tun exakt dasselbe (zumindest sollten sie das). Nun kompilieren wir Sa nochmal mit Ca und mit Cb. Hieraus resultieren dann die Binaries Ea und Eb. Da Ca und Cb funktional absolut identisch sein sollten, sollten auch Ea und Eb bitgenau gleich sein. Sind sie es nicht, so ist entweder A oder B nicht vertrauenswürdig und muss verworfen werden. Ersetzt man B nun durch einen vertrauenswürdigen Compiler T, so kann man prüfen, ob A vertrauenswürdig ist. Der vertrauenswürdige Compiler wird in diesem Modell lediglich verwendet, um Sa zu übersetzen. Es ist vollkommen egal, wie langsam der ist und ob der irgendwelche Optimierungen etc. beherrscht. Er kann also so einfach, wie möglich gebaut werden, im Extremfall direkt in Maschinensprache. Man hat auf diese Art und Weise das Problem aus dem Ursprungspaper gelöst: es besteht wieder ein direkter Zusammenhang zwischen dem vom Quellcode beschriebenen Verhalten und dem ausgeführten Code auf dem Prozessor. Für einen Menschen ist die Analyse des Quellcodes unendlich viel einfacher, als die des Maschinencodes. Über 30 Jahre nach der Formulierung des ursprünglichen Problems gibt es nun eine Lösung und diese ist auch noch so einfach und leicht nachvollziehbar. Meinen Respekt, Mr. Wheeler...
Nachdem btk heute über ein nettes Tool namens Multiplicity einen Artikel
geschrieben hat und darin Synergy erwähnt hat, wurde bei mir mal wieder der Spieltrieb geweckt.
Erstmal vornweg zur Erklärung: Sowohl Synergy, als auch Multiplicity sind Tools um mehrere Maschinen zu einer Art virtuellen Monitor zu verbinden. Dabei werden mehrere grafische Oberflächen mit einer Maus und einer Tastatur gesteuert. Verläßt man den Bildschirm der einen Maschine mit dem Mauszeiger, so taucht er auf der anderen Maschine wieder auf und man kann dort tippen. Das ganze funktioniert ohne merkbare Verzögerung. Zusätzlich werden auch noch die Zwischenablagen der einzelnen Maschinen synchronisiert.
Da Multiplicity ein Tool für Windows und MacOS ist, kam ein Test für mich leider nicht in Frage. Ich nenne nunmal nur eine einzige Windowsmaschine mein eigen und die ist auch noch emuliert. Also habe ich mir Synergy mal etwas näher angeschaut. Laut Webseite läuft das Tool unter Windows, Unix und MacOS X.
Mein Testsetup:
namenlos-mobil (mein Laptop) als Server
namenlos (mein Serverchen) als Client
Auf beiden Maschinen läuft ein Debian unstable, verbunden sind sie mit 100 MBit/s Ethernet. Glücklicherweise ist Synergy als Paket im Debian-Tree vorhanden, so daß sich eine Installation auf apt-get install synergy beschränkt. Die Konfiguration des Systems findet auf dem Server statt. Dazu legt man dort eine Datei an, in der man beschreibt, wie die Bildschirme zueinander angeordnet sind. Das ist immer in beide Richtungen notwendig. Wenn man also beschrieben hat, daß Bildschirm1 links von Bildschirm2 ist, dann muss man auch noch beschreiben, daß Bildschirm2 rechts von Bildschirm1 ist. Tut man das nicht (was durchaus Absicht sein könnte), dann kann der Mauszeiger zwar von Bildschirm1 zu Bildschirm2 wandern, aber nicht zurück. Bei mir sieht die Konfigurationsdatei wie folgt aus:
section: screens
namenlos:
namenlos-mobil:
end
section: links
namenlos:
right = namenlos-mobil
namenlos-mobil:
left = namenlos
end
Im Grunde genommen nahezu selbsterklärend. Es existieren zwei Bildschirme: namenlos und namenlos-mobil. Diese sind so angeordnet, daß sich namenlos links von namenlos-mobil befinded (so, wie das tatsächlich auf meinem Schreibtisch ist). Wie bereits erklärt muss auch die Gegenrichtung angegeben werden. Damit ist dann aber der Konfigurationsaufwand schon beendet. Man startet den Server nun mit synergys -f --config syn.conf. Dieser lauscht nun auf Port 24800 auf die Anfragen von irgendwelchen Clients. (Hinweis: der Server muss unter X gestartet werden, damit er sich an den X-Server anhängen kann. Logisch, wo sollte sonst die Maus etc. herkommen?)
Synergy selbst bringt keinerlei Sicherheitsfunktionen wie Nutzerauthentisierung oder Verschlüsselung mit. Damit nun nicht jeder meine Tastendrücke und ähnliches im Netz mitlesen kann (namenlos und namenlos-mobil sind über ein öffentliches Netz verbunden) muss da also noch getunnelt werden. Glücklicherweise benutzt Synergy nur eine einzige TCP-Verbindung. Das perfekte "Opfer" für einen SSH-Tunnel also. Von namenlos aus habe ich mittles ssh -L 24800:localhost:24800 namenlos@namenlos-mobil den entsprechenden Tunnel aufgesetzt. Nun werden alle Verbindungen, die auf namenlos an Port 24800 gehen auf denselben Port auf namenlos-mobil weitergeleitet. Auf dem Client wird nun (unter X) das Clientprogramm gestartet und mit dem Server verbunden. Da der Tunnel auf localhost:24800 endet, ist das auch der Server. Der Befehl lautet also synergyc -f localhost. Sowohl Server als auch Client werden nun ein paar Ausgaben machen und dann melden, daß alles erfolgreich geklappt hat. Wenn ich jetzt den Mauszeige auf namenlos-mobil über den linken Bildschirmrand hinaus bewege, dann taucht er auf namenlos wieder auf und ich kann auch dort Tasteneingaben machen. Beispielsweise schreibe ich diesen Text gerade auf der Tastatur von namenlos-mobil in ein Fenster auf namenlos. Ziemlich brauchbar, das ganze.
Leider ist da, wo Licht ist auch etwas Schatten. Der Versuch, ein Bild von einer Gimp-Session auf namenlos in eine Session auf namenlos-mobil zu kopieren scheitert leider. Hier macht sich das fehlen einer standardisierten Schnittstelle für Bilddaten unter X11 bemerkbar. Texte lassen sich wunderbar zwischen den einzelnen Maschinen hin- und herkopieren. Bspw. habe ich die gesamte URLs in dem Text aus dem auf namenlos-mobil laufenden Browser kopiert und in den auf namenlos laufenden eingefügt. Wenn das mit Bildern jetzt auch noch so ginge....
Fazit: einfach geil. Ich frage mich jetzt schon, wieso ich hier eigentlich immer so eine klobige Tastatur stehen hatte. Zumindest solange mein Schreibtisch derart begrenzt Platz bietet ist Synergy eine perfekte Lösung, die ich schon viel früher hätte entdecken sollen.
Ich muss sagen, von dem Algorithmus, der hier präsentiert wird bin ich ernsthaft begeistert. Das Paper nennt sich "Colorization Using Optimization" und der präsentierte Algorithmus schafft es, mit minimaler Unterstützung durch den Nutzer Schwarzweissbilder (oder sogar ganze Filmsequenzen) realistisch einzufärben. Auch das Umfärben bestimmter Objekte in einem Bild stellt kein Problem dar. Die Beispielbilder auf der Webseite sind absolut beeindruckend. Leider gibt es bisher nur eine Demoimplementierung in Matlab, die ich nicht verstehe. Sehr schade, ich würde das gern mal benutzen.
dasBlog ist eine in C# geschriebene Blog-Software, die Kollege btk verwendet. Leider hat diese einen etwas nervigen Bug in der Trackback Autodiscovery Funktion. Leider setzt die immer einen Trackback, wenn sie eine entsprechende URI in einer verlinkten Seite finden, auch wenn (entgegen der Spezifikation) dessen dc:identifier gar nicht zur Ziel-URL passt. Da btk mich hin und wieder verlinkt und ich dann immer die Trackbacks löschen muss, hab ich mal nen Fix geschrieben. Glücklicherweise findet man sich im Quellcode von dasBlog einigermaßen gut zurecht.
Raymond Chen, einer der Entwickler aus dem Windowsteam bei MS hat ein Blog mit teilweise recht interessanten Einblicken in die Geschichte der Windowsentwicklung und die Hintergründe hinter bestimmten Designentscheidungen. Recht lesenswert.
