Die Aufgabe lautet die UTF-8 BOM (0xEFBBBF) mittels eines Hexeditors in ein simples Textfile einzufügen.
Getestet wurden auf Ubuntu 12.04 verschiedene Tools – hier das Ergebnis:

1. hte (Konsolenhexeditor mit ncurses)

Leider ist die Integration von ncurses in die Ubuntu Welt – genauer gesagt in ein Gnome Terminal – nicht prickeld. Wesentliche Kommandos die mit der ALT Taste gesteuert werden wurden anstatt in das ncurses Programm an das darüberliegende Terminal übertragen, so dass ich es nicht schaffen konnte in den Edit Mode zu kommen. Ansonsten ist die grafische Representation des Byte-Codes ansprechend.

2. vi (mittels xxd)

Falls man mit vi -b ein File im binären Modus öffnet, kann man mit folgender Sequenz
:%!xxd
..Manipulation des Files
:%!xxd -r
die Datei ändern. Das Hinzufügen oder Entfernen von Bytes gelang mir auf Anhieb nicht. Mein Fazit: Für schnelle Manipulationen ideal, aber nur dafür.

3. okteta

Der KDE Hexeditor läuft selbstverständlich auch auf dem Ubuntu Unity Desktop. Was die Optionen der grafischen Representation anbelangt das beste Programm. Im Detail offenbaren sich – wie so oft unter KDE Schwächen. Bei der Characterdarstellung der Bytes sollte man sich auf einen rein lokalen 8-Byte Zeichensatz beschränken anstatt dem User vorzugauckeln, dass ein Byte eines Umlautes unter UTF-8 einem Character entspricht (bei der Byte-Sequenz C3B6 ‘ö’ wird schon alleine C3 unter UTF-8 als ‘ö’ dargestellt, zumindest in der Decoding Tabelle). Auch die Layout-Voreinstellungen der GUI sind nicht optimal.

4. bless

Das Mono-basierte Programm hat leider die Systembedingten Abhängigkeiten von allerhand Mono-Libraries.
Ansonsten wirkt das Programm aber sehr aufgeräumt und stringent. Von der Bedienung her das einfachste Programm – allerdings kann es nach der Manipulation nicht auf das geöffnete File zurückschreiben. Wer das versucht, bekommt folgende kryptische Fehlermeldung.
blessSaving

Fazit: Je nach Geschmack eignet sich okteta oder bless am Besten für diese Aufgabe

Comments Keine Kommentare »

Wenn sich ein File auf einem Linux System nicht mal mit Hilfe eines root-accounts löschen lässt, dann sollte man mal die sog. I-node flags (Extended Filesystem Attributes) genauer anschauen. Der Befehl dazu lautet

lsattr <FILE>

Falls in der Ausgabe der Character i vorkommt, dann ist das sog. FS_IMMUTABLE_FL flag gesetzt worden, welches eine Modifikation des i-Nodes gänzlich unterbindet (d.h. weder inhaltliche Veränderung noch eine Änderung von Metadaten ist erlaubt).
Ein Setzen des Flags mit

chattr +i <FILE>

erfordert die CAP_LINUX_IMMUTABLE capability. Programmatisch erfolgt dieselbe Operation mit ioctl

if (ioctl(fd,FS_IOC_GETFLAGS,&attributes)==-1) errExit("fetching attributes");
attributes |= FS_IMMUTABLE_FL;
if (ioctl(fd,FS_IOC_SETFLAGS,&attr) == -1) errExit("setting attributes");

Dieses i-node flag ist unter Linux seit Kernel 2.6.19 Filesystem-übergreifend implementiert. Es kann bspw. zum temporären Schutz von Dateien in Systemverzeichnissen genutzt werden, aber auch von Rootkits die Schadsoftware ins System eingeschleust haben.

Comments Keine Kommentare »

