planetknauer.net

Kaum zu glauben: Aber mit Treiberversion 11.7 steht nun endlich ein AMD-Treiber zur Verfügung, welcher sich ohne rumgepatche und langen händischen Kompilierorgien out-of-the-box auf Kernel 2.6.38 aus den Debian Backports installieren lässt. Wird ja auch so langsam Zeit, jetzt wo schon bald Kernel 3.1 vor der Türe steht...

AMD hat vorgestern Treiber 11.4 für Linux veröffentlicht. Der ist somit zwei Monate nach Kernel 2.6.38 erschienen. Ob der Treiber sich wohl gegen den Kernel kompilieren lässt?

Antwort: Leider nein:

AMD kernel module generator version 2.1
doing Makefile based build for kernel 2.6.x and higher
rm -rf *.c *.h *.o *.ko *.a .??* *.symvers
make -C /lib/modules/2.6.38-2-amd64/build SUBDIRS=/usr/src/fglrx-8.841/2.6.x modules
make[1]: Entering directory `/usr/src/linux-headers-2.6.38-2-amd64'
CC [M] /usr/src/fglrx-8.841/2.6.x/firegl_public.o
/usr/src/fglrx-8.841/2.6.x/firegl_public.c: In function ‘KCL_GlobalKernelLock’:
/usr/src/fglrx-8.841/2.6.x/firegl_public.c:1903: error: implicit declaration of function ‘lock_kernel’
/usr/src/fglrx-8.841/2.6.x/firegl_public.c: In function ‘KCL_GlobalKernelUnlock’:
/usr/src/fglrx-8.841/2.6.x/firegl_public.c:1909: error: implicit declaration of function ‘unlock_kernel’
make[4]: *** [/usr/src/fglrx-8.841/2.6.x/firegl_public.o] Fehler 1
make[3]: *** [_module_/usr/src/fglrx-8.841/2.6.x] Fehler 2
make[2]: *** [sub-make] Fehler 2
make[1]: *** [all] Fehler 2
make[1]: Leaving directory `/usr/src/linux-headers-2.6.38-2-amd64'
make: *** [kmod_build] Fehler 2
build failed with return value 2

Ich tippe ja drauf, dass man da noch über das entfernte BKL stolpert.

Bislang gab es relativ gute Pakete für Mumble 1.2.3 aus Debian Experimental, welche sich sauber unter Debian Squeeze installieren liessen. Unterdessen gibt es einen neuen Build, der auch grad das ganze QT aktualisieren will. Da dürfte ein ziemlich defektes System daraus resultieren. Logische konsequenz? Selber bauen natürlich

zuerst das alte Mumble deinstallieren:

aptitude purge mumble

Danach geht's eigentlich streng gemäss Wiki. Als nächstes muss man die benötigten Entwicklungspakete installieren:

apt-get build-dep mumble

Und nun die Source mit den gewünschten Parametern kompilieren. Ich brauch weder Server noch den Mumble 1.1 Clienten. Letzterer wird über den nicht dokumentierten Switch no-11x deaktiviert. Unter Debian werden die Lokalisierungen nicht gefunden und integriert, daher werden diese einfach ausgeschaltet. Vermutlich liesse sich das über Symlinks korrigieren

tar -zxf mumble-1.2.3.tar.gz
cd mumble-1.2.3
qmake-qt4 -recursive main.pro CONFIG+=no-server CONFIG+=no-embed-qt-translations CONFIG+=no-11x
make
su -c 'cp -r release /opt/mumble'
su -c 'cp icons/mumble.xpm /opt/mumble'

Und nun noch die Sache starten:

/opt/mumble/mumble

Dank virt-manager kann man auch mit kvm und xen per Klickibunti übers Netzwerk administrieren. Nur, unter Debian kann es vorkommen, dass alles korrekt eingerichtet ist (libvirtd läuft, User ist in der Gruppe libvirtd, /var/run/libvirt/libvirt-sock ist zugreifbar), trotzdem weigert sich der virt-manager mit der Meldung

"Unable to open a connection to the libvirt management daemon. Verify that: - The 'libvirtd' daemon has been started"

Liest man die Meldung weiter, so stösst man auf die Zeile

error: server closed connection: nc: invalid option -- 'U'

