Category: Linux

Vorab: Dieser Artikel ist noch in Bearbeitung

Nach fast 13 Jahren SuSE erwäge ich Ernsthaft die ganze Linux Infrastruktur auf Ubuntu zu migrieren. Nachdem ich Ubuntu 12.04 auf einem Laptop bisher zur vollen Zufriedenheit im Einsatz habe, wird allmählich aus der Erwägung Gewissheit.

Die Gründe sind mannigfaltig:

• openSUSE muß spätestens alle 18 Monate erneuert werden, ein Distributions-Update ist aber immer mit Problemen behaftet und wird bei Änderungen der Major Release (z.B. von 11.x auf 12.x) nicht empfohlen.
  Ubuntu 12.04 hat hingegen 5 Jahre Langzeitsupport.
• Ubuntu (und nur Ubuntu) bringt das Desktop System Unity mit. Eigentlich müßte man denken: Oh nein, nicht schon wieder ein neues. Tatsache ist aber, dass Unity sehr stabil läuft (vielleicht gerade wegen seiner rudimentären Einstellungsmöglichkeiten), ein durchdachtes Konzept bietet und sich geschmeidig mit der Tastatur steuern lässt.
  KDE hingegen halte ich persönlich für eine der größten Enttäuschung im Open Source Umfeld. Die Versionen 4.x sind bis heute nicht stabilisiert und immer wieder wird Kompatibilität gebrochen. XFCE läuft zwar recht gut, hat aber im Detail auch kleine Problemchen. Eventuell wäre unter openSUSE ein Gnome Desktop die Lösung, aber das Major Update von 2.x auf 3.x schreckte mich ab (wahrscheinlich wegen der schlechten Erfahrungen des KDE Updates von 3.x auf 4.x).
• Beim Paketmanagement machte ich mir Umstiegssorgen, denn zypper/YaST läuft auf openSUSE seit der Version 11.0 hervorragend. Tatsächlich steht aber apt-get und das Ubuntu Software Center auf 12.04 LTS der Konkurrenz prinzipiell in nichts nach. Die Syntaxunterschiede zwischen zypper und apt-get sind beherschbar, allerding macht zypper einen leicht besseren Eindruck.
  Es scheint aber so, dass die reduzierte Anzahl von Paketquellen bei Ubuntu im Gegensatz zu openSUSE, mehr Stabilität bietet. Hier denke ich vorwiegend an die vielen unterschiedlichen KDE/Qt Repositories bei openSUSE die sich immer wieder in einem inkonsistenten Zustand befinden und daher den simplen Wunsch ein KDE Programm updaten zu wollen, in einen Albtraum verwandeln.
• YaST mit seinen vielfältigen Einstellungen gibt es unter Ubuntu in dieser Form nicht. Nur leicht komplex angehauchte Aufgaben müssen auf der Kommandozeile erledigt werden. Die Systemsteuerung kennt nur wenige Einstellungen. Diese sind aber einwandfrei aufgearbeitet – außerdem integriert Ubuntu in den Systemeinstellungen auch die Desktopeinstellungen.
  Eine verwirrende Trennung zwischen YaST und den KDE-Systemeinstellungen wie unter openSuSE gibt es unter Ubuntu nicht.

Zu meistern sind strukturelle Unteschiede zwischen openSuSE und Ubuntu, im Detail wären das

• administrator access: Unter openSUSE wechselt man auf den root account (id:0). Dieser ist unter Ubuntu deaktiviert, man erledigt alle administrativen Aufgaben mit einem sudo Kommando. Dazu muss man natürlich Mitglied der Gruppe sudo sein.
• user-ID’sUnter Ubuntu kann man zwar auch neue User manuell mit einer User-ID unter 1000 ausstatten, es kommt dann aber zu Komplikationen bswp. bei der grafischen Anmeldung. Gerade im Umfeld von NFSv3 müssen aber die User-ID’s zwangsläufig synchronisiert werden.

