CDE – Common Desktop Environment

Leave a reply

Wer wie ich in den 1990ern auf diversen Unix-Workstations (HP-UX, AIX, usw.) gearbeitet hat, kennt sicherlich noch das Common Desktop Environment (CDE), welches 1993 von der Open Group (HP, IBM und Sun Microsystems) als proprietäre Software entwickelt wurde. Bei vielen kommerziellen Unix-Workstations war CDE bis ins Jahr 2000 der Standard-Desktop schlechthin, bis es u.a. durch Gnome oder KDE abgelöst wurde.

Am 6. August 2012 wurden die Quelltexte von CDE unter der LGPL veröffentlicht und stehen nun als OpenSource auf Sourceforge zum Download zur Verfügung.

Die Einrichtung ist ein wenig tricky, das Wiki auf Sourceforge leistet hierbei eine gute Hilfestellung. Ich habe CDE auf meinem älteren Laptop unter Linux (Ubuntu 12.04) eingerichtet und ein paar Screenshots beigefügt.

Auch wenn CDE nicht mehr ganz zeitgemäß erscheint, kann eine Einrichtung zur Nutzung auf gerade älteren Systemen aus Performancegründen durchaus sinnvoll sein – ist aber durchaus Geschmackssache 😉

CDE - The Common Desktop Environment, the classic UNIX desktop

CDE - The Common Desktop Environment, the classic UNIX desktop

CDE - The Common Desktop Environment, the classic UNIX desktop

CDE - The Common Desktop Environment, the classic UNIX desktop

Projekt: Raspberry Pi – Gameboy

119 Replies
RaspiGB-Intro

Original und Raspberry Pi-Gameboy

Heute stelle ich Euch mein neues Projekt vor: den Umbau eines klassischen Gameboys zu einer ultimativen Retro-Game-Konsole mithilfe der Raspberry Pi.

01-Intro

Vorwort

Raspberry Pi Modell B

Raspberry Pi Modell B

Die Raspberry Pi eignet sich als Einplatinen-Minicomputer für eine Vielzahl Anwendungszwecke, sei es als Mediacenter, Web- oder Cloudserver, für die Hausautomatisierung oder dank seiner freiprogrammierbaren GPIO-Schnittstelle für eine Vielzahl weiterer Projekte. Auch ich zähle mich zu den begeisterten Raspberry Pi-Fans und setze meine Raspberry zuhause primär als Mediencenter (Raspbmc) ein. Mehr zur Raspberry Pi auch unter http://raspberrypiguide.de.

Vor einiger Zeit entdeckte ich einen interessanten Artikel über eine auf Raspbian basierenden Distribution namens Retropie, welche eine Vielzahl Emulatoren unter einem grafischen Frontend zusammenfasst. Die Umsetzung ist sehr gut, die Zahl der emulierbaren Systeme beachtlich, hier eine Auswahl (Version 1.9):

Amiga, Apple (II/Mactintosh), Armstrad CPC, Arcade, Atari (800/2600/ST/STE/TT/Falcon), C64, Game Boy (Classic/Advance/Color), Game Gear, MAME, NeoGeo, Sega (Master System/Megadrive/Genesis/Mega-CD/Sega 32X), Nintendo Entertainment System (NES), N64, PC Engine, Playstation 1, ScummVM, Super Nintendo Entertainment System (SNES), Sinclair ZX Spectrum, PC/x86, Z Machine.

Später, genauer im Juli 2014 entdeckte ich ein Posting auf Facebook, was mich auf Anhieb begeisterte: Jemand hatte einen alten Gameboy mittels einer Raspberry Pi und einem 3,5″ LCD-Display umgebaut und mittels Retropie in einen „Super Pi Boy“ verwandelt.

Dieses Projekt inspirierte mich, das wollte ich auch! Die Idee zu meinem Vorhaben war also geboren, an dieser Stelle vielen Dank an „microbyter“ und seinen tollen Umbau, welchen er unter http://superpiboy.wordpress.com dokumentiert hat.

 I. Vorarbeiten

Zunächst ging es an die Planung: Welche Features sollte mein Umbau haben, was sollte gegenüber dem „Super Pi Boy“ verbessert werden? Ich entschied mich für nachfolgende Optimierungen:

  • 4 Buttons auf der Rückseite (statt 2), um mehr Bedienelemente nutzen zu können
  • Seitlicher Knopf zum Beenden der Emulation und Rückkehr zum Hauptmenü
  • Verschraubung des Gehäuses, Verbindung möglichst ohne Klebeband
  • Frontabdeckung für Display (Schutz des LCDs vor Verschmutzung)

Was wird benötigt?

Anschließend ging es an die Beschaffung der Einzelteile, die Liste hat sich im Verlauf des Umbaus mehrfach geändert, deshalb hier die finale Zusammenstellung. Bezugsquellen habe ich beigefügt, wo es möglich war:

Optionale Komponenten:

II. Versuchsaufbau & Ansteuerung GPIO

Eines der ersten Probleme, die zu lösen waren, war die Steuerung. Retropie mittels Tastatur zu bedienen, war ja kein Problem – doch wie lassen sich Steuerkreuz und Drucktaster des Gameboys für die Steuerung verwenden?

Hierzu bietet sich die GPIO-Schnittstelle an, eine gute Anleitung fand ich unter https://learn.adafruit.com/retro-gaming-with-raspberry-pi. Ein kleines C-Programm (Adafruit-Retrogame) setzt die Informationen der abgefragten GPIO-Pins (Taste gedrückt?) in entsprechend konfigurierte Tastaturbefehle um. Die entsprechenden Tastaturbefehle lassen sich im Retropie-Frontend konfigurieren.

Als die ersten Teile eingetroffen waren und ich noch auf Post von Übersee warten musste, ging es an einen ersten Versuchsaufbau, um genau dieses zu testen und die Softwareumsetzung zu realisieren.

Ein altes USB-Gamepad (Logitech Wingman) sollte als Versuchs-Gamepad herhalten, im Prinzip benötigte ich nur die Platine (PCB, printed circuit board) und das Gehäuse mit den Tasten. Also fix den IC ausgelötet

01-Versuchsaufbau Ansteuerung GPIO mit Logitech Wingman

und einzelne Drähte mit den Kontaktpunkten verlötet.

02-Versuchsaufbau Ansteuerung GPIO mit Logitech Wingman

03-Versuchsaufbau Ansteuerung GPIO mit Logitech Wingman

Die Drähte müssen vor dem Zusammenbau entsprechend beschriftet werden, um sie später korrekt anzuschließen. Anschließend erfolgte der Zusammenbau, die einzelnen Drähte habe ich mit einer Experimentierplatine verbunden und jede Taste auf Funktion überprüft. Hierzu kann z.B. eine Widerstandsmessung mittels einem Multimeter vorgenommen werden (unbetätigt = ∞ unendlich großer Widerstand, z.B. Anzeige einer „1“ auf der linken Seite des Displays / betätigt = < ∞ kleiner unendlich).

