Schnell und leicht: Dillo 3 ist zurück

Es war einmal ein Browser, der war schnell und sehr leicht. Er basierte auf GTK1, startete augenblicklich und war in vielen Distributionen zu finden, die sich auf ältere Hardware spezialisiert hatten.
Der Nachfolger mit der Versionsnummer 2 stieg danach auf die FLTK2 Bibliothek um, welche aber einige Lizenzprobleme hatte, so dass der Browser in vielen bekannteren Linuxdistributionen nicht aufgenommen werden konnte.
Wir schreiben das Jahr 2011 und Dillo 3 hat das Licht der Welt erblickt. Mittlerweile sind die Entwickler wieder auf FLTK1.3 umgeschwenkt, obwohl die Lizenzprobleme für die FLTK2-Bibliothek gelöst sind. Wie auch immer, Debian hat sich entschieden Dillo 3 aufzunehmen, weswegen ich mir den Browser kurzerhand mit Apt installiert habe.
Bei den Systemanforderungen ist Dillo 3 nach wie vor äußerst anspruchslos. Er belegt ca. 2 MB auf der Festplatte und laut ps_mem.py Skript ca. 11 MB RAM auf meinem Inspiron 4000. Die Startzeit um diese Seite zu laden liegt bei ca. 2 Sekunden.
Dillo hat sich offensichtlich seit meinen Versuchen Dillo 2 vergangenes Jahr zu kompilieren weiterentwickelt und bietet nun bessere CSS-Unterstützung. Mein WordPress-Blog ist lesbar und alle wichtigen Navigationslinks sind auch dort wo sie sein sollen.

Natürlich hat Dillo 3 auch ein paar Schwächen. HTTPS-Seiten würde ich weiterhin mit ihm nicht besuchen, da er außer rudimentärsten Kommandos SSL/TLS-Verschlüsselung nicht unterstützt.
Die CSS-Fähigkeiten sind sichtbar besser geworden, aber an die Qualität eines modernen Webkit-, Gecko- oder Presto- Browsers kommt er nicht heran.
Für alle, die immer auf der Suche nach dem besten Kompromiss zwischen Leichtigkeit und Funktionalität sind, kommt Dillo als Webbrowser als eine Möglichkeit in Frage. Mittlerweile bieten aber Webkit-Browser wie Surf deutlich bessere Rendereigenschaften bei vergleichsweise geringen Hardwareanforderungen.
Für reine HTML-Seiten ist Dillo ideal, obwohl links2 mit der -g Option ähnliche Ergebnisse bietet. Für Textseiten ohne Javascript und alles andere gibt es ja auch noch elinks. Interessant für Webentwickler ist auch Dillos Buganzeige am unteren rechten Bildschirmrand.
Am Ende muss man einfach abwägen, was man tatsächlich zum Browsen braucht. Standardmäßig ist Dillo sehr sicherheitsbewusst eingestellt. Cookies werden immer abgelehnt. Normalerweise lässt sich dieses Verhalten in ~./dillo/cookiesrc wieder ändern.

DEFAULT DENY
fltk.org ACCEPT
.host.com ACCEPT_SESSION

Hiermit werden alle Cookies abgelehnt, bis auf fltk.org, welches immer akzeptiert wird und host.com, wofür Dillo aber nur für die Dauer der Sitzung Cookies entgegennimmt. Leider gelang es mir trotzdem bis jetzt nicht, mich in das WordPress-Backend oder Google-Mail einzuloggen. Bei letzterem könnte auch die Beschränkung auf "Standardbrowser" eine Rolle spielen.
Häufig gestellte Fragen beantwortet die Dillo FAQ.
Wie immer gilt, Dillo am besten selbst einmal ausprobieren.

Gnome 3 ist nun in Debian Unstable

