Gerüchteweise hatte ich ja schonmal davon gehört, dass man seit Lucid Lynx ohne lange Installations- und Konfigurationsorgien auf die Musik und die Fotos des iPhone zugreifen können soll. Merkwürdigerweise ging das bei mir nie so richtig. Jedes Mal, wenn ich das iPhone einsteckte, passierte überhaupt nichts. Ich zweifelte schon an den Fähigkeiten meines (nicht-gejailbreakten nicht-jailgebreakten ach egal) iPhones, als ich über die viel zu einfache Lösung stolperte:

Das iPhone muss beim ersten Einstecken entsperrt sein (Alternativ kann man das ausgeschaltete iPhone auch bei eingestecktem Kabel einschalten, aber das ist eine andere Geschichte). Beachtet man diese kleine Randbedingung, taucht das iPhone ordentlich auf und man kann auf die Medien des iPhones einfach zugreifen. Leider fehlt mir noch eine Möglichkeit, direkt das Adressbuch meines favorisierten Mailclients Thunderbird mit dem iPhone zu synchronisieren.

Und da ich seit gestern auch im Besitz eines iPads bin (jaja, ich weiß, Schande über mein Haupt), konnte ich es mir nicht verkneifen, auch dieses Gerät mal mit Lucid zu verbinden. Und siehe da, auch das iPad wird ordentlich erkannt und man kann bequem und ohne Umstände auf die auf dem iPad gespeicherten Medien zugreifen. Jetzt fehlt neben der Synchronisation von Kontakten und Terminen nur noch ein Programm für Backup und Wiederherstellung des iPad/iPhone.

Ursache des fehlenden Akkus ist dieser Bug. Zum Glück lässt er sich einfach beheben. Man öffnet einen Editor und bearbeitet die Datei /etc/modules. Dort fügt man in einer neuen Zeile das Wort pmu_battery hinzu. Das sorgt dafür, dass beim nächsten Start das Modul pmu_battery mitgeladen wird und der GNOME Power Manager bzw. DeviceKit den Akku wieder wahrnehmen.

Nun sind wir in der Außenstelle nicht alleine und es gibt eine Menge Störfaktoren (andere WLANs) um uns herum. Konkret äußert sich das darin, dass die Verbindung in unregelmäßigen Abständen zusammenbricht und erst nach ein paar Minuten wiederhergestellt werden kann. Selbst die sorgfältige Kanalwahl mildert die Verbindungsabbrüche nicht.

Weitere Recherchen führen schließlich zu einem mysteriösem Wert in den erweiterten WLAN-Einstellungen des Routers namens Beacon Interval. Dieser regelt die Zeitabstände, in denen der Router versucht, die Clients zu synchronisieren. Eine Verkleinerung des werksseitig auf 100ms eingestellten Werts soll angeblich die Stabilität der Verbindung positiv beeinflussen. Interessanterweise ist hier genau das Gegenteil der Fall: Eine Verlängerung des Werts auf 500ms resultiert in einer stabileren Verbindung, während ein Verkürzung dazu führt, dass die Verbindung noch öfter abbricht. Zum Glück muss ich das nicht verstehen…

sudo modprobe ide-scsi

auf einer zweiten Konsole geladen werden, bevor man mit der Installation weitermachen kann. In neueren Versionen sollte der Fehler nicht mehr auftauchen. Mehr Informationen zu dem Bug liefert dieser Thread im englischsprachigen Ubuntu-Forum.

