OpenCore oder Clover die Drölfte...

Zitat von KMBeatz

Ein kleiner Patch in Opencore womit die ACPI Patches wie in Clover nicht angewendet werden wäre ja nicht viel verlangt gewesen.

Und plist-Patches wären auch nicht viel verlangt gewesen. Und eine eingebaute Linux-Autoerkennung (ironischerweise ist das gerade in der Recherche). Und eine Autoerkennung für DeviceProperties. Und ein angepasster Bootbildschirm.

Ob etwas geht oder nicht, ist erstmal herzlich egal. Der größte Unterschied zwischen OC und Clover ist, dass OC einer strikten Linie folgt und alles sinnvoll ineinander greift, und in Clover jeder Müll importiert wird, den irgendwann irgendwer mal für sich haben wollte. Der Kram wird dann auch kaum getestet, weil 3 Leute den nutzen, und übrig bleibt dann ein Wrack, von dem keiner weiß, warum es so funktioniert, wie es funktioniert.

Genau das verschandelt die Code-Basis, irgendwann muss man halt mal eine komplette Review machen und entscheiden was man braucht und was nicht. Alles was man nicht mehr braucht, kommt dann einfach weg. Jetzt lohnt sich das allerdings auch nicht mehr, weil bei dem Konstrukt blickt man dann irgendwann einfach selbst nicht mehr durch, oder es wird einfach soviel, dass die Zeit under der Aufwand sich nicht lohnen.

Sorry aber kann ich nicht nachvollziehen.

Respekt vor deiner/eurer Arbeit aber so eine Diskussion wegen eines kleines Patches bzw Einstellung zu machen ist nicht normal.

Was würde den bei Opencore schief laufen wenn es integriert wäre? Denke nichts.

Habe auch keine Lust zu diskutieren aber seine Meinung zu sagen ist ja nicht verboten oder?.

🖐

LG

Wenn man einmal damit anfängt sämtliche Userwünsche zu implementieren, dann hört man damit nicht mehr auf und dann hat man das selbe Ergebnis wie Clover.

Zitat von KMBeatz

aber so eine Diskussion wegen eines kleines Patches bzw Einstellung zu machen ist nicht normal.

Weißt du, was auch nicht normal ist? Robuste und gut wartbare Software zu schreiben. Schau dir Windows an. Optionen und Legacy-Code so weit das Auge reicht. Die sind an einem Punkt, an dem sie selbst von ihrer alten Codebasis wegwollen, aber sie schaffen es nicht. Sie ist zu groß, zu verschachtelt, zu wenig abstrakt. Mit jeder Änderung geht irgendwo irgendetwas abstruses kaputt. Jetzt schau dir macOS an. Alte Macs, die 32-bit Firmware haben? Weg damit. 32-bit Apps? Weg damit. GPUs ohne Metal-Unterstützung? Weg damit. Wie schätzt du Windows ggü. macOS ein?

Arbeite mal an großen Low-Level-Projekten in der echten Welt, und lass mich dann nochmal deine Meinung hören.

Zitat von KMBeatz

Habe auch keine Lust zu diskutieren aber seine Meinung zu sagen ist ja nicht verboten oder?.

Aber, dass ich darauf reagiere, ist verboten? Wenn du keine Reaktion willst, dann teile nichts, auf was wahrscheinlich reagiert werden wird.

KMBeatz

Ich glaube, so etwas liesse sich auch anders erfragen, ohne diesen fordernden Ton und ohne dieses gegensätzliche Geschreibe*, was eine Beantwortung schwierig macht.

* Behauptung vorweg stellen, dann eine Frage stellen aber gleichzeitig keine Lust auf Diskussion signalisieren, dann trotzig nochmal die Meinungsfreiheit demonstrieren.

Ohne wirklich Einblick in Interna zu haben, kann man sicher nicht abschätzen, ob es denn wirklich "einfach" wäre. Auch wenn es einen Patch dazu von dritten gegeben hat. Denn "dass OC einer strikten Linie folgt und alles sinnvoll ineinander greift" – hier fragt man sich natürlich, an welcher Stelle müsste ein solcher Patch stehen, wann wird abgefragt welches System gestartet wird (unabhängig davon, ob über OpenCanopy oder Text) und ist nicht zu diesem Zeitpunkt alles Relevante schon gelaufen und wenn ja, warum?

Ich habe große Hochachtung vor den Entwicklern, habe auch @Downloadfritz früher mal zu ziemlich genau diesem Thema befragt und bekam eine sehr fundierte Antwort, warum nicht.

Ich habe es vergessen …

Zitat von REVAN

Wenn man einmal damit anfängt sämtliche Userwünsche zu implementieren, dann hört man damit nicht mehr auf ...