Trotz erfolgreicher Installation von PDFStudio7 auf Ubuntu 12.04 und damit gelungener Intregration in das Startmenü (dash in der Ubuntu-Nomenklatura) wurde mir im Dateimanager das Programm nicht für das Öffnen von .pdf Dateien angeboten. Es lies sich auch nicht über den Menüpunkt Andere Anwendungen hervorzaubern.

Abhilfe schafft – bezogen auf den lokalen User Account – folgender Eintrag in die Datei
~/.local/share/applications/mimeapps.list

[Added Associations]
....
application/pdf=pdfstudio7-0.desktop

Die .desktop Datei selber liegt übrigens bei mir unter /usr/share/applications
Möchte man das Programm auch gleich zum Standardprogramm für .pdf Dateien machen, erweitert man die o.g. mimeapps.list Datei mit folgendem Eintrag:

[Default Applications]
....
application/pdf=pdfstudio7-0.desktop

…nein – eine Create Time gibt es tatsächlich unter POSIX nicht lautete eine nebensächliche Feststellung eines Artikels vom Juni 2007.

Auch wenn es immer noch nicht POSIX konform ist – das gegenwärtige Standardfilesystem auf Linux – ext4 – hat dieses Feature.

Abfragen lässt es sich aber derzeit mit dem stat Kommando leider noch nicht. Die Verrenkung um an das Datum zu kommen lautet:

debugfs -R 'stat NAME_OF_FILE_REALTIVE_FROM_DEVICE_MOUNT_POINT' DEVICE_MOUNT_POINT

synaptiks ist ein im KDE Umfeld angesiedeltes Programm zur Konfiguration von Touchpads (welche üblicherweise von der Fa. Synaptics stammen)

Seit synaptiks Version 0.7 steht hinter dem Programm nicht mehr der Dienst synaptiks Touchpadverwaltung – welcher automatisch in KDE gestartet wurde. Dieser sorgte dafür, dass innerhalb der KDE-Systemeinstellungen synaptiks nur konfiguriert werden musste, ohne dass man das Programm hätte explizit starten müssen.

Nun ist synaptiks ein Program ohne Dienst im Hintergrund, was folgende Auswirkungen hat:

• synaptiks funktioniert auch ohne KDE (z.B. in XFCE)
• synaptiks muss zumindest einmal explizit gestartet werden, so dass es sich im jeweiligen Tray (z.B. KDE-Kontrollleiste) verankert

In dem Snapshot sieht man die erste Seite von synaptiks, die früher in den KDE Systemsettings auftauchte. Dort sucht man sie jetzt vergebens. Dafür wird sie einem angezeigt, wenn man das Programm vom Tray aufruft.
Das wichtigste Feature ist auch gleich auf dieser Seite zu sehen: Touchpad bei Tastaturaktivität ausschalten
Der Punkt Beim Anmelden automatisch starten sollte nur aktiviert werden, wenn man den Einrichtungsdialog wirklich bei jedem login ins Windowsystem sehen möchte – ansonsten nicht anhacken. Das Tray Management von einem Windowsystem (KDE,XFCE..) kümmert sich schon um das jeweilige Einladen beim Login.

Noch eine Anmerkung: Momentan stürzt leider das Programm nach einem Wakeup von Suspend-to-RAM ab, was laut dem Autor Sebastian Wiesner bekannt und in Bearbeitung ist.

auch XFCE ist nicht von Kinder- oder Jugendkrankheiten befreit.

Falls der Auslogvorgang länger dauern sollte, im syslog eine Meldung wie folgende erscheint:
polkitd(authority=local): Unregistered Authentication Agent for unix-session:/org/freedesktop/ConsoleKit/Session21 (system bus name :1.388, object path /org/gnome/PolicyKit1/AuthenticationAgent, locale de_DE.UTF-8) (disconnected from bus)

dann ist die Wahrscheinlich (zumindest bei Version 4.8.1 auf openSUSE 11.4) gross, daß beim nächsten Login die Window-Decoration fehlen und auch andere Probleme auftauchen.