Doch welches Betriebssystem darf es denn sein? Das aktuelle Mac OS X lässt sich zwar mit einigen Tricks klaglos installieren, ist aber für den Gebrauch im Alltag dann doch etwas zu träge. Nach einigen Versuchen mit Fedora, die ich ziemlich schnell wieder eingestellt habe (ich bin einfach nicht für RPM-Distributionen gemacht), bin ich schlussendlich wieder bei Ubuntu gelandet. Da Intrepid in meinen Augen nicht der große Wurf ist, Hardy auf der anderen Seite dann aber doch etwas veraltet für eine Spielwiese ist, habe ich mich dafür entschieden, auf den momentanen Entwicklungszweig Jaunty zu setzen. Normalerweise teste ich ja die aktuelle Entwicklungsversion nie vor Erscheinen der Beta, aber in diesem Fall erschien mir der Umstieg so reizvoll (und das Risiko vergleichbar gering), dass ich es einfach gemacht habe. Ich würde es dennoch keinem mit gutem Gewissen empfehlen, bereits jetzt auf Jaunty umzusteigen, erst recht nicht auf einem Produktivsystem und/oder ohne solide Linuxkenntnisse.

Der PowerPC-Zweig ist ja bekanntlich von Canonical seit einiger Zeit nicht mehr unterstützt. Umso erstaunlicher ist es, dass es für Jaunty wieder tagesaktuelle funktionierende Live-CDs zum Testen gibt. Diese lässt sich allerdings nur mit dem Bootparameter video=ofonly zu einer grafischen Oberfläche bewegen, während nach der Installation der Parameter nicht mehr benötigt wird. Die Installation läuft flüssig und ohne bemerkenswerte Vorkommnisse ab, die grundlegende Hardware wird gut unterstützt.

Nach der Installation zeigt sich trotz des Alphastatus bereits ein sehr rundes Bild von Jaunty. Für die WLAN-Karte »Airport Extreme« mit dem BCM 4306-Chip muss lediglich das Paket b43-fwcutter installiert werden, der Rest passiert automatisch. Die WPA-Passphrase kann jetzt sogar richtig eingegeben und muss nicht mehr hex-kodiert werden (ja, man darf sich auch über Kleinigkeiten freuen). Die Desktop-Effekte funktionieren leider nicht, was ein verschmerzbarer Verlust ist, da Metacity auch grundlegende Compositing-Eigenschaften hat, so dass man z.B. auf Docky oder Transparenzen nicht verzichten muss. Das neue USplash-Bootlogo und der Loginscreen gefallen mir ebenfalls sehr gut (wobei ich auch schon negative Meinungen dazu gehört habe).

Begeistert bin ich von der automatischen Anpassung der Schrifteinstellungen an das Display, endlich fällt das manuelle Umstellen nach der Installation weg. Lediglich die Schriftgröße muss ich noch von Hand anpassen, da ich bis jetzt noch keine Mehrheit hinter der Schriftgröße 8 als Standardeinstellung versammeln konnte (ok, ich habe auch noch nicht versucht, eine Mehrheit zu finden). Die Notifications halte ich jetzt dagegen nicht für die Rieseninnovation, eher für eine nette Ergänzung.

Einmal musste ich bis jetzt manuell in eine Textdatei greifen. In Ermangelung einer zweiten Maustaste muss man zur Aktivierung der rechten Maustaste mit Apfel-Klick in der Datei /etc/default/mouseemu diese Zeile hinzufügen:

RIGHT_CLICK="-right 125 272"

Den Recovery Modus habe ich auch bereits einmal gebrauchen müssen, da mir ein Update während der Durchführung eingefroren ist und die grafische Oberfläche anschließend nicht mehr richtig startete. Schön ist, dass es im Recovery Modus jetzt ein Auswahlmenü gibt, das eine Rootkonsole mit aktiviertem Netzwerk zur Verfügung stellen kann. Das reduziert den Aufwand einer Reparatur nach Updatefehlern doch erheblich.

Bis jetzt habe ich noch keine Funktion vermisst, die nicht unterstützt wurde. Suspend-to-RAM (Standby) funktioniert einwandfrei – auch über längere Zeiträume (mehr als 8 Stunden) – und die von mir verwendeten Programme sind ebenfalls alle da und funktionieren mit den Profilen, die aus einem Backup des Macbook Pro wiederhergestellt wurden. Wenn ich das mit der Einrichtung von Feisty damals vergleiche, liegen da Welten dazwischen. Ich glaube, Jaunty wird ein richtig gutes Release.

