Aber auf dem 2. Gerät funktioniert der Monitor auch unter der selben Ventura-Version?
Beiträge von mhaeuser
-
-
Lad doch mal eine Log von einer DEBUG-Version hoch.
-
denn es ist schon denkbar das der Hash im NVRAM gespeichert ist und irgendwie nicht mehr aktualisiert wird
Nein, das ist eine digitale Signatur im APFS-Volume. Das Fehlerbild klingt nach Speicherkorrumpierung, vielleicht sogar im Buffer Cache. Ganz großes Kino, Apple.
-
Das hat mit OpenCore nichts zu tun. Entweder hat Ventura selbst den Bug eingebaut (in dem Fall muss Apple den beheben) oder der OpenCore Legacy Patcher patchet irgendwas kaputt. Hast du ein Zweitgerät zum Testen? Wann ging der Monitor zuletzt?
-
Hubert1965 Abgelehnte Lösungsansätze habe ich, wie wohl auch einige andere, mehrfach gesehen. Ebenso sarkastische Kommentare, gerade bzgl. Zusammenführung von Threads, wie inhärent unorganisiert das doch sei (was erprobter Weise nicht der Fall ist... so viel zum Thema Senf). Sachen nicht wissen ist in Ordnung, aber die Lautstärke der eigenen Meinung sollte im Verhältnis zur Kompetenz stehen, genau wie die Erwartungen an andere zum eigenen Einsatz. Wäre der Fakt, dass man den EFI-Ordner selbst kopieren muss wirklich so versteckt und kontraintuitiv, würde es im Forum um nichts anderes mehr gehen. Dass eine korrekte Erklärung mit "das ergibt für mich aber keinen Sinn, es wird sicher an <irgendwas Ausgedachtes> liegen" entgegnet wird, ist mir ziemlich sicher auch schon passiert. Es ist frustrierend und wie gesagt, irgendwann ist auch mal gut. Ein Opfer des Forums bist du jedenfalls nicht.
Wie dem auch sei, bzgl. "post installation" - gemeint ist die Installation von macOS. Die Installation von macOS ist abgeschlossen, wenn der Installer macOS installiert hat. Was und ob du danach noch etwas tust, wie zum Beispiel OC auf der SSD einrichten, gehört zu den Dingen, die du nach der Installation von macOS ("post install") erledigst. Das hat schon seine Richtigkeit. Wenn du gute Argumente dagegen hast, kannst du eine Pull Request öffnen.
Bzgl. automatisches Kopieren des EFI-Ordners - es gibt keinen sauberen Weg, wie das funktionieren sollte. OC ist kein Teil von macOS, also wird macOS von sich aus sicher nichts rüberkopieren. OC läuft zur Bootzeit, kann also kein Wissen darüber haben, wohin du macOS installierst oder, wann das abgeschlossen ist - geschweige denn reagieren. Das System im Speicher zu patchen, das automatisch zu erledigen, wäre wirklich angsteinflößend.
Die von Wolfe gezeichneten Infos finden sich schon direkt im Glossar (wenn auch nicht bildlich): https://dortania.github.io/Ope…ll-Guide/terminology.html
Wolfe "BIOS" und "UEFI/EFI/ESP" sind sehr irreführend. "BIOS" müsste "UEFI" und "UEFI/EFI/ESP" müsste "ESP" lauten. UEFI ist die Firmware (eine Ablösung von BIOS) und liegt nicht auf den Festplatten.
-
Dort steht nirgendwo, dass man den EFI-Ordner manuell vom Stick in die neue EFI-Partition muss.
Die wichtigsten Dinge stehen irgendwie immer im Nirgendwo: https://dortania.github.io/Ope…bing-opencore-off-the-usb
Es erscheint mir auch etwas unsinnig, diesen Schritt manuell durchführen zu müssen. Ich vermute, dass bei mir aus irgend einem Grund während der Installation die neue EFI-Partition nicht gemountet wurde, und dass daher dieser Schritt, der eigentlich automatisch geschehen sollte, nicht durchgeführt wurde.
Meintest du nicht mal, dass du immer alles in kleinste Detail recherchierst, bevor du es angehst? Wenn man diesen Schritt unsinnig findet, ist das ein Zeichen dafür, dass man die Prozesse schon in den Grundlagen nicht verstanden hat. Sich dan eine Automatik ausdenken, die es so nicht mal bei Unibeast gab, statt einfach wirklich alle Schritte zu lesen, ist dann auch ein bisschen viel des Guten.
-
CMMChris Was heißt MacBooks deutlich teurer, das Basismodell ist auch von 8C14C auf 10C16C. Gut, bei den CPU-Kernen sind das Effizienzkerne, aber sollte trotzdem gut skalieren. Damit sind die glaube ich sogar ein bisschen günstiger als M1 Pro 10C16C war, aber müsste ich nachschauen.
-
Und was folgt daraus? Gibt es jetzt das tägliche Sicherheit-Update, wo die Apple-Leute nicht einmal ihre grundlegende System-Software richtig pflegen (siehe Link CMMChris )..
Zusätzliches Sicherheit-Tool nennen die sowas. Wo sie doch nach jeder Schadens-Meldung Wochen und Monate brauchen.
- Die aktuellen Security Responses sind Tests für die Infrastruktur, so ist das halt bei einer Beta
- Sie sind gerade dafür da, damit es nicht mehr Monate dauert
- Der System Profiler ist keine „grundlegende Systemsoftware“, kein normaler Nutzer schaut da rein, insb. nicht in der Kext-Kategorie. Die Apple-Kexte fliegen da irgendwann schon raus
-
Ob das das Ende der Leistungssprünge ist, würd' ich mal offen lassen. Zum einen ist Apple neu im Bereich Desktop-GPU und ggf. wird es weitere spezialisierte Chips für die Media Engine geben - die Industrie ist sich relativ einig, dass dieser Ansatz Zukunftsfähigkeit hat. Einfach immer nur die Rohleistung hochdrehen geht nicht ewig gut. Zum anderen kann Apple mit der vollen Kontrolle über das OS vielleicht sogar ein Hardware-Software-Design entwickeln, das bestehende Nachteile von Mehr-CPU-Systemen stark reduziert. Dann bräuchte man keinen großen Chip, bei dem ohnehin fraglich ist, wie er skaliert, sondern kann sie "einfach" dazu stecken. Mal schauen.
-
Die Anzeige müssen die für SLE einfach abschalten, wird schon noch kommen
-
Natürlich würde letzteres die ganzen Speicheranbindungsvorteile durchkreuzen, aber es wäre nicht das erste Mal, dass Apple sich irgendeinen proprietären Slot ausdenkt.
Das Problem an klassischem RAM ist nicht der Slot, sondern die Distanz. Ein proprietärer Slot löst damit gar nichts.
-
DSM2 Unmöglich ist es nicht, wenn sie QoS für heterogenen RAM implementieren. Damit könnte man Speicherkompression und gecachte Dateien eher auf den externen RAM schieben statt zu swappen und den SoC-RAM für Arbeitsschritte freihalten. Passt aber nicht so wirklich in Apples Philosophie, Modularität hat ausgedient.
Aluveitie Einen Chipsatz brauchen die CPUs seit Ewigkeiten nicht wirklich, der ist zum Großteil praktisch ein PCIe-Hub. Naja, Intel ME hockt drauf… -
Enpass hat in bisherigen Audits nicht gerade gut abgeschnitten, die M1-Portierung war langsam, Linux-Flatpak wird nicht unterstützt und die Synchronisierung über iCloud macht immer mal wieder Probleme.
heylogin ist von allen Konzepten m.M.n. klar das beste und dazu noch kostenlos, aber da gab es leider noch gar keinen Audit.
1password ist in Bezug auf Audits wohl sehr vorbildlich.
KeePass ist UX-mäßig und gerade in Bezug auf Browser-Plugins ein heftiger Krampf.
LastPass wird irgendwie alle zwei Wochen gehackt, das muss man auch erstmal schaffen. -
talkinghead Weder OC noch Lilu sind Rootkits, weil sie die Privilegien anderer Software nicht bis kaum erweitern.
-
scheint ja eher eine mobile hacky Geschichte zu sein.
Nein, der Name kommt durch die Portierung von iOS.
-
CMMChris Ich bin nicht so drin in der Apple-Monitor-Welt - wie hoch ist die Wahrscheinlichkeit, dass ein ähnliches Panel in einem LG-Monitor verbaut wird? 5K >60 Hz ist wohl leider nicht Gamer genug für eine gute Auswahl
-
Nun, seit ich diesen Build im Einsatz habe kann ich zwar den Maus im Opencanopy Menü bewegen aber nicht mehr doppelklicken um den ausgewählten Menüeintrag zum starten zu bewegen.
Uups... https://github.com/acidanthera…d8968476d7cdb90d5ea53ff32
-
guckux Lies meinen Satz nochmal - ich habe gesagt, dass der Cache nicht der Grund für die Leistungssteigerung weit unter 100% ist, nicht, dass SMT nichts mit dem Cache zu tun hat.
-
guckux Natürlich bringt SMT nicht die doppelte Leistung, das ist physisch unmöglich und hat auch nichts mit dem Cache zu tun. Das einzige, was SMT ausreizt, sind ungenutzte Ausführungseinheiten. Bei Apple Silicon hat man aber auch ohne SMT einen sehr hohen Durchsatz und eine hohe Anweisungsparallelität, deshalb könnten die Gewinne nochmal spürbar geringer ausfallen.
-
SMT? Ich wäre mir nicht mal so sicher, ob SMT auf Apple Silicon wirklich einen nennenswerten Vorteil bringen würde.
