Beiträge von apfelnico

Zitat von Nordel

Hast du dich verschrieben

Nein. Eine 7800 HD ist ein extrem altes Brett und passt gut zur Ivy-Bridge CPU. Du meinst eine "RX 7800 XT", ganz andere Nummer.

BioMac

Ich glaube, Catalina ist für die angestaubte Hardware ein sinnvolles macOS.

M4 Pro und M4 Max sind verschiedene Modelle. Dazu kommt, der Studio hat mehr Thunderbolt Ports etc.
Insofern tatsächlich der bessere, und letztendlich günstigere (!) Rechner, bezogen auf Ausstattung.

Ich vermute mal, es soll kein (wenn der überhaupt kommt) M5 Ultra sein.
Wenn also auch kein M5 Max und ein M5 Pro reicht, dann nimm einen Mac Mini. Den gibt es übrigens auch aufpreispflichtig mit 10GbE. Wenn MacStudio, dann käme für mich nur der Ultra in Frage, möglicherweise noch der Max.

Der MacPro ist Apples einziges Gerät mit frei zugänglichen PCIe Steckplätzen. Somit von Hause aus der flexibelste Mac, was ihn als ideale Grundlage fürs SMBIOS des Hackintoshs macht.

Nee, immer nur MacPro. Ganz zu Anfang gestartet mit iMacPro.

H.264 geht auch super schnell raus, aber H.265 eben schneckelangsam. Aber im Sage stecken ja auch noch die mittlerweile richtig alten zwei Radeon7 drin. Hatte ich nie aktualisiert. Der MacStudio macht einfach mehr Spaß. Kleine Keksdose, verbraucht nix und lärmt nicht, ein Träumchen.

Ja, das geht natürlich. Hab ich ja auch lange gemacht mit DaVinci Resolve Studio und dem Sage10G. Nur eben sehr langsam.

Afterburner beschleunigt ausschließlich QuickTime ProRes. Hat mit H.265 in 10bit nun gar nichts zu tun.

Oh, das wäre was. Wobei, es gibt ja auch den „aktuellen“ MacPro mit Apple Silicon. Der kann das natürlich. Sieht von außen aus wie ein MacPro7.1.
Aber wenn es der Intel auch kann, wer mag sich damit noch auseinandersetzen, das zu erforschen und zu übertragen?

Zitat von ShadowMatser

Ich kann in Final Cut Pro keine Videos in H.265 / HEVC (8-bit und 10-bit) exportieren. In anderen Programmen wie DaVinci Resolve funktioniert zumindest 8-bit HEVC.

Ja, das ist frech von Apple. Kennt man auch von echten MacPro 7.1 (Intel) und dortigen Grafikkarten. Obwohl die das in Hardware beherrschen, wird es nicht genutzt. Soll wohl die Überlegenheit von Apple Silicon zeigen. Klar freue ich mich über die Ausgabe meines Mac Studios, weiß aber, dass eigentlich mein Hacki auch nicht schlecht abschließen würde. Ausgabe am Intelmac auch mit potenter Grafikkarte in HEVC nur über Software, kein Hardware-Encoding. Decoding ist natürlich freigeschaltet.

Zitat von BioMac

In den OC Kext-Ordner kopieren, bringt leider auch nix.

Bringt schon etwas, aber nur die "halbe Miete", es reicht noch nicht. Du musst die KernelExtension auch via config.plist einbinden, damit OpenCore diese lädt. Schau dir an, wie andere, schon vorhanden Kexte eingebunden sind und erstelle dort einen neuen Eintrag.

Es gibt nach wie vor die einzelnen, einmalig bezahlbaren Varianten als Universal-App. Die Icons der Versionen des Pakets sehen aber anders aus, beinhalten mehr KI-Funktionen und sind offenbar reine Apple Silicon Apps. Deutlich bei Pages und Co zu sehen. Im verlinkten Support-Dokument ists auch klar ersichtlich, nur Apple Silicon. Es wird langsam eng. Wer neuesten Scheiß von Apple will, kommt nicht drum rum.

Zitat von lev92

-amfipassbeta hat Abhilfe geschaffen.

Sehr gut. Ein -lilubetaall hätte wahrscheinlich auch funktioniert, es wäre für lilu und darauf angewiesene Kexte global gesetzt. Und ab einer bestimmten kompilierten Version von lilu gar nicht mehr nötig. Hier können (relativ) aktuelle Kexts und OpenCore bezogen werden: https://dortania.github.io/builds/

Zitat von lev92

Verstehe aber immernoch nicht, warum das Apple Creator Studio nicht verfügbar ist.

Im App Store steht "Not compatible" Online

https://support.apple.com/de-de/125029

Für diese Versionen benötigst du laut Support Apple Mx Prozessoren. Nur Tahoe reicht nicht. Teilweise läuft es ja schon unter macOS 15.6.

Zitat von Wolfe

Die Kexte sind laut Saschas Kextupdater sämtlich auf dem neuesten Stand.

