Posts by mhaeuser

ST3R30 Okay. Wissen wir denn, was abgeht? https://www.independent.co.uk/…vestigation-b2937456.html
Bis eine seriöse Evaluation vorliegt, dünnes Eis.

Musst einfach nur die .efi-Dateien mit den RELEASE-Versionen ersetzen, alles andere bleibt gleich. Da du die Version kennst, kannst du auch einfach md5sum laufen lassen und vergleichen.

ST3R30 Uff, das crazy. Und da meinte meine Nichte letztens noch, ich wäre nur fast alt. Mein Vater meinte auch schon, ich mach’ vielleicht einfach die “Troms” falsch…

Atalantia Es gibt auch nicht die eine richtige. ProperTree z.B. kann sie den Abhängigkeiten nach anordnen.

griven Jein, jetzt ist es interaktiv und kann auf ALLES eine Form von Antwort geben, das macht es wirklich viel gefährlicher.

Ein Freund aus den USA hatte letztens mit einem ChatGPT-Experten zu tun, der beachtliche 30 Minuten mit der KI im Kameramodus diskutiert hat, wie dieses Kinderschloss Richtung Haustür aufgeht, obwohl es offensichtlich jedes Mal eine falsche Antwort gab. Ich glaube, in 30 Minuten sollte jeder Erwachsene, der das Stadium menschliches Gemüse überschritten hat, so ein Schloss aufbekommen (oder schon lange vorher den Besitzer gefragt haben). Stattdessen ist er dann durch die Hintertür raus.

Ich hatte auch schon Studierende, die überzeugt waren, die (natürlich entweder falsche oder viel zu oberflächliche) ChatGPT-Erklärung zu verstehen und beim Erklären dieser hatten sie einen mentalen BSoD und es kam fast schon Buchstabensuppe raus.

Bei der Presse und im Internet hat man auch noch den Vorteil, dass sie relativ zentral sind. Relevant Falschmeldungen werden regelmäßig von seriöseren Quellen korrigiert und das bekommt man als Normalsterblicher auch mit (ob man es annimmt, ist eine andere Frage). KI-Halluzinationen entstehen sehr lokal, schnell, personalisiert und verbreiten sich dann durch heftig Algorithmus-selektierte Zielgruppen, die fast schon von der Außenwelt abgeschnitten sind. Bei einer Google-Suche findet man schon noch die Tagesschau oder namhafte Zeitungen. Auch, wenn sie “gleichgeschaltete Lügenpresse” sind, setzt man sich kognitiv irgendwie damit auseinander, wenn auch nur sehr kurz. Mit KI + TikTok wird man praktisch nicht mehr mit der Realität konfrontiert.

Außerdem haben viele Leute nicht mehr nur eine emotionale Verbindung zum jeweiligen Inhalt, sondern jetzt auch zum Chatbot selbst, der dann auch ein “persönliches Vertrauen” statt nur ein autoritäres bekommt.

Das ist schon eine andere Hausnummer. Es ist das selbe Prinzip, aber wirklich ad absurdum geführt…

Diese LLMs kann man generell nur bei Themen nutzen, bei denen man schon eine gute und zuverlässige Intuition hat. Ich nutze sie mittlerweile auch immer häufiger, aber fast ausschließlich als optionalen “fast path”, um schnell Dinge zu finden (Stellen in Code, Dokumentationen, …) oder, um einen gröbsten Überblick über Konzepte und deren Zusammenhänge zu bekommen. Mindestens in jeder zweiten Antwort ist ein wirklich fundamentaler Fehler drin, den ich aber eben auch schnell als solchen erkenne. Tut man das nicht, verliert man mit den LLMs teils sogar Zeit oder richtet eben Schaden an. Für das Einarbeiten in eher unbekannte Themen mit einer gewissen theoretischen Tiefe sind alle von denen nicht zu gebrauchen.

MacGrummel Vielleicht etwas off-topic, ich habe übrigens dasselbe Problem mit einer externen SSD + C-auf-A-Adapter am Router - eine Richtung ist USB 2.0, die andere USB 3.0. Verrückte Welt.