Wer Systeme mit einem hohen Anteil an Software entwirft oder betreut, steht vor großen Herausforderungen das System mit zur Abnahme beim Kunden konsistent (oder im Kosten-, Zeit- und Qualitätsrahmen) zu halten.
Im System Engineering ist ISO 15288 Systems and software engineering – System life cycle processes ein guter Ratgeber. Dort werden in einer Art Baukasten verschiedene Prozesse beschrieben, die man während der Lebenszeit (Life Cycle) auf das zu Zielsystem (System of interest) anwenden kann.
Doch sind diese – allen voran die technischen Prozesse in Kapitel 4 – gut genug wenn die wichtigen Systemelemente (Subsysteme) reine Software (SW) sind?
Theoretisch ja – praktisch vielleicht, es kommt auf das sog. Tailoring an. Es schadet aber nicht, in diesem Fall ISO 12207 Systems and software engineering — Software life cycle processes anzuschauen. Der Titel ist fast der gleiche wie bei ISO 15288 – sie orientiert sich auch stark an diese und gibt dem Leser 2 Möglichkeiten zur Benutzung vor.

  1. Das ganze System ist quasi Software – Man orientiert sich an den IO 15288 Prozessen und adaptiert diese gemäß Kapitel 6 von ISO 12207
  2. Das System besteht nicht nur aus SW – die ISO 15288 bestimmen das System of interest. Wird ein System Element als SW-item identifiziert wird dieses dann mit den Prozessen von Kapitel 7 des ISO 12207 Standards gehandelt. Dort werden 3 neue Prozessgruppen vorgestellt:
    • Software Implementation Processes
    • Software Support Processes
    • Software Resuse Processes

Gerade im 2.Ansatz liegt die Stärke, die überwiegend akzeptierten Vorgehensweisen von ISO 15288 auf die Spezifikas von SW zu übertragen, zumal ISO 12207 sich auch mit der ganzen Sprache eng an ISO 15288 anlehnt.

Comments Keine Kommentare »

Wenn ein Program dass Gleitkommazahlen von einer oder in eine Textdatei liest, bzw. schreibt nicht mehr funktioniert, dann sollte man sich genauer mit LC_NUMERIC befassen. Dieser Artikel behandelt die Auswirkungen auf Qt- und reine C-Programme.

LC_NUMERIC ist Bestandteil der sogenannte locales, der Lokalisierungen (oder auch Regionalisierungen) auf einem System. Diese Lokalisierungen lassen sich sehr fein einstellen – bspw. LC_MONETARY für die Währung oder eben LC_NUMERIC für das Zahlenformat – aber auch zusammenfassend mittels LC_ALL. Setzt man bspw. LC_ALL=de_CH.UTF-8, dann wird diese Einstellung auf alle sublocales übertragen und für LC_MONETARY ist der Franken gesetzt, wenn auch das meiste andere ziemlich deutsch ist.

Ok, nun aber zum Zahlenformat – und um die Sache ein bischen zu beschleunigen, soll eine Textdatei mit folgendem Inhalt ausgelesen werden.

#Hallöle
33.456,78
33456.78
33,456.78
33,99
33.98
33.777

Um die Zahlen besser zu verstehen muss noch einmal ausgeholt werden. LC_NUMERIC legt zwei Parameter fest.
Den Dezimaltrenner und den Tausender-Trenner. Er wird folgendermassen gesetzt:

Locale Dezimaltrenner Tausender-Trenner
en_US . ,
de_DE , .
C .

Das bedeutet, dass die deutsche Lokalisiserung genau andersherum als die US-Amerikanische ist. Die sog. C-Locale (auch POSIX-Locale genannt) kennt nur den Dezimaltrenner. Diese Locale ist als Rückfallebene gedacht.

Wie verhält sich nun ein Qt-Programm (Qt4), dass die o.g. Textdatei zeilenweise einliest und versucht den Text in Zahlen zu konvertieren? Zuerst einmal wird ein Testprogram unter der Umgebung LC_NUMERIC=de_DE.UTF-8 gestartet.

localeTest_de

Die Erklärung ist überrasch komplex. Zuerst einmal muss festgestellt werden, dass Qt Programme generell LC_NUMERIC-aware sind. Dies wird dadurch erreicht, dass QCoreApplication

setlocale(LC_ALL,"");

aufruft und damit locales aus dem Environment dem Programm zur Verfügung gestellt werden (dies wird durch die doppelten Anführungszeichen erreicht). Dennoch werten nicht alle Qt-Methoden LC_NUMERIC aus.

QByteArray::toDouble()
ignoriert die gesetzte locale und benutzt immer die C-Locale.

QString::toDouble()
verhält sich am kompliziertesten. Es wird der Dezimaltrenner der gesetzten locale ausgewertet, nicht aber der Tausender-Trenner (die Gründe liegen in der Kompatibilität zu C, siehe später). Gleichzeitig wird die C-Locale immer als Fallback mitausgewertet. Bei Qt5 verhält sich übrigens QString::toDouble wie QByteArray::toDouble

