macOS Big Sur: Verwirrung um Versionsnummer, Virtualisierungs-Framework in Beta 3 vorhanden

Der Wechsel von Mac OS 9 auf Mac OS X (gemeint ist 10) war ein gigantischer Generationenwechsel – passé war das kooperative Multitasking und der fehlende Speicherschutz. Mac OS 9 und MacOS X hatten so gut wie keine Gemeinsamkeiten: Der gesamte Unterbau war vollständig anders, die Oberfläche nahm sich nur Anleihen bei MacOS 9 und die präferierten Programmierschnittstellen waren vollständig anders. Seit Erscheinen von MacOS X inkrementiert Apple nur die zweite Stelle der Versionsnummer bei größeren Updates – die erste Stelle blieb seit Erscheinen von MacOS X vor fast 20 Jahren unverändert. Zuletzt kam macOS 10.15 Catalina auf den Markt.


Mit macOS Big Sur wird Apple dies ändern: Offiziell hört macOS Big Sur auf die Versionsnummer 11.0. Bei den anderen Plattformen erhöht Apple schon seit Beginn die erste Komponente der Versionsnummer bei größeren Aktualisierungen – macOS war hier ein Sonderfall. Seit macOS 11 Big Sur wurde in Foren hitzig diskutiert, ob die neue Benutzeroberfläche und die ARM-Kompatibilität tatsächlich einen solchen Versionssprung rechtfertigen – doch nun ist zumindest eine konsistente Versionierung der Apple-Systeme gegeben.

Gleichzeitig macOS 10.16 und macOS 11
Aus der technischen Perspektive ist es leider nicht so einfach: Manchmal müssen Entwickler bestimmte Verhaltensweisen von Apps von der macOS-Versionsnummer abhängig machen – und seit Erscheinen von Mac OS X ist die erste Versionskomponente stets konstant. Daher sparten es sich sehr viele Entwickler, die erste Komponente der Versionsnummer bei Mac-Apps überhaupt zu testen. Dies hatte zur Konsequenz, dass die Versionsnummer von macOS 11.0 bei einem solchen Test kleiner als macOS 10.15 ist – mit manchmal fatalen Konsequenzen.

Daher traf Apple die Entscheidung, dass sich macOS 11 erst als 11.0 zu erkennen gibt, wenn die App mit Xcode 12 und dem Software-Development-Kit von Big Sur kompiliert wurde – ansonsten "outet" sich macOS 11 als macOS 10.16, um kompatibel zu sein.

Weiteres Problem: Shell-Skripte
Auch Shell-Skripte für das Terminal haben ähnliche Probleme – doch anders als bei Apps ist es bei Shell-Skripten meist nicht bekannt, für welche macOS-Version diese erstellt wurden. Hier gibt sich macOS Big Sur stets als Version 11.0 zu erkennen – außer, wenn die Umgebungsvariabel "SYSTEM_VERSION_COMPAT=1" gesetzt ist. Dann liefert macOS Big Sur als Versionsnummer 10.16 zurück.


Virtualisierungs-Framework in Big Sur Beta 3 hinzugefügt
Die dritten Entwickler-Vorabversion von Big Sur, welche Apple vor knapp einer Woche herausbrachte, bringt nun das auf der WWDC 2020 angekündigte Virtualisierungsframework mit. Dies eignet sich zur Virtualisierung von Linux-basierenden Betriebssystemen auf Apple-Silicon-Macs wie auch auf Intel-Macs. Apple spricht in der Dokumentation nur von Linux-artigen Systemen – und das Framework scheint momentan auch nur hierauf ausgerichtet zu sein. Bezüglich einer möglichen Virtualisierung von Windows für ARM schweigt sich Apple weiterhin komplett aus.

Anders als das mit OS X 10.10 Yosemite eingeführte "Hypervisor Framework" setzt das "Virtualization Framework" an einer viel höheren Stelle an und nimmt Entwicklern viel Arbeit bei der Umsetzung von Virtualisierungslösungen ab. Das "Virtualization Framework" steht in Objective-C bzw. Swift zur Verwendung bereit – das "Hypervisor Framework" bietet nur eine C-Schnittstelle.

Kommentare

misc27.07.20 09:10
Kompatibilitätshacks, wie man sie sonst nur von Microsoft kennt...
-1
deus-ex27.07.20 09:15
Entwickler die nur die .X Versionsnummer abfragen sind bestimmt die gleichen die nur zweistellige Jahreszahlen verwendeten, selbst dann als es aus Speichergründen nicht mehr notwendig war.
+9
DTP
DTP27.07.20 09:29
deus-ex
Entwickler die nur die .X Versionsnummer abfragen
Apples Versionsnummer ist ja eben keine Dezimalzahl, die Verwirrung hat Apple ja schon mit 10.10 geliefert:
Denn das 10.9<10.16 (="kleiner als") ist, dreht Mathematiker*innen den Magen um.

