Ein Bildschirmfoto zu machen gehört praktisch zum guten Ton, wenn man seinen Desktop präsentieren will oder ohne viel Worte in einem Forum auf ein Problem hinweisen möchte. In der Regel genügt es mit vorinstallierten Programmen wie z.B. gnome-screenshot und einem Drücken der "Druck" Taste den Bildschirm als Foto zu archivieren. Seit längerer Zeit nutze ich auch Shutter, was viele zusätzliche Optionen bietet und dessen Plugins mir sogar oft die Nachbearbeitung mit Gimp ersparen. Meistens hilft mir hierbei ein ganz anderes Programm für diese Art von Aufgabe und das heißt scrot. Scrot ist eine wunderbare, kleine Anwendung, welche verschiedene Funktionen hat, um den gesamten Bildschirm oder auch nur einen Teil davon aufzunehmen und alles als .jpg oder .png Datei abzuspeichern. Mit weiteren Parametern lassen sich leicht Zeitstempel, frei bestimmbare Zeichenketten oder die Bildschirmauflösung an den Dateinamen anhängen. Scrot lässt sich prima von einem Terminal Emulator aus bedienen. Hier sind einige Beispiele:
Beispiele
1. Den gesamten Bildschirm aufnehmen und das Foto in das aktuelle Arbeitsverzeichnis speichern.
scrot
2. Den gesamten Bildschirm nach fünf Sekunden aufnehmen und dabei das Ganze mit einem Countdown visualisieren.
scrot -cd 5
3. Warte fünf Sekunden, visualisiere die Verzögerung und nimm nur das momentan ausgewählte Fenster auf.
scrot -u -cd 5
4. Warte fünf Sekunden, mache ein Bildschirmfoto und benenne den Dateinamen mit Datumsstempel, Bildschirmauflösung und scrot als Zeichenkette. Speichere das Bild im .png Format im Verzeichnis "bilder" im Home Verzeichnis des Nutzers ab und öffne es danach mit dem Bildbetrachter feh. $f ist ein Platzhalter für die Datei.
Das vor kurzem vorgestellte Crunchbang Linux nutzt Openbox als Fenstermanager und hat scrot hier geschickt im Menü von Openbox integriert. Um sich das zuletzt gezeigte Kommando nicht merken zu müssen, kann man es einfach in der menu.xml wie folgt eintragen oder natürlich auch den grafischen Weg über obmenu gehen.
Bei meiner ersten Begegnung mit Fluxbox bin ich damals auf tenr.de gestoßen. Ziemlich weit unten bei snippets befindet sich ein kleines Skript namens shot.sh, welches sich ebenfalls gut eignet, um den Umgang mit scrot zu vereinfachen. Ansonsten hilft wie immer auch man scrot weiter. Übrigens lässt sich mit der Option -q auch die Qualität der Aufnahme beeinflussen. 🙂
Als ich das offizielle Handbuch zu Virtualbox durchstöberte, entdeckte ich zuerst nicht, wie man ein Vdi-Image ohne Qemu in ein Raw-Image umwandeln kann, welches ich danach mit dd auf eine Festplatte schreiben konnte. Virtualbox bietet mit dem Kommandozeilenprogramm vboxmanage und der Option convertfromraw die einfache Möglichkeit ein Rohabbild in das eigene Format .vdi umzuwandeln. Doch wie geht es in die andere Richtung? Eine Suche im Internet brachte mich dann auf wikibooks.org, wo ich fand, was ich suchte.
Als Alternative bietet sich auch weiterhin das fantastische Qemu an:
qemu-img convert -O raw file.vdi file.raw
Ist das Abbild danach umgewandelt, lässt es sich direkt mit dd auf eine Festplatte (hier: sda) schreiben oder auch mit Qemu betrachten. dd if=file.raw of=/dev/sda oder qemu file.raw Manchmal führen eben doch mehrere Wege nach Rom. 😉
Beim Ausprobieren der neuen Live DVD von live.linux-gamers.net, bin ich dieses Wochenende an M.A.R.S, einem 2D Weltraum-Shooter, der unter der GPL veröffentlicht wird, hängen geblieben. M.A.R.S. ist für Einzel- und Mehrspieler ausgelegt und bietet verschiedene Spielmodi: Spaceball, Team Deathmatch, Grave-Itation-Pit, Cannonkeeper und Deathmatch-Arena. Es gibt eine klassische Spielphysik, bei der die zu steuernden Schiffe sich mit den Bewegungstasten um 360 Grad drehen können und mit Hilfe des Antriebs in eine Richtung driften. Auf Grund von Gravitation, Masse und Trägheit bewegen sie sich auch noch weiter, nachdem der Antrieb erloschen ist. Zum Abbremsen hilft also nur eine 180-Grad-Drehung und erneute Beschleunigung. Aus einem Arsenal von Waffen müssen Gegner zerstört und Planeten verteidigt werden. Letztere haben die schlechte Angewohnheit durch ihre Masse Schiffe von ihrer Flugbahn abzulenken und direkte Kollisionen mit ihnen lässt, genauso wie ein Waffentreffer, die Lebenspunkte der Schiffe sinken. Nur durch Andocken an den Heimatplaneten lassen sie sich wieder reparieren. Die Optik ist für ein 2D-Spiel äußerst ansprechend und an grafischen Effekten wurde nicht gespart. Für Anfänger gibt es ein gut gemachtes Tutorial, dass alle wichtigen Spielelemente erklärt.
Besonders auffallend ist der symphonische Metal-Soundtrack des Spiels, den ich für sehr gelungen halte. Hierfür konnten die Entwickler von M.A.R.S die ungarische Band Obsidian Shell gewinnen, welche ihre Musik unter by-nc-nd zur Verfügung stellt. Die Lieder lassen sich kostenlos auf Jamendo anhören und herunterladen. Wer die Band unterstützen möchte, kann ihre Alben auch auf Amazon oder mit iTunes kaufen oder direkt auf der offiziellen Homepage spenden. Wem das Album "Angelic Asylum" gefällt, sollte auch mal in das nur in ungarisch gesungene "Elysia" reinhören. Track Nr.1 "Ezer Év" hat es mir im Moment angetan. 😉
Installation
Wer die sehr gute Live-DVD von linux-gamers.net nicht komplett herunterladen und nur M.A.R.S. spielen möchte, kann z.B. für Ubuntu M.A.R.S. auch direkt aus einem PPA installieren. Es gibt aber auch Pakete für andere Distributionen und ein generisches tar.gz zum Download.
M.A.R.S befindet sich zur Zeit zwar noch im Alpha-Stadium. Dennoch gefällt mir das Spiel schon jetzt sehr gut. Bemerkenswert finde ich die Kombination aus Open-Source-Spiel und freier Musik. Bleibt zu hoffen, dass beide davon gleichermaßen profitieren.
Ich gehöre zu denjenigen, die an ein Musikprogramm nur eine wirkliche Anforderung stellen: Es muss Musik abspielen können. Darüber hinaus hätte ich gerne Funktionen für Playlist, Pause, Vor- und Zurückspulen, Shuffle und Wiederholung. Zwar sind Datenbanken, um die Lieder nach id3 Tags zu sortieren, nett und nützlich. Dennoch hätte ich gerne auch die Möglichkeit meine im Dateisystem schon geordneten Musikdateien auszuwählen und zwar dort, wo ich sie auch abgelegt habe! Mein Weg zum passenden Musikprogramm war lang. Angefangen hatte ich im letzten Jahrtausend noch mit Windows und Winamp, bis es sich irgendwann entschied in eine schwerfällige Grässlichkeit namens Winamp 3 mit eingebauten Videoplayer zu mutieren. Mit Linux ging es dann nicht zufällig mit XMMS und später Audacious weiter. Zu KDE-Zeiten kam ich an Amarok natürlich nicht vorbei, bis schließlich mit Ubuntu Rhythmbox und seit 11.04 nun Banshee Einzug hielt. Um so mehr ich meine älteren Laptops benutzt habe, desto mehr fiel mir auf, was ich eigentlich von guter Software erwartete und an der bestehenden vermisste. Sie musste schnell auf Eingaben reagieren, kein Warten, nur weil ich die Ansicht in einem Programm ändere. Sie sollte genügsam mit Systemressourcen umgehen. Wenn schon eine Datenbank für Musik, dann sollte diese schnell synchronisiert und eingelesen sein. Ich wollte Musik hören. Um die Verwaltung meiner Musiksammlung kümmere ich mich selbst. Viele Anwendungen gehen einen anderen Weg. Das geht soweit, dass die Suche nach Musik in Musicstores und das Brennen von Audiodateien in den Vordergrund gerückt wird und Musik hören selbst zur Nebensache wird. Deshalb verschwand irgendwann Rhythmbox und wurde durch den Music Player Daemon (mpd) und einen Client wie Ario, Sonata oder ncmpc ersetzt. Mittlerweile dient der zwölf Jahre alte Toshiba Portégé 3110 CT problemlos als MPD-Server. Dann kam die Zeit, wo ich mit MOC und C*mus experimentierte und mit dem letzteren das Musikprogramm gefunden hatte, welches alle Kriterien guter Software zum Musikabspielen erfüllte. Egal ob es der Laptop aus dem letzten Jahrtausend oder der (mittlerweile schon wieder LowEnd :roll:) Intel Dual-Core-Rechner ist, Musikabspielen war nie einfacher, nie schneller und nie reaktionsfreudiger.
Banshee vs. cmus
Ich kann gut nachvollziehen, warum nun nicht jeder sofort jubelnd seinen aufgeblasenen Player von der Platte tilgt. Eine grafische Oberfläche bietet etwas fürs Auge. Nicht jeder lässt sich von der Tatsache begeistern, dass cmus auch ohne X auf der nackten Konsole die gleiche Funktionalität und Performance zeigt und ich mir nicht extra einen neuen PC für das Programm kaufen muss. Es gibt viele gute Gründe ein anderes Musikprogramm zu wählen: "Ich mag es", "Ich brauche die Dinge, die du für überflüssig hältst", "Ich nutze das Programm, weil ich es kann?!" Dem kann ich nichts entgegensetzen. Doch wenn du an den Punkt kommst, wenn dein Rechner vor lauter Kraft nur noch in den Swap-Speicher schreibt oder du einfach nur Musik hören möchtest, dann lass dich verzaubern vom Charme und der Schönheit des Schlichten!
Wie findet man heraus, welche Linuxdistribution die "bessere" ist? In was besser eigentlich und wie misst man am besten? Natürlich braucht man geeignete Werkzeuge und Irgendetwas, mit dem sich die Ergebnisse vergleichen lassen. In meinem Beitrag zu Speicherverbrauch und Compiz von Ubuntu 11.04, habe ich versucht es etwas lockerer mit dem Systemmonitor und etwas Gefühl zu versuchen. Für großangelegte Benchmarks gibt es für Linux aber schon eine Lösung - die Phoronix Test Suite. Mit ihr lässt sich zwar nicht der Leistungsunterschied zwischen Programm X und Y messen, jedoch bietet sie umfangreiche Tests an, um Komponenten eines Computers auf Herz und Nieren zu prüfen. Wie performant ist mein Rechner gegenüber Modell xy eigentlich? Mit der Phoronix Test Suite kann man einer Antwort auf diese Frage näher kommen. Mich interessierte für mein Multi-Boot System hingegen wie sich die drei unterschiedlichen Distributionen Ubuntu 11.04 (64bit), Debian Testing (32 bit) und Arch Linux (64bit) auf dem gleichen Rechner schlagen. Würde es große Unterschiede zwischen den beiden 64 bit Systemen von Arch Linux und Ubuntu 11.04 geben und wie würde Debian Testing als 32 bit Betriebssystem abschneiden? Ich habe mich schließlich für die linux-system Test Suite entschieden, welche mit vielen Untertests nach eigener Aussage die Gesamtperformance eines Linux Systems im Vergleich zu anderen darstellen kann. Die Phoronix-Test-Suite ließ sich wie gewohnt installieren. In allen drei Distributionen gab es schon vorgefertigte Pakete. Die Tests sind bei jeder Distribution die gleichen und mussten nur ein einziges Mal heruntergeladen werden. Danach genügte ein phoronix-test-suite make-download-cache, wodurch die Tests im versteckten Ordner ~/.phoronix-test-suite/download-cache abgelegt wurden und nur noch zwischen den Systemen kopiert werden mussten. Die Test-Suite selbst wird mit dem Kommando
phoronix-test-suite benchmark linux-system
ausgeführt. Möchte man nur die Tests herunterladen genügt install anstelle von benchmark, zum Ausführen ist es der Befehl run. Insgesamt sollte man für eine so umfangreiche Test-Suite genug Zeit einplanen, da die Pakete teilweise auf dem Zielsystem noch kompiliert werden und zusätzliche Pakete über die Paketverwaltung installiert werden. Bei Debian und Ubuntu verlief dieser Prozess meistens reibungslos, bei Arch Linux musste ich öfter manuell nachhelfen. Selbst dann gelang es mir nicht alle Tests erfolgreich auszuführen. Da es aber genug vergleichbare Tests auch mit Arch schafften durchzulaufen, sieht das Ergebnis am Ende meiner Meinung nach eindeutig aus. Das Ergebnis habe ich der Einfachheit halber gleich auf openbenchmarking.org veröffentlicht. Dort finden sich auch Details zu den getesteten Komponenten des Rechners. Alle Distributionen waren zum Zeitpunkt des Tests auf dem aktuellen Stand. Kernel 2.6.38 und das ext4 Dateisystem kamen standardmäßig bei allen zum Einsatz. Als Desktopumgebung setzte ich bei Debian Testing auf Gnome 2.30, bei Ubuntu 11.04 auf Unity und mit Arch Linux auf Gnome 3.
Das Ergebnis
Phoronix-Test-Suite: pts/linux-system Intel Core 2 Duo e7400, Ubuntu 11.04, Debian Testing (wheezy), Arch Linux Nicht ganz überraschend ist mein 32 bit Debian Testing System bei dieser Test-Suite abgeschlagen Letzter geworden. Lediglich bei Minion, dem Threaded I/O Tester und POV-Ray liegt wheezy vorne. Die restlichen Tests zeigen deutlich, dass zwischen den beiden 64 bit Distributionen Ubuntu 11.04 und Arch Linux kein großer Unterschied besteht. Wenn überhaupt liegt Ubuntu bei Encoding und rechenintensiven Tests, bei denen ein 64 bit System seine Vorteile deutlich ausspielen kann, knapp vorne. Die größten Ausreißer gab es bei dem Postmark Test, wo wheezy komplett aus der Reihe fällt und dem Apache Benchmark, wo Arch Linux deutlich hinterher hinkt. Die Werte weichen zu deutlich von den anderen ab, weshalb ich denke, dass hier ein Messfehler vorliegt. Die ganzen Tests haben nachträglich noch einmal bestätigt, dass es absolut sinnvoll ist für Audio-, Video- und Bildbearbeitung ein 64 bit Betriebssystem einzusetzen. Ob es nun Arch Linux oder Ubuntu 11.04 ist, scheint weniger wichtig zu sein. Letzteres war scheinbar keine schlechte Wahl. Die Phoronix Test-Suite bietet aber auch Kritikpunkte. So sinnvoll ich es halte, dass es sich immer um die gleichen Tests handelt, es wird dadurch aber nicht einfacher herauszufinden, ob es eventuell distributionsspezifische Vorteile bei einzelnen Programmen gibt. Des weiteren ist eine solche Test-Suite immer auch ein Extremtest und spiegelt nicht den alltäglichen Gebrauch eines Computers wider. Sollte ich aber irgendwann den ganzen Tag nichts anderes tun als 1GB große Dateien mit GnuPG zu verschlüsseln, mache ich das am besten mit Ubuntu 11.04 (64bit). Komprimiere ich Dateien mit LZMA sollte es wohl besser Arch Linux(64bit) sein. Wenn ihr euch den Spaß machen möchtet und genau diese Testumgebung auf eurem Rechner ausprobieren wollt, können die Resultate direkt mit folgendem Befehl verglichen werden:
Zum Schluss habe ich mir ein anderes Resultat vorgenommen, welches die Tests Unigine Heaven und Openarena schon ausgeführt hatte. Im Prinzip ging es um den Vergleich Radeon 4870 gegen meine Nvidia 9600 GT. 32 bit versus 64 bit spielte hierbei keine Rolle. Die Auflösung betrug 1680x1050 Pixel. Alle Distributionen konnten auf die aktuellen Nvidia Treiber zurückgreifen. Unigine Heaven Test Nvidia 9600 GT Ubuntu 11.04, Debian Testing (wheezy), Arch Linux Bedauerlicherweise erreichte ich mit keinem der Distributionen die vorgegebenen Framewerte. Am schlechtesten schnitt dabei Arch Linux ab. Ich versuchte es deshalb mit OpenArena erneut, wo Ubuntu 11.04 (+compiz) 346,23 fps erzielen konnte. Debian Testing (+compiz) erreichte 330 fps und Arch Linux (Gnome 3) 329,57 fps. Die Unterschiede waren also nur marginal. Ergebnis OpenArena Wheezy Ergebnis OpenArena Arch Linux Interessant wurde es noch einmal als ich den OpenArena Test mit wheezy ohne compiz wiederholte und dabei 376,27 fps erreichte. Ergebnis OpenArena Wheezy ohne compiz Das Ergebnis lässt den Schluss zu, dass 32 bit oder 64 bit bei den Tests keine große Rolle spielte. Wichtiger sind verwendete Grafiktreiber, die Grafikkarte selbst und ob ein Compositing Fenstermanager wie compiz aktiviert war oder nicht. Für Spieler lässt das nur den Schluss zu, dass weniger Compiz beim Spielen mehr ist. Alles in allem zeigen die Phoronix Tests, dass die allgemeine Grundperformance bei vergleichbarer Architektur sehr ähnlich ist. Optimierungen und Verbesserungen einzelner Anwendungen konnte die Test-Suite aber nicht messen. Ob ein System mit speicherhungrigen Programmen überladen war oder dezent nur das Notwendige installiert war, ließ sich mit den Tests nicht feststellen.
Du möchtest mit Linux nicht nur Texte schreiben, Tabellen bearbeiten, Musik hören, im Internet surfen, Chatten, Emails lesen, deinen Bildschirm in einen drehenden Würfel verwandeln, Filme und Podcasts erstellen und auch noch anschauen, Server betreiben, ältere Hardware mit aktueller Software produktiv nutzen, sondern auch noch Spielen? Das ist doch Wahnsinn! Doch bevor ich den Satz mit einer Referenz an Sparta, der Film, oder das Überraschungsei beende, kommen wir gleich zum Wesentlichen. Wie alle wissen ist Spielen eine todernste Sache. Ein Monat/Woche/Tag ohne ein neues Spiel...grauenhaft. Deshalb dachte ich mir, dass ich einige Webseiten und das Programm Wine kurz vorstelle, die sich mit dem Thema "Spielen mit Linux" beschäftigen und wo man viel neues Futter finden kann. 😉
Wine
Wine ist ein Akronym und steht für "Wine is not an emulator". Das Programm verhält sich wie eine Zwischenschicht zwischen Linuxkernel und dem ursprünglichen Windowsprogramm und ist damit in der Lage Spiele so auszuführen als wären sie nativ für Linux geschrieben. Wine ist kostenlos und Freie Software. Ich kann nicht garantieren, dass jedes Spiel mit Wine perfekt läuft. In den vergangenen Jahren wurde ich aber bei bekannten und langfristig interessanten Spielen wie World of Warcraft, Starcraft II, Runes of Magic und den Spielen der Steam Plattform nicht enttäuscht. Die Wine-Datenbank liefert einen umfassenden Überblick über die unterstützten Spiele und weitere Software. Die Firma Codeweavers bietet zusätzlich professionellen Support und einige Besonderheiten für Wine an. Heute wird der 15. Geburtstag des Unternehmens gefeiert. Aus diesem Anlass gibt es das Crossover Bundle bis zum 31.Mai zu einem Vorzugspreis. Ich möchte, dass kommerziell erfolgreiche Spiele auch für Linux erhältlich sind. Leider sieht das nicht jeder Hersteller genau so. Es gibt Spieleentwickler wie id Software, für die so etwas nie ein Problem war. Von allen anderen kaufe ich nur noch, wenn das Spiel zumindest unter Wine einwandfrei läuft.
Holarse-Linuxgaming.de
Holarse gibt es auch schon eine kleine Ewigkeit. Meiner Meinung nach der Anlaufpunkt, wenn man einen Überblick über das Thema "Spielen mit Linux" haben möchte. Hier finden sich Spielekritiken, Installationsanweisung, Tipps und Trick zu allen möglichen Spielen, die sich mit Linux spielen lassen. Das Angebot reicht von Emulatoren um alte C64, Amiga oder DOS Klassiker wieder in das Hier und Jetzt zurückzurufen bis zu Wine und den nativen Linuxspielen. Geniale Programme wie ScummVM machen es möglich alte Lucasarts Klassiker zu spielen und das sogar noch problemlos auf einem 10 Jahre alten Inspiron 4000.
Penguspy
Diese moderne und schicke Seite bietet einen weiteren sehr guten Überblick über die besten nativen Linuxspiele. Die Idee hinter Penguspy ist, Linux als Spieleplattform bekannter zu machen und auch eine Möglichkeit zu bieten eigene Spielefavoriten in das Rampenlicht zu stellen. Penguspy lässt es zu nach freier/unfreier und kostenlosen/kommerziellen Spielen zu filtern, Spiele zu bewerten und interessante Spiele mit sozialen Netzwerken wie Facebook zu teilen. Gut finde ich auch, dass Videos in die Detailseiten zur Präsentation der Spiele eingebunden sind. Penguspy ist auf jeden Fall einen Blick wert.
Linux-Gamers.net
Last but not least. Um nach der Flut an Informationen nicht das Wesentliche aus dem Blickfeld zu verlieren, gibt es eine richtig gute Live CD/DVD von linux-gamers.net, mit der sich problemlos eine ganze Reihe von erstklassigen Linuxspielen spielen lässt. Gerade in der letzten Woche wurde die aktualisierte Version 0.9.7 mit Kernel 2.6.38 veröffentlicht. Mein Bericht zur alten findet sich hier.
Folgendes Problem: Viele, viele Dateien sollen umbenannt werden. Richtig praktisch für eine solche Aufgabe fand ich bisher nur das Programm Bulk-Renamer, welches Bestandteil des Dateimanagers Thunar ist. Sucht man im Internet weiter, findet man schnell weitere grafische Lösungsmöglichkeiten unter Linux. Ich möchte die Anzahl solcher Zubehörprogramme möglichst klein halten und unabhängig von Desktopumgebungen oder Programmbibliotheken sein. Gerade ein solches Problem ruft förmlich nach einer schnellen, nicht-grafischen Lösung: Der Shell Bei Debian und Ubuntu kann man standardmäßig auf die Bash zurückgreifen. Einen möglichen Ansatz zum mehrfachen Umbenennen von Dateien bietet eine Schleifenkonstruktion, die ich schon einmal in Zusammenhang mit dem massenhaften Umwandeln von Bild- und Videodateien in freie Formate vorgestellt habe.
#!/bin/bash
counter=123
for i in *.jpg; do
mv -i "$i" "Sommer_Urlaub_$counter".jpg
let counter+=1
done
Dieses kleine Skript muss nur noch abgespeichert und mit chmod+x ausführbar gemacht und in dem betreffenden Bilderverzeichnis ausgeführt werden. Dabei werden alle *.jpg Dateien der Reihe nach mit dem GNU Kommando mv in Sommer_Urlaub_123.jpg usw. umbenannt, wobei der Zähler bei 123 anfängt und dann am Ende der Schleife jeweils um 1 hochgezählt wird.
VIM - VI improved
Zuerst denkt man, wie kann ein Texteditor wie vim schon großartig beim Umbenennen von Dateien helfen? Ich muss zugeben, im Laufe der Zeit hat mich vim immer mehr begeistert und nachdem ich mir schon das Buch Vim 7 - Ge-Packt von Reinhard Wobst gekauft habe, stöbere ich auch ab und zu im Vim Wiki herum. Gerade zum Thema "Mehrere Dateien umbenennen" gibt es schon einen englischen Eintrag namens Bulk rename files. Um mehrere Dateien z.B. von Großschreibung zu Kleinschreibung zu transformieren, sendet man an vim einfach eine Liste mit allen in einem bestimmten Verzeichnis vorhandenen Dateinamen.
Bisher wurden die Dateien vollkommen unberührt gelassen. Alles hat sich in Vim abgespielt. Mit der Taste "u" kann die Aktion rückgängig und mit STRG+R das Rückgängige rückgängig gemacht werden. Wirklich ausgeführt wird die Umbenennung erst, wenn Zeile für Zeile an die Bash als Befehl übergeben wird. Das lässt sich durch
:w !sh oder :%!bash
erreichen. Auch in Vim lässt sich ein Zähler einbauen. Der allgemeine Ansatz scheint zu sein, eine separate Funktion zu schreiben, welche wiederum eine Zahl fortlaufend erhöht. Für meinen Geschmack habe ich dadurch in dem konkreten Beispiel gegenüber der for Schleife nichts gewonnen. Warum ich Vim als Alternative angeführt habe, ist vielmehr der Vorteil, dass man alles in Ruhe vorher betrachten und prüfen kann, bevor man die Veränderung auf seine Dateien loslässt. Außerdem bietet Vim z.B. die praktische Möglichkeit mit dem visuellen Modus nur ein paar Dateien auszuwählen und den Befehl hierauf anzuwenden. Dazu genügt es "v" zu drücken, mit den Cursortasten den Bereich zu selektieren, dann wieder in den Kommandomodus mit ":" wechseln und es erscheint automatisch schon
:'<,'>
Das ergänzt zu
:'<,'> !bash
und nur der ausgewählte Teil wird auch tatsächlich ausgeführt. Richtig interessant wird es aber erst mit Regulären Ausdrücken. Wer also z.B. nur den Buchstaben U, nach dem ersten Unterstrich groß oder klein schreiben möchte oder nur bestimmte Muster ersetzen möchte, kommt an den regular expressions nicht vorbei. Natürlich ist das ein Feature jeder guten Programmier- und Skriptsprache und nicht auf Vim beschränkt, welches in Sachen Reguläre Ausdrücke sowieso einen besonderen Weg gegangen ist. Ich denke für einen so einfachen Fall bleibe ich weiterhin bei der Bash. Auch die Alternative rename sollte man sich anschauen. Wer aber bisher dachte, dass Texteditoren nur zum Ändern von Konfigurationsdateien taugen, kennt jetzt zumindest einen Tipp mehr aus dem umfangreichen Vim Wiki und es gibt dort noch viele, viele mehr. 🙂
Mehr als ein Monat ist vergangen, seitdem ich Ubuntu 10.10 gegen ein Multi-Boot-System ausgetauscht habe. Falls ihr euch ebenfalls für ein solches System interessiert, findet ihr in diesem Beitrag eine Übersicht über die Vor- und Nachteile. Die gemachten Erfahrungen mit den drei neuen Betriebssystemen Ubuntu 11.04, Debian Testing und Arch Linux habe ich zusammengefasst und zu den einzelnen Schritten des Projekts verlinkt.
Warum überhaupt Multi-Boot?
Vorteile
Vergleichbarkeit: Mit einem Multi-Boot-System ist es unkompliziert sich die Vor- und Nachteile verschiedener Linuxdistributionen oder Desktopumgebungen unter realistischen Bedingungen anzuschauen. Zwar bieten Virtualisierungslösungen wie z.B. Virtualbox und Qemu einen weniger aufwendigen Überblick. Diese hinken in Sachen Performance einem Multi-Boot System in der Regel aber deutlich hinterher. Klare Aufgabentrennung: Ein Multi-Boot-System eignet sich hervorragend, um typische Arbeiten am Computer zu trennen. So lässt sich ein Betriebssystem ausschließlich zum Arbeiten, ein anderes für Videobearbeitung und ein drittes vielleicht zum Spielen nutzen. Flexibilität und Integrität: Nicht nur die Software kann flexibel an die eigenen Bedürfnisse angepasst werden, auch unterschiedliche Dateisysteme können eingesetzt werden, um die Performance für spezielle Anwendungen zu erhöhen. Bei getrennten Partitionen und Betriebssystemen wiegt ein Schaden am Dateisystem weniger schwer und Fehler wirken sich nicht auf alle Daten gleichzeitig aus. Sicherheit: Ein Multi-Boot-System kann so eingerichtet werden, dass nur diejenigen Anwendungen installiert sind, die man tatsächlich braucht. Was nicht installiert ist, kann auch nicht kompromittiert werden. Nutzt man ein System z.B. ausschließlich für private Korrespondenz und Büroarbeit lässt sich mitunter auf einen Browser und diverse Internet- und Multimediaanwendungen als potentielle Einfallstore für Schadsoftware verzichten. Performance: Je nach Geschmack und Vorlieben lassen sich Multi-Boot-Systeme für ihren jeweiligen Anwendungszweck optimieren. Ein Linuxsystem für Spiele braucht z.B. keine Textverarbeitung, kein Multimedia, kein Emailprogramm und auch kein Compiz. Nur das Spiel, ein Terminal, eventuell IRC- und VoiP-Client der Wahl, der aktuellste Grafiktreiber und ein auf das notwendigste optimierter Linuxkernel sind wirklich notwendig. Eingewöhnung: Gerade bei einem Umstieg von Windows oder Mac auf Linux oder zwischen zwei verschiedenen Linuxdistributionen, macht es Sinn für eine Übergangszeit zwei Systeme parallel zu nutzen, zumindest solange bis man sich an die neue Umgebung gewöhnt hat.
Nachteile
Mehr Aufwand: Für ein Multi-Boot-System fällt zusätzlicher Installations- und Konfigurationsaufwand an. Nicht nur muss der Installationsvorgang ggf. mehrmals wiederholt werden. Auch die Wartung, Pflege und Administration der Systeme kostet je nach Distribution und Vorstellungen zusätzliche Zeit. Noch nicht vertraute Konzepte anderer Distributionen müssen erst erlernt werden. Reboot: Um das System zu wechseln ist immer ein Neustart notwendig. Auch das kostet Zeit und kann manchmal störend sein, wenn man "nur mal kurz" etwas ausprobieren möchte. Doppelte Funktionalität: Idealerweise gibt es für die Multi-Boot-Systeme jeweils einen spezifischen Verwendungszweck. Es besteht aber die Gefahr, dass Programme doppelt installiert werden und sich Aufgaben überschneiden. Beispiel Browser: Hiermit lassen sich schnell Informationen im Internet finden, was sowohl für reine Büroarbeit als auch für Videobearbeitung und Spiele sinnvoll sein kann. Um Redundanz zu vermeiden, muss man sich vorher genau überlegen, was man sich von seinem Multi-Boot System überhaupt erwartet.
Unverschlüsselte Bootpartition für Debian Testing (ext2)
/dev/sda2 (Primär)
Daten- und Austauschpartition zwischen den verschiedenen Distributionen (ext4)
/dev/sda5 (Logisch)
LVM auf einem verschlüsselten Volume mit den Logical Volumes root, swap und home für Debian Testing
/dev/sda6 (Logisch)
Ubuntu 11.04 installiert in eine logische Partition (ext4)
/dev/sda7 (Logisch)
Swap Partition für Ubuntu 11.04 und Arch Linux
/dev/sda8 (Logisch)
Arch Linux installiert in eine logische Partition (ext4)
Die drei Linuxdistributionen im Überblick
Debian Testing (Gnome 2 + Compiz)
Gnome 2
Ursprünglich wollte ich Linux Mint Debian mit verschlüsseltem LVM installieren. Mit LMDE beschäftige ich mich seit Ende 2010 und habe mich dann auf Basis einer Debian Netzinstallation für "The Debian Way" entschieden. Nach einigem Rumprobieren und Abwägen zwischen Linux Mint Debian und dem reinen Debian, blieb ich schließlich bei Debian Testing. Zu gering erschienen mir die Vorteile und in der Tat war LMDE dann doch nur ein mint-meta Paket. Debian Testing ist nun das Haupt- und Arbeitssystem, von dem auch die anderen Systeme mit Hilfe von GRUB im MBR eingebunden werden. Als Desktopumgebung nutze ich Gnome 2, das ich nach der Installation des gnome-core Pakets nur noch geringfügig konfigurieren musste, um die von Ubuntu gewohnten Eigenschaften zu erhalten. Zur Zeit bin ich wunschlos glücklich mit Debian und warte nun geduldig auf Gnome 3.
Ubuntu 11.04 (Unity+Compiz+Gnome)
Ubuntus Natty Narwhal dient mir seit neustem als Videoschnittplatz, worunter bei mir auch Bild- und Audiobearbeitung fallen. Zukünftig möchte ich Ubuntu für die Realisierung kleinerer Videoprojekte einsetzen und dabei ausschließlich Open-Source-Software nutzen. Das Ganze ist ein Projekt im Entstehen. Sollten die Ergebnisse interessant und vorzeigenswert seien, gibt es eventuell auch einen Blogbeitrag. 😉 Die ersten Eindrücke zu Ubuntu 11.04 waren gemischt, aber mit ein paar kleinen Optimierungen lässt sich mit dem schicken Narwal leben.
Arch Linux (Gnome 3)
Arch Linux war schon seit längerem ein Testkandidat für mich. Obwohl etwas Einarbeitungszeit erforderlich ist, sind die erstklassige Dokumentation im Netz und das Ergebnis alle Mühen wert. Wer gar nicht auf ein gut getestetes Gnome 3 in Debian warten kann, hat mit Arch die besten Chancen die Zeit zu überbrücken. Da ich Stabilität und Zuverlässigkeit bei Betriebssystemen sehr hoch einschätze, wird Arch vermutlich auch in Zukunft Debian nicht verdrängen. Zu unterschiedlich sind hier die beiden Ansätze. Das heißt nicht, dass Arch Linux notorisch instabil ist, aber allein aus grundsätzlichen Überlegungen kann ein Rolling Release, welches auf brandaktuelle Software abzielt, nicht genauso umfangreich wie Debian Stable getestet sein. Archs besonders hervorzuhebendes Qualitätsmerkmal ist die erstklassige Dokumentation. Für ein leichtgewichtiges Linux oder gerade wenn man auf neue Feature Wert legt, ist Arch mit Sicherheit eine Option, die man im Hinterkopf behalten sollte.
Fazit
Ein Multi-Boot-System ist nützlich, lehrreich und macht Spaß. So bleibt in Zukunft die Möglichkeit die Vor- und Nachteile verschiedener Distributionen unter realistischen Bedingungen zu testen. Insgesamt ist das Hauptsystem mit Debian Testing deutlich aufgeräumter und besser auf die Anforderungen angepasst als das eine Standardinstallation von Ubuntu naturgemäß vorher leisten konnte. Die Reaktionsfähigkeit einer reinen Debian Installation gegenüber Ubuntu ist, nicht ganz überraschend, besser, obwohl es nicht leicht ist dieses Gefühl in Zahlen auszudrücken. Fakt ist aber auch, dass keine der Distributionen auch nur annähernd das gesamte Potenzial eines drei Jahre "alten" Dual Core Rechners unter durchschnittlichen Bedingungen ausreizen musste. Für mich funktioniert ein Multi-Boot-System momentan sehr gut. Wer den Aufwand scheut, wird die gleichen Probleme aber sicher auch anders lösen können.
Scheinbar bin ich nicht der Einzige, der die alten Gnome Applets im Panel vermisst. Es gibt schon verschiedene Projekte auf launchpad.net, die versuchen das alte Gefühl zurück in das Panel von Unity zu bringen.
Es gibt für indicator-sysmonitor ein Deb-Paket, welches sich nach dem Herunterladen mit einem simplen Doppelklick installieren lässt. Der Multiload-Indikator ähnelt und verhält sich auch so wie das alte Gnome-Applet. Lediglich Tooltips, die den zugehörigen Zahlenwert zeigen, fehlen noch. Der Sysmonitor hingegen ist recht schlicht. Die Anzeige von CPU-Auslastung und Speicherverbrauch genügen mir aber schon. Wie immer gilt der übliche Haftungsausschluss. Bei beiden Programmen handelt es sich nicht um offiziell unterstützte Software. Fehler können natürlich jederzeit auftreten. Ich kann mit beiden Applets gut leben. Trotzdem halte ich gerne die Anzahl der zusätzlichen Softwarequellen gering. Wichtig ist mir ein PPA nur für Wine, die neusten Nvidia-Treiber oder für Openshot und Blender, wenn es um Videobearbeitung geht.
Conky
An Alternativen mangelt es nicht. Conky gibt es auch schon viele Jahre und stellt als Systemmonitor praktisch jede erdenkliche Information zur Verfügung.
aptitude install conky
Die globale Konfigurationsdatei befindet sich in /etc/conky/conky.conf und sollte am besten für den normalen Nutzer nach ~/.conkyrc kopiert werden. Zur individuellen Konfiguration von Conky lassen sich wahrscheinlich ganze Bücher füllen. Wer es deshalb einfach mag, muss die Standardkonfiguration aber nur an zwei Stellen anpassen und erhält das Ergebnis auf dem folgenden Screenshot.
Die zweite Zeile muss hinzugefügt werden. Dadurch erscheint es, als ob conky direkt auf dem Desktop liegen würde. Damit conky auch jedes Mal beim Systemstart angezeigt wird, muss es als Startprogramm unter Systemeinstellungen->Startprogramme hinzugefügt werden. Als Befehl genügt conky. Die Systemeinstellungen befinden sich neuerdings oben rechts, wenn man auf den Ausschalten Knopf klickt. 🙄 Auf das Wesentliche reduziert könnte Conky auch wie im folgenden Bild aussehen. Die Ausgabe wurde auf RAM und CPU beschränkt. Mit der Option double_buffer yes verschwindet zwar das Flackern, wenn man own_window no gesetzt hat und somit den Fensterrahmen um conky vermeidet. Nautilus wehrt sich aber dagegen und zeigt danach keine Bilder mehr auf dem Desktop an. Die Position der Ausgabe lässt sich mit den Optionen gap_x und gap_y ändern. Im Netz existieren wahre Conky-Kunstwerke. Wer mit dem Ergebnis nicht zufrieden ist, findet mit einer Suche nach conkyrc schnell viele weitere Beispiele. Mehr Informationen zu conky und mögliche Problemlösungen gibt es auf ubuntuusers.de Meine Mini-Conkyrc:
alignment bottom_right
background no
border_width 1
cpu_avg_samples 2
default_color white
default_outline_color white
default_shade_color white
draw_borders no
draw_graph_borders yes
draw_outline no
draw_shades no
use_xft yes
xftfont DejaVu Sans Mono:size=12
gap_x 735
gap_y 419
minimum_size 5 5
net_avg_samples 2
no_buffers yes
out_to_console no
out_to_stderr no
extra_newline no
own_window yes
own_window_transparent yes
own_window_class Conky
own_window_type desktop
stippled_borders 0
update_interval 1.0
uppercase no
use_spacer none
show_graph_scale no
show_graph_range no
TEXT
${color grey}RAM:$color $mem/$memmax
${color grey}CPU:$color $cpu%
Kontraste. Nach Ubuntu 11.04 nun Arch Linux als OS Nr. 3 für das Multi-Boot Projekt. Warum gerade Arch? Nun zum einen stand es auf der Liste der leichtgewichtigen Distributionen ganz oben ;), zum anderen wollte ich die erste Begegnung mit Arch Linux vor zwei Jahren etwas vertiefen. Arch hat den Ruf eine Distribution für fortgeschrittene und erfahrene Linuxnutzer zu sein, welche sich vielfältig an die eigenen Bedürfnisse anpassen lässt und auch für ältere Rechner geeignet ist. Archs Philosophie heißt dementsprechend auch K.I.S.S.. Ich wollte für mich persönlich mal ausprobieren wie schwierig es ist Arch Linux zu installieren und zu einer funktionierenden, grafischen Desktopumgebung zu kommen. Dazu habe ich mir das aktuelle Netinstall Dual Image heruntergeladen und auf CD gebrannt. Archs Motto lautet nicht umsonst "Keep it simple", was aber eher von der technischen Seite so gesehen wird. Auf Mehrsprachigkeit legt die Installation keinen besonderen Wert. Wer keinen Aufwand beim Installieren möchte, ist bei Ubuntu deshalb besser aufgehoben. Der Installationsvorgang ist textbasiert und ähnelt der alternativen Installation von Ubuntu mit dem debian-installer. Wer diese Installationsmethode scheut, sollte von Arch besser die Finger lassen. Die eigentliche Arch Installation ist meiner Meinung nach nicht unbedingt schwieriger als eine Debian Installation. Sie erfordert aber an manchen Stellen mehr Detailwissen. Automatisierte Installationsprofile gibt es zwar, worauf aber während der Installation nicht hingewiesen wird. Was Arch meiner Meinung nach so besonders macht, ist die hervorragende Dokumentation im Internet.
Im Prinzip muss man nur den ausführlichen Anweisungen folgen und ist damit auf der sicheren Seite. Nachdem ich die Tastaturbelegung mit dem Kommando km auf de-latin1-nodeadkeys eingestellt hatte, genügte ein /arch/setup auf der Konsole um die Installation in Gang zu setzen. Danach muss man sich durch die acht Schritte auf dem folgenden Screenshot arbeiten und hat danach ein funktionierendes Arch Linux Grundsystem. Vorsichtig musste ich lediglich bei Schritt Nr. 2, der Partitionierung, sein und vermeiden, dass ich meine ursprünglich mit dem debian-installer erstellte Einteilung ins Nirvana befördere. Arch befindet sich nun auf /dev/sda8. Als Swap Partition konnte ich /dev/sda7 wählen, die selbe, die auch Ubuntu 11.04 (/dev/sda6) schon benutzt. Kritisch wurde es dann noch einmal bei der Abfrage, wohin GRUB installiert werden sollte. Für eine Arch Linux Einzelinstallation wäre das der MBR auf /dev/sda gewesen. Bei meiner Einteilung musste ich ihn auf /dev/sda8 installieren. Damit GRUB im MBR der ursprünglichen Debian Testing Installation das dritte Betriebssystem erkennt, muss wiederum os-prober update-grub mit Debian ausgeführt werden. Der Download und die restliche Installation der Pakete aus dem Internet verlief problemlos. Während ich bei Debian nun aber lediglich noch aptitude install gdm gnome hätte eingeben müssen, um ein funktionierendes Gnome zu installieren, musste ich vorher noch die Unterschiede von Arch Linux kennenlernen, wofür es aber schließlich als Belohnung das brandneue Gnome 3 gab. Mehr zu Gnome 3 mit Arch Linux im nächsten Beitrag.
Kontraste. Nach Ubuntu 11.04 nun Arch Linux als OS Nr. 3 für das Multi-Boot Projekt. Warum gerade Arch? Nun zum einen stand es auf der 