QLocale::toDouble()
hingegen orientiert sich ausschliesslich an der gesetzten locale.

Zum Vergleich nun die Ausgabe unter dem Environment LC_NUMERIC=en_US.UTF-8

localeTest_en

Interessant ist nun der Vergleich zu reinen C-Programme. Denn reine C-Programme mit ihren typischen Funktionen

printf/fprintf
scanf/fscanf
strtof

..usw. ignorieren standardmässig die gesetzte locale und stützen sich immer auf die C-Locale. Erst durch den schon oben genannten Aufruf von setlocale werden C-Programme locale-aware.
Werden allerdings C-Funktionen – bspw. aus einer Bibliothek – von einem Qt-Programm verwendet, sind sie automatisch locale-aware, da ja wie schon erwähnt QCoreApplication setlocale aufruft.

Dies ist eine große potentielle Fehlerquelle!

Um den Bogen zu QString::toDouble() nochmals zu spannen, sei erwähnt, dass C-Funktionen den Tausender-Trenner standardmässig ignorieren. Um z.B. printf zur Ausgabe des Tausender-Trenners bei Gleitkommazahlen zu zwingen, muss man

printf("Gezwungen zu %'f",myfloat);

einen Abostroph vor dem Formatierungszeichen einführen.
Zum Ausprobieren liegt das Qt Beispielprogramm sowie zwei plain C-Programme im diesem Archiv bei

Comments Keine Kommentare »

Standardprozesse unter Linux werden nun schon seit Kernel 2.6.23 durch den Complete Fair Scheduler verarbeitet, der seinerzeit den O(1) scheduler mit seinen dynamschen Prioritäten beerbte.

In diesem Zusammenhang wurde aber nicht nur der O(1) scheduler durch einen anderen ersetzt. Es wurde vielmehr ein ganzes scheduler Framework erschaffen, bei dem von oben nach unten die scheduler Klassen mit Ihren jeweiligen schedulern abgearbeitet werden. Der simple Ansatz lautet, dass immer versucht wird denjeniegen Prozess zu finden, welcher in der höchstmöglichen Klasse lauffähig (runnable) ist.
Derzeit sieht die scheduler Klassenhierarchie folgendermaßen aus:

  1. stop_sched_class
  2. rt_sched_class
  3. fair_sched_class
  4. idle_sched_class

Die Hintergründe sind im aktualisierten Linux Realtime Dokument zusammengefasst.

Comments Keine Kommentare »

Die Multipurpose Internet Mail Extensions sind entgegen ihrem Namen auch für die Identifizierung eines Dateityps auf Linux Desktops verantwortlich.

Eine gemeinsame Technik der freedesktop Organisation sorgt dafür, dass ein Verfahren dabei auf allen Desktops’ – Gnome,KDE,Unity.. – gleichermassen funktioniert. Die gemeinnützige Organisation kümmert sich dabei vor allem um die Standardisierung und stellt teilweise sogar SW (software) bereit.
Eine Übersicht der MIME-Type Spezifikation findet sich hier, während der Ordner mit den letzten verfügbaren Änderungen sich hier befindet.

