Vogels Perspektive

Gestern habe ich mein Notebook, ein IBM Thinkpad R50e, per WLAN (Intel Corporation PRO/Wireless 2200BG [Calexico2]) von Ubuntu 8.04 (hardy heron) auf Ubuntu 8.10 (intrepid ibex) aktualisiert. Leider fand der "unerschrockene Steinbock" nach dem Reboot die WLAN-Karte des Notebooks nicht mehr. Die Fehlermeldungen lauteten sinngemäß, dass die Hardware nicht gefunden werden konnte ("module not found" oder "device not ready").

Anscheinend wurde die benötigte Firmware für den neuen Kernel nicht kopiert, denn unter /lib/firmware/ gab es nur ein Verzeichnis 2.6.24-21-386 für den alten unter Ubuntu 8.04 eingesetzten Kernel. Nachdem ich den Inhalt dieses Verzeichnisses (tatsächlich genügt eine einzige Datei: ipw2200-bss.fw) in ein neu angelegtes Verzeichnis /lib/firmware/2.6.25-2-386 hineinkopiert und das Notebook neu gestartet hatte, funktionierte die WLAN-Verbindung wieder.

Nachtrag: Bei einer Neuinstallation von Ubuntu 8.10 auf demselben Rechner funktionierte der WLAN-Zugang auf Anhieb. Zur Neuinstallation hatte ich mich entschlossen, nachdem ich entdeckte, dass auch die Tonausgabe auf diesem Notebook nach dem Update nicht funktionierte.

Nachtrag 2: Auf http://tennessee.ubuntuforums.com/showthread.php?p=6085817 habe ich jetzt einen Lösungsvorschlag gefunden, der exakt das gleichzeitige Problem der fehlenden Tonausgabe und der fehlenden WiFi-Unterstützung behandelt. Hier genügte die Installation des Pakets "linux-restricted-modules", damit sowohl die Soundkarte als auch das Funknetzwerk wieder funktionierten.

Wer, wie ich, auf einem Rechner auch die als "proposed" gekennzeichneten Updates von Ubuntu Linux installiert, hat zwar seit kurzem schon die neue Firefox-Version 3.0.3, jedoch unter Umständen mit teilweise englischen Dialogtexten. Bis zur vollständigen Aktualisierung der Paketquellen lassen sich die Menüs in Firefox mit der folgenden Datei wieder auf deutsche Texte umstellen: http://releases.mozilla.org/pub/mozilla.org/firefox/releases/3.0.3/linux-i686/xpi/de.xpi
Grundsätzlich sollte man von "proposed"-Updates tunlichst absehen. Diese sind nicht dazu gedacht, übliche Heim- und Arbeitsplatzrechner mit der neuesten Software zu versorgen, sondern liefern eine Menge unreifes Zeugs aus, welches vor allem für jene interessant ist, die möglichst früh ihr Feedback zu neuen oder geänderten Funktionen an die Entwicklergemeinde liefern wollen und denen es nichts ausmacht, ihr System ab und zu neu aufzusetzen. Siehe dazu auch http://wiki.ubuntuusers.de/Paketquellen.

Zu Windowszeiten war ich ein großer Fan des Bildbetrachtungsprogramms IrfanView. Ein Feature, das ich besonders mochte, war die Möglichkeit, JPEG-Fotos um einen kurzen oder bis zu 64.000 Zeichen langen Kommentartext zu ergänzen, der direkt (und unsichtbar) in der Bilddatei gespeichert wurde und dadurch alle Kopier-, Verschiebe- und sonstigen Aufräumaktionen unbeschadet überlebte. Leider ist die Unterstützung des JPEG-Kommentarfeldes in den meisten Linux-Bildbetrachtern überhaupt nicht angesagt. Manche, wie gThumb, haben zwar eine Kommentarfunktion, speichern den Text aber separat und nicht in der Bilddatei, was die Funktion für mich wertlos macht.
Zum Glück gibt es in Nautilus die Möglichkeit, das Rechtsklickmenü um eigene Skripte zu erweitern, die einfach im Ordner ~/.gnome2/nautilus-scripts/ abgelegt werden. Jetzt kann ich meine Bildkommentare bequem im Texteditor bearbeiten. Alles was benötigt wird, befindet sich im Paket "libjpeg-progs". Darin sind zwei Konsolenprogramme namens "rdjpgcom" und "wrjpgcom" enthalten, die das JPEG-Kommentarfeld lesen und schreiben können. Nun muss nur noch im Skriptverzeichnis von Nautilus eine ausführbare Textdatei angelegt werden. Diese könnte beispielsweise "JPEG-Kommentar bearbeiten" heißen und folgenden Inhalt haben:

#!/bin/bash
rdjpgcom $1>$1_comment.txt
gedit $1_comment.txt
mv $1 $1_original.jpg
wrjpgcom -replace $1_original.jpg < $1_comment.txt > $1

Dieses Grundgerüst benötigt, um richtig benutzerfreundlich zu sein, noch ein paar Abfragen. So sollte das fertige Skript zum Beispiel testen, ob der von Nautilus übergebene Dateiname "$1" überhaupt zu einer JPEG-Datei gehört oder ob der Kommentar überhaupt geändert wurde. Hinterher aufzuräumen und die beiden zwischenzeitlich angelegten Dateien mit der Originalbilddatei und dem Kommentartext wieder zu löschen, wäre auch keine schlechte Idee. In der vorliegenden Form macht das Miniskript folgendes (in Nautilus sei, um nicht zu abstrakt zu werden, die Datei "bild.jpg" ausgewählt worden): Es liest den Kommentar aus "bild.jpg" und schreibt ihn in die Datei "bild.jpg_comment.txt". Diese wird im Texteditor bearbeitet, das Bild in die Datei "bild.jpg_original.jpg" gesichert, aus dieser wird der alte Kommentar entfernt und der Rest der JPEG-Datei zusammen mit dem neuen Kommentar wieder als "bild.jpg" gespeichert.

Die aktuelle Beta 2 von OpenOffice.org 3.0 verspricht ja einiges. Der PDF-Import, der Export hybrider PDF-Dateien und der Multiseitenzoom sind für mich genug Gründe, bereits jetzt schon ziemlich intensiv die neue Version zu nutzen. Beim Testen unter Windows fiel mir jedoch auf, dass das Programm die Dateitypen nicht registriert, sodass im Explorer angeklickte ODF-Dateien immer mit der parallel installierten OpenOffice-2- oder StarOffice-8-Version geöffnet werden oder, wenn sonst kein Programm zum Umgang mit ODF-Dateien installiert ist, mit irgendeinem anderen Programm. Aus irgendeinem Grund entwickelte auf einem Rechner der Adobe Reader eine seltsame Neigung, ODT-Dateien öffnen zu wollen. Laut Aussage der Entwickler ist das Absicht, da das Programm ja nur zu Testzwecken installiert werden soll und nicht zum produktiven Arbeiten. Trotzdem wäre es ja ganz schön, wenn das Anklicken von Dateien mit den entsprechenden Endungen (ODT, ODS, ODP, ODG, ...) auch das zu testende OpenOffice 3.0 startete.

Abhilfe schafft die Installation "zu Fuß" mittels eines zusätzlichen Parameters. Nach dem Auspacken der Installationsdateien muss man per "Eingabeaufforderung" in dem Verzeichnis, in das die Dateien ausgepackt wurden, folgendes eingeben:

setup.exe WRITE_REGISTRY=1

Das Installationsprogramm läuft dann normal durch und trägt die Betaversion als Standardanwendung für alle Open-Document-Dateitypen ein.

In der neuen GNU/Linux-Version Ubuntu 8.04 (Hardy Heron) weist der Gnome-Dateimanager Nautilus eine Eigenheit auf, die von einigen als Feature, von anderen als Bug angesehen wird: Das Datum einer Datei wird auf den Moment des Kopiervorgangs gesetzt, nicht auf das Entstehungsdatum der Ursprungsdatei. Es lassen sich mehrere Gründe konstruieren, warum das so sein soll, angefangen von "das haben wir schon immer so gemacht" (gemeint ist das Verhalten des Shell-Befehls "cp"), über "eine Kopie ist eine neue Datei, das soll man gefälligst auch sehen können" bis zu "Linux ist schließlich nicht Windows".

Ohne die Diskussion über Sinn und Unsinn dieses Verhaltens fortführen zu wollen (das kann, wer mag, hier tun), stand ich plötzlich vor dem Problem, einige hundert Digitalfotografien in diversen Ordnern zu haben, die ein völlig falsches Dateidatum aufwiesen. Für alle, denen ähnliches widerfahren ist: es gibt ein einfaches Programm, das das Dateidatum einer Fotografie wieder auf deren Aufnahmedatum zurücksetzen kann. Es heißt jhead, wurde von Matthias Wandel geschrieben und repariert das Datum aller Foto-Dateien eines Ordners mit einem einfachen Aufruf:

jhead -ft *.JPG

