Mac Mini mit ARM

[Bananenbieger]

Beim PowerPC-Wechsel hat Apple bspw. die APIs beerdigt, die ein paar Jahre früher den Umstieg von MacOS 9 auf OSX einfacher machen wollten.

Beim Wechsel auf ARM wird wohl Bootcamp dran glauben müssen. Das liegt dann allerdings weniger an Apple als vielmehr daran, dass Microsoft keine individuellen ARM-Windows-Lizenzen verkauft. Und Microsoft bekommt das mit der Softwareversorgung für Windows unter ARM nicht vernünftig hin (oder ich sag es mal anders: Microsoft macht tolle Arbeit, aber nur solange es um x86-Systeme geht).

Hab heute morgen von Apple die Zusage bekommen, dass wir ein ARM DTK bekommen. Bin mal gespannt.

 

[ottomane]

Hab heute morgen von Apple die Zusage bekommen, dass wir ein ARM DTK bekommen. Bin mal gespannt.

Ich wäre gespannt auf die Benchmark-Ergebnisse. Leider darfst du keinen machen bzw. die Ergebnisse nicht publizieren.

 

[Mitglied 87291]

Beim Wechsel auf ARM wird wohl Bootcamp dran glauben müssen.

Ist keine Theorie mehr, ist schon längst bestätigt.

Das liegt dann allerdings weniger an Apple als vielmehr daran, dass Microsoft keine individuellen ARM-Windows-Lizenzen verkauft.

Das Lizenzmodell mag dagegen sprechen, genauso aber Apples neue Secure-Boot System was nur von Apple signierter Software den Start erlaubt. Damit ist btw. nicht nur Windows raus sondern auch jegliche Möglichkeit Linux nativ zu installieren.

Und Microsoft bekommt das mit der Softwareversorgung für Windows unter ARM nicht vernünftig hin (oder ich sag es mal anders: Microsoft macht tolle Arbeit, aber nur solange es um x86-Systeme geht).

Haben ja momentan auch keinen Anreiz dazu. Es gibt noch keinerlei ARM Hardware oder ARM Marktanteil, welcher das rechtfertigen würde.
Aber immerhin wollen sie für Apple eine ARM-Office Variante bauen. Bin mal gespannt wie viel die kann.

Hab heute morgen von Apple die Zusage bekommen, dass wir ein ARM DTK bekommen. Bin mal gespannt.

Stark Leider sind die Dinge welche mich wirklich interessieren allesamt verboten worden...

 

[Bananenbieger]

Ich wäre gespannt auf die Benchmark-Ergebnisse. Leider darfst du keinen machen bzw. die Ergebnisse nicht publizieren.

Die Ergebnisse wären doch eh nicht aussagekräftig. Im DTK steckt ein iPad-Chip Ein Mac mini bekommt den Strom aus der Steckdose und daher wird man da problemlos auch mehr Power unterbringen können. Bei den Notebooks sieht es dann wieder anders aus. Meine persönliche Einschätzung: Apple wird sicher ein ultraflaches, ultraportables MacBook herausbringen, welches aber nur auf dem Leistungsniveau eines iPad Pros liegt. Das liegt einfach auf der Hand, weil Apple eine Vorliebe für möglichst kompakte und leichte Notebooks hat. Am anderen Ende der Produktpalette wird sich dann zeigen, was Apple macht. Ich gehe da von einem 2x8 Core-ARM plus dedizierter AMD GPU aus.

Ist keine Theorie mehr, ist schon längst bestätigt.

Richtig. Aber noch ist nicht aller Tage Abend. Windows 10 für ARM passt doch genau zum technischen Konzept von Apple. Sollte Apple und Microsoft darin einen Sinn sehen, auch Windows 10 auf ARM-Macs anzubieten, dann wird Apple sicher eine Windows 10 Version signieren und bereitstellen.
Aber ich halte das ebenfalls für recht unwahrscheinlich.

genauso aber Apples neue Secure-Boot System was nur von Apple signierter Software den Start erlaubt. Damit ist btw. nicht nur Windows raus sondern auch jegliche Möglichkeit Linux nativ zu installieren.

