Linux @ Home

Shellskripte müssen nicht zwangsläufig an die Shell in der Konsole gebunden sein. Sie können auch ansprechend verpackt werden für Otto Normaluser. Dazu gibt es verschiedenste Ansätze. Einer der modernsten und flexibelsten ist kdialog unter KDE4. Das Besondere an kdialog ist seine Fähigkeit zur Interprozess-Kommunikation (IPC) via DBus. DBus wurde von freedesktop.org entwickelt und ist mittlerweile bei fast allen Distributionen standardmäßig vorhanden. In KDE 3 kam dafür das KDE-eigene DCOP zum Einsatz. Noch früher in KDE 1 wurde eine Corba-Implementiereung verwendet. Beide Lösungen waren jedoch zu gross und umständlich.

Mein Beispielskript hier zeigt, wie man einen Fortschrittsbalken implementiert, welcher via DBus vom laufenden Shellskript gesteuert werden kann. Natürlich kann man via DBus noch viele weitere mehr oder weniger nützliche oder witzige Dinge machen mit dem jeweiligen Dialog, wie z.B. den Titel und Inhalt laufend verändern etc.

Solche Skripte müssen übrigens nicht auf KDE beschränkt sein. Es sollte schon mittels installierten kdelibs und natürlich kdialog möglich sein, dieselben unter Gnome, XFCE etc.laufen zu lassen, obwohl dort der Einsatz von zenity (GTK-basiert) eher angebracht wäre. Zenity ist praktisch in jeder Distribution installiert. Nur Leider fehlt dort der Progress-Callback resp. die Interprozess-Kommunikation. Zenity’s Progressbar ist dadurch eher eine simple Aktivitätsanzeige. Allen Alternativen zu kdialog ist gemein, dass sie die erwähnte Progressbar lediglich indirekt implementieren, z.B. indem sie die Prozentwerte des Balkens entgegennehmen oder die Aktivität während einer Operation anzeigen, Beispiel:

find /usr/bin | zenity --progress --pulsate

Durch die Verwendung von DBus können wir vielleicht bald auf eine wirklich Desktopunabhängige Lösung hoffen, indem z.B. auch zenity die Dialoge über DBus ansteuerbar macht…

Natürlich halten damit auch wieder die sleep-Anweisungen Einzug, damit nicht alle Text vorbeihuschen. Sie verlangsamen den Ablauf zwar insgesamt, aber bei einem Prozedur wie “USB-Stick entschlüsseln und einhängen” ist dies meines erachtens vernachläßigbar zu gunsten der Lesbarkeit der Infotexte.

#!/usr/bin/env bash
 
# TODO: Dieses Skript sollte durch das udev-System aufgerufen werden
# siehe dazu /etc/udev/rules.d/90-crypto-usb-stick.rules
 
USER=myuser
DEVICE=/dev/usbstick
MAPPERDIR=/dev/mapper/crypto_usbstick
MOUNTDIR=/media/crypto_usbstick
 
dbusRef=$(kdialog --title "Crypto-USB-Stick aktivieren und einhängen" --progressbar "Starte..." 2)
sleep 1
 
if ! kdialog --password "Bitte Passwort für Crypto-USB-Stick eingeben:" | cryptsetup luksOpen $DEVICE ${MAPNAME}; then
    kdialog --error "Konnte das Cryptodevice nicht erstellen! Vermutlich falsches Passwort eingeben?"
    qdbus $dbusRef org.kde.kdialog.ProgressDialog.close
    exit 1
fi
sleep 1
 
qdbus $dbusRef org.kde.kdialog.ProgressDialog.setLabelText "Verzeichnis $MOUNTDIR wird gesucht"
if [ ! -e $MOUNTDIR ]; then
    qdbus $dbusRef org.kde.kdialog.ProgressDialog.setLabelText "Verzeichnis $MOUNTDIR wird erstellt"
    mkdir $MOUNTDIR
fi
qdbus $dbusRef Set org.kde.kdialog.ProgressDialog value 1
sleep 1
 
qdbus $dbusRef org.kde.kdialog.ProgressDialog.setLabelText "Cryptodevice wird nach $MOUNTDIR eingehängt"
if ! mount $MAPPERDIR $MOUNTDIR -orw,user,exec,uid=$USER,gid=$USER; then
    kdialog --error "Konnte den Crypto-USB-Stick nicht in $MOUNTDIR einhängen!"
    qdbus $dbusRef org.kde.kdialog.ProgressDialog.close
    exit 1
fi
sleep 1
 
qdbus $dbusRef Set org.kde.kdialog.ProgressDialog value 2
qdbus $dbusRef org.kde.kdialog.ProgressDialog.setLabelText "Vorgang erfolgreich beendet!"
sleep 2
 
qdbus $dbusRef org.kde.kdialog.ProgressDialog.close

Das Warten auf Fedora 10 hat sich mal wieder definitiv gelohnt! Ich komme trotz vorhandener ATI und Intel-Grafikkarten zwar noch nicht in den Genuss des besten grafischen Schmankerls: KMS (Kernel Mode Setting), aber der Rest scheint auf Anhieb zu klappen wie versprcchen. Es sieht aus wie aus einem Guss, der Bootprozess ist etwas schneller geworden und für mich als KDE-Fan wartet endlich ein einigermassen stabiles KDE 4.1 auf Arbeit. Pulseaudio ist stabiler geworden (wenn auch noch nicht bugfrei) und übernimmt nun alle Audio-Aufgaben, so hat Amarok z.B. gar keine Optionen mehr um die Ausgabe auf etwas anderes umzustellen und das ist gut so.

Hier ein kleiner Status meiner Installationen:

