Category: macOS

macOS ⊆ UNIX

Lange Übergangszeiten bei Unicode und 64bit

Probleme mit falschen Umlauten oder Sonderzeichen sind auf der Tagesordnung. Prinzipiell müsste das nicht sein, aber fehlerhafte Programmierung und fehlende Erkennungsmerkmale führen zu hohen Fehlerquoten.

Hintergrund ist dass auf allen gängigen UNIX Systemen UTF-8 als Standardkodierung sowohl für den Inhalt von Klartextdateien als auch für die Kodierung von Dateinamen (siehe auch Form C/D Unterschied) verwendet wird.

Bei Windows wird in unseren Breitengraden standardmässig Latin-1 verwendet (exakt: Windows CP-1252). Dies führt zu Problemen beim Dateiautausch, wenn kein Transformationsmechnismus (bspw. bei Mac OS X wenn Windows Shares via SMB kontaktiert werden) eine Anpassung vornimmt.

Angesichts zigfacher Austauschmöglichkeit (email,USB-Stick,WebDAV,scp..) wird es meines Erachtens noch bis zu 10 Jahre dauern bis dieses Problem nicht mehr auftritt.

Die zweite Sache die m.E. noch bis zu 5 Jahre problematisch sein kann sind 64bit Plattformen. Unter Linux Standard, da der Distributionsinstaller auf allen x64 Plattformen vorschlägt die 64bit Variante zu installieren. Das hat aber zur Folge, dass 3rd party Desktop Programme die nur als 32bit Version oftmals nicht installierbar sind, da die 32bit Bibliotheken fehlen. Auch beim selber kompilieren mit automake&friends gibt es hin und wieder Probleme, wenn man an zig Stellen redundant einen 32bit Flag setzen muss.

Unter Mac OS X wird das Problem mit Fat-binaries erschlagen die einfach immer alles mitbringen. Application+Libraries in 32/64bit ev. noch als Universal Binary.

Einfach für den User aber mittlerweile extrem Resourcenintensiv. Auf einem Apple Laptop mit ca. 100GB HD kann man davon ausgehen, dass Ruck-Zuck 50GB nur für die installieren Programme und das Betriebssystem draufgeht.

Der einfachste Ansatz zukünftig wäre alles nur noch 64bit – dass dauert aber noch und bringt derzeit auch noch Nachteile mit sich (64bit Pointer Overhead).

GarageBand 08

Mit der neuen Version iLife08, die jedem Mac beiliegt, ist auch GarageBand auf Version 08 (von 4) erhöht worden. Im Gegensatz zum Update von Version 2 auf 3 gibt es diesmal Neuheiten für Musiker die sehr nützlich sind. Sie werden auf einer iLife Apple Website kurz dargestellt.

Ich habe 4 davon getestet:

  • Multitracking

Funktioniert ganz einfach – einfach die Aufnahmezeit mit dem gelben Loop-Balken einstellen und auf Record gehen. Nach jedem Durchlauf fängt er wieder von vorne an, ohne den letzten zu löschen. Wenn man die Aufnahme beendet kann man aus einen der Varianten wählen.

Genial, aber mit kleinen Kinderkrankheiten. Falls die Aufnahmespur (geloopter Bereich) nur ein wenig in einen nachfolgenden Bereich ragt, auch wenn der an dieser Stelle noch keine Audio/MIDI Informationen hat, wieder dieser nach einem dubiosen Algorithmus verlegt. Falls man diese Verlegung korrigiert, stürzt GarageBand hin- und wieder ab. Also lieber gleich sauber arbeiten

  • Automatisierte Spuren
GarageBand Automation Bisher konnte man für jede Spur nur die Lautstärke und das Panorama automatisieren (Aufklappknopf Spurinformationen) – jetzt kann man alles automatisieren was der Soundgenerator hergibt.Im Bildschirmfoto werden bspw. die Parameter des Hybrid Basic Generators von GarageBand zur Automatisierung angeboten.Im Falle eines Native Instruments Synthesizers werden bis zu 1000 Controller ID’s angeboten, die im Synthesizer Plugin jeweils einem Reglerelement zugewiesen sind.
Das ganze funktioniert übrigens tadellos.
  • Arrangements

Auch ein nettes Feature. Man kann in einem zusätzlichen oberen Balkenbereich, sog. Arrangements definieren, bspw „Intro“ oder „Refrain“. Diese Zonen kann man dann mit üblichen Methoden zur Bearbeitung verwenden. Beim Kopieren bspw. werden alle Spuren die sich in dieser Zone (Arrangement) befinden mitkopiert.

  • Visual EQ / Frequenzanalyse

GarageBand Visual EQ

Auch dieses Feature bringt GarageBand in höhere Regionen. Der Visual EQ steht jedem Instrument zur Verfügung und kann dort eingestellt werden, wo man auch sonst üblicherweise die AudioUnits einstellt.

In diesem Equalizer kann man in vier Frequenzregionen die Amplituenveränderung einstellen. Das ganze geht elegant mit der Maus.

Der Clou ist die Just-In-Time Veränderung der Frequenzanteile der gerade ausgewählten Spur (hellgraue Linie).

Damit kann man doch recht schnell einen ausgewogenen Frequenzverlauf oder eben auch nicht – wenn anders gewollt – hinbekommen.

Bei den AudioUnits sind mir 2 Änderungen aufgefallen, auch wenn diese eher von Mac OS X anstatt von GarageBand selber bereitgestellt werden.