Gnome 3.0 ist da! Der 13. Oktober brachte nicht nur Ubuntu 11.10, sondern auch den Übergang der letzten und entscheidenden Pakete von Gnome 3 aus Debian Experimental nach Unstable. Was lange währt, wird endlich gut. Damit lag ich im letzten Beitrag zu diesem Thema mit der Vermutung nicht ganz falsch, dass Gnome 3.0 in Debian dann erscheinen wird, wenn offiziell 3.2 von den Gnome Entwicklern freigegeben wurde.
Hier sind vielleicht noch ein paar interessante Fakten zu Gnome 3 in Debian:

  • Tatsächlich fand der Übergang von Gnome 2 nach Gnome 3 bisher auf eine sanfte und unbemerkte Weise für alle Testing- oder Unstable-Nutzer statt. Von Zeit zu Zeit flossen Pakete von Gnome 3 schon ein und wurden parallel zu Gnome 2 installiert, ohne dass dies irgendeine gravierende Auswirkung gehabt hätte. Am ehesten fiel es noch bei Anwendungen wie "Eye of Gnome" auf, die plötzlich Versionsnummer 3 trugen und nicht mehr im alten GTK2-Gewand erschienen sind, da sie nun auf GTK3 basieren.
  • Seit dem 13. Oktober befinden sich nun die wirklich entscheidenden Pakete in Debian Unstable, Gnome Shell, Nautilus 3 und Gnome Panel und mit ihnen alles, was das neue Bedienungskonzept von Gnome 3 sichtbar werden lässt.
  • Der Status von Gnome 3.0 in Debian lässt sich weiterhin auf http://www.0d.be/debian/debian-gnome-3.0-status.html verfolgen. Fast alles grün mittlerweile. 🙂
  • Gnome 3.2 hat eine ähnliche Übersichtsseite bekommen. http://www.0d.be/debian/debian-gnome-3.2-status.html
  • Kompetente und aktuelle Informationen in Englisch zu Gnome 3 in Debian gibt es im IRC in #debian-gnome auf OFTC.
  • Gnome 3 Release Critical Bugs: http://deb.li/gnomercbugs
  • Gnome 3 Buildd Status. Wurde Gnome 3 Paket X erfolgreich für meine Architektur gebaut?: http://deb.li/pkggnome
  • Auf linuxundich.de wurde berichtet, dass die Erweiterung nautilus-open-terminal zu Abstürzen der Ubuntu Version von Nautilus führt. Im Debian-Bugtracker existiert seit August Fehlerbericht #637309 hierzu, der scheinbar in Zusammenhang mit dem Fehlerbericht #869131 auf Launchpad.net steht. Scheinbar lassen sich eine Reihe von Bugs auf den notwendigen Übergang von GTK2 auf GTK3 zurückführen. Zu den mehr als 100 Gnome 3 relevanten Paketen gesellen sich auch noch eine große Anzahl von Erweiterungen hinzu, die alle ebenso portiert werden müssen. Eine Übersicht über alle schwerwiegenden Bugs in Bezug auf den Übergang von Nautilus befindet sich hier.
    Mittlerweile stuft Debian diese Bugs alle als "Serious" und damit als veröffentlichungskritisch ein. Erste Warnungen an die Paketbetreuer gab es bereits im August. Diese müssen nun mit Hilfe von Upstream ihre Pakete wieder in einen stabilen Zustand bringen. Da Ubuntu direkt aus Debian Unstable Pakete entnimmt, ist die aktuelle Ubuntu Version Oneiric Ocelot direkt davon betroffen. Dieses kleine Beispiel zeigt nur, dass Gnome 3 ein sehr großes Projekt ist, welches von einer großen Anzahl von Einzelpersonen abhängt um perfekt zu funktionieren.
  • Ich habe in meinem Beitrag "Wie steht es um Gnome 3 in Debian?" geschrieben, dass Debian einen größeren Aufwand hat Gnome 3 für alle auf Debian unterstützten Architekturen zur Verfügung zu stellen und es damit oft etwas länger dauert. Das trifft im Allgemeinen sicher zu, doch hat Josselin Mouette am 02. Oktober 2011, einer der Gnome Paketverwalter, auf der debian-devel Mailingliste klargestellt, dass dies nicht das Kernproblem ist.
    Vielmehr finden große Veränderungen in Debian in Übergängen (Transitions) statt, aber erst wenn sichergestellt ist, dass dadurch nicht eine Reihe von bestehenden Paketen unbenutzbar wird. Er führt die lange Verzögerung in Debian vor allem auf das letzte Einfrieren der Pakete für die Veröffentlichung von Squeeze zurück. Dadurch entsteht sozusagen ein "Paketstau", der nur langsam abgebaut werden kann.

So viel zum aktuellen Stand von Gnome 3 in Debian. Mit etwas Glück könnte schon am 23. Oktober Gnome 3 in Testing ankommen. Selbst wenn es länger dauert, ich werde warten. 😉

Konkurrenz zu Screen: Tmux

