Snow Leopard: Die Entwicklerversion privat

[crossinger]

War bislang der große Vorteil eines Apples nicht der, dass man auch auf ein paar Jahre alter Hardware das neueste OS laufen lassen konnte und somit der Lebenszyklus verlängert und damit die Kosten pro Jahr veringert werden?

Jein. Nicht wenige Hersteller haben sich die Anpassungen ihrer Software an Leopard gut bezahlen lassen. Manche haben sogar - offenbar bewusst - Versionssperren eingebaut, so dass man für Leopard zum Kauf eines Upgrades gezwungen war.

Mit solchen Methoden ist der Investitionsschutz auch zum Teufel...

*J*

[Bananenbieger]

Grr... das ist natürlich doof. Aber da kann Apple ja nichts für.

[crossinger]

Aber da kann Apple ja nichts für.

Das stimmt. Ich wollte auch nur darauf hinweisen, dass solche BS-Wechsel auch von den Softwarefirmen gerne zum Anlass genommen werden, um abzukassieren.

Und *dann* stellt sich nämlich die Gretchenfrage: Schön, wenn mein "alter" Rechner auch mit dem neuesten BS von Apple noch kann. Aber wenn meine Programme dann nicht mehr wollen - oder nur gegen Aufpreis, dann bleibt man bis zur Anschaffung der nächsten Hardware bei seinem bestehenden System.

Und genau darauf will ich hinaus: In allen Foren war nach den ersten Infos zum Snow Leopard Katerstimmung - ganz so, als ob der Umstieg auf das neue BS ein Naturgesetz ist, dem jeder Apple-Nutzer zwingend folgen muss. Es ist aber immer noch ein kann. Und niemand wird gezwungen. Was haben die Besitzer von alten G5-Macs von Snow Leopard zu erwarten? Die ".6" nach der 10? Immer das Neueste haben wollen?

Ich schätze mal, dass gerade im beruflichen Umfeld der Switch zu Leopard weitaus schleppender verlief, als bei den Hobbyisten/Consumern. Bis heute hört man ja von Ärger bei Adobes Creative-Suite. Und auch bei der Musik Soft- und Hardware (von der ich mehr Ahnung habe als von Adobe) ist Tiger bis heute die bessere Basis. Ein paar Grafiker in meinem Freundeskreis haben sogar immer noch Panther auf ihrem G5.

So gesehen kann ich das Hecheln nach "Snow Leopard für alle (Architekturen)" nicht so ganz nachvollziehen.

*J*

[Bananenbieger]

Natürlich. Generell hast Du recht. Ich glaube, es wird sogar teilweise noch Panther im professionellen Feld eingesetzt.

Aber andersherum gibt es sicherlich auch Unternehmen (meist kleinere bzw. Freiberufler), die eh ihre Software auf den neuesten Stand halten - aus welchen Gründen auch immer. Dann ist es schon ärgerlich, wenn das neue Programm XY nicht mehr unter Tiger/Leo läuft bzw. man zwar gerne auf SnowLeo und Programm XY aufrüsten will, aber der alte Rechner, aber eigentlich noch ausreichend schnelle Rechner, wird nicht mehr unterstützt.

Das hecheln nach Snow Leopard kann ich in sofern nachvollziehen, als das sich unter der Haube ganz schön viel tun soll. Ich habe leider noch nicht die gesamte Featureliste mir durchgelesen, allerdings habe ich schon einige Buzzwords wie ZFS gehört.

Wenn man bedenkt, dass der Macs von 2003 zur Zeit noch von Leo unterstützt werden (und auch von Apple noch den supported Hardware-Status haben), so denke ich, dass Apple eigentlich im Rahmen eines "Vertrauensschutzes" noch unter Snow Leopard wenigstens noch die Modelle ab 2005 unterstützt werden. Der 2005 PowerMac G5 Dual 2,7GHz ist wie gesagt immer noch eine Höllenmaschine...

Nicht, dass Du mich jetzt falsch verstehst: Ich schreibe gerade von einem iMac C2D mit Tiger

[MacApple]

Die Tatsache, dass zwei unterschiedliche Compiles in einer Datei liegen, sagt ja grundsätzlich noch nichts über die Entwicklung aus. Es ist aber definitiv nicht so, dass man sich einfach vor Xcode setzt, werkelt, und am Ende zwei Ergebnisse kompiliert. Die verschiedenen Probleme, die bedacht werden müssen, erwähnt Apple unter anderem in den Richtlinien zur UB-Entwicklung (Kapitel: Architectural Differences).

