Libraries Suchpfade (DT_PATH vs. DT_RUNPATH)

Seit geraumer Zeit gilt in der ELF Spezifikation (betrifft Linux) das ELF Symbol DT_RPATH (oder nur rpath) als deprecated, also veraltet. Der Nachfolger ist DT_RUNPATH (oder nur runpath) und wird von den GNU linkern seit langem unterstützt.

Es gibt nur ein entscheidenden Unterschied: Während DT_RPATH zur Laufzeit vor der Umgebungsvariable $LD_LIBRARY_PATH durchsucht wurde, wird DT_RUNPATH erst nach der Umgebungsvariable ausgewertet.

Wenn diese beiden ELF Symbole gleichzeitig vorhanden sind wird DT_RPATH ignoriert. Die gcc Linker Option -Wl,-rpath erzeugt derzeit standardmässig beide, was man aber mit dem Flag –disable-new-dtags ausschalten kann um das alte Verhalten (rpath gewinnt vor $LD_LIBRARY_PATH) zu erzwingen.

Der Grund für diese – zugegeben nicht neue – Änderung besteht wohl darin mehr Druck aufzubauen um zumindest auf SW-Distributionsseite nicht mehr den LD_LIBRARY_PATH zu benutzen. Dieser sollte nur noch dem Benutzer vorbehalten sein um seine speziellen Wünsche abzudecken.

Dieses Verhalten, sowie eine genauere Beschreibung des Suchmechanismus unter Mac OS X, ist in der Präsentation über Portablen Code aktualisiert.

Metadaten in Bilddateien (shotwell vs. digikam)

Nichts ist einfach in der Informationsverarbeitung.
Um überhaupt ein Foto in einer schon mittelmässig großen Sammlung wiederzufinden, benötigt man Tags – sog. Metainformationen – bspw. den Namen des Aufgenommenen.
Diese Informationen setze ich bspw. im Raw-Programm Corel Aftershot Pro. Es bietet sog. hirachische Tags an, bspw: „Persons/Alexandra“. Diese Tags werden auch in das exportierten JPEG miteingebettet.

Sowohl shotwell als auch digikam (zwei Bildverwaltungsprogramme für Linux) zeigen mir sie an – soweit, so gut. Allerdings möchte ich mit solch einem Bildverwaltungsprogramm auch JPEG’s verwalten, die ungetaggt durch bspw. das iPhone auf dem Rechner gelandet sind. Da ich unlängst auf den Linux Rechnern Ubuntu zum Einsatz bringe, setzte ich auf das dortige Standardprogramm shotwell, welches durch aufgeräumte Bedienoberfläche und durchdachte Benutzerführung glänzt….

..aber nur damit. Denn das setzen der Metainformationen ist in shotwell 0.12.3 (Ubuntu 12.04) eine Katastrophe. Mit der Option Tags, Titel und andere Meta-Daten in die Bilddateien schreiben können die gesetzen Informationen zwar wirklich in die Datei geschrieben werden, was da aber reinkommt ist Murks.
Und das ist genau das Gegenteil von dem was digikam macht – denn das Standard KDE Bildverwaltungsprogramm behandelt die Metainformationen vorbildlich. Hier die Erklärung

Bei den Metainformationen müssen wir EXIF, IPTC und XMP unterscheiden:

EXchange Image Format for Digital Still Cameras – Informationen werden direkt von der Kamera in die Bilddatei geschrieben (v.a. technische Informationen des verwendeten Equipments) und sind nicht dafür gedacht geändert zu werden, auch wenn das natürlich mit einigen Programmen möglich ist.

International Press Telecommunication Council – Informationen sind die älteren, einfach gehaltenen Informationen. In diesem Format – wir reden immer noch über die in der Bilddatei eingebettenen Informationen – gibt es das Feld Keywords bei dem mit Komma separiert eigenen Tags (z.B. „Alexandra“) gesetzt werden können.
Leider ist die Angabe eines Zeichensatzes nicht zwingend vorgeschrieben, weswegen man Ihn entweder angeben kann, oder den Umgebungszeichensatz wählt (UNIXoide Betriebssyteme: UTF-8).
Und schon die erste Schwäche von shotwell: Die Keywords werden mit einem Latin-1 Zeichensatz (wahrscheinlich ISO-8859-1) hereingeschrieben – ohne Angabe dessen – was alle anderen Programme, inkl. des Referenzprogramms exiftools dazu veranlasst bspw. Umlaute falsch darzustellen.