Arbeiten ist so leider nicht wirklich möglich. Das Problem tritt nur auf, wenn Compiz aktiviert ist und scheint unabhängig von der Treiberversion. In allen Nvidia-Paketen, die in den Ubuntu-Paketquellen zu finden sind, tritt das Problem auf, selbst mit dem nvidia-glx-180, der sich in den ubuntu-updates befindet. Auch der manuell installierte Betatreiber 180.27 macht das Ganze nicht besser. Man kann den Fehler übrigens leicht provozieren, indem man schnell zwischen zwei Arbeitsflächen hin und her wechselt.

Begleitet wird das Puzzlespiel von vielen Fehlermeldungen der Sorte

NVRM: Xid (0001:00): 13, 0003 00000000 00008297 00001b0c 10007010 00000003

in /var/log/syslog sowie

(II) NVIDIA(0): Initialized GPU GART.

in /var/log/Xorg.0.log.

Mich würde echt mal interessieren, ob ich der Einzige mit dem Phänomen bin?

NetworkManager: <debug> [1230290614.592207] periodic_update(): Roamed from BSSID (SSID meines WLANs) to (none) ((none))
NetworkManager: <debug> [1230290620.592461] periodic_update(): Roamed from BSSID (none) ((none)) to (SSID meines WLANs)

Da ein Wechsel auf den alternativen Netzwerk-Manager wicd das Phänomen gemindert, aber nicht beseitigen konnte, lag der Verdacht nahe, dass das Verhalten nicht am Manager, sondern am verwendeten Treiber ath9k liegt. Der zugehörige Launchpad-Bug scheint diesen Verdacht zu bestätigen.

Der aktuelle Entwicklungsstand des Treibers scheint den Bug gemildert zu haben, zumindest treten nach der Installation keine Abbrüche mehr auf, wenn auch die Verbindung manchmal ziemlich langsam wird. Wer es mal selbst probieren will, das täglich aktualisierte Treiberpaket ist bei Linux Wireless erhältich. Dort findet man auch detaillierte Informationen zum Installationsprozess.

Man erstellt sich also eine Datei /etc/hal/fdi/policy/appletouch.fdi und befüllt sie mit den gewünschten Optionen. Nicht vergessen darf man, eine bereits vorhandene Konfiguration in der xorg.conf zu entfernen oder zumindest auszukommentieren. Und so sieht das Meisterwerk bei mir dann aus:

<?xml version="1.0" encoding="ISO-8859-1"?>
<deviceinfo version="0.2">
<device>
<match key="info.capabilities" contains="input.touchpad">
<match key="info.product" contains="appletouch">
<merge key="input.x11_driver" type="string">synaptics</merge>
<merge key="input.x11_options.SHMConfig" type="string">true</merge>
<merge key="input.x11_options.TopEdge" type="string">0</merge>
<merge key="input.x11_options.LeftEdge" type="string">0</merge>
<merge key="input.x11_options.RightEdge" type="string">1100</merge>
<merge key="input.x11_options.BottomEdge" type="string">800</merge>
<merge key="input.x11_options.FingerLow" type="string">15</merge>
<merge key="input.x11_options.FingerHigh" type="string">25</merge>
<merge key="input.x11_options.TapButton1" type="string">1</merge>
<merge key="input.x11_options.TapButton2" type="string">3</merge>
<merge key="input.x11_options.TapButton3" type="string">2</merge>
<merge key="input.x11_options.ClickFinger1" type="string">1</merge>
<merge key="input.x11_options.ClickFinger2" type="string">3</merge>
<merge key="input.x11_options.ClickFinger3" type="string">2</merge>
<merge key="input.x11_options.VertEdgeScroll" type="string">0</merge>
<merge key="input.x11_options.HorizEdgeScroll" type="string">0</merge>
<merge key="input.x11_options.VertTwoFingerScroll" type="string">1</merge>
<merge key="input.x11_options.MinSpeed" type="string">0.5</merge>
<merge key="input.x11_options.MaxSpeed" type="string">2.5</merge>
<merge key="input.x11_options.AccelFactor" type="string">0.3</merge>
</match>
</match>
</device>
</deviceinfo>

