Paket voller Kompromisse

Da Asus noch kein Testgerät liefern konnte, kaufte ich einen x101 auf mein Unternehmen. Die dahinterstehende Kalkulation war, dass selbst bei einem Weiterverkauf mit 25% Wertverlust kein allzu großer Schaden eintreten würde. Allerdings habe ich derzeit einen Eee PC 1015B mit Zweikern AMD zur Hand, der für Fotos herhalten muss und als Vergleichsobjekt hinsichtlich der Verarbeitungsqualität.

Was sofort auffällt ist die dünne Bauform und das relativ leichte Gewicht. Das Gewicht ist nicht nur dem Wegfall der Festplatte, sondern auch dem vergleichsweise kleinen Akku geschuldet, der mit drei Zellen und 28Wh rund vier Stunden durchhält. Das ist meiner Erfahrung nach ausreichend, da ich längere Zugfahrten meide und sogar auf der Argentinienreise der alte Eee PC 701 als elektronisches Reisetagebuch auf langen Busfahrten genug durchhielt.

Schaut man sich das x101 näher an, stellt man eine Reihe weiterer Kompromisse fest:

• Tastatur: Die F-Tastenreihe fehlt. Um überhaupt USB-Anschlüsse unterbringen zu können, mussten diese an den dicksten Teil des Gehäuses rutschen, der Platz reichte dort dennoch nicht für darüber angebrachte Tasten. Die F-Tasten wurden kurzerhand gespart und die Tiefe der Tasten reduziert. Auch der Hub fällt geringer aus, so lässt sich gerade noch flüssig tippen.

• Ethernet: Gibt es nicht, es musste schon beim 1015B in einer Klapplösung umgesetzt werden. Fürs Netz gibt es nur WLAN.

• VGA/HDMI: Gibt es nicht, es war schlichtweg kein Platz für den Port da.

• USB: Zwei Ports müssen genügen, USB 3.0 und eSATA fehlt.

• Kartenleser: Statt SD ist MicroSD eingebaut – der hat unter der Tastatur Platz.

• Audio In/Out: Es gibt nur einen kombinierten Port, beispielsweise zur Verwendung mit typischen Handy-Headsets.

Gut zu erkennen – die F-Tastenreihe wurde geopfert, ansonsten hätte kein USB-Port Platz gehabt:

Die Dicke im direkten Vergleich mit dem Eee PC 1015B – dieser sieht plötzlich klobig aus:

Software

Vorinstalliert ist MeeGo in Version 1.1. Die ist schon etwas älter und weist einige Lücken bei der Lokalisierung auf. Ich habe daher nach einer halben Stunde rumprobieren Ubuntu 11.04 (in der 32 Bit Variante) mit Unity als Desktop installiert. Auf MeeGo 1.2 werde ich an anderer Stelle eingehen, ich sehe ein recht großes Potential für viele typische Netbook-Nutzer.

Zurück zu Ubuntu: Dank für Desktopeffekte brauchbar umgesetzter Hardwarebeschleunigung des Intel GMA 3150 läuft Unity schonmal reibungslos. Sowohl Sound, WLAN als auch ACPI (Helligkeit, rfkill) funktionieren einwandfrei. Anwendungen sind merklich träger als bei einem Dual-Core Atom oder AMD C-Serie, aber noch absolut im Bereich des gut Nutzbaren. Meine Ubuntu-Installation umfasste eine Root-Partition mit vier Gigabyte, eine Home-Partition mit deren drei und ein GB Swap. Eine meiner Ansicht nach bessere Partitionierung mit /usr auf einem SquashFS-Container werde ich demnächst separat vorstellen.

Fazit

Die eingegangenen Kompromisse sind spürbar, aber nicht schmerzhaft. Die F-Tastenreihe dürfte einigen Powerusern fehlen, mir fiel die umständliche Zugänglichkeit der Textkonsole (Strg+Alt+Fn+2) oder des oft in regulären Ausdrücken benötigten “^” auf. Abgesehen davon ist die Tastatur um längen besser als bei den Neunzöllern von vor drei oder vier Jahren. Als mobiles Admin- und Präsentationstool eignet sich das x101 dagegen nur eingeschränkt: Muss man eine Präsentation halten, ist ein USB-VGA-Adapter nötig, der nicht immer einfach einzurichten ist. Gleiches gilt für die Netzwerkwartung, wo ich gerne mit einem TFTP-Bootserver auf dem Notebook herumlaufe, der aber einen Ethernetport erfordert – da werde ich wohl weiterhin Lenovos x100e mitnehmen (und dieses mittelfristig durch ein x121e ersetzen).

