Linux @ Home

Selten lasse ich mich zu  solchen Postings hinreissen. Nun ist es soweit. Nachdem ich nun seit über 10 Jahren KDE nutze (seit ca. 1999), hat das Frustlevel mit KDE 4.x (Version egal) ein unerträgliches Mass erreicht. Schade, ich wäre gerne länger optimistisch gewesen bezüglich des Projektes. Ich hoffe, dieser Artikel wird nicht zu sehr als Troll-Posting aufgefasst, ich versuche so sachlich wie möglich zu bleiben (ich bin zwar kein KDE-Entwickler, kann aber Usability und Projektleitung einigermassen beurteilen)…

Ich war wirklich ein grosser Fan von KDE, habe die Gnome-Benutzer immer belächelt, weil sie für Konfigurationen Registry-ähnliche (brrrr…) Einträge in GConf machen mussten (auch heute noch?), falls es dafür kein entsprechendes Werkzeug gibt.

Als mit KDE 4.0-4.3 bereits viele enttäuschte KDE-Benutzer absprangen, bezichtigte ich sie der Ungeduld und vermutete, dass in 6 Monaten endlich Stabilität und Klarheit bezüglich der Schnittstellen, des Designs und der Oberflächen herrschen würde: Ich habe mich geirrt. Es sind mehr als 3 Jahre seit Version 4.0 vergangen, ich habe wirklich genug Geduld bewiesen. Leider ist weder die Stabilität, noch die Funktionalität auch nur annähernd an die Versprechungen der Entwickler herangekommen. Als Benutzer frisst mir KDE einfach zuviel Zeit und Ressourcen und kostet mich immer mehr Nerven.

Um nur ein paar unrühmliche Beispiele zu nennen:

• Plasma-Abstürze (diese treten je nach Grafikkarten-Treiben häufiger oder seltener auf, aber sie treten auf)
• Der “semantische Desktop” mit Nepomuk/Strigi => Zweimaliger Backendwechsel (alle Tags und Indizes konnte man vergessen oder nur mit grossem Aufwand migrieren) und immer noch kein funktionierendes Frontend, abgesehen von ein paar unintuitiven Dolphin-Buttons. Kurz gesagt: Sogar die Windows-Indizierung oder der Google-Desktop-Search funktionieren besser.
• Akonadi (Datenprovider)=> immer noch nicht vollständig integriert, nicht mal in KMail! Immerhin ist der Akonadi-Dienst heute stabil und zuverlässig.
• ALT+F2 (KRunner) war in mehreren Versionen instabil, brauchte Minutenlang, um Nepomuk oder werweisswas abzufragen und stürzt auch heute noch unregelmässig ab.
• Für mich sehr unverständlich: Das eigentlich geniale Konzept der Aktivitäten wurde niemals richtig brauchbar eingeführt. Dabei hätte man in Verbindung mit den virtuellen Deskstops Einiges erreichen können. Aber es ist bis heute nur den wenigsten Benutzern klar, das es Aktivitäten gibt geschweige denn, wie man sie nutzen oder konfigurieren kann (die Konfiguration wird sehr gut versteckt).
• Die Systemkonfigurationswerkzeuge sind immer chaotischer organisiert und bezeichnet (wer sucht das Tastaturlayout schon unter “Input Devices”?)
• Abstürze in KMail, amarok und vielen anderen Applikationen. Auf das von KDE verwendete QT-Framework sind die Abstürze kaum zurückzuführen, denn reine QT-Applikationen scheinen in der Regel sehr stabil zu arbeiten.
• Desktopeffekte: Tolle und gutaussehende Effekte, nur fehlt ein einheitliches Konzept. Der Benutzer ist ganz auf sich gestellt, die für ihn nützlichen Komponenten einzurichten. Ausserdem auch hier: Noch viel zu viele Abstürze, wenn man “ungewöhnliche” Mausbewegungen o.ä. macht, während ein Effekt in Kraft ist. Heute kann man kaum noch jemanden mit den tollen KDE-Desktopeffects beeindrucken, wenn sie nur zur Hälfte funktionieren wegen Treiberproblemen oder gar abstürzen, wenn man sie gerade einem Kollegen zeigen möchte

Dies sind auch in den meisten Foren so etwa die am häufigsten bemängelten Punkte.

