Mplayer nur für den Framebuffer

Die ganzen gestrigen Ausführungen, wie man mit Debian Binärpakete aus dem Quellcode baut, dienten eigentlich nur einem Zweck. Ich wollte K.Mandlas "Mplayer for the framebuffer only" Tipps einmal ausprobieren.
Wie macht man Mplayer noch schneller und ressourcenschonender? Man entschlackt ihn, indem man beim Kompilieren verschiedene Feature deaktiviert. Zum Übersetzen habe ich die gestern vorgestellte pbuilder Methode genutzt.
Ziel war es, die Unterstützung für Videoausgabe ausschließlich auf das Framebuffer Device fbdev zu beschränken. In debian/rules mussten die CONFIGURE_FLAGS und der Code zum Bauen der Mplayer GUI und der nicht grafischen Version angepasst werden.
Welche Optionen es gibt, erfährt man durch ./configure --help. Mit dem Befehl debchange -nmu changelog im debian Verzeichnis des Quellpakets kann das changelog angepasst werden.
Nach jeder Veränderung in debian/rules musste ich das Quellpaket mit dpkg-source -b Name_des_Verzeichnisses neu bauen, damit die gemachten Änderungen von pbuilder auch erkannt wurden. Wer Tipps und Hintergrundinformationen dazu hat und ob es auch andere Möglichkeiten gibt, kann mich gerne darauf stoßen.
Unter den CONFIGURE_FLAGS werden noch verschiedene if-Abfragen ausgeführt. Dabei sollte man vor allem das Bauen der Mplayer GUI Version deaktivieren, wir brauchen nur den Framebuffer, und Mencoder kann auch aus debian/rules verschwinden.

CONFIGURE_FLAGS =
              --prefix=/usr
              --confdir=/etc/mplayer
              --disable-x11
              --enable-xvmc
              --enable-menu
              --disable-arts
              --enable-largefiles
              --language=de
              --disable-libdvdcss-internal
              --disable-dvdread-internal
              --disable-libavutil_a
              --disable-libavcodec_a
              --disable-libavformat_a
              --disable-libpostproc_a
              --disable-libswscale_a
              --disable-openal
              --disable-sdl
              --disable-aa
              --disable-esd
              --disable-jack
              --disable-tv-v4l1
              --disable-tv-v4l2
              --disable-runtime-cpudetection
              --disable-mga
              --disable-smb
              --disable-gui
              --disable-lirc
              --disable-lircc
              --disable-liblzo
              --disable-fribidi
              --disable-libdv
              --disable-musepack
              --disable-speex
              --disable-cdparanoia
              --disable-dvdnav
              --disable-libamr_nb
              --disable-live
              --disable-mad
              --disable-mencoder
              --disable-gl
              --disable-pulse
              --enable-fbdev
              --disable-3dfx

Alles in allem hat das bei mir dazu geführt, dass das mplayer .deb Paket von 3 MB auf 1,7 MB geschrumpft ist. Zum Testen gelangte es dann auf den Toshiba Portégé 3110 CT, wo ich Youtube Videos mit Elinks und Mplayer angeschaut habe.
Auch mit einer angepassten Mplayer Version lassen sich h264 Videos nicht ruckelfrei in Vollbild auf einem PII 300 MHZ 64 MB RAM Laptop anschauen. Dennoch mit einer kleinen Modifikation des youtube-dl Skripts, ließen sich zumindest manche h263 Videos mit niedrigster Auflösung betrachten, wozu ich einfach die Option -f 5 anstelle von -f 34 übergeben habe.
Wichtig sind auch die kleinen Mplayer Tweaks und die Tipps in der MPlayer FAQ.
Zu einem Screenshot mit fbgrab reichte es aber, auch wenn dadurch der Laptop kurzzeitig ausgelastet war.

Gibt man dem alten Rechner eine Chance mit mpeg1/2 Videos und nutzt nicht gerade den CPU lastigen h264 Codec, sieht das Ganze besser aus. Über das Abspielen auf dem zwei Jahre jüngeren Dell Inspiron 4000 brauche ich nicht viele Worte verlieren. Das klappte auch schon vorher problemlos.
Als Fazit lässt sich sagen das selbst maßgeschneiderte Software nicht immer das Unmögliche schaffen kann, aber angesichts des zwölf Jahre alten Laptops noch brauchbare Ergebnisse liefert. Selber Kompilieren ist auf jeden Fall lehrreich. Debians Mplayer Binärpaket ist aber nicht fühlbar schlechter.
Auf jeden Fall gewinnt ihr ein paar Geek Punkte bei dem bleichen Geek von nebenan hinzu und vom Rest gibt es immerhin Augenrollen 🙄 , Kopfschütteln und sanftes Klopfen auf die Schulter.
Das Leben ist nicht immer fair.

Wie man Debian-Pakete aus den Quellen baut

