Asus EEE PC: Modders Einkaufszettel

Der EEE - fast völlig nackt! Für Bastler ein erregender Anblick...

Der EEE - fast völlig nackt! Für Bastler ein erregender Anblick...

(Stand: 5.9.08)

Vorbemerkung: Ein halbes Jahr EEE-PC-Entwicklung hat viele dieser Tipps überflüssig gemacht – spätestens, seit der EEEPC 901 auch in Deutschland erhältlich ist – zu einem Preis, der gar nicht so weit weg ist vom Preis des Originalgeräts – haben sich viele der Projekte in dieser Liste erledigt. Mit einer Mischung aus Freude und Betrübnis habe ich zur Kenntnis genommen, dass mein schönes Bluetooth-Projekt bei dieser Maschine vollkommen überflüssig ist, sie außerdem einen Draft-N-Adapter von Haus aus mitbringt und einen schönen Steckplatz für Standard-Festplatten. Verdammt nochmal, womit sollen wir Hardware-Hacker dann noch angeben? :) Und einen Touchscreen in einen EEE 900/901 zu basteln – dafür ist ob des gedrängten Display-Rahmens noch ein wenig mehr Mut erforderlich.

Andererseits gibt’s ja jetzt eine Menge Leute, die sich wie ich einen Pelz ärgern, dass sie auf ihrem inzwischen deutlich wertverlustigen 701er sitzen, und der neuen Traum-Maschine wenigstens ein wenig näher rücken wollen.

Aber jetzt mitten rein.

Nicht alles, was machbar ist, ist sinnvoll. Ich schlage folgende Gezipte Theorie des Sinnhaften Umbaus vor:

Eine gelungene Mod

  • erspart einem, ein Extra-Gerät mit herumzuschleppen
  • bringt wirklich ein Mehr an Nutzen
  • kostet nicht viel

Hier eine Liste mit den Umbauten, die mir gangbar und sinnvoll erscheinen:

Speicher erweitern

Stolpergefahr

PROJEKT: Den internen Speicher des EEE auf 1GB oder 2GB aufrüsten
NÖTIG, WEIL: es im eingebauten Speicher schon mal eng wird mit den Fotos für die 700-seitige Doktorarbeit; minimale Geschwindigkeitsgewinne
KOSTET: 20 Euro für 1GB
WAS MAN KÖNNEN SOLLTE: Einen Schraubenzieher finden – und ein richtig fieser Kernel-Hacker sein (allerdings nur bei einer Erweiterung auf 2GB)
DAGEGEN SPRICHT: dass 512MB von Haus aus eigentlich reichen
Mehr unter: dem entsprechenden Eintrag im eeeuser-Wiki
Schummel-Alternative für Nichtschrauber: Leider keine. Der einzige Ersatz für Speicher ist mehr Speicher.

Größeres internes Flash-Laufwerk

Warnung: Engstelle

PROJEKT: Einen USB-Stick auseinandernehmen – sagen wir: 8GB – und ins Gehäuse des EEE einbauen. Ohne einen USB-Port zu verschwenden.
NÖTIG, WEIL: das interne Laufwerk des EEE schon voll ist, wenn man mehr als einen Film mit in den Urlaub mitnehmen will – da hat jedes iPhone mehr Speicher.
KOSTET: 30 Euro für den Stick, zwei Stunden Bastelei
WAS MAN KÖNNEN SOLLTE: Löten
DAGEGEN SPRICHT: Wenn man nicht löten kann; Scheu vor Garantie-Aufklebern, reduziert die Akkulaufzeit um 5%, nerviges Popup-Fenster bei jedem Einschalten schreit nach einer Software-Anpassung
Mehr unter: diesem Blog-Eintrag
Schummel-Alternative für Nichtschrauber: eine SD-Karte im Erweiterungsslot

Weiterlesen

eeeXubuntu: Netter Versuch! [Update 4.4.08]

Schön ausgedacht. Hübsch umgesetzt. Und dann kommt die hässliche Praxis. Beim EEE PC unter eeeXubuntu liegt die Tücke im Detail.