Die Lösung: Debian installiert standardmässig netcat-traditional. Das unterstützt aber die Option U nicht. Dafür wird netcat-openbsd benötigt. Folglich kann man das beheben mittels

aptitude install netcat-openbsd

Zum Glück ist Debian Stable ja sooo bugfrei.

Sobald man mehr als zwei Monitore angeschlossen hat, beginnt Gnome bei der Multimonitorfähigkeit zu versagen. Ich habe zwei Monitore zu einem grossen Desktop zusammengefasst (AMD nennt dies in seinen proprietären Treibern BigDesktop) und einen weiteren Monitor separat laufen. Leider maximieren sich Fenster nun über den ganzen Dualscreen statt sich perfekt auf einen Monitor einzupassen. Besonders mühsam ist dies, wenn man ein Video im Vollbildmodus betrachten will. Mit nur zwei angeschlossenen Monitoren passiert dies nicht - selbst wenn diese zu einem grossen Desktop zusammengefasst werden. Interessanterweise sind aber das Hintergrundbild sowie die Panel perfekt an den Monitor angepasst. Da kommt als Verdächtiger folglich rasch der Window Manager, also Metacity in Frage.

Folglich habe ich diesen durch diverse andere Varianten ersetzt. openbox scheitert genau so am Multimonitor und mutter stürzt direkt mit Speicherzugriffsfehler ab. Aber xfwm4 aus Xfce4 funktioniert gemäss Wunsch. Allerdings braucht es dann noch einiges an Tweaking, bevor das ansonsten gewohnte Metacity-Verhalten wiederhergestellt ist (und ein paar sehr nette Komfortfunktionen dazugewonnen wurden).

Zunächst muss xfwm mit ein paar Accessoires installiert, gestartet und konfiguriert werden. Alle Angaben sind wie üblich für Debian und verwandte Systeme:

su
aptitude install xfwm4 xfce4-utils xfce4-settings
exit
xfmw4 --replace &
xfwm4-settings
xfce4-settings-helper

Der xfce4-settings-helper verschwindet sofort im Hintergrund und aktiviert die Tastenkürzel wie z.B. Alt-F2 wieder.

Jetzt stört mich nur noch, dass Fenster auch beim Scrollen mit dem Mausrad Fokus bekommen. Dies lässt sich über den xfce4-settings-editor abstellen, indem man den Wert des Eintrags /xfwm4/raise_with_any_button auf FALSE setzt.

Soweit so einfach. Kommen wir nun zum zeitlich aufwändigsten Teil. Um nun xfwm4 permanent als Standard einzurichten, gibt es unzählige Möglichkeiten. Ich habe nur eine gefunden, die "gefühlt fehlerfrei" funktioniert und diese ist technisch gesehen totaler Blödsinn. Und zwar habe ich in gnome-session-properties zwei neue Starter angelegt. Einer startet /usr/bin/xfwm4 --replace und ein zweiter /usr/bin/xfce4-settings-helper. Das ist natürlich insofern doof, da erst metacity und danach xfwm4 als Ersatz gestartet wird. Dies führt bei mir jedoch zu absolut keiner Startverzögerung, ganz im Gegensatz zu der Variante, eine ~./gnomerc anzulegen und darin die Zeile export WINDOW_MANAGER="/usr/bin/xfwm4" einzufügen. Das Resultat ist ein um 10 Sekunden verzögertet Start von Gnome. Das ist natürlich nicht akzeptabel. Ebenso gibt es die Variante im gconf-editor unter /desktop/gnome/session/required_components den Schlüssel windowmanager von gnome-wm zu xfwm4 zu ändern. Das Resultat hierbei war, dass gar kein Window Manager mehr gestartet wurde. Also noch schlimmer! Tja, und unter Debian gibt's noch die /etc/alternatives/x-window-manager. Diesen Symlink von /usr/bin/metacity auf /usr/bin/xfwm4 zu ändern bringt grad gar nichts, da dieser Symlink auf meinem System von gnome-wm (ist nur ein Shellskript) gar nicht ausgewertet wird.

Somit wär also ein Freitagabend verschwendet, weil Debian Stable ja sooo bugfrei ist.