Im folgenden möchte ich ein paar Wege aufzeigen, wie man ein Binärpaket mit Debian erzeugt. Das Ganze ist mehr als Merkzettel zu verstehen und ersetzt nicht die offizielle Dokumentation zur Erstellung von Binärpaketen mit Debian. Am Ende finden sich nützliche Links für alle, die sich mehr mit den technischen Details beschäftigen möchten. Außerdem finden sich dort auch Links zu Videos, die den Prozess ausführlich und nachvollziehbar erklären.
Die folgende Übersicht ist in Teilen eine Übersetzung des englischen Howto "How to build a package from source the smart way".

Der bessere Weg - Debianisierte Quellen kompilieren

Der allgemeine Weg ein Binärpaket aus den Quellpaketen zu erstellen läuft immer so ab:

  1. Zuerst muss der Paketmanager wissen, woher er die Quelldateien beziehen soll, wozu die Datei /etc/apt/sources.list modifiziert wird.
  2. Dann wird das Quellpaket als normaler Nutzer heruntergeladen.
  3. Dann wird dpkg-buildpackage ausgeführt, um ein .deb Paket zu erstellen.
  4. Und schließlich wird dpkg -i benutzt, um das .deb Paket zu installieren.

1. Folgende Zeile in die /etc/apt/sources.list eintragen, sofern man sid installiert hat.

deb-src http://ftp.de.debian.org/debian/ sid main

2. Die Paketabhängigkeiten zum erfolgreichen Kompilieren als root installieren

aptitude update
aptitude install build-essential fakeroot devscripts
aptitude build-dep Paketname

3. Quellen herunterladen und Binärpakete bauen (alle weiteren Befehle als normaler Nutzer ausführen)

mkdir /home/XXXX/tmp/
cd /home/XXXX/tmp/
apt-get source Paketname
cd Paketname-version/

Nun kann die Datei debian/rules oder weitere debianspezifische Dateien wie debian/control oder debain/changelog angepasst werden. Ein wichtiges Programm hierfür ist debchange welches sich im Paket devscripts befindet.
Nach der Konfiguration wird das .deb Paket erstellt.

dpkg-buildpackage -rfakeroot -us -uc

Mit -us -uc überspringt man den Schritt, bei dem üblicherweise Debian Pakete vom Paketersteller signiert werden.
4. Installieren

cd /home/XXXX/tmp/
dpkg -i Paketname_Version_Architektur.deb

Nicht debianisierte Quellpakete kompilieren

Obwohl Debian ein riesiges Paketarchiv hat, kann es vorkommen, dass es zu einem Paket noch keine angepasste Debianversion gibt. Hierzu muss also das Original-Tarball mit den Quellen von der Projektseite heruntergeladen werden und anschließend mit dem Debianprogramm dh_make in eine debianisierte Version umgewandelt werden. Die Abhängigkeiten des Pakets müssen dann manuell mit apt installiert werden.

aptitude install dh-make

Als normaler Nutzer wieder:

mkdir /home/XXXX/tmp/
cd /home/XXXX/tmp/
tar -xvf Paketname_Version.tar.gz
mv Paketname_Version/ paketname-version/
mv Paketname_Version.tar.gz paketname_version.orig.tar.gz

Die Benennung des Pakets und die Unterstriche sind wichtig, damit sie Debians Konventionen entsprechen. Anderenfalls wird dh_make eine Fehlermeldung ausgeben. Danach in das entpackte Verzeichnis wechseln und dh_make ausführen.

dh_make

dh_make wird eine Reihe von Fragen stellen und schließlich müssen die Felder für den Paketbetreuer ausgefüllt werden. (das was man mit aptitude show zu sehen bekommt)
Nachdem dies erledigt ist

dpkg-buildpackage -rfakeroot -us -uc
dpkg -i paketname_version_architektur.deb

Chroot Umgebung und pbuilder

Am besten führt man alle Schritte zum Kompilieren in einer speziellen chroot Umgebung durch, die vom restlichen System getrennt ist und die sich später sehr leicht auch wieder entfernen lässt. Ein weiterer wichtiger Vorteil ist, dass Pakete, die in dieser Umgebung richtig gebaut werden, auch auf anderen Rechnern erfolgreich übersetzt werden können. Der Prozess wird dadurch reproduzierbar.
Ich benutze entweder die debootstrap Methode oder das Programm pbuilder.
1. Pbuilder installieren

aptitude install pbuilder

2. Chroot Umgebung erstellen

pbuilder create --distribution squeeze

Standardmäßig wird ein auf sid basierendes chroot Image erstellt. Die Option --distribution ändert das.
3. Pbuilder aktualisieren

pbuilder update

Falls man längere Zeit nichts mehr kompiliert hat, sollte die chroot Umgebung aktualisiert werden.
4. Quellpaket herunterladen

apt-get source Paket

5. In das Quellverzeichnis wechseln und debianisiertes Quellpaket in chroot Umgebung bauen

pbuilder build Paket_Version.dsc

Die fertigen Binärpakete befinden sich danach in /var/cache/pbuilder/result.

Der herkömmliche Weg - autoconf und automake

In den meisten Quellpaketen befindet sich ein sogenanntes configure Skript, welches automatisch von dem GNU Programm autoconf generiert wird. In der Regel muss man in das Quellverzeichnis wechseln und folgende Befehle ausführen, um ein Binärpaket zu erstellen. Zuvor müssen Abhängigkeiten manuell oder mit aptitude build-dep installiert werden.
Als Ziel für die Installation wird /usr/local gewählt, /opt ist ebenfalls eine gute Alternative.