• iMac hat denselben Status (d.h. Mikro und Mausrädchen funktionieren noch nicht)
• Thinkpad: Bis auf die Thinkpad-Buttons (unter KDE4 noch nicht direkt unterstützt) alles o.k. Was mich absolut positiv überrascht und besonders freut: KDE4 scheint sogar mit eingeschalteten Desktop-Effekten genausowenig Strom zu verbrauchen wie KDE3! Im Leerlauf zwischen 11-13 Watt und mit Fensterbewegung (3D und transparent) maximal 16 Watt. Damit scheint KDE4 absolut Netbooktauglich zu sein.

Probleme

Natürlich gibt es auch bei diesem Release ein paar “Wie hat das bloss die Beta-Phase überstanden?” Erlebnisse:

• kpackagekit frisst unersättlich Memory, wenn keine Netzwerkverbindung besteht (Notebook)
• amarok 2.0 ist was die Oberfläche anbelangt noch im Betastadium und die Bedienung alles andere als intuitiv. Ausserdem werden Benutzer, die den “alten” Amarok geschätzt haben, verschreckt mit solchen krassen Oberflächen- und Backend-Änderungen
• Instabilitäten im Zusammenhang mit Xorg und KDE4 mit Dekstopeffekten. Beispiele: Abstürze (selten). Switching auf Konsole und zurück auf KDE (tty1) nicht möglich mit aktivierten Effekten (zumindest mit Intel-Grafikchip).
• xine läuft ca. 1 Sekunde bevor’s einen Speicherzugriffsfehler gibt

Nachtrag:

Nach längerer Testzeit sind mir doch noch ein paar mehr Dinge aufgefallen, vor allem solche, die eigentlich niemals so durch die Finger der Betatester rutschen sollten (ich vermute mal überhastete Updates vor dem Release?). Die Fehler betreffen die KDE-Version, über die Gnome-Version kann ich nichts sagen, da ich sie nicht benutze, aber wie ich Gnome kenne, läuft da alles stabil

• CD’s werden standardmäßig mit kscd wiedergegeben, nur leider ohne Ton! Lösung: Kaffeine benutzen In der Konfiguration das Ausgabegerät auf Phonon stellen (das sollte Standard sein, ist es aber leider nicht)
  
• Auch das Ripping-Programm (Sound Juicer) hat ‘ne Macke: Als wir eine CD der Freundin rippen wollten (frustriert durch obiges CD-Abspiel-Problem), sah ich, dass das Programm *.oga Dateien erstellte. “Na klar, Ogg Audio” dachte ich. Nur schade, dass Amarok dieses Format nicht erkennt beim Scannen der Sammlungs-Ordner! Lösung: Umbenennen nach *.ogg und Amarok erkennt die Stücke wie gehabt.

Fazit

Auf dem Notebook sollte man die Desktopeffekte nur anschalten, wenn man seine Freunde und Kollegen beeindrucken möchte. Danach sollte man vorerst darauf verzichten, weil man sonst im Gegenzug auf Funktionen wie Konsolen-Switch, Suspend-To-Ram und Suspend-To-Disk (resp. das Aufwachen macht Probleme) verzichten muss.
Sonst gibt es eigentlich nichts zu beachten, viel Spass beim Installieren und ausprobieren!

Vielleicht ist mit dem neuen Chefredaktor Andres Büchi ein neuer Stil im Beobachter eingekehrt? Das dachte ich mir, als ich den AHV-Artikel der Ausgabe 23/08 gelesen habe.
Auf mein Leser-eMail, in welchem ich mich über die Gründe dieser meines erachtens propagandistischen Schrift wunderte, habe ich überraschend eine Reaktion vom Chefredaktor persönlich erhalten (Vielleicht hat er Textbausteine verwendet, aber zumindest teilweise geht seine Antwort direkt auf mein Mail ein):

Continue reading…

Perl 5.10 ist nun bereits eine Weile draussen und hat Einzug auf die gängigen Linux-Distributionen gehalten. Aus diesem Grunde möchte ich an dieser Stelle einen kleinen Reminder bringen, welche Features für den Programmieraltag wirklich der Rede Wert sind. Viele der Neuerungen sind Backports aus der Designarbeit an Perl 6.

Da dies keine Einführung in Perl darstellt, sondern eine Info an Cracks, Admins und solche die es werden wollen, gehe ich nicht auf die Details ein. Ich schlage vor die Code-Beispiele jeweils in die Kommandozeile zu kopieren und zu damit herum zu spielen.

Wenn man die neuen Features benutzen will muss man dies im Skript deklarieren.

use feature ':5.10';

Continue reading…

All die Sparmassnahmen zeigen Wirkung: Letzte Woche unterbot mein Thinkpad im laufenden Betrieb (mit allen geladenen Modulen) die 10-Watt-Marke kurzzeitig (Langzeit 11,2W).
Und dies mit KDE 3.5 mit laufenden Anwendungen: 2 mal Konsole, gkrellm und was sonst noch so automatisch gestartet wird beim KDE unter Fedora 8:

Natürlich muss das Display dabei auf Batterie-Modus (50-60% Helligkeit) abgedunkelt sein, sonst werden sofort wieder 4-5 Watt mehr verbraucht. Externe Geräte sollten auch nicht angeschlossen sein. Nur ein simpler USB-Stick, der gemounted ist, erhöht den Verbrauch um über ein Watt. Ausserdem muss man etwas Geduld haben, um den Screenshot im richtigen Moment zu machen, weniger als 10 Watt sind wirklich eher die Ausnahme.

Wer kann dies unterbieten? Bitte im Kommentar einen Link auf den Screenshot hinterlassen, wenn Ihr’s geschafft habt ohne zu schummeln Ich weiss nicht, wieviel die neuen Netbooks (eee-PC und Co.) so brauchen, aber die müssten sowas doch mit Links erreichen, oder?