utilman Ich weiß nicht, welcher Untergrund das sein soll, aber als Mitentwickler von Clover, Ozmosis und OpenCore muss ich den wohl übersehen haben. Wenn es eine Möglichkeit geben “muss”, ein ARM-Betriebssystem auf beliebigen anderen Architekturen laufen zu lassen, bin ich ganz Ohr. Dann haben wir die Softwarekompatibilität auf ARM-Windows und -Linux gleich mit gelöst…

griven Ich glaube, es geht da eher um die sehr großzügigen Rundungen. Die DE-abhängigen Kosten sieht man am ehesten bei den AirPods Pro, v1 279 €, v2 299 €, v3 249 €… in den USA konstant 249 USD. Bei den APP wird die Marge vergleichsweise niedrig sein, daher die “tagesaktuellen” Sprünge, die es bei den Kernprodukten nicht gibt. Es ist aber durchaus üblich (und nicht nur bei Apple), die Marge eben nicht über die Märkte konstant zu halten, sondern an das Zielpublikum anzupassen. Am Ende nörgeln wir irgendwo darüber, dass wir zu reich sind…

karacho Naja, OCLP hat natürlich ganz andere Gründe als OC. Bei OCLP gibt es einen “Personal-/Zeitmangel”, bei OC gibt es einfach nicht viel zu tun. Läuft ja alles soweit. Unabhängig davon ist natürlich mit Tahoe Schluss.

Übrigens ist “Intel interessiert sie nicht mehr” nicht wirklich der Grund für die schlechte Software, ich hab auch auf dem M3 Pro genug Bugs. Müsste ich raten, liegt es am Auftrag zu Liquid Glass aber mit finanzieller Priorität auf KI und Lieferketten. Ich hoffe, die Gerüchte von “Snow Leopard” macOS 27 stimmen.

apfelnico Wenn du schonmal gehört hast, dass man proprietärer Software ja nicht trauen kann, weil sie ja nicht Open Source ist und man nicht "nachschauen" kann - kompletter Unfug.

Das ist jetzt natürlich sehr vereinfacht, aber im Endeffekt ist die Assemblyausgabe wie eine kompliziertere Version des Programmcodes ohne Variablennamen. Funktionsnamen gibt es teilweise, weil sie in den Symbolen zum dynamischen Linken (z.B. DLLs) und/oder in Debuggingcode enthalten sind. Viele Dinge erscheinen erst obskur (z.B., wenn Bibliotheksfunktionen praktisch in die aufrufende Funktion komplett hinein kopiert und integriert werden, "inlining"), folgen aber am Ende berechenbaren Mustern und die werden schnell zum Three Cord Song. Muss man einfach mal gesehen haben. IDA Pro bietet z.B. mittlerweile musterbasierte Erkennung von häufig verwendeten Bibliotheksfunktionen an.

Decompiler übersetzen dir Assemblyschnipsel in C-ähnliche Funktionen. Sieht man, wie unbenannte Variablen oder Funktionen verwendet werden (z.B. wenn Standardaufrufe wie I/O benutzt werden), kann man sie benennen und das ganze von unten nach oben aufrollen. Mit beliebig viel zeitlichen Ressourcen ist es kein Problem, eine (funktionell) exakte Kopie der Ursprungssoftware zu schreiben. Ist natürlich verdammt aufwendig.

Mieze Überflogen habe ich nichts, der Satz mit Netzwerktreiberbeispiel bezog sich direkt auf meinen HFS+-Kommentar und damit ist das mindestens missverständlich (für Außenstehende). Wenn das so gemeint war, dann hab ich nichts gesagt (bzw. doch, der Rest des Posts greift trotzdem identisch).

Mieze Das potentielle Verschieben eines antiquierten Dateisystems ins Userland kann mit Sicherheit nichts zu tun haben, weil es einen neuen Netzwerktreiber im Kernel gibt und die Entwickler ein bisschen rumgepfuscht haben. Ich kann langsam nicht mehr. Natürlich kommen ungeliebte Technologien ins Userland, gerade wegen des Sicherheitsaspekts - muss man sich weniger Mühe mit geben. Und die API bleibt stabil, während sie im Kernel flexibler werden kann. Und es steht ja nicht mal fest, ich habe doch nur geraten, warum es bzgl. HFS+ auf einmal Bugs geben könnte.

