macOS 10.15.6 enthält kritische Fehlerkorrektur für bootfähige Backups - Apple ließ sich zwei Monate Zeit

22. Juli 2020 12:30 Uhr - Redaktion

Das in der letzten Woche veröffentlichte Betriebssystemupdate macOS 10.15.6 enthält mehr Änderungen als von Apple dokumentiert: Ein Bug-Fix betrifft bootfähige Backups. macOS 10.15.5 führte einen schwerwiegenden Fehler ein, der das Anlegen von startfähigen 1:1-Kopien beeinträchtigte. Programme wie Carbon Copy Cloner oder SuperDuper mussten aufwendig umgearbeitet werden. Nun gibt es gute Nachrichten.

Apple hat das Problem mit macOS 10.15.6 behoben, wie die Entwickler von Carbon Copy Cloner und SuperDuper bestätigten. Das Anlegen von bootfähigen Backups kann nun wieder wie gewohnt erfolgen. Im Fall von Carbon Copy Cloner wurde mit dem neuesten Update auf die Version 5.1.20 der zwischenzeitlich erforderliche Workaround wieder entfernt.

Für diesen kritischen Bug-Fix ließ sich Apple zwei Monate Zeit. Es bleibt angesichts der langen Liste von schwerwiegenden, zum Teil wiederkehrenden Bugs in macOS Catalina (Datenverluste in Apple Mail und Schlüsselbund, Kernel-Panics nach Ruhezustand, Abstürze bei RAID-Datentransfers, ImageCaptureCore-Bug müllt Laufwerke zu, USB-Probleme, eGPU-Bootproblemee am Mac mini und und und) schlichtweg unverständlich, weshalb der Hersteller nicht schneller reagiert.

Ist es von einem Weltkonzern wie Apple, der Premium-Preise berechnet, zu viel verlangt, kurzfristig entdeckte Probleme mit gravierenden Auswirkungen auch kurzfristig mit Notfall-Patches zu beheben?

 
macOS Catalina
 
macOS Catalina: Apple-Qualitätskontrolle hat mehrfach versagt.
Bild: Apple.

 

Das seit Jahren unveränderte Update-Modell ist angesichts der zunehmenden Komplexität der Betriebssysteme schlichtweg nicht mehr zeitgemäß - mitsamt der offenbar immer schlampiger werdenden Qualitätskontrolle. Wie sonst ist es zu erklären, dass bei Aktualisierungen immer häufiger schwerwiegende Probleme oder Sicherheitslücken durchrutschen bzw. nicht schon im Vorfeld aufgespürt werden? Das betrifft auch iOS und iPadOS.

Schon jetzt blickt man mit Sorge auf den Herbst zur Markteinführung von macOS Big Sur. Noch ist es viel zu früh, Aussagen zur Qualität treffen zu können, doch wir halten schon jetzt an unserer traditionellen Empfehlung fest: Produktivsysteme sollten nicht vor dem nächsten Jahr mit der neuen Systemversion in Kontakt kommen. Zu groß ist leider inzwischen die Gefahr, dass bei einem neuen Apple-OS etwas nicht funktioniert. Die Risiken lassen sich deutlich reduzieren, indem mit einer Umstellung bis zum dritten oder vierten großen Update gewartet wird. Der potentielle Ärger ist ein zu frühes Upgrade einfach nicht (mehr) wert.

Kommentare

Bei BigSur ändert sich ja das Zusammenspiel der Systemerweiterungen, IMHO laufen KEXTs dann nicht mehr, sondern müssen auf die neuen Frameworks migriert werden (siehe auch die Meldung zu Little Snitch 5.0 vor ein paar Tagen). Damit werden wahrscheinlich erst einmal viele VPN Verbindungen nicht mehr gehen, da hier die Clients üblicherweise eigene Clients mit eigenen Kernel Extensions nutzen (z.B. Fortinet, Cisco AnyConnect).

Auch wird externe Hardware, die spezielle Treiber benötigt, wahrscheinlich nicht sofort laufen...

 