./configure --prefix=/usr/local --beliebige Optionen zur Konfiguration

Danach genügt es mit make die Quellen zu übersetzen und mit make install die Binärpakete in das gewählte Zielverzeichnis zu installieren.

make
make install

Für Debian ist es dabei besser make install durch checkinstall zu ersetzen. Checkinstall erstellt ein .deb Paket und merkt sich wohin die Pakete installiert werden. Der Nachteil ist, dass es weder die Quelldateien debianisiert noch Paketabhängigkeiten berücksichtigen kann.

su -c "checkinstall -D make install"

Ein Beispiel für diese Methode war meine Dillo2 Kompilierung auf dem Toshiba Portege.

Links

Basics of the Debian package management system
Debian New Maintainers' Guide
Ubuntu - Packaging Guide Complete
Videos von der MiniDebConf 2010 in Berlin in Deutsch
Die .ogv Dateien zu Packaging und Advanced Packaging zeigen einen Vortrag zum Thema Paketerstellung mit Debian.
Nach der Lektüre und den Videos sollte man in der Thematik fit sein. 😉

Solarized: Massage für die geplagten Augen

Ab und an bin ich auf der Suche nach einer neuen Idee um das Terminal ein wenig zu verändern. Diese Woche bin ich an einer interessanten Farbpalette namens Solarized hängen geblieben. Ethan Schoonover hat ein, wie ich finde, elegantes Thema gefunden, welches unter anderem die Farbgestaltung diverser Terminalemulatoren und die Syntaxhervorhebung von Editoren optimiert.

Farben in Vim ändern

Als Farbschema in Vim habe ich z.B. bis vor kurzem desert genutzt und nun erst einmal auf Solarized umgestellt. Das Thema schafft es mit geringem Kontrast sowohl auf dunklem als auch auf hellem Hintergrund zu überzeugen.
Die Installation war nicht besonders schwer.

  1. Auf der Homepage von Ethan Schoonover die gezippte Datei solarized.zip herunterladen.
  2. Im Ordner vim-colors-solarized die Datei solarized.vim nach ~/.vim/colors kopieren.
  3. ~/.vimrc editieren:

    syntax enable
    set background=dark
    colorscheme solarized

Für einen hellen Hintergrund das dark einfach durch light ersetzen. Es gibt noch ein paar optionale Einstellungen, die aber gut dokumentiert sind.

Farbpalette in rxvt-unicode auf solarized anpassen

Normalerweise stelle ich keine großen Anforderungen an einen Terminalemulator (na gut vielleicht ein paar ;)), außer dass er schnell reagieren muss, wenig Ressourcen verbraucht und flexibel anpassbar ist. Hier kommt dann rxvt-unicode oder kurz urxvt ins Spiel.
Im Solarized-Ordner Xresources müssen die dort stehenden Farbwerte entweder in die Datei Xresources oder in die Xdefaults im Home Verzeichnis kopiert werden.
Nach diesen Schritten sieht eine Python Datei in Vim nun so aus.

dircolors in urxvt anpassen

Die Farben der Verzeichnisse und Dateien sahen mit dem GNU Befehl ls noch nicht "solarized" aus. Dank huyz git repository und ausführlicher Anleitung hat sich mein Terminal nun von den Standardfarben weiterentwickelt.
Aus einem nicht nachvollziehbaren Grund konnte ich die 256 Farben Version nicht nutzen (*hust* hier steht warum), obwohl die TERM Variable auf "rxvt-unicode-256color" gesetzt worden war. Die Farben waren komplett falsch. Das ANSI-Universal Thema hingegen funktionierte.

    1. Die entsprechende Datei bei seebi oder huyz git repository herunterladen.
    2. Die Datei dircolors.ansi-universal kann z.B nach ~/.dir_colors kopiert werden.
    3. Den Befehl eval `dircolors $HOME/.dir_colors` in die Datei ~/.profile einfügen.

Dann den Terminal neustarten und man sollte ähnliche (leider keine 256 Farben) Terminal-Screenshots wie bei huyz sehen.

Fazit

Solarized gefällt mir zur Zeit ziemlich gut. Die Vim-Konfiguration ist sehr angenehm für die Augen und verschiedene Syntax wird deutlich hervorgehoben. Einzelne Konsolenanwendungen funktionieren aber noch nicht perfekt mit meiner momentanen Konfiguration und solarized. So gibt es bei manchen Htop-Themen auch mal gar nichts zu lesen auf Grund unpassender Kontraste zwischen verschiedenen Schriftfarben. Da Solarized noch im Beta Stadium ist kann ich nicht 100% sagen, ob es an dem Thema liegt oder falscher Einstellungen meinerseits. Wahrscheinlich eher letzteres.
Tiefergehende Diskussionen zu diesem Thema gibt es auch hier. Als Erinnerung für mich: Um die Terminus Schriftart unter Debian für urxvt einzurichten muss das Paket xfonts-terminus installiert werden und in der .Xdefaults folgender Eintrag stehen:

