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

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?

Nein, ich schliesse mich nicht einfach dem Canonical-Bashing an, aber Greg Kroah Hartman’s gesammelte Zahlen von Upstream-Kernelpatches der verschiedenen Firmen resp. Distributoren sprechen eine deutliche Sprache. Man muss dazu noch anmerken, dass er mittlerweile die Zahlen für Canonical nach oben korrigiert hat. Aber auch die hundert Patches zwischen Version 2.6.15 und 2.6.27-rc6 sind immer noch sehr wenig im Vergleich zu über elftausend von Redhat und über siebentausend von Novell.

In’s Rollen gebracht hat die Diskussion meines wissens Dave Jones mit einem Blog-Eintrag. Er reagierte damit auf eine Aussage von Canonical-Gründer Mark Shuttleworth in einem Interview mit dem standard.at, wo er sagt, dass es doch schön wäre, wenn alle Distributionen den angepassten Ubuntu-Kernel nehmen, da er doch so viele Hardware unterstütze. Greg’s Kroah-Hartman’s erster Vortrag bei einer Google-Veranstaltung und seine aktuelle Keynote auf dem “Linux Plumbers Conference” vom diesjährigen “Kernel Summit” mit den korrigierten Patch-Zahlen für Canonical setzten das Ganze fort.
Aus der Sicht der Kernel-Entwickler ist dies ein klares Missverhältnis zwischen dem in der Opensource-Szene üblichen Geben und Nehmen, was ich absolut verständlich finde.
Greg hat in seiner Keynote deutlich veranschaulicht, dass ein fehlender Upstream-Prozess, wie es bei CentOS beispielsweise der Fall ist, auch für den Benutzer mittelfristig nichts Gutes bringen wird.
Natürlich gab es kurz darauf entsprechende Gegenreaktionen von Ubuntu-Mitarbeitern.
Die Diskussion geht mittlerweile auf LWN weiter, es gibt auch Artikel, welche Canonical in Schutz nehmen vor ungerechtfertigtem Bashing. Jonathan Corbet hat darin ebenfalls Recht, wenn er meint, dass jede Distribution (meist zurecht) mit Kritik eingedeckt wird:

It is interesting to note that there appears to be a special place for distributors among those who would criticize. Red Hat, it has been said, drives things toward its own profit and has, in the past, pushed far too much bleeding-edge software on its long-suffering users. Fedora is accused of remaining insufficiently open, excessively bleeding-edge, and refusing to make the watching of flash videos just work. Novell/SUSE has done a deal with the devil. Debian, we are told, is simultaneously too chaotic and too bureaucratic, and it can never get a release out on time. Some charge that Gentoo’s community is dysfunctional, and that, in any case, it’s made up of people with too much time on their hands. And Ubuntu stands accused of taking the work of others while failing to give back to or even credit the community from which draws its software.

Mein persönliches Fazit: Es ist wichtig, dass diese Diskussion geführt wird, um den Unterschied zwischen Distributionen (Debian, Redhat, OpenSuSE, Fedora, …) und Re-Distributionen (CentOS, Ubuntu, …) zu sehen. Somit wird auch der Fokus wieder etwas zurechtgerückt, wer denn nun wirklich etwas für die gerngenannte Community macht und wer eher weniger. Letztendlich muss hier Canonical für alle Redistributoren (Mandriva, Xandros, …) als Prügelknabe herhalten, dies dürfte mittlerweile klar sein. Dennoch ist die Kritik gerechtfertigt, schliesslich handelt es sich um eine Firma, die letztendlich mit Linux ihr Geld verdienen will.

Die Verdienste von Canonical sind dennoch erheblich, wenn auch nicht im Upstream. Die Distribution hat Linux zu einen Verbreitungsschub auf dem Desktop verholfen, den es so noch nicht gab. Genau diese Tatsache wird widerum von einigen eher als Fluch denn als Segen betrachtet, es gibt also noch viel Diskussionsmaterial

Die Karriere eines Linux-Geeks verläuft meistens ähnlich: Als erstes wird ein SuSE (heute wohl eher ein Ubuntu) installiert und man erfreut sich an der einfachen und schnellen Installation und danach an den unzähligen Gratis-Tools. Und dies ohne je einen einzigen Key oder Online-Aktivierung oder Zahlung machen zu müssen (geschweige denn irgendwelche suspekten Cracks einzusetzen). Häufig folgt darauf die Neugier, unter der Haube nachzusehen. Also lernt man viele Systembefehle, etwas Bash-Skripting und schon will man auch das Herz des Betriebssystems selber backen: den Kernel. In diesem doch schon etwas fortgeschrittenen Stadium wechseln viele Benutzer zwischenzeitlich zu Gentoo, denn dort lernt man den Bootstrap-Prozess eines Linux-Systems ziemlich intensiv (auch wenn dies meiner Meinung nach etwas überschätzt wird, denn Gentoo ersetzt keine Grundausbildung in Serveradministration u.ä.)
Danach wechselt man der Stabilität zuliebe zu [bevorzugte Distribution hier einfügen], wo meistens ein relativ aktueller Kernel mit allen benötigen Modulen bereitliegt. Kaum jemand kompiliert heute noch einen Kernel wegen dem Performancegewinn oder der Datei-Grösse. All dies ist bei modernen Desktop und Laptops nicht mehr allzu relevant.
Aber trotzdem backe ich den Kernel ca. seit Version 2.6.25 selbst, zumindest für meine speziellen Maschinen. Dies hat vor allem mit der Qualität von RC-Kerneln zu tun und der Entwicklungsgeschwindigkeit, die sich meiner Laien-Meinung nach merklich erhöht hat. Musste ich für meinen iMac sehr lange warten, bis ich die Soundkarte via Hack zum laufen bekam, wird sie mit Kernel 2.6.27 direkt und korrekt erkannt. Und auch der Thinkpad X61s bedankt sich für aktuellste Intel-WLAN-Treiber (oh ja, denn der alte Zweig war ein _klein_ wenig instabil, Betroffenen wissen, was ich meine). Leider muss ich dort dann auf SE-Linux verzichten, da sich 2.6.27 nicht mit dem angegrauten Fedora 8 verträgt.

Es kann zurzeit also durchaus lohnend sein, wenn man neuere Hardware hat oder speziellere Geräte wie den iMac. Und mit einer funktioniereneden Konfiguration, welche man immer wieder aktualisiert, braucht man dazu effektiv ja nicht mehr als 5 Minuten an der Tastatur zu sitzen.

Ach ja, hier noch die Kernel-Konfiguration, wie sie für iMac und Thinkpad funktionieren sollte: kernel-config-26

Nach einer Auszeit meines Linux-Experiments auf dem iMac 24 von ca. 5 Monaten hatte ich endgültig genug vom OSX. Einfache Aufgaben wie “schnell ein Mail schreiben” u.ä. dauerten unter dem Strich einfach länger auf Mac als auf Linux (und sogar Win XP). Ich bin auch nicht bereit, für simple Progrämmchen Unsummen auszugeben, nur damit ich mit meinem “coolen” Mac endlich richtig arbeiten kann. Deshalb installierte ich also Fedora 9, neugierig, was die inzwischen zahlreich vorhandenen Updates verbessert haben. Tatsächlich lag am Jahresanfang einiges noch im Argen, wenn man den ersten Artikel anschaut. Mittlerweile sind wir jedoch bei Kernel 2.6.25 und zwei problematische Teile funktionieren nun tatsächlich besser:

Continue reading…