Ich habe in letzter Zeit wieder einige Konsolenprogramme ausprobiert, worunter auch Tmux zu finden war. Wenn man viel mit dem Terminal arbeitet oder auf der Konsole unterwegs ist, begegnet einem zwangsläufig GNU Screen und man fragt sich wie man es früher ohne dieses nützliche Programm geschafft hat.
Tmux ist wie Screen ein sogenannter Terminalmultiplexer, der mehrere Fenster mit darin laufenden Programmen innerhalb eines Bildschirms darstellen kann. Für mich ist er somit das Gegenstück zu einem kachelnden Fenstermanager unter X und besonders nützlich für sehr alte Rechner. In der Regel brauche ich Screen hauptsächlich um die Übersichtlichkeit zu verbessern und den Terminal einfach bedienungsfreundlicher zu gestalten. Nicht zu vergessen lassen sich die Sitzungen sowohl von Screen als auch Tmux abtrennen und jederzeit mit den darin laufenden Programmen wieder hervorholen.
Im Moment bin ich mit Screen zufrieden, doch ein paar gute Gründe zum Wechsel gibt es. Da wäre zum einen Screens Eigenart leicht angefressen auf längere Namen von Terminalemulatoren zu reagieren. Außerdem konnte ich rxvt-unicode-256color nur mit etwas Nachhilfe dazu bewegen von Screen erkannt zu werden. Schon damals hatte Neo in den Kommentaren auf Tmux hingewiesen und in der Tat scheint Tmux weniger Probleme mit 256-Farben-Terminals zu haben.
Ansonsten kann man oft lesen, dass Tmux das modernere Screen sei und aktiv weiterentwickelt wird. Ich kann nichts Gegenteiliges behaupten. Screen hingegen ist ein wahres Software-Urgestein, was aber nicht bedeutet, dass es schlecht oder unbrauchbar ist. Vielmehr scheint es so zu sein, dass Screen eine gewisse Reife erlangt hat und im Regelfall einfach funktioniert und dazu noch von allen großen Distributionen unterstützt wird. Abgesehen davon ist Screen Bestandteil des GNU Betriebssystems, weswegen ich mir um die Zukunft erst einmal keine Sorgen mache.
Ein klarer Pluspunkt für Tmux ist aus meiner Sicht die Fähigkeit, auch die vertikale und horizontale Aufteilung des Bildschirms nach der Wiederherstellung einer Session beizubehalten, die Screen leider verwirft. Ebenfalls bemerkenswert ist die gute Dokumentation zu Tmux und die vielen Beispiele, die im Netz kursieren. Eine Suche zu "tmux conf" hilft schon weiter.

GNU Screen
Tmux

Wie sie sehen, sehen sie nicht viel. Große Unterschiede in meiner Standardkonfiguration gibt es zwischen Screen und Tmux nicht. In letzter Zeit kommt noch fbterm für die Konsole hinzu, der die Optik mit einem Hintergrundbild deutlich aufpoliert. In der Regel tut es aber eine Statusleiste am unteren Rand für mich.
Tmux bietet eine simple Möglichkeit die Tastenbelegungen mit dem bind Befehl zu ändern, weswegen ich z.B. von STRG+B auf das Screen-typische STRG+A zurückgewechselt bin, um Kommandos an Tmux durchzuleiten.
Meine .tmux.conf sieht so aus:

# STRG+A anstelle von STRG+B
unbind C-b
unbind l
set -g prefix C-a
bind-key C-a last-window
# Reload Taste
bind r source-file ~/.tmux.conf
# wichtig für rxvt-unicode-256color
set -g default-terminal "screen-256color"
set -g history-limit 1000
# Automatisch gestartete Session
new -d 'exec irssi'
neww -n alpine 'exec alpine -d 0'
neww -n mc mc
neww -n htop htop
neww -n slurm 'exec slurm -i eth0'
neww -n hnb hnb
neww -n elinks elinks
neww -n wyrd wyrd
neww -n newsbeuter newsbeuter
# THEMA
set -g status-bg black
set -g status-fg white
set -g status-right '#[fg=white]#(cut -d " " -f 1-3 /proc/loadavg)#[default] #[fg=white]%H:%M#[default]'

Im Gegensatz zu Screen muss Tmux mit tmux attach gestartet werden, sofern man Anwendungen in einer neuen Session beim ersten Aufruf mit ausführen möchte. Es gibt noch viel mehr zu erzählen und vor allem auf der technischen Seite gibt es einige Unterschiede zu Screen.
Was man mitnehmen sollte ist, es gibt eine gute Alternative zu Screen und die heißt Tmux.

Eine algorithmische Konsolensymphonie