Um das vorneweg klarzustellen: es geht nicht nur um den Fuchsschwanz-Faktor. Der EEE-PC soll mein Begleiter sein in Alltag und Berufsleben; ich will ein System, das so sicher ist und komfortabel wie (X)Ubuntu, aber so schnell da wie Xandros, oder wenigstens fast: Notiz machen, Rechner zuklappen = Akku sparen, eine Stunde später die nächste Notiz. Außerdem hätte ich gern ein bisschen mehr Speicher als die knapp 200MB, die die Xubuntu-Installation auf sda1 vom internen Flash-Speicher übrig lässt. Deshalb der Hassel mit internem 8GB-Aufrüststick und der Swap-Partition, sonst könnte ich mich ja auch mit einem normalen Boot zufrieden geben.

Die interne USB-SolidStateDisk - an für sich eine gute Idee…

Nun passiert beim Suspend-to-disk-Tiefschlaf offenbar folgendes (wilde Theorie): die Swap-Partition wird auf Platte geschrieben – auf sda5, im internen Speicher also -, dann geht der EEE schlafen und meldet dabei die USB-Anhängsel ab. Da er sie nach dem Aufwachen wieder ordentlich anzapft, ist das soweit kein Problem.

Außer dass der 8GB-Speicher dann als sdd angemeldet wird, nicht als sdc. Was soweit nicht weiter wild wäre, wenn ich ihn nicht in Form der sdc3-Partition als /home-Verzeichnis gemounted hätte. Das Home-Verzeichnis ist also weg, und der Desktop läuft nicht mehr rund.

Versuche, den Rechner auszutricksen, haben auch nichts gefruchtet:

  • ein Skript in /etc/acpi/suspend.d/ – Ordner, das die Partition abmeldet, ein weiteres, das sie wieder anmeldet,
  • ein Mounten der sdc3-Partition über die UUID statt über den Namen /dev/sdc3.

Und nun? Ein Linux-Übergeek wüsste sicher sofort, was faul ist und was man tun kann. Der Untergeek muss weiter experimentieren.

(Da fällt mir auf, ich habe noch gar nicht geschaut, ob das beim normalen Suspend-to-RAM auch passiert… ts, ts…)

Nachtrag, 4.4.08:
Wie hat der hamburgische Kollege Detlef Schwarzer immer gebrummelt? „Versuch macht kluch!“ In der Tat. Das Problem tritt auch bei Suspend-to-RAM auf und lässt sich daher auch gut per dmesg im Log nachlesen: der SCSI-Treiber versucht, die Laufwerke anzusprechen, die sind aber abgeschaltet worden. Der Treiber weiß sich nicht anders zu helfen, als für die wiedergefundenen USB-Laufwerke neue SCSI-Kanäle anzumelden. Deshalb ist mein /home-Verzeichnis plötzlich auf sdd5 statt sdc5, was den Fenstermanager natürlich aus dem Takt bringt.

Immerhin funktioniert ein Trick:

(1) Ins Verzeichnis /etc/acpi/suspend.d eine ausführbare (Skript)-Datei anlegen namens 12-unmount-usb.sh, die den Befehl umount /home ausführt.

(2) Die FSTAB so anpassen, dass das /home-Laufwerk nicht über /dev/sdc5 gemountet wird, sondern über seine UUID.

(3) Im Verzeichnis /etc/acpi/resume.d ein weiteres Skript namens 89-remount.sh, das – naja – mit mount -a alles remounted. Damit ist das home-Verzeichnis immerhin wieder verfügbar, leider gehen einem irgendwann die Laufwerksbuchstaben aus, weil der SCSI-Controller wie gesagt dauernd neue Kanäle registriert, sodass man schon beim zweiten Resume plötzlich das Laufwerk sdf im System hat.

Der Trick ist also keine Lösung – die Skripten müssen also das USB-Laufwerk ordentlich abmelden, damit es an alter Stelle wieder einsortiert wird. Ein erster Anlauf brachte keine Lösung, aber ich arbeite dran.

Asus EEE PC: Xandros oder Xubuntu?

Fuchsschwanzmofa

Hat man ein Mofa nicht nur, damit man den Auspuff aufbohren kann – und einen Fuchsschwanz an den Lenker binden? Für junge Männer trifft das sicher zu. Von daher ist ein Alternativ-Betriebssystem für den Kleinst-Laptop EEE sicher eine feine Sache, die einem das Gerät noch näher bringen kann. Ubuntu bietet sich an – das ist verbreitet, komfortabel und in der gut angepassten Variante eeeXubuntu zu bekommen. Aber hat das Ganze über den Fuchsschwanz-Wert hinaus noch praktischen Nutzen?