Also muss man eh den Nach"komma"-Teil abtrennen und abfragen.
+1
Walter Plinge
Walter Plinge27.07.20 09:31
Apples Lösung ist ein guter Kompromiss für die _Nutzer_ alter Anwendungen.

Allerdings sollten Entwickler, die so schlecht programmieren, dass sie nur die Minor-Version testen sich ehrlich fragen, womit sie eigentlich ihr Geld verdienen.
+3
Walter Plinge
Walter Plinge27.07.20 09:33
DTP
Denn das 10.9<10.16 (="kleiner als") ist, dreht Mathematiker*innen den Magen um.

Also muss man eh den Nach"komma"-Teil abtrennen und abfragen.
Da der "Nachkomma"-Anteil eine völlig andere Bedeutung hat, als der "Vorkomma"-Anteil verbietet sich ein Vergleich der genannten Art ohnehin. Genauso gut könnte man sich beschweren, dass 10km > 100l. Das hat einfach keinen Sinn!
+5
DTP
DTP27.07.20 09:39
Walter Plinge
Da der "Nachkomma"-Anteil eine völlig andere Bedeutung hat, als der "Vorkomma"-Anteil verbietet sich ein Vergleich der genannten Art ohnehin.
Heutzutage selbstredend. Und hinterher ist man immer schlauer

Dass das so ist, ist den meisten erst seit macOS 10.10 klar. Selbst gestandene Installerlibraries wie InstallerWise und andere fielen damals aus allen Dezimalwolken. Ich erinnere mich noch, dass viele Installationen (was man ja damals machte) auf 10.10 zurückmeldeten, dass für die Installation mindestens 10.7 vorausgesetzt wird.
+1
Walter Plinge
Walter Plinge27.07.20 09:56
DTP
Dass das so ist, ist den meisten erst seit macOS 10.10 klar. Selbst gestandene Installerlibraries wie InstallerWise und andere fielen damals aus allen Dezimalwolken. Ich erinnere mich noch, dass viele Installationen (was man ja damals machte) auf 10.10 zurückmeldeten, dass für die Installation mindestens 10.7 vorausgesetzt wird.

Das war damals schon Mist und das damals ein paar Libs dieses Problem hatten zeigt nur, dass die Entwickler nicht darüber nachgedacht hatten, was sie dort eigentlich vergleichen (was bei float-Zahlen ohnehin sehr gefährlich ist).

Als Gegenbeispiel könnte ich hier einige andere Libs und Apps anbringen, die dieses Problem nicht hatten, weil sie eben von vornherein korrekt Major und Minor-Versionen unterschieden (und daher gar nicht erst mit Float-Zahlen hantierten, was sowieso immer eine gute Idee ist). Das hat in diesem Fall mal nichts mit "hinterher ist man schlauer" zu tun. Versionsnummern gibt es schließlich nicht erst seit 10 Jahren, und das Jahr 2000 Problem hat anschaulich vor Augen geführt, was passiert, wenn man in zu wenig Information zuviel hinein zu interpretieren versucht. Zudem lassen sich Abfragen wie die von Versionsnummern heutzutage leicht und einfach kapseln und ein für alle mal korrekt implementieren, da gibt es keine Entschuldigung.
+2
gegy
gegy27.07.20 10:02
Jedes mal wenn ich code schreibe und unter Zeitdruck stehe, reiße ich mich zusammen und sage mir: „Nein, ich werd es hier nicht einfach machen, denn das fällt mir irgendwann auf den Kopf“
Genau so passiert es nun allen Entwicklern, die es sich beim Prüfen der Versionsnummer einfach gemacht haben.
+4
Colonel Panic
Colonel Panic27.07.20 10:08
DTP
Denn das 10.9<10.16 (="kleiner als") ist, dreht Mathematiker*innen den Magen um.

Wie Walter Plinge schon richtig bemerkt hat, besteht der Fehler darin, die Versionsnummer als Dezimalzahl zu interpretieren. Die Versionsnummer ist ein 3-Tupel aus natürlichen Zahlen, und die Notation sieht vor, diese mit einem Punkt getrennt hinzuschreiben. Den Vergleichsoperator von Dezimalzahlen auf Versionsnummern anzuwenden ist schlicht ein Bug.
+7
DTP
DTP27.07.20 10:31
Genau, hinterher ist man immer schlauer

In den 1980ern und auch noch bis Mitte der 1990er waren Dezimalversionen üblich, üblich war die Versionsnummer 1.51 (und nicht 1.5.1). Apple war mWn eine der Ausnahmen.
Semantische Versionsnummern (also xx.xx.xx) haben sich erst in den 2000ern durchgesetzt.