Auf was man nicht alles stößt, wenn man ab und zu den Gesprächen in #debian auf irc.debian.org folgt. Hier ist das Wochenende-Rezept für pure Nostalgie gewürzt mit etwas geekig und retro.
Man nehme einen IBM Thinkpad 600 oder ein vergleichbares Modell, installiere Debian Squeeze, seine Konsolenfavoriten, starte FbTerm und darin dann einen Terminalmultiplexer wie Screen oder Tmux. Nun nur noch mit Irssi zu #debian verbinden und den passenden Moment abwarten, wenn ausnahmsweise einmal ein Youtube-Video gepostet wird.
Mit Hilfe von gpm gibt es Mausunterstützung, womit man leicht den Link kopieren und im gleichzeitig geöffneten elinks Textbrowser einfügen kann. Sobald die Seite aufgerufen ist, kommt der youtube-dl+mplayer Trick erneut zum Einsatz.
Jetzt noch gut streamen lassen und Mplayer beginnt automatisch mit dem Abspielen des geposteten Videos, natürlich gegen den Framebuffer!

Jetzt noch dicke Brillengläser kaufen, sich Zähne mit Überbiss wachsen lassen und die Musik des Videos laut aufdrehen. Fertig! 😉 Der perfekte Tipp übrigens um in jedem Haus, jeder Wohnung oder WG bald alleine zu sein. 😛

Ein winziges C-Programm

In nachfolgenden Video geht es um ein winziges in C geschriebenes Programm, womit sich hörbare Klänge und so etwas wie 8bit-Musik erahnen lässt. Das Beeindruckende ist wirklich der Umfang des Codes, der in einer Zeile variierende Klangmuster produziert. Wer es selbst mal ausprobieren möchte und experimentieren will, kann z.B. einfach folgenden Code ausführen. Die faszinierende Idee dazu stammt vom finnischen Blogger viznut aus seinem englischen Blog countercomplex. Kudos!

echo "main(t){for(t=0;;t++)putchar(t*(t>>((t>>9|t>>8))&63&t>>4));}"| gcc -xc -lm -&&./a.out|aplay

Frozen Synapse: Mit kühlem Kopf zum Sieg

Also habe ich mir das Humble Bundle gekauft und mir den Aufmacher genauer angeschaut. Dieses mal stand Frozen Synapse im Fokus. Aus der ursprünglichen Beschreibung zum Spiel war nur zu erahnen, was da auf mich zukommen würde. Taktischer Shooter, rundenbasiert, Kampagnenmodus und Multiplayer.
Vorneweg darf man schon sagen, dass der Linuxinstaller gelungen ist. Frozen Synapse wird in einer Bin-Datei ausgeliefert, die man nur noch ausführbar machen muss. Damit hebt es sich deutlich von Atomzombiesmasher ab, bei dem ich immer noch auf den angekündigten Installer oder zumindest eine Anleitung zum Installieren der richtigen Bibliotheken warte.
Im Optionsmenü lässt sich die Auflösung des Spiels schnell ändern und die Wahl zwischen Fenstermodus oder Vollbild ist kein Problem. Als erstes wählte ich danach das Tutorial aus, um mir meine ersten Sporen zu verdienen. Ein androider, cyberspaceiger Avatar, dessen Geschichte später in der Kampagne etwas deutlicher wird, führt einen durch mehrere Trainingskapitel.


Am Anfang lernt man noch Wegmarken richtig zu setzen und die Bewegungen seiner Spielfigur vorauszuplanen. Die Schwierigkeit steigt danach leicht an, bis man zum ersten Mal gegen zwei Gegner gleichzeitig vorgehen muss. Jetzt muss man nicht nur die Figur in die richtige Richtung schauen lassen, sondern auch von Fähigkeiten wie Ducken, Schießen auf Sichtweite und Warten Gebrauch machen.
Schnell wird klar, dass man hier die Züge des Gegners vorausahnen muss. Hier unterschied sich Frozen Synapse klar von anderen Taktikspielen. Das Spiel ist in zwei Phasen eingeteilt. In der Planungsphase werden die Aktionen der eigenen Figuren festgelegt. Drückt man danach auf die "Prime"-Taste ist der Gegenspieler oder Computer an der Reihe und es wird ein Ergebnis berechnet. Je nach dem wie gut man dessen Züge antizipiert hat, fällt der eigene Erfolg aus.
Nach dem Tutorial kennt man alle wichtigen Fähigkeiten, die sich mit Tastatur oder Maus auswählen lassen. Im Kampagnenmodus erhält man als "Taktierer" die Kontrolle über mehrere Einheiten, die die andere Fraktion ausschalten sollen. Die Story klammere ich hier ein wenig aus. Irgendetwas zwischen Ghost in the Shell, Matrix und Cyberpunk. Wirklich mitgerissen hat sie mich nicht, aber das tut dem Spiel keinen Abbruch. Die Szenarien, in die man geschickt wird, werden immer komplexer. Mit Hilfe von Granaten lassen sich auch Wände später wegsprengen, was die Handlungsmöglichkeiten stark erweitert.