JHead gibt es für Linux, OS X und Windows. Unter Ubuntu Linux ist es Bestandteil des Universe-Repositorys und kann mittels Synaptic installiert werden. Ein großes Dankeschön an Matthias Wandel für sein tolles Programm!

Nachtrag (20. Juni 2008): Der Fehler ist behoben worden und die neue Version der dafür zuständigen GLib-Bibliothek - libglib2.0-0 in der Version 2.16.3-1ubuntu3 - wird in Kürze über die Aktualisierungsfunktion verfügbar sein.

Wer schon einmal komplette Festplatten mittels dd kopiert hat (siehe unten), fragte sich wahrscheinlich nach spätestens einer halben Stunde, ob das Programm wirklich was tut und wenn ja, wie lange noch. Das unkomplizierteste aller Backupprogramme zeigt leider weder Fortschrittsbalken noch andere Statusinformationen an. Man kann es aber dazu bringen, eine Meldung über die bereits kopierte Datenmenge, die verstrichene Zeit und den durchschnittlichen Datendurchsatz auszugeben. Dazu öffnet man ein zweites Terminalfenster und gibt dort folgendes ein:

sudo kill -SIGUSR1 $(pidof dd)

Um alle 10 Sekunden über den Verlauf der Datensicherung informiert zu werden, kann man den Aufruf auch in eine kleine Schleife packen:

while /bin/true; do sudo kill -SIGUSR1 $(pidof dd); sleep 10; done

Nun gibt dd solange Statusmeldungen aus, bis die Schleife mittels Strg-C abgebrochen wird.

Nachtrag (24. Mai)
Den Referrern nach zu urteilen, schickt Google mir gerade etliche Anwenderinnen und Anwender, die wissen möchten, wie man komplette Festplatten unter Linux kopiert. Das ist ganz einfach. Angenommen, die vorhandene Festplatte, die kopiert werden soll, heiße /dev/sda und die Platte, auf die kopiert werden soll, sei /dev/sdg, so lautet der Kopierbefehl schlicht:

sudo dd if=/dev/sda of=/dev/sdg

Die Namen der Festplatten bekommt man beispielsweise mittels

sudo fdisk -l

heraus.

Beim Kopieren muss unbedingt darauf geachtet werden, dass die neue Festplatte mindestens so groß ist wie die alte. Und, ganz wichtig: dd fragt nicht "sind Sie sicher?" - es fängt einfach an zu kopieren. Wer sich mit der Angabe der Zielfestplatte vertut, ruiniert innerhalb von Sekunden sämtliche Daten, die dort gespeichert sind.

Eine nette Überraschung lieferte mir heute die Synaptic-Paketverwaltung, als ich in der frisch installierten neuen Ubuntu-Version 8.04 nach True-Type-Fonts suchte. Völlig unerwartet für mich wurde mein Symbolfont Marvosym.ttf in den Softwarekatalog der freien Betriebssystemdistribution aufgenommen. Ein Dankeschön an die ETH Zürich!

Marvosym gibt es für Windows und Linux.
Zur Marvosym-Website

Um Kartenausschnitte aus Google Maps in ein Blog einzubinden, gibt es drei Möglichkeiten, die bisher mehr oder weniger problematisch waren.

Am einfachsten und dümmsten ist das Anfertigen und Hochladen von Bildschirmkopien, was in der Vergangenheit bereits zu Abmahnungen in vierstelliger Höhe geführt hat, weil der feine Unterschied zwischen einer kopierten Grafikdatei und eingebundenen Serverdaten nicht beachtet wurde.

Die zweite Möglichkeit, zu der Google selbst einlädt, ist das Einbinden eines HTML-Code-Schnipsels, der – vereinfacht ausgedrückt – ein Fenster (Iframe) auf das Google-Maps-Angebot öffnet. Diese Methode ist jedoch auf nichtgewerbsmäßige Webauftritte beschränkt. Es gibt daher ein Problem, sobald der eigene Webauftritt durch Werbung unterstützt wird. Unabhängig davon, ob die Werbeeinnahmen aufs eigene Konto gehen oder in die Taschen eine "Gratis"-Hosters fließen, können solche Seiten als gewerbliche Webauftritte zählen.