Auch richtig. Die Frage ist nur, ob hier nicht die EU einschreitet. Halte ich auch nicht für sehr wahrscheinlich, ist aber im Rahmen des Möglichen.
Man wird in Zukunft wohl auch keine eigentlich nicht mehr supporteten macOS-Versionen für alte Hardware patchen können (Catalina läuft ja gepatched noch auf einem Alu-MacBook von 2008). Allerdings gehe ich stark davon aus, dass wir in 5 bis 10 Jahren eh keine Hardware mehr kaufen, sondern direkt von den Herstellern als Hardware-as-a-Service beziehen, weswegen das sich dann von selber erledigt.

Haben ja momentan auch keinen Anreiz dazu. Es gibt noch keinerlei ARM Hardware oder ARM Marktanteil, welcher das rechtfertigen würde.

Das ist aber ein Henne-Ei-Problem. Leider hat Microsoft mit Windows Mobile schon nicht Fuß im Markt fassen können.

 

[Scotch]

Das liegt dann allerdings weniger an Apple als vielmehr daran, dass Microsoft keine individuellen ARM-Windows-Lizenzen verkauft.

Da auch unter Win RT (ARM-Windows) systembedingt x86-SW nicht läuft, wäre das auch kein gleichwertiger Ersatz. Ist daher eigentlich egal. Es geht ja i.d.R. nicht darum, Windows laufen zu lassen (warum dann einen Mac kaufen?), sondern Programme unter Windows, für die es keine gleichwertige (oder keine) Alternative gibt. Die

Und Microsoft bekommt das mit der Softwareversorgung für Windows unter ARM nicht vernünftig hin (oder ich sag es mal anders: Microsoft macht tolle Arbeit, aber nur solange es um x86-Systeme geht).

Microsoft zwingt Entwickler halt nicht dazu, so wie Apple das macht, egal ob es Architekturwechsel, Änderungen des Grafik-Subsystems usw. sind. Deshalb entwickelt keiner dafür, da der Marktanteil zu gering ist. Bei Apple werden aber a) früher oder später keine Apps im MAS zugelassen, die nicht Universal-Binaries für x86 & ARM enthalten und b) früher oder später keine Macs mehr mit x86 ausgeliefert. So zumindest der Plan - ob das aufgehet, ist natürlich 'ne andere Frage... Der Wechsel von der Nische (x86) auf "die" Mainstreamarchitektur schlechthin (x86) war sicherlich weniger riskant als umgekehrt. Zumal die damalige SW-Situation auch nicht gerade rosig war... Das sieht jetzt natürlich anders aus - ist aber auch x86. Xamarin, Mono/.NET Core, Unity... - das hört ja alles erst mal auf zu funktionieren. Es sind ja nicht alle Anwendungen reine Cocoa/Swift-Apps, für die die ggf. existierenden Apple-Tools zum Plattformwechsel wie proklamiert funktionieren (und auch daran darf nach dem Marzipan/Catalyst Debakel gezweifelt werden). Ob das die Entwickler mitmachen, wird man sehen.

Bin mal gespannt.

Ich auch

Haben ja momentan auch keinen Anreiz dazu. Es gibt noch keinerlei ARM Hardware oder ARM Marktanteil, welcher das rechtfertigen würde.

Man sollte da vielleicht deutlich zwischen Win RT und IoT unterscheiden. Ich denke, der Grund dass es Win RT gibt, ist dass es Win IoT gibt und das hat durchaus seinen Markt. ARM ist da halt eine populäre Plattform, für den es Kernel und die anderen Rumpfkomponenten und Treiber eh' gibt. Warum sie es sich leisten, Win RT zu entwickeln - keine Ahnung. Vielleicht so eine Me-2-Geschichte, oder für dedizierte embededd GUIs, wo das Windows CE ablöst.

Meine persönliche Einschätzung: Apple wird sicher ein ultraflaches, ultraportables MacBook herausbringen, welches aber nur auf dem Leistungsniveau eines iPad Pros liegt.

Also ein iPad mit macOS. Welches zunehmend zu iOS konvergiert. Was macht da Apple also eigentlich genau? Macs mit ARM herausbringen, oder ist das eigentlich doch eher die Marketingstrategie, um den Mac einzustellen und noch teurere iPads and Mac-Kunden zu verkaufen? Fragen über Fragen

