Zu meiner Openbox-Einführung habe ich das Lxpanel als Standardpanel empfohlen, da es für mich dem klassischen Design am nächsten kommt und die Eingewöhnungsphase kurz ist.
Auf der anderen Seite ist Tint2 eine ebenso gute, wenn nicht sogar bessere, Option. Tint2 sticht insbesondere durch geringen Speicherverbrauch und wenige Abhängigkeiten mit anderen Paketen hervor.
Das Aussehen ist elegant und unkompliziert. In der Voreinstellung des vorgestellten Crunchbang Linux befindet sich das Panel z.B. am unteren Bildschirmrand. Geöffnete Anwendungen werden direkt auf den virtuellen Arbeitsflächen angezeigt, die das Panel aufteilen. Rechts davon befinden sich die "Tray Icons" laufender Programme und daneben dann die Uhr.
Positionierung, Farbgestaltung, Größe und das gesamte Aussehen lassen sich über eine einzige Konfigurationsdatei manipulieren, die ~/.config/tint2/tint2rc. Die Dokumentation ist gut und die letzten Fragen werden durch die FAQ beantwortet.
Mit Tint2 wird ein kleines grafisches Installationsprogramm namens tint2conf für das Einrichten der .tint2rc mitgeliefert. Beispiele finden sich bei Debian in /usr/share/doc/tint2/examples oder direkt auf der Entwicklerseite zum Download.
Ein paar Beispiele:
Mit tint2conf nimmt man schnell die erste Hürde beim Ausprobieren. Genug Beispiele finden sich überall im Netz z.B. auch im Crunchbang Forum.
Tint2 wurde zwar für Openbox 3 entwickelt, lässt sich aber auch mit anderen Fenstermanagern kombinieren. In Openbox genügt lediglich der Eintrag tint2 & in die ~/.config/openbox/autostart.sh.
Tint2 ist leicht,elegant und effizient. Ich mags.
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-3dfxAlles 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:
- Zuerst muss der Paketmanager wissen, woher er die Quelldateien beziehen soll, wozu die Datei /etc/apt/sources.list modifiziert wird.
- Dann wird das Quellpaket als normaler Nutzer heruntergeladen.
- Dann wird
dpkg-buildpackageausgeführt, um ein .deb Paket zu erstellen. - Und schließlich wird
dpkg -ibenutzt, 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.
- Auf der Homepage von Ethan Schoonover die gezippte Datei solarized.zip herunterladen.
- Im Ordner vim-colors-solarized die Datei solarized.vim nach ~/.vim/colors kopieren.
- ~/.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.
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.
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.
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.
- Quellpakete herunterladen z.B. auf der offiziellen Sourceforge Seite von Wine oder hier.
- Abhängigkeiten installieren
apt-get build-dep wine
oder indem die oben erwähnten Pakete manuell mit apt installiert werden.
- Quellpaket entpacken z.B. in ~/tmp mit
tar -xvf wine-1.2.tar.bz2
- Kompilieren: In das neue Wine-Verzeichnis in ~/tmp wechseln und
./configure
makeausfü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.
Mach ein Bildschirmfoto mit scrot
Ein Bildschirmfoto zu machen gehört praktisch zum guten Ton, wenn man seinen Desktop präsentieren will oder ohne viel Worte in einem Forum auf ein Problem hinweisen möchte.
In der Regel genügt es mit vorinstallierten Programmen wie z.B. gnome-screenshot und einem Drücken der "Druck" Taste den Bildschirm als Foto zu archivieren. Seit längerer Zeit nutze ich auch Shutter, was viele zusätzliche Optionen bietet und dessen Plugins mir sogar oft die Nachbearbeitung mit Gimp ersparen.
Meistens hilft mir hierbei ein ganz anderes Programm für diese Art von Aufgabe und das heißt scrot.
Scrot ist eine wunderbare, kleine Anwendung, welche verschiedene Funktionen hat, um den gesamten Bildschirm oder auch nur einen Teil davon aufzunehmen und alles als .jpg oder .png Datei abzuspeichern. Mit weiteren Parametern lassen sich leicht Zeitstempel, frei bestimmbare Zeichenketten oder die Bildschirmauflösung an den Dateinamen anhängen.
Scrot lässt sich prima von einem Terminal Emulator aus bedienen. Hier sind einige Beispiele:
Beispiele
1. Den gesamten Bildschirm aufnehmen und das Foto in das aktuelle Arbeitsverzeichnis speichern.
scrot
2. Den gesamten Bildschirm nach fünf Sekunden aufnehmen und dabei das Ganze mit einem Countdown visualisieren.
scrot -cd 5
3. Warte fünf Sekunden, visualisiere die Verzögerung und nimm nur das momentan ausgewählte Fenster auf.
scrot -u -cd 5
4. Warte fünf Sekunden, mache ein Bildschirmfoto und benenne den Dateinamen mit Datumsstempel, Bildschirmauflösung und scrot als Zeichenkette. Speichere das Bild im .png Format im Verzeichnis "bilder" im Home Verzeichnis des Nutzers ab und öffne es danach mit dem Bildbetrachter feh. $f ist ein Platzhalter für die Datei.
scrot -d 5 '%Y%m%d-%s_$wx$h_scrot.png' -e 'mv $f ~/bilder/ & feh ~/bilder/$f'
Scrot im Menü von Openbox integrieren
Das vor kurzem vorgestellte Crunchbang Linux nutzt Openbox als Fenstermanager und hat scrot hier geschickt im Menü von Openbox integriert. Um sich das zuletzt gezeigte Kommando nicht merken zu müssen, kann man es einfach in der menu.xml wie folgt eintragen oder natürlich auch den grafischen Weg über obmenu gehen.
<menu id="graphicsScreenshots" label="Bildschirmfoto aufnehmen">
<item label="Jetzt">
<action name="Execute">
<execute>
scrot '%Y%m%d-%s_$wx$h_scrot.png' -e 'mv $f ~/bilder/ & feh ~/bilder/$f'
</execute>
</action>
</item>
<item label="In 5 Sekunden...">
<action name="Execute">
<execute>
scrot -d 5 '%Y%m%d-%s_$wx$h_scrot.png' -e 'mv $f ~/bilder/ & feh ~/bilder/$f'
</execute>
</action>
</item>
<item label="In 10 Sekunden...">
<action name="Execute">
<execute>
scrot -d 10 '%Y%m%d-%s_$wx$h_scrot.png' -e 'mv $f ~/bilder/ & feh ~/bilder/$f'
</execute>
</action>
</item>
<item label="Ausgewaehlter Bereich....klicke und bewege die Maus">
<action name="Execute">
<execute>
scrot -s '%Y%m%d-%s_$wx$h_scrot.png' -e 'mv $f ~/bilder/ & feh ~/bilder/$f'
</execute>
</action>
</item>
<item label="Nur das Fenster">
<action name="Execute">
<execute>
scrot -u -d 5 '%Y%m%d-%s_$wx$h_scrot.png' -e 'mv $f ~/bilder/ & feh ~/bilder/$f'
</execute>
</action>
</item>
</menu>Bei meiner ersten Begegnung mit Fluxbox bin ich damals auf tenr.de gestoßen. Ziemlich weit unten bei snippets befindet sich ein kleines Skript namens shot.sh, welches sich ebenfalls gut eignet, um den Umgang mit scrot zu vereinfachen. Ansonsten hilft wie immer auch man scrot weiter. Übrigens lässt sich mit der Option -q auch die Qualität der Aufnahme beeinflussen. 🙂