Im angepeilten Einsatzbereich – Social Media, Schreibmaschine für Unterwegs und Internet Client trifft Asus die Zielgruppe fast punktgenau und überzeugt hier mit dem leichten Gewicht und dem schnellen Start. Den günstigen Preis muss ich etwas relativieren, mittlerweile haben Speicherriegel (11€ für 2GB) und Micro-SDHC-Karte (20€ für 16GB) den Preis auf genau 200€ hochgetrieben – das liegt über dem eines besser ausgestatteten Acer Aspire One D525 mit fast doppelter Akkulaufzeit und 250GB Festplatte – aber eben 300 Gramm mehr und einem klobigeren Netzteil (188€ derzeit bei Media Markt Krefeld).

Einziges Ärgernis ist nur den Verzicht auf Bluetooth, weil eben noch nicht jeder ein Handy mit AP-Funktion hat und eben auch viele BT-Mäuse im Umlauf sind. Nach den ersten Tagen mit dem x101 kann ich jedenfalls ziemlich sicher sagen, dass ich wieder häufiger mit Netbook unterwegs sein werde und hoffe insgeheim, dass Asus den wiedergefundenen “wahren Netbook-Pfad” nicht verlässt und stattdessen vielleicht eine Luxus-Variante des x101 auflegt – wie wäre es mit einem Dual-Core Atom, zwei GB RAM, 32GB SSD und Bluetooth im gleichen Gehäuse mit gleicher oder möglicherweise etwas besserer Akkulaufzeit?

Ich bin dann so vorgegangen:

1. Beide Platten mit einem SATA2USB-Adapter an den Linux-Desktop-Rechner angeschlossen

2. Mit
   dd if=/dev/sdx of=/dev/sdy bs=1M
   die alte (sdx) auf die neue (sdy) Platte geklont

3. Mit
   gdisk /dev/sdy
   die Platte im GPT-Partitionierungstool geöffnet und eine Partition vom Typ 0700 auf dem Rest der Platte angelegt, mit w bestätigt – das korrigiert die Position der Backup-GPT

4. Die Platte abgestöpselt und in den Mac eingebaut

5. Den Mac gebootet und dort im Festplattendienstprogramm die leere Partition gelöscht und die OS X Partition etwas gestreckt

Klappte prima und erspart mir eine Neuinstallation von OS X. Ich habe jetzt noch Platz, um demnächst Ubuntu drauf unterzubringen.

• Wie stark suckt Flash? Es gibt eine Beta der 10.1 für Linux, Hardwarebeschleunigung inbegriffen, News bei LinuxForDevices.com.

  Ich konnte mich nie wirklich mit Flash unter Linux, BSD oder MacOS X anfreunden und werde es wahrscheinlich nie wirklich können. Auf meinem 64 Bit Desktop läuft Flash im Plugin-Wrapper und schmiert zweimal am Tag ab. Ich bin damit die meiste Zeit ohne Flash unterwegs und vermisse es nicht wirklich. Nur wenn ich gerade Flash für ein kleines Video brauche, ist es nicht da. Ich hoffe, dass HTML5-Video bald soweit verbreitet ist, dass man auch für die Freizeit kein Flash-Plugin mehr braucht.

• Endlich kostenlose Navigation auf dem Nokia E71 Nokia reagiert auf protestierende Nutzer: News bei engadget.com.

  Dass Nokia seine kostenlose Navigation beim Start nur für eine Hand voll Geräte anbot, fand ich ärgerlich. Sollte ich ein ein Jahr altes E71 wegwerfen und ein mir ein E72 kaufen, um in den Genuß der Navigationslösung zu kommen? Der Protest der letzten Monate hat gewirkt: Nokia bietet die kostenlose Ovi Maps Version 3.0.3 nun auch für E66 und E71.

• Mein YaCY-Host läuft wieder! Ich mache wieder bei der freien Suchmaschine mit und helfe, mich und andere von Google abzunabeln.

  Auf dem Büroserver läuft nun eine Xen-Instanz mit 1,25GB RAM und 30GB Platte. 25GB Plattenplatz und 1GB RAM darf sich Yacy nehmen, dafür habe ich die CPU-Zyklen etwas beschränkt und stelle nur einen Prozessorkern bereit. Cool: Wenn man die Proxy-Indexierungstiefe auf 1 setzt und hin und wieder doch zu Google greifen muss, indexiert Yacy die auf den gelesenen Google-Ergebnisseiten verlinkten Seiten.

  Nachtrag: Hier gibt es einen älteren Artikel von mir zu Einrichtung und Funktionsweise von YaCY.

