Die Zukunft von macOS mit ARM-Prozessoren?!

[markus107]

Lieber nichts lesen, oder nur Pro Apple Artikel?
Ok, halte auch nichts von der Bild Zeitung.
Zudem findet man im Netz auch nicht alles. An Infos heran zu kommen, kann auch heute noch schwer sein.

 

[agrajag]

Bis 2025 soll laut Mac&i in den Macs, nur noch ARM verbaut sein. Von A bis Z. Also kein Intel usw mehr.
Momentan werden wohl noch Intel Chips verwendet, weil es nicht anders geht. Es wird also noch sehr viel passieren.

Der Grund dürfte schlicht der Mac Pro sein. Der ist der letzte mit Intel.

Mit APFS. Es wird nicht das letzte Format sein. Da soll noch mehr kommen. Denke mal für die Zukunft auch 128 Bit. Aber egal.

Bis der Nachfolger von APFS kommt, dürften locker 10-15 Jahre ins Land gehen. APFS ist doch (für ein Dateisystem) brandneu.

Kann NTFS lesen, aber nicht schreiben. exFat wird bald out sein.

Es gibt 1 oder 2 kommerzielle Treiber für NTFS. Ansonsten gibt es den freien NTFS-Treiber, der auf FUSE (Filesystem in Userspace) basiert. Leider hat die macOS-Version von FUSE das Problem, sehr langsam im Vergleich zu sein. Keine Ahnung, ob das technische Gründe hat, oder da niemand mehr Arbeit reinsteckt…

Nun zu Windows. Ganz stur NTFS oder exFat. Auch Veknüpfung mit dem iPhone nicht mehr möglich.

Wie ist das zu verstehen? Was ist der Zusammenhang?

Und nun beobachtet mal Linux Cinnamon. NTFS lesen und schreiben ist kein Problem. Von anderen Formaten möchte ich nicht sprechen.

Das Linux-FUSE ist, wie oben schon gesagt, deutlich schneller. Es gibt auch deutlich mehr Filesysteme für FUSE.

Warum wurde BootCamp usw abgeschaft? Denke mal, dass diese Dinge nur ein Programmierer versteht, und nicht ich.

Zunächst dürfte es daran gelegen haben, daß es schlicht kein (solo kaufbares) AArch64-Windows gibt, was man überhaupt hätte starten können. Ich hab Bootcamp ganz am Anfang mal ausprobiert, es aber für mich als nicht interessant abgehakt. Windows läuft sowieso am allerbesten in einer VM. Dann hat man auch die großen Treiberärgernisse nicht mehr.

Zudem war Bootcamp eh immer sowas wie ein wilder Hack. Das fing schon damit an, daß man diese Partitionierung ausschliesslich mit dem Bootcamp-Assistenten durchführen konnte. Wenn ich es nicht falsch erinnere, durfte man min anderen Tools da auch nicht mehr dran, wenn man keine Datenverluste riskieren wollte. (Oder hatten die Tools ihre Arbeit verweigert?)

 

[Elektroschrott]

Mac&i = Hintergrundwissen?

Das ist doch ein besseres Verkaufsblättle

Jepp. Stimme zu. Wenn ich was kaufen möchte, informiere ich mich. In diesem Sinne ist also jede Informationsquelle ein "Verkaufsblättle"... Nur gehören heise bzw. c't bzw. Mac & i meiner Ansicht nach zu den besseren. - Man kann aber gern auch anderer Ansicht sein...

 

[PiaggioX8]

Der Grund dürfte schlicht der Mac Pro sein. Der ist der letzte mit Intel.


Bis der Nachfolger von APFS kommt, dürften locker 10-15 Jahre ins Land gehen. APFS ist doch (für ein Dateisystem) brandneu.


Es gibt 1 oder 2 kommerzielle Treiber für NTFS. Ansonsten gibt es den freien NTFS-Treiber, der auf FUSE (Filesystem in Userspace) basiert. Leider hat die macOS-Version von FUSE das Problem, sehr langsam im Vergleich zu sein. Keine Ahnung, ob das technische Gründe hat, oder da niemand mehr Arbeit reinsteckt…


Wie ist das zu verstehen? Was ist der Zusammenhang?

Das Linux-FUSE ist, wie oben schon gesagt, deutlich schneller. Es gibt auch deutlich mehr Filesysteme für FUSE.


Zunächst dürfte es daran gelegen haben, daß es schlicht kein (solo kaufbares) AArch64-Windows gibt, was man überhaupt hätte starten können. Ich hab Bootcamp ganz am Anfang mal ausprobiert, es aber für mich als nicht interessant abgehakt. Windows läuft sowieso am allerbesten in einer VM. Dann hat man auch die großen Treiberärgernisse nicht mehr.

