Neues von meinem Manjaro

inxi-v2

Hab einfach mal den Kernel 3.14 von Hand installiert. Bei Manjaro scheint es so zu sein, dass die Kernel-Linie beibehalten wird. Wenn ich also ’nen Drei-Zehner habe, gibt es immer nur Drei-Zehner-Aktualisierungen. Will ich einen aktuellen Kernel haben, muss ich eine aktuellere Linie wählen. Hab ich mal gemacht, indem ich in der Paketverwaltung den Kernel 3.14 und die dazugehörigen Header augewählt habe. Die Abhängigkeiten (VirtualBox, proprietärer Grafiktreiber) wurden anstandslos aufgelöst und installiert. Das System läuft mit dem Kernel 3.14 absolut rund.

Werbeanzeigen

Mageia 4 – Installation

Gestern meldete distrowatch.com das Erscheinen des brandneuen Mageia 4. Natürlich musste ich mir diese Distribution einmal anschauen.
Mageia hat sich 2010 von Mandriva Linux abgespalten und erscheint als Community-Projekt, was mir von vornherein schon mal sehr sympathisch ist. Ich entschied mich für den Download der Live-DVD mit Gnome-Oberfläche in 64bit, weil ich erst einmal schauen wollte. Beim herkömmlichen Installationsmedium stehen als Desktop-Oberflächen KDE, Gnome, XFCE, LXDE, Mate, Cinnamon und RazorQT zur Auswahl.
Mageia bringt eine ganze Reihe an Anwendungen mit, so dass der geneigte Tester schon einmal ordentlich loslegen kann. Firefox, Evolution, LibreOffice, Empathy… um nur einige zu nennen.

Weiterlesen

Mission LPIC-2: Endspurt

Die Qualifizierungsmaßnahme ist nun zu Ende gegangen. Ich habe sie mit sehr gutem Erfolg abgeschlossen. So steht es zumindest auf dem Zertifikat, welches ich vom Bildungsträger erhielt. Angesichts der organisatorischen und gruppendynamischen Probleme unterwegs und der damit verbundenen Nichtabsolvierung von knapp zwei Dritteln der erforderlichen Bausteinprüfungen ist dieses Ergebnis von zweifelhaftem Wert. An dieser Stelle muss ich dann auch nicht mehr darüber nachdenken, ob dieses Zertifikat irgend einen Bekanntheitsgrad in der IT-Branche hat und ich es an eine Bewerbung heften sollte.
So habe ich mich folgerichtig allein auf die externen Prüfungen des Linux Professional Institute konzentriert.
Weiterlesen

Prozessorauslastung: KDE vs. LXDE [Update]

Zugegeben, dieser Vergleich mag etwas hinken, trotzdem habe ich mal genauer hingeschaut, weil mir durch die Beschäftigung mit conky auffiel, dass KDE den Rechenknecht einigermaßen strapaziert, selbst wenn gerade nichts passiert.

load-kde-leerlauf

Außer conky, htop im Terminal und gtk-redshift laufen keine zusätzlichen Anwendungen. Der Prozessor ist dauerhaft zwischen 20 und 30% ausgelastet, dazu werden ihm mit 2.200 MHz ziemlich flotte Beine gemacht. Beachtlich! Nur…, was werkelt der arme Kerl die ganze Zeit?

Das ließ mir natürlich keine Ruhe, sodass ich mir die Werte bei LXDE anschauen musste. Hier ist das Ergebnis bei Arch Linux mit LXDE/openbox:

load-lxde-leerlauf

Hier laufen zusätzlich conky, htop im Terminal, redshift im Hintergrund, Thunderbird und Docky mit xcompmgr. Die Auslastung des Prozessors lag dauerhaft zwischen 4 und 7% bei einer Taktrate von 1.000 MHz.

Natürlich wollte ich es jetzt wissen. Ich startete Lubuntu und ließ einige Anwendungen laufen, unter anderem zwei Terminals, Chromium mit einem Tab, Skype, Leafpad und einen Netzwerkstream im VLC-Player. Interessante Werte:

load-lubuntu-action

Mir schwant, dass mit der Prozessorauslastung und höherer Taktfrequenz auch der Stromverbrauch des Rechenknechts ansteigt und die Lebenszeit womöglich verkürzt wird. Sicher werde ich nicht reicher dadurch, aber irgendwo muss man ja anfangen. Und wenn die Kiste noch ein paar Jahre läuft, nenne ich das „nachhaltig gewirtschaftet“.

