macOS ⊆ UNIX
Dieser Artikel im heise newsticker spricht mir aus der Seele. An Apple einen Bugreport zu schicken, ist vergeudete Zeit. Selbst wichtige Probleme wie services oder gar sicherheitsrelevante Fehler werden lange ignoriert.
Da bleiben dann Feature Regressions wie das seit mehreren Releases kaputte CardDAV gleich ganz liegen. Der Bug Report 16938876 wird dann spätestens mit Abwicklung der Firma Apple geschlossen.
Beim Kopieren von Mediendateien vom NAS zu einer microSDXC Karte für den Einsatz auf dem Mobiltelefon, gab es wieder exakt das gleiche Problem, wie ich schon vor über 8 Jahren auf folgendem Blogpost geschrieben hatte:
Was mir aber bis vor kurzem nicht klar war, ist die Tatsache, dass die Normalisierungsprobleme auch auf einem Dateisystem mit UTF-16 Dateinamenkodierung auftritt.
Die microSDXC Karte ist nämlich mit dem moderneren Windows Dateisystem exFAT formatiert, das wiederum UTF-16 für die Kodierung von Filenamen benutzt. Daher auch hier der dringende Rat:
Eine Synchronisierung der Dateien von einem macOS Betriebssystem ist nicht empfehlenswert, schon gar nicht in heterogenen Umgebungen.
lsblk -no name,fstypeWenn mal wieder das MacBook zur Apple Reparatur muss – Butterfly Tastatur lässt grüßen – dann gibt man es einfach im Apple Store ab und zwar gleich mit dem Passwort eines admin Users!
Warum?
Weil Apple gerne ein Hilfprogramm installieren möchte und dazu einen admin Account benötigt!
Warum nicht per Startmedium?
Keine Antwort! Apple braucht den admin-account!
Noch übler ist es, dass sein einigen Jahren das macOS Verschlüsselungssytem FileVault2 nicht mehr per User, sondern die ganze Partition verschlüsselt. Daher nützt es nichts, einen dummy admin-account anzulegen, mit der Intention, dass dieser nicht an die verschlüsselten Dateien der anderen (ebenfalls admin user) herankommt.
Der einzige Workaround ist, alle user-bezogenen Daten zu löschen und mittels TimeMachine von einem externen Medium (Server) später wieder herzustellen.
Again: Apple Sucks!
Auch am Beispiel CardDAV sieht man, dass der Lifecycle von vielen Produkten – auch Software – eher zu- als abnimmt. Die mittlerweile erreichte Komplexität lässt schnelle Lebenszyklen eher nicht mehr zu, schon gar nicht, wenn es sich um kollaborative Werkzeuge handelt die nur auf einem Standard basieren und dementsprechend mannigfaltig implementiert werden.
Heute wird der aktuelle CardDAV Stand anhand von 3 Tools beleuchtet, die einige Überraschungen bieten.
Seit meinem Umstieg von iOS auf Android bei den mobilen Plattformen suchte ich dort nach einer guten CalDAV/CardDAV Implementation, da es auf Android (und übrigens auch nicht auf Samsung Adaptionen) keine Referenzimplementation gibt.
Fündig – und mittlerweile auch glücklich – wurde ich mit DavDroid von Bitfire , das nur eine DAV Datenschnittstelle bereitstellt, die beliebige Kalender oder Kontakttools bedient.
Mittlerweile glücklich, da das Tool anfänglich bei mir auch nicht fehlerfrei arbeitete. Die Synchronisierung hing sich teilweise auf, was aber schon lange her ist. Zudem wurde ein Feature eingebaut, welches die Synchronisation auf ein bestimmtes Netzwerk (WLAN SSID) beschränkt. Dann gab es lange einen Fehler mit doppelten Einträgen, was allerdings spätestens mit Version 1.9.1 gelöst wurde. Der derzeitige Stand ist 1.10 und in all den Versionen seit 1.0 floßen eine Menge Bugfixes und Verbesserungen in akzeptabler Zeit ein.
Auf den Linux Plattformen kommt benötigt Thunderbird ein Plugin für CardDAV – was bisher der sog. SOGO-Connector darstellte. Prinzipiell funktionierte er ordentlich, konnte aber während einer laufenden Thunderbird Instanz nicht resynchronisieren. Außerdem ist in dieser Konstellation auch das native Thunderbird Adressbuch, welches durch den Connector beliefert wird nicht ideal, da es mit dem CardDAV Standard RFC6352 nicht unbedingt harmoniert.
Glücklicherweise kommt mit dem CardBook Plugin für Thunderbird eine tolle neue Alternative ins Spiel, die parallel zum nativen Adressbuch ein zweites Adressbuch – voll auf CardDAV Basis – anbietet. Dieses Plugin lässt kaum Wünsche offen und läuft sehr stabil…
..so stabil, dass nun Thunderbird mit dem CardBook Plugin auch auf macOS zum bevorzugten Setup wird, denn das Apple-eigene Adressbuch (Contacts) ist schlechter als je zuvor.
Apple hat es tatsächlich geschafft die CardDAV Funktionalität seines Adressbuchs völlig zu ruinieren. Es ist seit Version 10.10 nicht mehr möglich mehr als ein Adressbuch von einem Server abzurufen. Desweiteren ist die eigenen Benennung fehlerhaft implementiert und die Synchronisation bricht immer wieder ab ohne einen konkreten Fehler zu bennenen. Das hinterlässt ein unvollständiges Adressbuch mit fehlenden Einträgen – an eine Synchronisation in Serverrichtung ist daher gar nicht mehr zu denken, zumal obendrein das Programm seit 10.12 auch gerne mal abstürzt.
Wer dennoch einen Blick in das schwarze Loch werfen will, dem sei folgende Links als Einstieg angeraten (es gibt viel viel mehr davon):
Fazit: Es geht – wenn auch langsam – voran. CardDAV hat sich zu einer festen Größe entwickelt, die man auch abseits von Google oder anderen Cloud-Anbietern benutzen kann.
Zwei Schritte vor – einen zurück. Das beschreibt ungefähr die NFS Unterstützung in macOS.
mit der abermals hier beschriebenen Option:
nfs.client.mount.options = nfc
erzwingt man auf macOS Ebene die Kodierung der Dateinamen als UTF-8 Form C zu interpretieren (machen alle außer Apple so).
Prinzipiell funktioniert das auch, aber der Teufel steckt wie immer im Apfel.
1. Öffnet man eine Form-C relevante Datei, bpsw. mit German-Umlaut „Angebot Sonderwünsche.pdf“ so kann man die Datei auf dem NFS Share auf einem macOS Sierra Client mit Preview öffnen.
2. Leider legt dann Apple Preview (auf deutsch: Vorschau genannt) ein verstecktes File an, in diesem Fall wäre dann eine Datei names „._Angebot Sonderwünsche.pdf“.
3. Sobald diese Datei existiert, kann das eigentliche pdf nicht mehr geöffnet werden, selbst mit Adobe Reader lässt sich die Datei nicht mehr öffnen, obwohl dieser das hidden File gar nicht angelegt hätte.
Die Fehlermeldung selber trägt auch nicht zur Aufklärung bei.
Leider scheint es unter macOS Sierra auch keine Möglichkeit zu geben, das Anlegen solcher Files auf NFS (oder allg. Network Shares) zu verhindern. Apple ist via Bugreport 32837974 informiert – ob’s was bringt?
Die Firma Apple ist schlicht und einfach arrogant. Objektiver kann man es nicht ausdrücken.
Jede paar Monate werden Schnittstellen, GUIs und Konfigurationseinstellungen geändert. Alles ohne direkten Nutzen für den Benutzer. Es passt halt ins Konzept der Apple Sekte und wer nicht mindestens die Hälfte seiner privaten Zeit für die phantastischen Neuigkeiten des Apple Universums investiert ist deren nicht würdig.
Eines von unzähligen Beispielen ist der Support für das NFS Protokoll. Damit NFS Client-seitig auf macOS Sierra überhaupt nutzbar ist, müssen Mount Optionen gesetzt werden, was früher mit der GUI NFS mounts in der Applikation Disk Utility möglich war.
Da Apple sein OS allerdings alle paar Monate komplett umkrempelt um in der Design Abteilung keine Langeweile aufkommen zu lassen, gibt es diese Funktionalität nicht mehr. Auf GUI Ebene wählt man nun die GUI Mit Server verbinden in der Applikation Finder an. Ganz easy, ohne lästige Optionen und damit…
…ohne brauchbare Funktionalität. Denn schon seit Jahren ist bekannt, dass Verzeichnisse und Dateien eines NFS mounts im Finder nur dann performant angezeigt werden, wenn die Mount-Option locallocks gesetzt ist.
Um dies auf macOS Sierra zu erreichen, empfielt sich folgendes Vorgehen:
1. in /etc/auto_master den Eintrag /net in der 3.Spalte mit der Option nolocks zu versehen, bspw.
/net -hosts -nosuid,nolocks,locallocks
ACHTUNG: Die Optionen hidefromfinder und nobrowse dürfen nicht gesetzt sein.
2. in /etc/autofs.conf den Eintrag AUTOMOUNTD_MNTOPTS ebenso mit den Optionen nolocks,locallocks versehen.
3. Im Finder erscheint dann unter dem linksseitigen Hostnamen nun auch der Folder net, der allerdings bis dato leer sein dürfte.
4. Dann muss man im Terminal den NFS Share explizit einmal anwählen, bspw. mit
cd /net/
5. Danach erscheint der NFS Share auch im Finder unter net. Diese Gelegenheit benützt man um den Folder auf die linksseitige Favoritenleiste zu legen.
Und das war’s dann….noch nicht ganz. Um die Kompatibilität zu einem Linux-basierendem NFS Server zu gewährleisten (siehe hier und hier) sollte weiterhin Clientseitig auf macOS die mount_nfs Option nfc gesetzt sein, zusammen mit intr um eine Abbruchsignal bei hängendem NFS Server wirksam werden zu lassen, die Datei /etc/nfs.conf würde also folgendermaßen aussehen:
#
# nfs.conf: the NFS configuration file
#
nfs.client.mount.options = intr,nfc
Falls man sich im laufenden Betrieb nicht mehr sicher ist, welche NFS Mount Optionen eigentlich gesetzt sind, befragt man den Client am besten mit
nfsstat -m
Dann sollte dem NFS Client Glück nichts mehr im Wege stehen, oder etwa doch…?
Nachdem ich nun KODI als Multimediacenter auf einem Mac OS X Betriebssystem dauerhaft etablieren möchte, befasse ich mich nun zwangsläufig öfters mit dieser SW.
Was mich schon recht schnell störte, war bspw. das beim Abspielen von Musik die untere Info-Leiste, die u.a. Cover-Art zeigt, recht schnell verschwindet – unabhängig von der Einstellung
Optionen -> Einstellungen -> Darstellungen -> Bildschirmschoner
Die recht einfache Lösung ist beim Abspielen von Musik die Taste „i“ zu drücken, siehe auch:
http://www.kodinerds.net/index.php/Thread/6870-Jetzt-gespielt-Ansicht-automatisch-einblenden/?pageNo=1
Bei Verwendung der Major-Version 16 empfiehlt es sich dringend auf die Minor-Version 16.1 upzudaten, da 16.0 ein Fehler bei der JSON/RPC Abfrage hat.
Vielleicht für viele Fotofreunde ein alter Hut – ich entdeckte allerdings erst gestern, dass man mit der gphoto2 Applikation unter Linux (auch Mac OS X) einige Daten der digitalen Spiegelreflexkamera auslesen kann, an die man anderweitig nicht so einfach (sprich ohne spezialisierte Tools) herankommt.
Der Befehl
gphoto2 --list-config
lisstet für die angeschlossene (und aktivierte) Kamera alle auslesbaren Optionen an (in einer Art Filestruktur-Nomenklatur). Hier sind 2 Beispiele um die Anzahl der Auslösungen, bzw. die Geräteversion auszulesen
gphoto2 --get-config /main/status/shuttercounter
gphoto2 --get-config /main/status/deviceversion
Seit MS-Office 2007 SP2 unterstützt MS-Office die Open-Document Formate (OASIS) der freien Office-Welt. Allerdings gilt diese Aussage nicht pauschal. Ausgerechnet die einzige MS-Office Version auf einer UNIX Plattform (MS-Office 2011 für Mac OS X) hat bis heute, trotz einiger Patches (z.B. HDPI/Retina Support) keine Unterstützung für diese Dateiformate – weder lesend noch schreibend.
Ein Armutszeugnis und ganz sicher nicht im Sinne der europäischen Forderungen nach Unterstützung der offenen Dateiformate. Ein weiteres Armutszeugnis daher auch für die europäischen Organisationen – allen voran der EU Kommision – die nichts gegen diesen Zustand unternehmen.
GRUB2 reicht mittlerweile aus, wenn man ein neues MacBook Pro entweder mit standardmässig vorhandenen Mac OS X oder mit Linux booten möchte. Die Hilfe von rEFIt oder dessen Nachfolger benötigt man nicht mehr.
Sehr ansprechend ist der Bootmodus von GRUB2 allerdings nicht – speziell auf einem High-DPI MacBook Pro erscheint die textuelle Auswahl winzig.
Daher entschied ich mich eine – möglichst einfache – grafische Konfiguration zu erstellen. Eine perfekte Quelle um damit anzufangen sind die GRUB2 Seiten auf dem Wiki Ubuntuusers.
Gestartet wird mit einem Thema – ich nenne es mal dualboot – und dem Anlegen eines gleichnamigen Verzeichnis in
/boot/grub/themes/dualboot
Maßgeben dort ist das grafische Layout – bei dem übrigens die Einträge nur vertikal angeordnet werden können. Ohne weitere Erklärung sieht dieses File folgendermaßen aus:
# thema dualbook
# speziell für die mobile workstation myHost entworfen
# Basis war das Thema "ubuntuusers.de"
# globale Einstellungen:
# ----------------------
# Notwendig um den Standardtext zu deaktivieren
title-text: "welcome on myHost - mobile workstation"
title-font: "Ubuntu Regular 72"
# Notwendig für Standardschrift im Terminal
terminal-font: "Unknown Regular 16"
# Hintergrundbild
desktop-color:"#9ba9bf"
# Beginn Komponentenliste:
#-------------------------
+ boot_menu{
# Position des ersten Menüeintrags
top = 400
left = 800
height = 1200
width = 1000
# Schrift der Menüeinträge
selected_item_color = "black"
item_color = "#888888"
item_font = "Ubuntu Regular 40"
selected_item_font = "Ubuntu Regular 40"
item_height = 314
item_width = 800
item_spacing = 20
icon_height = 314
icon_width = 265
item_icon_space = 40
}
Die benötigten Schriften (hier Ubuntu Regular), muss man pro Größe einzeln als .pf2 Datei mittels dem Kommando grub-mkfont erzeugen.
Die Icons müssen im ordern dualboot/icons abgelegt werden. Ich habe hier jeweils ein transparentes Icon für Linux und für Mac OS X mit der vertikalen Größe von 314px abgelegt. Der Dateiname (ohne Suffix) entspricht dabei dem class Namen des sog. menuentry in der Datei /boot/grub/grub.cfg welche allerdings generiert wird.
Daher muss bspw. die Datei /etc/grub.d/40_custom folgendermaßen angepasst werden:
menuentry "Mac OS X" --class MacOS {
exit
}
In /boot/grub/themes/dualboot/icons/ liegt die Datei MacOS.png
Zuletzt muss die globale GRUB2 Konfigurationsdatei noch angewiesen werden, dieses Thema auch zu benutzen, daher gibt es in der Datei /etc/default/grub folgende Einträge:
GRUB_GFXMODE=2560x1600
GRUB_THEME=/boot/grub/themes/acrux/theme.txt
Zudem habe ich noch die sinnlosen auto-detection Einträge von GRUB2 für Mac OS X (32- und 64-bit) entfernt:
# prevent GRUB internal Mac entries
GRUB_DISABLE_OS_PROBER=true
Mit diesen Anpassungen erscheint der Bootmanager grafisch ansprechend auf dem Niveau von rEFIt, welches jahrelang zuvor den Standard gesetzt hat.