• Xen 4.0 erschienen: Neue Version des Hypervisors, News bei Golem.

  Wenn ich die Nachricht richtig deute, läuft Kernel 2.6.31 dann mit pv_ops auf Xen (der Kernel erkennt, ob er auf Xen oder direkt auf der Hardware läuft), wenn ein Prozessor mit Intels oder AMDs Virtualisierungserweiterungen gefunden wird. Damit ist der Einsatz neuer Xen-Versionen auf vielen Maschinen die älter als zwei Jahre sind, in weite Ferne gerückt. Immerhin: Da pv_ops ein fester Bestandteil des Kernels ist/wird, hat das manuelle Patchen des dom0-Kernels bald ein Ende. Ich hoffe, dass Xen damit eine Zukunft im SMB-Bereich und nicht nur im Rechenzentrum hat, denn KVM hat mit PCI Passthrough u.ä. in letzter Zeit mächtig aufgeholt.

• Einsteiger-Smartphones von Nokia C3, C6 und E5, News bei Golem, News bei Engadget und News bei Infosync.

  Immer noch kein Symbian^3, stattdessen das neu gelabelte Symbian^1 (TOFKAS605TH = The OS Formerly Known As Series 60 5th Edition), nett und meine Erfahrungen mit E71 und 5230 zeigen, dass Nokia durchaus brauchbare Geräte mit langen Standby-Zeiten und schneller Navigation bauen kann, auch die Preise sind moderat und die Tastatur des E5 hoffentlich so gut wie beim E71, aaaaaber von einem Gerät wie dem C6 hätte ich langsam das neue Touchscreen-Symbian erwartet.

./ati-driver-installer-10-3-x86.x86_64.run

probierte ich erneut

aticonfig --initial

Das Ergebnis war ernüchternd: Wieder wurde mir gesagt, dass keine unterstützten Karten im Rechner vorhanden waren, eine Konfiguration daher nicht möglich sei. Zur Erinnerung: lspci erkennt die Karte wie folgt:

01:00.0 VGA compatible controller [0300]: ATI Technologies Inc Device [1002:68e0]

Doch heute packte mich ein wenig der Spieltrieb und ich probierte zunächst anhand einer minimalen xorg.conf, ob denn die Karte erkannt wird, wenn ich dem Treiber explizit mitteile, dass er für sie zuständig ist — das besorgt die Zeile ChipID. Über SSH loggte ich mich also am Notebook ein und baute die Konfigurationsdatei auf. Bereits mit einer Section “Screen” und einer Section “Device” erhielt ich ein Bild in der nativen Auflösung des Widescreen-Displays. Die minimale xorg.conf:

Section "Screen"
        Identifier      "Screen_AUTO_1366x768"
        Defaultdepth    24
        SubSection "Display"
             Modes "1366x768" "1024x768" "1024x600" "800x600"
        EndSubSection
EndSection

Section "Device"
        Identifier  "Card0"
        Driver      "fglrx"
        ChipId      0x68e0
        VendorName "ATI"
        BusId      "PCI:1:0:0"
EndSection

Die vollständige xorg.conf kann hier heruntergeladen werden. Die größte Änderung dürfte sein, dass ich Option "SWCursor" "true" aktiert habe, um nach einem Logout das Fehlen des Zeigers zu vermeiden. Wer diese xorg.conf als Basis für eigene Experimente verwendet, sollte wie ich sich per SSH einloggen, den gdm stoppen und dann remote versuchen, ob sich der Xserver starten lässt: Logdatei und Meldungen in der Konsole, in dem der Start durchgeführt werden, sind aussagekräftig – Oft muss ChipId oder BusId angepasst werden.

Fehlendes Kernelmodul

Leider lässt sich auf meinem 2.6.33.1 das fglrx-Kernelmodul nicht kompilieren. Nach dem Wechsel nach /lib/modules/fglrx/build_mod und Aufruf von ./make.sh mäkelt das Script zunächst über zwei fehlender Header. Nach dem softlinken dieser Header geht es aufgrund geänderter Funktionen auch nicht weiter. Ich werde dieses Problem irgendwann angehen, gebe mich zunächst mit weniger (gar keiner?) Beschleunigung zufrieden.