Und Knust (falls der euch ein Begriff ist) nahm sogar eine reine Dezimalzahl, die sich langsam an Pi (3,141592654…) nähert. http://www.texfaq.org/FAQ-TeXfuture
0
Walter Plinge
Walter Plinge27.07.20 10:50
DTP
In den 1980ern und auch noch bis Mitte der 1990er waren Dezimalversionen üblich, üblich war die Versionsnummer 1.51 (und nicht 1.5.1). Apple war mWn eine der Ausnahmen.
Semantische Versionsnummern (also xx.xx.xx) haben sich erst in den 2000ern durchgesetzt.

In dem Fall gab es aber ziemlich viele Ausnahmen. Schon MS-DOS hatte keine rein dezimalen Versionsnummern. Selbst bei Linux - das von Torvalds ja 1991 begonnen wurde - hatte die Versionsnummer faktisch von Anfang an semantische Bedeutung.

Bei vielen Anwendungen der 80er und 90 fiel es nur deshalb nicht ins Gewicht, weil diese entweder nie Bugfix-Revisionen herausbrachten (war in den 80ern/frühen 90er eher unüblich, schon wegen der Verteilungsproblematik), oder aber nie über eine Minor-Revision 9 hinauskaumen (gleiches Problem, es gab einfach eher Major-Releases).

Nein, Versionsnummern waren auch in den 80ern bereits üblicherweise semantisch. Damals gab es nur einfach deutlich weniger Versionen! Die Ausnahme war hier eher die Versionierung des _Mathematikers_ Knuth.
+1
MikeMuc27.07.20 13:52
Ob sich damit das Versionsschema an IOS anpaßt werden wir erst nächstes Jahr erfahren. Erstmal könnte man mit OS 11 sagen, das damit der Wechsel auf "Apple Silicon" angedeutet wird. Nicht mehr und nicht weniger. Erst wenn nächstes Jahr MacOS 12 kommt, dann veranstalten sie dort den gleichen Versionswettlauf wie bei IOS.
0
ERNIE27.07.20 14:10
Es ist schon seit SEHR vielen Jahren üblich in der Versionsbezeichnung mit Punkt getrennte Ganzzahlen zu verwenden.
Auch, wenn Apple dies WOMÖGLICH vorangetrieben hat, sind sie nicht die "Erfinder" davon.

Tatsächlich finde ich den weiter o.g. Vergleich mit der zweistelligen Jahreszahl gar nich so weit hergeholt.

Ich sehe dieses - vermutlich eher selten auftretende - Problem jedoch ganz nüchtern als lösbar an.
0
subjore27.07.20 14:11
Aber was genau hätten denn die Entwickler bei der Versionsnummer genau prüfen sollen?
If vorpunkt>=10 und nachpunkt >=11 do ...?
Das vor dem Punkt war doch immer 10.
0
ERNIE27.07.20 14:17
subjore
Aber was genau hätten denn die Entwickler bei der Versionsnummer genau prüfen sollen?
If vorpunkt>=10 und nachpunkt >=11 do ...?
Das vor dem Punkt war doch immer 10.

Warum nicht?
Und vor 10.x war es ja auch mal 9.x und davor 8.x...
ganz besonders bei 8 machte es in mancherlei Hinsicht auch einen Unterschied, ob es 8.1 oder 8.6 war.
0
martzell27.07.20 16:34
Ich konnte meinen HP Drucker nicht weiter nutzen und habe ihn verschenkt. Weil die Installationssoftware ab Mac OS 10.10 fälschlich meckerte mindestens 10.7 sei Voraussetzung. Workaround wäre gewesen ein Mac OS kleiner 10.10 zu installieren, Treiber zu installieren und Mac OS zu aktualisieren, da auf meinem alten MacBook die HP Treiber Software, auch unter Mac OS 10.10 noch einwandfrei funktionierte. HP wollte auf meinen Hinweis hin sich des Problems nur mit dem Installer nicht annehmen.
0
martzell27.07.20 16:47
Bei den Mac OS Versionsnummern handelt es sich um 3 einzelne Ganzzahlen (engl. integer):
typedef struct {
    NSInteger majorVersion;
    NSInteger minorVersion;
    NSInteger patchVersion;
} NSOperatingSystemVersion;

Seit Mac OS 10.10 bietet das Betriebssystem dafür sogar eine Prüfmethode für Prorgammierer. Davor wird es allerdings komplizierter.
- (BOOL)isOperatingSystemAtLeastVersion:(NSOperatingSystemVers ion)version
0
marcel15127.07.20 19:24
DTP
Und Knust (falls der euch ein Begriff ist) nahm sogar eine reine Dezimalzahl, die sich langsam an Pi (3,141592654…) nähert. http://www.texfaq.org/FAQ-TeXfuture
Knust kenne ich tatsächlich nicht. Den TeX-Urheber Donald E. Knuth, den Du mit Sicherheit gemeint hast, dagegen schon.
0

Kommentieren

Sie müssen sich einloggen, um die News kommentieren zu können.