urxvt*font: xft:Terminus:pixelsize=14

Anonymität im Netz mit Tails

Anonymität, Vertrauen und Sicherheit: Wörter, die immer wieder Emotionen im Zusammenhang mit dem Internet hervorrufen. Ich möchte auf SSH, https oder GnuPG nicht mehr verzichten, wobei letzteres nicht nur Dropbox sicherer macht.
Auf der anderen Seite gibt es aber auch übertriebene Reaktionen, wenn in Zusammenhang mit jedem neuen Internetangebot gleich das Ende der informationellen Selbstbestimmung und des Datenschutzes herbeigeredet wird.
Ich habe kein Problem damit, dass Suchbegriffe gespeichert und analysiert werden, damit informativere Seiteninhalte generiert werden und man einen besseren Überblick darüber erhält, was die Leute eigentlich interessiert und was nicht - solange dies anonym geschieht.
Das Problem ist die Verknüpfung der IP des Nutzers mit diesen Informationen, die für das obige Beispiel irrelevant sind, mit dem sich aber leicht persönliche Profile anlegen und letztendlich auch über den ISP zurückverfolgen lassen.
Am anderen Ende wird die Ansicht vertreten, dass man als anständiger Bürger nichts im Internet zu befürchten habe. Leider schert das den "Mann in der Mitte" oder etwas wie Echelon wenig. Unverschlüsselte Daten können mit entsprechendem technischen Know-How und Aufwand immer und überall eingesehen werden.
Jeder würde sofort Sturm laufen, wenn die Post jeden Brief öffnen und kopieren würde, doch niemand stört sich daran, dass jede Email offen einsehbar verschickt wird.
Was kann man also tun? Auf jeden Fall ein gesundes Maß an Misstrauen entwickeln, ohne dabei in Hysterie zu geraten, in die manche Medien gerne verfallen. Gerade zur Thematik von Anonymität und Sicherheit im Netz gibt es spezielle Linuxdistributionen, die sich mit dem Thema beschäftigen.
Eine davon heißt Tails, The Amnesic Incognito Live System, welches auf Debians Live-Projekt basiert. Tails bringt einem vor allem das Tor Netzwerk näher, mit dem es möglich ist anonym im Internet zu surfen und i2p. Während i2p ein Projekt ist, welches versucht ein komplett anonymes und sicheres Netzwerk zu erschaffen, welches unabhängig vom heutigen Internet ist, konzentriert sich Tor darauf Anonymität im Internet zu erzeugen, indem Informationen zwischen Client und Server durch das Tor-Netzwerk geleitet werden und dadurch am Ende nicht mehr feststellbar ist, wer der ursprüngliche Absender war.

Tails lässt sich als Live-CD, per USB oder in Virtualbox ausprobieren. Nach dem Einloggen startet sofort Iceweasel (Firefox) mit dem installierten Addon Torbutton, mit dem das Aktivieren von Tor ein 1-Klick-Erlebnis ist.
Anwendungen in Tails sind schon so konfiguriert, dass Daten durch das Tor Netzwerk geleitet werden. So lässt sich zum Beispiel anonym im IRC mit Pidgin chatten. Sowohl die Tor als auch Tails Webseite weisen darauf hin, dass es keine perfekte Anonymität gibt und vieles davon abhängt, welche Anwendungen man nutzt bzw. besser nicht nutzen sollte.
Zum Sensibilisieren für das Thema Sicherheit und Anonymität im Internet und als Denkanstoß, ist Tails auf jeden Fall einen Blick wert.

CrunchBang + ArchLinux = ArchBang

Es ist ArchBang Zeit. Als ich meine Liste zum Ausprobieren von leichtgewichtigen Distributionen schrieb, bezeichnete ich noch Crunchbang als "das andere Bang". Wer war nun zuerst da? Archbang versteht sich selbst als Archlinux Derivat, welches dem Nutzer die Mühe abnimmt, Pakete für den Openbox Desktop selbst zu installieren und zu konfigurieren.
Archbang hat kaum eigene Dokumentation zu bieten und deshalb verwundert es auch nicht, dass neue Nutzer schnell an das herausragende Wiki von Archlinux verwiesen werden.
Ohne Umschweife, ist Archbang ein anderes Archlinux oder gar eine besondere neue Distribution? Nein.
Kurz zusammengefasst lässt sich der archtypische Installationsprozess durch Archbang ein wenig abkürzen, Paketquellen und Pakete müssen logischerweise nicht ausgewählt werden. Der Rest ist vollkommen identisch zur gewohnten Textinstallation.
Wenn man wie ich vor kurzem einen längeren Blick auf CrunchBang Linux werfen konnte, fallen sofort die frappierenden Ähnlichkeiten auf. Schwarz gehaltenes Desktopthema, Openbox mit einem nur in wenigen Punkten abgeänderten Rechtsklick-Menü und eine Konfiguration, die in vielen Punkten Crunchbang mehr als ähnlich ist.
Unterschiede in der Auswahl der vorinstallierten Anwendungen sind ebenfalls nur gering. Größte Auffälligkeiten sind MPlayer anstelle von VLC, das LXTerminal, geeqie als Bildbetrachter und das umfangreiche GIMP im Gegensatz zu dem auf einfache Grafikaufgaben beschränkten, aber dadurch auch schnelleren, MTPaint.