Xubuntu-Einstellmöglichkeiten

Ein paar grundsätzliche Überlegungen

Bestandsaufnahme: im direkten Vergleich mit der EEE-Standardinstallation ist (X)Ubuntu-Linux unbestritten

Und da ist das dickste Argument noch gar nicht erwähnt: die riesige Ubuntu-Community, die noch das obskurste Problem längst gelöst hat. Allerdings sind riesige Gewinner-Communities eher abstossend – der „Bayern-München-Effekt“. Die wirklich coolen Säue sitzen in der EEE-Gemeinde, oder? Und sie haben nicht nur (einige wenige) Freunde bei Asus in Taiwan, sie haben auch gute Argumente, lieber am vorinstallierten EEE-Xandros-Linux weiterzuschrauben – trotz aller berechtigten Kritik an der lieblosen Linuxerei auf dem Standard-EEE.

Denn das Xandros hat drei schwergewichtige Argumente für sich:

  • Speed
  • Speed
  • Speed.

Mein schon heftig verbasteltes Xandros kreidlert ab wie ein Epo-Radler. Nach 12 Sekunden ist der Cursor da, nach spätestens weiteren 21 Sekunden ist der Desktop einsatzbereit, nach weiteren 11 Sekunden steht die WLAN-Verbindung. Um komplett abzuschalten, benötigt das System sage und schreibe 10 Sekunden – in dieser Zeit hat eeeXubuntu kaum den Tastendruck ausgewertet.

Die eeeXubuntu-Vergleichswerte für einen normalen Bootvorgang: 42 Sekunden bis zum Login-Bildschirm, der Standard-Desktop steht nach weiteren 11 Sekunden, bis der völlig überflüssige 3D-Schickibuntifuchsschwanz-Fenstermanager compiz übernommen hat, sind noch einmal 42 Sekunden vergangen (ist Warten der wahre Sinn des Lebens?) Heruntergefahren ist Xubuntu in 22 Sekunden.

Etwas besser sieht der Vergleich aus, wenn man eeeXubuntu nicht kaltstartet, sondern in den Tiefschlaf schickt (a.k.a. suspend-to-disk oder hibernate) und wieder aufweckt. 32 Sekunden, bis der Rechner alles gesichert hat und den Winterschlaf erreicht, 30-35 Sekunden, bis er arbeitsfähig wieder vor mir steht. Das ist doch schon besser.

Eine Tiefschlafstudie

Die Tiefschlaffunktion ist sicher der grösste Leckerbissen auf der Palette der eeeXubuntu-Spezialitäten; im Xandros -Kernel ist sie gar nicht hineinkompiliert, was nicht nur Robert Basic Nerven raubte. Mich wiederum kostete es einige Nerven, bis eeeXubuntu wirklich winterschlafen wollte. Letztes Problem war, dass nach dem „Hibernate“die swap-Partition regelmässig verschwunden war – und das ist bei allen so, die die Standardinstallation nutzen. Das Problem liegt interessanterweise im Bootmanager: die entsprechende Grub-Zeile wurde um „resume=/dev/sda5“ ergänzt, und das Problem war behoben. Ein bekannter Bug der Standard-Installation mit ubiquity. (Mehr Details hier. )

Die Installation war auch kein Zuckerschlecken: für eine fuchsschwanzige Xubuntu-Experience rät es sich, die Schrauber-Liste im eeeUser-Wiki Punkt für Punkt abzuarbeiten. – Nun denn: Nachdem Xubuntu nun also rund läuft, ist eins im direkten Vergleich nicht mehr zu übersehen: hübsch, aber fett. Ein rundes halbes Gigabyte mehr als meine vergleichbare Xandros-Installation, und da sind die 560MB für die nötige Swap-Partition noch gar nicht gerechnet. (Zum Sinn und Unsinn von Swap auf Flash-Karten hier bald mehr.) Schöne Spielereien wie Compiz verbrennen wertvollen Akku-Strom, ebenso wie all die hübschen Helferlein, die man sich zwangsläufig ins Haus holt – selbst auf dem schlanken XFCE-Desktop.