Ein nicht unwesentlicher Vorteil dieser Methode ist, dass man Konfigurationsänderungen vornehmen kann, ohne den XServer neu starten zu müssen. Ein Neustart von HAL genügt normalerweise schon.

sudo /etc/init.d/hal restart

Es kann allerdings vorkommen, dass zusätzlich anschließend auch noch der Touchpad-Treiber neu geladen werden muss, was allerdings schnell passiert ist.

sudo modprobe -r appletouch && sudo modprobe appletouch

Die Multitouch-Touchpads neuerer Macbooks werden vom bcm5974-Treiber versorgt. Dementsprechend ist bei diesen Exemplaren in der obigen Konfiguration appletouch durch bcm5974 zu ersetzen.

Damit nicht genug, das Dateisystem wird zeitgleich auf readonly geschaltet, so dass so gut wie nichts mehr machbar ist. Das Ganze ist im Bug #267089 dokumentiert und tritt anscheinend nur auf, wenn das Macbook Pro einen RAM-Ausbau von 4 GB hat. Hoffentlich gibt es da bald einen Ausweg, bevor ich noch Entzugserscheinungen bekomme…

Wie zu erwarten war, läuft der Stick nicht out-of-the-box. Nach dem Einstecken meldet sich der Stick als »ZeroCD«-Wechseldatenträger, der den Windows-Treiber installieren möchte. Verständlicherweise bringt das unter Ubuntu nicht wirklich viel. Leider gibt es noch keine integrierten Bordmittel, um den Stick in den richtigen Modus zu versetzen, sodass man bereits hier die offiziellen Paketquellen verlassen muss. USB_ModeSwitch ist für diesen Zweck wohl das beliebteste Tool. Daneben gibt es noch REZERO und ozercdoff. Da ich ungerne Software außerhalb der Paketverwaltung installiere, habe ich mich für REZERO entschieden. Martijn van de Streek bietet in seinem PPA Intrepid-Pakete für REZERO an, sodass die erste Hürde der Installation schnell genommen ist. Paketquelle hinzufügen, Paket installieren, Paketquelle entfernen, fertig. Die Änderung zeigt dann auch sofort Auswirkungen. Wird der Stick eingesteckt, wird er zwar noch kurz als Datenträger erkannt, aber anschließend in den richtigen Modus versetzt, so dass der (für das Modem zuständige) HSO-Treiber übernehmen kann.

Eine gute Nachricht ist, dass der HSO-Treiber bereits in Ubuntu integriert ist, so dass man sich ein manuelles Neukompilieren nach einem Kernel-Update sparen kann. Allerdings kann der Network-Manager anscheinend nichts mit dem Stick anfangen (Gegenbeweise sind herzlich willkommen). Auf der Suche nach Alternativen zum Verbinden bin ich schließlich auf HSOconnect gestoßen. Das Programm ist ebenfalls als DEB-Paket verfügbar, benötigt zudem HSOlink und funktioniert nach der Installation einwandfrei. Die Einstellungen der Verbindung habe ich auf diese Werte gesetzt:

• APN: internet.t-mobile
• Username: t-mobile
• Password: tm

Leider hat die Sache einen Haken: Einige Programme (z.B. der Firefox) erkennen nicht, dass man eine Internetverbindung hat und schalten in den Offline-Modus. Nach dem manuellen Umschalten in den Online-Modus ist aber auch dieses Problem gelöst und das mobile Surfen kann losgehen.