Natürlich ist das alles kein Zufall sondern auch ein wichtiger Bestandteil von Open Source. Mittlerweile gibt es vier Hauptentwickler des Projekts und irgendwann muss wohl dem Projektleiter und Initiator Crunchbang Linux so gut gefallen haben, weshalb er kurzerhand das ganze Konzept auf seine Lieblingsdistro Archlinux angewendet hat.
Im Gegensatz zu Crunchbang, welches auf das stabile Debian Squeeze setzt, hat Archbang sich die Vorteile einer rollenden Distribution wie Archlinux zu eigen gemacht. Einmal installiert und man erhält fortlaufend immer die neusten Versionen der Programme.
Wie halte ich es nun mit Archbang? Ich denke, wenn man eher zu Archlinux neigt und eine vorgefertigte, leichtgewichtige Distribution auf Basis von Openbox und Archlinux sucht, dann ist Archbang genau das Richtige. Da Archlinux-Nutzer sowieso zu den "Tu-es-selbst"-Kandidaten gehören, werden die sich auch kaum an der fehlenden Dokumentation stören und sich gleich am umfangreichen Fundus des Mutterprojekts bedienen.
Ist man mit Debian zufrieden, fällt es sicher leichter sich für Crunchbang zu entscheiden, wobei um das Projekt herum schon eine sehr aktive Gemeinschaft entstanden ist. Die Dokumentation ist zwar nicht perfekt, aber doch deutlich besser als bei Archbang. Persönlich neige ich mehr zu Crunchbang, nicht nur weil ich Debian favorisiere, sondern weil ich auch denke, dass Ruhm und Ehre für eine hervorragend konfigurierte Openbox-Distribution bei Crunchbang liegen sollte.
Beide Distributionen sind gleichermaßen geeignet, wenn man ein ressourcenschonendes Betriebssystem sucht. Am Ende ist die Frage scheinbar wirklich nur: Arch oder Debian?

dict: Babylonisches Sprachwirrwarr gelöst

Was müssen das für Zeiten gewesen sein als man noch Bücher und Zeitschriften bemühen musste, um etwas über eine fremde Sprache zu lernen. Klobige, Kilogramm schwere Wälzer angefüllt mit Wissen von A-Z. Damals im letzten Jahrtausend, im fernen Mittelalter, irgendwann Mitte der 1990iger Jahre.
Doch dann wurde das tragbare Telefon erfunden und wurde irgendwann so klein, dass man keinen Koffer mehr zum Transport benötigte. Wörterbücher in praktischen Miniausgaben, maßgeschneidert für den Urlaub und unterwegs, waren lange Zeit nicht aus dem Handgepäck wegzudenken. Bis, ja bis das Zeitalter der Killerääps Einzug hielt und die Frage "Wie löse ich das Problem?" durch "Gibt es dafür ein App?" ersetzt wurde.
Zum Glück gibt es noch andere Möglichkeiten ohne Smartphone zu überleben.
Man nehme die Linuxdistribution der Wahl, installiere den Wörterbuch Client dict oder ding und schon lässt sich direkt aus einem Terminalfenster z.B. nach Englisch-Deutschen Übersetzungen suchen.

aptitude install dict dictd dict-de-en

Anschließend reicht ein dict Geek um Schockierendes herauszufinden. 😯
Natürlich gibt es auch noch dict.cc, freedict.org und leo.org , welche direkt über den Browser oder wie bei leo.org auch über Browseraddons zu erreichen sind.
Dict und Ding sind nicht wirklich neu. Doch manchmal kann man schnell vergessen, dass das zu einer Zeit schon funktionierte als Handynutzer in Schwimmbädern noch merkwürdig bestaunt wurden. Und ja das funktioniert auch heute noch auf Hardware aus der gleichen Zeit. 🙂
Noch mehr Wörterbücher für Linux.

Lubuntu 11.04 sparsam und trotzdem komfortabel

Alle sprechen über Ubuntu 11.04 und Unity, doch die Ubuntuwelt hat noch weitere interessante Ableger zu bieten. Lubuntu bemüht sich seit längerer Zeit als offizielles Ubuntu Derivat neben Kubuntu, Xubuntu und Ubuntustudio anerkannt zu werden.
Lubuntu setzt dabei auf die namensgebende LXDE Desktopumgebung, deren erklärtes Ziel es ist, einen ressourcensparenden Desktop zu erschaffen. Damit sind gleichermaßen geringer Speicherverbrauch und reaktionsfreudigere Programme als auch stromsparend und umweltfreundlich gemeint.
Deswegen hat Compiz und natürlich auch Unity keine Chance bei Lubuntu, was es auch einfacher macht die Distribution z.B. in Virtualbox auszuprobieren.