Zudem war Bootcamp eh immer sowas wie ein wilder Hack. Das fing schon damit an, daß man diese Partitionierung ausschliesslich mit dem Bootcamp-Assistenten durchführen konnte. Wenn ich es nicht falsch erinnere, durfte man min anderen Tools da auch nicht mehr dran, wenn man keine Datenverluste riskieren wollte. (Oder hatten die Tools ihre Arbeit verweigert?)

Das ist so nicht ganz richtig.
Bootcamp braucht man nicht unbedingt. Bootcamp legt ja nur erst mal eine zusätzliche NTFS-Partition zur MacOS an und stösst den WIN-Installer an.
Also Bootcamp ist nur ein Tool das aus einer vorhandnen MacOS-Partition zwei macht und die zweite für NTFS vorbereitet und Treiber fürWIndows vorhält(installiert.
Mit entsprechenden Festplattentools (oder über das Terminal) kann man das aber auch machen.
Kannst auch eine externe SSD anschliessen und da komplett für WIN nutzen (am besten als GUID formatieren).
Soll auch Leute geben die ihren Mac nur mit Windows und ohne MacOS nutzen.

Der (inoffizielle) Vorteil der Intel-Macs: wer sich entsprechende Boards/Hardware selbst kauft kann aus einer Dose einen Hackintosh machen, der leistungsmässig einen original Mac ganz schnell in den Schatten stellt zu einem Bruchteil der Originalkosten.
Und selbst ein Intelfähiges MacOs ist unter einer WIN-VM problemlos zum laufen zu bringen.

Bei den ARM-Macs gehe ich mal davon aus dass die VM auch den x86 emulieren muss, da entsprechende Hardware ja nicht vorhanden ist. Da es aber wohl schon VMs für MacOS gibt, gehe ich mal davon aus dass es nicht mehr lange dauern wird bis es die auch fürs iPad gibt.
Und damit nähern wir uns dem Star Trek Universum, wo sie nur noch mit einem Tablet rumlaufen. Tatstatur und Maus kann man ja jetzt schon problemlos an iPad nutzen.
Die ARM Geräte haben meiner Ansicht nach auf jeden Fall das Potenzial Laptops auf absehbare Zeit abzulösen.

Es braucht also tablets, die auch mit Maus und Tatstatur umgehen können und es braucht eine akzeptable Möglichkeit auf grosse Bildschirme zu spiegeln (z.B. Dockingstation mit GPU). Und es sollte langsam mal eine akzeptable Lösung geben um auch Festplatten einfach ans iPad anzuklemmen.

Ach ja - dass WIN in einer VM besser läuft als unter Bootcamp ist definitiv ein Gerücht.
Entscheidend für die VM ist neben dem Prozesor jede menge RAM und Anzahl der Kerne die man der VM zuweisen kann.
Die GPU z.B. wird von keiner VM genutzt (nicht mal mit VM auf einem Windows-Rechner).
Daher kannst auch kaum Games unter einer VM zocken.
Und gerade bei MacOS ist es so, dass viele Games gar nicht native unter MacOS laufen (da nicht angepasst) sondern in einer angepassten VM.

 

[Madcat]

Wenn meine Entwicklungswerkzeuge für meine Elektroniksachen auch auf dem iPad laufen würden hätte ich wohl kein Macbook mehr hier auf dem Tisch stehen. Ich mache schon sehr viel mit meinem iPad Pro 9.7" von 2016. Ich darf gar nicht drüber nachdenken, was die neuen iPads können.

 

[Mister79]

Wenn meine Entwicklungswerkzeuge für meine Elektroniksachen auch auf dem iPad laufen würden hätte …

Gibt es solche Software nicht für iPads? So gar nicht?

 

[PiaggioX8]

Gibt es solche Software nicht für iPads? So gar nicht?

Da ist WIN-Software weitaus besser aufgestellt als für MacOS oder iOS. Einfach weil es die schon seit Jahrzehnten dort gibt und in der Industrie das Apple-Zeugs eben kein Standard ist.

 

[markus107]

@agrajag

Bis der Nachfolger von APFS kommt, dürften locker 10-15 Jahre ins Land gehen. APFS ist doch (für ein Dateisystem) brandneu.

APFS wurde 2019 eingeführt? Umstieg von Mojave auf Catalina? Also nicht mehr so brandneu? Was heute entwickelt wurde, ist morgen schon out. Alles geschah zu Intel Zeiten.
Nun spinne ich mal herum.
Entwickler schimpfen jetzt schon herum, in puncto Sicherheit. Können wir nicht mehr lösen!
Kann mir nur folgende Dinge vorstellen: Das Apple bis 2025 alles auf die Reihe bekommt. Das alle Chips von ARM sind. Also volle Apple Kontrolle. Und dann auch ein neues Datei Format.
Aber lassen wir uns mal überraschen. Keiner weiß, was noch passiert. Man kann es sich nur denken.

 

[agrajag]

@agrajag

APFS wurde 2019 eingeführt? Umstieg von Mojave auf Catalina? Also nicht mehr so brandneu? Was heute entwickelt wurde, ist morgen schon out.

Jein. Es gibt bereiche, da gilt das nicht. Besonders Dateisysteme sind ein heisses Eisen. Mit 5 Jahren ist ein Dateisystem durchaus noch jung. ZFS war sogar schon 5 Jahre alt, als es 2006 final veröffentlicht wurde. Und mittlerweile ist es gut 20 Jahre alt – und ist nachwievor das modernste Dateisystem. Und APFS wird auch noch locker 10 Jahre aktuell sein.

Bei Dateisystemen sind alle, zurecht, sehr konservativ. Wenn etwas zu 100% fehlerfrei sein muß, DANN das Dateisystem.

Alles geschah zu Intel Zeiten.

Der Zusammenhang zu einer Architektur ist welcher?

Entwickler schimpfen jetzt schon herum, in puncto Sicherheit. Können wir nicht mehr lösen!

Was?!? Welche Entwickler schimpfen über welche Sicherheitsprobleme rum? Und wer kann was nicht lösen?

Kann mir nur folgende Dinge vorstellen: Das Apple bis 2025 alles auf die Reihe bekommt. Das alle Chips von ARM sind. Also volle Apple Kontrolle. Und dann auch ein neues Datei Format.

Was ist überhaupt dein Problem?!? Was ist das für eine Fixierung auf einen APFS-Nachfolger? Was fehlt dir denn da so sehr?!?

Aber lassen wir uns mal überraschen. Keiner weiß, was noch passiert. Man kann es sich nur denken.

Du hörst dich an wie erin Verschwörungstheoretilker. Alles schön vage halten. Blos nichts konkretes. Nur gemunkel und getuschel von "anderen".

Du lässt mich etwas ratlos zurück…

 

[Madcat]

Gibt es solche Software nicht für iPads? So gar nicht?

Leider nicht. Ich kann ja schon froh sein um die Werkzeuge, die es für macOS gibt. Ich muss u.a. deshalb stets vorsichtig sein, wenn ich das OS wechsle. Ich kann es mir nicht leisten, dass ich ein/zwei Monate warten muss, bis meine Werkzeuge wieder funktionieren. Deshalb bekommt das Update auch immer als erstes der Rechner, bei dem es relativ egal ist, ob etwas nach dem Update noch geht oder nicht

Da ist WIN-Software weitaus besser aufgestellt als für MacOS oder iOS. Einfach weil es die schon seit Jahrzehnten dort gibt und in der Industrie das Apple-Zeugs eben kein Standard ist.

So schaut es aus. Meine Mikrocontroller-Wahl im Bereich 8 Bit fiel unter anderem auf die AVRs eben weil es Tools für diese Mikrocontroller auch auf Mac OS gab. Wäre ich damals mit Windows unterwegs gewesen wäre es bei mir eher was mit den PICs geworden statt der AVRs.

 

[Brettsegler]

Meine Mikrocontroller-Wahl im Bereich 8 Bit fiel unter anderem auf die AVRs eben weil es Tools für diese Mikrocontroller auch auf Mac OS gab. Wäre ich damals mit Windows unterwegs gewesen wäre es bei mir eher was mit den PICs geworden statt der AVRs.

Dann kannste jetzt endlich auf die PICs umsteigen. MPLAB läuft auf meinem M1 perfekt.

 

[Jayway]

Meine Mikrocontroller-Wahl im Bereich 8 Bit fiel unter anderem auf die AVRs eben weil es Tools für diese Mikrocontroller auch auf Mac OS gab. Wäre ich damals mit Windows unterwegs gewesen wäre es bei mir eher was mit den PICs geworden statt der AVRs.

Das ist ja verrückt. Bei mir war es genau umgekehrt. Die Wahl auf AVR fiel, weil es für Linux und Windows gute Tools gab (AVR Studio, avrgcc, Debugger für AVR etc.). Erst seit Microchip Atmel übernommen hat und die MPLAB IDE auch AVR unterstützt, habe ich leichten Herzens den Wechsel zu macOS vollzogen. Vorher hätte ich mit macOS vermutlich PIC's gewählt.

 

[Madcat]

Jungs, ich hab mich um 2005 bzgl. Mikrocontrollerprogrammierung ausgerichtet. Da war mit Mac OS X und PICs programmieren noch lange nix in Sicht. Dafür gabs aber schon den avr-gcc und avrdude. OK, war damals auch noch ein Krampf das unter Mac OS Tiger zum Laufen zu bekommen. Was war es 2007 ein Segen als obdev das Crosspack für Mac OS raus brachte

 

[Madcat]

MPLAB läuft auf meinem M1 perfekt.

Welches Java hast du installiert? Bei mir schmiert in einer Tour Java ab, immer wieder. Ich glaub die längste Laufzeit bisher war rund 5000s bis es zum Crash kam. Für die neuen AVR (aktuell arbeite ich mit einem Attiny3226) nutze ich daher das MPLAB mit Windows 11 Arm unter Parallels.

 

[Brettsegler]

Welches Java hast du installiert? Bei mir schmiert in einer Tour Java ab, immer wieder. Ich glaub die längste Laufzeit bisher war rund 5000s bis es zum Crash kam. Für die neuen AVR (aktuell arbeite ich mit einem Attiny3226) nutze ich daher das MPLAB mit Windows 11 Arm unter Parallels.

Ähhhm, bewußt gar keins. MPLAB meint:

Product Version: MPLAB X IDE v5.50
Java: 1.8.0_265; OpenJDK 64-Bit Server VM 25.265-b11
Runtime: OpenJDK Runtime Environment 1.8.0_265-b11
System: Mac OS X version 10.16 running on x86_64; UTF-8; en_EN (mplab)

Achtung: Ist noch die 5.50 und nicht die aktuelle 6.00 wegen Kompatibilität zu einigen PCs hier im Labor an der Uni. Und nur im Zusammenhang mit PIC24F benutzt.

Grüße

 

[Brettsegler]

Ich glaube es nicht! Gerade ist MPLAB abgestürzt

 

[Madcat]

Bei mir ist die Version ob 5.5 oder 6.00 egal

EDITH:

Ich glaube es nicht! Gerade ist MPLAB abgestürzt

hihihi, das kenn ich

 

[Brettsegler]

Hmm, das letzte Mal im Juli intensiv genutzt und da ging es noch. Jetzt ebenfalls Java wie bei dir. Kann jetzt aber nicht mehr nachvollziehen, ob das im Juli auch schon die Version 5.50 war. Muss ich mir nächste Nochmal genauer anschauen. Doof...

 

[oneOeight]

Welches Java hast du installiert? Bei mir schmiert in einer Tour Java ab, immer wieder.

Gibt es keine Logs?
1.8 ist ja schon recht alt, reicht aber für die meisten Anwendungen.

 

[Brettsegler]

Gibt es keine Logs?
1.8 ist ja schon recht alt, reicht aber für die meisten Anwendungen.

---

Nachfolgend mal der Anfang. Geht noch endlos weiter. Kannst du da irgendetwas erkennen?

Und ich kann ja wirklich mal eine aktuelle Version testen. Unten sieht man ja, dass das Programm offenbar eine eigene Version in seinem Programmpfad installiert hat.

-------------------------------------
Translated Report (Full Report Below)
-------------------------------------

Process:               java [58485]
Path:                  /Applications/microchip/*/java
Identifier:            java
Version:               ???
Code Type:             X86-64 (Translated)
Parent Process:        bash [58359]
User ID:               501

Date/Time:             2022-10-21 19:56:48.4716 +0200
OS Version:            macOS 12.6 (21G115)
Report Version:        12
Anonymous UUID:        84BCF12B-2B2F-8B67-D61A-7A775AFD46AB

Sleep/Wake UUID:       BD190276-603B-4A59-ACF5-6D86B46D2B7B

Time Awake Since Boot: 180000 seconds
Time Since Wake:       69 seconds

System Integrity Protection: enabled

Crashed Thread:        37  Java: main

Exception Type:        EXC_BAD_ACCESS (SIGBUS)
Exception Codes:       KERN_PROTECTION_FAILURE at 0x000000010d1ec000
Exception Codes:       0x0000000000000002, 0x000000010d1ec000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Reason:    Namespace SIGNAL, Code 10 Bus error: 10
Terminating Process:   exc handler [58485]

VM Region Info: 0x10d1ec000 is in 0x10d1ec000-0x10d1ed000;  bytes after start: 0  bytes before end: 4095
      REGION TYPE                    START - END         [ VSIZE] PRT/MAX SHRMOD  REGION DETAIL
      Rosetta Return Stack        10d1e8000-10d1ec000    [   16K] rw-/rwx SM=PRV 
--->  VM_ALLOCATE                 10d1ec000-10d1ed000    [    4K] ---/rwx SM=PRV 
      shared memory               10d1ed000-10d1f1000    [   16K] r--/r-- SM=SHM