04-Versuchsaufbau Ansteuerung GPIO mit Logitech Wingman

Hierzu muss man verstehen, was ein Tastendruck eigentlich auf der Platine bewirkt. Die druckempfindlichen Bereiche sind nichts anderes als Schalter, die bei Betätigung geschlossen werden. Jeder Schalter hat seinen eigenen Verbindungsdraht (+), aber alle Schalter eine gemeinsame Masse (common ground, -). Nimmt man nun eine Widerstandsmessung zwischen Masse und z.B. Schalter „A“ vor, ist der Messwert zunächst unendlich groß. Betätigt man nun den A-Knopf, verringert sich der Messwert (kleiner unendlich) – der Schalter ist geschlossen.

Die Verbindung der Experimentierplatine mit den GPIO-Pins der Raspberry PI habe ich mittels Jumperkabeln (männlich/weiblich) vorgenommen, diese lassen sich bequem ohne Löten umstecken.

Zur Planung der Belegung der einzelnen GPIO-Pins habe ich mich an nachfolgender Pinbelegung (gültig für Raspberry Pi Modell B) orientiert:

raspberry-pi-rev2-gpio-pinout

Nun mussten die GPIO-Pins mit den einzelnen Schaltern verbunden werden, dies habe ich zunächst auf dem Papier geplant und anschließend mittels der Jumperkabel umgesetzt.

05-Versuchsaufbau Ansteuerung GPIO mit Logitech Wingman

Wie man sieht, reichten die Tasten das Gamepads nicht ganz – hier musste ich mir mit zwei Drucktastern (für Select + Start) sowie zwei weiteren Tastern aus einem Experimentierset (für die Schultertasten LI/RE) behelfen.

Nun konnte ich die Software und dessen Konfiguration entsprechend anpassen, auf den Einbau des Kitsch Bent PCB sowie der Drucktaster vorbereiten und einen finalen Anschlussplan erstellen, auf diesen komme ich später noch einmal zurück.

2014-08-03-Belegungsmatrix Planung fuer PCB

Finaler Anschlussplan / Belegungsmatrix für Kitsch Bent PCB + Taster

III. Demontage Gameboy

Zur Demontage des Gehäuses wird ein spezieller „Triwing“-Schraubendreher verwendet, welchen ich oben in der Materialliste aufgeführt habe. Nach dem Öffnen des Gehäuses ist zu beachten, das Ober- und Unterseite mit einem Flachbandkabel verbunden sind, welches vorsichtig herausgezogen werden kann.

Da von dem Gameboy selbst „nur“ das Gehäuse, Batteriefachabdeckung sowie Bedienelemente benötigt werden, können die elektrischen Komponenten, sofern noch funktionsfähig, einfach ausgebaut und als Ersatzteile für die Reparatur eines ggf. weiteren Gameboy aufbewahrt werden.

IV. Bearbeitung des Gehäuses

Nach einer Grundreinigung der Gehäuseteile und Bedienelemente ging es an die Bearbeitung. Hierzu eignet sich ein Dremel sehr gut, ich empfehle ein Sägewerkzeug sowie zwei Fräser, insbesondere zur stirnseitigen Bearbeitung. Wer noch nie mit dem Dremel gearbeitet hat, sollte zuvor ein wenig üben – gerade bei Kunststoffen ist schnell etwas zuviel Material entfernt.

Ich habe zuvor die Teile vermessen und Handskizzen erstellt, um so wenig Material wie möglich zu entfernen – dennoch muss gerade an der Unterseite der gesamte Batteriekasten einschließlich der Verrippung entfernt werden, stirnseitig habe ich eine kleine Bohrung für den Anschluss des Netzteils vorgesehen. An der Oberseite ist ein vergrößerter Ausschnitt für das Display erforderlich, sowie eine kleine Aussparung für den Lautsprecher.

Beim Batteriefach-Deckel sind 4 Bohrungen ø12,7 mm erforderlich sowie minimale Materialabtragung um die Bohrungen herum, um die Verschraubung der Taster zu ermöglichen. Hier sieht man das finale Ergebnis (oder was davon übrig geblieben ist):

01-Bearbeitung GehaeuseDie verbliebenen Öffnungen habe ich mittels kleiner Kunststoffzuschnitte und Sekundenkleber verschlossen.

Zur Befestigung habe ich zwei kleine Laschen mit kleinen Muttern M3 angeklebt, um beide Gehäusehälften miteinander verschrauben zu können, da sämtliche der früheren Befestigungspunkte bedingt durch die beengten Platzverhältnisse weichen mussten.

 V. Lötarbeiten und Verkabelung – Steuerung + GPIO

Nach dem Eintreffen des Kitsch Bent Common Ground DMG Control Panels ging es nun daran, die geplante Verkabelung der Steuerung in die Realität umzusetzen. Hierzu greife ich noch einmal meine Belegungsmatrix auf:

Finaler Anschlussplan / Belegungsmatrix für Kitsch Bent PCB + Taster

Finaler Anschlussplan / Belegungsmatrix für Kitsch Bent PCB + Taster

Zunächst führte ich die Lötarbeiten an den Drucktastern durch:

01-Steuerung Anschließend die Anbindung des Kitsch Bent PCBs:

02-Steuerung

03-Steuerung

 

Als zusätzlichen Schalter für die ESCAPE-Sequenz (Abbruch der Emulation und Rückkehr ins Frontpanel) band ich noch einen kleinen Drucktaster an den noch freien Pin 26 / GPIO 7 an und setzte dessen Masse auf Pin 14. Mit ein wenig Sekundenkleber und Heisskleber fixiert passt dieser ideal in die Öffnung des früheren Gameboy-Netzteilanschlusses:

04-Steuerung

VI. Lötarbeiten und Verkabelung – Stromversorgung + Sound

Die Stromversorgung gestaltete sich ein wenig schwieriger als zunächst gedacht. Ich wollte diese zunächst wie beim „Super Pi Boy“ mittels einer 5V-Micro-USB-Schnittstelle lösen, musste dieses Vorhaben aber letztendlich aufgeben (siehe Abschnitt LCD-Display) und mich primär auf die 12V-Schiene beschränken. Um die 5V-Komponenten wie Raspberry Pi und Audio-Verstärker zu versorgen, entschied ich mich für den Einbau eines LM2596 Schaltreglermoduls.

a) LCD-Display

Nachdem ich das Taotronics LCD-Display aus seinem Gehäuse ausgebaut hatte, stellte ich erfreut fest, das die Platine bedeutend kleiner war, als beim verwendeten Modell des „Super Pi Boy“. Doch stellte sich bei der Recherche heraus, das ein Umbau der Stromversorgung von 12V auf 5V bei diesem Modell nicht so ohne weiteres zu realisieren war – mangels tiefergehender Kenntnisse entschied ich mich, keine Lötarbeiten an der Platine durchzuführen und die Stromversorgung auf 12V zu belassen.

01-Kabelverlegung