Lubuntu bietet für mich die gleichen Komfortanwendungen, die ich auch von Ubuntu gewohnt bin. Um das Installieren von notwendigen, aber leider unfreien Treibern zu vereinfachen, kommt wie gewohnt Jockey zum Einsatz.
Als Büroanwendungen sind Gnumeric und Abiword vorinstalliert, die zwar weniger umfangreich als die bekannte LibreOffice Suite sind, dafür sich in Sachen Geschwindigkeit besser schlagen und für allgemeine Aufgaben wie Briefe schreiben und Tabellenkalkulationen vollkommen ausreichend sind.
Zum Surfen ist Chromium vorinstalliert, Sylpheed für Emails, welches ich genau wie den Fork Claws-Mail empfehlen kann und dann wäre da noch Pidgin und Xchat zum Chatten. Mit Mplayer lassen sich alle Formate dieser Erde abspielen, Audacious zum Musikabspielen ist auch keine schlechte Wahl, wobei ich hier natürlich gerne cmus gesehen hätte. 😉
Drucken, CD/DVD Brennen, Notizen verfassen, Bilder bearbeiten Lubuntu bietet alle Voreinstellungen, die man auch aus Ubuntu kennt, nur mit dem Unterschied, dass es sich um andere Namen und leichtgewichtige Software handelt. Als Dateimanager ist PCManFM installiert, der ebenso wie Thunar zu den populären Alternativen zählt, wenn man reaktionsfreudige Anwendungen bevorzugt.
Als Fenstermanger setzt LXDE Openbox ein. Leider nutzt Lubuntu in der Voreinstellung nicht das Rechtsklickmenü von Openbox und lässt PCManFM den Desktop übernehmen. Für Ubuntuumsteiger ist das Verhalten dadurch zwar intuitiver, ein perfekt konfiguriertes Menü wie bei Crunchbang vermisste ich dadurch aber.
Lubuntu wirkt durch das LXPanel und durch die Desktopeinstellungen zwar traditionell, was durchaus aber auch Vorteile haben kann. Die Umgewöhnung dürfte für Ubuntunutzer eher gering sein, wodurch die Eingewöhnungsphase sich in Grenzen hält.
Ich denke Lubuntu kombiniert das Positive aus zwei Welten. Ubuntus komfortable Voreinstellungen und die Vorteile leichtgewichtiger Software für ältere Rechner, aber auch modernen Netbooks und Desktop PCs, die ihre Rechenzeit für wichtigere Aufgaben als den Compositing Manager benötigen.
Lubuntu 11.04 ist auf Grund der vorinstallierten Dienste und Anwendungen nicht ganz so ressourcensparend wie andere Debian Openbox Derivate oder eine selbst konfigurierte Debian Netzinstallation. Dafür lässt es sich bequem als Live CD ausprobieren und später installieren und bringt alles mit, was man auch von Ubuntu gewohnt ist.
Mit der nächsten Veröffentlichung von Ubuntu 11.10 soll Lubuntu auch endlich offiziell zur Familie gehören. Gute Entscheidung, es wurde Zeit. Wieder ein Haken auf der Liste. 😉

Wine einmal selbst kompilieren

Ungewöhnliche Probleme erfordern ungewöhnliche Maßnahmen...oder so ähnlich. Der Bug mit den Zeratul-Missionen bei Starcraft II beschäftigte mich seit einer Weile, weswegen ich noch einmal im Netz nachschaute, ob jemand nicht doch mit den gleichen Problemen zu kämpfen hatte.
In der Wine-Anwendungsdatenbank stieß ich dann endlich auf einen Kommentar, der exakt das gleiche Problem beschrieb. Ich erinnerte mich wieder daran, dass ich schon erfolgreich die ersten beiden Zeratul-Missionen mit Wine 1.2 gespielt hatte. Vielleicht half hier ja ein Versionswechsel?
In Sachen Wine hinkt Debian aus mir unbekannten Gründen mit der aktuellen Version weit hinterher. (Debian Sid z.Z. 1.1.42). Damit lässt sich zwar auch Starcraft 2 spielen, das Zeratul Problem bleibt aber bestehen. Als Alternative gibt es aber auf der WineHQ-Seite zumindest die Möglichkeit die aktuellen Entwicklungsversionen des Wine 1.3 Zweiges als vorgefertigte .deb Pakete herunterzuladen, die mir aber auch nicht weiterhelfen konnten.
Alles in allem blieb nur die Möglichkeit Wine aus den Quellen selbst zu kompilieren. Ich schaute zuerst nach, welchen Weg die Entwickler vorschlugen und installierte danach zuerst einmal die für die Kompilierung notwendigen Pakete.
Welcher Weg der Sinnvollste zur Kompilierung eines Debian Binärpakets ist, scheint wirklich davon abzuhängen, welche Webseite man gerade liest. Interessanterweise konnte man praktisch überall etwas anderes lesen. Zur eigenen Dokumentation gehe ich später noch einmal auf die verschiedenen Optionen ein. Prinzipiell bietet Debian viele Werkzeuge an, die den Prozess stark vereinfachen und für alle, die öfter Pakete mit Debian erstellen, mit Sicherheit auch der beste Weg sind.
Hier ist nun aber der althergebrachte Weg mit Linux ein Quellpaket zu übersetzen und der auch vom Wine-Wiki vorgeschlagen wird. Zum Ausprobieren habe ich mir erneut eine minimale chroot Umgebung mit debootstrap erstellt.

  1. Quellpakete herunterladen z.B. auf der offiziellen Sourceforge Seite von Wine oder hier.
  2. Abhängigkeiten installieren

    apt-get build-dep wine

    oder indem die oben erwähnten Pakete manuell mit apt installiert werden.

  3. Quellpaket entpacken z.B. in ~/tmp mit

    tar -xvf wine-1.2.tar.bz2

  4. Kompilieren: In das neue Wine-Verzeichnis in ~/tmp wechseln und

    ./configure
    make

    ausführen.