Beim AUMatrix Reverb ist im unteren Bereiche ein Frequenzfilter hinzugekommen.

Audio Unit: Matrix Reverb

Daneben ist AUPitch zur Veränderung der Tonhöhe dazugekommen.

Audio Unit: Pitch

Alles in allem ein sehr gelungenes Update. Von minimalen Kinderkrankheiten und dem üblichen Übersetzungschaos abgesehen ist es ein größerer Schritt nach vorne.

umask 0002

Ich bin ein großer Fan dieser umask, den Sie ermöglicht in Zusammenarbeit mit dem sgid-bit eine fast beliebige Rechtevergabe im POSIX-Netzwerk ohne ACL’s einsetzen zu müssen.

Egal ob man private Gruppen oder sonstige vertrauenswürdige Gruppen erschafft – ein Datenaustausch auf einer lokalen Workstation oder im NFS-Netzwerk ist zu 95% konfigurierbar.

Während man auf fast allen UNIX Plattformen eine globale umask 0002 in /etc/profile einträgt, muss man auf Mac OS X eine XML-basierende Property Datei ändern, und zwar mit

defaults write /Library/Preferences/.GlobalPreferences NSUmask 2

Hinweise:

  • Bei allen nicht-root Usern muß natürlich sudo vorangestellt werden
  • Der letzte Pfadteil (.GlobalPreferences) wird ohne den Suffix .plist angegeben.
  • Nach NSUmask kommt der typische Oktalwerk des Rechtesystems

bash Einstellungen

Im Prinzip sollte es ja nicht schwer sein mit den Voreinstellungen der Shells:

/etc/profile beherbergt die systemweiten Shell Voreinstellungen

~/.profile dagegen die lokalen

~/.bash_profile oder ~/.bash_login beinhalten die lokalen Einstellungen nur für eine bash login-shell
~/.bashrc dagegen die lokalen Einstellungen für eine allg. bash-shell (nicht-login).

Das schwierige ist, dass Solaris bspw. keine globale bashrc kennt, SuSE Linux aber schon, dort heisst Sie aber /etc/bash.bashrc(.local) – bei RedHat Linux wiederum /etc/bashrc
Oftmals werden diese zusätzlichen Dateien auch nur eingelesen, weil Sie andere Dateien (bspw. die lokalen Dateien) inkludieren.

Hat man die Notwendigkeit Skripte portabel zu schreiben, sollte man nur mit den zuerst genannten Arbeiten. Dazu hat man ja die Möglichkeit eine lokale .bashrc Datei im Skeleton Ordner für neue Homeverzeichnisse zu erstellen.

ZFS

ja das fehlt noch – ein stabiles und modernes Filesystem das alle UNIX Varianten beherschen.

Und ich hoffe es wird ZFS sein (Zettabyte File System) – wieder aus dem Hause Sun, die schon den Vorläufer UFS (UNIX File System) herausbrachten, welcher theoretisch (aber nicht praktisch, da durch viele Varianten verwässert) auf allen UNIXen laufen sollte.

Bedeutung hat ein einheitliches FileSystem v.a. für Wechseldatenträger.

Unter Linux wird es nur noch eine Frage der Zeit sein – Fortschritte gab es durch Google’s Summer of Code 2006. Im Frühjahr 2006 gab es auch Gerüchte dass Mac OS X, zukünftig auf ZFS setzt. Bisher hat man nichts mehr gehört – aber es sollen ja noch einige Features der nächsten Release Leopard geheim sein…

Hier wird einem der Mund wässrig gemacht:

http://unixconsult.org/zfs_vs_lvm.html

Dateinamen in UTF-8

Auf UNIX Filesystemen werden die Dateinamen schon seit längerer Zeit mit der Zeichenkodierung UTF-8 gespeichert. Da auch NFS seit langem UTF-8 unterstützt könnte man meinen, man sei im UNIX-Paradies des heterogenen Dateiaustausches.

Leider nicht, denn einer macht’s immer anders. Mac OS X hat sich für eine spezielle Variante entschieden, bekannt unter Form D

Form D kennt kein „precomposing“ – ein zusammengesetzes Zeichen, bpsw. deutsche Umlaute, wird getrennt als Buchstabe und die darüberliegenden Pünktchen kodiert. Dieses Vorgehen hat Vorteile bei der Suche.

Der Nachteil ist dass alle anderen, Linux – Windows – kommerzielle UNIX’es – W3C das „precomposing“, bekannt als Form C verwenden. Dort wird ein Umlaut als ein Zeichen (mit 2 Bytes) kodiert.

Lediglich die Zeichen des ASCII Codecs sind immer gleich. Falls man Dateinamen mit Zeichen ausserhalb des ASCII Bereiches verwendet, wird man Probleme bekommen. Tatsache ist:

Form C Dateinamen aus der Linux/UNIX Welt kann der Finder in Mac OS X darstellen, aber einige Programme aus dem Hause Apple nicht öffnen (bspw. iPhoto)

Form D Dateinamen aus der Mac OS X Welt können zumindest unter Linux problemlos verarbeitet werden. Zudem stellen konsole/xterm die Dateinamen einwandfrei dar – konqueror sieht man das decomposing an – María wird mit einem i-Punkt und einem Akzent dargestellt – das ist verkraftbar…

Hier ist Linux flexibler und muss als Klügerer nachgeben – mit folgendem Befehl werden alle Dateinamen in den home Verzeichnisse von Form C auf Form D konvertiert.

convmv -r -f utf8 -t utf8 –nfd –notest /home