Rückseite des 3,5″ LCD Displays

Die Anschlussbelegung ist wie folgt:

  • rot: +12V
  • schwarz: GND
  • gelb: AV2
  • weiss: AV1

Da mein Clinch-Stecker für den Videoausgang zu groß für den Einbau ins Gehäuse war, baute ich ihn auf ein Minimum um, die gelbe Ader habe ich an AV2 (gelb) und die schwarze Ader an GND angeschlossen. AV1 (weiss) blieb ungenutzt und wurde abgebunden.

02-Kabelverlegung

 

b) Spannungswandler LM2596 Schaltreglermodul

03-Kabelverlegung

Die Ausgangsspannung des Schaltreglermoduls lässt sich mittels einer Verstellschraube sehr fein regeln; dieser Schritt ist zuerst mittels eines Multimeters vorzunehmen. Ich habe eine Leerlaufspannung von 5,1V eingestellt. An den 12V-Eingang habe ich die Anschlüsse der Netzteilbuchse sowie das LCD-Display angebunden; am 5V-Ausgang das Micro-USB-Kabel für die Stromversorgung des Raspberry Pi sowie die Stromversorgung des Audio-Verstärkerboards.

Wie auf nachfolgendem Bild zu sehen, musste der Stecker für die Stromversorgung des Raspberry Pi mangels Bauraum ebenfalls massiv gekürzt werden.

04-Kabelverlegung

c) Audio + Lautsprecher

Bei der Planung entschied ich mich für Ersatzlautsprecher für den Nintendo DS, da diese zum einen vom Bauraum in das Gehäuse passten und zum anderen laut verschiedener Meinungen einen relativ gute Klangqualität aufweisen.

06-Kabelverlegung

Am Audioausgang der Raspberry Pi nutzte ich einen klassischen, abgewinkelten 3,5 mm Klinkenstecker und schaltete zwischen Ausgang und Lautsprecher einen PAM8403 Audio-Verstärker.

05-Kabelverlegung

Interessanterweise trat bei mir auf dem rechten Kanal ein sehr lautes Rauschen auf, weshalb ich mich dazu entschied, nur den linken Kanal anzubinden. Dieses Problem schien bei mir am Audioausgang der Raspberry Pi zu liegen, welche auch mit normalen Kopfhörern ein Grundrauschen auf dem rechten Kanal aufwies – nach dem Studium diverser Foren scheinen Soundprobleme am Audioausgang der Raspberry Pi keine Seltenheit zu sein. Wie auch immer – für Retrogames benötigt man im Regelfall aber keinen HiFi-Sound.

Ich habe meine elektrische Verkabelung in Form eines Schemas zusammengefasst:

Kabelverlegung

 

VII. Zusammenbau der Komponenten

Viel Platz bietet das Gameboy-Gehäuse nicht – dementsprechend benötigt man beim Zusammenbau Geduld und teilweise starke Nerven. Ich habe mit dem Oberteil des Gehäuses begonnen und zunächst den Lautsprecher mit zwei Klebepunkten Heisskleber fixiert. Anschließend erfolgte der Einbau des Displays, welches ich mittels doppelseitigem Klebeband fixierte. Zuletzt erfolgte der Einbau des Common Ground DMG Control Panel. Sämtliche offenliegende Elektronik habe ich anschließend mittels Isolierband abgedeckt.

01-ZusammenbauDie Unterseite gestaltete sich als Herausforderung – der zur Verfügung stehende Bauraum ist mehr als beengt und knapp, gerade die Kabelverlegung erfordert ein wenig „Ideenreichtum“. Gerade das ursprünglich nicht eingeplante Schaltreglermodul erforderte viel Überlegung – das Modul ist nicht gerade klein. Auf dem nachfolgenden Bild sieht man den finalen Aufbau, kurz vorm endgültigen Zusammenbau.

02-Zusammenbau

Beim Verschrauben stellte ich allerdings heraus, das die beiden Schrauben nicht ausreichend waren und gerade in der Mitte eine Befestigung fehlte – hier zeigte sich ein Spalt zwischen beiden Gehäusehälften. Ohne Klebeband liess sich dort leider nichts machen 🙁

Zum Schluss habe ich noch eine Acrylglas-Abdeckung (1 mm Dicke) zum Schutz des Displays aufgebracht (Fixierung mittels ein paar Punkten Sekundenkleber).

Anbei der finale Aufbau, im Vergleich zum Original von 1989:

04-Zusammenbau

05-Zusammenbau

06-Zusammenbau

 VIII. Schlusswort

Nach dem Zusammenbau und einem ersten Test muss ich sagen: Ich bin begeistert! 😀 Der Umbau selbst hat eine Menge Spaß gemacht und ich habe sehr viel dabei gelernt. Wenn man bedenkt, das ich kein Elektrotechniker bin und zum ersten Mal (wirklich) mit einem Lötkolben gearbeitet habe, war die Lernkurve sicherlich hoch 😀 Im Verlauf des ganzen Projekts habe ich mir einige Kenntnisse und Fähigkeiten aneignen können, das es mich umso mehr freut, das alles so reibungslos geklappt hat und am Ende sogar funktioniert. Und es macht einfach Spaß, mit dieser ultimativen Retro-Game-Konsole zu spielen 😀

An dieser Stelle noch einmal meinen herzlichen Dank für die Anregung, welche mir der Umbau von „microbyter“ unter http://superpiboy.wordpress.com gegeben hat.

So, nun seit Ihr gefragt! Ich freue mich auf Eure Zuschriften, Lob, Kritik, Ideen, Vorschläge und natürlich: Eure eigene Umsetzung Eurer ultimativen Retrogame-Konsole!

Von numothersocks und Server-Freezes

Leave a reply

Wieder ein spezielles Thema (sorry), aber sicherlich auch für andere Serverbetreiber mit ähnlichen Problemstellungen interessant.

Vorweg, „numothersock“ ist kein pfälzisches Äquivalent für die Aufforderung nach dem Griff eines bestimmten Kleidungsstücks – mitnichten.

Mein V-Server quengelte heute deshalb ein wenig herum, nach ein paar spontanen Freezes stürzte mySQL ab, anschließend frohr der Server ein und war nicht mehr erreichbar – nach einer Uptime von 100 Tagen schon ein wenig seltsam. Ein Blick ins VZPP offenbarte mir einen roten Ressorcenverbrauch – hier war von numothersock die Rede – das Limit betrug 400 und wurde am heutigen Tage desöfteren überschritten.

Bei „numothersocks“ handelt es sich um eine Anzahl von Sockets, welche zur Interprozesskommunikation dienen und hierzu geöffnet werden. Programme und Dienste öffnen also einen oder mehrere dieser Sockets, um miteinander kommunizieren zu können. Auf einem V-Server steht allerdings nur eine recht limitierte Anzahl zur Verfügung – je nach Zahl der verwendeten Dienste (apache, postfix, dovecot, mysql, voice, etc.) kann es letztendlich ein wenig knapp werden.