Nerviges Overlay “Unsupported Hardware”

Im rechten unteren Eck befindet sich ein Overlay “Unsupported Hardware”. Dieses lässt sich nur abschalten, indem man mit dem Hex-Editor an das Treiber-Binary herangeht. Der User “Crypto2600″ aus den Ubuntu-Foren hat hierfür ein kleines Script geschrieben, das den Vorgang automatisiert:

#!/bin/sh
DRIVER=/usr/lib/xorg/modules/drivers/fglrx_drv.so
for x in $(objdump -d $DRIVER|awk '/call/&&/EnableLogo/{print "\\x"$2"\\x"$3"\\x"$4"\\x"$5"\\x"$6
}'); do
echo found $x
sed -i "s/$x/\x90\x90\x90\x90\x90/g" $DRIVER
done 

Das Ende vom Lied?

Fürs erste läuft die Grafik zufriedenstellend. Das fehlende Kernelmodul rüste ich bei Gelegenheit nach — ich mutmaße einmal, dass die Buildscripte für Lucid bald gepatcht sind, so dass diese Änderung nicht mehr viel Arbeit bedarf. Und vielleicht supported Ati die 5470 ja irgendwann einmall ganz offiziell…

Nachtrag, 6. April 2010: “fglrx” hatte die Lösung. Umgesetzt habe ich sie, indem ich nach dem Download des Patches von http://aur.archlinux.org/packages/catalyst/catalyst/fglrx-2.6.33.patch und Anwenden desselben die Module unterhalb von /lib/modules gebaut habe. Quick and dirty gelang diese mit:

cd /lib/modules/fglrx
patch -p5 < /tmp/fglrx-2.6.33.patch
cd build_mod
./make.sh
cd ..
./make_install.sh

Anschließend lies sich das Modul wie erwartet laden und Hardwarebeschleunigung ist nun aktiv aktiv.

• LessLinux: Auch mit “meiner” eigenen, lose auf Linux From Scratch aufbauenden Live-Distribution LessLinux ging es in den letzten Wochen in vielen kleinen Schritten weiter. Mittlerweile wird viel Standard-Netzwerk-Hardware automatisch erkannt, WLAN kann mit WICD angesprochen werden, einige eigene Ruby-Gtk-Scripte sorgen für eine komfortable Installation auf USB-Stick oder die Erstellung von Containern mittels Cryptsetup.

  Jetzt kommt die Stelle, an der Ihr helfen könnt: Bitte ladet Euch den aktuellsten Build herunter und erstellt ein Hardware-Protokoll. Mit diesem Hardware-Protokoll (es enthält die Ausgaben von lspci, lsusb und lshw), habe ich es leichter, die Hardwareerkennung zu verbessern.

• Android: Das Handy-Linux kommt nun auch mit einem Native Development Kit, mit dem sich native Linux-Anwendungen erstellen lassen, die direkt auf dem Linux des Android und nicht auf der aufgesetzten Dalvik VM laufen. Insbesondere die Portierung von Emulatoren und einigen Spielen, die SDL verwenden, dürfte vom NDK profitieren.

  Unterdessen zeigt Android bereits erste Fragmentierungserscheinungen: HTC stellte auf dem eigenen Telefon eine erweiterte Oberfläche “Sense UI” vor, die leider nicht auf die Telefone mit Google Branding kommen soll. Mal gespannt, ob das Resultat bald drei verschiedene Adressbuch-APIs sind.

• SkyOS: Bei SkyOS handelte es sich bislang um proprietäres ein Ein-Mann-Betriebssystem. Ein C++-lastig implementiertes OS für 32-Bit-x86, das mit einer gut durchdachten Architektur glänzen kann. Als Problem stellte sich in den letzten Jahren jedoch die Treiber-Unterstützung heraus, zuletzt kam die Entwicklung fast zum Erliegen. Nun hat der Entwickler Robert Szeleney einen radikalen Schritt gewagt und SkyOS auf einen Linux-Kernel und ein minimales Linux-Userland gestellt. Die Vorgehensweise erinnert etwas an NeXTstep bzw. MacOS X. Auf jeden lohnt es sich, ein Auge auf die weitere Entwicklung zu werfen. Mehr im Blog von Robert Szeleney