Gut gefällt mir, dass man mit dem Mausrad in das Spielfeld rein- und rausscrollen kann und man alle Zeit der Welt hat seinen Zug zu planen. Bevor man in die zweite Phase übergeht, hat man immer noch Gelegenheit seine Schritte wie in einem Film abspielen zu lassen. Gefällt einem das Ergebnis dieser Vorschau nicht, lassen sich die taktischen Züge noch einmal ändern.
Die Musik des Spiels ist ebenfalls gut gelungen. Ich würde sie mal als Elektro-Pop bezeichnen, der unaufdringlich den Spielablauf untermalt. Ein bemerkenswertes Feature war die eingebaute Videoaufnahme, mit der sich das komplette Szenario aufnehmen lässt. Wer Starcraft oder Warcraft mit den Replays kennt weiß bescheid. Die Videos werden als OGV-Container mit Theora für Video- und Vorbis als Audiocodec abgespeichert und lassen sich direkt auf youtube.com hochladen. Toll!

Fazit

Frozen Synapase ist kein Spiel, welches man mal schnell durchzockt und dann zur Seite legt. Es hat nichts mit einem Actionshooter gemein, sondern konzentriert sich allein auf taktisches und planvolles Spiel. Es ist also mehr was für Leute, die eine Knobelaufgabe wie im Schach suchen und schon immer mal so etwas wie ein SWAT-Team fernsteuern wollten. Frozen Synapse unterstreicht, dass Indiespiele sehr kreativ sein können und dass es auch möglich ist gute Spiele für mehr als nur eine Plattform zu entwickeln.
Als zusätzlichen Bonus gibt es beim Kauf des Humble Bundles noch SpaceChem und Trauma dazu. Letzteres zeichnet sich nicht nur durch eine fotorealistische Grafik aus, sondern zieht einem auch durch das ungewöhnliche Umfeld in seinen Bann. Trauma lädt zu einer Reise in die Träume einer verunglückten jungen Frau ein, die man deuten muss, um mehr über sie und ihr Schicksal herauszufinden. Lohnt sich, einfach mal selbst ausprobieren. 😉

Automatischer Paketbau mit dem Build Service von OpenSUSE

Wer keine Lust hat eine vollständige Entwicklungsumgebung aufzusetzen, aber dennoch gerne eigene Softwarepakete erstellen möchte, kann auf einen Dienst der Linuxdistribution OpenSUSE zurückgreifen. Mit diesem ist es möglich Pakete für verschiedene RPM-basierte Distributionen und auch für Debian oder Ubuntu zu erstellen.
Es genügt, wenn man sich auf https://build.opensuse.org mit Nick und E-Mail registriert. Anschließend hat man Zugriff auf ein eigenes Konto, mit welchem sich eigene Projekte realisieren lassen. Das webgestützte Interface hat mir auf Anhieb gut gefallen. Nachdem man sich für sein neues Paket einen Namen und eine Beschreibung ausgedacht hat, kommt man auch schon sofort zum wesentlichen Teil.
Auf der "Sources"-Seite müssen alle notwendigen Dateien zum Bauen eines eigenen Debianpakets hochgeladen werden. Im Grunde genommen sind das die wichtigen Steuerungs- und Kontrolldateien aus dem mit dh-make erstellten Debian-Ordner innerhalb des Quellpakets. Diese müssen, um vom Buildservice verarbeitet werden zu können, zuerst wie folgt umbenannt werden.

debian.changelog
debian.compat
debian.control
debian.rules
debian.install

Ebenfalls möglich ist es, Dateien direkt aus dem Internet herunterladen zu lassen oder ein Tar-Paket in ein anderes Format zu komprimieren. Sind diese Vorbereitungen getroffen, fehlt nur noch die DSC-Datei und das eigentliche Quellpaket im gepackten Tar-Format. Als Alternative lässt sich auch das komplette Paket-Version-debian.tar.gz mit Quellverzeichnis und der DSC-Datei laut der offiziellen Anleitung hochladen. Letztere Methode hat den Vorteil, dass man auf ein debianisiertes Quellpaket zurückgreifen kann und somit nur noch diese Dateien zum Buildservice hinzufügen muss, was ziemlich praktisch ist.