Ich habe schon eine gewisse Zuneigung zu LXDE und Openbox entwickelt. Jetzt ist ein weiteres Argument dazu gekommen, auch das Arbeitspferd KANOTIX auf LXDE umzustellen. Mit einem geheimen Test habe ich schon die Vorgehensweise klar gemacht. Ich werde darüber berichten. Hier sei nur soviel verraten: es wird ähnlich frickelig wie bei Arch…

Update 14.11.2012:

Ich schrieb ja eingangs, dass der Vergleich hinken mag. Ein Indiz dafür und für die Beschäftigung des Prozessors habe ich womöglich mit dem proprietären nVidia-Treiber gefunden. Ich habe ihn in KANOTIX mit LXDE installiert, und nach der Aktivierung lag die Taktfrequenz dauerhaft bei 2.200 MHz. Das bedeutet, dass der Vergleich offenbar nicht ganz fair war, denn ich ließ KDE mit dem nVidia-Treiber gegen LXDE mit nouveau antreten, weshalb KDE von vornherein auf verlorenem Posten stand. Das allerdings bekam durch eben die etwas genauere Beschäftigung mit der Materie überhaupt erst heraus.
Leider kann ich die Prozessorauslastung in KDE mit dem nouveau-Treiber nicht testen, da ich wider Erwarten erfolgreich und schnell bei der Löschung von KDE war.

Wieder was gelernt: apt-pinning

Nicht jedes Update bietet zwangsläufig Verbesserungen, manchmal gibt es auch unerwünschte Nebenwirkungen, wenn man ständig up-to-date sein will.Ich habe das mit dem proprietären nVidia-Treiber 304.37 erfahren.

Zuerst zeigten sich die Symptome bei gtk-redshift. Im Abstand von etwa zehn Sekunden schaltete es für eine halbe Sekunde auf 6.300 Kelvin, anschließend wieder zurück auf den von mir abends bevorzugten Wert von 4.900 Kelvin, was eine ziemlich nervige Flackerei ergab.
Beim vorhergehenden Treiber 302.17 gab es dieses Farbspiel nicht. Nach einigem Probieren und Suchen fand ich eine Lösung. gtk-redshift bietet verschiedene Modi, die man mit dem Parameter -m beim Aufruf einstellen kann. Die Modi werden angzeigt mit

redshift -m list

Es werden alle verfügbaren Modi angezeigt, bei mir sind es randr (default) und vidmode. Da randr eben nicht fehlerfrei lief, rief ich gtk-redshift mit vidmode auf

gtk-redshift -l 52.5:13.4 -t 6300:4900 -m vidmode

Diesen Aufruf habe ich in den KDE-Systemeinstellungen unter „Autostart“ eingetragen, er funktioniert tadellos.

Auf das nächste Problem stieß ich heute eher zufällig, als ich Googleearth starten wollte. Zuerst tat sich gar nichts, dann rief ich Googleearth im Terminal auf. Die Fehlermeldung lautete sinngemäß, dass Googleearth bereits laufe, anderenfalls es sich um einen Fehler handele und ich ~/.googleearth/instance-running-lock löschen soll.

Das tat ich, denn

ps -A|grep google

lieferte kein Ergebnis, also war da auch kein Prozess für die Anwendung googleearth aktiv.

Das Programm startete nun. Aber es fehlte der für die Anwendung nicht unwesentliche Erdball. An dessen Stelle blinkte nur hilflos ein winziger weißer Punkt. Keine Fehlermeldung im Terminal, nichts. Eine Neuinstallation brachte keine Änderung.

Auf dem Netbook ließ sich Googleearth installieren, und mit 32bit und der Intel-Grafik läuft es. Ich vermutete also, dass der Grafiktreiber nVidia 304.37 der Übeltäter sein müsste, was bedeutet, dass ich den Treiber auf die letzte, mir bekannte funktionierende Version downgraden muss. Nach ein wenig Probieren und Lesen fand ich die für mich brauchbare Methode: Downgrade und Halten der betroffenen Pakete mit apt-pinning. Über dieses pinning lassen sich verschiedene Paketquellen bevorzugen. Ich entschied mich, die betreffenden neun Pakete mit der letzten funktionierenden Versionsnummer in der Datei /etc/apt/preferences aufzulisten:

Package: nvidia-glx
Pin: version 302.17*
Pin-Priority: 1000

Package: nvidia-settings
Pin: version 302.17*
Pin-Priority: 1000

Package: nvidia-xconfig
Pin: version 302.17*
Pin-Priority: 1000

Package: nvidia-kernel-dkms
Pin: version 302.17*
Pin-Priority: 1000

Package: libgl1-nvidia-glx
Pin: version 302.17*
Pin-Priority: 1000

Package: xserver-xorg-video-nvidia
Pin: version 302.17*
Pin-Priority: 1000

Package: nvidia-vdpau-driver
Pin: version 302.17*
Pin-Priority: 1000

Package: nvidia-alternative
Pin: version 302.17*
Pin-Priority: 1000

Package: libgl1-nvidia-glx-ia32
Pin: version 302.17*
Pin-Priority: 1000

Die Datei kann mit einem beliebigen Editor erstellt werden, wichtig sind die Leerzeilen zwischen den einzelnen Abschnitten. Außerdem sollte man die Datei root übereignen, also den Editor einfach gleich mit root-Rechten aufrufen.

Jetzt braucht es nur noch einen kleinen Befehl in der Kommandozeile, und der proprietäre nVidia-Treiber 304.37 ist Geschichte und durch 302.17 ersetzt:

su
apt-get update && apt-get dist-upgrade
reboot

Reboot ist hier angesagt, weil es die einfachste Methode ist, das Kernelmodul für den nun geänderten Treiber zu laden.

Das apt-pinning über die Versionsnummer verhindert, dass bei künftigen dist-upgrades die eben installierten älteren Pakete wieder durch neuere als 302.17 überschrieben werden. Auch wird verhindert, dass diese Pakete bei Abhängigkeitsproblemen gelöscht werden. Wenn ich doch eine neuere Version des proprietären Treibers installieren will, gibt es eine einfache Lösung:

su
mv /etc/apt/preferences /etc/apt/preferences.nvidia.old
apt-get update && apt-get dist-upgrade
reboot

Die Datei /etc/apt/preferences ist damit nicht gelöscht, sondern nur umbenannt und wird daher nicht berücksichtigt. Durch eine erneute Umbenennung zum ursprünglichen Namen kann ich bequem den alten funktionierenden Treiber wieder installieren, falls eine neue Version doch nicht zündet.

Die Geschichte vom apt-pinning ist hier schneller niedergeschrieben, als sie praktisch gedauert hat. Es war schon einige Zeit für Recherche und Probieren nötig. Letztendlich hat es sich aber gelohnt, denn ich habe wieder etwas über die Mechanismen innerhalb der Paketverwaltung gelernt. Und das Ausprobieren an einem konkreten Fall ist einprägsamer als jedes noch so intensive Studium der einschlägigen man-pages und Websites, möchte ich meinen.

Pimp my Netbook

Demnächst wird Debian „Wheezy“ eingefroren, um irgendwann in den stable-Zweig zu wandern. Das neue KANOTIX, das ich bereits auf dem Desktop teste, ist dann nicht mehr fern, was zugleich auch das Ende meiner Sonderlösung mit GNOME 2 auf dem Netbook bedeutet.

Durch die Beschäftigung mit GNOME 3 und Unity auf dem Desktop-Rechner sowie vorangegangene Tests mit Unity auf dem Netbook bin ich zu der Überzeugung gekommen, dass Unity auf dem kleinen Bildschirm des Netbooks eine recht brauchbare Oberfläche ist.

In der Zwischenzeit wurde Ubuntu 12.04 „Precise Pangolin“ veröffentlicht, und eingefleischte Ubuntunutzer sprechen vom bisher brauchbarsten Unity. Also machte ich mit einem Live-USB-Stick erste Tests, ob denn auch die Hardware mitspielt. Sie tat es anstandslos, sodass ich eine Installation auf der Festplatte wagen konnte.

Die Installation lief ohne Zwischenfälle, und das Netbook tut, was es soll. Bisher sind keine Probleme aufgetreten. Die Bedienbarkeit der Oberfläche gefällt mir, im Vergleich zu KDE mit plasma-netbook, dass ich als Alternative mit einer KDE-basierten Distribution wie KANOTIX hätte, liegt Unity eindeutig vorn. Im alltäglichen Betrieb muss „Precise Pengolin“ mit Unity nun beweisen, dass es alltagstauglich ist.