An so warmen Tagen wie heute, in denen sich das Thermometer im Arbeitsraum sich in die Nähe von 30° bewegt, kommt ab und zu Sorge über den Temperaturzustand und das Wohlbefinden der Desktop-Systeme auf. Manch einer, der vom Board-Hersteller seiner Wahl unter MS-Windows mit hübscher Zusatzsoftware verwöhnt wurde, mag sich dann fragen, wie er unter Linux an entsprechende Informationen gelangt. Unter einer aktuellen SuSE-Distribution ist das i.d.R. kein Problem dank umfänglicher Libraries und Module zur Unterstützung einer Vielfalt von Sensoren. Unter anderen Distributionen muss man sich ggf. ein kleines Startskript zum Laden der Module selbst schreiben.

Ksysguard, sensors-detect und sensors
Auf unseren Rechnern befinden sich in der Regel Asus-Boards. Nach dem Einrichten der jeweiligen Linux-Systeme (Opensuse) lassen wir immer auch das nette Tool “/usr/sbin/sensors-detect” laufen und nehmen zu den identifizierten Sensoren der Boards und des Prozessors die entsprechenden Konfigurationseinträge in der Datei /etc/modprobe.conf vor. Unter SuSE versehen wir zusätzlich die Datei “/etc/sysconfig/lmsensors” mit Einträgen wie von “sensors-detect” vorgeschlagen. Übrigens: Ein zusätzlicher Blick in die Datei “/etc/sensors.conf” ist in jedem Fall interessant und lehrreich.

Ein kleines Startscript startet dann unter Suse die Sensor-spezifischen Module während des Hochfahrens der Systeme. Ein ähnliches Skript kann man auch zum manuellen Start der Sensor-Module verwenden. Bei einem unserer Rechner sieht der zentrale Teil des Skripts etwa wie folgt aus:

modprobe i2c-nforce2
modprobe eeprom
modprobe it87
modprobe k8temp
# sleep 2 # optional
/usr/bin/sensors -s

Danach bleibt eigentlich nur noch übrig, unter der KDE-Applikation “ksysguard” ein sog. “Arbeitsblatt” für die Temperatur und Lüfterdaten anzulegen und die Updatefrequenz vorzugeben. (Die verschiedenen verfügbaren Sensoren werden im linken Bereich des “ksysguard”-Fensters angezeigt.)
Unter KDE lasse ich mich dann nicht nur über die aktuellen internen Temperaturen des lokalen Rechners (s. Bild), sondern auch über den Zustand anderer Linux-Desktop-PCs informieren (per ssh -X Verbindung). Traut man den graphischen Bildern nicht oder braucht man Werte genauer, so hilft der Aufruf von “/usr/bin/sensors” im Terminal oder an der Konsole.

KPowersave
Hat man erst einmal vernünftige Informationen über die Temperaturen des Prozessors und des Chipsatzes am Display, so lohnt es sich, verschiedene Einflussfaktoren auf die Temperatur zu studieren. U.a. kann man ein wenig mit KPowersave herumzuspielen. Viele AMD- und Intel-Prozessoren können über entsprechende Schema-Einstellungen unter KPowersave auch dynamisch getaktet werden. Voraussetzung ist i.d.R., dass eine entsprechende Option im BIOS geschaltet ist (z.B. “AMD Cool and Quiet”). Meiner Erfahrung nach bringt das Umstellen des CPU-Frequenzschemas auf “dynamic” u.U. bis zu 8 ° Celsius Temperaturabsenkung im zeitlichen Mittel. Das ist an sehr heißen Tagen eine beträchtliche Reserve und man vermeidet unter normalen Lastanforderungen permanent hoch drehende CPU-Lüfter.

Zusätzlicher Seitenlüfter im Gehäuse bei Heatpipes auf dem Mainboard
Gerade bei Mainboards mit einer Heatpipe zur Kühlung des Chipsatzes lohnt sich evtl. auch der Einbau eines kleinen (leisen) Lüfters in die seitliche Gehäusewand, der vertikal kühle Luft von außen auf die Kühlbleche der Pipes lenkt. Dieser zusätzliche Lüfter brachte bei mir eine erhebliche Temperaturabsenkungen des Boards.

Wenn man täglich mit Webseiten-Entwicklung zu tun hat, bleibt es nicht aus, dass man über Fehler in diversen Browsern stolpert.

Ärgerlich finde ich Bugs, die entstanden sind und auch nicht entdeckt wurden, weil die Entwickler/Tester nur den Normalfall betrachtet haben. Zwei schöne Beispiele liefert hier der Konqueror in seiner Rolle als Web-Browser.

Bug 1: Nur teilweise Darstellung von Bildern, wenn Webseiten geladen werden, nachdem (!) der Browser auf einen Zoomfaktor > 1 eingestellt wurde