Werden zuviele Sockets verwendet, „hängen“ einzelne Programme oder der ganze Server – in den Logfiles unter anderem durch Meldungen wie „cannot allocate memory...“ erkennbar.

Die Socket-Verwendung lässt sich auf dem Server mittels netstat -p nachprüfen bzw. netstat -p | wc -l zum Ermitteln der Anzahl. Mittels cat /proc/user_beancounters erhält man noch eine nette Statistik hierzu.

Nutzt man Postfix als MTA (Mail Transfer Agent), kann folgender Eintrag in /etc/postfix/main.cf helfen, die Zahl der verwendeten Sockets zu reduzieren:

default_process_limit = 10

Diese Zahl ist für einen privat genutzten Mailserver mehr als ausreichend. Der Default-Wert beläuft sich im übrigen auf 100 und ist damit eher für Mailserver ausgelegt, welche ein weit größeres Volumen abwickeln müssen.

Siehe hierzu auch den folgenden Auszug aus http://www.postfix.org/TUNING_README.html:

Tuning the number of Postfix processes
The default_process_limit configuration parameter gives direct control over how many daemon processes Postfix will run. As of Postfix 2.0 the default limit is 100 SMTP client processes, 100 SMTP server processes, and so on. This may overwhelm systems with little memory, as well as networks with low bandwidth.

You can change the global process limit by specifying a non-default default_process_limit in the main.cf file. For example, to run up to 10 SMTP client processes, 10 SMTP server processes, and so on:

/etc/postfix/main.cf:
default_process_limit = 10

You need to execute „postfix reload“ to make the change effective. This limit is enforced by the Postfix master(8) daemon which does not automatically read main.cf when it changes.

You can override the process limit for specific Postfix daemons by editing the master.cf file. For example, if you do not wish to receive 100 SMTP messages at the same time, but do not want to change the process limits for other Postfix daemons, you could specify:

/etc/postfix/master.cf:
# ====================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ====================================================================
. . .
smtp inet n - - - 10 smtpd

Linux – Swap testen

Leave a reply

Die Bereitstellung eines ausreichend großen Swapspace zur Erweiterung des verfügbaren Arbeitsspeichers war früher eine zwingende Notwendigkeit – RAM war stets knapp und teuer. Bei den heutigen Mengen an RAM ist das Thema Swap sicherlich nicht mehr von so großer Bedeutung wie früher (manche verzichten mittlerweile sogar ganz darauf) – doch gibt es immer noch gute Gründe dafür, einen Bereich der Festplatte hierfür vorzusehen, je nach Anwendungsfall in der Größenordnung des 1- bis 3-fachen des verbauten RAMs.

Unter Linux kommt hierzu meistens eine Swap-Partition zum Einsatz, welche über die /etc/fstab eingebunden wird. Mittels free -m lässt sich die aktuelle Belegung des Arbeitsspeichers einschließlich Swap überprüfen.

Um die ordnungsgemäße Funktion und Nutzung der Swap-Partition zu testen, sprich als Härtetest den „Ernstfall“ zu proben, kann folgendes C-Programm verwendet werden (Nutzung auf eigene Gefahr!):

#include <stdlib.h>
#include <stdio.h>
#include <string.h>

int main(int argc, char** argv) {
  int max = -1;
  int mb = 0;
  char* buffer;

  if(argc > 1)
    max = atoi(argv[1]);

   while((buffer=malloc(1024*1024)) != NULL && mb != max) {
    memset(buffer, 0, 1024*1024);
    mb++;
    printf("Allocated %d MB\n", mb);
   }

   return 0;
}

Das Script unter memeater.c speichern und mittels gcc memeater.c -o memeater kompilieren.

Achtung! Ich weise erneut darauf hin, das die Nutzung dieses Programms ausdrücklich auf eigene Gefahr erfolgt. Bevor man dieses Programm startet, sollten alle nicht gespeicherten Daten gesichert und alle geöffneten Programme geschlossen werden.

Was macht dieses Programm? Es belegt soviel Arbeitsspeicher, wie es nur kann – entweder einen per Parameter festgelegten Wert oder den gesamten verfügbaren Arbeitsspeicher (Aufruf ohne Parameter). Das Programm sollte bei Erreichen des Maximalwerts abbrechen, um einen Speicherüberlauf (Out-of-Memory) zu verhindern – denn dieser ist bekanntermaßen alles andere als spaßig.

Der Aufruf erfolgt mittels ./memeater parameter. Als Parameter kann auch ein fester Wert in MB eingegeben werden. Um beispielsweise 900 MB zu belegen, erfolgt der Aufruf mittels ./memeater 900

Nach erfolgreichem Start sollte nachfolgende Ausgabe in ähnlicher Form erscheinen:

$ ./memeater
Allocated 1 MB
Allocated 2 MB
(...)
Allocated 16381 MB
Allocated 16382 MB
Allocated 16383 MB
Killed

Lässt man parallel einen Systemmonitor mitlaufen, kann man die Belegung des Arbeitsspeichers auch grafisch mitverfolgen. Kommt das Programm an die Grenze des zur Verfügung stehenden Speichers, kann das System kurzzeitig zum Stillstand kommen, bis der Prozess beendet wurde.

Überprüft man unmittelbar im Anschluss die Speicherbelegung mittels free -m, lässt sich ersehen, ob und inwieweit der Swapspace genutzt wird.

Arch Linux – Erste Zwischenbilanz

Leave a reply

Screenshot Arch Linux

Screenshot Arch Linux

Vor gut einer Woche habe ich mein Produktivsystem auf Arch Linux umgestellt (siehe auch Mein Wechsel zu Arch Linux). Zeit also für eine erste kurze „Zwischenbilanz“.

Ich muss zugeben, Arch Linux beeindruckt. Bis auf ein paar Kleinigkeiten habe ich keinerlei Probleme oder Inkompatibilitäten festgestellt, das System „rennt“. Zwischenzeitlich trudelten die ersten Updates ein, welche sich problemlos installieren ließen – auch wenn man hier gegenüber Systemen mit festem Release-Zyklus etwas genauer hinschauen sollte, gerade wenn eine neue Kernelversion dabei ist. In diesem Fall sollte man nach dem Update mittels mkinitcpio -p linux den Kernel neu generieren, um etwaige Probleme bereits im Vorfeld zu vermeiden.

Auch würde ich empfehlen, hin und wieder vor der Durchführung evtl. Updates einen Blick in die News unter https://www.archlinux.de oder https://www.archlinux.com zu werfen, falls gravierende Änderungen am System vorgenommen werden. Der Aufwand hält sich allerdings wirklich in Grenzen, ich habe zu diesem Zweck nur eine Mailingliste unter https://mailman.archlinux.org/mailman/listinfo/arch-announce abonniert.