Wenn man einen oder mehrere neue MIME-Types (mit dazugehörigem Programm) einführen möchte, geht man am besten folgendermaßen vor:

  1. Man sucht sich einen passenden Ablageordner – die auf dem System vorhandenen sind
    $XDG_DATA_DIRS/mime
    $XDG_HOME_DIR/mime

    falls XDG_HOME_DIR nicht gesetzt ist, gilt
    ~/.local/share/mime
    Natürlich kann man bspw. XDG_DATA_DIRS auch erweitern um einen neuen Pfad einzuführen
  2. Eigene MIME-Type Deklarierungen müssen innerhalb einer standardisierten XML-basierenden Datei im Ordner packages (unterhalb des Ordners mime) gespeichert werden, bspw
    ~/.local/share/mime/packages/myType.xml
    Eine xml Datei kann dabei auch mehrere MIME-Types definieren. Der genaue Vorgang erklärt eine hervorragende Tutorialseite auf freedesktop:
    Tutorial: adding MIME information to the database
  3. Die sog. MIME-Type database muss aktualisiert werden. Dazu gibt es ein Skript welches die ganzen im Punkt 1. erwähnten Verzeichnisse durchscannt und dort jeweils dezentral binär aufgebaute Hilfsdateien anlegt. Das shell script welches natürlich mit Administrationsrechten ausgeführt werden muss, lautet
    update-mime-database
  4. Die Verknüpfung eines MIME-Types mit einem Programm ist nicht Sache der MIME-Type Definition. Stattdessen legen die Programmbeschreibungsdateien, die sog. desktop-Dateien, offen welche MIME-Types sie bearbeiten. Diese Dateien mit der Endungs .desktop, liegen in
    XDG_DATA_DIRS/application
    XDG_HOME_DIR/application

    mit denselben Ergänzungen wie im Punkt 1.
    Die freedesktop Spezifikation findet man auf folgender Seite. Ein anschauliches Beispiel findet sich hier.
  5. Nachdem man die MIME-Types und Anwendungen die bestimmte MIME-Types bearbeiten können festgelegt hat bleibt noch folgende Frage zu klären: Welche Anwendung ist die bevorzugte Anwendung eines MIME-Types, bspw. image/png ?
    Dort hat jeder Desktop (bspw. KDE) seine Voreinstellungen in der generierten mime.cache Datei (siehe Punkt 3. – Hilfsdateien) getroffen. Diese Entscheidungen können aber ergänzt oder geändert werden.
    Dazu muss man die Datei
    mimeapps.list
    unterhalb von
    XDG_DATA_DIRS/application
    XDG_HOME_DIR/application

    ändern. Wie genau erklärt die Spezifikation auf freedesktop an dieser Stelle.
    Neben der Angabe einer bevorzugten Anwendung für einen MIME-Type in der Sektion
    [Default Associations]
    gibt es auch noch die Möglichkeit zusätzliche Assoziationen zu kreieren oder zu vorhandene zu löschen.

  6. Am Ende bleibt noch die Frage wie man an diese MIME-Type Informationen gelangt? Sicher, haben die grossen Desktops Routinen dafür entwickelt die den Spezifikationen von freedesktop genügen, aber wie kommt man als ISV (Independent Software Vendor) an diese Informationen.
    Vorab – eine API gibt es nicht – unter keiner Sprache. Was es gibt sind Skripte allen voran
    xdg-mime
    des Portland SW Paketes von freedesktop (der SW Part von freedesktop, siehe Einleitung). Unter Ubuntu/Debian gibt es auch noch das Perl-Skript
    mimetype
    mit welchem man wesentlich mehr Informationen abgreifen kann.
    Zu diesem Thema möchte ich noch auf 2 nützliche Links verweisen
    http://wiki.ubuntuusers.de/MIME-Typ
    http://aksubuntu.com/questions/279899

Abschliessend lässt sich sagen, dass die MIME-Type Informationen unter Linux ausgereift und ausreichend ist. Was verbesserungsbedürftig ist, und leider gerade dahindarbt, ist die SW-Unterstützung, v.a. eine C/C++ API seitens freedesktop.org wäre wünschenswert. Dies soll aber nicht darüberhinwegtäuschen, dass die Zusammenarbeit der Linux Desktops gut funktioniert.

Comments Keine Kommentare »

Eine Überraschung erlebte ich beim Bauen einfacher Demonstrationsprogramme unter Ubuntu 12.04. Folgende Anweisung:

gcc -lpthread -o pthread_demo pthread_demo.c

erzeugte beim Linkvorgang mehrere unresolved symbols bzgl. pthread Methoden. Tatsächlich wurde aber mit gleicher Anweisung das Programm zu den Anfangszeiten von Ubuntu 12.04 gebaut. Eine Umstellung des Linker Programms ld bzw. der Aufruf desjeniegen durch gcc dürfte daran schuld sein. In ld Version 2.20 führt der Linker-Flag

--as-needed

dazu, dass Bibliotheken nur noch gelinkt werden wenn diese undefined Symbols im Objekt File oder einer zuvor gelinkten Bibliothek auflösen kann. Daher muß von nun an das Objekt File vor den benötigten Bibliotheken im gcc Aufruf stehen.

gcc -o pthread_demo pthread_demo.c -lpthread

Alternativ könnte man das alte Verhalten mit folgendem Linker-Flag wiederherstellen

gcc -Wl,--no-as-needed -lpthread -o pthread_demo pthread_demo.c

Comments Keine Kommentare »

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.

Comments Keine Kommentare »

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!

Comments Keine Kommentare »

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…

Comments Keine Kommentare »