Diese Nachricht habe ich gerade bei heise.de gelesen.
... Das Betriebssystem warnt bald, wenn abgekündigte Kernel-Erweiterungen verwendet werden.
Wie sieht das dann bei uns mit Clover / OpenCore aus?
Gerade auf Heise
-
- Erledigt
- dutch64
- Erledigt
-
-
Das wurde bereits hier angesprochen.
Habe die beiden Threads deswegen auch zusammengeführt.
-
Ist unser aller (Hackintosh-)Ende nicht eh bald in Sicht?
Aktuell sieht doch alles so aus, als würde Apple mittelfristig wieder den Fehler machen und zu irgendwelchen ARM-CPUs wechseln.
Für mich wäre das Thema mit dem Wegfall der x86/x64 Architektur definitiv erledigt - macOS ist ne feine Sache - aber für Desktopbetrieb will ich nichts von ARM-CPUs hören und sehen.
Den Powermac und wie das ganze proprietäre "Gelumpe" früher hieß, hätte ich niemals gekauft oder empfohlen.
Die gleiche Architektur wie Windows und somit auch von 98% aller Softwarehersteller zu nutzen, war aus meiner Sicht der wichtigste Schritt, dass heute überhaupt viele Leute auch ein Macbook usw. haben wollen.
Ich hatte mal ein Synology-NAS mit ARM-CPU -- da war der Name leider Programm. So eine ARMe Performance hatte ich schon lange nicht mehr. Gleiche Modell mit Intel-CPU - Faktor 2-3 schneller.
-
Und selbst wenn sie wechseln würden, werden die aktuellen Systeme im Kaby-. Coffee- und Cascade-Lake noch mindestens 5 Jahre weiter unterstützt.
In der Zeit kann im Hackintosh-Universum noch sehr viel passieren...
-
Es muss ja kein harter Bruch sein. Windows will auch schon seit Jahren auf ARM, weil diese Chips *jetzt* energiesparend sind und nicht in 30 Jahren, wenn Intel und AMD ihre Initiativen durchhaben. Für ein MacBook für den Ottonormalverbraucher ist das bestimmt eine super Sache
-
Stimmt auch wieder.. ich habe ja auch die Hoffnung, dass die die nur bei mobilen Geräten einsetzen.
Im Desktopbereich hat der ARM keine Existenzberechtigung, da sein einziger Vorteil gegenüber Intel/AMD die Energieeffizienz ist - die mir aber bei einem Desktop-PC, wo eine 300 Watt fressende GFX drin ist, mal völlig wumpe ist
Es bleibt spannend
-
Apple wird so bald nicht komplett auf ARM umschwenken. Das können die sich gar nicht leisten. Auf absehbare Zeit wird es maximal eine Koexistenz von ARM und x86 geben. Schlanke MacBooks mit ewig langer Akkulaufzeit für die Non-Pro User. Am Rest ändert sich erstmal nichts. Die Chancen stehen aber wahrscheinlich gar nicht so schlecht dass es hier künftig einen Mix aus Intel und AMD geben wird.
-
Zuerst einmal:
zu den Hochzeiten von PPC, waren diese der x86 Plattform um Welten überlegen. Damals konnte Apple noch Werbung und Demos mit Vergleichen machen und zeigen, wie Macs die Wintels abhängen.
Als die PPC Entwicklung allerdings ins Stocken kam und die Roadmap auch bis auf weiteres keine Besserung anzeigte, während Intel nach dem P4-Heizofen-Desaster endlich den Wert von Performance-pro-Watt erkannte und eine in der Tat fulminante Entwicklung hinlegte, war der Wechsel eine völlig logische Entscheidung.
Aktuell ist es so, dass Intel am Stocken ist. Apple könnte zwar (und das werden sie auch hoffentlich in Bälde) auch AMD-CPUs als Option anbieten, denn dank gleicher Architektur ist die Anpassung für die eine Fingerübung, aber tatsächlich schneller als PCs...das können sie weiterhin nicht bewerben.
Auf der anderen Seite bauen sie als einer der wenigen mit ARM-Volllizenz jedes Jahr einen neuen Ax Chip, der sich deutlich schneller weiterentwickelt als deren x86 Pendants. Wenn man dann noch bedenkt, dass die Dinger mittlerweile in i5 und sogar Vorjahres i7 Regionen vorstoßen obgleich sie für mobile Devices stromsparend arbeiten müssen, kann man erahnen, was ein Bx oder wie immer die solche unlimitierten Desktopchips nennen würden ohne diese Einschränkungen zu leisten in der Lage wäre.
Somit sehe ich zwar noch keinen ARM-Mac in den nächsten 1-2 Jahren, aber wenn die Entwicklung so weitergeht wird es dereinst kommen, aber erst wenn der Leistungsüberschuss so hoch ist, dass eine x86 Emulation mit vernünftiger Leistung läuft.
-
Quelle: https://twitter.com/_rogame/status/1225381275617415168
Referenziert werden wohl NAVI12_A0, NAVI21_A0, PICASSO_A0, RAVEN2_A0, RAVEN_A0, RENOIR_A0 und VANGOGH_A0.
Das kann wird ja spannend!
-
Einmal mehr die Info, dass das schon seit ein paar Tagen hier läuft.
-
was meint ihr mit "auf das ende der Clover kext Injektion steuern wir zu"?
Mich würde interessieren wo genau der Unterschied liegt? Unterschied wovon?
-
ozw00d Ich hoffe ich habe das damals richtig verstanden.
OC linkt die Kexts selbst und fügt sie in den prelinkedkernel ein - die Datei wird also so geladen, als wäre der Cache mit den Kexts in LE neu gebaut worden, nur eben ohne Involvierung von macOS.
Klingt für mich deutlich anders als es bei Clover funktioniert, ein Hinweis darauf gibt ja auch schon der Clover Configurator, da heisst es unter System Parameters "Inject Kexts".
-
derHackfan ist es auch - deswegen wird OC nicht betroffen sein, wenn Apple die Booter-Kext-Funktion ersatzlos streicht
-
derHackfan also verstehe ich das richtig:
OC: verlinkt die Kext quasi während der Laufzeit als wenn der kext aus dem cache kommt (prelinked)
Clover: Injected die Kext erst wenn das System startet?
Wenn ich damit richtig liege, warum haut man in Clover die Kexts dann in Other? Ich verstehe es irgendwie nicht So richtig bei Clover.
Was bedeutet hierbei Involvierung von macOs?
mhaeuser kannst du die Booter-Kext-Funktion näher erläutern?
-
In welchen Ordner man die Extensions bei Clover packt ist eigentlich egal der Other Ordner wird empfohlen weil dort abgelegte Extensions von Clover unabhängig von der zu startenden macOS Version (Darwin Kernel Version) verwendet und injected werden. Die Reihenfolge in der Clover vorgeht entspricht immer dem folgenden Muster
1. Extensions aus dem zur Kernel Version passenden Ordner (Darwin Version)
2. Extensions aus dem Ornder Others
Sinn macht das wenn man Extensions hat die sich auf eine bestimmte macOS Version beziehen und nur da verwendet werden sollen (gab mal eine Weile bei der VoodooPS2.kext die Notwendigkeit zwischen verschiedenen OSX Versionen zu differenzieren). Unabhängig vom Ordner in dem sich die Extension befindet funktioniert aber die Art und Weise wie Clover die Extensions ins System einbringt immer auf die gleiche Art und Weise.
-
ozw00d Hab das schon mehrfach erklärt, könnte vielleicht mal ins Wiki oder so...
Der Kernel hat direkt nach dem Start keinen FS-Zugriff, weil er keinen FS-Treiber (oder Schnittstellentreiber, der Baum geht ja noch weiter) hat, braucht aber trotzdem die Erweiterungen. Dazu gibt es den prelinkedkernel, bei dem die Kexts schon gegen den Kernel gelinkt zusammen mit diesem im selben Image verpackt sind und zusammen mit diesem geladen werden. Über ein Offset im eigenen Header kann er dann die Kexts im Speicher finden und starten (Linken geschieht nicht, da *pre*linked). OpenCore modifiziert den prelinkedkernel direkt und fügt die selbst gelinkten Kexts an - im Endeffekt das selbe wie der Cache-Aufgbau im OS (kextcache).
Damals konnte man den prelinkedkernel (bzw. den Vorgänger MKEXT) noch umgehen, indem man mit "no cache boot" gestartet hat. Das funktioniert, indem der Booter (boot.efi) die Kexts in den Speicher lädt und eine Tabelle mit Adressen aufbaut, die dem Kernel via DeviceTree bereitgestellt wird. Der Kernel lädt und linkt(!) dann die Kexts selbst gegen sich selbst (KXLD), sodass er sie starten kann. Diesen Mechanismus, der seit Yosemite nicht mehr unterstützt wird, nutzt Clover aus, um die Kexts zu laden - und der steht auf der Abschussliste.
-
OC: verlinkt die Kext quasi während der Laufzeit als wenn der kext aus dem cache kommt (prelinked)
Ich weiß nicht was du mit "während der Laufzeit meinst", aber man kann es sich in etwa so vorstellen. Normalerweise packt macOS selber alle Kexts in einen Cache und lädt dann beim Start die Daten ohne große Verifikation (die passiert soweit ich weiß größtenteils davor) aus diesem Cache. OC bastelt den Cache auseinander (ohne involvierung von macOS), fügt die vom Benutzer hinterlegten Kexts ebenfalls in den Cache, schnürt das Paket wieder zu und übergibt das ganze macOS. macOS lädt daraufhin alle Kexts aus dem Cache, wie als wäre nichts gewesen und genau so, wie es sein soll.
Clovers Injection basiert hingegen auf einer alten macOS Kernel-Methode, mit der es damals möglich war Kexts zu laden, obwohl sie nicht im oben genannten Cache liegen. Diese Methode ist veraltet und unbenutzt, warum sie noch im Kernel vorhanden ist weiß ich persönlich nicht. Da es dazu aber offensichtlich keinen Grund gibt, kann die Methode auch jederzeit verschwinden und Clovers KextInjection ist hinüber...
Edit: DF war schneller, aber vielleicht hilft ja meine vereinfachte Darstellung dem ein oder anderen es zu verstehen...
-
und lädt dann beim Start die Daten ohne große Verifikation (die passiert soweit ich weiß größtenteils davor) aus diesem Cache.
Das *kann* sogar nur davor passieren, weil durch das Linken die Daten unwiederherstellbar verändert werden - jede Signaturverifikation oder so *muss* also vor dem Linken passieren. Wir sind vor dem ganzen Quatsch relativ sicher
-
Das *kann* sogar nur davor passieren, [...] - jede Signaturverifikation oder so *muss* also vor dem Linken passieren.
Und somit ist dann auch begründet warum die von dir gepostete Meldung Leggalucci für die Hackintosh Community vollkommen irrelevant ist.