Bei KDE merkt man seit einigen Jahren, dass die Projektleitung chaotisch ans Werk geht, Entwickler Aaron Seigo ignoriert seit Jahren die unzähligen Kommentare in seinem Blog und den KDE-Foren, in denen die Benutzer einfach nur Stabilität, weniger Abstürze und weniger Bugs fordern, wenn er und andere Entwickler schon wieder mit den nächsten Features auftrumpfen, während grundsätzliche Attribute noch nicht mal stabil funktionieren. Sebastian Kügler indes kündigt bereits die Betaversion von KDE 4.7 an. Auch dort viele Kommentare, dass Version vor 1.0 (1998) stabiler war, als es 4.x je war usw. Je länger die Benutzerklagen bezüglich der mangelnden Stabilität von KDE 4 ignoriert oder beschwichtigt wurden, ohne dass es spürbare Verbesserungen gab (es gab sie, aber nur für Benutzer, die in der Lage waren, immer die neuesten Versionen zu installieren), desto ungeduldiger und drängender wurde natürlich deren Ton. Mittlerweile werden sogar Kommentare gelöscht, weil sie sich im Ton ganz vergreifen, schlecht bewertet und als “Trollpost” bezeichnet. Das deutet auf Schwierigkeiten hin, die sich längerfristig auswirken dürften. Sehr schade, denn es geht hier viel Vertrauen verloren, das doch so wichtig ist für Softwareprodukte.

Was tun? Noch bis Ende letzten Jahres gab es für mich kaum eine Alternative, denn KDE hat unbestritten viele tolle Applikationen und Gnome 3 steckte scheinbar noch etwas in den Kinderschuhen.

Mit dem Release von Fedora 15 sollte Gnome 3 in brauchbarer Form vorliegen. Mit grösster Skepsis stattete ich diesr Desktopumgebung einen Besuch ab. Kurz und gut: Ich war von Anfang an begeistert! Schon mit einer so frühen Release haben die Gnome-Entwickler ein absolut stabiles und benutzbares Produkt abgeliefert! Natürlich sind noch nicht alle Applikationen und Systemkomponenten migriert worden, aber das Projekt scheint sehr gut voranzukommen. Das alte Gnome hat mir nie gefallen, zu altbacken und kaum konfigurierbar. Doch genau dieser “Mangel” an Konfigurationsmöglichkeiten scheint bei Gnome 3 gut in das Gesamtkonzept zu passen. Die Gnome-Shell ist zwar gewöhnungsbedürftig, aber sie stellt nach kurzer Zeit sogar jede Mac-Oberfläche in den Schatten. Warum? Weil man sich auf die Arbeit mit den jeweiligen Applikationen konzentrieren kann und weil die verwendeten Effekte auf den Workflow ausgelegt sind und praktisch nie abstürzen. Auch wenn ich hoffe, dass ich in Zukunft mehr konfigurieren kann (z.B. gespeicherte Sessions, in welchen die Applikationen auf zugewiesenen Desktops starten), fehlt mir im Moment nichts. Ich kann es vielleicht in die Worte fassen: Es fühlt sich alles von Anfang an richtig an, die meisten Kommandos entdeckt man intuitiv (z.B. das Navigieren in den Desktops, das Aufrufen der Gnome-Shell etc.), die Projektleitung scheint zu wissen, was das Ziel ist und das merkt man. Vielleicht erweisen sich nun die höheren Einstiegshürden in die Gnome-Entwicklung als Vorteil, weshalb Gnome-Entwickler unter Umständen etwas “reifer” und zurückhaltender sind mit Features, die dem Workflow nicht wirklich helfen.

Man darf mich also seit dieser Woche als Gnome3 (oder Gnome-Shell?) Benutzer bezeichnen. Ich kann sagen, die Migration ist mir viel leichter gefallen, da ich nur in einem Drittel der Zeit dasselbe erreichte, wie mit einer neuen KDE-Installation: Evolution ist viel stabiler geworden (stabiler als KMail war es schon immer) und es hilft einem beim Einrichten von Googlemail-IMAP-Accounts. Ausserdem integriert es Google-Kalender sauber, genauso wie Google-Kontakte uvm. Im Büro nutze ich Evolution sogar mit unserem Exchange-Server (inkl. GAL) ohne Probleme. Soweit so gut.