Halten wir fest: es macht sich bezahlt, dass Asus sein Taschenlinux liebevoll klein und schnell optimiert hat; man spart sich endlose Headerdateien und ganze Regale voller Bibliotheksdateien, die für den EEE ohnehin irrelevant sind. Die Vorteile der Optimierung durch Asus scheinen die grössere Ubuntu-Community auszugleichen – das Xandros bleibt die Nummer eins. Wenn man nicht doch einen Fuchsschwanz will.

Nachsatz

Der grosse Vorteil am Tiefschlaf ist unbestritten: man arbeitet genau da weiter, wo man aufgehört hat. Das Xandros ist zwar wie gesagt schneller, wenn man es komplett herunter- und wieder hochfährt, verbraucht in der Zwischenzeit dann auch keinen Strom, nervt aber, weil man alles, was Office offen hatte, erst mal wieder herstellen muss. Eine Projektidee: alle aktiven Userspace-Programme wie Firefox, Ooo und Mail über so was hier in eine Datei sichern und über ein Startskript wieder aufrufen? (Noch nicht getestet; die Software scheint nicht weiterentwickelt zu werden.)

Noch ein allerletztes PPS: gerade will ich diesen Artikel speichern, da schaltet der EEE ohne Vorwarnung ab. Der Akku war leer, und xubuntu hat’s nicht gemerkt. Da ist wohl noch Bastelei fällig.

GENERATED FILE. DO NOT EDIT.

Nicht ändern! Diese Warnung steht in der ersten Zeile einer Datei, über die Firefox dressiert werden kann, auch unter Linux „.M4V“-Dateien zu streamen. Dummerweise muss man die Datei dazu aber ändern.

Weshalb ist die folgende Aktion nötig? Seit ich einen iPod Touch besitze, kann ich direkt von der Videorekorder-Platte gucken – EyeTV macht’s möglich; die Videorekorder-Software für meinen Mini-Mac bringt außer diversen Exportformaten auch einen kleinen Medienserver mit Webinterface mit. Er produziert die MPEG-4-Ströme, die das im iPod verbaute Quicktime versteht.

Wäre doch schön, wenn man diese Ströme auch von den anderen Rechnern aus nutzen könnte? Sie sind ja schließlich nichts besonderes – im Prinzip. Leider nicht auf dem Linux-Laptop, dem meistgenutzten Rechner – dort weigert sich ein mit allen Plugins gewaschener Firefox schlicht, die Filme abzuspielen, und verlangt nach einem Quicktime-Plugin. Der MIME-Typ „video/x-m4v“ sei sonst nicht abzuspielen.

Nun muss man wissen, dass diese Behauptung lächerlich ist. Nicht nur, dass MPlayer und Kaffeine Quicktime-Codecs an Bord haben und von daher überhaupt keine Schwierigkeiten mit MPEG-4 oder H.264; installiert ist auch das Hausschwein unter den Videoplayern: VLC frisst eigentlich alles. Nicht diesmal. Was ist los?

Schließlich löscht ein chirurgischer Eingriff in ~/.mozilla/firefox/pluginreg.dat das Problem. Eben jene Datei, deren erste Zeile… siehe Überschrift. Einfach den Abschnitt für das mplayerplug-in wie folgt ergänzt:

QuickTime Plug-in 6.0 / 7:$
8
0:video/quicktime:Quicktime:mov:$
1:video/x-quicktime:Quicktime:mov:$
2:image/x-quicktime:Quicktime:mov:$
3:video/quicktime:Quicktime:mp4:$
4:video/quicktime:Quicktime – Session Description Protocol:sdp:$
5:application/x-quicktimeplayer:Quicktime:mov:$
6:application/smil:SMIL:smil:$
7:video/x-m4v:MPEG-4:m4v,mp4:$

..also: die letzte Zeile hinzugefügt, die Anzahl der MIME-Typen oben auf 8 abgeändert (war vorher 7), und die Sache läuft. Brav öffnet MPlayer die Streams in einem neuen Fenster.

Nun geht’s: Eyetv streamt auf den Linux-Rechner Interessanterweise geht derselbe Versuch schief, wenn ich die VLC-Dateien verändere. Der Player läuft nicht los. Woran liegt’s: Zu ungeduldig? Egal, so geht’s ja; der Hack funktioniert.

Also: in Zukunft von derartigen Warnungen nicht abschrecken lassen. Das T-Shirt dazu gibt’s im Make Store.

Beware!