Wine lässt sich dann direkt aus dieser Umgebung benutzen oder danach auch mit dem Kommando make install in den Pfad des Nutzers installieren.
Sollten Probleme beim Ausführen von ./configure auftreten, fehlen einige Pakete als Abhängigkeiten, die manuell nachinstalliert werden müssen. Das war es im Prinzip schon. War das Ganze nun ein Erfolg?
Ich konnte danach Starcraft II zwar starten und benutzen. Das Spiel stürzte trotzdem nach Klick auf den Kristall im Labor ab, mit dem die Zeratul Missionen gestartet werden. Auch eine weitere Wine Version 1.2.1. brachte das gleiche Ergebnis. 🙁
Das Problem scheint also woanders zu liegen. In Sachen Kompilierung ist die oben beschriebene Methode praktisch auf jeder Linuxdistribution zu verwenden, ist aber gerade bei Debian eine etwas "unsaubere" Lösung, da der Paketmanager und die von Debian zur Verfügung gestellten Werkzeuge nicht zum Einsatz kommen. Mehr Möglichkeiten zum Erstellen von Binärpaketen mit Debian habe ich hier beschrieben. 🙂

Ein minimales Debian für Spiele

Es ist nicht schwer ein minimales Debian zu erstellen, dessen einziger Zweck Spiele sind. Ich hatte eine Zeit lang überlegt, ob ich nicht direkt auf das vor kurzem vorgestellte Crunchbang Linux zurückgreifen sollte, welches auf Debian Stable mit Openbox aufbaut.
Stable schien zwar verlockend, hat aber auch den Nachteil nicht die aktuellsten Treiber für meine Nvidia Karte und den neusten Xorg Server und Linuxkernel mitzuliefern. Natürlich gab es noch die Möglichkeit mit Hilfe von Debians Backports die Lücke zu schließen, aber ich hatte das Gefühl, dass das System hier an seine Grenzen stieß und ich mehr eine "experimentellere" Umgebung zum Testen der Spieleumgebung suchte.
Hier sind einige Punkte, die man berücksichtigen sollte, wenn man ein minimales, performantes und hochaktuelles Spielesystem auf Basis der Debian Distribution nutzen möchte.
1. Debians Netzinstallation: Eine Netzinstallation, bei der keine zusätzliche Pakete mit Tasksel installiert werden, ist genau richtig. Nach der Installation müssen in der /etc/apt/sources.list die Paketquellen von Squeeze auf Sid umgestellt werden.
2. Minimale grafische Desktopumgebung: aptitude install xorg alsa-base openbox
Die Wahl des Fenstermanagers ist Geschmackssache. Mit Openbox kann man nicht viel falsch machen.
3. X ohne Loginmanager starten: Bei Schritt zwei ist es natürlich möglich einen Loginmanager wie gdm oder slim zu installieren. Auf diese zusätzliche Last lässt sich mit dieser Lösung verzichten.
4. Openbox konfigurieren: Crunchbang Linux hat Openbox ausgezeichnet konfiguriert, weswegen ich Ideen von Crunchbang und eine eigene Konfiguration kombiniert habe.
Zusätzlich sollte das Paket menu installiert werden, welches automatisch ein zusätzliches Menü generiert. Besonders nützlich ist das bei Wine oder Crossover Games. Damit das reibungslos funktioniert sind die Pakete xdg-utils und ggf. xdg-user-dirs nützlich. Weitere Informationen gibt es auch im Openbox Wiki.
5. Desktop gestalten: Tint2 und Conky runden den Desktop wunderbar ab und lassen sich umfangreich konfigurieren. Um Zeit zu sparen habe ich auch hier nur eine leicht abgewandelte Version von Crunchbang eingesetzt. Zum Einrichten des Hintergrundbildes bleibe ich bei feh.
6. Schriften installieren: aptitude install ttf-sazanami-gothic ttf-dejavu ttf-bitstream-vera
7. Zusatzprogramme:
Dateimanager: Midnight Commander oder einfach nur die coreutils
Texteditor: Vim 😉
Browser: Iceweasel und/oder elinks
Terminal: rxvt-unicode
SSH: Gehört für mich bei jedem System dazu
8. Nvidia Treiber: Einfach "The Debian Way" installieren.

Ergebnis

64 MB RAM Auslastung nach einem Neustart, kein unnötiger Ballast, nur das Notwendigste zum Spielen. 🙂


Download: openbox_tint2_conky_config.tar

Crossover Games: Steam und Starcraft II