eXtensible Metadata Platform ist Adobe’s letzter Streich um eine XML-basierte offene und erweiterbare Metainformationsplattform zu schaffen. Durch die Erweiterbarkeit gibt es allerdings gleich mehrere Abschnitte einer XMP Information – die übrigens sowohl in die Bilddatei eingebettet werden, aber auch als sog. sidecar file separat vorliegen kann.
Die wichtigesten Abschnitte sind Dublin Core bei den die Informationen im Feld Subject vorliegen als auch lr (Adobe Lightroom) – bei dem das Feld hierarchicalSubject gesetzt wird und genau hier kann man anstatt „Alexandra“ bspw. „Persons|Alexandra“ setzen (genau mit dieser Schreibweise).
Und genau hier versagt shotwell grandios: Anstatt „Persons|Alexandra“ in das Feld zu schreiben, wird „Persons, Persons/Alexandra“ geschrieben und in Dublin Core wird anstatt „Alexandra“, „Persons, Alexandra“ geschrieben. Diese Fehlinformationen bringen dann wiederum andere Programme, die die Metainformationen richtig handhaben (digikam,Corel Aftershot Pro,Adobe Lightroom) ausser Tritt. Die Portabilität ist hinüber.

Trotz Ubuntu ist digikam wieder das Bildverarbeitungsprogramm der Wahl auf Linux!

Murks beim Batteriewechsel

Als ich mal wieder Batterien im Kinderspielzeug austauschen musste, ist mir ein ganz dreister Fall untergekommen. Folgendes nettes Drückspielzeug

ls1

entpuppte sich als dreister Murks. Die 2 Knopfzellen (LR41, aka AG3) lassen sich sehr schwer entnehmen. Entweden man lötet die Halterung ab, oder man hebelt die eingeklebte Elektronik aus.
ls2

Diese Art des Batteriewechsels ist schon scharf an der Grenze des ElektroG §4, welche eine Europäische Richtlinie umsetzt, die festeingebaute Batterien in Elektrogeräten verhindern soll. Zudem hat das gute Teil auch kein WEEE-Symbol für gesondert zu entsorgende Elektrogeräte.
Man geht halt davon aus, dass es einfach nach Kurzgebrauch im Mülleimer landet. Die Zeche zahlen dann alle…

useradd vs. adduser

Möchte man einen bestehenden User auf einem Ubuntu System eine weitere Gruppenzugehörigkeit spendieren, so geht das auf 2 verschiedene Arten.

  1. adduser <username> <groupname>
  2. usermod -a --groups <groupname> <username>

Der Befehl der ersten Variante ist eher von High-Level Natur, der zweite hingegen von Low-Level. Gerade hier muß man aufpassen, dass der Parameter -a (append) gesetzt ist, sonst wird mit diesem Befehl die bereits bestehenden Gruppenzugehörigkeiten gelöscht!
Dies fällt überlicherweise auch erst nach einem Relogin auf.

USB Tastatur für GRUB Bootloader aktivieren

Beim Starten eines Rechners passierte jahrelang ein komische Sache, die ich erst jetzt – bedingt durch einen Anfängerfehler – auf den Grund gehen musste.

Direkt nach dem Start meldet sich wie üblich das BIOS.. und hat keinerlei Probleme mit der USB-Tastatur.
Danach die Übergabe an den GRUB Bootloader – der auf einmal keinerlei Tastatureingaben mehr entgegennimmt. Bei der finalen Übergabe an das Betriebssystem (Ubuntu Linux, openSUSE Linux) wird die Tastatur wieder erkannt

Offengestanden habe ich aus Zeitmangel die eigentlich Ursache, oder das Zusammenspiel der Komponenten im Hintergrund nicht recherchiert, hier ist aber die Abhilfe an meinem System:

Im BIOS (Phoenix BIOS) die Option Enable Legacy USB im Menu Advanced aktiviert!

Änderung der voreingestellten places (Orte) in Nautilus

Beim Standarddateimanager von Ubuntu 12.04 Nautilus kann man in der Seitenleiste bekanntlich Lesezeichen (bookmarks) anlegen, deren Name und Zielverweis wählbar ist.

Voreingestellt sind unter der Rubrik Rechner bereits ein paar Ordner, bspw. Dokumente, Bilder, Musik, Videos. Das Zielverzeichnis dieser Einträge lässt sich in Nautilus selber nicht ändern.
Die Zielverzeichnisse holt sich Nautilus – wie auch andere Programme – vom Desktop-übergreifenden Projekt freedesktop.org, welches die Einträge in folgender Datei ablegt.

$(XDG_CONFIG_HOME)/user-dirs.dirs

also im Normalfall

~/.config/user-dirs.dirs

Dort ändert man bspw. das Verzeichnis für XDG_DOWNLOAD_DIR um das Zielverzeichnis für den Download-Ordner zu ändern.

Indizierung einer neuen Qt Help Project Datei schlägt fehl

Selten tritt im QtCreator ein merkwürdiges Phänomen auf. Man fügt im Optionen Dialog eine neue Qt Help Project Datei (*.qch) hinzu und die darauf hin automatisch startende Indizierung bricht sofort (klanglos) ab.
Man merkt den Effekt natürlich im Suchfeld, denn eine Volltextsuche auf diese Hilfe liefert keine Ergebnisse zurück

Den eigentlichen Fehler kann man nur entdecken, wenn man QtCreator auf der Kommandozeile startet – dann erscheint in diesem Fall

virtual void fulltextsearch::clucene::QHelpSearchIndexWriter::run() : Failed because of CLucene exception.