Mal unabhängig von Arch Linux macht die tägliche Arbeit unter der Gnome-Shell 3.12 durchaus Spaß, viele Bedienkonzepte orientieren sich an OS X und ermöglichen eine komfortable Nutzung des Systems. Die Oberfläche wirkt sehr aufgeräumt und reagiert flott. Richtig toll finde ich auch die Erweiterbarkeit mittels der „GNOME Shell Extensions, womit sich einfach via Browser diverse Funktionalitäten wie z.B. eine Wetteranzeige oder ein Applications-Menü (Startmenü) im Panel aktivieren lassen.

Mittels des gnome-tweak-tool lassen sich umfangreiche Anpassungen vornehmen. Erscheinungsbild, Schriftenglättung, Extensions, Startprogramme und vieles mehr lässt sich hier bequem konfigurieren.

Um wieder auf Arch Linux zurückzukommen; die Integration der Gnome Shell ist meiner Meinung nach unter Arch Linux sehr gut gelungen, hier habe ich unter Ubuntu ganz andere Erfahrungen gemacht, insbesondere im Hinblick auf die Performance. Subjektiv wirkte für mich unter Ubuntu auch unter Unity alles etwas „träger“, obwohl ich fairerweise sagen muss, das die Unterschiede wirklich minimal sind und sich aus dem Zusammenspiel von Kernel, Treiber und X11 in jeweils unterschiedlichen Versionsständen und Konfigurationen über beide Distributionen ergeben. Arch ist hier gegenüber Ubuntu naturgemäß mit aktuelleren Versionsständen unterwegs, was durchaus einen Einfluss auf die Gesamtperformance des Systems hat.

In Summe kann ich Arch Linux all denjenigen empfehlen, welche schon ein wenig Erfahrung mit Linux gemacht haben und etwas mit der Shell vertraut sind.

Scannen/Kopieren per Shell-Script

1 Reply

Scannen stellt unter Linux kein großes Problem mehr dar – viele Scanner werden von der Sane-API unterstützt und lassen sich mittels diverser Frontends komfortabel nutzen.

Oftmals ist die Nutzung eines grafischen Frontends allerdings gar nicht erforderlich – gerade wenn um reine Archivierungszwecke oder einfache Kopien vollständiger A4-Seiten geht. Anstelle im grafischen Frontend zig Knöpfe zu drücken, um einen Scan als PDF-Datei abzulegen, lässt sich das Ganze per Shellscript und scanimage automatisieren. Dieses Script lässt sich auch als Starter mit der enthaltenen Befehlszeile gnome-terminal -x sh -c "/home/user/scripts/scan-a4-color-300dpi.sh" auf den Desktop legen und bequem starten.

Scannen und als PDF ablegen

Das nachfolgende Script erzeugt eine PDF-Datei in Farbe. Hierzu wird die A4-Vorlage mit 300 DPI in Farbe eingescannt, das resultierende Image optimiert, in das JPEG-Format umgewandelt und als PDF-Datei, benannt nach Datum und Uhrzeit, abgelegt. Anschließend wird diese im Dokumentbetrachter evince geöffnet.

#!/bin/bash
# Setzen der Variablen (Datum, Uhrzeit)
zeitstempel=$(date +%Y-%m-%d_%H-%M-%S)

# Scanvorgang, Ausgabeformat TIFF
scanimage \
--clear-calibration \
--format=tiff \
--mode Color \
--depth 8 \
--resolution 300 \
--icc-profile /usr/share/color/icc/adobergb1998.icc \
-l 1mm \
-t 1mm \
-x 208mm \
-y 295mm \
-p \
-v \
> /home/user/Scans-Neu/tmp/"$zeitstempel".tif

# Konvertieren des TIFF-Bildes in JPEG incl. Bildverbesserung
convert \
-quality 95 \
-gamma 1.0 \
-brightness-contrast 10x40 \
/home/user/Scans-Neu/tmp/"$zeitstempel".tif \
/home/user/Scans-Neu/tmp/"$zeitstempel".jpg

# Konvertierung ins PDF-Format
convert /home/user/Scans-Neu/tmp/"$zeitstempel".jpg /home/user/Scans-Neu/"$zeitstempel".pdf

# Entfernen der temporaeren Dateien
rm /home/user/Scans-Neu/tmp/"$zeitstempel".tif
rm /home/user/Scans-Neu/tmp/"$zeitstempel".jpg

# Anzeigen des fertigen PDF-Dokuments
evince /home/user/Scans-Neu/"$zeitstempel".pdf

Das Script lässt sich in vielen Punkten individualisieren, z.B. hinsichtlich der Farbtiefe. Reine Textvorlagen lassen sich z.B. im „Lineart“-Modus (1-Bit) scannen und mittels tiff2pdf mit geringem Speicherbedarf als PDF ablegen. Denkbar ist beispielsweise auch eine integrierte Texterkennung mittels OCR, um ein durchsuchbares Dokument zu erzeugen. Für meinen Anwendungsfall reichte das einfache Einbetten eines JPEG-Image in einem PDF allerdings aus.

Eine Abwandlung des obigen Scripts verwandelt den Scanner in einen Farbkopierer:

Scannen und ausdrucken (Kopieren)

Das folgende Script ist eine Abwandlung des obigen „Scan2PDF“-Scripts. Die A4-Vorlage wird mit 300 DPI eingescannt, das resultierende Image optimiert, mittels tiff2ps für den Druck aufbereitet und über eine Pipe an den Drucker gesendet:

#!/bin/bash
# Setzen der Variablen (Datum, Uhrzeit)
zeitstempel=$(date +%Y-%m-%d_%H-%M-%S)

# Scanvorgang, Ausgabeformat TIFF
scanimage \
--clear-calibration \
--format=tiff \
--mode Color \
--resolution 300 \
--icc-profile /usr/share/color/icc/adobergb1998.icc \
-l 1mm \
-t 1mm \
-x 208mm \
-y 295mm \
-p \
-v \
> /home/user/Scans-Neu/tmp/"$zeitstempel".tif

# Konvertieren des TIFF-Bildes incl. Bildverbesserung
convert \
-gamma 1.0 \
-brightness-contrast 10x40 \
/home/user/Scans-Neu/tmp/"$zeitstempel".tif \
/home/user/Scans-Neu/tmp/"$zeitstempel"p.tif

## Konvertieren des TIFF-Bildes ins PS-Format und starte Druckjob
tiff2ps -z -w 8.27 -h 11.69 /home/user/Scans-Neu/tmp/"$zeitstempel"p.tif | lp -d "Druckername" -o fit-to-page -o fitplot

# Entfernen der temporaeren Dateien
rm /home/user/Scans-Neu/tmp/"$zeitstempel".tif
rm /home/user/Scans-Neu/tmp/"$zeitstempel"p.tif

Natürlich gibt es auch hier wieder viele Möglichkeiten, das Script zu individualisieren.

Viel Spaß beim Basteln!

Linktipp: explainshell.com

Leave a reply

Wer wie ich gerne mit der Shell arbeitet, nutzt oftmals eine Vielzahl an Befehlskombinationen. Die erste Anlaufstelle hinsichtlich Shell-Befehlen sind sicherlich die Manpages, doch die Recherche der einzelnen Befehle und Parameter kann manchmal recht langwierig werden.