MacGrummel Mein Post ging doch in die komplett andere Richtung. Apple programmiert ausschließlich für die eigene Hardware und Apple hat im Detail nicht die höchsten Qualitätsstandards. Ist nichts Neues und erst recht nicht erst seit Apple silicon. Wie man daraus Jahr für Jahr eine persönliche Agenda der Führungsriege gegen ein fast schon bedeutungsloses Hobbyprojekt machen kann, entbehrt sich mir dieses Jahr zum Glück zum letzten Mal.

Bzgl. OpenCore gab es übrigens beidseitige Rücksichtnahme und Kompromisse. Man kann mir als jemandem, der direkte und indirekte Apple-Kontakte (ge)pflegt (hat) und die Interna diesbzgl. kennt einfach mal glauben - oder eben auch nicht. Dinge kritisieren ist doch ok, aber hier werden derart abwegige Schlüsse gezogen, dass das doch fast nur Ragebait sein kann.

Wieso wird immer sofort los gewettert? X.4 sind seit Jahren “Halbzeitmeilensteine”, wo nochmal gut im Unterbau rumgerührt wird (oft gerade im GPU-Bereich, Whatevergreen hat es manchmal gut abbekommen). Der HFS+-Bug kann alle möglichen Gründe haben, von Änderungen an einem Kernelinterface bis hin zu FSKit-Experimenten (würde mich nicht wundern, wenn HFS+ wie FAT32 als Legacy demnächst ins Userland verbannt wird). Gefühlt will man gerade zu vom bösen Apple unterdrückt werden, das sich nach der eigenen Hardware richtet und sich in einer Beta 1 moderate UX-Bugs erlaubt.

Für das Ärgern von Hackintoshern läuft es im Preboot erstaunlich stabil. Die letzte ärgerliche Änderung in OpenCore gab es in macOS 13.

karacho Moreover, nothing changed from what I explained 6 years ago - OC’s architecture is not designed for in-FFS use (no, the kernel starting is not an indication that it is “working”), and even if it was, firmware is not designed for such an interruption of its routine (Oz integrated with the vendor BDS and inherited its terrible bugs, OC substitutes it). May work, may not, may break with firmware updates, may break if BDS assumptions are violated only under specific circumstances, etc. And the gain? Well, nothing, really…

Vor ein paar Jahren war eine der am wenigsten schlimmen Linux-Distros für neue Hardware Fedora. Bei meinem X370/3700X-Setup sorgte PulseAudio für mehrere Probleme, die sich mit Finetuning nur minimieren aber nicht beheben ließen. Fedora (nimmt sich nicht viel ggü. z.B. OpenSUSE Tumbleweed) implementiert Neuerung deutlich schneller als andere Distros mit Releasezyklus und in diesem Fall hatte pipewire sämtliche Probleme behoben.

“Stabil” heißt in der Softwarewelt nicht “ausfallsicher” sondern “konsistent im Verhalten”. Es werden viel seltener neue Bugs eingeführt, aber alte Bugs und Limitierungen auch nur selten adressiert. Muss man für das eigene Setup abwägen.

Azteca Welche Kritik? Der jedem erfahrenen Entwickler offensichtliche Fakt, dass sich sowas mit LLMs nicht schultern lässt, ist ein Hinweis zum Vorgehen. Wenn dir (wie mir letztens) im Baumarkt vom Fachmann gesagt wird, dass du mit einer Hieb-3-Feile nicht weit kommst, bekommst du dann auch einen Trotzanfall und lädst ihn zu dir nach Hause ein, er soll selber machen? Ich habe eine Hieb-2 dazu geholt und habe es nicht bereut, ganz ohne zertrümmertes Ego. Danke, Herr Fachmann!