Da werden natürlich SOWOHL Kexte nach letzter Veröffentlichung, SOWIE neu kompilierte mit letzten Veränderungen, aber noch nicht veröffentlicht, als neuester Stand bewertet. Kann also gut sein, dass bestimmte Betaversionen von Kexten letztendlich das bemängelte Bootargument obsolet machen. Aber ich will mich da nicht so weit ausm Fenster hängen, nur so eine Idee aus der Ferne. Und vielleicht ist unsere Konversation ne Einladung für die Leute, die es genau wissen, ihr Wissen zu teilen. Ich bin immer noch zumindest davon Überzeugt, dass für ein installiertes Tahoe dieses Bootargument nicht vonnöten sei, und das es schädliche Auswirkungen auf bestimmte Apps hat. Bei mir läuft mit dem Bootargument zum Beispiel nicht eine App zur Konfiguration meines Pegasus 32 Thunderbolt R8 Raids. Da wird, obwohl gemountet, kein Laufwerk zur Konfiguration gefunden. Ohne Bootargument klappt alles wie es soll.

Edit:

Auch OpenCore 1.0.7 kann natürlich, da noch gar nicht als Release vorhanden, auf einem Stand sein, das nicht dem "aktuellen" Build entspricht, wenn man es jetzt kompilieren würde. Zum Beispiel erfolgt üblicherweise kurz nach dem offiziellen Release ein "Bump to Version x.x.x". Das wäre dann die frühstmögliche Version 1.0.7. Selbstverständlich, wenn noch keine weiteren Änderungen vorgenommen wurden, auf dem Stand von 1.0.6. Bis heute ist natürlich da wieder einiges passiert (selbiges gilt bei den Kexts) …

Zitat von MPC561

Alleine das meine Netzwerkfavoriten nicht mehr automatisch geöffnet werden wenn ich auf einen Favoriten Link im Finder Klicke, sondern das ich jeden Share von meinen Servern manuell öffnen muss ist schon...

Ich hab sogar bei 26.0 ein Ticket geschrieben aber die Pfeifen in Cupertino brauchen es wohl nicht das Netzwerkshares automatisch gemountet werden. In 26.2 immer noch nicht korrigiert.

Ich habe mir etwas geschrieben, funktioniert prächtig. Damit werden zwei Laufwerke eines NAS via NFS automatisch gemountet. Per Automator eine App erstellt, die ein integriertes Shell-Script abfeuert. Diese App dann per "Anmeldeobjekt" automatisch starten lassen.

In Automator eine App erstellen, diese soll die Aktion "Shell-Skript ausführen" beinhalten. Als Shell "/bin/zsh" festlegen, Eingabe übergeben als "An stdin". Inhalt des Skripts:

Oben in der Sektion "Konfiguration" habe ich zwei Ziele definiert, es können in diesem Array beliebig viele definiert werden, einfach durch Leerzeichen getrennt. Wichtig, es müssen natürlich Reihenfolge wie Anzahl bei "NFS_SHARES" und "MOUNT_POINTS" korrelieren. "NAS_IP" sollte auch klar sein. Hier sieht man auch wunderbar, dass man dem Mountpoint auch durchaus einen anderen Namen geben könnte, gegenüber dem Freigabenamen des Netzlaufwerks/Ordner.

Zunächst hat das nicht zufriedenstellend geklappt, weil zur Zeit, während diese App von macOS gestartet wird, noch nicht vollständig die benötigten Ressourcen bereitstehen. Habe zuerst eine "Pause" eingefügt, fand später aber die Idee mit dem Ping sinnvoller. Hier wird nur die Zeit veranschlagt, die tatsächlich notwendig ist. Das Dingen pingt also das Ziel an und sobald dieses sich meldet, wird der Rest abgefahren. Pingt alle Sekunde einmal innerhalb von 30 Sekunden. Kann man ändern im Script. Beim eigentlichen Befehl mount muss man schauen, welche Optionen konkret benötigt werden.

Wichtig: bei diesem Script wird sudo benötigt, aber es läuft automatisch ab ohne das ich Eingaben (Admin-PW) vornehmen kann. So wie es ist, wird es also nicht funktionieren.

Es sei denn – hier kommt eine Einschränkung hinsichtlich Sicherheit – man bearbeitet die etc/sudoers und hebt für die benutzen Befehle oder gänzlich die Eingabe eines PW bei Nutzung von sudo auf.

Zur Bearbeitung (mit nano als Editor) kann folgendes ins Terminal getippt werden: sudo EDITOR=nano visudo

Hier könnte nun in der Zeile (weiter unten) beginnend mit "%admin" folgendes stehen:

%admin ALL = (ALL) NOPASSWD: ALL

Nun mit control+o und Enter sichern sowie mit control+x schließen (nano).

Achtung, wenn ihr euch nicht sicher seid, dann lasst es.