Konqueror behandelt Bilder, deren Größe mit “em”-Vorgaben festgelegt sind, solange richtig, wie man die entsprechenden Webseiten bei normaler Schriftgröße lädt. Selbst eine nachfolgende Vergrößerung der Schriften bzw. des Browser-Bildes über “Ctrl +” (bzw. Strg +) skaliert die Bilder im erwarteten Maße. Lädt man jedoch Webseiten mit Bildern (deren größe mit “em” definiert wurde) bei bereits eingestelltem Zoomfaktor >1 (z.B. 1.5 durch zweimalige Anwendung von CTRL +), so werden die Bilder nur abgeschnitten dargestellt. Der Browser vergisst, Bildbereiche zu rendern, die über die Bildgröße hinausgehen, die bei einem Zoomfaktor von 1.0 gültig wären.

Meine Meinung: Hier wurde unzureichend getestet.

Bug 2: Properties von Iframes werden beim Laden einer Seite zu spät für Scripts bereitgestellt

Tritt im Zuge des Ladens einer Webseite das sog. “onLoad” – Ereignis auf, so sollten zu diesem Zeitpunkt alle Webseiteninhalte fertig aus dem Netz geladen sein und im Browser alle relevanten Informationen zu den geladenen Objekten zur Verfügung stehen. Eine solche Eigenschaft ist die (Gecko-spezifische) Eigenschaft “innerWidth” von “window”- oder “(i)frame”-Objekten. Firefox und Opera stellen diese Eigenschaft auch bereit, wenn das Onload-Ereignis eintritt. Nicht dagegen Konqueror – er liefert zwar “genauere” Daten als die anderen Browser, da er auch die breite von evtl. auftreteden Scrollbars der “(i)frames” berücksichtigt. Diese Daten stehen u.U. aber erst zeitverzögert nach dem Eintreten des “onLoad”-Ereignisses für die Verarbeitung in Javascript-Programmen zur Verfügung.

Meine Meinung: Ich weiß nicht, wie oft man “innerWidth” beim onLoad-Ereignis in der Praxis benötigt. Ich meine aber, dass die Vorgehensweise beim Konqueror die Verletzung einer natürlichen Erwartungshaltung an die Verfügbarkeit zu Seitenelementen billigend in Kauf nimmt. Der Sinn des onLoad-Ereignisses ist in gewisser Weise in Frage gestellt, wenn Objektinformationen erst nach diesem Zeitpunkt bereitgestellt werden. Der Bug riecht förmlich nach einem konzeptionellen Fehler bei der Behandlung von Iframes.

Es ist mir nun schon mehrfach passiert, dass bei der  Ersteinrichtung von smb4k ein kleines Unglück passiert:

Beim Einrichten des Zugriffsverfahren  (Einrichten -> Administrator) wird bei der Wahl von sudo das /etc/sudoers File editiert. Aus irgendeinem Grund geht dies ab und zu schief und die Formatierung der Datei wird zerstört.

Der korrekte Zeilenaufbau dieser Datei ist aber essentiell. Werden z.B. Zeilenumbrüche an der falschen Stelle gesetzt, funktioniert danach unter KDE “kdesu” nicht mehr.

Weder smb4k läuft danach, noch yast2, etc. – im Grunde funktioniert nichts mehr , bei dem kdesu vorgeschaltet wird. kdesu liest die Einstellungen in /etc/sudoers aus und stößt dabei auf Fehler.  Dies resultiert unter KDE dann in einer Meldung vom Typ “su meldet Fehler”.

Testen kann man das sehr einfach, indem man das Kommando “visudo” als root verwendet. Man nehme eine kleine Änderung vor und speichere das Ergebnis ab. Die resultierenden Fehlermeldungen zeigen i.d.R., was geändert werden muss.

Zusätzlich gilt, dass folgende Einträge  vorhanden sein sollten :

——-

Defaults targetpw   # ask for the password of the target user i.e. root
ALL ALL=(ALL) ALL   # WARNING! Only use this together with ‘Defaults targetpw’!

# Runas alias specification

# User privilege specification
root    ALL=(ALL) SETENV: ALL

# Uncomment to allow people in group wheel to run all commands
# and set environment variables.
# %wheel    ALL=(ALL) SETENV: ALL

# Same thing without a password
# %wheel    ALL=(ALL) NOPASSWD: SETENV: ALL

# Samples
# %users  ALL=/sbin/mount /cdrom,/sbin/umount /cdrom
# %users  localhost=/sbin/shutdown -h now

# Entries for Smb4K users.
# Generated by Smb4K. Please do not modify!
User_Alias    SMB4KUSERS = userx

Defaults:SMB4KUSERS    env_keep=”PASSWD USER”
SMB4KUSERS    host = NOPASSWD: /opt/kde3/bin/smb4k_kill
SMB4KUSERS    host = NOPASSWD: /opt/kde3/bin/smb4k_umount
SMB4KUSERS    host = NOPASSWD: /opt/kde3/bin/smb4k_mount
# End of Smb4K user entries.
—-

“host” ist durch den lokalen Rechnernamen zu ersetzen

“userx” ist durch den User zu ersetzen, der/die smb4k benutzen darf. Hier kann auch eine komma-separierte Liste von Usernamen angegeben werden.

Ob root auch smb4k benutzen sollte, ist aus Sicherheitsgründen sehr diskutabel. Ich vermeide das.