• Netbooks: In den letzten Monaten hat sich hier wenig getan. Netbooks sind beinahe eine Commodity und unterscheiden sich nur noch im Preis. Die letzten Juli für 399 Euro verkauften Medion Akoya E1210 gibt es nun als B-Ware für 219 Euro. Da fällt es umso positiver auf, dass HP mit dem hübschen, wenn auch nicht ganz billigen HP 5101 zeigt, dass Alu und Magnesium im Understatement-Gehäuse noch ihre Berechtigung haben. Nachtrag, 30. Juni: Golem hat Details und Bilder der hierzulande verkauften Version mit UMTS.

Installiert habe ich Ubuntu 9.04 (Jaunty) Alpha 6, natürlich per Netinstall, schließlich wird der Broadcom Tigon bereits von der Installations-Initrd unterstützt. Handarbeit war bei der xorg.conf notwendig, da auch mit dem Openchrome-Treiber X dachte, das Panel habe 1366×768 Pixel Auflösung. Die xorg.conf reiche ich nach kann hier heruntergeladen werden. Auch Sound funktioniert einwandfrei, die Webcam habe ich noch nicht getestet ebenso.

Ärgerlich ist die WLAN-Karte Broadcom BCM4312

PCIID: 14e4:4315

die weder vom bc43-Treiber des Kernels erkannt wird, noch von dem von Ubuntu mitinstallierten wl.ko, noch von einem selbstgebauten wl.ko von Broadcoms Webseite. Auch mit Ndiswrapper kein Erfolg. Einmal konnte ich einige Sekunden lang pingen — nachdem ich direkt von Windows nach Linux mit wl.ko gebootet habe. Auf einem cleanen System (Akku raus und Stützkondensatoren leeren vor dem Anschalten) ging gar nix.

Ich bin am Überlegen, ob ich die 30 Euro in eine gescheite Mini-PCI(e)-WLAN-Karte investieren will, schrecke aber ein wenig davor zurück, das ganze HP2133 zu zerlegen, um an die unter dem Motherboard verbaute Karte heranzukommen. Sinnvoll wäre es vielleicht schon angesichts der auch unter XP schlechten Empfangsleistung.

Vielleicht hat jemand eine Idee, eine Version des STA-Treibers, die mit bestimmten Kernelversionen harmoniert (notfalls Vanilla 2.6.27 oder 2.6.29-RC) oder einen Treiber, der sich mit Ndiswrapper ohne Probleme verwenden lässt? Ansonsten werde ich wohl noch ein paar Tage auf WLAN verzichten (nicht wild, weil das Gerät eh im Außeneinsatz verwendet wird) und mich dann ans Zerlegen machen.

Update, 19. März: Gleiches Problem mit 2.6.27.20 und Broadcoms Binärtreiber (ja, die als Source veröffentliche Layer ist ziemlich dünn) 5.10.79.10: Beim Insmod bekomme ich in der Ausgabe von “dmesg” einen “Error 13″. To be continued, zunächst stehen andere Baustellen auf dem Programm.

Die Gegenstände im einzelnen:

• Ein Subnotebook Fujitsu-Siemens B142: Mit Touchscreen, 300MHz-Celeron und 160MB RAM, derzeit ist Ubuntu 7.10 installiert. So sahen Netbooks vor zehn Jahren aus — allerdings kosteten sie das fünf- bis achtfache. Dieses Gerät wurde in der Serie “Schrott flott” meines privaten Blogs bereits gefeaturet.

• Ein Psion Revo: Der Vorgänger aller modernen MIDs. Mit Infrarotschnittstelle und einem Opera basierten Browser konnte man damals tatsächlich surfen und mailen. Textverarbeitung und Tabellenkalkulation suchen heute auf PDAs noch ihresgleichen.

• Ein funktionierendes 100MB-ZIP-Laufwerk: Inclusive Diskette. Diese Dinger waren mit der Verfügbarkeit erschwinglicher CD+RW soetwas von out… Und das ist nun auch schon 13 oder 14 Jahre her.

• Ein Nokia 7110: Die WAP-Gurke mit Scrollrad. Elegant und auch heute noch ein Fashion-Statement.

• Ein Nokia 6021: Ehemals billiges Business-Phone ohne Kamera, mit Series 40 (?) und einfachem Mail-Client. Nimmt per Bluetooth Kontakt nach außen auf.

• Ein Nokia 3510i: Billiges Handy ohne Schnickschnack. Ich habe einmal nach einem “Schweissschaden” die Kontakte unter der Tastaturmatte mit dem Topfreiniger gereinigt, seither funktioniert es, liegt aber kaum genutzt in der Ecke.

