Linux – Seite 5 – instruyete

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!

Ä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.

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.

pdf mit barcodes ausdrucken (gelöst)

Paketscheine von Hermes bspw. enthalten immer einen Barcode.

Leider wird dieser nicht immer korrekt ausgedruckt, sondern teilweise punktiert – also völlig unbrauchbar – ausgedruckt.
Zuerst hatte ich CUPS, bzw. die Treiber/Filter im Verdacht. Tatsächlich scheint es aber an den Programmen zu liegen.

Korrekt ist der Ausdruck eigentlich nur in folgenden Kombinationen:

Überhaupt nicht – unabhängig von der Einstellung Farbe/SW – funktioniert es mit:

Warum das so ist? Ich weiß es zumindest derzeit nicht.
=> Jetzt weiß ich es! Siehe Kommentar #1

truecrypt mount ext2 reparieren

Was tun wenn eine ext2-formatierte truecrypt Partition repariert werden muss? Praktisch kann das schnell der Fall sein, wenn z.B. das Filesystem nicht mehr sauber ist und mittels Ext2FS für Mac OS X (Paragon) eingehängt wird.

Dann muß unter Linux e2fsck (fsck.ext2) ran, bspw.

e2fsck -a /dev/mapper/truecrypt1

D.h. der Befehl wird nicht auf die Partition selber, sonder auf den dm-Container ausgeführt. Das bereinigen der Partition funktioniert aber nur zuverlässig, wenn beim truecrypt mount unter „Optionen“ die Checkbox „Do not mount“ angehackt ist, d.h. der eigentliche Inhalt des dm-Containers wird unter keinem Mountpoint (normalerweise /media/truecrypt1) angelegt, trotz aktiviertem dm-Container.

CalDAV Synchronisationsprobleme (mit davical)

Mir ist es jetzt schon zweimal passiert, dass die Clients untereinander die Synchronisation entweder komplett eingestellt haben oder nur noch teilweise Kalendereinträge anzeigten. Was war passiert?

Beim ersten Fall hatte ich in Mozilla Lightning einen Kalendereintrag mit einer speziellen (customized) Wiederholungsregel angelegt (letzter Mittwoch im Monat). Das schmeckt dem iOS Kalender (egal ob Version 4.x oder 5.x) gar nicht – genauso wenig wie dem Programm iCal (3.x) unter Mac OS X (Snow Leopard). In diesem Fall blieb mir nichts anderes übrig als auf diese Wiederholungsregel zu verzichten.
Darauf gekommen bin ich relativ schnell, da ich einfach die letzten Einträge die ich vorgenommen habe sukzessiv zurückgenommen habe.

Der zweite Fall war etwas schwieriger. Am Sonntag erzeugte ich noch munter Einträge (3 Wochen im Voraus) in Mozilla Lightning, alles ok. Beim Blick auf den iOS Kalender fiel mir nichts auf – ich hatte aber eh nur die momentane Woche in Beobachtung.
Das Problem bemerkte ich später wiederum an Lightning, der jetzt einige Einträge gar nicht mehr anzeigte – auch der laufenden Woche. Ausserdem waren die Einträge die ich am Sonntag vornahm, weg (die übrigens im iOS Kalender gar nicht auftauchten).
Was war den hier passiert? Eine Beobachtung des Apache Log ergab, dass sehr wohl alle Kalenderänderungen mit
"PUT /davical/caldav.php/<myCalender>/<current-ID.ics> HTTP/1.1 ..."
immer noch übertragen werden. Einträge löschen wurde übrigens noch sauber synchronisiert. Eine erstmalige Synchro auf einem Mac OS X Rechner mit iCal schlug fehl, nichts wurde übertragen.
Die Lösung brachte eine erstmalige Synchro mit dem KDE Kontact Kalender – der holte alle (auch die verschwundenen) Einträge hervor und zeigte sie an. Und in einem, der am Sonntag angelegten Einträge, befand sich im Beschreibungstext ein Sonderzeichen (falsche Kodierung), welches mit Copy/Paste von einem Webartikel reinkopiert wurde. Nachdem ich das Zeichen entfernte, klappte die Synchro anstandslos auf allen Clients. Daher kann ich nur empfehlen keine Texte aus einer Quelle zu kopieren, bei der die Zeichensatzkodierung nicht mit dem des Kalender-Clients übereinstimmt. Gerade auf Webseiten ist die Kodierung oft sehr unterschiedlich.
Die fast noch wichtigere Erkenntnis ist, dass schnelles Fehlertracking nicht mit einer SW Monokultur zu schaffen ist. Je heterogener die SW Landschaft (Clients) ist, desto robuster läuft der Netzwerkdienst.

Ubuntu 12.04 LTS vs. openSUSE

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.

PDFStudio7 als Standardprogramm für .pdf’s unter Linux (Ubuntu 12.04)

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