Category: UNIX

Als ich einige Sondertasten auf meiner Cherry Marlin Tastatur unter Linux zum Laufen kriegen wollte, merkte ich erst dass auch dieses Modell Out-Of-The-Box unterstützt wird. Mann muss dazu aus dem Tastaturauswahlmenü (KDE,Gnome oder auch YaST...) das Modell

Cherry Blue Line CyBo@ard (alternate option)

anwählen, dann sind alle Sondertasten vorhanden und können auf bestimmte Aktionen gemappt werden.

Hintergrund sind für die Marlin Tastatur passende Einträge in der Datei

/usr/share/X11/xkb/symbols/inet 

 // Cherry Blue Line CyBo@rd (alternate option)
partial alphanumeric_keys
xkb_symbols "cherrybluea" {
    include "inet(media_nav_common)"
    key <I21>   {       [ XF86Calculator        ]       };
    key <I32>   {       [ XF86HomePage          ]       };
    key <I5F>   {       [ XF86Standby           ]       };
    key <I6C>   {       [ XF86Mail              ]       };
    ....

Diese Internetkeys sind hexadezimal kodierte Werte (nach dem I) welche sich aus dem keycode der Taste (mit xev ermittelbar) – 128 ergeben.

Beide Filesysteme sind virtuelle in-memory Filesysteme (siehe mount Kommando), die den Status des Systems reflektieren.

 /sys ist das neuere der beiden und ist mit Kernel 2.6 eingeführt worden. Ursprünglich nur gedacht um eine Geräteabbildung für Powermanagement Systeme zu bieten, wurde sysfs zum universellen Abbild von kobject Instanzen, dem Herz des Kernel 2.6 Devicemodels.

 /sys bietet eine saubere Hierachie, auf dem heute schon alle Powermanagement relevanten Programme aufbauen und wird sukzessive /proc ablösen. Es ist vom Userspace erreichbar und verspricht Kontinuität.

/proc ist ein eher unstrukturiertes Verzeichnis in dem sich allemöglichen Informationen bzgl. Prozessen und Geräte befindet. Im Gerätebereich hingegen werden Informationen sukzessive im Hinblick auf /sys verschwinden (so schon geschehen mit ACPI und USB Infos).

Wichtig hingegen ist immer noch /proc/sys – ausgehenden von diesem Basisverzeichnis lassen sich alle darunterliegenden Kernelparameter mit dem sysctl Kommando verändern.

Dieses Kommando darf man allerdings nicht mit dem Systemcall sysctl verwechseln, welches unter Linux auf der Abschussliste steht, da die Wartung quasi nicht mehr möglich ist und die Verwendung wohl gegen Null tendiert.

Der Fortschritt des KDE Projektes ist unverkennbar. Mit der neuesten Minor-Release 4.2 wurden viele Ecken geschliffen, Probleme gelöst und unter anderem das neue Powermanagement System powerdevil etabliert.

Um es mal ganz deutlich zu sagen: KDE 4.2 ist optisch das beste was es gerade auf dem Desktop Markt gibt – durch seine Konfigurationsmöglichkeiten übertrifft es Mac OS X Leopard, auch wenn das Problem der Grundkonfiguration seitens der Distributoren noch nicht gegessen ist.

Der Snapshot zeigt schon einige Highlights. Das Dashboard mit den sog. Plasma Widgets ist immer sicht- und bedienbar – nicht nur bei Aktivierung. Die Konsole ist transparent, das Rendering der Windows streichelt die Augen. Eine Aufzählung der KDE Windows Manager Eigenschaften sprengt aber den Rahmen..

..vor allem weil ich über das neue Powermanagement System sprechen wollte.

Hier der Basiseinstellungsdialog mit 2 Profile, die ich anlegen musste: Akku und Performance.

Im Bereich Profile ändern, stellt man Verhaltenswerte der Profile ein, bspw. die Helligkeit des Monitors…

.. kann aber auch bei Aktivierung des Profils – z.B. durch ziehen des Steckers – eigene Skripte auslösen.

Dies nutzte ich um einige Page Cache Werte anzupassen. Die Anregung dafür gaben mir die on-the-fly Tipps der powertop Ausgabe. Die Problematik diese Werte umzustellen lassen ist, dass Sie die Kernelkonfiguration zur Laufzeit betreffen und diese Änderungen nur von root vorgenommen werden können. Ein Shell Skript darf zudem nicht mit dem suid Bit markiert werden, so dass der billigste Trick nicht greift!

Die Lösung ist, dass ich ein Skript im Homeverzeichnis des Users anlegte, welches mit sudo das eigentlich Skript aufruft. Mit visudo gab ich dem User die Rechte dies zu tun. Die drei erforderlichen Einträge lauten folgendermassen:

1. Das Skript im User Home Verzeichnis

(für Akku Profil)

#!/bin/bash

sudo /usr/local/bin/sys_akku.sh

(für Performance Profile)

 #!/bin/bash

sudo /usr/local/bin/sys_performance.sh

2. Das Kernel Steuerungsskript

(für Akku Profile)

#!/bin/bash
/sbin/sysctl vm.dirty_writeback_centisecs=6000
/sbin/sysctl vm.dirty_expire_centisecs=6000
/sbin/sysctl vm.laptop_mode=1

(für Performance Profil)

 #!/bin/bash
/sbin/sysctl vm.dirty_writeback_centisecs=500
/sbin/sysctl vm.dirty_expire_centisecs=3000
/sbin/sysctl vm.laptop_mode=0

3. visudo Einträge

SETANYUSERHERE ALL=NOPASSWD:/usr/local/bin/sys_akku.sh
SETANYUSERHERE ALL=NOPASSWD:/usr/local/bin/sys_performance.sh

Die Werte sind ev. noch nicht optimal, ergeben aber bei powertop Messungen verbesserte Laufzeiten.

Habt Spass!

Hab jetzt mal Adobe’s Flash Player 10 für Linux installiert. Der Hauptgrund war, dass mit dieser Version endlich der Overlay Fehler beseitigt wurde, der bis Version 9 immer dann auftritt, wenn ein Menü über einer Flash Ausgabefläche erscheint – oder eben nicht erscheint.

Dieser Fehler ist tatsächlich im neuesten Release gefixt. Allerdings lässt es sich auf openSUSE 11.0 nicht über das Non-OSS Repository einspielen. Daher muss man zuerst dieses Paket löschen und dann das rpm Paket von der Adobe Webseite einspielen.

Ein manueller Link ermöglicht systemweit Firefox auf das Plugin zuzugreifen (SUSE spezifisch)

 ln -s /usr/lib/flash-plugin/libflashplayer.so /usr/lib/browser-plugins/

Die hervorragende Nachricht ist, dass Adobe ebenfalls das Plugin nativ in einer 64bit Version exklusiv für Linux anzubieten. Mann kann es von folgender Seite herunterladen.

http://labs.adobe.com/downloads/flashplayer10.html

Das zu herunterladende .tar.gz Paket enthält nur das Plugin als .so Datei. Diese kopiert man entweder in das obengenannte systemweite Verzeichnis oder nach

~/mozilla/plugins

Auch hier muss man das bestehende Paket deinstallieren und ev. nspluginwrapper deinstallieren und bei Bedarf reinstallieren. nspluginwrapper ermöglicht es 32bit plugins im 64bit Browser zu arbeiten, bspw. gibt es Adobe Reader Plugin nur als 32bit Version. Ein reinstallieren löscht der plugin Eintrag des alten flash Paketes.

Gute Nachrichten von nVIDIA! Die neue Treibergeneration 177.XX bringt wesentliche Performancegewinne gegenüber dem lange aktuellen Treiber 173.14. Zudem funktionieren jetzt endlich die Compositing Effekte des kWin Windowmanagers von KDE4 flüssig.

Die durchschnittlichen Frameraten des X2-The Threat benchmarks mit 1440×900,32bit,alle Effekte ausser Realtime-Shadows zum Vergleich (viele Testreihen)

nVIDIA 173.14: 26.0-26.2 fps

nVIDIA 177.82: 34.4-34.6 fps

Das bedeutet einen Performancegewinn von über 30%

Leider könnendiese Frameraten nicht erzielt werden, wenn die Compositing (Desktop) Effekte bei KDE4 aktiviert sind. Auch ein temporäres deaktivieren bringt nichts, solange man sich noch in der Session befindet.

Ich habe diese Problematik mal an die KDEler weitergeleitet:

http://bugs.kde.org/show_bug.cgi?id=175454

Obwohl man auf der truecrypt webseite eine (32- und 64bit) Installation für openSuSE herunterladen kann, scheint das Paket nur für openSuSE 10.3 und höher ausgelegt sein.
Bei der ersten openSuSE Distribution (10.2) kommt beim einspielen des rpm Pakets folgende Fehlermeldung (vorausgesetzt man hat schon das fuse Paket installiert)

error: Failed dependencies:

        libfuse2 is needed by truecrypt-6.1-0.i586

        libstdc++.so.6(GLIBCXX_3.4.9) is needed by truecrypt-6.1-0.i586

Kritisch an diesem Binary ist, dass eine neuere C++ Library verlangt wird, so dass man mit grosser Sicherheit sagen kann, dass ein Ignorieren der Dependencies zum Absturz des Programmes zur Laufzeit führt.

Also kommt man auf openSuSE 10.2 nicht umhin dass Source Paket selber zu kompilieren. Bei der Übersetzung merkt man dann aber, dass wxWindow mindestens in Version 2.8.x vorliegen muss und damit das von openSuSE bereitgestellte 2.6.3 Paket zu alt ist.

Hier ist die Auflistung aller Schritte, die zum Erfolg der Übersetzung von truecrypt 6.x führen.

1. Das Softwarerepository packman muss als Installationsquelle hinzugefügt werden.
2. Falls vorhanden, alle installierten wxGTK Pakete löschen – dies kann ev. dazu führen, dass aus dem packman Repository gewisse Pakete erneuert werden müssen.
3. Aus dem packman repository alle wxWidgets Pakete installieren
4. Die Pakete fuse und fuse-devel müssen installiert werden. Letzteres ist auf keiner openSuSE 10.2 DVD enthalten und muss über das OSS Software Repository eingespielt werden.
5. Das truecrypt source Archiv entpacken.
6. In das Verzeichnis truecrypt-6.1-source wechseln und dort 3 spezielle Headerdateien im Bezug auf das PKCS11 System herunterladen:

wget ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-20/pkcs11.h
wget ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-20/pkcs11f.h
wget ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-20/pkcs11t.h

dann make ausführen das entstandene binary in ein lokales bin Verzeichnis kopieren,bspw:

cp Main/truecrypt /usr/local/bin/

Auf einem neueren Linux Desktop Rechner, der Client- als auch Serverdienste übernimmt kann man auch kräftig Stromsparen. Die zentralen Einsparungspotentiale liegen bei der CPU und den Festplatten.

Auf openSuSE übernimmt im powersave Paket der powersaved Dienst die Funktion, die CPU Geschwindigkeiten zu regeln. Dabei kommen default Einstellungen zum Tragen, die unter

/etc/sysconfig/powersave

geändert werden können.Alternativ kann man auch mit einem Desktop Applet – wie Lithium unter KDE4 – die Werte anpassen.

Es handelt sich dabei um

a) das Powerschema, z.B. „Performance„, dessen Beschreibung genauere Werte für bswp. Abschaltzeiten beinhaltet und auch ein default CPU-Frequenzschema setzt.

