macOS ⊆ UNIX
Die kontinuierliche Verbesserung der Qt IDE Creator bringt nun in der aktuellen Version 2.2 ein wirklich sehr nützliches Feature bzgl. Teamfähigkeit – Die Editoreinstellungen können projektweise vorgenommen werden.
Hört sich unspektakulär an, bringt Creator aber in komplexen Setups wesentlich besser ins Spiel und ist mir zumindest ein Blogeintrag wert 🙂
Die 10. Suchaktion nach den .icc files auf meinen Rechnern, ist der Anlass diese Zusammenfassung zu schreiben:
Auf Mac OS X werden die .icc’s in folgenden Pfaden abgelegt:
global:
/Library/ColorSync/Profiles/
lokal:
~/Library/ColorSync/Profiles/
ev. existiert unterhalb dieser Verzeichnisse noch ein Display directory.
Auf Linux und Solaris gibt es keine Regel, d.h. der File Hierarchy Standard gibt keine Richtlinie aus – wohl aber haben sich Standardpfade eingebürgert, welche auf der OpenIccDirectoryProposal Webseite ausführlich dargelegt sind. In Kürze sind das:
global:
das Unterverzeichnis /color/icc der Verzeichnisse aus den Systemvariablen
$XDG_DATA_DIRS
$XDG_CONFIG_DIRS
..also normalerweise..
/usr/share/color/icc
/usr/local/share/color/icc
..oder eventuell auch..
/var/lib/color/icc
lokal:
$XDG_DATA_HOME/color/icc
normalerweise: ~/.local/share/color/icc
$XDG_CONFIG_HOME/color/icc
normalerweise: ~/.config/color/icc
auch hier können sicher unterhalb dieser Verzeichnisse Subdirectories, bspw. device befinden.
Wie schon in einem vorangegangenem Artikel erwähnt verwendet Mac OS X leider,leider eine andere Form der UTF-8 Kodierung als der Rest der Welt (Linux,UNIX,Internet,everybody..)
Das Problem ist das Pre-/Postcompositing bei zusammengesetzten Zeichen. Wenn man den Ratschlag des oben verlinkten Artikels beherzigt und es Mac OS X recht machen will und Form D verwendet, stösst man leider auf Probleme mit rsync.
rsync erkennt automatisch die verwendete Encodierung – d.h. auf allen klassischen UNIX Plattformen UTF-8.Kann aber nicht zwischen Form C und D unterscheiden. Das führt dazu, dass bei einem rsync Abgleich von UTF-8 Form D gemässen Dateien auf Linux, Dateinamen mit zusammengesetzen Buchstaben (alle dt. Umlaute) gelöscht und wieder kopiert werden, da rsync diese Dateien als Unterschiedlich erkennt – nicht vom Inhalt, sondern vom Dateinamen.
Man kann zwar mit dem –iconv Flag, den Quell- und Zielzeichensatz bestimmen, aber es gibt eben nur ein UTF-8 – ausser auf Mac OS X, dort gibt es auch UTF8-Mac, was allerdings ein Feature der dortigen iconv Bibliothek ist. Ein rsync von UTF-8 Form D gemässen Dateien funktioniert somit unter Mac OS X um sollte sofern es die Einrichtung (bspw. NFS shares) erlaubt auch verwendet werden.
Leider sieht es nicht so aus, als ob die iconv Verantwortlichen Lust darauf haben den UTF-8 Zeichensatz generell in Form C und D zu trennen. Noch weniger sieht es danach aus, dass Apple auf Form D verzichtet um den 6 Mrd. Menschen auf dem Planeten das Leben leichter zu machen.
Man wird weiterhin immer das kleinste Übel suchen müssen…..
Adobe Reader gibt es auf fast allen Plattformen. Zum Lesen von pdf Dokumenten immer noch erste Wahl, was Features und Darstellungsqualität angeht. Leider lassen sich aber mit dem Reader keine Kommentare hinzufügen, ausser dieses Feature wäre explizit in der .pdf Datei freigeschaltet, was quasi nie vorkommt (muss mit Adobe Acrobat Pro unter bestimmten Bedingungen erzeugt worden sein).
Es gibt aber abseits von Adobe einige Programme, die bei jedem pdf Dokument sog. Annotations (Kommentare) und Text Highlights (Markierungen) vornehmen können – diese können dann von anderen pdf Programmen erkannt und gelesen werden.
Hier eine Auflistung der Programme, die derzeit auf UNIX Plattformen pdf Dateien kommentieren und Markierungen setzen können.
Die Wirkung auf das Auge muss bestehen bleiben…
..das ist das Ziel von Farbmanagement, wenn Farben von einem Farbmodell in das andere (z.B. vom Bildschirm zum Drucker) oder von einem Gerätefarbraum in einen anderen (z.B. von DSLR zu Monitor) überführt werden.
Beim Farbmanagement gibt es 4 Teilaufgaben :
Unter Mac OS X ist ColorSync die Schnittstelle für alle diese 4 Aufgaben. Kalibrierungsprogramme – z.B. Eye-One Match liefern dieser Schnittstelle Daten, wobei Anwenderprogramme wie bspw. Bibble Daten zur Berechnung an diese weitergeben.
Unter Linux existiert leider kein ColorManagement Modul. Punkt 1+2 kann Argyll übernehmen. Punkt 3+4 muss das Anwenderprogramm übernehmen – oder spezialisierte Module wie LCMS von Scribus.
Während unter Mac OS X „installierte“ ICC Profile sofort in die in der Grafikkarte vorhandenen VLUT (Video Lockup Table) installiert werden – muss dies unter Linux mit dem dispwin Kommando manuell geschehen. Diesese legt man derzeit am besten unter:
/etc/X11/xinit/xinitrd.d/
ab. Zu beachten ist, dass mit dem Display Switch „-d“ auch zweite Monitore angesprochen werden können (genauere Hinweise siehe in diesem Artikel). Dies kann oder muss (Intel GMA950 mit LVDS/TMDS Problematik) man bspw. bei Intel Mobile GPU’s, die auch auf Desktops vorkommen, machen. Bei nVIDIA basierten GPU’s geht derzeit kein seperates LUT, was professionelle Multimonitorbildbearbeitung ausschliest. Auch fehlende XRANDR Unterstützung und das löschen des VLUT’s durch nvidia-settings machen sich negativ bemerkbar.
Eine Besonderheit stellen einige professionelle Geräte aus dem Hause EIZO dar. Dieser verfügen über ein Hardware LUT, welches nur durch die mitgelieferte Software ColorNavigator beschrieben werden kann. Dieser liefert zusammen mit dem ICC Profil äussert zuverlässige Ergebnisse – man kann unter Linux hier auch auf das „installieren“ des ICC Profils verzichten.
Abschliessend noch ein kleines selbstgeschriebenes Testprogramm, welches nur ein Bild auf einem wählbaren Monitor ausgiebt. Durch mehrfaches Starten des Programms kann man bei Multimonitorbetrieb die Unterschiede klar sehen.
Das Programm liegt als Mac OS X und Linux Version, sowie im Source Code bereit
Wer auf einem Mac das (mitterweile von Nokia stammende) Qt SDK installiert und in seinem Programm jpeg Support benötigt wird schnell feststellen, dass dieser abhanden kommt, wenn man in seine Applikation Qt-Frameworks einbindet.
QImageWriter::supportedImageFormats() wird .jpg/.jpeg nicht mehr aufzählen.
qconfig.pri welches die Qt Konfiguration beschreibt, listet jpeg Support in QT_CONFIG nicht auf – weder als system-jpeg noch als einkompiliertes Modul. Die Datei befindet sich übrigens (bei Qt 4.5) unter /usr/local/Qt4.5/mkspecs
Die Lösung ist eine plugin Library: libqjpeg.dylib welche sich unter
/Developer/Applications/Qt/plugins/imageformats
befindet. Auch diese Datei muss in das Applikation Bundle mitaufgenommen werden, die Referenz mit install_name_tool geändert werden, und QApplication muss der plugin Pfad mitgeteilt werden.
Eine genaue Anleitungung dazu findet sich in der ausgezeichneten Qt Hilfe unter dem Stichwort:
Deploying an Application on Mac OS X
Die letzte iX veröffentlichte eine Umfrage, welche auf die Benutzung von Linux auf dem Desktop abzielte. Das ernüchternde Ergebnis war, dass sich seit der gleichen Umfrage von 2006 fast nichts veränderte, es wurde sogar ein minimaler Rückgang verzeichnet. Auch andere „Messergebnisse“ oder Prognosen bescheinigen Linux eine Stagnation auf dem Desktop – je nach Land und Methode so zwischen 1 – 3% Marktanteil.
Mac OS X hingegen baut auf dem Desktop seine Stellung weiter aus und kratzt momentan deutschland- und weltweit an der 10% Marke. Kommerzielle Workstation UNIX Varianten, wie Sun Solaris – spielen in diesem Segment keine Rolle mehr. Eher noch dringen Embedded Geräte – mit einem meistens auf Linux basierenden OS – weiter vor.
Die Zukunft von Sun Solaris ist sehr ungewiss. Natürlich spielt es im Enterprise Bereich bei den Hochleistungsservern noch eine grosse Rolle aber Linux rückt auch dort dichter auf die Pelle. Oracle – der neue Besitzer von Sun Microsystems – könnte mit einer eigenen Linuxdistribution die Entwicklungskosten, die Solaris derzeit benötigt, wahrscheinlich deutlich reduzieren. Allerdings würden Sie dann auch die Alleinstellungsmerkmale von Solaris aufgeben – vielleicht bauen Sie deshalb nur die Kompatibilitätsschichten zu Linux weiter aus.
Bei Linux zeichnen sich unterschiedliche Tendenzen ab. Aufgrund der hohen Innovationsgeschwindigkeit und der kurzen Releasezyklen des Kernels wird Linux seine Stellung im SOHO-/Midrange-Server und HPC Bereich weiter ausbauen und zum dominaten Mitspieler in dieser Kategorie aufsteigen.
Im klassischen Desktop Bereich scheint sich aber der Abstand zu Mac OS X und Windows zu vergrössern. Während man sich bei der Linux Foundation noch darum bemüht die Grundlagen des Desktops (Dialoge, etc.) aufgrund mehrerer vorhandener Windowmanager zu vereinheitlichen, ist Mac OS X – aber auch Windows – schon mit sehr mächtigen Frameworks (CoreAudio,CoreGraphics,Windows Presentation Foundation,Windows Communication Foundation) ausgestattet. Diese API’s erlauben Anwendungsprogrammierer sich nur primär auf die Logik Ihrer Applikation zu konzentrieren während man sich unter Linux noch um den ganzen Rest kümmern muss. Natürlich gibt es auch auf dem Linux Desktop diese Ansätze (bspw. GStreamer als Kooperation zwischen Gnome und KDE), diese sind aber noch in der Anfangsphase – nicht immer ausgereift und es gibt v.a. keinen Hinweis darauf wie diese Technologielücke in der nächsten Zeit geschlossen werden sollte.
Damit wird sich Linux als Desktop bei Privatnutzern trotz der Stabilitäts- und Sicherheitsvorteile in der nächsten Zeit nicht durchsetzen können. Anders sieht es in gewissen Enterprise Bereichen aus. Dort wo das Betriebssystem quasi nur als Programmstarter benutzt wird und die überschaubaren Applikationen mit maximaler Stabilität und Performance laufen müssen, ist Linux im Vorteil – sofern die Applikationen die Plattform unterstützen.
Noch besser sieht es im bei Spezialanwendungen oder im Embedded Bereich aus. Dank der flexiblen Konfigurationsmöglichkeiten die Windows und Mac OS X einfach nicht bieten, ist dort Linux mit Abstand die beste Wahl. Da es sich dort auch schon seit einiger Zeit im harten Einsatz bewährt hat, wird sich die Verbreitung von Linux auf solchen Systemen in nächster Zeit beschleunigen.
Der Mac OS X Zug fährt mit konstanter Geschwindigkeit weiter. Nach der 10% Hürde wird es Apple in den nächsten Jahren schaffen 20% des Desktop Marktes für sich zu beanspruchen. Auch wenn einige Entscheidungen aus dem Hause Apple schwer nachzuvollziehen sind (Vernachlässigung der Pro Sparte im Hardware Bereich) bleibt Mac OS X das beste Desktop System unserer Zeit. Die Verschmelzung der klassischen Mac OS GUI’s mit der UNIX Technik von NEXT brachte ein System hervor, welches aus mehreren Welten das Beste vereinte und auf dem Desktop technisch wie ergonomisch das Feld mit grossem Abstand anführt.
Wenn man übergreifend den ganzen IT Kuchen betrachtet, werden die Stücke die auf UNIX Technologie basieren – und damit sind nicht die imkompatibel in Windows hereingewanderten Komponenten gemeint 🙂 – kontinuierlich grösser.
Nicht nur für die Musikproduktion, sondern auch für simple HIFI-Wiedergabe bestens geeignet ist das portable Audio Device duet der kalifornischen Audio Schmiede Apogee.
Alle In- und Outputs (ausser Kopfhörer) laufen über ein Brake-Out Kabel. Die Line Outputs haben -10 dBV und ergeben einen wunderbaren Klang – die D/A Wandler gehören der Oberklasse an.
Zwei hochohmige Instrumenteneingänge sowie 2 symmetrische XLR Eingänge (wahlweise +4dBu für Profi- und -10 dbV für Consumergeräte) mit dazuschaltbarer Phantomspeisung gehören zum Eingangsreportoire.
Der grosse Drehknopf kann entweder Ein- / Ausgangspegel oder die Lautstärke regeln. Daneben kann er aber auch noch mit bis zu 4 MIDI Informationen (MIDI – Drehregler) bestückt werden. Das Umschalten dieser Funktionalität erfolgt durch Drücken des Knopfes.
Das Design aber auch die Bedienung, sowie die beigelegte Mixer Software ist schlicht und einfach genial. Apogee konzentriert sich auf das wesentliche und lässt daher unwesentliche Dinge weg (siehe link).
Lange ist es her als Apple ankündigte, dass ZFS in Mac OS X Einzug halten sollten. Leider ist die Einbindung immer noch recht rudimentär. Nicht besser, eher schlechter, sieht es unter Linux aus. Da die von Sun für ZFS gewählte CDDL Lizenz, nicht kompatibel zur GPL ist, gibt es keine Kernelunterstützung für ZFS in Linux (im Gegensatz zu BSD). Dafür ist das Filesystem im Userland mittels FUSE jetzt angesiedelt.
Auch wenn die Unterstützung noch zu wünschen übrig lässt, sind dennoch die bestehenden Implementierungen stabil genug um einen ernsthaften Test zu wagen, der auch – ums vorweg zu nehmen – erfolgreich war.
Hintergrund ist, dass man unterhalb der verschiedenen UNIX Systeme immer noch kein gemeinsames Filesystem hat mit dem man portable Datenträger versehen könnte. FAT32 ist denkbar ungeignet, da es
Somit kann bspw. rsync Operationen auf solchen Datenträgern vergessen.
ZFS bringt sehr viele neue Ansätze mit, bestechend ist aber dass sich verschiedene ZFS Filesysteme – sog. data sets – auf pools arbeiten die online jederzeit neue Datenträger aufnehmen können. Alle Grenzen sind online beliebig verschiebbar, die klassische Trennung Filesystem-Volume-Datenträger wird also aufgehoben.
Nach diesen warmen einleitenden Worten nun die Vorgehensweise beim erzeugen eines ZFS sets auf einem externen Datenträger – dazu müssen auf Linux die Pakete fuse und zfs-fuse installiert sein.
1. Nach dem Anschließen der Festplatte, meldet sich diese als /dev/sde
2. mit fdisk eine Partitionstabelle auf /dev/sde erstellen
3. zpool create -o version=8 testpool /dev/sde
Hintergrund: Die Spezifikation der ZFS pools wird laufend weiterentwickelt. Dabei wird die Versionsnummer der ZFS pool Beschreibung hochgezählt. Unter Linux werden mit zfs-fuse 0.5 Pools bis zur Version 13 unterstützt. Die letzte ZFS Implementierung unter Mac OS X kann aber nur Version 8. Auf einem solchem System könnte auf kein ZFS pool > Version 8 zugegriffen werden, daher wird unter Linux der Pool explizit mit Version 8 erstellt.
Die unterstützten Versionen können jederzeit mit
zpool upgrade -v
angezeigt werden.
4. Nach der Erstellung des Pools „testpool“ ist dieser sofort als data-set benutzbar, was ok ist – man braucht bei einer externen FP nicht unbedingt ein zweites Dataset (welches mit
zfs create /testpool/subdirectory
angelegt werden könnte).
Der Mountpoint wird ebenfalls sofort ungefragt auf /testpool gelegt, man kann ihn ändern mit
zfs set mountpoint=/mnt/externalZFSdisk testpool
5. Nach solch einer Operation muss man ihn einmal wieder mounten
zfs mount testpool
6. Ein ZFS data set auf einer externen Festplatte wird normalerweise nicht ge- und unmounted sondern im- und exportiert.
zpool export testpool
damit wird implizit auf ungemounted.
7. Auf einem anderem Rechner wird nun die FP angeschlossen:
zpool import
zeigt einem die verfügbaren Pools sofort an (in dem Fall testpool, inkl. den Informationen welcher Datenträger sich dahinter verbirgt)
zpool import testpool
macht ihn dem System zugänglich, indem er das dazugehörige dataset mounted (Unter Mac OS X wird es standardmässig dann unter
/Volumes/testpool
eingehängt.
Danach kann man problemlos darauf zugreifen. Normalerweise sollte nach der Session ein
zpool export testpool
ausreichen – unter Mac OS X – muss man aber trotzdem dass Volume mit den bekannten Methoden vorher auswerfen.
Der Datenaustausch mit allen oben erwähnten Annehmlichkeiten unter den UNIX Systemen steht nichts mehr im Wege.
Noch ein paar Hinweise..
zpool list
listet alle verfügbaren Pools auf, während
zpool status testpool
deren Status (v.a. im Fehlerfall hilfreich) anzeigt.
zpool iostat -v testpool
zeigt die I/O Transaktionen an
zpool add testpool /dev/sdf
würde dem Pool noch einen weiteren Datenträger zuweisen, was in diesem Bsp. keinen Sinn machen würde.
Unter Mac OS X wird mit dem ls Befehl schon angedeutet, dass die POSIX Rechte durch ACL’s erweitert sind. Tatsächlich unterstützt ZFS die neuen NFSv4 ACL’s die unter UNIX defacto ACL Standard darstellen und ziemlich an die Windows NT ACL’s angelehnt sind. Unter Linux werden diese leider noch nicht angezeigt. Sun’s eigene Solaris Umgebung verhält sich hier natürlich vorbildlich.
Full Screen Antialiasing (FSAA) ist ein Feature welches von modernen GPU’s (Graphic Processor Units) angeboten wird. Es wird von OpenGL (auf Windows auch Direct 3D) Applikationen angesprochen.
Im Zuge von Einbrüchen der Frameraten von OpenGL Programmen auf KDE 4.2 Desktops hatte ich mir Antialiasing (AA) mal genauer angeschaut.
Es gibt prinzipiell 3 Möglichkeiten, welches FSAA zum Einsatz kommt.
Auf einer nVIDIA 8600M GT GPU, sind bspw. folgende __GL_FSAA_MODE Werte zulässig:
Names for valid 'FSAA' values: 0 - Off 1 - 2x (2xMS) 5 - 4x (4xMS) 7 - 8x (4xMS, 4xCS) 8 - 16x (4xMS, 12xCS) 9 - 8x (4xSS, 2xMS) 10 - 8x (8xMS) 12 - 16x (8xMS, 8xCS)
Die verschiedenen Techniken von AA sind:
Die Verwendung von AA benötigt aber nicht nur mehr Rechenleistung sondern auch mehr Video Speicher (VRAM), da einfache Pixels nun genauer (x-fach) aufgelöst werden.
Den Effekt sieht man schön bei eine Benchmark der Phoronix-Test-Suite – glmark
Neben dem offensichtlichen Unterschied der Frameraten zwischen dem Benchmark auf IceWM und KDE 4.2 sieht man schön den Performanceabfall, bei höherwertigen AA Einstellungen.
Interessant wird es wenn der gleiche Benchmark auf dem gleichen System mit höherer Auflösung (jetzt: 1680 x 1050 px.) gefahren wird.
Auf einmal bricht die Framerate schon beim Übergang von 2fach Multisampling zu 4MS ab. Ein eindeutiger Hinweis, dass der originäre Videospeicher nicht mehr reichte und der Grafiktreiber auf das herkömmliche RAM ausweichen musste, wass deutliche Latenz ins Spiel brachte.
Der Ausreisser unter KDE 4.2, bei dem die höchste Performance bei bester AA Einstellung suggeriert wird, ist darauf zurückzuführen, dass der KDE Windowmanager (kwin) wegen Überlastung, eine eigene Einstellung von AA wählte und die Einstellung von nvidia-settings überschrieb.