Will man schnell herausfinden, was sich z.B. hinter dem Shell-Kommando

du $HOME | sort -rn | less

verbirgt, kann man http://explainshell.com verwenden. Die Eingabe wird grafisch aufbereitet ausgegeben und auf die relevanten Abschnitte der betreffenden Manpages beschränkt, absolut empfehlenswert.

Mein Wechsel zu Arch Linux

1 Reply

Logo Arch Linux

Logo Arch Linux

Adieu Ubuntu – Welcome Arch Linux! Vor ein paar Tagen habe ich den Wechsel auf meinem Produktivsystem erfolgreich vollzogen und möchte gern meine Beweggründe und Erfahrungen mit Euch teilen.

Gründe für den Umstieg

Ich bin seit den 90ern treuer Linux-Fan (meine erste Distribution war SuSE 6.0) und nutze Ubuntu seit Erscheinen der Version 6.06 (Dapper) auf meinem Produktivsystemen, vorrangig als LTS (siehe auch mein früherer Post hierzu.) Auf meinen Servern kommt traditionell stets Debian zum Einsatz.

Bisher war ich mit Ubuntu stets sehr zufrieden, auch heute würde ich Ubuntu als Einsteigerfreundliche Distribution uneingeschränkt empfehlen. Ubuntu hat in den letzten Jahren sehr viel für die Linux-Community erreicht und eine Distribution geschaffen, welche einen problemlosen Umstieg von Windows auf Linux ermöglicht und sowohl Anfänger als auch Fortgeschrittene gleichermaßen zufriedenstellen kann.

In den vielen Jahren Ubuntu (meine zuletzt eingesetzte LTS-Version war 12.04) gab es allerdings einige Entwicklungen, die mich persönlich doch ein wenig störten. Canonical, die Firma hinter Ubuntu, löst sich vermehrt von Debian sowie Community-Standards und setzt in meinen Augen auf nicht immer nachvollziehbare Eigenentwicklungen, als heraus stechende Beispiele seien hier insbesondere der „Unity“-Desktop und die Entwicklung eines eigenen X-Servers „Mir“ als Ersatz für X.org genannt. Unity selbst finde ich persönlich gar nicht schlecht, es greift viele Konzepte auf, welche auch u.a. in OS X ihre Anwendung finden (beispielsweise das Globalmenue oder die Exposé-Funktion) und lässt sich intuitiv bedienen, wenn man sich einmal daran gewöhnt hat.

Was mich allerdings in den letzten Monaten vermehrt störte, war die mangelnde Aktualität der Softwarepakete – was beim Einsatz einer LTS-Version auch normal und durchaus erwünscht ist. Der Fokus liegt hierbei nun mal auf Stabilität: ein festgelegter Entwicklungsstand wird mit seinen Paketversionen zum Tag X eingefroren, als LTS-Fassung zur Verfügung gestellt (ggf. mit Anpassungen) und fortan nur noch mit Sicherheitsupdates versorgt. Neue Funktionen oder Verbesserungen fließen hierbei nicht ein. Ubuntu 12.04 enthielt beispielsweise Kernel 3.2, X.org 1.11.4 und Libre Office 3.5.2.

Hier gab es bereits die ersten Probleme. Der Kernel 3.2 bereitete auf meiner Hardwareplattform Schwierigkeiten (Soundchip & SSD-Controller wurden nicht erkannt), der enthaltene proprietäre NVIVIA-Treiber lag in einer veralteten Version vor und sorgte für diverse Grafikprobleme. Gut, dank des LTS Enablement Stacks ließ sich das Problem relativ schnell beheben, später fanden auch neuere NVIDIA-Treiber ihren Weg ins Repository, womit sich auch die Grafikprobleme lösten.

Doch was ist mit den Anwendungsprogrammen? Ich benötigte beispielsweise zur Erstellung meiner LaTeX-Dokumente eine halbwegs aktuelle TeX Live Distribution, doch in den Paketquellen ließ sich nur eine veraltete Fassung finden. Gleiches auch bei Libre Office – die Version 3.5 war mir für den täglichen Einsatz etwas zu angestaubt.

Kein Problem – für diesen Fall gibt es eine Vielzahl an Fremdquellen, sogenannte „Personal Package Archives“, kurz PPAs, welche die Installation neuerer Softwarepakete erlauben. Doch Fremdquellen haben den bitteren Beigeschmack, das sie die Stabilität eines LTS-Systems gefährden können und deshalb nicht ohne triftigen Grund verwendet werden sollten.

Doch am Ende kamen trotz sorgfältiger Auslese gut und gerne 10 Fremdquellen auf meinem System zum Einsatz, welche ein späteres Upgrade auf die nächste LTS-Version (spätestens 2017) aufgrund diverser Paketabhängigkeiten sehr wahrscheinlich unmöglich gemacht hätten. Doch das System lief trotz diesem Wildwuchs problemlos und hätte erst zum Supportende im Jahr 2017 ein Upgrade, respektive eine Neuinstallation verlangt.

Dann kam das neue LTS-Release 14.04 und bei mir die Überlegung zu einem Wechsel. Allerdings wusste ich bereits im Vorfeld, das ich auch mit 14.04 nicht an PPAs und einer Vielzahl manueller Nacharbeit vorbeikommen würde. Wollte ich das wirklich wieder? Dazu überzeugten mich die Neuerungen in 14.04 nicht sonderlich und würden den Aufwand einer Neuinstallation nicht rechtfertigen. Hier tat sich dann die Frage auf, ob Ubuntu für mich noch die richtige Distribution ist.

Entscheidungsfindung – Arch, Gentoo, Fedora, FreeBSD oder doch lieber Debian?

Doch wenn nicht mehr Ubuntu, welche Distribution dann? Fragen über Fragen – bei hunderten möglicher Distributionen fiel die Wahl nicht leicht. Nach dem Studium der meistgenutzten Distributionen und deren Philosophien blieben nach Abwägen der jeweiligen für mich relevanten Vor- und Nachteile Debian, Fedora, Gentoo und Arch übrig. Debian war für mich zunächst die erste Wahl (zumal ich es seit Jahren auf meinen Servern einsetze), gefolgt von Fedora, doch wollte ich diesmal möglichst aktuelle Softwarepakete auf meinem Produktivsystem. An diesem Punkt stellte sich für mich letztendlich die Frage, ob eine Snapshot-basierte Distribution mit festen Release-Zyklen die richtige Wahl für mich ist. Die Zweige Debian „testing oder „sid“ schieden aufgrund ihrer Nachteile für mich aus.

Das Konzept „Rolling Release“

Der Begriff „Rolling Release“ steht sinngemäß für „laufende Aktualisierung“. Ein Betriebssystem, welches das Konzept Rolling-Release anwendet, aktualisiert sämtliche Software-Pakete fortwährend. Betriebssystem und Anwendungsprogramme sind (je nach Distribution) somit stets auf dem aktuellen Stand der Entwicklung.