Im “Prototypen” von InsanelyMac waren doch schon im reinen Boilerplate-Code halluzinierte APIs und oben ging es auf einmal um Kernel-Header, obwohl der einzige Existenzzweck von DriverKit der Umzug weg vom Kernel ist. Jetzt auf einmal wird eine Firmware von einem Gerät ohne persistenten Speicher extrahiert. Sowas muss einem auffallen, wenn man weiterkommen will…

DerBeste Das ist jetzt wirklich nicht böse gemeint, aber probiere doch, die Sache ordentlich zu lernen. LLMs sind nicht auf dem Level, realistische Treiber zu entwickeln. Wenn ein erfahrener Entwickler alles vorkaut, kommt vielleicht wenigstens etwas raus, aber so nicht. Ich mache gerade Compilerentwicklung - deutlich angenehmer als Treiberentwicklung - und nichtmal dort sind die LLMs eine große Hilfe, wenn es nicht gerade um Boilerplate oder sehr isolierte Bugs geht.

Außerdem ist so der Lerneffekt fast 0. Deine Posts widersprechen sich immer wieder und dir fällt es entweder nicht auf oder es ist dir egal (wäre schade). Den allgemein bekannten Fakten wie der FW-Geschichte von schrup21 widersprechen sie ebenfalls. Erst gibt es einen halbfertigen Prototypen, der lädt, dann auf einmal können DriverKit-Treiber gar nicht geladen werden, dann geht es auf einmal doch wieder. Ich hoffe, das fällt nicht nur mir auf.

Es gibt kompetente Netzwerkentwickler wie Mieze in der Community und es täte allen gut, eher auf sie als auf halluzinierende KIs zu hören. Soll jeder sein Lieblingsspielzeug nutzen, aber meine Studiokopfhörer machen mich auch nicht zum Spezialisten für Mix&Master…

MacGrummel Selbstverständlich können neue Treiber geladen werden. WiFi ist nur keine unterstützte Geräteklasse - jeder Mac hat bereits WiFi, also wird in die Richtung keine Arbeit gesteckt. Inwieweit es “unmöglich” ist im Vergleich zu den alten Ethernet-Emulatoren, weiß ich nicht - wenn es an mach_types.h scheitert, muss man wohl auf das nächste tolle LLM warten.

Mieze Vom Linux-Kernel höre ich viel Gutes, habe aber noch nie wirklich damit gearbeitet. In jedem anderen “größeren” Projekt, mit dem ich zu tun hatte (EDK II, GRUB, systemd-boot, iPXE EFI, GNU-EFI, Shim, git, rEFInd, Clover, OpenCore/AUDK(!!), rustc, …) steht Schmerz an der Tagesordnung - gelegentlich auch von mir verursacht. Wenn du das alles unter “heiße Nadel” (ist auch regelmäßig der Fall, so ist es nicht) kategorisierst, kann man machen, ist aber dann nur bedingt aussagekräftig. Vielleicht ist Linux auch der eine heilige Gral, mit dem ich eben noch nicht konfrontiert war. Aber, wie in den meisten anderen Ingenieursfeldern ist offensichtlich auch in der Informatik eine Mischung aus Vorsichtsmaßnahmen und etwas Demut angebracht.

(Ein benutzbares Linux-Userland ist mir auch noch nicht untergekommen, Kernel hin oder her…)

Mieze War die Erklärung nicht einfach ChatGPT?

Wie auch immer, Treiber im Userland sind eine weitgehend objektiv gute Sache. Was du wetterst, stimmt natürlich alles, ist aber auch eine Niche. Die meisten Treiber haben keine derartigen Performanceanforderungen. Je nach Geräteklasse und Design könnten Kontextswitches sogar verringert werden. Für die Netzwerkdomäne ist das natürlich ein eher ungünstiges Model. Ich frage mich aber generell, wie Benchmarks unter Apple Silicon aussähen.

Gut programmierte Treiber brauchen das nicht… jo und gut designte Hardware mit gut programmierter Software brauchen auch kein Segmenting, RELRO oder Stack Canaries. Korrektheit bei realistischer Software, gab’s nicht, gibts nicht und wird es erstmal nicht geben, fertig. Hände hoch, wer unter Windows noch keinen Bluescreen wegen irgendeinem OEM-Treiber hatte. Oder Privilege Escalation…