Ähnlich geht/ging es mir beim Kext Updater. Es gab/gibt viele gute Ideen aus dem Forum die ich dann auch umgesetzt habe weil die für die Meisten nützlich sind. Es gab aber auch Anfragen wo ich den Nutzen für die breite Maße nicht gesehen habe da zu speziell und diese Ideen habe ich dann verworfen. Letztlich muss ich den ganzen Kram ja auch "warten". Da muss man sich ja nicht einen unnötigen Molloch heranzüchten.

Man muss dann eben Prioritäten setzen.

apfelnico soweit ich mich an den Post erinnere, kann zu dem Zeitpunkt an dem die ACPI Modifikationen gemacht werden das OS noch nicht zuverlässig erkannt werden. Und da es keine technisch saubere Lösung möglich ist, welche in allen Fällen korrekt funktioniert, wurde das Feature es wieder entfernt.

Der NDK Fork hat das einfach aus der History wiederhergestellt…

Zitat von KMBeatz

Sorry aber kann ich nicht nachvollziehen.

griven schrieb doch weiter oben schon, wie es geht.

OpenCore oder Clover die Drölfte...

Ok, er schrieb keine Anleitung oder HowTo wie man es macht, er hat aber die eigentliche Lösung aufgezeigt wie es funktioniert, ohne dass die Devs noch extra einen Schalter in OC einbauen wie dazumal beim N-D-K Fork. ( Stichwort _OSI in den ACPI Patches). Vorausgesetzt, man befasst sich mit der Materie, ist bereit zu lernen und auch selber Hand anzulegen.

Der Punkt ist halt das man eben sauber arbeiten muss und sich Gedanken über die Modifikationen die man vornimmt machen sollte bevor man sie vornimmt. Natürlich ist der Weg den Clover da geht bequem und vermeintlich einfach aber am langen Ende ist er eben auch unsauber und tatsächlich zumindest Teilweise auch gefährlich. Was man vielfach, gerade im Clover Umfeld, erlebt ist ein Arbeiten mit der Gießkanne (sicher auch begünstigt durch Tools wie den Clover Configurator da man hier schnell mal einen Haken nach dem Try and Error Prinzip gesetzt hat) ganz nach dem Motto viel hilft auch viel. Das viel hilft auch viel Denken ist aber inzwischen auch im OpenCore Bereich weiter verbreitet als man denkt. Schaut man sich nämlich mal die EFI Ordner einiger Hilfesuchenden an sieht man auch hier immer wieder teils hanebüchene Konstrukte in denen dann einfach mal alle mitgelieferten ACPI Samples geladen werden oder ähnlich dösige Stunts...

Gerade der Bereich der ACPI Modifikationen erfordert aber per Definition eigentlich schon ein sauberes Arbeiten und so sollte die Maxime doch eigentlich sein so wenig eingreifen wie möglich und wo es sich nicht vermeiden lässt so sauber und penibel arbeiten wie es geht. Meiner Meinung nach muss man sich hierbei an aller erste Stelle die Frage stellen welche Modifikationen brauche ich wirklich und wozu brauche ich sie? Hat man diese Frage für sich beantwortet und ist man nicht bereit tief in die Materie einzusteigen ist die zweite Frage die sich stellt gibt es da schon was zum Beispiel in den ACPI Samples die OpenCore mitbringt das ich nutzen kann (bei den mitgelieferten Samples muss man sich keine Sorgen darüber machen das es Probleme mit Windows gibt denn die haben die entsprechenden _OSI Weichen an Bord) oder nicht? Am Ende dieses Frage Antwort Spiels bleibt vielleicht noch etwas über das dann wirklich ein manuelles Eingreifen erforderlich macht an der Stelle kommt man dann halt nicht umhin sich eben doch mit der Materie zu befassen aber das liegt halt in der Natur der Sache. Geht man so vor dann erreicht man auf den meisten Systemen ein akzeptables Ergebnis ohne das man die "Funktion" von Clover überhaupt vermisst

Ich weiß das das bei Laptops oft eine lästige weil sehr spezielle Angelegenheit ist kann aber aus Erfahrung sagen das es sich lohnt sich damit zu beschäftigen denn das Ergebnis des sauberen Arbeitens (auch unter Clover als Loader) ist ein sauber arbeitendes System sowohl unter macOS als auch unter Windows ganz ohne die Notwendigkeit die Injects für Windows zu unterdrücken. Der Benefit der daraus entsteht ist im Übrigen auch das ein irgendwie unter macOS arbeitendes System auf diese Weise unter macOS nochmal sauberer und weniger Fehleranfällig läuft.