Es ist richtig, dass Apple schrittweise die Unterstützung für Kernel-Extensions (.kext) beendet und viele Entwickler bereits für macOS Big Sur enorme Anstrengungen unternehmen müssen, um weiterhin kompatibel zu sein. Wir haben dieses Thema vor einigen Wochen näher beleuchtet:

• Firewall-Software Little Snitch: Version 5.0 für macOS Big Sur in der Entwicklung

• Virtualisierung: VMware kündigt neue Version von Fusion mit Unterstützung für macOS Big Sur an

Wie bereits bei Catalina (Aus für 32-Bit-Unterstützung) steht also auch bei Big Sur (bestimmte .kext werden nicht mehr unterstützt) eine gravierende Änderung an, die eine (erneute) Upgrade-Warnung für Arbeitsgeräte rechtfertigt, weil die Gefahr sehr groß ist, dass nach der Installation plötzlich bestimmte Peripherie oder Software nicht mehr (richtig) funktioniert bzw. kostenpflichtige Upgrades erforderlich sind. Das Tempo, in dem Apple das gesamte System umbaut, wird immer schneller, und die Frage muss berechtigt sein, ob dieses Tempo angemessen ist.

Mit freundlichen Grüßen

@Redaktion: Prinzipiell stimme ich zu, wenn man die Gegenfrage ebenfalls zulässt: Ist es berechtigt, dass sich Anwendungshersteller auf steinalten Frameworks, veralteten Treibern und schlecht gewarteter Software ausruhen, die sie für teures Geld weiterhin als aktuelle Produkte vertreiben?

Wenn eine Software eine Kernel-Extension benötigt, dann muss der Hersteller mit der Kernel-Entwicklung zwingend Schritt halten und Schritt halten können, ohne Wenn und Aber. Der nötige Aufwand muss im Projekt berücksichtigt sein. Das ist man seinen Kunden schuldig.
Ansonsten muss man Alternativen finden; es gibt Profi-Hersteller im Audiobereich, die das hinkriegen.

Der Wegfall der 32-Bit-Unterstützung war nicht nur weit im Vorfeld angekündigt, er war eine für jeden offensichtliche Entwicklung, der im Unix/Linux-Umfeld keine Scheuklappen trug. Davon wurde niemand überrascht. Bis auf diejenigen, die, vermutlich aus Gründen der Profitmaximierung, die nötigen Anpassungen auf den Rücken ihrer Kunden ausgesessen haben.

Man kann sich trefflich darüber streiten, ab wann und in welchem Tempo alte Zöpfe abgeschnitten gehören. Aber das Gejammer von Herstellern, dass sie von der Umstellung auf 64 Bit beispielsweise "überrascht" worden seien, ist extrem unglaubwürdig bis vollkommen lächerlich.

Ich hege durchaus Verständnis für das Spannungsfeld zwischen innovativem OS-Hersteller und eher konservativer Produktpflege, aber das Beharrungsvermögen mancher Anwendungshersteller grenzt schon an absichtliche Blockade bzw. bewusste Sabotage von Neuerungen. Ob das angemessen ist, muss man daher auch fragen dürfen; die Wahrheit - oder der optimale Weg - liegt vermutlich wieder einmal irgendwo in der Mitte.

Wir haben im Herbst 2019 mit deutlichen Worten kritisiert, dass es ein Unding ist, dass einige Hersteller auch nach 10+ Jahren die 64-Bit-Unterstützung nicht auf die Reihe bekommen haben. Trotzdem haben wir uns bei Catalina für eine Upgrade-Warnung - die wir in dieser Form noch nie herausgegeben hatten - entschieden, weil sich de facto viele User des Umstands nicht bewusst waren, dass 32-Bit-Software nicht mehr läuft (oder diesen Fakt zwischenzeitlich wieder vergessen haben - es ist eine schnelllebige Welt). Dabei haben wir primär an unsere Leserschaft gedacht. Ein weiterer Grund war das im Herbst 2019 stark problembehaftete Notarisierungs-Verfahren, das einige Entwickler zur Weißglut trieb.