• Eine NSLU2: Urvater aller Linux basierten NAS-Geräte, wer geduldig ist, kann Debian 4.0 oder 5.0 darauf installieren.

• Ein iPod Mini 4GB: Der erste “kleine” iPod. Dieser hier hat einen neuen Akku (vom Wühltisch bei der zur48).

• Toshiba 2130CT (nicht abgebildet): Notebook mit 16MB RAM und 486er. Auf der Unterseite prangt noch das Siegel des letzten Eigentümers — der Finazverwaltung BaWü.

iPod und einen Revo (es gibt zwei) werde ich garantiert behalten. Der iPod bekommt wohl eine 16GB CF-Karte und evtl. Rockbox als Firmware, der Revo dient weiter als serielles Terminal. Am B-142 hänge ich irgendwie, aber vielleicht lasse ich mich dazu überreden, dieses abzugeben. Die anderen Gegenstände trete ich auf Anfrage ab. Bedingung: Ihr habt eine Idee für ein Bastelprojekt. Egal, ob es Löten oder nur Programmieren umfasst, Ihr müsst jedenfalls nicht gleich SMD-technisch abgehen wie der hier. Und nochwas: IEDs sind kein Bastelprojekt, das sich qualifiziert, eher sowas!

• MSI Wind vs. Medion Akoya E1210: Vor Wochen schon habe ich mir einen sechszelligen Akku (4400mAh statt 2200mAh) für mein Akoya Mini bestellt. Medion hatte keine Akkus mehr im Shop und bei Zur48 gab es den Akku für den Wind für 74,95 Euro. Da beide Geräte das gleiche Chassis verwenden, hoffte ich auf Kompatibilität. War aber nix. Ein kleiner Kunststoffsteg soll verhindern, dass man MSI-Akkus im Medion Akoya verwendet. Abhilfe ist einfach: Beide Akkus nebeneinanderlegen, den Kunststoffsteg neben den Kontakten identifizieren und dann mit dem Teppichmesser herausschnitzen. Möglicherweise tut es auch ein Lötkolben.

• Ob es Palm schafft? Das Betriebssystem haben sie ja schon an Access übertragen, die Modellpalette enthält nun unter Produktionskosten verschacherte PalmOS-Geräte (ab 99€ beim Dittsche-Markt) und nicht wirklich aus der Masse herausragende Windows-Geräte. Schade eigentlich. Denn Palm hatte früher gute günstige Geräte mit langer Akkulaufzeit, intuitiver Bedienung und großer Anwendungsauswahl. Nun geht’s zu Ende.

• Nokia denkt laut über Linux nach: Interessant war vor ein paar Wochen die Meldung, dass ausgerechnet Google und Motorola über den Umweg Gnome Mobile künftig zu OpenMoko, Maemo und Poky beizutragen. Offenbar ist das derzeit ausschließlich via Java-API ansprechbare Android nicht flexibel genug. Künftig wären Hybriden denkbar: Reines Android auf den günstigeren Telefonen und auf den teureren das vollständige Gnome Mobile mit einer DalvikVM, die auf Gnome- und Gtk-APis aufsetzt. Zur Konkretisierung meiner letzten Randnotizen: Nicht primär Android ist die interessante Sache, sondern die DalvikVM. Die möchte ich nicht nur auf Geräten mit einem richtigen Linux sehen, sondern auch auf iPhones. Auch Nokia denkt laut über Linux auf höherwertigen Mobiltelefonen nach, hält aber von Maemo mehr als von Android. Nach dem vollständigen Kauf von Trolltech ist Qt bald sowohl für Symbian (wird wohl das Lower-End-Betriebssystem werden) als auch für Maemo verfügbar.

• Inflight-Entertainment für Geeks: TAM fliegen, eine der neuen 777 erwischen und kurz nach dem Start auf den Monitor im Sitz vor Dir schauen. Was ist das? Redboot als Bootloader, ein AMD Geode, 256MB RAM, natürlich Linux. Netterweise hat das Softwarehaus, welches die Inflight-Distri zusammengestellt hat auf einen Bootsplash verzichtet, so dass man schön zuschauen kann, wie eine SD-Karte gemountet wird und von dort auf Loopback eingehängte Container mit den Apps zugegriffen wird. für den “DVD”-Player scheint ein Chip von Sigma zum Einsatz zu kommen (wie im LaCie-Festplattenplayer). Auch ein paar Bugs sind drin, so beschwert sich die Bash über fehlende Klammern. Expected ‘}’. Der Bootvorgang dauert ewig, so dass man einiges über “fette” Embedded-Systeme lernen kann:

  

  Nachtrag: Könnte die Panasonic-Hardware und das RED-System sein…