Schade, dass nagelneue Boards immer noch dieses eklige BIOS statt dem wesentlich moderneren EFI mitbringen. BIOS und Grub können nämlich nichts mit GPT anfangen, was für grosse Partitionen über 2TB aber notwendig ist. Und BIOS bzw MBR begrenzt die Partitionsgrösse auf anachronistische 2TB. Denn wenn man schon 4*2TB kauft, um ein anständiges NAS zu basteln, will man sich nicht lange mit Daten hin-und-her-Schaufelei von Partition A nach Partition B und zurück befassen. Doch auch dafür gibt es eine Lösung:

Es darf einfach keine Partition über 2TB Grösse existieren, auch nicht als Software-RAID-Verbund. Aber LVM darf sich darüber hinwegsetzen.

Daher mein Setup:
- Am Anfang der Platten eine kleine Partition von 128MB als RAID-1 für /boot
- Danach drei Partitionen à 666GB, welche jeweils als RAID-10 zusammengefasst werden
- Die drei RAID-10 Partitionen werden mittels LVM zu einem gigantischen logischen Volume zusammengefasst. Alternativ kann man natürlich auch ein RAID-5 nehmen, dann tauscht man 2TB mehr Festplattenplatz gegen massiven CPU-Overhead bei allen Zugriffen ein.

Zuerst mal mit einer Live-CD nach Wahl starten und die Disks vorbereiten. Zu beachten ist, dass so grosse Festplatten gerne mit 4k-Sektoren ausgeliefert werden:

cfdisk -h224 -s56 /dev/sda #erstellen von 4 Partitionen vom Typ FD (RAID autodetect) unter Beachtung der 4k-Sektorengrenze
sfdisk -d /dev/sda | sfdisk --force /dev/sdb #sfdisk mag die 4k-Sektorengrenzen nicht, daher erzwingen wir sie
sfdisk -d /dev/sda | sfdisk --force /dev/sdc
sfdisk -d /dev/sda | sfdisk --force /dev/sdd
mdadm --create --verbose /dev/md0 --level=1 --raid-devices=4 /dev/sd?1
mdadm --create --verbose /dev/md1 --level=10 --raid-devices=4 /dev/sd?5
mdadm --create --verbose /dev/md2 --level=10 --raid-devices=4 /dev/sd?6
mdadm --create --verbose /dev/md3 --level=10 --raid-devices=4 /dev/sd?7
pvcreate /dev/md[123]
vgcreate bigdisk /dev/md[123]
vgchange -a y bigdisk

Danach erstellt man ein paar logische Volumen nach Bedarf, startet die Setup-CD (in meinem Fall natürlich Debian Squeeze) und schon läuft die Sache rund. Partman wird sich zwar trotzdem beschweren, lässt aber die Installation zu. Und Grub installiert sich ganz normal im MBR.

Da heute LibreOffice 3.3 in stabiler Version freigegeben wurde, wird es höchste Zeit, das proprietär gewordene OpenOffice.org loszuwerden. Da LibreOffice schon im experimental-Zweig von Debian Einzug gehalten hat, lässt es sich sehr elegant auch unter Squeeze (derzeit noch testing) installieren.

Zuerst muss der experimental-Zweig zu apt hinzugefügt werden:

cat >> /etc/apt/source.list <<EOF
deb http://ftp.ch.debian.org/debian/ experimental main
deb-src http://ftp.ch.debian.org/debian/ experimental main
EOF
cat >> /etc/apt/preferences <<EOF
Package: *
Pin: release a=testing
Pin-Priority: 700

Package: *
Pin: release a=experimental
Pin-Priority: 600
EOF

aptitude update

Anschliessend kann bequem irgendwelche Software aus experimental hinzugefügt werden, indem mittels dem Parameter -t an aptitude/apt-get signalisiert wird, welcher Debian-Zweig verwendet werden soll. Die LibreOffice-Paket haben jedoch noch ein paar unsaubere Abhängigkeiten, so dass derzeit einige davon aus testing verwendet werden müssen.

aptitude install libhsqldb-java
aptitude -t experimental install libreoffice libreoffice-l10n-de libreoffice-gnome ttf-opensymbol