Oder anders gefragt: Was unterscheidet denn jetzt genau noch ein iPad-Pro mit Tastatur und Maus von einem Macbook, wenn man i.W. email, Web und ein bisschen Textverarbeitung, Garageband und Tabellenkalkulation macht? Und spielt das noch eine Rolle, wenn man statt iPad Pro mit Magic Keyboard sagen kann "ich habe das neue Macbook mit ARM-Prozessor"?

Windows 10 für ARM passt doch genau zum technischen Konzept von Apple

Dafür gibt's aber keine Software, siehe oben! Welchen Sinn sollte es machen, Windows RT zu installieren, wenn es 100x so viel Anwendungen für macOS/iPadOS (siehe oben ) gibt? Bootcamp/Win-Virtualisierung macht man auf einem Mac doch, weil einem SW fehlt - unter Win RT macht höchstens dann ein virtuelles macOS Sinn, weil einem SW fehlt

 

[Balkenende]

Ja, das ist verkürzt und fachlich nicht so fundiert wie Du meine Denkweise.

Irgendein Windows (ARM) ist total Wurscht, auch da laufen ja nicht x86-Programme einfach so.

Genauso ist doch die Situation.

 

[ottomane]

So wird es kommen. Gute und performante Hardware traue ich Apple zu. Aber was nützt es, wenn das System vernagelt und proprietär wie ein iPad ist?
Ich werde das genau beobachten, allerdings als Außenstehender.

 

[Scotch]

Naja, wenn das jemand hinbekommt, dann Apple - und ein alternatives System mit "anderem" OS und HW wäre schon irgendwie cool. Ich benutze immer noch einen RiscPC, das letzte Update für RISC OS auf original-Acorn-HW ist von Montag (dieser Woche) Für die Jungen unter euch: Die haben ARM und die ersten Prozessoren erfunden und auch das erste OS dafür entwickelt - das wird bis heute maintained, u.a. auch für meine 30 Jahre alte HW. Aber das ist natürlich kein produktives System - i.W., weil ich von moderner SW verwöhnt bin. Performant und absolut flüssig zu bedienen ist es auch heute noch. Aber allein der Albtraum, mal was ausdrucken zu müssen...

Nur: Die Geschichte zeigt, dass für Butter & Brot PCs - also die ganzen Desktops für den täglichen Bedarf, wo es ganz überwiegend darauf ankommt, welche SW man benutzen kann und weniger, welcher Prozessor da 'drin steckt - sich nicht-x86-Acrhitekturen nie durchgesetzt haben. Schliesslich haben die x86 noch sehr viel performantere Wettbewerber (z.B. die ganzen MIPS- und SPARC-Truppen, ARM ist/war ja weiss Gott nicht die einzige erfolgeriche RISC-Plattform) abgehängt. Das sieht im Server-, Storage- und HPC-Bereich sicher anders aus - aber das spielt hier ja keine Rolle. Abgesehen von den "Standard-Apple-Silicons" mit einer GPU im SoC wird es z.B. interessant sein, ob und wer denn "richtige " GPUs entwickelt, die mit Apples ARM CPUs spielen. Auf so einem 5k-27"-Display sind da ja nun schon ein paar andere Bretter zu bohren, als auf einem iPhone-Display, insb. wenn man mehrere Monitore anschließen will und darauf vielleicht nicht nur 2D-Grafiken bewegt. Auch für ML-Anwendungen - z.B. die zunehmen ausgebauten PS-AI-Werkzeuge, um mal interessate Anwendungen für weniger technik-affine Anwender als Beispiel zu bemühen - wird man nicht für alle Anwendungen sich auf die Neural Engine auf dem SoC beschränken wollen. Klar - kann man alles machen, aber erstmal müssen GPU-Hersteller ähnlich hochoptimierte Treiber wie für x86 schreiben - und da sieht es ja beim x86-Mac schon Mau im Vergleich zum PC aus. Und Treiber für eine andere Hardware-Plattform zu schreiben ist 1x neu und dann warten - da ist nix mit automatisch konvertieren. Das ganze dann noch für Metal statt irgendeines etablierten Standards... Wie gesagt, es wird stark davon abhängen, ob Apple die Entwickler (HW & SW) an Bord kriegt. Ebenfalls nicht ganz unwichtig: Mit Computerspielen war's das dann auf dem Mac... Die wenigen nativen Entwicklungen kann man ja nun an einer Hand abzählen und wenn Unity oder Epic keine Lust haben sollten, ihre Entwicklungsumgebungen 1x neu für ARM zu entwickeln...