Nochmals: Bitte versteht mich nicht falsch, die KDE-Entwickler sind Profis und viele Applikationen möchte ich nicht mehr missen (obwohl die Anzahl schrumpft aufgrund zunehmender Abstürze). QT ist und bleibt ein geniales Framework, dass ich jederzeit GTK vorziehe, um kleine Applikationen zu entwickeln. Auch werde ich weiterhin mit Spenden die einzelnen Projekte unterstützen. Nur bezweifle ich mittlerweile offiziell, dass die Projektleitung dazu fähig ist, dieses Boot wieder in ruhigere Gewässer zu lenken. Nach der Lektüre von Frederick P. Brooks “The Mythical Man-Month”, Peter Seibel’s “Coders at Work” und anderen Materialien über vergangene Grossprojekte im Softwarebereich deutet für mich Vieles darauf hin, dass KDE4 niemals stabil werden wird. Als Entwickler muss man sich dann überlegen, ob nicht ein kompletter Neuanfang das Beste wäre. Als Benutzer hat man glücklicherweise mit Gnome 3, XFCE usw. brauchbare Alternativen.

Kaum wurde KDE SC 4.4.0 (SC steht für Software Compilation, seit ein paar Wochen nennt sich KDE so, weil es doch langsam viele Software aus dem Projekt gibt) und schon stehen für Fedora 12 die Pakete bereit. Natürlich rechnete ich mit Kinderkrankheiten, denn ein KDE 4-Release war noch nie “Produktionsreif” sondern eigentlich immer Beta. Das ist nun mal so, wen das stört, der soll doch testen und helfen, damit sich das ändert.

Auf jeden Fall wurde KDE schlanker, was die Fensterdekoration angeht. Es gibt einen Formfaktor-Umschalter, der bei mir aber zuerst einmal den kwin-Prozess abstürzen liess.  Ein Erlebnis, welches sich unter verschiedensten Umständen wiederholen sollte. Die Intention des Umschalters ist jedoch durchaus klar, denn bei Netbooks kommt ein ganz anderes Prinzip zum tragen als bei Desktops:

Continue reading…

Nachdem sich der Anfangsstress bei meinem neuen Job als Vollblut-Linux-Admin etwas zu legen beginnt, ist wieder mal Zeit für ein paar Experimente: Schon viel zu lange habe ich dieses Thema aufgeschoben, weil ich mir sagte “Sowas brauch’ ich nicht”. Jetzt wo es einmal läuft habe ich mich schnell daran gewöhnt und will gar nicht mehr anders: Dual-Monitor-Betrieb ohne Xinerama-Ärger.
Wie das geht? Erstmal wie üblich: KEINE ATI-Karte kaufen, sondern den Konkurrenten bevorzugen (vielleicht darf ich diese Aussage endlich mal relativieren in einigen Jahren). Der Rest ergibt sich fast von selbst, denn mit nvidia-settings kann man die benötigten Einstellungen machen. Der Nachteil ist, dass man bei jeder X-Session von neuem die Einstellungen machen muss, da sie nicht im .nvidia-settings gespeichert werden. Man könnte auch die X11-Konfiguration speichern, dies funktioniert bei den modernen Distributionen allerdings nicht (das xorg.conf wird immer spartanischer oder existiert gar nicht mehr). Deshalb lässt man sich die X11-Einträge von nvidia-settings anzeigen und ergänzt sie dann selbst im /etc/X11/xorg.conf:

Section "Device"
        Identifier  "Videocard0"
        Driver      "nvidia"
        Option      "NoLogo" "true"
        Option      "TwinView" "on"
        Option      "TwinViewOrientation" "RightOf"
        Option      "MetaModes" "DFP-0: nvidia-auto-select, DFP-1: nvidia-auto-select"
        Option      "Coolbits" "1"
        Option      "RandRRotation" "yes"
        Option      "AddARGBGLXVisuals" "True"
EndSection
Section "Extensions"
        Option      "Composite" "Enable"
EndSection

Auch hier gilt natürlich: Besser selber mit nvidia-settings erstellen anstatt nur kopieren.

KDE4 macht glücklicherweise fast keine Zicken mit dem Dual-Monitor-Betrieb, auch unter erschwerten Bedinungen wie bei mir (zwei verschiedene Auflösungs-Modi). Es muss lediglich eine sogenannte “Aktivität” unter Plasma hinzugefügt werden, welche sich automatisch der Auflösung des zweiten (rechten) Monitors anpasst. Anders als in anderen Betriebssystemen kann nun auch eine zweite Kontrollleiste erstellt werden, welche dem zweiten Monitor dann dieselbe Funktionalität zur Verfügung stellt wie dem “Hauptmonitor”.

Wie konnte ich sowas praktisches nur so lange ignorieren? Naja, im nächsten Artikel stelle ich Euch “multitail” vor, welches ich ebenfalls leider viele Jahre ignoriert habe.

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