Irgendwie läuft der Ati-Kram noch nicht ganz zufriedenstellend. Immerhin hat es AMD unterdessen fertiggebracht, ihr Treiberpaket mit korrekten md5-Signaturen zu versehen. Ich hab daher auf meinem Debian Squeeze ein Kernel-Update auf 2.6.36.3 vorgenommen (mit dem 2.6.37 kann man den Ati-Murks unmöglich kompilieren) und dann den aktuellen Ati-Treiber versucht zu installieren. Nicht ganz trivial, aber es geht. Ich setze mal voraus, dass ein vollständiges build-environment samt gcc und xorg-dev installiert ist.

Erst ein Kernel-Update:

cd /usr/src
tar -jxf /path/to/linux-2.6.36.3.tar.bz2
cd linux-2.6.26.3
cp /boot/config-2.6.32-5-amd64 .config
make oldconfig
fakeroot make-kpkg --initrd --append-to-version=-custom kernel_image kernel_headers --jobs=8
dpkg -i ../linux-image-2.6.36.3-custom_amd64.deb

Mit --jobs=8 wird der nagelneue Quadcore auch endlich mal etwas ausgereizt

Gut, danach reboot und Installation der Ati-Treiber samt der dubiosen Patches von hier:

sh ati-driver-installer-10-12-x86.x86_64.run
cd /
patch -p1 < /path/to/arch-2.6.36.patch
patch -p2 < /path/to/ati-drivers-2.6.36.patch
patch -p1 < /path/to/ati-drivers-fix_compilation-bug-297322.patch
patch -p1 < /path/to/sema_init.patch
cd /lib/modules/fglrx/build_mod
./make.sh
cd ..
./make_install
modprobe fglrx

Dann klappt's auch mit AMD. Die grosse Stolperfalle ist der zweite Patch, welcher anders codierte Pfadangaben drin hat und darum mit -p2 statt -p1 aufgerufen werden will. Der Rest ist ziemlich geradeaus.

Kann man wirklich sooooooooooo dumm sein???

$ sh ati-driver-installer-10-12-x86.x86_64.run
Created directory fglrx-install.qE5M0i
Verifying archive integrity...Error in MD5 checksums: 48c2e8ce1f504f07a0985afe489b26e3 is different from dfc5d2753d97882b67eb453b85ff8dbc

Zum Glück hat die Karte nur 38.- gekostet. Na ja, nächstes mal wieder nVidia.

Neulich bin ich mal gefragt worden, wie ich Backups mache. Die Antwort: Mit einem relativ simplen Cron-Skript und rdiff-backup per SSH auf den Fileserver. Das gibt ein schönes inkrementelles Backup, bei dem man beliebig weit zurückgehen kann, allerdings behalte ich nur die Daten der letzten zwei Monate. Rdiff-Backup braucht relativ wenig Rechenleistung, Bandbreite und Speicherplatz und funktioniert auch hervorragend über's Internet. Wird das Cron-Skript häufig genug aufgerufen, emuliert dieses Backup recht gut das Verhalten von Apples Time-Machine. Nachteilig ist lediglich, dass es in meinem Fall ein vom Clienten initiiertes Backup ist. Solange der zu sichernde Rechner die Daten auf den Backup-Server schreibt, ist ein Backup nicht sicher vor Manipulationen. Besser wäre es, wenn der Server vom Clienten lesen würde. Nur bräuchte der Server dann root-Login auf dem Clienten, was auch nicht unbedingt der Sicherheit förderlich ist...

Folgendes muss man auf dem Server einrichten:

• SSH-User für's Backup
• Im $HOME/.ssh/authorized_keys die public-SSH-Keys des root-Users der zu sichernden Systeme eintragen (ja, das Backup-Skript wird in der Regel als root laufen, da man z.B. auch /etc sichern will).
• Im Verzeichnis, welches die Backups enthalten soll, muss für jeden zu sichernden Rechner ein Verzeichnis erstellt werden, das so heisst, wie der Host (zu erfahren durch Eingabe von "hostname" auf dem Client)
• In diesen Verzeichnissen muss jeweils eine Verzeichnisstruktur erstellt werden, welche der $DIRECTORIES-Variable aus untenstehendem Skript entspricht.
• Zuletzt chownt man diese gesamte Struktur an den zuerst erstellen SSH-User.

Und so schaut mein Skript aus:

#!/bin/bash