Wie der Screenshot zeigt, habe ich mich an dem kleinen Texteditor Nano wieder einmal probiert. Eine gute Wahl, wenn man sich in die Materie vortasten will. Nachdem die drei Dateien hochgeladen waren, begann die Virtuelle Maschine, eine XEN Lösung übrigens, automatisch mit der Erstellung der Build-Umgebung, Auflösen der Abhängigkeiten und dem anschließenden Kompilieren. Ich musste danach nur noch die fertigen Deb-Pakete herunterladen.
Praktisch an dem Build Service ist, dass man parallel für unterschiedliche Distributionen und Architekturen Pakete bauen kann. Außer Webzugang und einem Konto gibt es keine weiteren Voraussetzungen. Das gesamte Angebot eignet sich besonders für Entwickler, die ihre Software auf mehreren Plattformen testen wollen, ohne dabei privat mehrere verschiedene Entwicklungsumgebungen installieren zu wollen. Für mich als Nicht-Entwickler ist es dagegen einfach eine bequeme Möglichkeit zum Experimentieren und Dazulernen. Abgesehen davon, dass das zugrundeliegende Rahmenwerk für den Build Service Freie Software ist, zeigt es auch, dass sich verschiedene Linuxdistributionen mit ihrer Infrastruktur gegenseitig ergänzen können.
Von wegen immer: Mein Linux ist besser als deins. 😛

FbTerm: Konsole muss nicht langweilig sein

Inspiriert von K.Mandlas Post zu FbTerm, habe ich mich mal daran gewagt und mir diesen Framebuffer Terminal Emulator etwas genauer angeschaut.
Das ist FbTerm in Aktion und in der Tat, das ist nicht X!



FbTerm schafft es den Anschein zu erwecken, als ob man sich auf einem grafischen Desktop befände, indem es ein Programm wie fbi oder fbv dazu nutzen kann ein Hintergrundbild zu setzen.
Zumindest mit fbi hatte ich keinen Erfolg, aber vielleicht gibt es da draußen jemanden, der mehr Glück als ich damit hat.
Für mich funktionierte schließlich fbv, welches auch von den Entwicklern des Framebuffer Terminals vorgeschlagen wird. Riskiert man einen Blick auf man fbterm findet sich dort schon ein vorgefertigtes Miniskript, mit welchem es möglich ist ein Bild gegen den Framebuffer darzustellen und das dann von fbterm quasi abgegriffen und als Hintergrundbild verwendet wird.

#!/bin/bash
# fbterm-bi: a wrapper script to enable background image with fbterm
# usage: fbterm-bi /path/to/image fbterm-options
echo -ne "e[?25l" # hide cursor
fbv -ciuker "$1" << EOF
q
EOF
shift
export FBTERM_BACKGROUND_IMAGE=1
exec fbterm "$@"

Eine kleine Hürde war das Installieren von fbv. Dieses kleine Programm kann zwar genauso wie fbi Bilder gegen den Framebuffer darstellen, wird aber seit sieben Jahren nicht mehr weiterentwickelt, weshalb es in Debian nicht mehr zur Verfügung steht.
Nicht immer muss aber hohes Alter gleichzeitig schlechte Software bedeuten. Ich lud den Quellcode von der Projektseite herunter und kompilierte fbv kurzerhand selbst.

./configure
make

