Author: apo

Posted on

dwm, urxvt, qingy, xmodmap, surf und ein Thinkpad

In diesem Beitrag geht es noch ein wenig um ein paar wissenswerte Funktionen und Hilfsprogramme zum Dynamic Window Manager und um ein paar Merkwürdigkeiten und Einstellungen rund um den Thinkpad 600.

Qingy

Da ich dieses Jahr vor neuen Anwendungen und ein paar Veränderungen keinen Halt gemacht habe, durften natürlich Loginmanager für die Konsole auch nicht fehlen. Qingy ist darunter eine interessante Alternative und ein Mittelding zwischen der minimalen Startx-Lösung und einem voll ausgestatteten Loginmanager wie Gnomes GDM3, wenn man sich in eine grafische X-Umgebung einloggen möchte.
DWM und Qingy scheinen aber nicht richtig zueinander zu finden. Zumindest konnte ich Qingy nicht dazu bewegen eine Login-Shell zu starten, die meine gesamten Umgebungsvariablen wie z.B. die Spracheinstellungen berücksichtigt. Das führte leider dazu, dass Umlaute nicht dargestellt werden konnten.
Mit diesem scheinbar esoterischen Problem war ich aber nicht allein und das Arch-Linux-Wiki hatte dazu mal wieder einen passenden Tipp, z.B. Qingy über eine sogenannte Custom Session zu starten. Ein grafischer Loginmanager wie Qingy berücksichtigt dabei die Datei .xsession. Der Befehl exec zsh -l -c "dwm" brachte mich aber leider nicht ans Ziel.
Lange Rede kurzer Sinn, ich bin wieder ohne Loginmanager unterwegs und habe mir eine Anwendung gespart. Im Gegensatz zu den grafischen Pendants berücksichtigt die Startx/Xinit-Lösung die im Home-Verzeichnis versteckte .xinitrc, was später noch nützlich sein sollte.

rxvt-unicode-256color

Ich greife schon etwas vor, denn ich habe auch einen Backport von rxvt-unicode-256color erstellt. Die 256-Farben-Version von urxvt befindet sich leider nicht in Squeeze. Da ich aber, abgesehen vom Toshiba 220cs, überall schon rxvt-unicode mit der Solarized-Farbpalette benutze, durfte es auf dem Thinkpad auch nicht fehlen und war dank der schon bestehenden Config-Dateien auch schnell eingerichtet.
Mir ist aber aufgefallen, dass die Xft-Schriftarten das Scrollen sehr verlangsamen, was entweder an der Grafikkarte, den Treibern oder auch einer Terminaleinstellung liegen könnte. Da es aber sowohl in Xterm als auch in Urxvt auftrat, bin ich mir bei letzterem nicht so sicher. In einem Forum meine ich gelesen zu haben, dass
urxvt*buffered: false
in der .Xdefaults helfen solle. Mir half hingegen der Wechsel zu einer Bitmap Schrift. Einfach folgendes zur .Xdefaults hinzufügen:

urxvt*font: -xos4-terminus-medium-*-*-*-12-*-*-*-*-*-*-*
urxvt*boldFont: -xos4-terminus-bold-*-*-*-12-*-*-*-*-*-*-*

xmodmap

Mit Hilfe von xmodmap lässt sich die Tastaturbelegung ändern, indem die kerneleigenen Keycodes in sogenannte Keysyms des X-Servers konvertiert werden. Einen guten Überblick über die Thematik findet sich unter dem Stichwort Xmodmap im deutschen ArchLinux-Wiki.
Nachdem ich beim Neukompilieren die MOD-Taste von Mod1 (ALT) auf Mod4(Super) geändert hatte, musste ich noch das Problem lösen wie ich nun bei einem Laptop ohne Super-Taste die Tastenkombinationen ausführen konnte. Als Alternative bot sich z.B. die AltGr-Taste an.

xmodmap -e "keycode 108 = Super_L"

Das funktionierte auch prima, bis ich wieder einmal | als Zeichen benötigte. 🙄
Kein Problem nehmen wir die rechte Strg Taste.

xmodmap -e "keycode 105 = Super_L"

Leider Fehlanzeige, ganz so trivial ist xmodmap dann doch nicht. Vorher war z.B. noch das notwendig:

xmodmap -e "remove control = Control_R"
xmodmap -e "keycode 105 = Super_L"
xmodmap -e "remove mod4 = Super_L"
xmodmap -e "add mod4 = Super_L"

Wer nun schon voll Feuer und Flamme ist und die Enter-Taste auf die Löschen-Taste, Backspace zu Space und Shift zu ESC auf dem Rechner des Arbeitskollegen ummappen möchte, sollte sich auf jeden Fall noch die Befehle xev, xmodmap -pm und xmodmap -pke merken, denn die werdet ihr sicher für das Unterfangen brauchen.
Mit

xmodmap -pke > .Xmodmap

lässt sich die gesamte Keytabelle in die Datei .Xmodmap schreiben, womit die Einstellungen, in der Theorie, mit Hilfe der .xinitrc wiederhergestellt werden können. Das Verhalten ist leicht wahnsinnig, also nichts für schwache Nerven. 🙂

DWM und Xsetroot

So sieht meine .xinitrc im Moment aus.

#!/bin/sh
if [ -f $HOME/.Xmodmap ]; then
	/usr/bin/xmodmap $HOME/.Xmodmap
fi
#xmodmap -e "keycode 108 = Super_L"
urxvtd -q -o -f&
while xsetroot -name "`date` `uptime | sed 's/.*,//'`"
do
	sleep 20
done &
exec dwm

Der erste Abschnitt liest die Einstellungen aus der .Xmodmap bei jedem Login ein, Zeile 9 startet Urxvt im ressourcensparenden Daemon-Modus und von 11-14 benutze ich eine Funktion, um das Hintergrundfenster von X mit einer Statusanzeige zu versehen. Standardmäßig stellt DWM hier die eigene Versionsnummer dar.
Die Anzeige lässt sich mit dem Befehl Xsetroot verändern. Weitere interessante Beispiele gibt es unter dem Stichwort DWM im ... ArchLinux-Wiki. Ebenfalls bemerkenswert ist die Erweiterung dwmstatus, ein Grundgerüst, mit dem es möglich ist fortgeschrittene Statusanzeigen einzubauen.

Surf und Tabbed

Last but not least, im Zusammenspiel mit surf und tabbed ist DWM erst richtig vollständig. Wo surf unter einem "normalen" Fenstermanager vielleicht suspekt erscheint, spielt er hier seine wahre Stärke aus. Startet zuerst tabbed mit dmenu. Shift+Strg+Enter öffnet Surf direkt in den "Tabs", mit Strg+G geht es zur Adresszeile. URL eintippen und mit Shift+Strg h/l zum nächsten Tab wechseln.