### Settings ###
DIRECTORIES="/etc /home /usr/local/bin"
EXCLUDES="/home/*/.local/share/Trash"
SSHUSER="rdiff-backup"
SSHHOST="192.168.0.1"
REMOTEDIR="/mnt/backup/$(hostname)/"
RDIFF="/usr/bin/rdiff-backup"
RDIFFOPTIONS="ssh -p 2222 %s rdiff-backup --server"
FILEAGE="2M"

NOW=$(date +"%Y-%m-%d")
GZIP="$(which gzip)"
STATUSFILE="/var/tmp/rdiff-backup-status"
LOCKFILE="/var/lock/rdiff-backup-lock"
DUMPDIR="/home/backup"

if [ -e "$LOCKFILE" ]; then
echo "Lockfile exists, quitting..."
exit 255
fi

touch "$LOCKFILE"

### Packages List ###
dpkg --get-selections | $GZIP > $DUMPDIR/dpkg.$NOW.txt.gz
RETVAL=$(($RETVAL + $?))

### File based Backup ###
for DIR in $DIRECTORIES; do
EXCLUDESLIST=""
for EXCLUDE in $EXCLUDES; do
SIZE=$(expr match "$EXCLUDE" "$DIR")
if [ $SIZE -gt 0 ]; then
EXCLUDESLIST="$EXCLUDESLIST --exclude $EXCLUDE"
fi
done
$RDIFF $EXCLUDESLIST --remote-schema "$RDIFFOPTIONS" $DIR $SSHUSER@$SSHHOST::$REMOTEDIR/$DIR
RDIFFRETVAL=$?
RETVAL=$(($RETVAL + $RDIFFRETVAL))
if [ $RDIFFRETVAL = 0 ]; then
$RDIFF --force --remote-schema "$RDIFFOPTIONS" --remove-older-than $FILEAGE $SSHUSER@$SSHHOST::$REMOTEDIR/$DIR
RETVAL=$(($RETVAL + $?))
fi
done

find $DUMPDIR -ctime +7 -exec rm -f '{}' ';'
RETVAL=$(($RETVAL + $?))

echo $RETVAL > "$STATUSFILE"
rm -f "$LOCKFILE"
exit $RETVAL

Was bedeuten nun all die Variablen unter "Settings"?

• DIRECTORIES: Die zu sichernden Verzeichnisse.
• EXCLUDES: Nicht zu sichernde Verzeichnisse
• SSHUSER: Mit welchem User wird per SSH am Server angemeldet
• SSHHOST: Die Adresse des Backup-Servers. Entweder eine IP oder ein Hostname.
• REMOTEDIR: Das Basisverzeichnis, worin auf dem Server die Backups gespeichert werden.
• RDIFF: Pfad zum lokal rdiff-backup Binary
• RDIFFOPTIONS: Wenn man zusätzliche Optionen angeben will, z.B. einen alternativen SSH-Port. Kann man auch leer lassen
• FILEAGE: Nach wie vielen Tagen/Monaten/Jahren die Inkremente gelöscht werden sollen

Komische Welt bei Microsoft. Einen kleinen russischen Softwaretester mit mutmasslichen Verbindungen zum Geheimdienst schafft man aus. Aber dann gibt man quasi im gleichen Atemzug mal den Sourcecode von Windows 7 an den FSB weiter? Das versteh mal einer.

Ob diese Code-Weitergabe wohl Einfluss auf das künftige nationale Betriebssystem von Russland haben wird? Bislang hatte ich ja eher das Gefühl, dass dies einfach eine weitere Linux-Distribution werden soll. Gut möglich, dass es nun ein "Lindows-Reloaded" wird.

Ich bin ja nun schon mehrfach wie ein Mondkalb angeglotzt worden, weil ich tatsächlich noch richtige CDs kaufe und diese in ein ach so platzverschwendendes Regal stelle. Die Lösung wär doch gemäss meiner Gesprächspartner so einfach: Bei einer der grossen amerikanischen Firmen, deren Namen mit einem A beginnt die Musik zu günstigen Preisen in virtueller Form kaufen.