Einzigste mir bekannte Lösung ist das Erzwingen einaer Neuindexierung aller Files – durch ein löschen des Index Ordners
~/.config/<Qt-Eigentümer>/qtcreator/.qhelpcollection

<Qt-Eigentümer> muss natürlich durch „Digia“ oder „Nokia„, ev. „Trolltech“ ersetzt werden. Das kommt darauf an, wann der Basisordner erstmalig erstellt wurde.

Kommando in bash kann nicht starten obwohl ‚which‘ es findet

Manchmal liegen Programme in verschiedenen Versionen vor und verlangen nach einem Ansatz der es erlaubt die verschiedenen Versionen relativ einfach zu starten.
Eine Möglichkeit ist es die PATH Umgebungsvariable so zu setzen, dass mehrere Verzeichnisse die das Programm beinhalten gelistet sind, z.B.

PATH=~/binNeu:~/binAlt

Ein fikives Programm testMe ,würde nun aus ~/binNeu starten. Wenn man nun temporär dieses Verzeichnis umbenennt, sollte testMe aus ~/binAlt gestartet werden.
Tatsächlich wird das auch vom which Kommando so angezeigt. Bei der Ausführung von testMe, gibt die bash erstaunlicherweise die Fehlermeldung aus, das ~/binNeu/testMe (!) nicht gefunden wird.

Grund dafür ist eine Cache-Hashtable welche die bash am Anfang anlegt um einen Programmstart zu beschleunigen. Und genau diesen muss man in diesem Fall mit folgendem Kommando löschen.

hash -r

Alternativ könnte man auch das File sourcen, welches direkt oder indirekt die PATH Variable setzt, oder schlicht die bash schließen und neustarten.

Pakteinstallationsprogramme unter openSUSE vs. Ubuntu

Manchmal möchte man auch ein spezielles Paket schnell einspielen oder deinstallieren – ohne Rücksicht auf die vorhandene SW Repository Struktur.
Ehrlicherweisse muß man dazu sagen, dass dieser Ansatz immer mehr an Bedeutung verliert, da diese Aufgabe einerseits von den (High-Level) Paketmanagern ebenso übernommen wird und andererseits schlichte grafische Frontends (im Dateimanager integriert) diese Aufgabe auch schnell meistern.
Wie auch immer, Ubuntu schickt dpkg für die Low-Level Aufgabe ins Rennen, während openSUSE rpm benutzt. Hier ein Vergleich der Systeme:

Aufgabe rpm dpkg
Alle installierten Packages auflisten     rpm -qa dpkg -l
Information bzgl. eines Packages anzeigen     rpm -qi dpkg -p
Den Inhalt eines Packages auflisten     rpm -ql dpkg -L
Zugehöriges Package zum File demo finden     rpm -qf demo dpkg --search demo
Installieren eines Packages demo     rpm -i [-v -h] demo     dpkg -i demo
Update eines Packages demo     rpm -U [-v -h] demo     dpkg -i demo
Deinstallieren eins Packages demo     rpm -e demo dpkg -r demo oder dpkg -P demo (s.u.)

Hier geht kein Programm als Sieger vom Platz. Persönlich gefällt mir die Ausgabeformatierung von rpm meistens besser.
Andererseits scheint es so, dass dpkg manchmal filigranere Optionen anbieten. Beim Löschen eines Packages bspw. unterscheidet dpkg die Option -r (remove) welche nur die installierten binaries löscht (Paketstatus ist immer noch vorhanden: un) und die Option -P (purge) welches auch die vorhandenen Konfigurationsdateien löscht und damit das Package vollständig löscht.

Paketmanager unter openSUSE vs. Ubuntu

Die Installation/Deinstallation von Softwarepaketen unter Berücksichtigung von Abhängigkeiten zu anderen Paketen erfordert nicht nur ein simples Paketinstallationsprogramm auf unterer Ebene (Low Level) sondern ein Paketmanagementsystem auf oberer Ebene (High Level), welches die verfügbare Software mit Hilfe sog. Software-Repositories.
Ubuntu schickt dafür apt ins Rennen, während openSUSE zypp benutzt. Hier ein Vergleich der Systeme:

Aufgabe zypper apt-get
Vorhandene SW Repositories auflisten     zypper repos [--url] cat /etc/apt/sources.list
SW Repository name hinzufügen zypper addrepo path name     vi /etc/apt/sources.list (händisch eintragen)
SW Repository name entfernen zypper removerepo name vi /etc/apt/sources.list (händisch austragen)
Das SW Paket demo installieren zypper install demo apt-get install demo
Das SW Paket demo deinstallieren zypper remove demo apt-get remove demo
Komplette SW updaten zypper update apt-get upgrade
Inhalte der SW Repositories erneuern zypper refresh apt-get update
Nach dem SW Paket demo suchen zypper search demo apt-cache search demo

Beim Vergleich der zwei Paketmanagementsysteme gewinnt zypp.
Es liegt nicht nur am größeren Befehlssatz – bei apt muß man teilweise mangels Befehle direkt in den Konfigurationsdateien editieren – es ist auch die vorbildliche tabellarische Ausgabe die sich positiv von apt absetzt.