Wie zuvor schon erwähnt, hat der Surf-Backport Probleme bei der Darstellung einiger Https-Seiten, weswegen Midori eine sinnvolle Alternative auf dem älteren Laptop bleibt.
Ich denke zum Thema DWM ist vorerst alles gesagt. Immer dann, wenn ich eine grafische Anwendung brauchen sollte, bietet er ab sofort einen Rückzugspunkt vom Konsolensetup mit Screen. 😉

Posted on

Einen maßgeschneiderten dwm-Fenstermanager von sid nach squeeze backporten

Obwohl ich denke, dass der Fenstermanager dwm in der Standardkonfiguration schnell zu erlernen und außerdem schlicht und ressourcensparend ist, wollte ich dennoch 2-3 Dinge verändern. Da Veränderungen bei dwm nur durch eine Neukompilierung möglich sind, habe ich die Gelegenheit genutzt und mich wieder etwas mehr mit der Erstellung eigener Debianpakete beschäftigt.
Ich hatte in dem Beitrag "Wie man Debian Pakete aus den Quellen baut" mehrere Methoden vorgestellt, wie man eigene Software speziell für Debian kompilieren kann. Die Pbuilder-Methode gefiel mir davon am besten. Erfolgreich wurde damit ein Mplayer nur für den Framebuffer und auch schon ein paar kleinere Backports erstellt.
Bevor ich meinen Weg zum Kompilieren und Anpassen von dwm vorstelle, wollte ich noch auf eine Alternative hinweisen. Im englischen Forum auf forums.debian.net gibt es schon eine sehr ausführliche Anleitung zum Kompilieren und Konfigurieren von dwm, die den Standardweg mit make und den Debian-Weg mit dpkg-buildpackage zeigt. Wie auch immer, ich denke Pbuilder ist noch einfacher.

Der elegante Weg mit pbuilder

Vorbereitung

aptitude install pbuilder
pbuilder create --distribution squeeze

oder wenn man z.B. i386-Pakete mit seinem AMD64-System bauen möchte

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

Quellen freischalten

deb-src http://ftp.de.debian.org/debian/ sid main in /etc/apt/sources.list hinzufügen.
Als normaler Benutzer das Quellpaket herunterladen und in das Quellverzeichnis wechseln.

apt-get source dwm
cd dwm-5.9/

Zwei Möglichkeiten

Möglichkeit 1

cp config.def.h config.h
vim config.h

Möglichkeit 2

cp config.def.h debian/local/config.apo.h
vim config.apo.h

Das Debian-Quellpaket bietet zum einen die Möglichkeit die Konfigurationsdatei wie gewohnt im Hauptverzeichnis editieren zu können oder aber im Debian-Verzeichnis. Der Paketverwalter von dwm hat hierzu einige Regeln angepasst, so dass beim Kompilieren auch alle Dateien im Verzeichnis debian/local in der Form config.*.h berücksichtigt werden.
Das hat später den enormen Vorteil, dass man gleichzeitig verschiedene Versionen von dwm übersetzen und später mit Debians update-alternatives Mechanismus auswählen kann.

Konfiguration

Ich habe die zweite Möglichkeit gewählt und die config Datei in debian/local namens config.apo.h modifiziert und folgende Dinge geändert.

  1. Farbe von hellblau auf dunkelgrau ändern
    static const char selbordercolor[] = "#333333";
static const char selbgcolor[] = "#333333";
  2. Anzahl der Tags von 9 auf 6 verringern
    static const char *tags[] = { "1", "2", "3", "4", "5", "6", };
  3. Anstelle der ALT-Taste die Super/Windows-Taste benutzen
    #define MODKEY Mod4Mask
  4. rxvt-unicode anstatt xterm benutzen
    static const char *termcmd[] = { "urxvtc", NULL };

Das war es auch schon. Mir war insbesondere der Wechsel von xterm zu rxvt-unicode und von ALT zu Mod4 wichtig, da es einige Programme gibt, bei denen die voreingestellte ALT-Taste zu Problemen führen kann.

Kompilieren

Das Quellpaket aktualisieren

dpkg-source -b dwm-5.9/

Als Benutzer root ausführen

pbuilder build dwm_5.9-1.dsc
Das fertige I386-Squeeze-Paket fällt in /var/cache/pbuilder/result heraus und muss danach nur noch auf dem Zielrechner mit dpkg -i dwm_5.9-1_i386.deb installiert werden.
Mit dem Befehl update-alternatives --config dwm lässt sich danach zwischen der Standardversion, der dwm.web und der dwm.apo Version umschalten.

Fazit

Ich denke die Pbuilder-Methode sollte man sich aus mehreren Gründen beim Bauen von Debianpaketen merken. Zum einen lässt sich damit in einer "Reinraum-Umgebung" ein Paket sauber kompilieren. Man kann auf einer AMD64-Maschine mit Debian Unstable I386-Pakete für Debian Stable bauen und darüber hinaus sogar mehrere Pbuilder-Umgebungen parallel installieren, in denen Pakete für Testing, Unstable oder auch Ubuntu gebaut werden können!
Beachten sollte man aber, dass dieser Backport noch nicht den offiziellen Ansprüchen genügt. Insbesondere wurde das Paket nicht richtig umbenannt, das Changelog nicht geändert oder persönlich mit GnuPG signiert. Aber für den privaten Hausgebrauch sollte es reichen. 😉
Als optionale Ziele hatte ich mir noch vorgenommen surf, den minimalistischen Webkit-Browser aus der Suckless-Familie, und rxvt-unicode-256color "backzuporten", da es für beide keine Version in Squeeze gibt.
Kurz gesagt: Surf lässt sich genauso einfach von Sid nach Squeeze backporten, er funktioniert auch, es gibt aber einen schweren Bug beim Aufruf von Https-Seiten, der so mit Debian Unstable nicht auftritt. Backports sind also unter Umständen gar nicht so schwierig, man sollte aber immer auch im Hinterkopf behalten, das Probleme nicht nur beim Übersetzen auftreten können. Mehr Details zu rxvt-unicode-256color und dwm demnächst auf diesem Kanal.

Posted on

Das fortlaufend nutzbare Debian Testing alias CUT

Nachdem ich CUT vor ein paar Monaten schon vorgestellt hatte, wollte ich kurz wissen wie es mit dem Vorschlag weitergegangen ist.
CUT hat einen eigenen Wiki-Webauftritt auf cut.debian.net erhalten. Dort befindet sich zur Zeit eine Übersicht über den Stand des Projekts, Hintergründe und Geschichtliches und verschiedene Informationen und Stichpunkte wie man intern mit dem Projekt umgehen sollte.
Zur Erinnerung: CUT soll im Wesentlichen vier Probleme mit Debian Testing beseitigen.

  1. Testing soll fortlaufend nutzbar und installierbar bleiben. Der Debian Installer soll aktuell aber zuverlässig arbeiten.
  2. Softwarepakete sollen nicht wie bisher "eingefroren" werden, sondern kontinuierlich aktuelle Software in CUT einfließen.
  3. Kein Entfernen von Paketen mehr, die Übergänge größerer Projekte blockieren (Gnome 3) oder die auf Grund von Fehlern nicht für Debian Stable in Frage kommen.
  4. Zeitnahe Sicherheitsaktualisierungen.