Nun gut. Das angebissene Obst kommt nicht in Frage, weil man dazu eine Software braucht, die nur und ausschliesslich unter proprietären Betriebssystemen funktioniert. Ausserdem ist deren Format AAC, womit mein alter ogg/mp3-Player definitiv nicht umgehen kann und ich mein aktuelles Smartphone nicht getestet habe.
Aber es gibt ja noch diese weibliche Kriegerin, die ebenfalls ein Download-Angebot hat und dabei sogar (patentbehaftete) mp3s anbietet. Von ihr hab ich neulich ein Mail bekommen, worin ein kostenloser Sampler zum Download angeboten wird. Na in dem Fall probieren wir die Sache doch mal aus! Für Albumdownloads bieten sie eine proprietäre Software an, welche es praktischerweise auch für Linux gibt. Zu den unterstützten Distributionen gehört z.B. Ubuntu 8.10, dessen Name schon andeutet, dass es 2 Jahre alt ist. Na gut, schauen wir doch mal, das das .deb unter Ubuntu 10.04 so macht:
gdebi meint nach Doppelklick in fett rot: "Fehler: Falsche Systemarchitektur »i386«" Oh! Ich hab ja ein 64bit System. Tjaaa, mal die Suchmaschine meines geringsten Misstrauens bemüht und bin sogleich auf eine Anleitung gestossen. Alles klar, ich brauch nur ein dubioses Skript laufen lassen und manuell ein paar veraltete Pakete installieren.

Und siehe da, danach läuft die Sache. Zumindest vorerst. Ob die Software dann auch unter Ubuntu 10.10 oder Debian 6 oder einem aktuellen Gentoo laufen wird, steht in den Sternen. Abgesehen davon, dass so Binärmüll auf meinem System sowieso nur wenig erwünscht ist.

Wie auch immer. Meine CD-Regale hab ich schon vor langer Zeit gekauft. Die Regalwand bietet derzeit auch noch etwasPlatz und wär auch relativ einfach erweiterbar. Daher bleib ich lieber weiterhin dabei, die Musik auf realen Scheiben zu kaufen und danach händisch in Ogg/Vorbis umzuwandeln. Das dauert zwar etwas länger, dafür weiss ich dann auch, was ich hab.

Nachdem ich mir mal wieder einen neuen Hirngrill besorgt hab, wollte ich dessen Daten natürlich bei Gelegenheit wieder auf den PC sichern. Programm der Wahl ist hierfür natürlich opensync. Als Übertragung würde sich zwar Bluetooth anbieten, was in einer theoretisch einfacheren Konfiguration von Opensync enden würde. Jedoch ist mir Bluetooth im Allgemeinen etwas zu fummelig. Daher bin ich ganz froh darüber, dass mein neues Gerät auch über USB synchronisiert werden kann. Das erfordert zwar eine etwas aufwändigere Konfiguration, dafür erhoffe ich mir davon längerfristig einfachere Ausführung des Synchronisationsvorgangs.

Eine ältere aber sehr gute Anleitung für ein anderes, vergleichbares Gerät habe ich ziemlich schnell gefunden. Daher an dieser Stelle nur ein kurzes Update für mein Modell:

Zur Programminstallation gilt eigentlich nur zu sagen, dass Ubuntu in der Geschmacksrichtung "Krüppliger Koala" schon alle Programme in den Standard-Repositories hat, ein einfaches

aptitude install multisync0.90 multisync-tools opensync-plugin-syncml opensyncutils opensync-plugin-file

reicht also schon (ggf noch weitere Plugins nach Bedarf hinzufügen).

Danach musste ich auch wieder eine handgefertige udev-Regel für den Zugriff als eingeschränkten Benutzer anlegen. Dies funktioniert analog zur verlinkten Anleitung, lediglich die Device-ID muss angepasst werden. lsusb meldet folgende Daten:

Bus 001 Device 006: ID 0421:0223 Nokia Mobile Phones

woraus sich folgende Regel ableiten lässt:

BUS=="usb", SYSFS{idVendor}=="0421",SYSFS{idProduct}=="0223",GROUP="plugdev",USER="lukas"

Das neue Upstart-System vom Koala erfordert einen etwas anderen Befehl zum Neustart von udev:

sudo service udev restart