Zum erfolgreichen Übersetzen sollte man sich vorher die Entwicklerpakete für libjpeg, libungif und libpng herunterladen. Danach verschob ich die fbv Binärdatei manuell nach /usr/local/bin.
Um FbTerm schließlich mit einem beliebigen Hintergrundbild zu starten, kopiert man das Skript z.B. in eine Datei namens fbterm-bi, macht sie mit chmod u+x ausführbar und führt das Ganze aus.
./fbterm-bi mein-hintergrund-bild.jpg
Innerhalb von fbterm wird man darauf hingewiesen, dass fbterm die Tastaturbelegung nicht ändern konnte, um die eigenen Tastaturkürzel ausführen zu können. Laut Handbuch kann man entweder fbterm mit setuid(0) Rechten ausstatten, mit dem der Prozess kurzzeitig Rechte erhält, die eigentlich nur root zustehen, um die Tastaturbelegung ändern zu können.
Die zweite Möglichkeit ist das Programm setcap aus dem Paket libcap2-bin zu benutzen, um nur einen klar definierten Teil der Root-Rechte auf FbTerm kurzzeitig übergehen zu lassen.
Mir erschien letzteres die bessere Methode zu sein, weswegen ich das vorgeschlagene Kommando ausführte.
setcap 'cap_sys_tty_config+ep' /usr/bin/fbterm
Nun hat man auch als normaler Benutzer eines Systems Zugriff auf FbTerms Tastenkürzel. So ähnlich wie bei screen lassen sich weitere Fenster innerhalb von FbTerm mit STRG+ALT+c öffnen und mit STRG+ALT+d schließen. Mit STRG+ALT+Zahl lässt sich dann wieder zwischen Fenstern hin- und herwechseln. Besonders nützlich ist auch die eingebaute "History" Funktion SHIFT+Bildhoch bzw. SHIFT+Bildrunter, womit man die komplette Anzeige hoch - und runterscrollen kann.
Interessant wird es aber erst richtig mit einem Programm wie screen, womit sich der Bildschirm innerhalb von FbTerm teilen lässt oder man seine gesamten Anwendung einfach wieder abtrennen, in den Hintergrund bringen und auch wieder nach Bedarf hervorholen kann.
Ebenfalls bemerkenswert sind die Verwendung von fontconfig und der damit einhergehende Zugriff auf die gleichen Schriften, die auch in GTK oder QT Anwendungen eingesetzt werden. Die Schriftfarbe und -familie lässt sich leicht in der Konfigurationsdatei ~/.fbtermrc ändern.
So lässt sich mit ein paar Handgriffen selbst vollkommen überholte Hardware, die ausschließlich mit Konsolenanwendungen betrieben wird, schnell bunter und ansprechender machen. Da behaupte noch einer die Konsole sei langweilig. 🙂

Ein Versuch: Debian-Pakete mit pbuilder backporten

Wie schwierig konnte es schon sein ein Debian-Paket von Sid nach Squeeze zu "backporten". Ich kramte mal wieder Debians Netzinstallation hervor und installierte mir ein 64 bit Debian. Anschließend machte ich ein Upgrade auf Sid und wollte nun i386-Pakete für Squeeze bauen.
Ich habe mich für die "Pbuilder"-Methode entschieden. Mit Pbuilder lässt sich eine komplette Entwicklungsumgebung in eine spezielle Chroot-Umgebung einschließen und jeder Paketbau läuft unter kontrollierten Bedingungen ab.

pbuilder create --distribution squeeze --debootstrapopts --arch --debootstrapopts i386


Mit dem oben stehenden Kommando wird Pbuilder angewiesen eine Umgebung auf Basis von Squeeze und der i386-Architektur zu erstellen. Die weiteren Optionen, die in der offiziellen Doku zu Pbuilder stehen, brauchte ich nicht.
Anschließend kann man sich mit dem normalen Benutzer die Quellpakete, die man übersetzen möchte, herunterladen.

apt-get source nano cmus


Mit root Rechten wechselt man daraufhin zu den heruntergeladenen Quellpaketen und weist Pbuilder an das Paket in der Chroot-Umgebung zu bauen.

pbuilder build Paketname.dsc


Das Ergebnis viel unterschiedlich aus. Relativ kleine Pakete mit wenig Abhängigkeiten wie Nano oder slurm ließen sich problemlos übersetzen. Hier hatte ich am Ende tatsächlich ein fertiges Paket, welches ich auf jedem Debian Squeeze installieren konnte.
Problematisch wird es nur bei Software, die viele Abhängigkeiten mit anderen Paketen hat. In Squeeze entsprechen natürlich viele Pakete nicht mehr dem aktuellen Stand. Hier muss man also zuerst alle Abhängigkeiten übersetzen, bevor man anfängt das eigentliche Paket zu kompilieren.
Mit Hilfe eines "Local Repository" wird beim Bauen der Pakete dann nicht mehr nur auf die offiziellen Debianpakete verwiesen, sondern man kann lokal Abhängigkeiten bauen, auf die pbuilder Rücksicht nehmen wird. Mit diesem kleinen "Trick" lassen sich auch komplexere Pakete backporten.
Ich stehe hier zwar selbst noch am Anfang, weiß aber nun, wo ich suchen muss, wenn ich tatsächlich mal unbedingt ein brandaktuelles Softwarepaket nach Debian Stable bringen möchte. Immerhin ist mir nun klarer geworden, wo die Schwierigkeiten bei Backports liegen und was Raphael Hertzog mit dem Satz meinte: "Gnome 3 in Squeeze? - No sorry".