Edit: Intension bei mir war, dass es zum Ersten bei mir auch nicht klappte, Netzlaufwerke automatisiert wie früher einzubinden, zum Zweiten, dass das Standardprotokoll SMB grottig langsam ist (ob das nun an Apple Implementierung oder am Overhead des Protokolls an sich liegt, Rechtemanagement etc ist mir Wurscht), daher habe ich NFS benutzt, welches mir das NAS auch bereitstellt. Zusammen mit 10GbE, Jumboframes und weiteren Optimierungen konnte ich Zugriff (Lesen und Schreiben) dramatisch steigern.

Zitat von Noir0SX

-lilubeta wird dir dabei nie helfen, bei -lilubetaall hingegen wird nicht nur Lilu sondern auch die Plugins der nicht unterstützen Version bekannt gemacht

Da hast du recht, das meinte ich auch. War nur so aus 'm Kopp, bin unterwegs.

Zitat von Wolfe

Levs EFI und meine seien identisch.
Bei mir ist AMFIPass.kext in Version 1.4.1. im Ordner Kext vorhanden und in der config.plist eingebunden und aktiviert. Mit amfi=0x80 startet Tahoe erfolgreich, ohne bleibt es im Ladebalken hängen bei ca einem Achtel oder Zehntel. Ohne amfi=0x80, mit -lilubeta bleibt er wie der screenshot im Verbosemodus zeigt beim Ladevorgang hängen.

Dann prüft doch beide mal, ob ihr jeweils aufm neuesten Stand seid mit OpenCore und allen anderen Kexts. Ich meine, dass "amfi=0x80" die Holzhammermethode ist und AMFI komplett deaktiviert, was empfindliche Auswirkungen auf System und Apps hat. Und eigentlich nicht nötig sei, da das was erreicht werden soll, auch via amfipass.kext geleistet wird. Lediglich bei Systeminstallation kann es hilfreich sein. Möglicherweise schreib ich aber auch Unfug, merke das ich nicht mehr so tief drin stecke, seit ich größtenteils wieder mit Macs arbeite. Mein SAGE10G läuft nebenan als zweiter Schnittrechner mit Tahoe, da ist es so wie ich schrieb. Ständig rumfummeln mache ich nicht mehr, ratzfatz ist das erworbene Wissen dazu wieder weg.

Mit „amfi=0x80“ holst du dir solche Probleme rein. Es ist, wenn überhaupt, nur während Installation System notwendig. Die amfipass.kext sollte reichen. Die muss natürlich nicht nur vorhanden sein, sondern auch eingebunden und laufen. Check dein OpenCore und Treiber und Kexte, ob neueste Version. Möglicherweise ist noch ein lilubeta zielführend.

Hast du ne amfipass.kext eingebunden? Ist besser, dann amfi=0x80 raus.

So soll es sein. Ziemlich genial beim Mac. System an/in anderen Mac stecken, läuft. Bei uns Hackies kommt noch der individuelle EFI-Ordner mit OpenCore hinzu. Und je nach System eben Patches für spezifische Hardware.

Eine Variante, wie man zum Beispiel die originale Festplatte des Finders als hochwertige Grafik bekommt:

Festplatte aufm Schreibtisch anwählen, "Cmd+i" drücken oder rechte Maustaste, Informationen. Dort sehen wir oben links ebenfalls das Icon. das anwählen und mittels "Cmd+c" kopieren.

Nun zum Beispiel Apples Vorschau starten, "Neu aus der Zwischenablage" aus dem "Ablage"-Menü wählen, oder einfach "Cmd+n", dann die oberste Grafik "exportieren" (ebenfalls im "Ablage"-Menü) als PNG inklusive Alpha (Transparenz).

Gibt viele weitere Möglichkeiten und natürlich kann man die Zwischenablage auch direkt in Affinity einfügen mittels Cmd+v.

Ring und Festplatte würde ich nicht „freistellen“, sondern es gibt die Festplatte auch einzeln, bereits freigestellt. Ring dazu neu erstellen inklusive Verlauf und Schatten, Inhalt dann passend dahinter.

Ob 72 oder 144 dpi kann in der Verarbeitung zunächst Wurscht sein, Hauptsache die Auflösung der Gesamtmaße in Pixeln der Vorlage/ Bearbeitung ist ausreichend.

Den angesprochenen Screenshot fand ich insofern tatsächlich hilfreich, dass neben viel Werbung zumindest eine für mich wertvolle Information enthielt, wie man passende Varianten des Icons in welchen Größen als PNG in einen Ordner packt, um dann mit einem hauseigenen Befehl per Terminal daraus das Icon erstellen lässt. Kostenlos, nicht eine, sondern alle relevanten Größen integriert, korrekte Syntax. Das in Verbindung mit dem kostenlosen Affinity und dem Wissen, wie man aus diversen Quellen/Apps hochwertige Grafikvorlagen/Bestandteile fürs weitere Bearbeiten rauspopelt, sollte doch die Eingangsfrage mehr als exzellent beantworten.