anschliessend sollte das Gerät auch neu angestöpselt werden. Das Handy fragt dann auch nach dem Betriebsmodus, für die Synchronisation hab ich immer "PC Suite" angewählt. Damit funktioniert die Synchronisation problemlos, folglich habe ich auch keinen anderen Modus getestet. Der Befehl syncml-obex-client -u sollte nun genauere Geräteinformationen ausgeben. Nun lassen sich im multysync-GUI oder mit den opensync-Kommandozeilentools die Plugins konfigurieren. Diese sind relativ gut dokumentiert, wodurch sich auch die XML-Konfigurationsdateien sehr einfach den eigenen Bedürfnissen anpassen lassen.

Ich hab mir als neustes Spielzeug ein Shuttle X50 als Mediacenter gekauft. Dabei handelt es sich um ein All-In-One Gerät, sprich einen Bildschirm, worin schon ein komplettes System integriert ist. Als Clou hat das Ding einen Touchscreen. Mein Plan dahinter: Das soll ohne Maus und Tastatur laufen und nur über den Touchscreen gesteuert werden. Die Wahl fiel auf dieses Gerät und nicht den EeeTop, weil der zweiterer nur schlecht verfügbar ist und die schlechtere CPU verbaut hat. Noch bin ich mit der Konfiguration des Geräts nicht komplett fertig, aber hier mal ein kleiner Bericht:

Die Hardware ist ganz passabel für die Medienwiedergabe geeignet. Der Bildschirm hat 15" und 1388x768 Bildpunkte, was dem billigen "HD Ready" entspricht. Als CPU ist ein Zweikern-Atom verbaut, wodurch die Leistung natürlich stark begrenzt ist. 2GB RAM ist mehr als üppig. Die Festplatte mit 160GB ist übergross, da sowieso alle Daten auf dem Server liegen. Aufgrund ihrer mangelhaften Performance werd ich die auch mal gegen eine SSD austauschen, sobald die Dinger erschwinglich werden. Die Festplatte wird auch ordentlich warm, üblicherweise zwischen 48°C und 53°C. Anschlüsse sind ausreichend vorhanden, zumindest 5x USB, Cardreader, Sound (Line Out, Line In, Mic In), Gigabit-Netzwerk, VGA und WLAN ist alles, was ich an so einem Gerät je brauchen werd. Webcam gibt's auch noch, die läuft auch unter Linux. Bluetooth gibt's nicht, wozu auch? Die mickrigen 2W Boxen sind leider viel zu schwach, bei dem Geflüstere kommt keine Stimmung auf. Das Netzteil ist ein Laptop-Netzteil, leider wurde da nur ein Kabel Schuko-Stecker mitgeliefert (der Händler hat wohl das schweizer Kabel vergessen), so dass ich hier erst einen lokalen 3-Pol-Stecker ranschrauben musste.

Das Gerät ist zum Glück frei von Microsoft-Steuer verfügbar, also kann man da grad auf einer jungfräulichen Festplatte ein Linux nach Wahl installieren. Meine erste Wahl fiel auf Debian, womit leider der Touchscreen nicht in Betrieb zu nehmen war. Ein drücken auf den Monitor liess die Maus entweder unkoordiniert rumschwirren (Lenny) oder bewegte gar nichts (Squeeze/Sid). Also hab ich den krüppligen Koala installiert (daher auch in einem der vorhergehenden Beiträgen der Kommentar zur nervigen USB-Startmedien-Erstellung). Derzeit ist die 32Bit-Variante drauf, allerdings ist die CPU tatsächlich 64Bittig, so dass hier noch eine Neuinstallation fällig wird. Mit Ubuntu funktioniert eigentlich alles, nur der Touchscreen von eGalax brauchte nach Installation von xserver-xorg-input-evtouch noch etwas Grob- und Feintuning: Erstens war die X-Achse verkehrt, so dass eine Bewegung von links nach rechts den Mauszeiger von rechts nach links bewegen liess. Und zweitens konnten die äussersten 5cm des Bildschirms nicht erreicht werden. Dafür gibt's ja Kalibrierungstools. Leider funktionieren die überhaupt nicht. Also muss man hier von Hand rangehen. Dazu müssen zunächst allfällige Kalibrierungsinformationen des evtouch-Treibers gelöscht werden, diese sind unter /etc/evtouch/ abgelegt. Anschliessend kann man von Hand anfangen die HAL-Informationen zu erraten. Ja, eigentlich sollte der krüpplige Koala ja HAL durch DeviceKit und udev ersetzen, dennoch läuft noch der HAL-Daemon mit.