Wie gesagt: Bin gespannt, ob und wie Apple die Entwickler einfängt. Sicher nicht mit so einer dünnen Nummer wie der WWDC Keynote, aber da kommt ja sicher noch was (um so unverständlicher, was die Nummer sollte, ich versteh's immer noch nicht - das war schliesslich die Keynote einer Entwicklerkonferenz und nicht irgendeine Keynote für die Boulevardpresse). Sie wie bisher zu Plattformänderungen zwingen zu wollen, dürfte auf dem Mac m.E. schief gehen. Dafür sprechen auch heute schon die vielen (auch namhaften) MAS Totalverweigerer.

 

[Bananenbieger]

Irgendein Windows (ARM) ist total Wurscht, auch da laufen ja nicht x86-Programme einfach so.

Windows 10 für ARM kann zumindest 32bit-x86 Emulieren.

Xamarin, Mono/.NET Core, Unity... - das hört ja alles erst mal auf zu funktionieren.

Unity läuft doch schon unter ARM. Unreal ebenfalls. Xamarin ebenso. Die ganze Codebase dieser Frameworks hat doch schon ARM-Unterstützung. Und macOS wird ebenfalls unterstützt. Hier muss man (bis auf vielleicht eine Handvoll Bugs) wirklich nur Build-Parameter anpassen.

Und immer mehr Software läuft eh nur noch im Browser. Selbst MS Office wird mittlerweile zu einem beachtlichen Teil nur noch über den Browser genutzt. Der Neue Evernote-Client ist auch nur noch die Electron-Variante des Webinterfaces.
Auch die Software meines Unternehmens hat eigentlich immer native Desktop-Clients gehabt. Heute nutzen über 75% der Endnutzer nur noch unsere Web-Interfaces. Selbst bei den Power-Usern sind es nur noch 40%, die unbedingt die nativen Windows- und Mac-Clients nutzen.

aber erstmal müssen GPU-Hersteller ähnlich hochoptimierte Treiber wie für x86 schreiben

Die Treiber sind nicht wirklich ein Problem. Der GPU ist es recht egal, welche Architektur die CPU hat, solange die Byte-Order gleich ist. Gerade ARM sollte auch ein Interesse daran haben, dass deren GPUs gut unter macOS laufen. nVidia ist ja bei den Macs draußen und im Bereich Machine Learning kann AMD am besten auf der Mac-Plattform mit nVidia konkurrieren.

Apple bietet mit Metal auch jetzt schon eine sehr performante Grafik-API an. Und weil unter iOS die gleiche API verwendet wird, dürfte der Support durch Software sich eigentlich verbessern.

 

[ImpCaligula]

Hast Du da Quellen, dass in den Unternehmen (weltweit) nur noch 40% ein lokales Betriebssystem installiert haben?

Vom Solo Selbständigen bis zum Mittelstand kenne ich da kaum jemanden. In Konzernen mag das anders sein - und selbst da ist das nicht bei jedem Konzern selbstverständlich.

Und wenn ich mir die Installationszahlen von MS Office - Lokal - da sehe ich keinen Trend zur Webbrowser Version. Vor allem weil die Browser Version fast nichts wirklich kann (Funktionsumfang).

Nur noch Browser Applikationen und Clients mag in einer schönen Idealen IT Welt gelten - entspricht m.E. aber nicht der Realität.

 

[Bananenbieger]

Ich hab doch gar nicht von lokalen Betriebssystemen geredet.

Die meisten Fachapplikationen sind heutzutage doch schon browser basiert. Egal ob CRM, PIM, DAM, ERP, CMS, DMS, Ticket-Systeme, Urlaubsverwaltung, Talent-Management, Corporate Wiki, Corporate Social Media, Ausschreibungsmanagement und und und.
Fast alle mittleren bis größeren Unternehmen wollen Software mit lokal installierten Clients loswerden, weil das erheblich mehr Administrationsaufwand mit sich bringt.
Und bei Cloud-basierter Software gibt es kaum noch welche, die lokal installierte Desktop-Clients benötigt. Unternehmen, welche auf Cloud-Software mit Web-Oberfläche setzten, konnten Homeoffice wegen der Pandemie problemlos einführen.

Dass es noch lokale Software gibt, hängt größtenteils damit zusammen, dass Unternehmen nicht so schnell mal eben ihre Softwareinfrastruktur austauschen. Und in vielen Bereichen hat lokal installierte Software ja immer noch ihre Daseinsberechtigung aus technischen Gründen.

 

[Scotch]

Windows 10 für ARM kann zumindest 32bit-x86 Emulieren.

Emulieren != Virtualisieren. Das geht mit ganz erheblichen Performance-Verlusten einher. Gibt ja Gründe, dass sich Windows RT nicht wie geschnitten Brot verkauft (mal abgesehen vom "wen interessiert's, welche CPU in meinem Laptop werkelt" für 95% der Kunden).

Unity läuft doch schon unter ARM.

ARM ist eine Architektur, kein Prozessor. Unity muss Architektur & Plattform unterstützen - schliesslich braucht es ja auch unterschiedliche Unity-Versionen für Windows und macOS, für Android und iOS, für (damals) i386 und x86 usw. Z.B. muss Unity Universal 2 Binaries erzeeugen können und an den App-Container wird sich allein schon deshalb auch das eine oder andere ändern. Für den "End-Entwickler" vmtl./hoffentlich transparaent, aber nicht für den Platform/FRamework Entwickler. Wenn das alles so ist, wie Apple es erzählt sollte es allerdings "einfach" sein, wenn es bereits eine macOS Version gibt.

Das wäre dann aber auch nur ein Framework und etliche der anderen gibt's gar nicht für ARM. Mal ganz davon abagesehen, dass selbst da, wo es ARM und x86 Versionen gibt, Feature-Set und Performance nicht gleicht auf sind.

Gerade ARM sollte auch ein Interesse daran haben, dass deren GPUs gut unter macOS laufen.

Nochmal: ARM ist weder eine Firma, noch ein Prozessor. Und GPUs stellen die überhaupt nicht her.

Die Treiber sind nicht wirklich ein Problem.

Ich stelle fest: Du hast in deinem Leben noch keinen Hardware-Treiber programmiert.

Apple bietet mit Metal auch jetzt schon eine sehr performante Grafik-API an. Und weil unter iOS die gleiche API verwendet wird, dürfte der Support durch Software sich eigentlich verbessern.

Weil ja auch heute schon die ganze Grafik- und Spiele-Branche total begeistert native Metal-Programme schreibt (und nicht etwa OpenGL nutzt, welches Apple nicht mehr weiter entwickelt und woraus sich die teilweise grottige Performance im Vergleich zum gleichen Spiel unter Windows erklärt)? Weil Apples-Alleingang bis heute keine geometrischen Shader kann (und das erklären könnte, warum es längst nicht jedes Unity- oder Unreal-Spiel native unter macOS gibt, obwohl es deiner Theorie nach ja nur neu gebaut werden müsste)?

Nur so ein paar spontane Ideen aus der Multi-Platform-Hölle

Dass es noch lokale Software gibt, hängt größtenteils damit zusammen, dass Unternehmen nicht so schnell mal eben ihre Softwareinfrastruktur austauschen.

Es hängt natürlich auch damit zusammen, dass die Bandbreite der Anwendungen erheblich größer als "CRM, PIM, DAM, ERP, CMS, DMS, Ticket-Systeme, Urlaubsverwaltung, Talent-Management, Corporate Wiki, Corporate Social Media, Ausschreibungsmanagement" ist. Zumal die meisten deiner Beispiele Client-Server Anwendungen sind - die machen bei mir privat vielleicht 10% der genutzten Anwendungen aus und dienstlich vielleicht 30%. Office im Browser könnte ich z.B. allein deshalb schon nicht nutzen, weil ich oft da wo und wenn ich arbeiten muss gar kein Netz habe, z.B. im Flugzeug oder irgendwo in infrastrukturellen Ungunstgebieten.

Aber die ganze Diskussion geht m.E. am Thema vorbei: Solange Apple nicht zeigt, dass Apple Silicon schneller, kühler oder günstiger als gleichwertige x86 sind - wen interessiert's, ob in einem Mac eine ARM oder x86 CPU verbaut ist?

 

[Bananenbieger]

Emulieren != Virtualisieren. Das geht mit ganz erheblichen Performance-Verlusten einher.

Hab ja nichts anderes behauptet. Wobei ich mir gerade gar nicht sicher bin, ob das wirklich eine Emulation ist oder so wie bei der Xbox One Binärcode AOT übersetzt wird.

Gibt ja Gründe, dass sich Windows RT nicht wie geschnitten Brot verkauft

Die Gründe liegen aber eher wohl im Business, nicht in der Technik. Genauso ist Windows Mobile ja eher aus Business-Sicht, denn aus technischer Sicht gescheitert. Microsoft lernt da leider nur langsam.

Unity muss Architektur & Plattform unterstützen

Richtig. Unity unterstützt bereits ARM und macOS. Heißt: Du musst aus der bestehen Codebase jetzt eine andere Kombination kompilieren.

Ich stelle fest: Du hast in deinem Leben noch keinen Hardware-Treiber programmiert.

Ich hab auch keinen Prozessor entworfen und kein Betriebssystem geschrieben.

In der Switch steckt eine ARM-APU von nVidia und nVidia bietet ganz offiziell ARM-Treiber für Linux an. So groß kann das Problem also mit den Treibern nicht sein.

Weil ja auch heute schon die ganze Grafik- und Spiele-Branche total begeistert native Metal-Programme schreibt

iOS gehört so ziemlich zu den meistverbreiteten Spieleplattformen, noch vor Xbox und PlayStation.

warum es längst nicht jedes Unity- oder Unreal-Spiel native unter macOS gibt,

Hängt wohl eher damit zusammen, dass es kaum Macs gibt, die AAA-Game-kompatible Grafikkarten haben. Apple verbaut doch praktisch nur Mobile-GPUs. Wir werden daher auch eher von iOS portierte Spiele auf den Macs sehen.

Zumal die meisten deiner Beispiele Client-Server Anwendungen sind - die machen bei mir privat vielleicht 10% der genutzten Anwendungen aus

In Unternehmen sind nun mal die meisten Computer-Arbeitsplätze eher mit Client-Server-Anwendungen ausgestattet. Klar, es gibt auch da Ausnahmen. Aber genauso gibt es Unternehmen, die fast ausschließlich auf Thin-Clients setzen.

 

[Scotch]

Ich hab auch keinen Prozessor entworfen und kein Betriebssystem geschrieben.

Sorry, aber das ist Polemik. Du fällst hier mit Aussagen dazu auf, wie "einfach" das Erstellen von Treibern für eine neue Plattform ist, oder mal eben von einem Prozessortyp auf einen anderen zu cross-kompilieren die ziemlich deutlich machen, dass du das noch nie gemacht hast. Also häng' dich mal ein bisschen weniger weit aus dem Fenster mit deiner Relativiererei.

In der Switch steckt eine ARM-APU von nVidia und nVidia bietet ganz offiziell ARM-Treiber für Linux an. So groß kann das Problem also mit den Treibern nicht sein.

Was man daran sieht, dass es ja absolut alles an Spielen für ARM-Plattformen auch auf der Switch gibt? Nein? Warum denn nicht, muss man doch "nur" mal eben neu kompilieren...

iOS gehört so ziemlich zu den meistverbreiteten Spieleplattformen, noch vor Xbox und PlayStation.

Was ist das denn für ein bizarres Argument? Deiner Diktion folgend müsste es dann ja alle iOS-Spiele auch auf dem Mac geben. Weil ist ja Metal und das Programm gibt es schon und Unity und Unreal gibt es ja auch auf Mac und x86 also muss da ja nur einer das Knöpfchen drücken. Eigentlich ist es nachgerade verwunderlich, dass der Mac nicht die allerverbreiteste Spieleplattform überhaupt ist. Oder das aTV, das teilt sich schließlich schon heute die Plattform mit iOS... was da wohl schief gegangen ist?

Wir werden daher auch eher von iOS portierte Spiele auf den Macs sehen.

Das wird dann sicher eine Alternative für Mac-Benutzer, die heute Dank Bootcamp auf einen zweiten Rechner verzichten können. Ach was, die werden alle so begeistert von ARM-Macs sein, dass sie sich einen neuen Mac und einen Gaming-PC kaufen. Best of both Worlds!

Aber in einem hast du Recht: Mit hoher W'keit wird der nächste iMac das 27"-iPad - dann verschwindet tatsächlich die Grenze zwischen den Gerätetypen. Ob dann iPads eher die Convertibles von morgen oder iMac die Zukunft der iPads darstellen wird sich daran entscheiden, welche Software es gibt.

Ich bin 'raus, bis es belastbare Informationen gibt. Schliesslich war das Thema mal "erstaunlich, dass Apple eine neue HW-Platform vorstellt, ohne auch nur irgendwelche Fakten zu bringen, warum das toll sein soll".

 

[ottomane]

Erste Benchmarks tauchen auf: https://www.macrumors.com/2020/06/29/rosetta-2-benchmarks-a12z-mac-mini/

 

[Joh1]

Was man daran sieht, dass es ja absolut alles an Spielen für ARM-Plattformen auch auf der Switch gibt? Nein? Warum denn nicht, muss man doch "nur" mal eben neu kompilieren...

Ich weiß selber nicht wie schwer das ist. Aber die Switch ist deutlich schwächer als die anderen Plattformen was schon verhindert das die Spiele auch dort erscheinen. Wäre die Power vorhanden würden sicherlich auch andere AAA Titel dort übertragen werden.

 

[Bananenbieger]

Du fällst hier mit Aussagen dazu auf, wie "einfach" das Erstellen von Treibern für eine neue Plattform ist, oder mal eben von einem Prozessortyp auf einen anderen zu cross-kompilieren die ziemlich deutlich machen, dass du das noch nie gemacht hast. Also häng' dich mal ein bisschen weniger weit aus dem Fenster mit deiner Relativiererei.

Zumindest mit Cross-Compilieren kenn ich mich dann doch ziemlich gut aus. Denn unsere Software läuft so ziemlich auf allen Enterprise-Architekturen, die es in den letzten drei Dekaden gegeben hat. Ich hab sogar noch eine Kiste mit MIPS-R5000 zuhause stehen. Viel Kopfschmerzen habe ich auch bei den exotischeren Hardwareplattformen nie gehabt. Solange OS und APIs plattformübergreifend verfügbar waren, ließ sich auch ziemlich einfach alles portieren.

Nochmals die Frage: Was ist denn hier besonders neu an der Plattform? Die Software bleibt die gleiche und der Kern von macOS ist schon seit ewigen Zeiten cross-plattform. Der ganze hardwarenahe Unterbau von iOS ist ja gleich. Alle i*OS-Apps laufen auch auf x86 (->Simulator) und alle Apps seit dem intel-Switch setzen auf APIs auf, die es weiterhin geben wird.

Was man daran sieht, dass es ja absolut alles an Spielen für ARM-Plattformen auch auf der Switch gibt? Nein? Warum denn nicht, muss man doch "nur" mal eben neu kompilieren...

Läuft die Switch mit Android, iOS, Windows oder macOS? Nein. Natürlich ist es da mit neu kompilieren nicht getan. Ist auch eine ganz andere Baustelle. Oder umgekehrt: Kann doch nicht so schwer sein, ein Windows-Programm unter macOS auszuführen, ist doch schließlich die gleiche Hardwareplattform... Ist natürlich auch Unfug.

Was ist das denn für ein bizarres Argument? Deiner Diktion folgend müsste es dann ja alle iOS-Spiele auch auf dem Mac geben.

Kein bizarres Argument. Das Mainstream-Gaming findet heute auf den Smartphones statt.
Und übrigens laufen bald alle i*OS-Spiele auf den ARM-Macs. Apple stellt hier die iOS-APIs unter macOS bereit, so dass die i*OS-Apps und -Spiele ganz ohne jegliche Modifikationen funktionieren werden.

Aber in einem hast du Recht: Mit hoher W'keit wird der nächste iMac das 27"-iPad - dann verschwindet tatsächlich die Grenze zwischen den Gerätetypen.

Ich denke eher, dass es immer noch Apps geben wird, die speziell für Tastatur-Maus-Bedienung und/oder große Bildschirme optimiert wurden. Touch-Bedienung ist halt nicht überall sinnvoll und für touch-optimierte Oberflächen sind nicht ideal, wenn man eine Applikation it Tastatur und Maus bedienen will.
Der Trend könnte auch in die Richtung gehen, dass die Apps Oberflächen bekommen, die sich wie responsive Webapps ans Endgerät anpassen. Wie das geht, zeigt Google mit Flutter.