Die Modernisierung von macOS ist grundsätzlich zu begrüßen, allerdings werden erstens die Vorlaufzeiten immer kürzer (wie jetzt bei .kext; betrifft aber auch andere APIs) und zweitens wird bei diesem Vorhaben seitens Apple immer mehr geschlampt (unfertige Features bzw. schlecht implementiert oder viele Bugs, weil wieder mal zu wenig Zeit für QA blieb). Spannungsfeld trifft es hier ganz gut: Einerseits über die notwendigen Entwicklungen berichten, andererseits aber auch vor vorschnellen Systemaktualisierungen warnen.

Das soll nicht gleich als Generalkritik verstanden werden. Fakt ist aber, dass auf den jährlichen Feature-Seiten zu neuen macOS-Release nie das erwähnt wird, was wegfällt. Und worauf kommt es denn bei der tagtäglichen Arbeit an? Auf ein funktionierendes System. Und hier kann ein vorschnelles Upgrade leider Workflows zerstören und unnötige Kosten auslösen. Daher verstehen wir es einfach als unseren Job, auf die Bremse zu treten, auch wenn wir uns damit (wieder mal) unbeliebt machen. 👹

Das soll es aber jetzt von unserer Seite erstmal zu diesem Thema gewesen sein. Wir werden über die weiteren Entwicklungen in den nächsten Wochen und Monaten berichten.

D'accord, in allem. Ich möchte das auch nicht als Kritik an der Redaktion oder der Berichterstattung verstanden wissen, so war es nicht gemeint! Es ging nur um den Gegenpol zu dem Tempo, das Apple vorlegt, dass auf der anderen Seite eben auch gern ausgesessen und blockiert wird.

Die Upgrade-Warnungen und immer wieder erfolgenden Hinweise auf mögliche nachfolgende Probleme sind gut und sehr berechtigt. Es ist leicht zu übersehen, welche Folgen derart tiefgreifende Änderungen haben können, und am Ende des Tages möchte jeder ein noch funktionsfähiges System besitzen. Selbst eine Warnung zu viel ist deutlich besser als eine zu wenig.

Die Qualitätsmängel der jüngeren Änderungen und Updates bei Apples sind offenkundig, die fehlende Vollständigkeit der Changelogs (wenn es denn überhaupt welche gibt) ein ständiges Ärgernis. Insofern wird interessant, wie gut der Wechsel der Prozessorarchitektur gestemmt werden und inwieweit er weitere Probleme mit internen Abläufen nach außen hin zeigen wird.

Zumindest ich habe das auf die Bremse treten hier deshalb nicht als ein sich unbeliebt machen aufgefasst. Es ist damit wie mit Sicherheitswarnungen: Niemand schätzt sie besonders, aber sie sind notwendig, und im Grunde genommen ist man doch dankbar dafür, denn wie sähe die Alternative aus? Deshalb: Danke schön für ihre Arbeit, und bitte so weitermachen! 😃

Einfach mal verschiedenen Entwicklern auf Twitter/Blogs folgen oder Developer Foren lesen. Dann seht ihr, was abgeht (viel Wut, weil ständig um Apple-Bugs herumprogrammiert werden muss und es keine gescheite Doku gibt). Catalina läuft zwar inzwischen relativ solide (bei mir), aber es war wirklich ein aufreibendes Jahr.

Und ja, es ist wirklich so: Wer im Studio oder der Agentur oder dem Büro Macs stehen hat, einfach nur damit arbeitet und sich nicht groß über neue Entwicklungen informiert, kann sich beim unbedachten Klick auf "Upgrade" wirklich Ärger einhandeln.

Aber es ist, wie es ist. Es gibt den 1 Jahres Rhythmus, der wird auch bleiben, und man kann nur hoffen, dass Apple mehr Personal und Zeit für Tests und Fixes aufwendet.