Nvidia oder Nouveau: Xorg 1.11.1 und das Dilemma mit den Treibern

Wie einige vielleicht wissen, bin ich im April auf ein Multi-Boot-System umgestiegen. Anstelle von Ubuntu als einziges Betriebssystem auf dem Dual-Core-Rechner, dient dieses nun als Video- und Bildbearbeitungsplattform, Debian Sid in der Minimalinstallation als Spielesystem und Debian Testing erledigt die Hauptarbeit mit Bürosoftware, E-Mail-Programm und Webbrowser. 90 % der Zeit mit dem Dual-Core-Rechner verbringe ich dann auch mit Debian Testing.
Vor wenigen Tagen gab es ein Update auf die aktuelle Version des Xorg-Servers 1.11.1. Seitdem verursachen manche Seiten in Iceweasel und anderen Browsern eine hohe CPU-Last und selbst das kurze Überfahren des AWN-Docks mit dem Mauszeiger bringt die CPU wegen der Compositing-Effekte schon ins Schwitzen.
Da es in mehreren Applikationen auftritt, liegt der Verdacht nahe, dass das letzte X-Update dafür verantwortlich ist. Wie meldet man aber so einen Bug und formuliert das Problem richtig? Immerhin gibt es ja nicht nur ein Paket zum X-Server. Ein simples: "Iceweasel ruckelt. Es muss an eurem X-Server liegen. Macht was" hilft sicher nicht weiter.
Ich suchte erst noch einmal etwas genauer im Netz und fand irgendwo den Hinweis, dass nicht unbedingt X, sondern die Nvidia-Treiber schuld seien. Und tatsächlich, als ich auf die freien Nouveau-Treiber umgestellt hatte, gab es plötzlich kein Geruckel mehr.
Damit wäre die Sache eigentlich erledigt, der Bug und das Problem aber nicht beseitigt. Das X-Team von Debian würde mich mit Sicherheit direkt zu Nvidia verweisen, da unfreie Pakete wegen dem verschlossenen Quellcode nicht von Debian gefixt werden können. Wahrscheinlich könnte Nvidia dann nur sagen, dass vor dem Update der Treiber wie beabsichtigt funktionierte und Xorg der Übeltäter sei.
Hier hilft außer ein Warten auf ein Xorg- oder Nvidia-Update nicht viel. Natürlich könnte man versuchen ein Downgrade auf die letzte Version von X zu machen. Sinnvoller wäre es auf die freien Treiber auszuweichen. Warum nutze ich die eigentlich nicht? Immerhin habe ich ja schon ein parallel installiertes OS für Spiele.
Das große Problem von Nouveau ist weniger der experimentelle 3D-Support, sondern auch die mangelhafte Unterstützung von Powermanagement-Funktionen. Der Lüfter meiner "Nvidia 9600 GT"-GraKa dreht nämlich permanent auf 100%. Hinzu kommen kleinere Fehler z.B. flackert mein Cursor auf manchen Webseiten plötzlich. Mit nvclock gelang es mir bisher leider ebenfalls nicht die Lüftergeschwindigkeit anzupassen.
Für mich heißt das erst einmal warten auf Gnome 3. Sollte Nouveau hier ähnlich gut funktionieren wie bei Arch Linux, erwäge ich den Umstieg, nehme auch das lautere Lüftergeräusch in Kauf und drehe in Zukunft die Musik einfach etwas lauter auf. 😉

Einmal gefrorenes Humble Bundle Spezial bitte: Frozen Synapse

Es ist mal wieder soweit. The Humble Frozen Synapse Bundle ging vor kurzer Zeit an den Start. Das Besondere ist dieses Mal, dass es sich nur um ein Spiel handelt, welches für die nächsten 14 Tage zum Kauf angeboten wird.
Frozen Synapse scheint ein sehr taktisches Spiel zu sein, bei welchem das Vorausplanen des eigenen Zuges und das Miteinbeziehen der Umgebung maßgeblich zum eigenen Spielerfolg beiträgt. Scheinbar ist es auch für Multiplayer gedacht. Alles weitere dazu, sobald ich Zeit hatte einen Blick auf das Spiel zu werfen. 😉
Bietet man mehr als der durchschnittliche Preis erhält man auch noch das alte Frozenbyte Bundle dazu. Allein aus diesem Grund lohnt es sich schon den Durchschnittspreis (momentan < 5$) zu überbieten. Christoph von linuxundich.de war mit seinem Post einen Tick schneller. Mehr Infos mit weiteren Videos zum Spiel bei ihm.