Anfang des Monats dachte ich, ich hätte alles unter Kontrolle und könnte damit leben. Schließlich hatte sich herausgestellt, dass der große und mächtige Core-Duo-Rechner zwar ab sofort nur noch mit 2 GB RAM bestückt werden konnte, merkwürdige Fehlermeldungen und Abstürze sich aber wahrscheinlich auf den aktuellen Nvidia-Treiber bezogen hatten, weswegen ich ein älteres Backup aufspielte und die betreffenden Treiber auf "halt" setzte. Zumindest von den beängstigenden Segfault-Fehlern war weit und breit nichts mehr zu sehen. Doch dann kam der Tag als ich eine recht große Datei komprimieren wollte, bzip2 sich aber im Laufe des Prozesses schlicht weigerte fortzufahren. Interessanterweise erschien eine sehr ausführliche Fehlermeldung, dass dieser Fehler wahrscheinlich im Zusammenhang mit fehlerhaftem RAM stehen könnte....Möglicherweise war da ja was dran.
Ich startete den Rechner neu und sah..Schwärze. Irgendwann funktionierte dann nicht mal mehr der Einschaltknopf, weswegen ich die Faxen dick hatte und mir ein neues Mainboard kaufte. Ich suchte zuerst nach dem identischen Modell P5N73-CM, um auch der kleinsten Möglichkeit von Inkompatibilität aus dem Weg zu gehen, musste aber leider feststellen, dass sich dieser Typ in den vergangenen 2,5 Jahren äußerst rar gemacht hatte. Ich entschied mich schließlich für das P5QPL-AM von ASUS, welches vergleichbare Spezifikationen hatte. Natürlich schaute ich vorher noch einmal nach dem empfohlenen RAM-Speicher auf der Herstellerseite, von TEAM-RAM aber keine Spur. Ich kreuzte also alle Finger und siehe da 2x2 GB TEAM TVDD2048M800 Module laufen stabil in diesem Board. Die einzig heikle Aufgabe war es den Prozessor samt Kühler vom alten Board auf das neue zu bekommen. Ich weiß nun ungefähr wie sich ein Chirurg bei einer Operation am offenen Herzen fühlen muss. 🙂 Um alle Zweifel auszuräumen unterzog ich die Kiste seit letzter Woche noch einigen Stresstests, um mal das Wort des Jahres zu benutzen. Es wurden 2 GB große Dateien xz komprimiert, für die Wissenschaft mit Boinc gerechnet und auch Unity habe ich benutzt. Fazit: Operation erfolgreich, Patient lebt
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.
Testing soll fortlaufend nutzbar und installierbar bleiben. Der Debian Installer soll aktuell aber zuverlässig arbeiten.
Softwarepakete sollen nicht wie bisher "eingefroren" werden, sondern kontinuierlich aktuelle Software in CUT einfließen.
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.
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.
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.
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. 😀
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.
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".
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.
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:
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.
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. 😉
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)
Der erste Eindruck hat nicht getrogen und tatsächlich hatte das Netzteil des Thinkpad 600 durch den Kurzschluss auf dem Weihnachtsmarkt ordentlich etwas abbekommen. Mit dem neuen Universalnetzteil funktioniert die Kiste aber wieder, Debian, ConnochaetOS, KolibriOS und Co. laufen einträchtig im Multibootsystem und alle Daten sind nach wie vor intakt. Eine gute Nachricht, weswegen weiteren Experimenten nichts entgegenstehen sollte. 🙂 Auf der anderen Seite hat mich in letzter Zeit der etwas verrückt spielende Core Duo in Atem gehalten, weshalb weniger Zeit für interessantere Computerprobleme geblieben ist. Die weniger gute Nachricht lautet dann auch, dass das System weiterhin instabil ist, obwohl ich mittlerweile einige Zeit damit verbracht habe, um mich über den Unterschied von Single- und Dual-Channel-RAM zu informieren, schon wieder gelernt habe :roll:, dass man selbst bei sorgfältiger Recherche immer noch Fehler machen kann und zu guter Letzt nicht mehr unterscheiden kann, ob es nun ein Hardware- oder doch eher ein Softwareproblem ist. Aber der Reihe nach. Der Core Duo besaß einmal 2x 2GB-RAM-Module des Herstellers Team Group aus Taiwan mit der genauen Produktbezeichnung TVDD2048M800. Nachdem mehrere Anwendungen kontinuierlich abstürzten und ich mit Memtest86+ festgestellt hatte, dass offenbar der Speicher defekt war, entfernte ich ein Modul und alles schien wieder in Ordnung zu sein. Nach einiger Zeit wiederholte sich das Spiel aber und ich beschloss das Übel loszuwerden und mir neuen Arbeitsspeicher zu kaufen. Da der Hersteller meines Mainboards ASUS war, begab ich mich auf dessen Homepage um mehr über geeigneten RAM für mein P5N73-CM Motherboard herauszufinden. Dort gab es tatsächlich ein PDF-Datenblatt mit einer "Qualified Vendor List". "Großartig", dachte ich, dort werde ich sicherlich den passenden RAM für mein Board finden. Ich wählte natürlich den schnellstmöglichen PC6400 RAM mit 800Mhz Speichertakt und entschied mich für Kingston KHX6400D2LLK2/1GN. Stutzig machte mich nur, dass der ehemals verbaute RAM von TEAM gar nicht in der Liste auftauchte. Ich bestellte daraufhin also KHX6400D2LLK2/4G, wobei ich gutgläubig aber leider auch naiv annahm, dass das der gleiche Speicher war, der lediglich als 2x2 GB RAM Kit verkauft wurde. Das 11. IT Gebot lautet aber, "Du sollst dir über Hardware kein Bildnis machen!". Augenscheinlich funktionierte nur ein Modul gleichzeitig mit meinem Board, so dass ich nur 2 GB installieren konnte. Ein Blick danach auf die Kingston Homepage offenbarte mir dann meine Fehleinschätzung. Ich hatte mir ein Dual-Channel-Memory-Kit gekauft, mein Motherboard unterstützte aber nur Single Channel. Da ich nun keine Lust mehr auf weitere Experimente hatte, bestellte ich einfach zwei 2GB-Module des Original-TEAM-RAMs. Gleicher Typ, gleicher Hersteller, eine narrensichere Angelegenheit. Als ich jedoch beide Bausteine eingesetzt hatte und mich schon über die Anzeige 4096 MB im Bios gefreut hatte, wurde mein Freudentaumel jäh durch eine GRUB-Fehlermeldung beendet. Egal was ich auch tat, entweder startete der Rechner nach dem Erreichen des GRUB-Menüs neu, fror ein oder zeigte mir diese Fehlermeldung. Jedoch mit einem RAM-Modul und 2 GB RAM scheint es keine Probleme zu geben. Möglicherweise ist sogar das Motherboard selbst defekt. Passend dazu bekomme ich seit neustem, aber nur mit dem Nvidia-Treiber, diese Fehlermeldung.
NVRM: Xid (0000:02:00): 13, 0003 00000000 00008297 00001338 0000fd20 0000000c [28271.390112] NVRM: Xid (0000:02:00): 13, 0003 00000000 00008297 00000e08 0015f404 00000004 [28276.495279] NVRM: Xid (0000:02:00): 13, 0003 00000000 00008297 00000e08 0015ff04 00000004 [28278.719604] NVRM: os_schedule: Attempted to yield the CPU while in atomic or interrupt context
Im offiziellen Nvidia-Forum habe ich diesen Thread dazu gefunden, der aber scheinbar nicht weiterverfolgt wird. Die Symptome sind ein manchmal kurz flackernder Bildschirm und teilweise ein komplettes Einfrieren des gesamten X-Servers, der sich danach nur noch über SSH beenden lässt. Hängt dies nun ebenfalls mit dem RAM-Problem zusammen oder ist das nur eine unglückliche Verquickung von Hardware- und Softwarefehlern? Ich weiß zur Zeit nur eins. Solange ich 2 GB RAM und die freien Nouveau-Treiber benutze, scheint das System stabil zu laufen, benutze ich hingegen den Nvidia-Treiber ist ein Neustart des X-Servers vorprogrammiert. Für einen Rechner, der mehr als doppelt soviel gekostet hat wie alle gebrauchten Laptops des Haushalts zusammen, eine eher schlechte Nachricht.
Alle Jahre wieder findet in einem kleinen Dorf im Zentrum der Welt ein weltbekannter Weihnachtsmarkt statt. Am letzten Wochenende versammelten wir uns erneut im Glühweinzelt, um Glühwein mit und ohne Schuss, Lumumba und Kinderpunsch auszuschenken. Dieses Mal erklärte ich mich bereit, stimmungsvolle Musik mit Hilfe des Thinkpad 600 zur Verfügung zu stellen. Alle Theorie ist trocken und grau, weshalb etwas Praxis nicht schaden konnte. Mit Debian und dem effizienten C*mus war die musikalische Unterhaltung des Weihnachtsmarkts gesichert. Da ich es darauf angelegt hatte, gab es zusätzlich für den ein oder anderen Bildschirmschonertrick mit Screen einige "Ohs und Ahs". 😉
Unauffällig in einer Ecke stehend erfüllte der Thinkpad seine Aufgabe. Der gesamte Tag verlief in musikalischer und technischer Harmonie. Zumindest bis wir uns dem Ende des Abends näherten. Denn spätestens wenn die Gäste einem mit wässrigem Blick anstarren und fordern: "Ich will Rum mit Glühwein. Du hast mich verstanden? RUM mit Glühwein!", ist es mal wieder Zeit das alljährliche Fest ausklingen zu lassen. Wäre da nicht der kleine Kurzschluss beim Abbauen des Standes gewesen, der das Netzteil meines treuen Laptops abrauchen ließ, es hätte wieder einmal ein perfekter Abend werden können. 🙁 Mal schaun, ob die Bestellung, die in Kürze hier eintreffen wird, den Laptopoldie noch retten kann.
Auch wenn ich mich in Sachen Arch Linux oft wiederhole. Beißt euch durch die Installation durch, bleibt dran und gebt nicht auf - ganbatte kudasai!. Sie ist wirklich gut im englischen oder deutschen Arch Linux Wiki erklärt. Nachdem man diese vermeintliche Hürde nämlich genommen hat, stellt man plötzlich fest, dass man für den Rest der Lebenszeit seines Computers nicht mehr daran denken muss. Genauso wie bei Debian Unstable oder Testing ist Arch eine fortlaufend aktualisierte Distribution, weswegen der Teil mit der Installation wirklich nur einen Bruchteil der Zeit am Rechner ausmacht. Wie versprochen ist hier ein erster Eindruck, was mir bei regelmäßiger Benutzung von Arch auf dem Inspiron 4000 aufgefallen ist.
Das Netzwerk
Nachdem man den Installationsschritten gefolgt ist, muss man sich als Neuankömmling erst einmal ein paar Problemen stellen. Eine Interfaces Datei für Arch Linux gibt es nicht. Ist die nicht sogar bei Debian schon "deprecated"? Am leichtesten geht es, wenn man direkt in der /etc/rc.conf eine einzelne Netzwerkschnittstelle einrichten möchte. Für statische oder dynamische IP-Adressen-Konfiguration ist hier der richtige Ort. Wenn es komplizierter werden soll aufgrund mehrerer Netzwerkkarten, sollte man sich netcfg anschauen. Ein Verhalten, das erst einmal gewöhnungsbedürftig ist falls man Befehle wie ifconfig, ifup und ifdown sofort nach einer Minimalinstallation von Debian gewohnt ist. Für einen Laptop gefällt mir außerdem noch Wicd, mit dem sich übersichtlich drahtlose Netzwerke einrichten lassen.
Aptitude und Pacman
Arch Linux ist kaputt, denn es hat kein Apt. Wahre Worte. 😛 Pacman ist zwar nicht Apt, erfüllt aber ähnliche Aufgaben, die man auch von Apt gewohnt ist. Die wichtigsten Befehle für den Anfang sind:
pacman -Syu : Das komplette System auf den neuesten Stand bringen
pacman -S "Paketname": Ein Paket installieren
pacman -Ss "Suchbegriff" : Nach einem Begriff/Paket suchen
pacman -Sc : Den Paketcache leeren
pacman -Rs "Paketname" : Ein Paket und dessen Abhängigkeiten entfernen, sofern sie nicht von anderen Paketen gebraucht werden
Man vermisst zwar ein wenig Aptitudes exzellente Suchfähigkeiten, bisher konnte ich mein Arch trotzdem immer nach meinem Geschmack einrichten.
Kleine Unterschiede
Arch Linux bezeichnet sich selbst als eine Keep-it-simple-Distribution. Das geht soweit, dass das Patchen von Dateien bis auf ein absolut notwendiges Minimum reduziert wird. In der Regel werden neue Feature und Sicherheitsaktualisierungen durch den jeweiligen Upstream-Autor erstellt und dann umgehend als Arch-Linux-Paket bereitgestellt. Das kann aber auch dazu führen, dass einige Fähigkeiten, die man aus Debian kennt, plötzlich nicht mehr funktionieren. Am Beispiel scrot, dem Screenshot Programm, wird das ziemlich deutlich. In der Arch Version gibt es den Patch zum gezielten Aufnehmen eines Fensters, in der offiziellen Version leider nicht. (-u) Dafür wird eine inoffizielle Version in AUR bereitgestellt. Wie gut sie wirklich ist, lässt sich nur durch Ausprobieren feststellen. Im Moment hat sie nur zwei Bewertungspunkte.
Pakete aus AUR - der leichte Weg
Am Anfang genügt es vollkommen nur die offiziell verfügbaren Pakete und den offiziellen Paketmanager Pacman zu benutzen. Es stehen dann zwar nicht die gleiche Anzahl an Paketen wie bei Debian zur Verfügung, man kann aber durch geschicktes Substituieren das Problem meistens umgehen. In den letzten beiden Posts zu Arch Linux auf dem Inspiron 4000 habe ich die manuelle Methode mit makepkg -s vorgestellt, bei der man das PKGBUILD manuell herunterladen und ggf. Abhängigkeiten ebenfalls manuell bauen muss. Wenn man sich erst einmal an dieses "Do-it-yourself"-Konzept gewöhnt hat, macht das Bauen von Paketen bei Arch Linux sogar richtig Spaß. Für den regelmäßigen Baumeister empfiehlt sich aber einer der sogenannten AUR-Helfer. Insbesondere yaourt scheint populär zu sein. Im Grunde genommen ist yaourt ein Wrapper für Pacman, der die gleichen Befehle unterstützt, gleichzeitig aber die Möglichkeit bietet direkt im Arch User Repository nach Software zu suchen und diese wie mit Pacman gewohnt zu installieren. Momentan benutze ich yaourt ausschließlich nur für das Installieren von AUR-Paketen, was eine große Zeitersparnis ist.
Zum Schluss
Ja, Arch Linux ist anders als Debian. Wenn man sich aber an die Unterschiede gewöhnt hat, macht es viel Spaß. Software zu verwalten ist einfach und unkompliziert. Pacman ist weniger mächtig als Apt, ist dabei aber auch fühlbar schneller auf älteren Rechnern. Ein Bonus ist sicherlich auch, dass man in Sachen Desktopumgebung nicht umdenken muss. Meine alten Openbox-Einstellungen konnte ich problemlos übernehmen.