Denkste…

Auf dem Büroserver lief ein Vanilla-Xen mit selbstgebautem Kernel. So sollte es auch bleiben. Für ein Update des Ubuntu 7.10 mit Xen 3.2 bestand zunächst keine Veranlassung, ich besorgte mir also frische openSUSE-11.0-Kernel-Quellen — die sind relativ aktuell (2.6.25) und enthalten die Xen-Patches mit all den von mir benötigten Features. Dummerweise brach der Build mit einem Compile-Fehler ab — möchte openSUSEs Kernel etwa einen bestimmten Compiler? Da die Dom0 letztlich nicht besonders viele Dienste beherrbergt und eigentlich dazu dient, Geräte an die DomUs durchzuschleifen, entschied ich mich für das Aufsetzen einer frischen Dom0. Als Distribution sollte openSUSE 11.0 zum Einsatz kommen, schließlich ist Novell neben RedHat der Distributor mit dem stärksten Xen-Engagement und sollte daher eine komplette und gut abgestimmte Dom0 liefern. Leser, die über planet.ubuntuusers.de auf diesen Eintrag kamen, mögen mir verzeihen.

Und dann nach Netzwerkprobleme

Als Installationsmedium verwenden wir gerne einen PXE-/TFTP-Bootserver. Da genügt es, den Rechner ans Netz zu stöpseln, das BIOS korrekt einzustellen und dann ein paar Sekunden auf das Bootmenü zu warten. Der neue Rechner lud auch brav Kernel und Initrd, fand aber danach keinen Link mehr. Gnarrrr…

eth0: RTL8168c/8111c at 0xee112000, 00:21:de:ad:be:ef, XID 3c4000c0 IRQ 18

Das Problem ist besonders bei Realtek-Karten bekannt und tritt immer wieder einmal auf: Anscheinend bleiben Reste des PXE-Codes im Speicher der Karte, worauf diese vom Kernel nicht richtig initialisiert werden kann. Ähnliche Probleme treten manchmal beim Hin- und Herbooten zwischen verschiedenen Betriebssystemen auf. Meist hilft ein BIOS-Update in Kombination mit den aktuellsten Treibern (sprich: einem frischen Kernel oder Herstellertreiber). Das war mir dann zu aufwendig, ich deaktivierte den PXE-Boot und entschied mich für die Installation per USB-DVD-ROM.

Juchhu, er bootet

Die Installation der nackten openSUSE und die Nachinstallation von Xen sowie das erste Update mittels zypper lief problemlos durch — ich hätte ehrlich gesagt bei einem Minimalsystem nichts anderes erwartet. Xen wurde sauber in der Grub-Konfiguration eingetragen und ich selbst fügte dem Linux-Kernel noch die Einträge zum Durchschleifen von USB- und DVB-Karte hinzu:

pciback.permissive pciback.hide=(0000:06:00.0)(0000:06:00.1)(0000:06:00.2)(0000:06:01.0)

Zu früh gefreut

Dummerweise lies sich die DomU mit dem Videorecorder nicht starten. Das ist die einzige Domain, die im Dauereinsatz auf durchgeschleifte PCI-Karten zugreift. Der Aufruf von dmesg schuf Klarheit: Die beiden pciback.-Bootparameter waren unbekannt. Ein Blick in openSUSEs Kernelkonfiguration zeigte die Ursache: Der PCI-Backend-Treiber war als Modul kompiliert, was zur Folge hat, dass erst der Kernel lädt und PCI-Karten initialisiert und dann der Backend-Treiber diese nicht mehr maskieren kann. Ich installierte also die Kernelquellen, passte die Optionen für den Backend-Treiber an (“Backend driver support” und “PCI-device backend driver” fest einkompiliert statt Modul und “PCI Backend Mode (Passthrough)”), versah den Kernel mit einem eigenen Prefix und kompilierte ihn neu.

Nach mkinitrd, Anpassung der Grub-Konfiguration und Reboot war auch diese Hürde gemeistert. Es war Mitternacht, ein guter Zwischenstand, Zeit ins Bett zu gehen.

Das lässt mich kalt (der nächste Morgen)