Für Punkt 1 gibt es nun seit der Ankündigung des ersten veröffentlichten Testing-Snapshots-Abbilder zum Download als ISO-Datei bzw. direkt als Apt-Quelle. Z.B.

deb http://snapshot.debian.org/archive/debian/20111130T223330Z testing main
deb-src http://snapshot.debian.org/archive/debian/20111130T223330Z testing main

All diese Versionen sind aber nach wie vor als inoffiziell anzusehen und ein Angebot für Entwickler und interessierte Benutzer. Trotzdem bieten sie eine Lösung für Punkt Nr.1.
Wie aus cut.debian.net hervorgeht, ist das Projekt weiterhin im Fluss und bei weitem nicht abgeschlossen. Es scheint zur Zeit eher unwahrscheinlich zu sein, dass mit CUT ein weiterer Debian-Zweig neben Experimental/Unstable/Testing und Stable geschaffen wird. Insbesondere steht nach wie vor die Frage im Raum, wie man es schafft genug Freiwillige zu motivieren, die gleichzeitig an Testing und an einer parallel entwickelten fortlaufend aktuellen CUT/Rolling-Version arbeiten, damit die nächste Veröffentlichung von Stable ihre herausragende Qualität behält.
Ich persönlich hätte als Nutzer Interesse an einer verbesserten Testing-Version, die auch meinetwegen gerne einen werbewirksamen Namen haben darf. Ideal wäre meiner Meinung auch, wenn Projekte wie Aptosid, die etwas sehr ähnliches für Debian Unstable machen, ihre Ressourcen mit CUT innerhalb des Debian-Projektes bündeln könnten.
Wie auch immer, ich finde es gut, dass das CUT-Team sich die Mühe macht. Wer auf dem Laufenden bleiben möchte, kann sich gerne auf der CUT-Team Mailingliste eintragen.

Posted on

Ein individuelles dmenu erstellen

Das gute dmenu wurde zwar primär für die Verwendung mit dem Fenstermanager dwm entwickelt, es lässt sich aber auch mit anderen kombinieren. Zum ersten Mal habe ich das dieses Jahr bei Crunchbang beobachtet, das auf Debian Squeeze und den Openbox-Fenstermanager setzt.
Doch zuerst einmal, so sieht dmenu für gewöhnlich aus.


Indem man die Anfangsbuchstaben des gesuchten Programms eintippt und das Ganze mit Tab vervollständigt, bewegt man sich in rasender Geschwindigkeit durch alle installierten Anwendungen, die im eigenen $PATH installiert sind. Programme werden danach durch Enter gestartet, fertig. Kein Warten, sehr effizient, Gnome-Do oder gar Unity und die Gnome-Shell werden dadurch zum Ausführen von Programmen überflüssig.
Normalerweise benötige ich bei Openbox und vergleichbaren Fenstermanagern nur das Rechtsklickmenü und ein paar Tastenkürzel. Mit dem Skript dmenu-bind.sh von Gatti Paolo lässt sich aus dmenu aber ganz leicht eine übersichtliche Menüstruktur erstellen.
Der Aufbau ist einfach und leicht nachzuvollziehen. Unter die Menüpunkte wie z.B. web werden der Name des Menüpunkts und der auszuführende Befehl geschrieben.

chromium "chromium"

oder

vim "urxvtcd -e vim"
In dem Menü kann man danach wie gehabt mit den Pfeiltasten und der Enter-Taste navigieren. Das Skript lässt sich z.B. in ~/.config/dmenu/dmenu-bind.sh abspeichern und in ~/.config/openbox/rc.xml oder mit Hilfe von obmenu an eine Taste binden.

<keybind key="A-F3">
  <action name="Execute">
    <startupnotify>
      <enabled>true</enabled>
        <name>dmenu-bind</name>
    </startupnotify>
        <command>~/.config/dmenu/dmenu-bind.sh</command>
  </action>
</keybind>

Das angepasste dmenu kann nun mit Alt+F3 aufgerufen werden.


Das gesamte dmenu-bind.sh Skript sieht so aus.

#!/bin/bash
#       Custom dmenu-bind.sh
#
#       Copyright 2009, Gatti Paolo (lordkrandel at gmail dot com)
#       Distributed as public domain.
#       09.28.2009 -- First release
#       09.29.2009 -- Submenu support added
if [ "$1" == "" ]; then
    title="MainMenu"
    menu=(
#               labels            commands
#           Main =========================================
                web               "$0 web"
                system            "$0 system"
                tools             "$0 tools"
                settings          "$0 settings"
    )
else
    case $1 in
    web)
        title="web"
        menu=(
#           Web ==========================================
                firefox           "firefox"
                lostirc           "lostirc"
         )
    ;;
    tools)
        title="tools"
        menu=(
#           Tools ========================================
                gedit             "gedit"
                geditsudo         "gksudo gedit"
         )
    ;;
    system)
        title="system"
        menu=(
#           System =======================================
                home              "pcmanfm"
                tilda             "tilda"
                synaptic          "gksudo synaptic"
         )
    ;;
    settings)
        title="settings"
        menu=(
#           Settings =====================================
                volume            "$0 volume"
                dmenu             "gedit $0"
                obconf            "obconf"
         )
    ;;
    volume)
        title="Volume"
        menu=(
#           Volume controls ==============================
                0%                "amixer sset Master 0"
                50%               "amixer sset Master 50"
                70%               "amixer sset Master 70"
                100%              "amixer sset Master 100"
         )
    ;;
    esac