Eher durch Zufall schaute ich am 15. Mai, zwecks Vorstellung einiger Spieleseiten für Linux, wieder einmal bei Codeweavers vorbei, die ja bekanntlich 50 % des Codes zu Wine beisteuern.
Gerade an diesem Tag feierte das Unternehmen seinen 15. Geburtstag und hatte das Crossover Bundle für einen Sonderpreis im Angebot.
Ich konnte nicht widerstehen und wollte vor allem das darin enthaltene Crossover Games einmal ausprobieren. Im Prinzip handelt es sich hier um ein modifiziertes Wine, was vor allem die Installation und Deinstallation vereinfachen und die Integration in den Desktop verbessern soll.
Sehr angenehm war das vorgefertigte .deb Paket, welches sich mit dpkg -i schnell installieren ließ. Bevor man sich überhaupt zum Kauf entscheiden muss, bietet Codeweavers eine einwöchige Probephase mit dem Programm an, in der alle Fähigkeiten der späteren Vollversion ausprobiert werden können.
Erst nach dem Kennenlernen muss das Produkt aktiviert werden, wozu es nach dem Kauf genügt Emailadresse und Passwort für den bei Codeweavers hinterlegten Account anzugeben.
Nach der Installation erscheint ein neues Menü für die Software von Codeweavers, aus welchem sich heraus das spezielle Setupprogramm zur Installation von Windowsspielen aufrufen lässt.
Auffallendstes Merkmal dabei sind die sogenannten Flaschen, mit denen sich eine Softwareinstallation sauber trennen lässt. Für ein und dasselbe Spiel lassen sich so verschiedene Konfigurationen definieren.
Crossover Games unterscheidet zwischen offiziell durch Codeweavers unterstützten und von der Wine-Community betreuten Spielen. Die offiziellen Spiele erhalten vollen Support durch den Kundendienst des Unternehmens und stehen im Fokus der kontinuierlichen Verbesserung des kommerziellen Produkts, womit schließlich auch auch dem Open-Source-Programm Wine entscheidend geholfen wird.


Ich installierte zum Test Steam und Starcraft II. Ersteres war eine "One-Click" Erfahrung. Steam im Menü auswählen, installieren klicken, der Rest funktioniert automatisch. Kein Herumschlagen mit winetricks oder Suche nach dem passenden Installations-HowTo. Es klappte einfach.
Bei Starcraft II musste ich wie schon bei der reinen Wine Installation die DVD manuell mounten, damit die versteckten Verzeichnisse sichtbar wurden. Crossover weist einen aber auf den richtigen Befehl hin.
Danach kam die Installation nicht in Gang und erst nachdem ich die komplette DVD wieder in ein Verzeichnis auf die Festplatte kopiert hatte, klappte es schließlich.
Sollte der lange dauernde Updateprozess zwischenzeitlich abbrechen, genügt es den Starcraft II Prozess zu killen und Crossover neuzustarten.
Im Vergleich zu meiner ersten Installation mit Wine und Ubuntu 10.04 fiel mir noch auf, dass das Intro während der Installation erfreulicherweise weiterlief.
Die Performance von Starcraft II ist besser, was aber mehrere Ursachen hat. Zum Ausprobieren habe ich Debian Sid (32 bit) in einer Minimalinstallation installiert. Außer Openbox, Alsa, kleineren Hilfsprogrammen, dem brandneuen 2.6.39 Kernel und den aktuellen Nvidia Treibern, gibt es nichts, was das System herunterziehen könnte.
Die Startzeit von Starcraft II ist besser geworden und die knackenden Geräusche im Ladebildschirm sind ebenfalls verschwunden, was vermutlich am fehlenden Pulseaudio liegen dürfte.
Da Compiz nun ebenfalls fehlt, lässt sich damit auch die leichte Verbesserung bei den Frames erklären. Nach wie vor habe ich aber zwei spezielle Probleme, die mir erst nach Installation von Wine 1.3 aufgefallen sind.
Die Zeratul-Missionen lassen sich nicht mehr spielen. Starcraft 2 mit Crossover oder Wine stürzt hier wiederholbar ab. Ich scheine aber der Einzige zu sein, der mit diesem Problem zu kämpfen hat. 🙁
Das zweite ist der bekannte Haven-Bug, bei dem eine Haven Mission durch den "Nebel des Krieges" unspielbar wird.
Zusammenfassend heißt das: Crossover ist eine deutlich benutzerfreundlichere Version von Wine, mit der sich Spiele sauber verwalten lassen. Alle Bugs kann aber auch diese kommerzielle Wine Version nicht beheben.
Mit dem Kauf der Software erhält man übrigens Punkte, mit denen man die Weiterentwicklung von Wine und der Crossover Produkte steuern kann.
Umso mehr Punkte ein Windowsprogramm erhält, desto mehr konzentrieren sich die Entwickler darauf das Fehler beseitigt werden und wissen somit auch, wo die Prioritäten der Wine-Anwender liegen.
Ich denke, wenn man nicht gerade selbst Unmengen Code zum Wine Projekt beisteuert, ist die Kaufversion von Codeweavers ein guter Weg das Projekt zu unterstützen.