Grund dafür ist sind Probleme mit dem Sessionmanager – provozieren kann man das, wenn man bspw. Firefox beendet und die Abspeicherung der vielen Daten im .mozilla Unterverzeichnis nicht abwartet, sondern sich versuch sofort abzumelden.
Dass wirft den Sessionmanager aus der Bahn, der dann bis zu seinem Timeout braucht um in diesem Fall die Session zu schliessen.

Der workaround lautet das Verzeichnis .cache des Users zu löschen.

Die heute aktuelle KDE 4.7.0 Inkarnation beglückt einem nach dem Starten der KDE Session mit 100% CPU Auslastung durch kded4

kded4 ist der KDE daemon der vorzugsweise via D-Bus Abfragen vornimmt, die Plasma Widgets dann grafisch darstellen (notifier).
Gefüttert wird der daemon durch seine Module, die sofern sie fehlerhaft sind, wie momentan

kded_networkstatus.so (in /usr/lib64/kde auf einem x64_86 System)

dann leicht in einen busy endlos-loop gerät – bei dem erwähnten Modul pollt er sich zu Tode.
Leider ist die Fehlersuche relativ mühselig – anstatt auf der Oberfläche in den KDE Systemsettings rumzuklicken, würde ich alle Verknüpfungsdateien für kded in

/usr/share/kde4/services/kded

zuerst entfernen und dann wieder Stück für Stück hineinkopieren und anschliessend in KDE einloggen um direkt die Auswirkungen des speziellen Moduls zu sehen.

Seit geraumer Zeit werde ich nach jedem Login in einem KDE4.x System zeitverzögert mit folgender Meldung beglückt:

„Nepomuk Indexing agents have been disabled“

Zusätzlich kommt noch einiges an blabla bzgl. akonadi Beschwerden.
Die Sache ist, dass ich in den KDE Systemeinstellungen nepomuk deaktiviert habe und keine KDE PIM Programme verwende. So what?

Nachdem ich mir hier nochmals die Terminologie der KDE Lieblingsprojekte verinnerlicht habe, wurde die Ursache schnell klar, auch wenn die Hintergründe es immer noch nicht sind.

Akonadi als PIM Datenzugriffsframework benötigt unbedingt nepomuk für die Umsetzung der Suche.
Warum aber starten denn überhaupt die akonadi agents? Schon der Versuch die nicht benötigten Softwarekomponenten (alles was mit akonadi und KDEpim zu tun hat) zu löschen, schlug fehl. Sie sind so stark mit dem restlichen KDE System verzahnt, dass man entweder gleich das ganze KDE System löschen oder sie eben behalten muss.
Auch ein löschen der (aus welchem Grund auch immer) schon angelegten akonadi Resourcen in den KDE Sytemeinstellungen brachte akonadi beim KDE Start nicht zum schweigen. Es scheint, dass akonadi von banalsten Programmen wie der Plasma-Uhr, benutzt wird. An dieser Stelle gab ich nach und aktivierte nepomuk (allerdings ohne den Strigi Indexer).

Dies führte dann zu dem dubiosen Fehler, dass sich nepomuk beschwerte nicht starten zu können, da das soprano backend redland fehlt. Tatsächlich waren aber alle redland Komponenten installiert. Da ich aber in den KDE Systemeinstellungen zu nepomuk nur eine Konfigurationseinstellung bzgl. des virtuoso backends gesehen habe, schwante mir wieder eine Inkosistenz – geschuldet mangelhafter Transitionsprozesse während der fortlaufenden KDE updates in der 4.x Reihe. Abhilfe schafft das Löschen folgender nepomuk Dateien:

~/.kde4/share/config/nepomuk*
~/.kde4/share/apps/nepomuk/*

Seitdem läuft nepomuk und akonadi ohne Fehlermeldungen und v.a. ressourcenschonend im Hintergrund. Lediglich nach dem Einloggen erscheinen für wenige Augenblicke die Prozesse

nepomukservicestub
akonadi_maildispatcher_agent

mit CPU Belastung.
Übrigens war dies während der inkonsistenten Phase ganz anders. Dort liefen teilweise akonadi Prozesse, sowie das benutze mysql, wild und CPU-fressend durch die Gegend.