fi
for (( count = 0 ; count < ${#menu[*]}; count++ )); do
#   build two arrays, one for labels, the other for commands
    temp=${menu[$count]}
    if (( $count < ${#menu[*]}-2 )); then
        temp+="n"
    fi
    if (( "$count" % 2 == "0" )); then
        menu_labels+=$temp
    else
        menu_commands+=$temp
    fi
done
select=`echo -e $menu_labels | dmenu -p $title -nb black -nf white -sb darkblue -sf white`
if [ "$select" != "" ]; then
#   fetch and clean the index of the selected label
    index=`echo -e "${menu_labels[*]}" | grep -xnm1 $select | sed 's/:.*//'`
#   get the command which has the same index
    part=`echo -e ${menu_commands[*]} | head -$index`
    exe=`echo -e "$part" | tail -1`
#   execute
    $exe &
fi
Posted on

Elitäre Fenstermanager sind vielleicht doch einfacher zu bedienen als gedacht

Das Problem bei kachelnden Fenstermanagern ist, dass sie zum einen mit ihren Namen schon einen sonderbaren Eindruck hervorrufen und sie sich zum anderen selbst als ein Werkzeug für Poweruser oder die technische Elite empfehlen. Was auch immer das genau bedeuten mag.
Ich hatte letztes Jahr Awesome und später auch ratpoison auf dem Portégé 3110CT ausprobiert und an beiden Gefallen gefunden, da sie nach kurzer Eingewöhnungsphase äußerst sparsam mit den begrenzten Ressourcen umgingen und mit Hilfe der voreingestellten Tastenkürzel sich der kleine Laptop auch effizienter bedienen ließ.
Für den Thinkpad 600 habe ich zusätzlich zu all den Konsolenanwendungen neben dem Xorg-Server und Qingy zum Login nun auch DWM, den Dynamic Window Manager, installiert. DWM treibt es zwar mit dem elitären Dünkel, nicht aber mit dem Ressourcenverbrauch auf die Spitze. Im Gegenteil zeigt mir htop an, dass DWM sich gerade einmal mit 0.6% von 128 MB RAM begnügt.
DWM ist deshalb so besonders, da der Fenstermanager in einer einzigen Binärdatei ausgeliefert wird und sich aus nur 2000 Zeilen Code zusammensetzt. Die Konfiguration erfolgt über das Editieren einer Headerdatei der Programmiersprache C, wodurch DWM den Ruf weg hat nur etwas für Profis zu sein. Die Entwickler bringen das so auf den Punkt:

Because dwm is customized through editing its source code, it’s pointless to make binary packages of it. This keeps its userbase small and elitist. No novices asking stupid questions. There are some distributions that provide binary packages though.

Eine dieser Distributionen, die Binärpakete von dwm bereitstellt, heißt natürlich Debian. Für einen Test, ob einem DWM gefällt oder nicht, genügt wie immer:
aptitude install dwm
Bei meiner Konfiguration konnte ich danach im Loginmanager Qingy DWM als neue Session auswählen und landete nur wenige Sekunden später genau dort.


Das Bedienungsprinzip von DWM ist ziemlich einfach und es gibt sogar ein kurzes offizielles Tutorial dazu.
Am oberen Bildschirmrand befindet sich das Panel mit den sogenannten Tags, die sich zwar aus Benutzersicht ähnlich zu Arbeitsflächen verhalten, aber dennoch nicht das Selbe sind. Jede neue Anwendung erscheint zuerst im Master-Fenster und existierende werden nach rechts auf den sogenannten Stack verschoben. Wie der Screenshot zeigt habe ich vier Terminals geöffnet (Shift+ALT+Enter), wovon drei Terminals rechts im Stack angeordnet sind und das Hauptfenster die restliche Hälfte einnimmt.
Mit Hilfe von Alt+j/Alt+k lässt sich der Reihe nach der Fokus auf ein anderes Fenster wechseln. Mit Alt+h/Alt+l lassen sich die Fenster des Stacks horizontal verbreitern oder verkleinern. Zwischen einem ausgewählten Stackfenster und dem Hauptfenster lässt sich mit Alt+Enter wechseln.
DWM bietet standardmäßig drei verschiedene Modi. Alle Fenster werden automatisch im Tiling Modus (Alt+t), also kachelnd, angeordnet. Möchte man ein Fenster im Vollbild betrachten, muss man mit Alt+m in den Monokelmodus wechseln.


Um die Fenster frei zu bewegen und mit der Maus in der Größe anpassen zu können, gibt es den Schwebemodus alias Floating. (Alt+f) Wenn man die Alt-Taste gedrückt hält, kann man mit einem Druck auf die linke Maustaste das Fenster verschieben und mit der rechten Maustaste es vergrößern oder verkleinern.


Warum die Tags sehr nützlich sein können, erkennt man schnell am obigen Bildschirmfoto. So lässt sich zum Beispiel der ausgewählte Browser mit Shift+Alt+3 auf Tag Nr. 3 verschieben und mit Alt+1 und Alt+3 zwischen Tag 1 und 3 wechseln. Doch wenn man sich auf Tag 1 befindet und Tag 3 mit einem Rechtsklick sozusagen "zuschaltet", erscheinen alle Fenster dieses Tags auch auf dem aktuellen. Da sich DWMs Modi "on-the-fly" anpassen lassen, kann das Browserfenster dann schwebend über allen anderen positioniert werden.
Noch nützlich zu wissen ist das Kommando Shift+Alt+c, mit dem Fenster und darin laufende Anwendungen beendet werden und Shift+Alt+q, womit man sich von DWM abmeldet und wieder zurück zum Loginmanager gelangt.
Wer nicht alle Applikationen aus einem Terminal ausführen will, sollte sich noch die suckless-tools installieren, in denen sich unter anderem dmenu und slock zum Bildschirm sperren befinden. Dmenu lässt sich dann mit Alt+p aufrufen. Dmenu funktioniert in etwa wie die Gnome-Shell...nur viel, viel effizienter und schneller. 🙂
Ein paar kleine Details möchte ich bei DWM später noch ändern, aber zum schnellen Ausprobieren oder als Lösung für eine leichtgewichtige Desktopumgebung ist das Binärpaket bei Debian schon gut geeignet.

Posted on

Ein wahrer Klassiker: Mein Commodore C64

Das Jahr neigt sich dem Ende entgegen und wenn ich zurückblicke habe ich einige Beiträge zu den älteren Rechnern des Haushalts geschrieben. Doch einen habe ich bisher immer absichtlich verschwiegen.


Wie das geschulte Auge schnell erkennt, das ist der Commodore 64. Als echter Computerklassiker würde der C64 meiner Meinung nach ein eigenes Blog verdienen und es gibt mehr als genug Leute, die das schon mit Bravour in Angriff genommen haben. Das Netz ist voll mit Informationen zum guten alten Brotkasten und ich freue mich nach wie vor, dass die Gemeinschaft weiterhin so groß und aktiv ist.
Immer wenn ich denke, dass ich irgendetwas tolles mit einem meiner Laptops erreicht habe, muss ich an den C64 denken, der vor drei Jahrzehnten Dinge mit 64 Kilobyte RAM vollbracht hat, an denen heute selbst Multicore-Rechner noch scheitern.
Vielleicht erinnert sich der ein oder andere an meinen Link zum 286er-Webserver. Das ist sicherlich mehr als beeindruckend, zumindest bis man den C64 Webserver gesehen hat. 🙂
Und immer dann, wenn ich etwas zu Betriebssystem XY schreibe und womöglich 100 andere Alternativen vergessen habe, dann denkt an Contiki zurück, welches den C64-Webserver antreibt.
Außerdem ist der Commodore C64 bei Leibe kein Museumsstück oder Auslaufmodell. Es gibt ihn selbst heute noch, in einer etwas moderneren Version, aber mit der gleichen Optik, zu kaufen. 🙂
Wie ich zum C64 gekommen bin? Nun meine Eltern hatten mich damals vor die Wahl gestellt. Entweder der C64 oder die neue Weltraum-Eisenbahn von Lego. *Seufz* Wohlstandsprobleme deutscher Kinder. 😛
Als ich dann später auf den Amiga 500 umsteigen wollte, wurde ich leider gezwungen den C64 zu verkaufen. Zwei Rechner gleichzeitig zu besitzen, das ging nun wirklich nicht. Ich vermute Sigmund Freud würde dies in seiner Psychoanalyse sicher als Grund ansehen, warum ich heute ein Blog über mehrere alte Laptops führe. 😀
Hier noch mal ein Foto zum Schmunzeln. Unverkennbar aus welchem Jahrzehnt diese Verpackung zum C64 stammt.


Moment ich wurde doch gezwungen den C64 abzugeben. Wieso habe ich nun wieder einen? Nun vielleicht war es Mitleid mit einem Geek oder einfach nur Freundlichkeit, aber eine Freundin hat mir ihren C64 mit samt ihrer Spielesammlung viele Jahre später einfach geschenkt.
Ein kleiner Auszug


Deswegen besitze ich bis heute noch einen funktionsfähigen Commodore 64. Wer nun etwas Interesse an einem C64 und einigen Spielen bekommen hat, sich aber nicht extra die Hardware dazu anschaffen möchte, hat natürlich die Möglichkeit mit Hilfe eines Emulators zurück in die Vergangenheit einzutauchen.
Installiert euch einfach ein Linux und den Emulator Vice, womit ihr die besten Chancen habt ein wenig vom Charme und Erbe des C64 zu erfahren. Unwidersprochen der C64 war natürlich damals schon ein phantastischer Computer für Spiele.
Wer sowohl die Hardwareanschaffung als auch Vice scheut, kann sich leicht mit ein paar Minuten Zeit in die Ära des Commodore zurückversetzen. Hier einmal das Intro zu Turrican II als Umsetzung auf dem Amiga 500. Mit Sicherheit eines meiner damaligen Lieblingsspiele und insbesondere die Musik von Chris Hülsbeck hatte ich regelmäßig auf Wiederholung. Das war zu einer Zeit als die Endgegner noch furchteinflößende Namen wie "The Machine" hatten. 😀

Posted on

Eine weitere simple Backup-Methode: Partclone, TinyCore und sshfs

Ein Backup zu machen ist das A und O. Ein Satz, den man regelmäßig liest und dem man auch zustimmen kann, nur um es dann doch auf die lange Bank zu schieben bis es schließlich zu spät ist. So etwas nennt man dann PP, Persönliches Pech. 😮
Die Auswahl für ein Backup reicht von Keep it simple, über "The Debian Way" bis hin zu einer kompletten Linuxdistribution, die Festplatten und Partitionen klonen und wiederherstellen kann.
Auf etwas älteren Laptops wie dem Thinkpad 600 funktioniert für mich auch die Partimage-Methode, indem ich von meinem Debian Stable aus eine weitere Partition sichere und bei Bedarf wieder einspiele.
Trotzdem ich freundlicherweise sogar Bilder zur Verfügung gestellt bekommen habe, wie man mit Hilfe von Clonezilla selbst mit nur 128 MB RAM ein vollständiges Festplattenbackup machen kann, hat dies bei mir leider noch nicht hingehauen.
Da es aber keine Rolle spielt, welche Linuxdistribution man benutzt, sondern nur, DASS es funktioniert, bin ich ziemlich glücklich, dass ich mit TinyCore nun die Möglichkeit habe ein vollständiges Backup durchzuführen.
Dazu muss man lediglich noch die Erweiterungen partclone.tcz und sshfs-fuse.tcz installieren. Partclone bietet gegenüber Partimage den Vorteil mehr Dateisysteme sichern zu können, darunter auch ext4 und btrfs.
Mit Hilfe von SSH lässt sich ein entferntes Dateisystem auf einem anderen Rechner einhängen und das Backup direkt an diesen Computer übertragen. Bei TinyCore muss man entweder die Rechte für den Standardnutzer tc konfigurieren oder mit sudo su als root die folgenden Kommandos ausführen.

Mit dem entfernten Rechner verbinden

mkdir /home/tc/backup
sshfs user@192.168.0.201:/home/user /home/tc/backup

Partition mit Partclone sichern

partclone.extfs -c -d -s /dev/sda2 -o /home/tc/backup/20111205_hal600_sda2.img

Partition mit Partclone wiederherstellen

partclone.restore -d -s /home/tc/backup/20111205_hal600_sda2.img -o /dev/sda2

MBR mit dd sichern

dd if=/dev/sda bs=512 count=1 of=/home/tc/backup/20111205_hal600_mbr.img



Mit den oben genannten Beispielen habe ich sowohl die zweite Partition der Thinkpad 600 Festplatte als auch den MBR und die Partitionstabelle gesichert und mit Hilfe des SSH-Dateisystems an einen entfernten Rechner übertragen. Je nach Interesse lassen sich mit TinyCore noch eine ganze Reihe anderer Möglichkeiten mit älterer Hardware verwirklichen.

Posted on

Linux im RAM: Erfahrungen mit TinyCore auf dem Thinkpad 600

Nachdem die allgemeinen Hardwareprobleme wieder im Griff sind, wird es Zeit die Erfahrungen mit TinyCore zusammenzufassen. Ich habe mich nach meinem letzten Beitrag zum Thema "TinyCore remastern" noch etwas mit der Konfiguration dieser minimalistischen Linux-im-RAM-Distribution beschäftigt und lade die gefundenen Erkenntnisse hier einfach mal ab.

TinyCore auf dem Thinkpad 600

Da ich festgestellt habe, dass der standardmäßig installierte XVesa-Treiber nur eine unzureichende Bildschirmauflösung bietet und alles grünlich verzerrt, habe ich den Xorg-Server in Version 7.6 installiert. Als Ausgangsbasis zum weiteren Testen habe ich mir den Vorschlag von Heinz zu Herzen genommen und den Browser "Bon Echo", alias Firefox 2.0 mit GTK1-Bibliothek, Fluff, ein Dateimanager auf Basis von FLTK und kmaps für die deutsche Tastaturbelegung installiert. Nur an der Option "Add app inside intitrd on boot" konnte ich danach nicht mehr festhalten.
Ich denke, es liegt nicht an der Größe meines Arbeitsspeichers, 128 MB sind ausreichend um all diese Erweiterungen direkt beim Booten in den RAM zu kopieren. Dennoch wird der Xorg-Server nicht aktiviert und TinyCore fällt auf den XVesa-Modus zurück. Das Problem ließ sich nur durch Remastern mit der Option "Add app outside initrd on boot" beseitigen. Das bedeutete zwar, dass ich den USB-Stick nicht mehr entfernen konnte, gleichzeitig sinkt dadurch aber auch der benötigte Verbrauch an RAM, weswegen diese Methode für die älteren Rechner mir nun als der bessere Weg erscheint. Die Startzeit beim Booten wird ebenfalls verkürzt, hingegen erhöht sich die Wartezeit beim ersten Aufruf der Erweiterung.

Apps Audit

Natürlich kann man TinyCore auch komplett in Virtualbox remastern und wie im letzten Beitrag zu diesem Thema erwähnt, überflüssige Extensions der Multicore-Version entfernen und Konfigurationsdateien schon vor dem ersten Remastern bearbeiten.
Da das langweilig war, bin ich sofort nach dem Beenden von Ezremaster auf den Thinkpad 600 gewechselt und habe dort dann alle weiteren Anpassungen vorgenommen. Mit Hilfe der Anwendung "Apps Audit", grob vereinfacht eine Mischung aus Ubuntus Softwarecenter und Synaptic :D, lassen sich Extensions entfernen und das System auf den neusten Stand bringen und einstellen, welche Erweiterungen schon beim Booten (OnBoot) und welche erst auf Nachfrage (OnDemand) in den RAM geladen werden.

  • Pakete entfernen. Dependencies -> Build Reporting Database -> Extension auswählen -> Mark for Deletion -> Rebooten (mit Backup!)
  • System aktualisieren. Updates -> Check for Updates
  • Erweiterungen beim Booten laden. OnBoot -> Maintenance -> Extension wählen
  • Erweiterung nach Anfrage laden. OnDemand -> Maintenance -> Extension wählen
Apps Audit

AppBrowser

Applikationen, Softwarepakete sagen die einen, TinyCore nennt es Extensions. Diese Anwendungen lassen sich mit dem AppBrowser installieren. Er ist denkbar einfach zu bedienen. Mit Connect verbindet man sich zum TinyCore-Repositorium, danach nur noch die Erweiterung auswählen und aus den vier Modi wählen. Ich habe hier wie auch zuvor OnDemand gewählt und als weiteres App Dropbear, den winzigen SSH-Client und -Server installiert.
Alle Erweiterungen werden als Loop-Device eingehängt und dann lediglich mit dem Dateisystem verlinkt. Im Prinzip verhalten sich deshalb TinyCores Extensions ähnlich wie die IMG-Dateien eines Mac. Möchte man Programme deinstallieren genügt es einfach die TCZ-Datei zu löschen.

AppBrowser

Netzwerk

Das Letztere wäre ohne funktionierendes Netzwerk nicht möglich gewesen. Ich versuchte es zuerst mit meiner WLAN-Karte ASUS WL-107G mit Ralink-Chipsatz und dem Kerneltreiber rt2500pci. Der Linuxkernel erkannte die Karte wie gewohnt automatisch und da ich sowohl alle Wifi-Programme und auch wpa_supplicant von der Multicore-Version behalten hatte, funktionierte die minimalistische Netzwerkanwendung wifi.tcz problemlos. Zumindest für ca. 30 Sekunden hatte ich danach drahtlosen Internetzugang mit WPA-Verschlüsselung. Danach fror das System leider ein. Auch der Weg über die Kommandozeile half nicht weiter.
Ich tauschte danach die Karte gegen eine der 3com PCMCIA Karten aus, mit der es schließlich problemlos möglich war eine kabelgebundene Verbindung mit eth0 als Schnittstelle aufzubauen.

Netzwerk + Control Panel

Persistenz

Ein ganz wichtiges Thema bei TinyCore ist Persistenz. Nach dem Ausschalten des Computers sind gewöhnlich alle Daten, die vorher in den RAM geladen wurden verschwunden. Damit man sowohl seine Erweiterungen als auch wichtige Systemeinstellungen nach dem Reboot weiterverwenden kann, bietet TinyCore zwei grundlegende Möglichkeiten an.

  1. Dauerhaftes /home-, /opt- und /tce-Verzeichnis. Mit Hilfe von Bootcodes lässt sich TinyCore schon beim Starten anweisen die /home-, /opt- und /tce-Verzeichnisse dauerhaft auf einem Datenträger anzulegen. Beim Remastern mit dem schon vorgestellen Ezremaster ist das Schritt Nr.2. Die Bootparameter lassen sich auch nachträglich ändern. Die entsprechende Datei befindet sich in /mnt/sdb1/boot/extlinux und heißt extlinux.conf, wobei sdb mein eingehängter USB-Stick ist.Die Bootparameter lassen sich an die Zeile APPEND anhängen. Wer wie ich TinyCore auf einen USB-Stick installiert und Extensions außerhalb der initial ramdisk installiert hat, stellt fest, dass das TCE-Verzeichnis automatisch persistent angelegt wurde. D.h. alle Erweiterungen, die man mit dem Appbrowser in /mnt/sdb1/tce/optional installiert, werden gespeichert.
    Ausführlicher erklärt wird es im TinyCore-Wiki im Artikel "Persistence for Dummies".
  2. Backup. Die intuitivste und wahrscheinlich auch einfachste Methode ist es ein Backup zu machen. Beim Abmelden kann man zwischen den drei Optionen None, Backup und Safe auswählen, also entweder nicht speichern, ein Backup machen oder ein Backup machen und das alte Backup zusätzlich sichern. Alle Dateien und Informationen werden dann gepackt und im /tce-Verzeichnis als mydata.tgz gesichert. Was genau gespeichert oder nicht gespeichert werden soll, lässt sich in zwei einfachen Textdateien festlegen. Im /opt-Verzeichnis befinden sich die versteckten Dateien .filetool.lst und .xfiletool.lst. Die erste Datei ist eine Whitelist, in der Verzeichnisse und Dateien aufgeführt sind, die gesichert werden sollen. Die .xfiletool.lst ist das Gegenstück dazu, in der Dateien vom Backup ausgeschlossen werden können.Dabei gilt: .xfiletool.lst > .filetool.lst, wodurch es möglich ist Verzeichnisse auf eine Whitelist zu setzen, aber darin enthaltene Dateien vom Backup auszuschließen.

Folgende Dateien und Verzeichnisse habe ich zusätzlich zu den Voreinstellungen zum Backup hinzugefügt oder ausgeschlossen.

.filetool.lst

etc/X11/xorg.conf
opt/eth0.sh
opt/wpa_supplicant.conf
etc/passwd
etc/shadow
etc/dropbear

.xfiletool.lst

.mozilla/

Deutsche Tastaturbelegung

Xorg

Da ich den Xorg-Server benutze, ist es notwendig, dass man die Einstellungen zur deutschen Tastaturbelegung manuell in /etc/X11/xorg.conf ändert. Die Vorgehensweise habe ich vor kurzem etwas ausführlicher beschrieben. Im Prinzip ist es das gleiche Spiel wie bei ConnochaetOS oder Slitaz. Als Eintrag genügt aber in der Regel schon:

Section "InputDevice"
  Identifier "Keyboard"
  Driver "kbd"
  Option "XkbLayout" "de"
EndSection

Für Leserinnen und Leser aus der Schweiz und Österreich sollte natürlich auch ch und at funktionieren. 🙂 Nicht vergessen die xorg.conf in die .filetool.lst einzutragen!

Konsole

Für die virtuelle Konsole benötigt man das Paket kmap.tcz und die passende deutsche Keymap. Der folgende Befehl sollte in /opt/bootlocal.sh eingetragen werden. Er wird dann automatisch beim Start ausgeführt.

loadkmap < /usr/share/kmap/qwertz/de-latin1.kmap

Dropbear

Dropbear ist ein kleiner SSH-Client und -Server und der passende Ersatz, wenn man die gleiche Sicherheit wie mit OpenSSH haben möchte, aber auf die sftp Fähigkeit verzichten kann. Zum Starten von Dropbear trägt man den Befehl
/etc/init.d/dropbear start
in die /opt/bootlocal.sh ein. Gleichzeitig muss der Standardbenutzer tc ein Passwort erhalten (passwd) und die Dateien /etc/passwd, /etc/shadow und das gesamte /etc/dropbear Verzeichnis persistent gemacht werden.

Hintergrundbild einrichten

Das Hintergrundbild lässt sich spielend leicht ändern. Kopiert euer bevorzugtes Bild einfach nach /opt/backgrounds. Anschließend lässt sich im Control Panel unter "Wallpaper" das neue Hintergrundbild einrichten. So lässt sich ganz leicht aus TinyCore ein Ubuntu Oneiric Ocelot machen. 😉

Auf ein Wort

Es ist schon erstaunlich, dass es Freie Betriebssysteme gibt, die nicht nur auf 13 Jahre alter Hardware funktionieren, sondern dann auch noch komplett im RAM laufen können.
Ich denke TinyCore ist ein Beispiel dafür, dass man sowohl ältere Hardware als auch innovative Konzepte unter einen Hut bringen kann. TinyCore ist kein Abklatsch irgendeines bekannten Mainstream-Linux, dass sich an der Vorarbeit anderer gütlich tut und nur das Desktopthema austauscht.
Vollkommen zufrieden bin ich aber noch nicht. Die WLAN-Karte muss/sollte funktionieren. TinyCore auf eine Festplatte zu installieren ist zwar möglich, das halte ich aber nicht für den eigentlichen Verwendungszweck dieser Minidistribution. Zu rudimentär ist auch der Installer, als dass er einen ernsthaften Vergleich mit Debian oder Ubuntu standhalten könnte. Ideal ist TinyCore für den privaten Desktopbenutzer, der ein maßgeschneidertes Linux für einen USB-Stick und für den RAM sucht.
TinyCore bietet einige technisch einfache und effiziente Systemprogramme, die ideal für ältere Rechner geeignet sind, da sie kaum Ressourcen in Beschlag nehmen. Sie sehen zwar optisch nicht überwältigend aus, verrichten aber zielgerichtet ihren Dienst.
Debian, Slitaz oder ConnochaetOS halte ich für eine Festplatteninstallation auf dem Thinkpad 600 für die bessere Alternative, keine der Drei lässt sich aber so schnell und einfach mit 128 MB oder weniger in den RAM installieren, wobei man mit TinyCore eine grafische Oberfläche standardmäßig geboten bekommt.
Wenn man also ein bestehendes Betriebssystem nicht verändern möchte und gleichzeitig verschiedene Optionen von "Was man mit alten Computern machen kann" ausprobieren will, bietet sich TinyCore als eine ideale Möglichkeit an.
Wie immer muss man die Vor- und Nachteile für sich selbst abwägen. Fakt ist, TinyCore belegt momentan mit allen Erweiterungen gerade einmal 65 MB Speicherplatz, was es ideal für meinen 128-MB-USB-Stick macht. 😉
Nach dem Booten zeigt mir htop an, dass TinyCore 30 MB RAM in Anspruch nimmt. Mit Bon Echo, Fluff und ein paar Systemprogrammen komme ich auf 68 MB. Mehr als genug gute Gründe, um die Entwicklung von TinyCore in Zukunft weiter zu verfolgen.

Speicherverbrauch und Fluff
BonEcho

Links

TinyCore Wiki
TinyCore Forum
Anleitung zu TinyCore als Webserver

Posted on

Nur gute Nachrichten

Heute ist mir eingefallen, dass es eine ganz einfache Möglichkeit gibt herauszufinden, ob ein Rechner Hardwareprobleme mit sich herumträgt oder einfach nur die Software verbugt ist. Man muss nur ein älteres Backup einspielen als alles noch problemlos funktionierte und die Ergebnisse mit der aktuellen Situation vergleichen. 🙄
Nachdem ich diesen Geistesblitz hatte, schnappte ich mir ein mehr als zwei Monate altes Partitionsabbild meines minimalen Debian-Spielesystems, holte Clonezilla wieder hervor, spielte das Image ein und siehe da, keine X-Server-Abstürze und auch keine wirren Nvidia-Treiber-Fehlermeldungen mehr.
Besser so herum als feststellen zu müssen, dass man sich eine neue Graka oder gar PC kaufen muss. Wie zu erwarten war steckt der Fehlerteufel irgendwo zwischen den neuesten Nvidia-Treibern und dem Xorg-Server. Nur um zu sehen wie effektiv das Ganze ist, habe ich nun alle Nvidia- und Xorg-Pakete mit aptitude auf "hold" gesetzt und bin gespannt wie sich das System in Zukunft verhalten wird.
Für ein Spielesystem halte ich zwar nach wie vor aktuelle Treiber für das A und O, doch diese gegen ein instabiles System einzutauschen macht keinen Sinn. Klammert man das Treiberproblem aus, funktioniert Debian Unstable auf der Maschine ausgezeichnet. Als Alternative bietet sich in Zukunft zum Vergleich an einmal Debian Stable zu installieren und die Treiber und den Xorg-Server aus den Backports oder sogar manuell zu installieren.

Debian Backup und Neuinstallation

Da ich gerade in Schwung war, habe ich mich entschieden das parallel installierte Hauptsystem auf Basis von Debian Testing (i386) gegen ein amd64 gleichen Typs auszutauschen. Als ich die Idee zu dem Multibootsystem hatte, wollte ich mit i386 auf Nummer sicher gehen, aber da der Core Duo 64bit unterstützt und ich Debian Testing darauf ausschließlich als Arbeits-PC benutze, macht es keinen Sinn an i386 festzuhalten.
Da ich nicht bis zur Marktreife von Multiarch warten wollte, wenn es möglich sein wird ein i386 System auf amd64 upzugraden, habe ich mich für die althergebrachte Neuinstallation und "The Debian Way" entschieden. Ich hatte das komplette Home- und Etc-Verzeichnis gesichert, auf die Paketliste von dpkg aber verzichtet.
Es genügte vollkommen das Verzeichnis /home nach der Neuinstallation wieder einzuspielen und eine Handvoll Konfigurationsdateien aus dem alten Verzeichnis /etc manuell in das neue zu verschieben. Metapakete wie gnome-core waren schnell installiert und auch der Rest war lediglich ein

aptitude install Paketname

Nun muss sich das RAM-Problem nur noch irgendwie von selbst lösen. 😉

Posted on

Linux Mint MGSE, MATE und Gnome-3-Shell-Erweiterungen per Mausklick installieren

In Sachen Gnome-3-Erweiterungen passiert in letzter Zeit einiges. Dieser Beitrag ist für alle Zweifler, Nörgler und Nostalgiker, die am liebsten bis an das Ende aller Tage Gnome 2 benutzen möchten, genauso wie für alle euphorischen Enthusiasten, die die Veränderungen um der Veränderung willen bejubeln. Ihr habt nun die Möglichkeit das Rad der Zeit zurückzudrehen oder selbst Teil eines neuen Zeitalters zu werden. *Pathos Schilder und epische Musik im Hintergrund*

Linux Mint Gnome Shell Extensions (MGSE)

Seit dem 26. November 2011 steht Linux Mint 12 "Lisa" in den Internetregalen. Wer dachte, dass Linux Mint Ubuntus Unity-Desktop hinterherhecheln würde, sah sich getäuscht. Mit der aktuellen Version führt das Mint-Team eine neue Erweiterung zu Gnome 3 ein, die schlicht Mint Gnome Shell Extensions genannt wird. Im Prinzip gelingt Linux Mint der Spagat, zum einen den traditionellen Mint-Desktop im Stil von Gnome 2 mit dem besonderen Mintmenü beizubehalten und zum anderen alle neuen Schmankerl von Gnome 3 hinüber zu retten. So wird Gnome 3 äußerlich und optisch wieder zu Gnome 2.

Ich denke Linux Mint hat hier gute Arbeit geleistet, den eigenen Markenkern aufpoliert und eine sehr gute Gnome-Shell-Erweiterung entwickelt. Idealerweise sollte MGSE aber bald Upstream, also vom Gnome 3 Projekt selbst, als Erweiterung aufgenommen werden und dann der gesamten Freien Software Welt zur Verfügung gestellt werden.
Im Moment lassen sich Mints Gnome Shell Extensions außerhalb von Linux Mint zum Beispiel als PPA bei Ubuntu installieren, was unter dem Stichwort "Gnome Shell Extensions" im Wiki von ubuntuusers.de wie immer gut erklärt wird.
Auf MGSE bin ich aufmerksam geworden, als ich die "debian-devel"-Mailingliste überflogen habe, wo es schon die erste Anfrage gab, ob nicht irgendjemand MGSE für Debian paketieren möchte. Für Debian gibt es zwar noch kein Paket, wer aber Sid benutzt kann die Erweiterung MGSE direkt aus GIT herunterladen und den dortigen Anweisungen zur manuellen Installation folgen.

MATE

MATE ist eine Abspaltung von Gnome 2, die sich zumindest bei Linux Mint 12 und bei Arch Linux aus AUR parallel zu Gnome 3 installieren lässt. Das MATE-Projekt scheint im Juni diesen Jahres im Arch-Linux-Forum entstanden oder zumindest angekündigt worden zu sein. Der dortige MATE-Thread wird bis heute fortgeführt.
Ohne Zweifel ein sehr ambitioniertes Projekt, das scheinbar im Moment nur von einigen Einzelpersonen aus Argentinien vorangetrieben wird. Viele zentrale Gnome-2-Anwendungen sind schon auf GTK3 portiert worden. An vielen Stellen wurde aber auch nur der Name umbenannt und aus Nautilus wurde Maja, aus Metacity Marco und aus gconf mate-conf. Ziel soll es sein Gnome 2 fortzuführen und den "klassischen" Desktop weiterzuentwickeln. Wie ein Debian-Entwickler im oben genannten Link auf der Mailingliste schon kritisch bemerkte, muss MATE zuerst einmal eine kritische Masse erreichen, damit überhaupt jemand daran denkt diese neue alte Desktopumgebung für Debian zu packen.
Ich denke, dass es nicht damit getan ist ein paar Anwendungen umzubenennen und für GTK3 zu kompilieren. Eine Weiterentwicklung kostet viel Zeit und Aufmerksamkeit, weshalb ich nicht daran glaube, dass MATE langfristig erfolgreich sein kann. Es ist deutlich einfacher den MGSE-Weg von Linux Mint zu gehen und die Gnome-Shell auf Grundlage von Gnome 3 neu zu designen, wobei gleichzeitig sicher gestellt ist, dass erfahrene Gnome-3-Entwickler diesen Weg für die Zukunft unterstützen werden. Trotzdem zeigt es aber auch den großen Vorteil Freier Software. Wenn man mit etwas unzufrieden ist, ist es ausdrücklich erlaubt es zu ändern und man muss nicht damit rechnen mit Patentklagen überzogen zu werden.
Wer wirklich an Gnome 2 hängt sollte die Installations-CD von Debian Squeeze mit Gnome-Desktop herunterladen und sich bis 2014 an einem äußerst zuverlässigen und stabilen System freuen oder trotz aller Nostalgie ernsthaft über eine reine Fenstermanager-Lösung wie Openbox plus Tint2 nachdenken (oder Enlightenment 😉 ), die ein vergleichbares Desktoperlebnis bieten können und wesentlich reaktionsfreudiger sind.

Gnome Shell Extensions per Mausklick installieren

Wer kennt nicht Minority Report, wo Tom Cruise spielend leicht mit ein paar Handbewegungen Bilder und Anwendungen seines gläsernen Computers bewegt. (Den uncoolen und nicht-drahtlosen Datenaustausch mit Hilfe einer Plexiglasscheibe vergessen wir besser).
Was spricht dagegen in nicht allzu ferner Zukunft seinen Desktop online einfach per Sprachsteuerung oder wilden Bewegungen zusammenzustellen? Warum nicht schon heute?
Mit extensions.gnome.org gibt es nun die brandneue Möglichkeit Gnome-3-Shell-Erweiterungen per Mausklick direkt im Browser zu installieren. Denkt an Firefox Addons und ihr ahnt wie das Ganze funktioniert. Im Moment ist die Anzahl zwar noch begrenzt, aber dort findet sich z.B. schon ein Anwendungsmenü im Stil von Gnome 2, ein Panel und die Möglichkeit Anwendungen aus dem Gnome Panel zu starten.
Einziger Haken bei der Sache: Man muss Gnome 3.2 installiert haben und auf Grund eines Bugs mit Webkit-Browsern vorerst besser Firefox/Iceweasel zum Installieren benutzen.

Moment...das bedeutet.
Gnome 2 ist zurück!
MGSE ist schön, MATE ist eine weitere Alternative, doch die Zukunft des modernen Linuxdesktops ist heute, hier und jetzt Gnome 3 mit seinen per Mausklick installierbaren Erweiterungen! (Nun, muss ich nur noch die versprochenen Millionen der Gnome-Entwickler für diese schamlose Werbung eintreiben. So geht das KDE :P)