b) das CPU-Frequenzschema, z.B. „On Demand„, welches die sog. p-States der modernen Prozessoren steuert, die Ihre Frequenz dynamisch den Lastbedingungen anpassen können

Die möglichen Werte werden unter

/sys/devices/system/cpu/cpu0/cpufreq/

aufgelistet. Dort kann man auch die aktuelle Frequenz unter „cpuinfo_cur_freq“ ablesen.

Neben der CPU verbrauchen auch die Festplatten konstant Strom, da der Spindelmotor immer in Bewegung ist. Aber auch Festplatten besitzen seit geraumer Zeit Stromsparmechanismen:

hdparm -S n /dev/sdX

sorgt für ein Abschalten nach „n“ Sekunden.

hdparm -B n

setzt den Stromsparmodus der Platte, bei der die Plattenfirmware die Spindow-Zeit regelt. „1“ sorgt für maximales Sparen, „255“ schaltet das Powermanagement ab.

Beide Werte müssen aber umsichtig gesetzt werden. Erstens vertragen klassische Desktop (noch weniger Serverfestplatten) ein häufiges aus- und anschalten nicht, ausserdem sorgen manche Prozesse wie der syslog-daemon für ein permanentes Beschreiben, was ev. die Abschaltzeit nie erreichen lässt.

Dieses Problem kann man dadurch umgehen, dass unter

/proc/sys/vm/dirty_writeback_centisecs

ein höherer Wert, Schreibaktionen auf Platte länger zwischenpuffert. Ob dies, gerade bei einem so wichtigen Dienst wie syslog, akzeptabel ist, muss jeder dann selber entscheiden.

Bei einem Intel Core Duo Rechner mit zwei 3.5“ Festplatten ist ein durchschnittlicher Verbrauch zwischen 40 – 60 W die Regel.