Für die HAL-Rekonfiguration sollte die Datei /usr/share/hal/fdi/policy/20thirdparty/50-eGalax.fdi nach /etc/hal/fdi/policy/ kopiert werden, danach bearbeitet man die Kopie in /etc. In einem ersten Schritt müssen nun die Werte für minx und maxx ausgetauscht werden, damit die X-Achse korrigiert ist. Anschliessend kann man die Werte für minx, miny, maxx und maxy so lange anpassen, bis der Touchscreen halbwegs passabel funktioniert. In meinem Fall schauen die betreffenden Zeilen so aus:

<merge key="input.x11_options.minx" type="string">3490</merge>
<merge key="input.x11_options.miny" type="string">750</merge>
<merge key="input.x11_options.maxx" type="string">520</merge>
<merge key="input.x11_options.maxy" type="string">3150</merge>

Damit bin ich vorerst zufrieden, auch wenn ich bei Gelegenheit wohl nochmals daran fummeln werde. In einigen Reviews habe ich gelesen, dass der Touchscreen nervig langsam sei, das kann ich auf jeden Fall nicht bestätigen. Theoretisch würde er wohl auch Multitouch beherrschen (klickt man an zwei unterschiedlichen Stellen, so geht der Cursor in die Mitte davon), allerdings kann der Treiber nicht mal Drag n' Drop, daher kann man da vorerst nur abwarten.

Als Mediacenter sollte da eigentlich auch eine dedizierte Mediacenter-Software drauf. Leider bin ich hier noch nicht fündig geworden. Das Ubuntuusers-Wiki hat zwar eine schöne Auflistung an passender Software, aber überzeugen konnte mich bislang nichts davon. Mediacenter-Software ist üblicherweise auf die Steuerung per Fernbedienung (welche Tastatursignale sendet) ausgelegt. Etwas, das sich nur per Maus-Linksklick bedienen lässt, habe ich so noch nicht gefunden. Lediglich XBMC habe ich allerdings noch nicht testen können, das schmiert bei mir grad ab.

Meine Lösung lautet nun wie folgt: Netbook-Launcher als Starter für Programme und Mediendateien, als Player wird Totem (das Standardprogramm von Gnome) verwendet. Nautilus wurde so konfiguriert, dass Verzeichnisse und Dateien per Singleklick geöffnet werden. Damit ist das System schon ziemlich gut per reinem Linksklick steuerbar. Für input-intensivere Aufgaben kann ich immer noch per SSH oder VNC drauf zugreifen.

Natürlich fehlt für ein vollwertiges Mediacenter noch ein Punkt: Ein Möglichkeit um DVDs abspielen zu können. Diese habe ich leider noch nicht gefunden. Klar, ich könnte mir einfach ein externes Gerät kaufen. Aber das würde einerseits den "ich schlepp nur Monitor und Netzteil"-Gedanken ruinieren, andererseits hab ich ja schon mehrere DVD-Laufwerke in damit vernetzten Geräten verbaut. Also muss irgendwie ein Blockdevice über das Netzwerk transportiert werden. Leider fallen iSCSI, ATA-Over-Ethernet und Network Block Device aus, da diese allesamt nicht mit optischen Laufwerken umgehen können. enbd soll es angeblich können, aber dafür wollen erst mal Kompilierorgien vorgenommen werden (ja, seit Ubuntu bin ich irgendwie schon faul und verwöhnt geworden... Damals unter Gentoo hätt ich bestenfalls mit den Schultern gezuckt.). Den Feinschliff mit der DVD-Wiedergabe tu ich mir folglich ein anderes Mal an.

Mein Favorit unter den Bildbetrachtern ist geeqie, seines Zeichens selbsternannter lightweight Gtk+ based image viewer for Unix like operating systems. Nur: Wenn sich das Ding 200MB RAM krallt um ein 200kb Bild anzuzeigen, ist das nicht mehr unbedingt "lightweight" nach meiner Definition... Ein prima Programm bleibt's aber trotzdem. Na ja, wird wohl mal ein Bugreport fällig