Natürlich vereinfacht sich die ein oder andere Sache, aber dass man vollkommen anders entwickelt, wenn man nur noch für eine Architektur entwickelt, ist doch ein wenig übertrieben.

Aber noch ein Gedanke, wobei ich dafür meine Hand nicht ins Feuer legen würde: Cocoa-Applikationen lassen sich doch mit relativ geringem Aufwand fit für 64-Bit machen

Na ja, ganz so einfach ist das nicht. Wenn man das nicht sorgfältig macht, bekommt man nur ein 64Bit wannabe Programm raus.

MacApple

[Bananenbieger]

Da fällt mir gerade ein: Was machen eigentlich die Kollegen von der OpenSource-Fraktion? Die müssen immerhin Programme entwickeln, die unter Linux, BSD, Darwin/OSX und noch einigen anderen Betriebssystemen auf zig 32bit und 64bit Plattformen laufen. Samba läuft ja auch auf einem Intel Mac genau so wie auf einem MIPS R5000

[zeno]

Glückwunsch, der Beitrag hats auf tuaw geschafft

[rcfa]

Ich fände das aber blöd, natürlich sind die letzten PowerMacs noch nicht alt, aber ich denke man sollte sich von der ppc - Altlast lösen.

In Mac OS X gibt's Altlasten, die da heissen:
- 32-bit
- Carbon

Aber mit PPC hat das nix zu tun. Die Compiler für PPC sind fertig. Wenn man also nicht gross in die alte CPU Platform investieren möchte, braucht man diese nur mehr oder weniger belassen wie sie sind, statt weiter zu optimieren. Manche Optimierungen kommen jedoch automatisch, weil man von neueren Compilerversionen profitiert.
Davon abgesehen ist es für Apple wichtig zumindest auf einer big-endian Platform zu laufen, denn das stellt sicher, dass der Code CPU unabhängig bleibt, und sich nicht versteckte Fehler einschleichen.

Wenn Apple G4 und IA-32 wegfallen liesse, dann wäre das sehr sinnvoll. Aber allen PPC code loszuwerden, aber dann an IA-32 festzuhalten, das bringt reichlich wenig, ausser dass man Benutzer durchaus tauglicher Systeme dazu zwingt neue Rechner zu kaufen wenn diese die neuen Funktionen (z.B. Exchange support) von Snow Leopard haben wollen.

Bitte mal nicht vergessen, dass PPC bei weitem immer noch die modernere Platform darstellt als die x86 CPU, zumindest was das Programmiermodell darstellt. Somit kann man da wirklich nicht von Altlasten reden.
Compileroptimierungen sind nicht nur von der CPU Platform, sondern sogar vom CPU Modell abhänging, also wird man für einen Nehalem, Mermon, oder Conroe Chip jeweils anders optimieren müssen, will man wirklich optimalen code. Apple wird sich da wohl auf entweder den meistverkauften oder den schnellsten Prozessor entscheiden, damit sie entweder die besten high-end Benchmarks oder die grösstmögliche Zahl befriedigter Kunden haben.

PPC weglassen bringt höchstens Ersparnisse bei QA, die aber teilweise verloren sind, weil man versteckte Fehler im Code weniger leicht findet (falsche Annahmen bei byte alignment, endian code, etc.)

[rcfa]

Viele Leute glauben Kode sei einfach schneller weil's nun 64-bit sind statt 32.
Das hat etwas, da bei IA-x86-64 im Vergleich zu IA-x86-32 die Zahl der Register grösser ist, was effizienteren Code erlaubt. Das Resultat ist aber 32-bit Code der etwas schneller läuft, weil er auf einer besseren CPU läuft.

Die echten 64-bit Vorteile bedürfen einer völlig anderen Programmierweise. Statt dateibasieren Denkens, wird das Programmiermodell nur noch mit internen Datenstrukturen arbeiten, welche man einmal (memory mapped) einliest wenn das Programm startet, und welche man gelegentlich auf Platte sichert, den Rest überlässt mand dem VM System des OS.

Schon mal versucht Datensätze auf Platte zu sortieren? Und nun mal das ganze im Hauptspeicher?
Ah, leicht anders, gell? Das ist der qualitative Unterschied zwischen einem 32-bit und 64-bit Program.
So lange die Programmierer nicht völlig umdenken und nicht 32-bit Computer bei der Entwicklung aussen vor lassen können, so lange werden wir nicht in den Genuss echter 64-bit Architektur kommen.

Daher ist es viel wichtiger IA-32 loszuwerden als den PPC G5.

[MacMark]

Der "anonyme Entwickler " verstößt damit vermutlich gegen die NDA. Nicht besonders schlauer Zug.