Und wieder einmal sprang eine Festplatte nach dem Auskühlen nicht an. Wahrscheinlich ist das Öl in einem Lager etwas verharzt. Da die betreffende Festplatte Teil eines RAID5-Verbundes ist, verzichtete ich auf den Trick mit dem Fön und kaufte einfach eine neue. Sollte jemand auf dasselbe Problem stoßen: Zunächst startet man das Array ohne die defekte Festplatte (mit --run oder --force)…

root@kiste# mdadm --assemble --run /dev/md0 /dev/sdd1 /dev/sde1 /dev/sdf1
mdadm: /dev/md0 has been started with 3 drives (out of 4).

Dann partitioniert man die neue Platte und fügt die neue Partition dem Array hinzu:

root@kiste# mdadm --add /dev/md0 /dev/sdc1
mdadm: added /dev/sdc1

Ein Blick ins /proc zeigt dann den Synchronisiationsfortschritt:

root@kiste# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 sdc1[4] sdd1[1] sdf1[3] sde1[2]
      1465151808 blocks level 5, 64k chunk, algorithm 2 [4/3] [_UUU]
      [>....................]  recovery =  0.2% (1398528/488383936) finish=251.2min speed=32304K/sec

unused devices: 

Das RAID-Array kann jetzt bereits verwendet werden, allerdings ist die Performance unterirdisch. Zumindest auf das Kopieren oder Synchronisieren großer Datenmengen sollte man also noch verzichten.

Lästige Kleinigkeiten

Soweit, so gut. Einige Kleinigkeiten bleiben. So verwendet meine Videorecorder-DomU noch einem älteren openSUSE-Xen-Kernel, dessen USB-Massenspeicher-Treiber reproduzierbar abstürzt, wenn eine Festplatte oder ein DVD-ROM angeschlossen ist. Stöpsele ich nach dem Boot an, funktioniert alles einwandfrei. Hier werde ich wohl um einen frischen Kernel nicht herumkommen. Bis dahin lebe ich mit dem etwas aufwendigeren Reboot.

Warum tut man sich soetwas überhaupt an? Ich nutze Xen, weil es sich um die flexibelste Virtualisierungslösung handelt, insbesondere wenn PCI-Karten an unpriviligierte Domains durchgereicht werden sollen. Dazu kommt der geringe Overhead durch Xen selbst. Allerdings haben sich seitens Citrix in letzter Zeit einige Schludrigkeiten eingeschlichen. So ist der originale Linux-Kernel mit Xen-Patches noch auf Stand von 2.6.18, die Xen-Unterstützung im Linux-Kernel reicht gerade für den Betrieb einfacher DomUs und gerade kleinere Distributionen tun sich schwer mit der zeitnahen Integration von Xen-Patches in aktuelle Kernel. Auch Novells Nachlässigkeit bei der Konfiguration des PCI-Backends zeigt, dass man dort Xen wohl nicht mehr ganz so hoch priorisiert wie noch vor gut einem Jahr. Klar, dass Citrix zusammen mit den großen Distributoren die kommerziellen Xen-Varianten verkaufen möchte, aber nur eine breite Nutzerbasis in der Community kann auch dafür sorgen, dass ein Produkt ausgereift und gut getestet am Markt bestehen kann. Eine Mindestvoraussetzung dafür sollte sein, dass aktuelle Kernel bereitstehen und sich als stabil deklarierte Releases auf aktuellen Distributionen kompilieren lassen.

Nun wagt also Apple den Schritt von dünnen planen Aluplatten und Tiefziehteilen zu einem aus dem vollen gefrästen Chassis? Als ich die ersten Spekulationen über den Brick hörte, konnte ich es zunächst nicht glauben. Jetzt wo Bilder des fertigen Gerätes und der CNC-Frässtraße vorliegen, wird der Trick offensichtlich: Das Chassis wird aus einem nur zehn bis elf Millimeter dünnen Alustrang gefräst, der untere Deckel mit der schönen Rundung ist wohl weiterhin ein Tiefziehteil. Das erspart rund 50% Materialverlust (gegenüber einem 15mm dicken Strang) und sorgt zudem für den optischen Eindruck eines dünneren Gerätes.

Gespannt bin ich aufs Oberflächen-Finish: Vermutlich wird Apple einfach lackieren, so ist sichergestellt, dass alles Ton in Ton bleibt. Spassig wird aber die Möglichkeit, das MacBook zu zerlegen, mit Glasperlen zu strahlen und dann dem Eloxator des Vertrauens zu geben, auf dass dieser das Gerätchen in iPod-Mini-Grün oder Ringlé-Babyblau zurückliefert.

• News bei Golem.de