Dieses Konzept hat mich – zugegeben – recht neugierig gemacht. Stets ein aktuelles System samt Anwendungsprogrammen zu haben, ohne zu festen Zyklen den Aufwand einer Neuinstallation auf sich nehmen zu müssen, klingt zu schön um wahr zu sein. Hierzu kamen für mich zwei Distributionen in Frage, welche das Konzept des Rolling Release verfolgen: Gentoo und Arch.

Bei Gentoo, einer quellbasierten Distribution, dessen Pakete vor der Installation kompiliert werden müssen, schreckte mich allerdings der enorme Zeitaufwand des Kompilierens ab. Allein die Downtime und die Stromkosten, welche bei jedem mehrstündigen Libre Office Update durch das erneute Kompilieren aus dem Quelltext anfallen würde, stehen im keinen Verhältnis zum Nutzen. Also sollte es doch eine Distribution sein, welche Binärpakete anbietet, so fiel die Wahl auf Arch Linux.

Der Umstieg auf Arch Linux

Arch Linux verfolgt gegenüber Ubuntu einen anderen, minimalistischen Ansatz und eine etwas andere Philosophie. Es wurde als Basis-Betriebssystem für fortgeschrittene Anwender entwickelt und basiert auf den Grundsätzen:

  • Einfach halten, nicht überladen (KISS-Prinzip, „Keep it simple, stupid“)
  • Keine GUI-Werkzeuge zur Konfiguration verwenden, die die eigentlichen Vorgänge vor dem Benutzer verstecken

Der minimalistische Ansatz bietet die Möglichkeit, sich eine individuelle Systeminstallation ohne unnötigen Ballast zusammenzustellen. Ich war überzeugt, also war die Entscheidung gefallen.

Auf https://www.archlinux.de kann ein aktuelles Snapshot-Image zum Booten von CD oder USB-Stick bezogen werden. Der minimalistische Ansatz zeigte sich bereits nach dem ersten Start: Ich landete auf einem Bash-Prompt, von nun an war die Installation also meine Sache. Wer sich allerdings schon etwas mit Linux befasst hat und mit der Konsole ein wenig vertraut ist, sollte vor keine großen Schwierigkeiten stoßen, zumal das Wiki von archlinux.de eine sehr gute Anleitung bereitstellt, welche ich nur empfehlen kann: https://wiki.archlinux.de/title/Anleitung_für_Einsteiger.

Die Dokumentation der Wikis unter https://www.archlinux.org sowie https://www.archlinux.de ist wirklich hervorragend und bietet eine Vielzahl Hilfestellungen an, sollte man auf Probleme stoßen.

Die Installation und Konfiguration verlief nun Schritt für Schritt, binnen weniger Minuten war die Partitionierung und Formatierung der Festplatte sowie die Einrichtung des Bootloaders erledigt, ein paar Minuten später Netzwerk und Lokalisierung konfiguriert und die Grundinstallation samt X-Server und Gnome-Desktopumgebung erfolgt. Es macht wirklich Spaß zu sehen, wie das eigene System Stück für Stück entsteht, die Lernkurve ist hoch.

Anschließend erfolgte, wie bei jedem anderen Linux-System auch, die Installation von weiterer Paketen und Anwendungsprogrammen und abschließend die detaillierte Konfiguration. Übrigens: Wer wie ich apt als Paketmanager unter Debian/Ubuntu zu schätzen gelernt hat, wird das Arch-Pendant pacman lieben.

Hier seht Ihr das Ergebnis:

Screenshot Arch Linux

Screenshot Arch Linux


(Arch Linux 64-Bit unter Kernel 3.14.1 und Gnome 3.12.1)

Fazit

Ich bin wirklich begeistert. Was mich überrascht hat: Letztendlich benötigte ich für die Installation samt Konfiguration nicht länger, als ich bei Ubuntu benötigt hätte. Die meiste Zeit verschlingt meiner Ansicht nach grundsätzlich die individuelle Systemkonfiguration, egal ob diese unter Windows, Linux oder OS X erfolgt. Auf größere Probleme bin ich bisher nicht gestoßen, in Summe hat die Installation sogar Spaß gemacht.

Das finale System beinhaltet keinen unnötigen Ballast, da jegliche Software selbst ausgewählt und installiert wurde. Die Startzeit ab Auswahl im Grub-Bootmanager bis zum Loginprompt beträgt auf meinem System knappe 3 Sekunden, trotz identischer Zahl an Diensten deutlich schneller als unter Ubuntu. Meiner Einschätzung nach liegen die Gründe in der schlankeren Konfiguration sowie im Init-System systemd, welches Arch Linux verwendet.

Ansonsten wirkt Arch Linux unter Gnome 3 subjektiv betrachtet angenehm flott und „aus einem Guss“. Die aktuelle Software begeistert natürlich, eine Vielzahl Bugs, welche ich noch aus den älteren Softwareversionen unter Ubuntu 12.04 kannte, wurden in den neueren Fassungen behoben.

Die Aktualisierung des Systems wird innerhalb des Terminals mittels des Befehls pacman -Syu vorgenommen – einfach und effizient.

Natürlich darf man bei Rolling Releases nicht vergessen: Ein solches System benötigt Pflege. Die stetige Aktualität des Systems erfordert hin und wieder einen gewissen Wartungsaufwand bei Aktualisierungen – dies ist der Preis, den man dafür zahlt. Mir persönlich sind allerdings ein paar Minuten manuelle Konfiguration bei größeren Aktualisierungen lieber, als der immense Zeitaufwand einer vollständigen Neuinstallation. Allerdings sind die wenigen händischen Eingriffe, welche hin und wieder bei tiefgreifenden Veränderungen des Systems vorgenommen werden müssen, auf den jeweiligen Webseiten von Arch Linux sehr gut dokumentiert.

In Summe hat mich diese Distribution überzeugt – künftig werde ich also ein wenig mehr aus dem Blickwinkel von Arch Linux berichten.

Ubuntu-Distributionen und neue Kernel-Versionen

1 Reply

logo-ubuntu_su-orange-hex Die beliebte Linux-Distribution Ubuntu wird in zwei Varianten angeboten, einmal als Short Term Support (STS) und als Long Term Support (LTS). Neue Releases der STS erscheinen alle 6 Monate und werden ab Version 13.04 für 9 Monate unterstützt. LTS-Releases erscheinen alle 2 Jahre und werden ab Version 12.04 über einen Zeitraum von 5 Jahren unterstützt.

Die Qual der Wahl

