@StefanStillhart Von mir hast du zumindest keine PN bekommen, nur um das festzuhalten. Hier einen anderen Eindruck vermitteln zu wollen zeugt von nem miesen Charakter. Ich wollte übrigens tatsächlich helfen, aber das spar ich mir zukünftig.
@djdannzen@StefanStillhart Das ist wie ein Unfall in Zeitlupe... man kann nicht wegsehen... oder verhindern.
Ich werd jedenfalls meine Zeit anderweitig einsetzen, anstatt längst eine längst verlorene Schlacht zu retten. Keller ausmisten vielleicht.
Das liegt an den Kopfschmerzen, die wiederholtes mit der Hand vor die Stirn schlagen verursacht. (Sorry, Sarkasmus.)
Ich hatte dir vor einer Woche ein paar Ratschläge gegeben, war heute sogar kurz davor, dir praktisch Hilfe anzubieten. Nachdem auf beides keine Reaktion kam, bin ich davon ausgegangen, dass du kein Interesse daran hast und wollte eigentlich deine Posts fast schon stumm schalten. Stattdessen dieser Appell, weil aller guten Dinge sind drei.
Ich bin mir bei dir nicht ganz sicher, was die Motivation hinter deinen Posts ist. Ob du tatsächlich Interesse an der Entwicklung deines Systems hast oder ob das ganze nur für Social Media herhalten soll. Bei letzterem kann ich dir nicht helfen.
Als jemand, der sich in der IT-Branche auskennt: Irgendwann implodiert dir das Ganze, wegen zu viel Komplexität. Jedes Feature, das du einbauen lässt, macht es schlimmer, einfach weil ein LLM dank beschränktem Context nicht jedes Detail im Blick haben kann. Du kannst versuchen, das zu verhindern, durch präzise Regeln, Vorgaben, Abläufe und Dokumentation, aber es wird den Zeitpunkt nur verschieben, nicht verhindern.
Egal, was du tust: Sorge immer für eine Kopie der Rohdaten, mit denen du alle alle Ergebnisse reproduzieren kannst - und auf die dein LLM keinen Zugriff hat. Damit du im Ernstfall von vorne anfangen kannst. Alles andere spielt keine Rolle.
Verlange von deinem LLM Tests für jedes Feature ("test driven development, TDD", Unit- und Integration-Tests), lass immer wieder die gesamte Struktur analysieren und nach Inkonsistenzen suchen (z.B. "Datenbank Normalisierung"), sorge für "refactorings" um die Schwächen zu beseitigen und lass dir jedes Feature, jeden Change, jede Schnittstelle, dokumentieren (im Repo und in den LLM-Memories, am Ende jeder Session) - auch wenn das ganze wie Zeit- und Tokenverschwendung aussieht. Damit kannst du den Zeitpunkt weiter verzögern. Repo- und Datenbank-Backups zu haben rettet dich, wenn der Zeitpunkt da ist und dein LLM Amok läuft.
Viel Glück.
Wir haben hier Meinungsfreiheit, zumindest auf dem Papier. Die gilt für jeden, egal ob links, rechts, arm oder reich. Nennt sich auch Gleichberechtigung.
So wie du die Meinungen anderer als Hass interpretierst, könnten andere deine Meinungen ebenfalls als Hass interpretieren - Hass auf alles, was nicht der eigenen Meinung entspricht. Oder als fehlende Toleranz. Was übrigens das ist, was Linke gerne von anderen fordern.
Ich werde mich weiterhin dafür einsetzen, dass jeder Mensch seine Meinung frei, ungehindert und ohne Angst vor Konsequenzen äußern kann.
Kannst du das auch?
@OLBJAN Süd-Ost-Ost. Aber ich habs mir fast gedacht.
Trotzdem wär ne Zahl interessant. So als grobe Hausnummer. Damit ich bei ner eventuellen Wohnungssuche drauf achten kann - oder halt eben nicht.
Als jemand, der sich in der IT-Branche auskennt: Irgendwann implodiert dir das Ganze, wegen zu viel Komplexität. Jedes Feature, das du einbauen lässt, macht es schlimmer, einfach weil ein LLM dank beschränktem Context nicht jedes Detail im Blick haben kann. Du kannst versuchen, das zu verhindern, durch präzise Regeln, Vorgaben, Abläufe und Dokumentation, aber es wird den Zeitpunkt nur verschieben, nicht verhindern.
Egal, was du tust: Sorge immer für eine Kopie der Rohdaten, mit denen du alle alle Ergebnisse reproduzieren kannst - und auf die dein LLM keinen Zugriff hat. Damit du im Ernstfall von vorne anfangen kannst. Alles andere spielt keine Rolle.
Verlange von deinem LLM Tests für jedes Feature ("test driven development, TDD", Unit- und Integration-Tests), lass immer wieder die gesamte Struktur analysieren und nach Inkonsistenzen suchen (z.B. "Datenbank Normalisierung"), sorge für "refactorings" um die Schwächen zu beseitigen und lass dir jedes Feature, jeden Change, jede Schnittstelle, dokumentieren (im Repo und in den LLM-Memories, am Ende jeder Session) - auch wenn das ganze wie Zeit- und Tokenverschwendung aussieht. Damit kannst du den Zeitpunkt weiter verzögern. Repo- und Datenbank-Backups zu haben rettet dich, wenn der Zeitpunkt da ist und dein LLM Amok läuft.
Viel Glück.
Yeah... this is a nothingburger.
There's basically no cloudprovider running qemu with cxl enabled or configurable to the user. No attack surface.
The QEMU security policy actually addresses this: not every QEMU code path is considered a security boundary, and experimental device models often aren't. CXL Type-3 emulation is pretty firmly in "experimental, for development" territory. So, congratulations. You found a bug in a new, experimental device model, that's not in use anywhere.