Für all jene Webschaffenden, die nicht über vollkommen einnahmenfreie Seiten verfügen, hat Google eine Programmierschnittstelle entwickelt, das sogenannte Google Maps API. Dieses wird nicht nur für rechtlich unbedenklich gehalten (auch von mindestens einem Juristen) und ist deutlich vielseitiger in den Gestaltungs- und Interaktionsmöglichkeiten, sondern hier wird auch jedem Webmaster ein eindeutiger Schlüssel zugeordnet, sodass Google die volle Kontrolle über die Auslieferung oder Nichtauslieferung der Karteninhalte behält und bei zu intensiver Nutzung Ausgleichszahlungen aushandeln oder aber gezielt Inhalte sperren kann. Diese dritte Lösung wäre perfekt für Blogs geeignet, eröffnet aber wiederum das Problem, dass Javascriptcode sowohl in den unsichtbaren Kopf- als auch in den Inhaltsbereich der Seite eingefügt werden muss. Wer mit einer fertigen Blogsoftware arbeitet, möchte aber wahrscheinlich nur ungern Googles Javascriptdateien in die Vorlagendateien einbinden, damit nicht bei jedem Seitenaufruf erst einmal haufenweise fremder Code durch die Gegend geschoben werden muss, der zudem nur dann wirklich benötigt wird, wenn auf der jeweiligen Blogseite tatsächlich auch ein Kartenausschnitt dargestellt wird.

Für die von mir verwendete Blogsoftware (Serendipity) gibt es zwar ein fertiges Google-API-Plugin von Zoran Kovacevic, das erlaubt jedoch nur die Darstellung eines für alle Seiten gleichen Kartenausschnitts in der Seitenleiste. Das ist nett für Blogs, die sich mit einem geografisch eng begrenzten Gebiet befassen, ich fand es jedoch für meine Zwecke ungeeignet.

Um aus dieser Zwickmühle zu entkommen, kann man nun die Möglichkeiten, die Google mit der Nutzung des API anbietet, mit der Einfachheit, die das Iframe-Codeschnipsel der bekannten Google-Maps-Seite bietet, kombinieren. Man benötigt dazu nur eine einzige zusätzliche Datei im Startverzeichnis des Blogs, die den ganzen API-Code enthält.

Der folgende Code könnte beispielsweise unter dem Namen "map.php" auf dem Webserver des Blogs abgelegt werden:

<head>
<script
 src="http://maps.google.com/maps?file=api&amp;v=2&amp;key=LANGEKRYPTISCHEZEICHENFOLGE"
 type="text/javascript">
</script>
<script
 type="text/javascript">
 function initialize() {
 if (GBrowserIsCompatible()) {
  var map = new GMap2(document.getElementById("karte"));
  map.setCenter(new GLatLng(<?php echo $_GET['ll']; ?>), <?php echo $_GET['z']; ?>);
  map.setMapType(G_NORMAL_MAP);
  map.addControl(new GSmallZoomControl());
  }
 }
</script>
</head>
<body onload="initialize()" onunload="GUnload()">
<div id="karte" style="width: 100%; height: 100%"></div>
</body>


Im Blogeintrag selbst ist dann nur noch folgende Codezeile einzufügen:

<iframe width="400" height="300" src="map.php?ll=51.472973,7.472579&z=24"></iframe>

Die Koordinaten (ll=51.472973,7.472579) und den Zoomfaktor (z=24) kann man einfach aus Google Maps übernehmen. In diesem Fall sollten die Pinguine des Dortmunder Zoos erkennbar sein:



Hier zum Vergleich der entsprechende Ausschnitt bei Google Maps

Jetzt sollte man noch dafür sorgen, dass nicht jeder die Datei map.php in seinem eigenen Webauftritt einbinden kann. Auch dafür gibt es eine einfache Lösung – aber das ist eine andere Geschichte.

Wegen der unklaren und in meinen Augen widersprüchlichen Angaben zur Zulässigkeit von Luftbildern in der Anfangsdarstellung der Karten empfehle ich momentan, das Aktivieren der Satelliten- oder Hybriddarstellung dem Nutzer der Seite zu überlassen. Der Spiegel hat zwar am 29. Februar 2008 eine Aussage von Google-Sprecher Kay Oberbeck dazu veröffentlicht, ob die im Ernstfall rechtlichen Bestand hätte, weiß ich jedoch nicht zu sagen. Auf die Frage "Wer darf Karten und Luftbilder von Google Maps per API eingebettet zeigen?" erhielt Spiegel-Redakteur Konrad Lischka jedenfalls die eigentlich positive Antwort: "Die kostenfreie Google Maps API darf auf Seiten angezeigt werden, welche für jedermann frei zugänglich sind, unabhängig davon ob es sich dabei um gewerbliche oder nicht-gewerbliche Seiten handelt. Ansonsten wird eine kostenpflichtige Google Maps Enterprise Lizenz benötigt." Auch von der Firma GeoContent gibt es laut einem Kommentar in Robert Basics Blog inzwischen grünes Licht für die API-Verwendung.