Welche Variante man wählt, hängt von den eigenen individuellen Bedürfnissen ab:

  • STS-Versionen bieten aktuellere Softwarepakete und somit teils neue Funktionen gegenüber den LTS-Varianten, haben allerdings den Nachteil des relativ kurzen Supportzeitraums von 9 Monaten hinsichtlich Fehlerkorrekturen und Sicherheitsupdates. Somit eignen sie sich primär für den Einsatz auf Desktops und erfordern nach Ablauf des Supportzeitraums ein Upgrade auf die nächsthöhere Version oder (besser) eine Neuinstallation.
  • LTS-Versionen sind auf Stabilität und lange Supportzeiträume ausgelegt und eigenen sich sowohl für den Server- als auch Desktopbetrieb. Die Softwarepakete sind nicht so aktuell wie bei den STS-Versionen, dafür ist erst nach 5 Jahren ein Betriebssystem-Upgrade auf die nächste LTS-Version erforderlich. Wer aktuelle Softwareversionen (wie z.B. von LibreOffice) benötigt, kann diese recht einfach über Backports oder PPAs aktualisieren.

Ich persönlich bevorzuge generell LTS-Versionen, auch auf meiner Workstation. Hauptsächlich aufgrund des langen Supportzeitraums – eine Systemeinrichtung und Individualisierung kostet auch unter Linux etwas Zeit. Das ist etwas, was ich nicht alle 6-9 Monate machen möchte – dafür fehlen mir schlichtweg Zeit und Nerven. Dazu kommt, das ich die STS-Releases eher als „Beta“-Versionen der LTS-Fassungen sehe – manches STS-Release war nach meiner Erfahrung hin und wieder schlichtweg nicht so ausgereift, um es als zuverlässiges Arbeitssystem nutzen zu können.

Das heißt nicht, das STS-Versionen generell schlecht sind – wer Neuerungen ausprobieren möchte und dem es nichts ausmacht, alle 9 Monate eine größere Systemaktualisierung / Neuinstallation auf sich zu nehmen, der kann mit einer STS-Version durchaus glücklich werden. Weitere Infos zu den Unterschieden zwischen beiden Varianten findet man im Ubuntuusers-Wiki.

LTS – Kernel & X11

Wer sich für eine LTS-Version entschieden hat, nutzt in der Standardinstallation im Regelfall gegenüber den STS-Releases etwas ältere Kernel- und X-Server-Versionen, bei Ubuntu 12.04 „Precise Pangolin“ sind dies beispielsweise Kernel 3.2 und X-Server 1.11.4.

Dies kann über den sehr langen LTS-Unterstützungszeitraum von 5 Jahren durchaus problematisch sein – beispielsweise wenn man neue Hardware einsetzen möchte, die dem vorliegenden älteren Kernel noch nicht bekannt sein dürfte. Um den Hardwaresupport zu verbessern, werden mit den Point Releases seit 12.04.2 bei einer Neuinstallation zurückportierte neuere Versionen des Kernels und des X-Servers aus jüngeren Ubuntu-Versionen als Standard verwendet – allerdings nur bei einer Neuinstallation eines Point Releases. Bestehende LTS-Installationen werden nicht automatisch aktualisiert. Die Firma hinter Ubuntu, Canonical, definierte diese Aktualisierungsmethode als „LTS Enablement Stack-Support“.

Wenn die bestehende Installation incl. der verwendeten Hardware problemlos läuft und neu implementierte Funktionen innerhalb des Kernels nicht benötigt werden, ist ein Wechsel der Kernelversion normalerweise nicht erforderlich. Benötigt man hingegen neuere Versionen von Kernel, X-Server und MESA, lassen sich diese auch bei einer bestehenden LTS-Installation einfach nachinstallieren.

Welche Versionen dies sind, lässt sich anhand folgender Tabelle nachvollziehen:

Ubuntu-Version

Kernel

Xserver-Core

MESA

Backport aus STS-Version

12.04

3.2

1.11.4

8.0.4

–

12.04.2

3.5

1.13.0

9.0.3

Quantal (12.10)

12.04.3

3.8

1.13.3

9.1.7

Raring (13.04)

12.04.4

3.11

1.14.5

9.2.1

Saucy (13.10)

Um beispielsweise die LTS Enablement Stacks aus dem derzeit aktuellen Point Release 12.04.4 zu installieren, nutzt man folgende Zeile:

sudo apt-get install --install-recommends linux-generic-lts-saucy xserver-xorg-lts-saucy libgl1-mesa-glx-lts-saucy
sudo update-grub

Im Regelfall werden die benötigten Abhängigkeiten problemlos aufgelöst. Bei mir traten wider Erwarten ein paar Abhängigkeitsprobleme auf – ich vermute, das diese Tatsache aus einer vorhergehenden Aktualisierung resultierte. Ich konnte diese beheben, nachdem ich das Paket xserver-xorg-lts-quantal entfernt hatte:

sudo apt-get autoremove xserver-xorg-lts-quantal
sudo apt-get install --install-recommends linux-generic-lts-saucy xserver-xorg-lts-saucy libgl1-mesa-glx-lts-saucy
sudo update-grub

Wichtig:

Auch wenn es sich um stabile Point Releases handelt, rate ich dennoch zur Vorsicht und zu einem vorherigen Backup. Im schlimmsten Fall führt die Aktualisierung zu einem nicht mehr startenden System und den damit verbundenen händischen Korrekturen. Hier rate ich zunächst, das entsprechende Point Release mittels einem Live-Medium (DVD/USB-Stick) vorab auf Hardware-Inkompatibilitäten zu testen.

Sollte der neue Kernel nach der Aktualisierung des Hauptsystems zu Problemen führen (System startet nicht), kann im Grub-Bootmenü unter „Previous Linux versions“ der vorherige Kernel ausgewählt werden. In einem solchen Fall kann ein Kernel aus dem nächst niedrigeren Point Release installiert und getestet werden, beispielsweise Kernel 3.8 aus dem Point Release 12.04.3.

Festplatten-Image mit Clonezilla

Leave a reply

Wer ein Image seiner einzelnen Partitionen oder ganzer Datenträger benötigt, dem empfehle ich die OpenSource-Lösung Clonezilla. Clonezilla ist vom Funktionsumfang her absolut mit dem der kommerziellen Konkurrenz vergleichbar und lässt sich bequem von USB-Medien oder CD-ROMs booten. Die Menüführung ist Textbasisiert und erlaubt dem Nutzer die Kopie einzelner Partitionen oder kompletter Datenträger. Die Abbilder werden als Dateien auf einem anderen Datenträger gespeichert; unterstützt werden dabei sowohl interne als auch externe Datenträger sowie Netzwerkressourcen wie NFS-, SSH- oder Samba-Server.

Ich habe mich für Clonezilla entschieden, da bei der Image-Erstellung nur die belegten Dateisystemblöcke gesichert werden, was neben der Zeitersparnis insbesondere bei SSDs sinnvoll ist. Manche Tools zur Image-Erstellung sichern jede Zuordnungseinheit, ob belegt oder nicht. Schreibt man ein solches Image auf eine SSD zurück, wird jede einzelne Zuordnungseinheit belegt, was im Sinne der Lebensdauer nicht empfehlenswert ist und einen manuellen Trimvorgang (siehe Solid-State-Drives & TRIM) erforderlich macht.