[{"content":"Warum die führenden KI-Labore womöglich an die Börse drängen, bevor ihr einziger Vorteil verschwindet Über die führenden KI-Unternehmen lässt sich eine bequeme Geschichte erzählen und eine unbequeme. Die unbequeme ist rein struktureller Natur. Sie verlangt niemandem eine Lüge ab. Sie verlangt nur, dass die Zahlen sich weiter so verhalten, wie sie es bisher tun. In dieser Lesart rennen die Spitzenlabore nicht der Profitabilität entgegen, sondern dem Ausstieg — weil das Zeitfenster, in dem sie auch nur annähernd ihre Bewertung wert sind, schmaler sein könnte, als irgendjemand offen auszusprechen bereit ist.\nDie Bewertung und die Lücke dahinter Man beginnt am besten bei den Ausgaben. Das Training und der Betrieb von Frontier-Modellen sind erschreckend teuer: Rechenleistung, Energie, der Aufbau von Rechenzentren und die Gehälter einiger tausend Menschen, die verlangen können, was sie wollen. Das nötige Kapital bemisst sich nicht in Millionen, sondern in zweistelligen Milliardenbeträgen.\nAnthropic hat Mitte 2026 vertraulich den Börsengang eingereicht — bei einer Bewertung von annähernd 965 Milliarden Dollar, also nahe der Billionenmarke. Kurz zuvor hatte das Unternehmen rund 65 Milliarden Dollar eingesammelt, eben zu dieser Bewertung. Dem gegenüber steht eine Umsatz-Run-Rate von etwa 47 Milliarden Dollar im Mai 2026 — gegenüber rund 10 Milliarden ein Jahr zuvor. Der Umsatz ist also real und wächst rasant, bleibt aber ein Bruchteil dessen, was die Bewertung rechtfertigen müsste. Dieselbe Form wiederholt sich über die gesamte Branche: Was hineinfließt, übersteigt bei Weitem, was herauskommt, und die Lücke wird durch einen Glauben finanziert — den Glauben, dass der Vorsprung, den diese Unternehmen heute halten, sich irgendwann in dauerhaften, verteidigungsfähigen Gewinn verwandelt.\nDieser Glaube ruht auf einer einzigen tragenden Annahme: dass das Vorderfeld ein Burggraben sei. Ist es nicht. Genau das sollte den Investoren den Schlaf rauben.\nEin Produkt ohne Lock-in Man halte sich vor Augen, was Software-Imperien früher dauerhaft gemacht hat. Windows und Microsoft Office waren nicht unschlagbar, weil sie die bestmöglichen Produkte waren. Sie waren unschlagbar wegen der Wechselkosten und der Netzwerkeffekte. Die Dateien lagen in deren Formaten, die Kollegen nutzten dieselben Werkzeuge, Muskelgedächtnis, Makros, IT-Abteilung und Schulungsbudgets steckten allesamt in einem bestimmten Ökosystem. Der Wechsel war teuer — auf eine Weise, die mit der Qualität der Alternative nichts zu tun hatte.\nGroße Sprachmodelle haben fast nichts davon. Aus Sicht des Käufers ist ein Modell eine austauschbare Komponente. Wer ein vernünftiges Harness gebaut hat — das Gerüst, die Prompts, das Retrieval und das Tooling rund um das Modell —, kann das Modell darunter mit vergleichsweise geringem Aufwand austauschen. Gebunden ist man an die eigene Infrastruktur, nicht an die des Anbieters. Damit gibt es nur einen einzigen Grund, für ein Frontier-Modell einen Aufpreis zu zahlen: dass es gerade jetzt, für die eigene Aufgabe, spürbar besser ist — und zwar deutlich genug, um ins Gewicht zu fallen. In dem Moment, in dem eine günstigere Option gut genug ist, hat der Aufpreis keine Verteidigung mehr.\nDeshalb ist der Frontier-Vorsprung so fragil. Er ist keine Mauer, sondern ein Vorsprung von wenigen Monaten, der kontinuierlich erodiert und mit jeder Veröffentlichung neu erkämpft werden muss.\nDie Kommodifizierung ist bereits da Der deutlichste Beleg dafür, wie flach der Burggraben ist, liegt darin, woher die Konkurrenz kommt. Chinesische Labore veröffentlichen seit geraumer Zeit leistungsfähige Open-Weight-Modelle, die dem westlichen Vorderfeld nur um eine einstellige Zahl von Monaten hinterherhinken — nahe genug, dass die Lücke für einen großen Teil realer Aufgaben unsichtbar ist. Entscheidend: Vieles davon erscheint als offene Gewichte oder wird über APIs zu Preisen weit unterhalb dessen angeboten, was die US-Labore verlangen. Diese Kombination ist zersetzend. Sie bedeutet, dass ein Unternehmen ein nahezu frontaktuelles Modell auf eigener Rechenleistung betreiben oder vergleichbare Fähigkeit über eine API zu einem Bruchteil der Kosten beziehen und die teuren Platzhirsche damit schlicht umgehen kann.\nEuropa fügt einen weiteren Vektor hinzu. Mistral und das Open-Weight-Ökosystem darum bedeuten, dass auch der Westen eine glaubwürdige günstige und offene Option hat, die nicht demselben Renditedruck des Risikokapitals unterliegt. Das Ergebnis: „Frontier-Fähigkeit“ lässt sich immer weniger als Monopolrente bepreisen. Sie wird zur Ware mit kurzer Haltbarkeit — und Waren tragen keine Billionenbewertungen.\nDie Frage, die die Labore nur schwer beantworten können, lautet also: Wenn der Vorsprung drei Monate beträgt und schrumpft, und das Produkt sich bei minimalen Wechselkosten durch ein günstigeres ersetzen lässt — wofür genau zahlen die Käufer dann einen Aufpreis, und wie lange noch?\nDie Nachfrageseite rettet die Rechnung nicht Man könnte hoffen, die Nachfrage sei so gewaltig, dass sie das Preisproblem überrollt. Die bisherige Evidenz weist in die andere Richtung. Privatnutzer zahlen weitgehend nicht; sie sammeln sich auf den kostenlosen Stufen und nehmen, was sie bekommen. Unternehmen sind zahlungsbereiter, aber auch rationaler — und eine wachsende Zahl von ihnen beginnt zu eruieren, dass die Rendite ihrer KI-Ausgaben die Rechnungen nicht rechtfertigt. Wenn der Käufer mit den tiefsten Taschen anfängt, nach dem ROI zu fragen, und der Käufer mit den flachsten Taschen sich gänzlich weigert zu zahlen, wird der Weg zu jenen Cashflows, die die Bewertungen rechtfertigen würden, sehr schwer zu zeichnen.\nDas ist die Klemme. Die Kosten sind strukturell hoch und lassen sich nicht ohne Weiteres senken. Die Preise stehen unter dauerhaftem Abwärtsdruck durch günstigere, austauschbare Konkurrenten. Und die Nachfrage, die einen über schiere Menge aus der Klemme befreien würde, ist weicher und preissensibler, als die Bewertungen unterstellen.\nDeshalb kommt der Ausstieg zuerst Setzt man dies zusammen, ergibt das Verhalten des Systems einen anderen Sinn. Als früher Investor — die Angels, die Fonds der Serien A bis D — hat man sein Geld nicht hineingesteckt, um über Jahrzehnte langsame Dividenden zu beziehen. Man hat es für eine große, schnelle Rendite hineingesteckt, und das eigene Modell setzt voraus, dass die meisten Wetten scheitern, sodass die Gewinner alles tragen müssen. Man sieht so klar wie irgendjemand, dass der Burggraben dünn ist und die Kommodifizierung sich beschleunigt. Man weiß, dass das Unternehmen nicht dann am wertvollsten ist, wenn es am profitabelsten ist, sondern wenn die Geschichte am überzeugendsten ist — solange es noch als das Heißeste gilt, noch als das Vorderfeld wahrgenommen wird, bevor ein günstigerer Konkurrent vorführt, dass der Vorsprung keinen Aufpreis mehr gebietet.\nDer rationale Zug ist dann nicht, auf eine Profitabilität zu warten, die womöglich nie eintritt. Er besteht darin, die Geschichte in Liquidität zu verwandeln, solange die Geschichte noch trägt. Der Börsengang ist das Instrument. Sobald die Aktien frei gehandelt werden, löst sich ihr Kurs von den Gewinnen und treibt auf dem Glauben — und Glauben lässt sich durch ein Narrativ weit länger aufrechterhalten, als eine Bilanz es je rechtfertigen könnte. Das frühe Geld steigt auf dem Höhepunkt der Geschichte aus. Wer beim IPO kauft, erbt die Frage, ob der Burggraben jemals real war.\nDas stellt die Dringlichkeit des Börsengangs in ein anderes Licht. Er ist nicht zwangsläufig ein Zeichen von Zuversicht in eine dauerhafte, profitable Zukunft. Er lässt sich ebenso als Zeichen lesen, dass die Leute, die den Zahlen am nächsten sind, liquide sein wollen, bevor der Markt begreift, was sie längst ahnen — dass Frontier-Führung gemietet und nicht besessen ist, und dass die Miete fällig wird.\nWer kauft, wenn das frühe Geld aussteigt — und wer die Rechnung trägt Damit der Ausstieg funktioniert, braucht es auf der anderen Seite einen Käufer, der nicht fragt, ob der Preis vernünftig ist. Genau diesen Käufer liefert die Indexmechanik. Sobald ein Wert in einen großen Index aufgenommen wird, löst das sofortiges, nicht-diskretionäres Kaufen durch Indexfonds und ETFs aus: Jeder passive Fonds, der den Index nachbildet, muss die Aktie kaufen — zu dem Preis, den der Markt gerade aufruft, ohne jedes Urteil darüber, ob dieser Preis gerechtfertigt ist. Allein an den S\u0026amp;P 500 sind rund 24 Billionen Dollar gebunden. Das ist preisunempfindliche Nachfrage in gewaltigem Maßstab.\nUnd hier kommt die Altersvorsorge ins Spiel, denn genau dort liegt der Großteil dieses passiven Geldes: in Pensionsfonds, in den Standard-Zielfonds der betrieblichen Altersvorsorge, in ETF-Sparplänen, in den 401(k)-Konten der amerikanischen Beschäftigten. Diese Vehikel treffen keine Einzelfallentscheidung über eine KI-Aktie. Sie bilden einen Index ab. Landet ein KI-Labor im Index, werden die Ersparnisse gewöhnlicher Menschen automatisch zu Zwangskäufern — und die Insider, die oben verkaufen, verkaufen in eben diese Nachfrage hinein. Manche Unternehmen geben sogar gezielt neue Aktien direkt in diese erzwungene Nachfrage aus. Der Mechanismus überträgt Wohlstand von den preisunempfindlichen Sparern zu den frühen Verkäufern.\nVerschärft wird das durch die verkürzten Aufnahmefristen. Die „Seasoning“-Periode — die Zeit, die ein Unternehmen börsennotiert sein muss, bevor es indexfähig wird — ist bei mehreren Anbietern drastisch geschrumpft. Die Nasdaq 100 nimmt Neulinge inzwischen 15 Tage nach dem Listing auf, zuvor waren es zwölf Monate. FTSE Russell ging weiter und verkürzte das Fenster für seine Russell-Indizes auf fünf Tage für große Neuemissionen — und nannte SpaceX, Anthropic und OpenAI ausdrücklich als die Kandidaten, die damit beschleunigt aufgenommen werden sollen. Je kürzer das Fenster, desto früher trifft das Zwangskaufen den Streubesitz, und zwar mit weniger vorheriger Preisfindung: Die mechanische Nachfrage kann einen Kurs neu bepreisen, bevor die Fundamentaldaten überhaupt Zeit hatten, sich einzustellen. Für SpaceX allein wurde das kurzfristige Zwangskaufen über QQQ- und Russell-1000-Tracker auf 22 bis 27 Milliarden Dollar geschätzt; über alle Indizes hinweg könnte die Summe, wenn sie sich materialisiert, 100 Milliarden übersteigen.\nDie eine echte Bremse ist der S\u0026amp;P 500. Sein Indexanbieter hatte im Mai 2026 selbst vorgeschlagen, die Seasoning-Frist von zwölf auf sechs Monate zu kürzen und die Profitabilitätsanforderung für Megacaps auszusetzen — und diesen eigenen Vorschlag am 4. Juni 2026 wieder verworfen. Sämtliche Aufnahmekriterien bleiben unverändert: zwölf Monate Seasoning, GAAP-Profitabilität, Mindeststreubesitz. Praktisch heißt das, dass ein verlustreiches KI-Labor in den größten passiven Benchmark der Welt erst dann aufgenommen wird, wenn es ein volles Jahr lang echte GAAP-Gewinne ausweist — angesichts des Geschäftsmodellproblems aus diesem Essay also womöglich nie.\nDie Antwort auf die Frage, ob die Öffentlichkeit die Rechnung zahlt, lautet damit: weitgehend ja, aber nicht über jeden Kanal. Über die Nasdaq 100, die Russell-1000-Tracker und das breitere passive Ökosystem fließt das Geld der Sparer schnell und preisunempfindlich in diese Werte — und bricht der Kurs später ein, sitzen die Verluste genau dort, in den Altersvorsorgedepots. Der einzige große Kanal, der vorerst geschlossen bleibt, ist der S\u0026amp;P 500 — und das nur so lange, wie seine Profitabilitätshürde hält.\nWas übrig bleibt, wenn der Kurs einbricht Wenn das in etwa stimmt, ist das unabhängige, risikokapitalfinanzierte Frontier-Labor kein stabiler Endzustand, sondern eine Phase. Spätestens wenn das Narrativ kippt und der Aktienkurs einbricht — wenn ein günstigerer Konkurrent den Aufpreis widerlegt und frisches Kapital ausbleibt —, fehlt diesen Unternehmen genau das, was ihnen nie gehörte: ein Grund, warum jemand dauerhaft mehr zahlen sollte. Ohne diesen Grund versiegt die Finanzierung, und ohne Finanzierung lässt sich die Kostenbasis nicht tragen.\nDie wahrscheinlichsten Überlebenden sind dann nicht die Labore, die auf der Kraft einer Geschichte an die Börse gegangen sind, sondern die Akteure, die Verluste unbegrenzt absorbieren können, ohne überhaupt Risikokapitalrenditen zu brauchen: die Handvoll Billionen-Dollar-Konzerne — Google, Microsoft und gut finanzierte Außenseiter wie Musks Unternehmung —, die notleidende IP und Talente billig aufkaufen, Inferenz auf ewig subventionieren und KI als Funktion eines bestehenden Imperiums behandeln können statt als Geschäft, das für sich allein stehen muss. Daneben steht die günstige, offene, teils chinesische, teils europäische Ebene, die den Preisboden dauerhaft niedrig hält.\nDas ist das nüchterne Ergebnis. Die Technologie überlebt — günstiger, als irgendjemand erwartet hat. Was nicht überlebt, ist das Geschäftsmodell, das sie unabhängig finanzieren sollte. Der Börsengang ist nicht das Ziel dieses Modells, sondern seine letzte Verwertungsstufe: der Moment, in dem das frühe Geld aussteigt und der öffentliche Markt — über die Indexfonds, in denen die Altersvorsorge liegt — die Rechnung dafür übernimmt, dass ein Burggraben verkauft wurde, den es nie gab.\n","permalink":"https://aibix.io/blog/der-ausstieg-bevor-der-burggraben-versiegt/","summary":"\u003ch2 id=\"warum-die-führenden-ki-labore-womöglich-an-die-börse-drängen-bevor-ihr-einziger-vorteil-verschwindet\"\u003eWarum die führenden KI-Labore womöglich an die Börse drängen, bevor ihr einziger Vorteil verschwindet\u003c/h2\u003e\n\u003cp\u003eÜber die führenden KI-Unternehmen lässt sich eine bequeme Geschichte erzählen und eine unbequeme. Die unbequeme ist rein struktureller Natur. Sie verlangt niemandem eine Lüge ab. Sie verlangt nur, dass die Zahlen sich weiter so verhalten, wie sie es bisher tun. In dieser Lesart rennen die Spitzenlabore nicht der Profitabilität entgegen, sondern dem Ausstieg — weil das Zeitfenster, in dem sie auch nur annähernd ihre Bewertung wert sind, schmaler sein könnte, als irgendjemand offen auszusprechen bereit ist.\u003c/p\u003e","title":"Der Ausstieg, bevor der Burggraben versiegt"},{"content":"„Ein Problem mit einer Systemanwendung wurde festgestellt.“ Bei jedem Aufwachen aus dem Standby.\nDie Spur In /var/crash/ lagen drei Berichte. Der spannende: systemd-journald, Signal 6 (SIGABRT). Und das siginfo verrät den Täter: si_pid = 1. Den Abbruch hat systemd selbst geschickt. Ein Watchdog-Kill:\nsystemd-journald.service: Watchdog timeout (limit 3min)! Killing process 119999 (systemd-journal) with signal SIGABRT. journald hängt drei Minuten, also schießt PID 1 es ab. Dreizehnmal in einer Woche. Warum hängt es? Weil es nicht hinterherkommt:\nMissed 221232 kernel messages /dev/kmsg buffer overrun, some messages lost. Irgendwer flutet den Kernel-Log. Der Schuldige, 332.584-mal in einem Boot, drei pro Sekunde, ununterbrochen:\nucsi_acpi USBC000:00: bogus connector number in CCI: 2 Der falsche Verdächtige Naheliegend: Am USB-C Port hängt nur ein älteres Netzteil von einem Dell Laptop.\nMarkenfremdes USB-C Power Delivery, das klingt nach Verhandlung, die schiefgeht. Ein perfekter Verdächtiger.\nAlso systematisch testen:\nNetzteil abgezogen → Sturm läuft unverändert, 3,6/s. Modul neu geladen, Port leer → Sturm startet von selbst. Kalt gebootet, nichts eingesteckt → Sturm da, plus UCSI_GET_PDOS failed (-70). Anker 737, 140 W, USB-C Powerbank → kein typec-Partner, alles null, Sturm identisch. Jede Variable einzeln eliminiert. Der Lader ist unschuldig, jeder Lader ist unschuldig.\nDie eigentliche Ursache Die UCSI-Firmware des Acer Aspire A14-52M ist scheinbar fehlerhaft. Der Embedded Controller beantwortet UCSI-Kommandos mit Kommunikationsfehler. Der Kernel-Treiber ucsi_acpi merkt das, verwirft es und fragt sofort wieder. Endlosschleife. Geladen wird trotzdem: Der EC handelt die Leistung in Hardware aus, völlig unabhängig OS. Deshalb fiel mir nie ein Ladeproblem auf.\nUnd die SSD? Der Reflex: So ein Log-Sturm zerschreibt doch die NVMe. Nachgerechnet: rund 21 Millionen identische Zeilen pro Jahr, von journald gnadenlos dedupliziert auf ein paar hundert Byte pro Eintrag: fünf bis acht Gigabyte im Jahr. Bei einer 2-TB-TLC mit ~1.200 TBW sind das 0,0005 % der Lebensdauer pro Jahr. SMART sagt nach 6,14 TB nüchtern: Percentage Used: 0%. Die SSD hat es nicht mal bemerkt.\nDer Fix Acer hat (Stand BIOS V1.32, November 2025) nichts gepatcht, fwupd kennt kein Update. Und der UCSI-Stack tut auf dieser Maschine scheinbar eh nichts Nützliches (die Hardware handelt PD auch ohne das OS, incl. unterschiedlicher Ladeleistung, je nach Netzteil). Also raus damit:\necho \u0026#34;blacklist ucsi_acpi\u0026#34; | sudo tee /etc/modprobe.d/blacklist-ucsi_acpi.conf echo \u0026#34;install ucsi_acpi /bin/true\u0026#34; | sudo tee -a /etc/modprobe.d/blacklist-ucsi_acpi.conf sudo update-initramfs -u Laden, USB-C-Daten, Thunderbolt, DisplayPort — alles läuft weiter über EC und Retimer. Verloren geht nur die USB-C-Telemetrie, die hat aber sowieso sowieso nur Nullen geliefert. Sturm vorbei, Log wieder übersichtlich.\nLehre: Der naheliegende Verdächtige, das fremde Netzteil, war eine saubere Sackgasse. Erst der leere Port im Kaltstart hat die Firmware überführt. Messen schlägt Raten.\nOne more thing — für die, die’s genau wissen wollen Ab hier wird’s schmutzig: Coredump auspacken und im Debugger nachsehen, woran journald genau hängengeblieben ist. Wen nur der Fix interessiert, ist oben fertig. Wer wissen will, wie man so eine Aussage wie „PID 1 hat es abgeschossen“ belegt, liest weiter.\nDie .crash-Datei ist ein apport-Bericht mit base64-verpacktem Coredump. Auspacken:\napport-unpack /var/crash/_usr_lib_systemd_systemd-journald.0.crash /tmp/jd Symbole hat man lokal keine, also Ubuntus debuginfod ziehen lassen und den Stack der abgestürzten Thread ansehen:\nDEBUGINFOD_URLS=https://debuginfod.ubuntu.com \\ gdb -batch -ex \u0026#39;set debuginfod enabled on\u0026#39; \\ -ex \u0026#39;file /usr/lib/systemd/systemd-journald\u0026#39; \\ -ex \u0026#39;core-file /tmp/jd/CoreDump\u0026#39; \\ -ex \u0026#39;bt\u0026#39; -ex \u0026#39;print $_siginfo\u0026#39; Und da steht alles drin:\nProgram terminated with signal SIGABRT, Aborted. #0 __GI___libc_read (fd=146, buf=..., nbytes=4104) at read.c:26 #1 read_virtual_file_fd () from libsystemd-shared-255.so #2 read_virtual_file_at () from libsystemd-shared-255.so #3 device_read_uevent_file () from libsystemd-shared-255.so #4 sd_device_get_devname () from libsystemd-shared-255.so #5 ... #6 sd_event_dispatch () #7 sd_event_run () Der Thread klemmt in einem read() auf Dateideskriptor 146 — einer sysfs-uevent-Datei, gelesen über sd_device_get_devname(). journald wollte zu einem hereinflatternden Geräte-Event den Namen auflösen und blieb im virtuellen Dateisystem hängen. Drei Minuten lang. Genau die Sorte Stall, die der Watchdog bestraft.\nUnd der Beweis, dass es ein Watchdog-Kill war und kein interner abort(), steht im siginfo:\n$1 = {si_signo = 6, si_code = 0, _sigchld = {si_pid = 1, si_uid = 0}} si_code = 0 ist SI_USER, das Signal kam von einem kill(), nicht aus dem Prozess selbst. Und si_pid = 1: Absender ist PID 1, systemd.\n","permalink":"https://aibix.io/blog/wie-eine-scheinbar-fehlerhafte-usb-c-firmware-journald-abschiesst/","summary":"\u003cp\u003e„Ein Problem mit einer Systemanwendung wurde festgestellt.“ Bei jedem Aufwachen aus dem Standby.\u003c/p\u003e\n\u003ch2 id=\"die-spur\"\u003eDie Spur\u003c/h2\u003e\n\u003cp\u003eIn \u003ccode\u003e/var/crash/\u003c/code\u003e lagen drei Berichte. Der spannende: \u003ccode\u003esystemd-journald\u003c/code\u003e, Signal 6 (SIGABRT). Und das \u003ccode\u003esiginfo\u003c/code\u003e verrät den Täter: \u003ccode\u003esi_pid = 1\u003c/code\u003e. Den Abbruch hat \u003cstrong\u003esystemd selbst\u003c/strong\u003e geschickt. Ein Watchdog-Kill:\u003c/p\u003e","title":"Wie eine scheinbar fehlerhafte USB-C-Firmware journald abschießt"},{"content":"Du hast ein Tutorial befolgt. Debian-Cloud-Image gezogen, mit virt-customize den qemu-guest-agent reingebacken, brav --truncate /etc/machine-id aufgerufen, das Image in ein Proxmox-Template konvertiert. Dann drei VMs daraus geklont — und zwei hängen sich am DHCP. Im DHCP-Log: zwei Leases mit derselben Client-ID. Im Gast: identische /etc/machine-id.\nAber du hast doch gerade ein truncate gemacht?\nDas Symptom Cloud-Init-Templates auf Proxmox sind simpel: VM-Image mit cloud-init drin, via qm template in Klon-Modus, pro Deployment qm clone. Funktioniert — bis du mehr als eine VM klonst und Lease-Konflikte siehst:\nZwei Klone bekommen vom DHCP-Server dieselbe IP. systemd-networkd schreibt im Journal: DUID generated from machine-id. cat /etc/machine-id liefert auf jedem Klon denselben Hex-String. Alle Klone haben dieselbe machine-id geerbt. systemd-networkd leitet daraus die DHCP-Client-DUID ab. Aus DHCP-Sicht: alle Klone sind dieselbe Maschine.\nDie naheliegende Lösung, die nicht funktioniert Jedes zweite Tutorial schreibt:\nvirt-customize -a $IMG --truncate /etc/machine-id Sieht plausibel aus. Läuft fehlerfrei durch. Datei ist nach dem Befehl leer. Alles gut? Nein. Beim nächsten Boot ist die Datei wieder gefüllt — und beim nächsten virt-customize-Aufruf auf demselben Image ebenfalls.\nWarum: das libguestfs-Verhalten In den Verbose-Logs steht eine unscheinbare Zeile:\n[ 1.6] Setting the machine ID in /etc/machine-id virt-customize schreibt am Anfang jeder Operation einen Zufallswert in /etc/machine-id. Hartcodiert in libguestfs — aus einem Grund, der mit Proxmox nichts zu tun hat: Fedora-Kernel-Postinstall-Scripts erwarten eine gesetzte machine-id, sonst bleibt der Kernel halb installiert. RHEL-Bug #1554546, seit 2018 WONTFIX.\nWer --truncate /etc/machine-id aufruft, gewinnt nichts — virt-customize schreibt sie unmittelbar danach wieder.\nDer Fix: virt-sysprep, nicht virt-customize virt-sysprep ist genau für diesen Zweck gebaut und respektiert das machine-id-Reset. Als letzter Schritt nach allen virt-customize-Aufrufen:\nvirt-sysprep -a $IMG --operations machine-id,bash-history,logfiles,tmp-files,net-hostname,net-hwaddr, ssh-hostkeys,ssh-userdir,dhcp-client-state,package-manager-cache machine-id — Datei wird geleert, systemd generiert beim Boot neu. ssh-hostkeys — sonst hat jeder Klon dieselbe Server-Identität. net-hwaddr — leert persistente Mappings, damit systemd nicht die alte MAC zuweist. dhcp-client-state — alte Leases raus. Wichtig: erst virt-customize (Pakete installieren), dann virt-sysprep. Andersrum sinnlos.\nBelt-and-suspenders zusätzlich ein Firstboot-Hook, falls jemand später nochmal virt-customize anwirft:\nvirt-customize -a $IMG --firstboot-command \u0026#39;rm -f /etc/machine-id /var/lib/dbus/machine-id \u0026amp;\u0026amp; systemd-machine-id-setup \u0026amp;\u0026amp; systemctl restart systemd-networkd 2\u0026gt;/dev/null || true\u0026#39; Bonus-Falle: PVE 9 und das fehlende dhcpcd-base Auf Proxmox VE 9 schlägt der erste virt-customize-Aufruf mit --install fehl: die libguestfs-Appliance bekommt keinen Netzwerk-Zugriff, apt update scheitert an DNS. Fehlender Dependency-Eintrag im Debian-guestfs-tools-Paket — in PVE 8.x kam der DHCP-Client noch transitiv, in Debian 13 / PVE 9 ist die Kette gebrochen. Upstream als libguestfs/libguestfs#211, Fix in trixie-proposed-updates.\nWorkaround:\napt install dhcpcd-base auf dem Proxmox-Host. Danach funktioniert virt-customize --install wieder.\nLessons Learned Copy-paste-Tutorials sind eine eigene Korrektheitsklasse. Das --truncate /etc/machine-id-Anti-Pattern hat sich über zehn Jahre durch hunderte Blog-Posts vererbt, weil niemand es nachgeprüft hat. Das Kommando wirft keinen Fehler — das Symptom tritt erst auf, wenn man mehr als eine VM klont.\nvirt-customize und virt-sysprep sind unterschiedliche Tools mit unterschiedlichen Zwecken. virt-customize baut das Image, virt-sysprep macht es klonbar. Wer beide in der richtigen Reihenfolge einsetzt, hat ein deutlich saubereres Setup.\nPrimärquellen lesen ist nicht optional. RHEL-Bug #1554546, libguestfs Issue #211, der upstream-Commit zur machine-id — alles in zehn Minuten zu finden, während die Frustration mit dem kaputten Template Stunden frisst.\n","permalink":"https://aibix.io/blog/die-machine-id-falle-proxmox-cloud-init-templates-die-wirklich-klonbar-sind/","summary":"\u003cp\u003eDu hast ein Tutorial befolgt. Debian-Cloud-Image gezogen, mit \u003ccode\u003evirt-customize\u003c/code\u003e den \u003ccode\u003eqemu-guest-agent\u003c/code\u003e reingebacken, brav \u003ccode\u003e--truncate /etc/machine-id\u003c/code\u003e aufgerufen, das Image in ein Proxmox-Template konvertiert. Dann drei VMs daraus geklont — und zwei hängen sich am DHCP. Im DHCP-Log: zwei Leases mit derselben Client-ID. Im Gast: identische \u003ccode\u003e/etc/machine-id\u003c/code\u003e.\u003c/p\u003e","title":"Die machine-id-Falle: Proxmox Cloud-Init Templates, die wirklich klonbar sind"},{"content":"\nTeil 1 hat CLAUDE.md, den Research-Plan-Implement-Workflow und Kontextmanagement behandelt. Hier geht es um die fortgeschrittene Ebene: die vier Features, die aus Claude Code einen echten Orchestrator machen — und die die meisten Nutzer entweder gar nicht kennen oder falsch verstehen.\nSkills: wiederverwendbare Workflows als Slash-Commands Wichtiger Hinweis vorab: Das alte .claude/commands/-Format funktioniert noch, ist aber Legacy. Das aktuelle Format laut Dokumentation sind Skills in .claude/skills/\u0026lt;name\u0026gt;/SKILL.md. Der Unterschied ist nicht trivial: Skills unterstützen YAML-Frontmatter, können von Claude autonom geladen werden und lassen sich direkt mit Sub-Agents verknüpfen.\nStruktur einer Skill-Datei:\n.claude/skills/ security-scan/ SKILL.md pr-summary/ SKILL.md Beispiel: .claude/skills/security-scan/SKILL.md\n--- name: security-scan description: Run a security vulnerability scan on the codebase. Use when the user asks about security, CVEs, or before a production deploy. allowed-tools: Read, Grep, Glob model: claude-opus-4-6 --- Analyze the codebase for security vulnerabilities including: - SQL injection risks - XSS vulnerabilities - Exposed credentials in code or config files - Insecure configurations Report findings grouped by severity: Critical / High / Medium / Low. Aufruf: /security-scan — oder Claude lädt den Skill autonom, sobald die description zur aktuellen Aufgabe passt.\nDas $ARGUMENTS-Platzhalter-Feature funktioniert in beiden Formaten: /security-scan src/api/ übergibt src/api/ als Argument.\nWichtig: Bestimmte Namen sind intern reserviert. Die vollständige Liste der Built-in Commands steht in der Slash Commands Referenz.\nSkills mit context: fork — isolierte Ausführung Das mächtigste Frontmatter-Feld: context: fork startet den Skill in einem eigenen Sub-Agent. Der Skill läuft isoliert — kein Zugriff auf die aktuelle Konversationshistorie, aber der Parent-Agent bekommt das Ergebnis zurück.\n--- name: deep-research description: Research a topic thoroughly in the codebase context: fork agent: Explore --- Research $ARGUMENTS thoroughly: 1. Find relevant files using Glob and Grep 2. Read and analyze the code 3. Summarize findings with specific file references Der agent: Explore-Wert gibt an, welcher Sub-Agent-Typ verwendet wird. Explore ist ein Built-in, der auf Read-only-Tools optimiert ist — kein versehentliches Schreiben während der Recherche.\nHooks: deterministische Kontrolle über den Agent-Lifecycle Hooks sind Shell-Skripte, die Claude Code an definierten Punkten im Lifecycle ausführt. Konfiguriert werden sie in ~/.claude/settings.json (global) oder .claude/settings.json (Projekt).\nDie vollständige Hooks-Referenz listet alle Events — hier die wichtigsten:\nEvent Wann Besonderheit PreToolUse Vor jedem Tool-Aufruf Kann Tool blockieren oder erlauben PostToolUse Nach jedem Tool-Aufruf Kann Feedback an Claude schicken UserPromptSubmit Wenn User Prompt submitted stdout wird Claude als Kontext injiziert Stop Wenn Claude fertig ist Kann Claude zwingen weiterzumachen SubagentStop Wenn Sub-Agent fertig ist Wie Stop, aber für Agents WorktreeCreate Wenn Worktree erstellt wird Ersetzt die Default-Worktree-Logik SessionStart Beim Session-Start Kontext injizieren Kommunikationskanal: Claude Code übergibt JSON-Daten via stdin an das Skript. Das Skript kommuniziert zurück über Exit-Code und stdout/stderr:\nExit 0 + kein JSON: alles normal Exit 2: blockieren, Nachricht aus stderr geht an Claude Exit 0 + JSON-Objekt: feingranulare Steuerung Praktisches Beispiel — Formatter-Hook:\n{ \u0026#34;hooks\u0026#34;: { \u0026#34;PostToolUse\u0026#34;: [ { \u0026#34;matcher\u0026#34;: \u0026#34;Write|Edit|MultiEdit\u0026#34;, \u0026#34;hooks\u0026#34;: [ { \u0026#34;type\u0026#34;: \u0026#34;command\u0026#34;, \u0026#34;command\u0026#34;: \u0026#34;jq -r \u0026#39;.tool_input.file_path\u0026#39; | xargs -I{} sh -c \u0026#39;echo {} | grep -q .rs$ \u0026amp;\u0026amp; cargo fmt -- {} || true\u0026#39;\u0026#34; } ] } ] } } Jedes Mal wenn Claude eine .rs-Datei schreibt, läuft automatisch cargo fmt. Claude sieht den Output und kann darauf reagieren.\nKontextinjektion mit UserPromptSubmit:\n{ \u0026#34;hooks\u0026#34;: { \u0026#34;UserPromptSubmit\u0026#34;: [ { \u0026#34;hooks\u0026#34;: [ { \u0026#34;type\u0026#34;: \u0026#34;command\u0026#34;, \u0026#34;command\u0026#34;: \u0026#34;echo \u0026#34;Current git branch: $(git branch --show-current). Last commit: $(git log -1 --oneline)\u0026#34;\u0026#34; } ] } ] } } Bei UserPromptSubmit ist stdout der Sonderfall: Exit 0 + stdout → der Text wird Claude als Kontext injiziert. Claude weiß damit bei jedem Prompt automatisch, auf welchem Branch du arbeitest.\nGefährliche Befehle blockieren:\n{ \u0026#34;hooks\u0026#34;: { \u0026#34;PreToolUse\u0026#34;: [ { \u0026#34;matcher\u0026#34;: \u0026#34;Bash\u0026#34;, \u0026#34;hooks\u0026#34;: [ { \u0026#34;type\u0026#34;: \u0026#34;command\u0026#34;, \u0026#34;command\u0026#34;: \u0026#34;jq -e \u0026#39;.tool_input.command | test(\u0026#34;rm -rf|git push --force|git reset --hard\u0026#34;)\u0026#39; \u0026amp;\u0026amp; exit 2 || exit 0\u0026#34;, \u0026#34;timeout\u0026#34;: 5 } ] } ] } } Exit 2 blockiert den Tool-Call. Die stderr-Nachricht geht als Feedback an Claude — es kann dann einen anderen Weg wählen.\nSub-Agents: spezialisierte Assistenten mit eigenem Kontext Sub-Agents sind in .claude/agents/ als Markdown-Dateien definiert. Jeder Agent hat einen eigenen Kontext-Window und kann auf spezifische Tools eingeschränkt werden. Die Subagents-Dokumentation erklärt das System vollständig.\nBeispiel: .claude/agents/test-runner.md\n--- name: test-runner description: Use proactively when tests need to be run or when test failures need to be fixed. Runs tests and iterates until they pass. tools: Bash, Read, Edit --- You are a test automation expert. Your only job is running tests and fixing failures. When invoked: 1. Run the full test suite: `cargo nextest run` 2. Analyze failures 3. Fix the root cause (not the test) 4. Re-run until green 5. Report what you changed Claude kann diesen Agent autonom aufrufen (wenn die description passt) oder du rufst ihn explizit auf: \u0026quot;Use the test-runner agent to fix the failing tests\u0026quot;.\nWichtig für Tool-Sicherheit: Wenn tools weggelassen wird, erbt der Agent alle Tools. Wer einen Read-only-Analysten will, muss das explizit einschränken:\n--- name: doc-reviewer description: Review documentation for accuracy and completeness tools: Read, Grep, Glob --- Sub-Agents und Kontext: Ein Sub-Agent startet mit einem leeren Kontext. Die einzige Verbindung zum Parent ist der Prompt-String beim Aufruf. Alles was der Agent wissen muss — Dateipfade, Fehlermeldungen, Entscheidungen — muss explizit in diesem Prompt mitgegeben werden.\nDas /agents-Kommando in Claude Code bietet ein interaktives Interface zum Erstellen und Verwalten von Agents, inkl. MCP-Tool-Auswahl.\nGit Worktrees: parallele Sessions ohne Kollisionen Claude Code hat nativen Worktree-Support via --worktree / -w Flag — kein manuelles git worktree add nötig:\n# Erstellt .claude/worktrees/feature-auth/ mit neuem Branch claude --worktree feature-auth # Zweite Session parallel claude --worktree bugfix-123 # Name automatisch generiert claude --worktree Laut Common Workflows Doku handhabt Claude Code das Cleanup selbst: Kein Commit → Worktree und Branch werden beim Beenden automatisch entfernt. Mit Commits → Branch bleibt erhalten.\nManueller Worktree für bestehende Branches:\n# Existing branch auschecken git worktree add ../project-bugfix bugfix-123 # Neue Branch in spezifischem Verzeichnis git worktree add ../project-feature-a -b feature-a cd ../project-feature-a \u0026amp;\u0026amp; claude Sub-Agents mit Worktree-Isolation:\nSub-Agents können über das Frontmatter automatisch in eigene Worktrees laufen:\n--- name: parallel-refactor description: Refactor a module in isolation isolation: worktree --- Refactor $ARGUMENTS following the project conventions in CLAUDE.md. Work in isolation. Do not modify files outside the target module. Jeder Agent-Aufruf bekommt seinen eigenen Worktree — automatisch angelegt und nach Abschluss aufgeräumt. Das bedeutet: mehrere Refactoring-Agents können gleichzeitig laufen, ohne sich gegenseitig zu blockieren.\nWorktreeCreate Hook für volle Kontrolle:\n{ \u0026#34;hooks\u0026#34;: { \u0026#34;WorktreeCreate\u0026#34;: [ { \u0026#34;hooks\u0026#34;: [ { \u0026#34;type\u0026#34;: \u0026#34;command\u0026#34;, \u0026#34;command\u0026#34;: \u0026#34;$CLAUDE_PROJECT_DIR/.claude/hooks/worktree-setup.sh\u0026#34; } ] } ] } } Der Hook ersetzt Claudes Default-Worktree-Logik komplett — nützlich wenn du immer von einem bestimmten Remote-Branch branchen oder zusätzliche Setup-Schritte ausführen willst.\nDas Zusammenspiel Alle vier Konzepte greifen ineinander:\nSkill (context: fork) → spawnt Sub-Agent (agent: Explore) → Sub-Agent läuft in eigenem Worktree (isolation: worktree) → Hooks laufen bei jedem Tool-Aufruf (PostToolUse formatter) Ein konkretes Setup für ein Rust-Projekt:\nSkill /pre-commit — führt Linting, Tests und Security-Scan durch, bevor ein Commit erlaubt wird Hook PostToolUse auf Write|Edit — cargo fmt automatisch Hook PreToolUse auf Bash — blockiert git push --force Sub-Agent test-runner — läuft autonom nach Implementierungsränderungen Worktree per Feature — claude --worktree feature-x Das ist kein Overhead — das ist einmalige Konfiguration, die danach unsichtbar im Hintergrund läuft.\nTeil 1: Claude Code meistern: Was die Top-Nutzer anders machen\nDas ultimative Claude Code Handbuch für Einsteiger: Vibe Coding lernen, eigene Apps bauen, Tools und Skills erstellen und ganze Projekte mit deinem … Intelligenz für Einsteiger, Band 5) Anzeige · Amazon-Partnerlink · Preis auf Amazon Claude AI für Einsteiger: Der schnelle Einstieg ohne technisches Vorwissen Anzeige · Amazon-Partnerlink · Preis auf Amazon ","permalink":"https://aibix.io/blog/claude-code-meistern-teil-2-skills-hooks-sub-agents-und-worktrees/","summary":"\u003cp\u003e\u003cimg loading=\"lazy\" src=\"/media/2026/03/Ingenieure-arbeiten-an-humanoidem-Robotermodell.png\"\u003e\u003c/p\u003e\n\u003cp\u003e\u003cem\u003eTeil 1 hat CLAUDE.md, den Research-Plan-Implement-Workflow und Kontextmanagement behandelt. Hier geht es um die fortgeschrittene Ebene: die vier Features, die aus Claude Code einen echten Orchestrator machen — und die die meisten Nutzer entweder gar nicht kennen oder falsch verstehen.\u003c/em\u003e\u003c/p\u003e","title":"Claude Code meistern – Teil 2: Skills, Hooks, Sub-Agents und Worktrees"},{"content":"\nClaude Code ist kein Code-Generator. Es ist ein Agent. Wer es wie GitHub Copilot behandelt — Prompt rein, Code raus — verschenkt 90% des Potenzials und verbrennt dabei jede Menge Tokens. Power-User bauen stattdessen eine Umgebung, in der Claude eigenständig denken, planen und arbeiten kann.\nWas Claude Code wirklich ist Der häufigste Fehler: Claude Code als smarten Autocomplete zu benutzen. Einzeiliger Prompt, fix Ergebnis, weiter. Das funktioniert — aber es ist ungefähr so, als würde man einen Seniorentwickler ausschließlich für Copy-Paste-Aufgaben einsetzen.\nClaude Code wurde als Agentic Coding Tool konzipiert. Es kann:\nCodebasen selbstständig navigieren und verstehen Mehrere Dateien gleichzeitig bearbeiten Bash-Befehle ausführen und Ergebnisse interpretieren Iterativ arbeiten: planen, ausführen, prüfen, korrigieren Der Unterschied zwischen einem Power-User und einem Gelegenheitsnutzer liegt fast immer nicht im Prompt-Skill, sondern in der Umgebung, die sie für Claude einrichten.\nDie CLAUDE.md — der größte einzelne Hebel Eine CLAUDE.md-Datei im Projektstamm ist das Erste, was Claude Code beim Start liest. Wer diese Datei nicht hat, gibt Claude jeden Tag die gleichen Kontextinformationen im Prompt mit — oder eben nicht, was zu inkonsistenten Ergebnissen führt.\nEine gute CLAUDE.md enthält:\n# Projektkontext Dieses Projekt ist ein Rust-basiertes CLI-Tool für Netzwerkanalyse (libpcap + eBPF). Target: Linux aarch64, CUDA 12.x. # Architektur - src/capture/ — libpcap-Integration - src/ebpf/ — eBPF-Programme und Loader - src/ui/ — Ratatui-basiertes TUI # Conventions - Fehlerbehandlung: anyhow überall, thiserror für öffentliche APIs - Tests: cargo nextest, nicht cargo test - Kein unwrap() in Produktionscode # Häufige Befehle - Build: cargo build --release - Test: cargo nextest run - Lint: cargo clippy -- -D warnings Faustregel: Alles, was du einem neuen Kollegen in der ersten Stunde erklären würdest, gehört in die CLAUDE.md. Je spezifischer, desto besser.\nDer Research-Plan-Implement-Workflow Statt direkt mit „schreib mir eine Funktion für X“ anzufangen, trennen Power-User konsequent drei Phasen:\n1. Research Lies src/capture/mod.rs und src/ebpf/loader.rs. Verstehe, wie die beiden Module aktuell kommunizieren. Schreib noch nichts. Claude liest die relevanten Dateien und gibt dir eine Zusammenfassung. Du prüfst, ob es richtig verstanden hat.\n2. Plan Ich will einen Ringbuffer einbauen, der eBPF-Events mit pcap-Paketen korreliert. Wie würdest du das angehen? Zeig mir einen Plan, bevor du irgendetwas implementierst. Claude schlägt eine Lösung vor. Du diskutierst, korrigierst, ergänzt.\n3. Implement Gut. Jetzt implementiere Schritt 1 aus dem Plan. Nur Schritt 1, nichts anderes. Der Schritt-für-Schritt-Ansatz klingt langsamer, ist es aber nicht. Ohne Plan produziert Claude oft Code, der technisch funktioniert aber die falsche Abstraktion wählt — und dann fängst du von vorne an.\nKontextmanagement: /clear ist dein bester Freund Der Kontext-Overhead ist real. Eine lange Session mit vielen Dateien, Shell-Outputs und hin-und-her Korrekturen kostet Tokens — und irgendwann fängt Claude an, frühere Entscheidungen zu „vergessen“ oder widersprüchliche Korrekturen zu machen.\nDrei Regeln:\n/clear zwischen unverwandten Aufgaben. Feature A und Feature B gehören nicht in dieselbe Session, wenn sie nichts miteinander zu tun haben. Regelmäßige Checkpoints. Lass Claude nach einer komplexen Implementierung kurz zusammenfassen, was es getan hat. Das dient als Kontextverdichtung und zeigt dir, ob es auf dem richtigen Weg ist. Große Dateien gezielt laden. Statt „lies das gesamte Projekt“ lieber: „lies src/ebpf/loader.rs und erkläre, wie der BPF-Map-Zugriff funktioniert.“ Permissions und MCP-Server: einmal sauber einrichten Wer Claude Code produktiv nutzt, konfiguriert es einmal richtig und nie wieder:\n~/.claude/settings.json (global):\n{ \u0026#34;permissions\u0026#34;: { \u0026#34;allow\u0026#34;: [ \u0026#34;Bash(cargo:*)\u0026#34;, \u0026#34;Bash(git:*)\u0026#34;, \u0026#34;Bash(grep:*)\u0026#34;, \u0026#34;Bash(find:*)\u0026#34; ] } } Ohne diese Konfiguration fragt Claude bei jedem Bash-Befehl nach — was bei einem Agenten, der 20 Befehle pro Aufgabe ausführt, schnell nervtötend wird.\nMCP-Server erweitern Claude Code um externe Tools: GitLab-Integration, Datenbankzugriff, interne APIs. Der Aufwand für die Einrichtung zahlt sich aus, sobald Claude Code selbstständig Issues erstellen, PRs kommentieren oder gegen Staging-APIs testen kann.\nHäufige Fehler und wie man sie vermeidet „Mach das einfach fertig“\nZu breite Aufgaben führen zu Code, der technisch „fertig“ ist, aber nicht das tut, was du wolltest. Besser: Aufgaben in Teilschritte zerlegen, jeden bestätigen lassen.\nKein Feedback bei Korrekturen\n„Nein, das ist falsch\u0026quot; ohne Erklärung führt oft dazu, dass Claude die gleiche Lösung leicht variiert wiederholt. Besser: „Das funktioniert nicht, weil [Grund]. Versuche stattdessen [Richtung].\u0026quot;\nDie Session als einzige Quelle der Wahrheit\nWas im Chat gesagt wurde, ist nach /clear weg. Wichtige Entscheidungen und Konventionen gehören in die CLAUDE.md, nicht in den Chat.\nTool-Calls ignorieren\nClaude Code zeigt dir jeden Bash-Befehl, den es ausführen will. Das ist kein Lärm — das ist der Blick in den Denkprozess. Wenn ein Befehl falsch aussieht, stopp und korrigiere. Billiger als danach aufzuräumen.\nFazit: Infrastruktur schlägt Prompt-Talent Die besten Claude Code-Nutzer sind keine besseren Prompt-Schreiber. Sie haben bessere Infrastruktur:\nEine gepflegte CLAUDE.md mit echtem Kontext Saubere Permissions-Konfiguration Konsequentes Session-Management Aufgaben, die klein genug sind, um verifizierbar zu sein Claude Code ist ein Multiplikator — aber Multiplikator mal schlechte Struktur ergibt immer noch Chaos. Mit der richtigen Umgebung wird es zum schnellsten Entwickler-Kollegen, den du je hattest.\nDas ultimative Claude Code Handbuch für Einsteiger: Vibe Coding lernen, eigene Apps bauen, Tools und Skills erstellen und ganze Projekte mit deinem … Intelligenz für Einsteiger, Band 5) Anzeige · Amazon-Partnerlink · Preis auf Amazon Claude AI für Einsteiger: Der schnelle Einstieg ohne technisches Vorwissen Anzeige · Amazon-Partnerlink · Preis auf Amazon ","permalink":"https://aibix.io/blog/claude-code-meistern-was-die-top-nutzer-anders-machen/","summary":"\u003cp\u003e\u003cimg loading=\"lazy\" src=\"/media/2026/03/Ingenieure-arbeiten-an-humanoidem-Robotermodell.png\"\u003e\u003c/p\u003e\n\u003cp\u003e\u003cem\u003eClaude Code ist kein Code-Generator. Es ist ein Agent. Wer es wie GitHub Copilot behandelt — Prompt rein, Code raus — verschenkt 90% des Potenzials und verbrennt dabei jede Menge Tokens. Power-User bauen stattdessen eine Umgebung, in der Claude eigenständig denken, planen und arbeiten kann.\u003c/em\u003e\u003c/p\u003e","title":"Claude Code meistern: Was die Top-Nutzer anders machen"},{"content":"\nEnde März 2026. Claude ist das beste Sprachmodell auf dem Markt — und gleichzeitig kaum benutzbar. Was als „Spring Break“-Promotion begann, hat sich zur größten Vertrauenskrise in Anthropics Geschichte entwickelt. Aber die eigentliche Geschichte ist nicht die, die in den Tech-Medien steht.\nDie Schlagzeilen drehen sich um Rate Limits: Session-Budgets, die in Minuten statt Stunden verfallen, $200/Monat-Abonnenten, die nach drei Prompts ausgesperrt werden. Das ist ärgerlich, aber für europäische Nutzer oft kein direktes Problem — das Peak-Hour-Fenster (5–11 AM PT, also 14–20 Uhr CET) trifft uns nur am Nachmittag. Was mich als täglichen Power-User wirklich trifft: Claude wird dümmer. Nicht metaphorisch. Messbar.\nDie Promotion, die nach hinten losging Am 13. März startete Anthropic eine zweiwöchige Aktion: doppelte Usage-Limits außerhalb der Spitzenzeiten für alle Pläne — Free, Pro, Max, Team. Die offizielle Promo-Seite klingt großzügig. War es auch, isoliert betrachtet. Das Problem: Gleichzeitig wurden die Peak-Hour-Limits still und heimlich verschärft. Drei Tage lang wusste niemand davon. Erst am 26. März bestätigte Anthropic-Mitarbeiter Thariq Shihipar — nicht per Blog-Post, nicht per E-Mail, sondern in einem X-Post — dass 5-Stunden-Sessions während der Spitzenzeiten absichtlich schneller verbraucht werden.\nDie Hintergrundgeschichte: Nach OpenAIs Pentagon-Vertrag Ende Februar explodierten die ChatGPT-Deinstallationen um 295% an einem einzigen Tag. Die #QuitGPT-Bewegung trieb Millionen neuer Nutzer zu Claude. Die App erreichte Platz 1 im US App Store. Anthropics annualisierter Umsatz sprang auf $19 Milliarden. Aber GPU-Kapazität skaliert nicht über Nacht. Der Blogger J.D. Hodges brachte es auf den Punkt: Man kann 100.000 neue Abonnenten über Nacht gewinnen, aber nicht 100.000 GPUs an Inferenz-Kapazität. Irgendwo muss die Lücke sichtbar werden — als langsamere Antworten, niedrigere Qualität oder striktere Limits.\nDie Ironie dabei ist zum Haareraufen. Die #QuitGPT-Fraktion wollte ein moralisches Zeichen setzen — und hat das genaue Gegenteil erreicht. Indem Millionen Nutzer OpenAI den Rücken kehrten, haben sie OpenAIs Kapazitäten entlastet. Weniger Consumer-Last auf den GPUs bedeutet mehr freie Rechenzeit für genau den Kunden, gegen den protestiert wurde: das US-Militär. Man hat dem Pentagon quasi einen Gefallen getan und gleichzeitig den einzigen Anbieter in die Knie gezwungen, der den Pentagon-Deal abgelehnt hatte. Glückwunsch.\nWer es wirklich ernst gemeint hätte mit dem Protest, hätte die Strategie umdrehen müssen: Nicht weggehen, sondern bleiben. Jeden Freund, jede Bekannte überreden, sich bei OpenAI anzumelden und die Kapazitäten aufzuzehren. Statt dessen: Massenflucht zu Anthropic, wo die Infrastruktur auf den Ansturm nicht vorbereitet war, während OpenAI plötzlich Luft zum Atmen hatte. Strategisches Denken sieht anders aus. Aber Hauptsache, man konnte einen Screenshot der Deinstallation posten. Ganz großes Kino.\nDas eigentliche Problem: Qualitätsverlust unter Last Rate Limits sind nervig, aber planbar. Was nicht planbar ist: Wenn dasselbe Modell, das vor einer Minute eine Aufgabe sauber gelöst hat, dieselbe Aufgabe plötzlich nicht mehr hinbekommt. Und genau das passiert gerade. Nicht sporadisch — reproduzierbar, über Sessions hinweg, bei mir und offensichtlich bei tausenden anderen.\nDie Ursachen sind mehrschichtig, und Anthropic schweigt zu den meisten davon.\nContext Rot: Das 1M-Token-Versprechen ist eine Mogelpackung Anthropic bewirbt ein 1-Million-Token-Kontextfenster für Opus 4.6. Was sie in der Werbung nicht prominent erwähnen: Die Qualität degradiert massiv, lange bevor dieses Fenster voll ist. Anthropics eigene API-Dokumentation räumt ein, dass mit steigender Token-Zahl Genauigkeit und Recall abnehmen — ein Phänomen, das sie selbst „Context Rot“ nennen. Die „Krücke“ dafür nennt man dann „Context Engineering“\nDie Zahlen aus GitHub-Issue #35296: Zuverlässige Performance im Bereich 0–256K Token. Danach progressive Degradierung. Bei 1M Token scheitert jede vierte Multi-Needle-Retrieval-Abfrage — und das auf einem synthetischen Benchmark. In realen Coding-Sessions mit Tool-Calls, Fehlermeldungen und Konversationshistorie ist es deutlich schlimmer.\nNoch konkreter: Die Performance beginnt laut unabhängigen Analysen bei etwa 147.000 Token zu degradieren. Nicht bei 200K, nicht bei 500K. Bei 147K. Die Auto-Compaction feuert deshalb jetzt bei 64–75% Kapazität statt bei 90% — weil Anthropic selbst weiß, dass das Modell ab diesem Punkt in einem degradierten Zustand arbeitet. Diese Daten sind offenbar vor dem 1 Mio Token Kontext – da wird nochmal deutlich, dass das nichts als eine Mogelpackung ist.\nFür Power-User mit MCP-Servern wird es richtig eng: Eine saubere Session ohne MCP bietet ~160–170K Token Arbeitsbudget. Mit 5 MCP-Servern sinkt das auf 120–130K. Mit 9 MCP-Servern können 50.000+ Token allein für Tool-Schemas draufgehen, bevor man ein Wort getippt hat. Das effektive Arbeitsbudget in einer typischen Session mit mehreren MCP-Servern liegt bei 100–120K Token — und die Degradierung beginnt bei 147K. Die Marge ist hauchdünn.\nForschung zu Context Rot zeigt außerdem unterschiedliche Degradierungsmuster je nach Füllgrad: Unter 50% verliert das Modell Token in der Mitte des Kontexts („Lost in the Middle“-Problem). Über 50% gehen die frühesten Token verloren — also typischerweise die initialen Instruktionen, CLAUDE.md-Regeln und Session-Ziele. Das erklärt, warum Claude nach einer halben Stunde Instruktionen ignoriert, die zu Beginn der Session perfekt befolgt wurden.\nTrial-and-Error statt Reasoning: Der Opus-4.6-Rückschritt Seit dem Release von Opus 4.6 Anfang Februar häufen sich Berichte über einen fundamentalen Verhaltenswechsel: Das Modell denkt weniger nach und probiert mehr aus. Statt ein Problem einmal durchzudenken und eine funktionierende Lösung zu liefern, startet es Trial-and-Error-Schleifen, die 20+ gescheiterte Versuche produzieren. Bereits Ende Januar dokumentierte GitHub-Issue #21431 das Muster: „Expected: Think through the problem once, deliver working solution. Actual: Trial-and-error debugging that wasted time.“\nEin professioneller Nutzer dokumentierte den Verfall in GitHub-Issue #28469 mit chirurgischer Präzision: Dieselbe Aufgabe — „SSH auf NAS, Disk-Usage prüfen“ — die unter Opus 4.5 ein einziger Turn war (SSH, df -h, fertig), braucht unter Opus 4.6 plötzlich 5–8 Turns: CLAUDE.md lesen, MEMORY.md lesen, einen Explore-Agent spawnen, SSH-Config lesen, um Erlaubnis fragen, drei überflüssige Befehle ausführen, dann endlich df -h. Seine Produktivitätsschätzung: 50–60% Rückgang seit Opus 4.6.\nDas Muster ist immer dasselbe: Claude versucht Ansatz A, scheitert. Man erklärt warum. Zwei bis drei Turns später versucht Claude Ansatz A erneut — manchmal wortgleich. Das ist keine Halluzination im klassischen Sinne. Es ist ein Failure-Loop, der darauf hindeutet, dass das Modell weniger Reasoning-Budget bekommt als früher. Die Analyse von AlphaGuru bringt es auf den Punkt: Das Modell ist nicht dümmer — es bekommt weniger Zeit zum Denken. Es überspringt die tiefe Analyse und springt direkt zur Aktion.\nEin besonders bitteres Detail aus Issue #28469: Nach einer Context-Compaction liest Claude die CLAUDE.md und MEMORY.md erneut ein, zeigt deren Inhalt im Tool-Output — und verletzt die darin enthaltenen Regeln im unmittelbar nächsten Turn. Die Instruktion steht literally im Kontext, und das Modell ignoriert sie trotzdem. Für jemanden, der produktionskritische Regeln in diesen Dateien hinterlegt hat („Niemals main/master pushen, immer branch nutzen“), ist das ein Safety-Problem, kein Komfort-Problem.\nSub-Agent-Hänger: Architektonische Schwächen Wer mit Claude Code Sub-Agents arbeitet — und das ist zunehmend der Standard-Workflow für komplexere Aufgaben — kennt das Muster: Ein Sub-Agent wird gestartet, arbeitet, und dann… nichts mehr. Der Spinner (das animierte Symbol heißt so, von englisch „to spin/spinning“ – drehen/drehend) dreht sich. Der Haupt-Agent wartet. Keine Fehlermeldung, kein Timeout, keine Recovery. Erst ein manueller Interrupt (/btw oder Ctrl+C) bringt das System wieder in Bewegung.\nDas ist kein Edge-Case. Es gibt mindestens vier dokumentierte Failure-Modes:\nStream-Freeze: Die API-Streaming-Verbindung bleibt mitten in der Übertragung stehen. Der Prozess lebt (steckt in epoll_wait), aber es kommen keine Tokens mehr an. Kein Fehler wird gemeldet. Die Session kann sich nicht selbst recovern — nur kill -9 hilft. GitHub-Issue #25979 dokumentiert einen spezifischen Trigger: Wenn eine Background-Agent-Notification genau am Ende eines Turns oder zwischen Turns eintrifft, hat der nächste API-Call eine hohe Wahrscheinlichkeit zu hängen.\nFehlender Timeout im Task-Tool: Wie in OpenCode-Issue #13841 im Detail analysiert, wartet das Task-Tool, das Sub-Agents spawnt, auf den gesamten Sub-Agent-Run — ohne jeglichen Timeout-Wrapper. Der Abort-Mechanismus feuert nur, wenn der Nutzer die Parent-Session manuell abbricht. Der Sub-Agent erbt keinen Tool-Level-Timeout. Das ist kein Bug — das ist eine architektonische Lücke.\nPermission-Prompt-Deadlock: GitHub-Issue #7091 dokumentiert: Wenn ein Sub-Agent einen Edit-Approval triggert, hängt der Haupt-Agent auf unbestimmte Zeit. ESC funktioniert nicht. Der einzige Ausweg ist Ctrl+C und eine neue Session. Bonus-Bug: Eine einzige Ablehnung eines Sub-Agent-Edits propagiert fälschlicherweise auf alle wartenden Sub-Agents.\nUnsichtbare Sub-Agents nach Compaction: Die März-Release-Notes bestätigen einen Fix für „Background Subagents, die nach Context-Compaction unsichtbar werden, was dazu führen konnte, dass doppelte Agents gespawnt wurden.“ Ebenfalls gefixt: „MCP Tool Calls, die auf unbestimmte Zeit hängen, wenn eine SSE-Verbindung mitten im Call abbricht“ und „eine Race Condition, bei der Background-Agent-Task-Output auf unbestimmte Zeit hängen konnte, wenn der Task zwischen Polling-Intervallen abschloss.“\nDie März-Release-Notes listen insgesamt über ein Dutzend Fixes für Hang- und Race-Condition-Bugs auf. Das zeigt, dass Anthropic die Probleme kennt. Aber es ist ein Whack-a-Mole-Spiel: 13 Releases in drei Wochen (v2.1.70–2.1.83), und der Changelog enthält keinen einzigen Fix für Context-Degradierung, keine Wiederherstellung der Thinking-Depth-Kontrolle und keine Infrastruktur-Stabilitätsankündigungen.\nDie Routing-Hypothese: Quantisierung unter Last? Die unbequemste Frage, die Anthropic konsequent nicht beantwortet: Werden verschiedene Modellversionen oder Quantisierungsstufen je nach Serverlast ausgeliefert?\nAnthropics offizielle Linie aus dem August-2025-Postmortem: „We never reduce model quality due to demand, time of day, or server load.“ Aber das war vor dem März-Debakel. Entwickler Ahmad Osman spekuliert auf X offen über dynamische Anpassungen während der Spitzenzeiten — Quantisierung der Modellgewichte auf Int4 oder 1.58-bit, KV-Cache-Quantisierung, oder Routing zu destillierten/kleineren Modellen. Ein GitHub-Issue (#21427) fragte direkt, ob unterschiedliche Modellversionen zu verschiedenen Tageszeiten ausgeliefert werden — keine offizielle Antwort.\nAnekdotische Evidenz gibt es reichlich: Mehrere Entwickler berichten, dass ihre besten Claude-Sessions nachts oder am frühen Morgen stattfinden. Ein Entwickler dokumentierte auf Grizzly Peak Software, dass seine produktivsten Sessions zwischen 22 Uhr und 2 Uhr nachts (Alaska Time) liegen — bei geringerer Last, möglicherweise auf Full-Precision-Instanzen. Aus dem August-Postmortem wissen wir, dass Anthropic tatsächlich verschiedene Server-Pools für Short- und Long-Context-Requests betreibt und dass fehlerhafte Routing-Logik ~30% der Claude-Code-Nutzer betreffen konnte, wenn Requests an falsche Server-Typen gingen. Das Routing war „sticky“ — einmal falsch geroutet, folgten Nachfrage-Requests demselben falschen Pfad.\nOb sie es nun offiziell tun oder nicht: Die Symptome sind konsistent mit Load-basiertem Routing. Und die Weigerung, die Frage direkt zu beantworten, macht die Sache nicht besser.\nAnthropics Kommunikationsversagen Was dieses Desaster von einem normalen Scaling-Problem unterscheidet, ist die Kommunikation — oder deren Ausbleiben.\nDrei Tage lang wussten zahlende Kunden nicht, was mit ihrem Service passierte. Die offizielle Bestätigung kam per X-Thread eines einzelnen Mitarbeiters. Kein Blog-Post, kein E-Mail-Update, keine Statusseite-Erklärung. CEO Dario Amodei hat sich nicht geäußert. PiunikaWeb brachte es auf den Punkt: Für Leute, die $200/Monat zahlen, ist es ziemlich hart, einen Post auf X checken zu müssen, um zu erfahren, was mit ihren Usage-Limits los ist.\nDie 90-Tage-Uptime-Zahlen zum 27. März sprechen für sich: claude.ai bei 98,98%, Claude API bei 99,06%, Claude Code bei 99,3%. Alles mit „Major Outage“-Status markiert. Allein im März gab es dokumentierte Incidents am 2., 11., 17.–19., 20.–22., 25. und 27. — das ist kein „gelegentlicher Ausfall“, das ist ein Pattern.\nBesonders bitter: Am selben Tag, an dem Anthropic die Limit-Verschärfung einräumte, setzte OpenAI die Codex-Usage-Limits für alle Nutzer kostenlos zurück — als Goodwill-Geste für neue Plugins. Keine Bedingungen, keine Peak-Hour-Einschränkungen. Einfach ein Reset. Das PR-Problem könnte für Anthropic kaum größer sein.\nDie Infrastruktur-Lücke Die tiefste Ironie der März-Krise: Sie ist ein Erfolgsproblem, kein Versagen. Claude ist das beste verfügbare Modell für Coding und analytische Aufgaben. Die ethische Haltung von Anthropic generiert echte Nutzerloyalität. Aber die Infrastruktur kommt nicht hinterher.\nDie Pipeline ist massiv: Eine $50-Milliarden-Partnerschaft mit Fluidstack für Custom-Rechenzentren in Texas und New York, Zugang zu bis zu 1 Million Google-Cloud-TPU-Chips, AWS Project Rainier mit 500.000+ Trainium2-Chips, und ein $30-Milliarden Microsoft-Azure-Commitment. Aber diese Kapazitäten kommen im Laufe von 2026 online — nicht heute.\nDerweil versucht Anthropic, den Gap mit Promotions, Limit-Umverteilung und Feature-Offensive zu überbrücken: Voice-Mode, Plugin-Marketplace, Excel/PowerPoint-Integration, Claude in Chrome, Cowork — 13 Releases in drei Wochen. Die Priorität liegt klar auf Wachstum und Feature-Parität mit der Konkurrenz. Stabilität und Inferenz-Qualität für Bestandskunden stehen offensichtlich nicht an erster Stelle.\nWas hilft — Stand jetzt Anthropic wird das Compute-Problem nicht über Nacht lösen. Für den Alltag gibt es ein paar Stellschrauben, die den Unterschied zwischen produktiver Session und Frustration ausmachen:\nContext aktiv managen. /context regelmäßig prüfen. Bei 60% Füllgrad handeln, nicht erst bei 90%. /compact proaktiv nutzen — nicht warten, bis die Auto-Compaction feuert, denn die läuft bereits in einem degradierten Zustand. /compact akzeptiert einen Custom-Prompt, der die Zusammenfassung auf die relevanten Aspekte fokussiert. Das ist der unterschätzteste Hebel. Abgesehen von diesen Tipps habe ich mein Context-Window auf 20% (also 200k Tokens, wie früher) begrenzt. Was soll ich mit einer Mio Tokens wenn dreiviertel davon verrotten? Zudem starte ich Claude Code nach jedem Feature neu – nicht ganz optimal, weil er sich dann erst wieder zurechtfinden muss, beim aktuellen trial-and-error-statt-denken auch nicht so prickelnd, aber immer noch besser als mit einem völlig dementen Model zu arbeiten.\nAlso, Sessions kurz halten. 30-Minuten-Sprints mit einem Ziel pro Sprint. Eine Feature, ein Bug, ein Modul. Dann compacten oder clearen. Eine 30-Minuten-Session verbraucht typischerweise 50–80K Token — deutlich unter der 147K-Degradierungsschwelle.\nMCP-Server-Last kennen. Jeder MCP-Server kostet Token für Tool-Schemas. Wer 9 Server geladen hat, verbrennt 50K+ Token, bevor der erste Prompt abgeschickt wird. Server nur laden, wenn sie für die aktuelle Aufgabe gebraucht werden.\nCLAUDE.md schlank und aktuell halten. Eine AGENTbench-Studie zeigt, dass LLM-generierte Context-Files die Erfolgsrate sogar senken können. Drei Monate akkumulierte Instruktionen, die eine Codebasis beschreiben, die sich längst weiterentwickelt hat, machen das Modell schlechter, nicht besser.\nSub-Agent-Hänger einplanen. /btw als manueller Nudge, wenn der Spinner zu lange dreht. Für automatisierte Workflows: Hooks und externe Watchdogs, die JSONL-Session-Files auf Inaktivität überwachen. Es gibt keinen eingebauten Timeout — man muss selbst dafür sorgen.\nMulti-Model-Strategie. Claude für die schweren Aufgaben, bei denen die Reasoning-Qualität den Unterschied macht. Für den Alltag: Gemini CLI (kostenlos, 1000 Requests/Tag, 1M Token Context), OpenAI Codex ($20/Monat mit ChatGPT Plus), oder lokale Modelle für Rate-Limit-Freiheit. Nicht entweder-oder — sowohl-als-auch.\nFazit März 2026 markiert einen Wendepunkt für Anthropic. Das Unternehmen hat sich in eine Position manövriert, in der es gleichzeitig das beste Modell am Markt hat und das schlechteste Nutzererlebnis für Power-User liefert. Die technische Überlegenheit von Claude Opus 4.6 steht außer Frage — wenn es funktioniert. Aber „wenn es funktioniert“ ist kein akzeptabler Zustand für ein $19-Milliarden-Unternehmen, das $200/Monat für eine Subscription verlangt.\nDie Lektion für die gesamte AI-Branche ist klar: Usage-Limits und Inferenz-Qualität unter Last — nicht Benchmark-Scores — werden zum primären Schlachtfeld für Subscriber-Retention. Wer das Compute-Demand-Problem zuerst löst — oder zumindest am ehrlichsten darüber kommuniziert — wird das nächste Kapitel der AI-Subscription-Wars definieren.\nAnthropic hat die Infrastruktur-Pipeline, um das Problem zu lösen. Was sie noch nicht haben, ist die Kommunikations-Infrastruktur, um ihren zahlenden Kunden in der Zwischenzeit das Gefühl zu geben, dass sie ernst genommen werden. Ein X-Thread eines einzelnen Mitarbeiters ist kein Krisenkommunikationsplan.\nStand: 27. März 2026. Die Spring-Break-Promotion endet am 28. März. Was danach passiert, wird zeigen, ob Anthropic aus dem März gelernt hat.\nQuellen Anthropic: Claude March 2026 Usage Promotion — Offizielle Promo-Seite Anthropic API Docs: Context Windows — Offizielle Dokumentation zu Context Rot Anthropic: A Postmortem of Three Recent Issues — Aug/Sep 2025 Routing-Bugs Anthropic: $50 Billion Infrastructure Investment Claude Status Page — Laufende Incident-Dokumentation Claude Code Release Notes (März 2026) — Changelog inkl. Sub-Agent-Fixes GitHub #35296 — 1M Context Window: Advertised Capability Does Not Work as Marketed GitHub #28469 — Opus 4.6 Comprehensive Regression GitHub #21431 — Massive Quality Regression (Jan 2026) GitHub #21427 — Model Quality Variation at Different Times of Day GitHub #25979 — Claude Code Hangs Indefinitely (Stream Stall) GitHub #7091 — Sub-Agent Permission Prompt Deadlock J.D. Hodges: Claude AI Usage Limits — What Changed in 2026 AlphaGuru: What’s Going On with Claude Code? PiunikaWeb: Anthropic Finally Explains Claude Usage Limits The Register: Anthropic Tweaks Claude Usage Limits MacRumors: Claude Code Users Report Rapid Rate Limit Drain Grizzly Peak Software: The Night Claude Got Dumber Plain English: Why Claude Gets Dumber the Longer Your Session Runs ProductTalk: Context Rot — Why AI Gets Worse the Longer You Chat Cordero Core: Your CLAUDE.md Is Making Your Agent Dumber (AGENTbench-Studie) Mauro: Claude Code Kept Getting Stuck — Hooks Fix Ahmad Osman auf X — Quantisierungs-Hypothese Das ultimative Claude Code Handbuch für Einsteiger: Vibe Coding lernen, eigene Apps bauen, Tools und Skills erstellen und ganze Projekte mit deinem … Intelligenz für Einsteiger, Band 5) Anzeige · Amazon-Partnerlink · Preis auf Amazon Claude AI für Einsteiger: Der schnelle Einstieg ohne technisches Vorwissen Anzeige · Amazon-Partnerlink · Preis auf Amazon ","permalink":"https://aibix.io/blog/claudes-maerz-krise-wenn-wachstum-die-infrastruktur-ueberholt/","summary":"\u003cp\u003e\u003cimg loading=\"lazy\" src=\"/media/2026/03/ChatGPT-Image-27.-Maerz-2026-21_46_17.png\"\u003e\u003c/p\u003e\n\u003cp\u003eEnde März 2026. Claude ist das beste Sprachmodell auf dem Markt — und gleichzeitig kaum benutzbar. Was als „Spring Break“-Promotion begann, hat sich zur größten Vertrauenskrise in Anthropics Geschichte entwickelt. Aber die eigentliche Geschichte ist nicht die, die in den Tech-Medien steht.\u003c/p\u003e","title":"Claudes März-Krise: Wenn Wachstum die Infrastruktur überholt"},{"content":" Video abspielen Erst beim Klick wird das Video von YouTube geladen und Ihre IP-Adresse an Google übertragen. Näheres in der Datenschutzerklärung. Damit der KI-Opa nicht immer nur erzählt, wie toll alles ist: Ich zeig euch, wie es funktioniert. Hands-on, kein Gelaber.\nDas Experiment Die Aufgabe: Ein komplettes Business-Launch-Paket für ein fiktives Katzenhotel auf dem Mars erstellen lassen. Warum Mars? Damit ich niemandem auf die Füße trete, der echte Katzenhotels betreibt.\nWas ich haben wollte:\nMarktanalyse mit Konkurrenzübersicht Investor-Pitch-Decks (DE + EN) Flyer (DE + EN) Kalkulation als Excel Risikoanalyse als Präsentation Eine fertige Webseite — deployed auf einem Hetzner-Server, mit DuckDNS-Domain und Let’s-Encrypt-Zertifikat Alles in einem Rutsch. Kein Template, kein CSS, keine Bilder vorgelegt. Einfach nur: Mach mal.\nWie Cowork arbeitet Cowork bekommt einen lokalen Ordner — der wird in eine Linux-VM gemappt. Mehr sieht das Ding nicht. Kein Netzlaufwerk, keine Magie. Lokale Platte, Ordner, fertig.\nWichtig: Cowork kann kein SSH. Es kann Web-Suche, MCP-Tools (wie Hetzner-API oder GitLab) und eben auf diesen einen Ordner zugreifen. Das war auch der erste Roadblock — der Chat hatte mir ein Prompt gebaut, das SSH-Konfiguration voraussetzte. Cowork kam aus seiner VM nicht raus. Merke: Immer wissen, was das Tool kann und was nicht.\nDer erste Durchlauf — steiniger Weg Nach etwa 6 Minuten hatte Cowork den Hetzner-Server erstellt, die Excel-Kalkulation gebaut, PowerPoints generiert und die Webseite zusammengeschraubt. Klingt gut? War es auch — bis man genauer hinschaut.\nWas nicht lief:\nPowerPoint-Slides: Text lief aus den Boxen, Zahlen lagen übereinander, Überschriften viel zu groß Flyer: Sahen nach nichts aus — keine Bilder (klar, Claude baut keine Bilder), aber auch strukturell schwach Server-Deployment: Certbot kollidierte mit System-Python, Pip machte Ärger, SSH-Zugang fehlte Das ist normal beim ersten Wurf. Entscheidend ist, was man daraus macht.\nIterieren bis es passt Ich hab Screenshots reingeworfen, Probleme beschrieben, und Cowork hat nachgebessert. Die Risikomatrix war unlesbar? Screenshot rein, er baut sie komplett neu. PowerPoint-Text bricht um? Er erkennt es, passt Schriftgrößen an. Nach ein paar Runden sahen die Präsentationen brauchbar aus — kein Kunstwerk, aber eine solide Basis zum Weiterarbeiten.\nFür den Server hab ich am Ende ein Bash-Script bauen lassen, das die Konfiguration übernimmt. PowerShell ging nicht (Execution Policy auf dem Windows), die Hetzner-API allein reichte nicht. Auch hier: Iterieren, bis es funktioniert.\nDer eigentliche Trick: Aus Fehlern einen Skill bauen Und jetzt kommt der Punkt, der das Ganze mächtig macht.\nIch hatte jetzt: ein fertiges Ergebnis, eine komplette Konversation mit allen Roadblocks, und das Wissen darüber, was funktioniert hat und was nicht. Daraus hab ich Cowork einen Skill bauen lassen.\nEin Skill ist eine strukturierte Anleitung, die Cowork kennt und auf Abruf ausführen kann. Der Skill Creator analysiert die gesamte Session — was lief, was nicht — und destilliert daraus einen reproduzierbaren Workflow.\nDas Ergebnis: Ein Business Launch Kit Skill, der nach ein paar Eingaben (Name, Branche, Standort, Subdomain) das komplette Paket selbstständig generiert.\nDer Beweis: Hundehotel in 30 Minuten Neuer Ordner, neues GitLab-Repo, neues Thema: Hundehotel auf Neptun. Gleicher Skill.\nMein Aufwand: Drei Eingaben — Projektname, Subdomain, ein paar kreative Vorgaben („Sei kreativ, keine Katzen-durch-Hunde-Kopie“). DNS-Eintrag einrichten. Server-Script ausführen. Fertig.\nCowork hat den Großteil selbstständig erledigt: GitLab befüllt, Präsentationen gebaut, QA-Agent laufen lassen, Fehler in den PowerPoints selbst erkannt und repariert. SSH kann Cowork nach wie vor nicht — die DuckDNS-Subdomain musste ich weiterhin manuell anlegen. Aber dank des funktionierenden Bash-Scripts, das aus dem ersten Durchlauf entstanden war, war das Deployment auf dem Server ein Kinderspiel.\nRund 25–30 Minuten für das komplette Paket. Autark.\nWas das bedeutet Mach ich in einer halben Stunde zwei deutsche und zwei englische Präsentationen, Flyer, Pitch-Decks, eine Risikoanalyse, eine Marktanalyse, einen Businessplan und setze einen Server auf? Nein. Nicht manuell.\nAber darum geht es: Der erste Durchlauf ist der steinige Weg. Man iteriert, findet Roadblocks, löst sie. Dann fasst man zusammen, baut einen Skill — und ab dem zweiten Mal läuft das Ding.\nNatürlich ist das Ergebnis nicht perfekt. Ohne eigene Templates, CI-Vorgaben, Bilder und Styleguides sieht alles generisch aus. Aber man hat einen Ausgangspunkt, auf dem man aufbauen kann. Zehn Folien verbessern geht schneller als zehn Folien von Null bauen. Und wer es von Anfang an besser haben will: Einfach eigene Templates, Logos und Styleguides vorher in den Arbeitsordner legen — Cowork nimmt sie als Vorlage und das Ergebnis sieht direkt nach eurem CI aus, nicht nach KI-Einheitsbrei.\nFazit Die Arbeitsweise ist simpel:\nEinmal den steinigen Weg gehen — mit dem Tool gemeinsam Roadblocks dokumentieren — was ging nicht, was war die Lösung Skill bauen lassen — aus dem Erfahrungsschatz Reproduzieren — neuer Inhalt, gleicher Workflow, Bruchteil der Zeit Wer sich mit diesen Tools beschäftigt, ist am Ende schneller. Nicht weil die Tools perfekt sind — sondern weil man lernt, sie richtig einzusetzen.\nNutzt diese Tools. Es lohnt sich.\nThe Claude Cowork Handbook (Revised \u0026amp; Expanded September 2026): Your Complete Guide to Getting Started and Getting More Done With Claude Co Work (The Claude AI Guides 1) (English Edition) Anzeige · Amazon-Partnerlink · Preis auf Amazon MASTER CLAUDE CHAT, COWORK AND CODE: From Prompting to Operational AI Anzeige · Amazon-Partnerlink · Preis auf Amazon ","permalink":"https://aibix.io/blog/von-null-zum-business-paket-in-30-minuten-mit-claude-cowork/","summary":"\u003cfigure class=\"yt-facade\" data-yt-id=\"wRANJUDPMtQ\"\u003e\n  \u003ca class=\"yt-facade__link\" href=\"https://www.youtube.com/watch?v=wRANJUDPMtQ\" rel=\"noopener\" target=\"_blank\"\u003e\n    \u003cimg class=\"yt-facade__thumb\" src=\"/media/youtube/wRANJUDPMtQ.jpg\" alt=\"\" loading=\"lazy\" width=\"1280\" height=\"720\"\u003e\n    \u003cspan class=\"yt-facade__play\" aria-hidden=\"true\"\u003e\u003c/span\u003e\n    \u003cspan class=\"yt-facade__label\"\u003eVideo abspielen\u003c/span\u003e\n  \u003c/a\u003e\n  \u003cfigcaption class=\"yt-facade__note\"\u003e\n    Erst beim Klick wird das Video von YouTube geladen und Ihre IP-Adresse an Google übertragen.\n    Näheres in der \u003ca href=\"/datenschutzerklaerung/\"\u003eDatenschutzerklärung\u003c/a\u003e.\n  \u003c/figcaption\u003e\n\u003c/figure\u003e\n\u003cp\u003eDamit der KI-Opa nicht immer nur erzählt, wie toll alles ist: Ich zeig euch, wie es funktioniert. Hands-on, kein Gelaber.\u003c/p\u003e","title":"Von Null zum Business-Paket in 30 Minuten — mit Claude Cowork"},{"content":"„Ich verstehe diesen ganzen KI-Hype nicht.“ – Diesen Kommentar habe ich gelesen und musste darauf antworten. Nicht genervt, sondern weil ich den Satz vor 30 Jahren genauso über Computer und vor 25 Jahren über das Internet gehört habe. Und weil wir gerade exakt wieder an diesem Punkt stehen.\nVideo abspielen Erst beim Klick wird das Video von YouTube geladen und Ihre IP-Adresse an Google übertragen. Näheres in der Datenschutzerklärung. Die Geschichte wiederholt sich Als der Personal Computer aufkam, war er ein teures Spielzeug für Nerds. Als das Internet kam, war es ein Tummelplatz für zwielichtige Gestalten – einen sinnvollen Nutzen konnte das Ding ja unmöglich haben. Heute gibt es ganze Generationen, die kein Leben ohne Internet kennen. Und genau so wird es Generationen geben, die kein Leben ohne KI kennen werden.\nKI ist nach Computer und Internet das nächste Werkzeug, das unser aller Arbeits- und Alltagsleben nachhaltig verändern wird. Die Fortschritte allein im letzten Jahr sind so gewaltig, dass wir uns langsam auf dem steilen Teil der Kurve befinden. Dem kann sich niemand mehr entziehen.\nYou are holding it wrong Wenn Leute sagen, KI bringe ihnen nichts – dann liegt das in den allermeisten Fällen nicht an der Technologie, sondern daran, wie sie benutzt wird. Nur über ein Chat-Interface draufloszuquatschen und irgendwas zu erwarten: das ist vorgestern.\nWir reden heute von agentischen KI-Tools – Werkzeuge wie Claude Code, Cowork oder andere Coding-Agents. Die können auf Dateisysteme zugreifen, das Web durchsuchen, mit Datenbanken arbeiten, Code schreiben und testen. Die arbeiten 10 bis 18 Stunden am Stück durch und erledigen Aufgaben in Minuten, für die ich früher Tage gebraucht hätte.\nAber: Du musst ihnen den Job richtig erklären. Und dafür gibt es ein System.\nDas 4-Stufen-System: Prompt, Context, Intent, Spec 1. Prompt – Die richtige Anweisung Prompt Engineering ist nicht tot – es ist nach wie vor die Grundlage. Was sage ich dem Modell, was es tun soll? Aber der Prompt allein reicht heute nicht mehr. Er ist nur die erste Schicht.\n2. Context – Das Kontextfenster managen Sprachmodelle haben ein begrenztes Kurzzeitgedächtnis – das Kontextfenster. Es ist nicht gut, wenn das planlos vollgestopft wird. Context Engineering bedeutet: dem Modell gezielt die Informationen geben, die es für genau diesen Job braucht. Das kann über Webseiten-Abruf geschehen, über Vektordatenbanken, Graphdatenbanken – Stichwort RAG (Retrieval Augmented Generation). Der Kontext muss so gestaltet sein, dass er exakt das enthält, was das Modell gerade braucht. Nicht mehr, nicht weniger.\n3. Intent – Ziele und Guardrails definieren Agentische Modelle sind Optimierungsmaschinen. Du gibst ihnen eine Aufgabe und sie optimieren, bis sie fertig sind. Sie geben nicht auf. Sie nehmen Umwege. Sie schießen über das Ziel hinaus. Deshalb muss man neben dem Ziel auch klar formulieren, was unter keinen Umständen passieren soll. Klassische Guardrails: keine eigenmächtigen Credentials beschaffen, bei Unsicherheit anhalten und nachfragen, nichts erfinden. Wer das nicht definiert, der wundert sich, wenn die Maschine eigenkreativ wird.\n4. Spec – Die präzise Spezifikation Zum Schluss die Spezifikation: Was genau soll das Ergebnis sein? Wie soll die App aussehen? Was soll mit diesen Dokumenten passieren? Was erwarte ich als Output? Je präziser die Spec, desto besser das Ergebnis.\nDer Clou: Du musst das nicht alleine können Das Schöne an der ganzen Sache: Man muss kein Meister im Schreiben von Prompts, Kontexten oder Spezifikationen sein. Man kann die KI selbst nutzen, um diese vier Bausteine gemeinsam zu entwickeln. Setz dich hin, öffne ein Chat-Interface und sag:\n„Ich möchte Folgendes erreichen: [Ziel]. Lass uns gemeinsam einen Prompt, den relevanten Kontext, Intent mit Guardrails und eine Spec dafür entwickeln.“\nIm ersten Schritt baust du dir mit der KI die vier Bausteine. Im zweiten Schritt drückst du einer neuen Session genau diese Bausteine in die Hand – und dann rennt die Maschine los und arbeitet, ohne große Rückfragen, genau das ab, was du dir vorgestellt hast.\nAus der Praxis Aufgaben, die vor einem Jahr noch nicht funktionierten, die vor einem halben Jahr nur mit ständigem Händchenhalten liefen – die werden heute in fünf bis zehn Minuten abgefrühstückt. Du denkst, du hast das Ding für den ganzen Vormittag beschäftigt, und nach zehn Minuten steht es da und will die nächste Aufgabe.\nMir ist neulich morgens beim Kaffee eingefallen: Lass uns doch mal ein Konsolenprogramm bauen, eine Art erweitertes TUI-Tool. Am Abend war das Ding fertig. Oder: „Hier habe ich ein paar Repos, die Dokumentation passt nicht zusammen – sortier das mal aus.“ Ratzfatz hatte ich sauber dokumentierte Repositories. Dafür hätte ich früher eine Woche gebraucht.\nUnd nein, die halluzinieren nicht, wenn man ihnen einen sauberen Kontext vorgibt. Wenn die Information nicht da ist, sagen sie das auch. Man muss es ihnen nur sagen – und genau dafür ist das Intent-Thema da.\nDranbleiben oder abgehängt werden KI ist das neue Office. Genauso wie wir damals Excel, Word und PowerPoint lernen mussten, müssen wir uns jetzt ein neues Skillset aneignen. Der Unterschied: Es entwickelt sich momentan alle paar Monate weiter. Da muss man am Ball bleiben.\nJetzt ist die Gelegenheit, das mitzuerleben, wenn es gerade losgeht. Sich hinzusetzen und ein paar Sachen auszuprobieren – unbezahlbar. Denn eines ist sicher: Es geht nicht mehr weg. Und dein Arbeitskollege, der sich nicht verschließt, der ist derjenige, der den größten Output produziert.\nDenk mal drüber nach.\nGenerative KI-Systeme entwickeln: KI-Engineering für die Praxis – vom Prompt Engineering bis zu RAG und Agenten Anzeige · Amazon-Partnerlink · Preis auf Amazon Prompt Engineering for LLMs: The Art and Science of Building Large Language Model-Based Applications Anzeige · Amazon-Partnerlink · Preis auf Amazon Prompting kurz \u0026amp; gut: Large Language Models verstehen, ChatGPT \u0026amp; Co. professionell nutzen Anzeige · Amazon-Partnerlink · Preis auf Amazon ","permalink":"https://aibix.io/blog/ki-ist-kein-hype-es-ist-das-neue-internet-und-du-verpasst-es-gerade/","summary":"\u003cp\u003e\u003cstrong\u003e„Ich verstehe diesen ganzen KI-Hype nicht.“\u003c/strong\u003e – Diesen Kommentar habe ich gelesen und musste darauf antworten. Nicht genervt, sondern weil ich den Satz vor 30 Jahren genauso über Computer und vor 25 Jahren über das Internet gehört habe. Und weil wir gerade exakt wieder an diesem Punkt stehen.\u003c/p\u003e","title":"KI ist kein Hype – es ist das neue Internet. Und du verpasst es gerade."},{"content":"Dann müssen wir da eben selbst was bauen … Wer schon mal einen Streamer mit sauberem Webcam-Overlay gesehen hat — kein Greenscreen, einfach die Person freischwebend über dem Gameplay — der hat mit hoher Wahrscheinlichkeit NVIDIA Broadcast bei der Arbeit beobachtet. Eine App, die per GPU den Hintergrund in Echtzeit entfernt — und sie ist hervorragend. Saubere Kanten um die Haare, weiche Übergänge bei schnellen Bewegungen, null Konfiguration. Ich hab sie jahrelang unter Windows benutzt. Funktioniert einfach.\nDann habe ich mir vorgenommen auf Linux umzusteigen.\nNVIDIA Broadcast gibt es nicht für Linux. Nicht „ist in der Beta“, nicht „gibt’s ’nen Workaround“ — es existiert schlicht und einfach nicht. Die zugrundeliegenden SDKs (Maxine, VFX SDK) sind zwar verfügbar, aber kostenpflichtig. NVIDIA möchte, dass ich für KI-Features auf der GPU, die ich bereits gekauft habe, nochmal extra zahle. Für ein Feature, das unter Windows kostenlos ist.\nIhr werdet euch jetzt fragen was das soll, warum macht der das? Ganz einfach:\nhabe ich keine AMD oder Intel GPU zur Hand, kann also nicht testen was Claude fabriziert. Je weniger Code der verstehen muss desto besser funktioniert er (bilde ich mir zumindest ein). Vor ein paar Monaten wäre das ein Dealbreaker gewesen. Ich bin kein Softwareentwickler. C++ und CUDA sind nicht meine Welt. Aber wir leben in interessanten Zeiten: Ich hab Claude Code aufgemacht und angefangen auszuprobieren was damit inzwischen so geht.\nDie Diagnose obs-backgroundremoval ist ein beeindruckendes Stück Open-Source-Software. Vier Jahre Entwicklung, acht KI-Modelle, Support für jede Plattform und jeden GPU-Hersteller — Windows, macOS, Linux, NVIDIA, AMD, Intel, CPU-Fallback. Das ist ein ausgereiftes Projekt, und was jetzt kommt, ist ausdrücklichkein Bashing des Projekts oder seines Autors. Die haben ein Cross-Platform-Plugin gebaut, das auf beinahe allem läuft. Was ich gemacht habe, ist das genaue Gegenteil: alles außer einem einzigen Ziel rauswerfen. Das ist kein bessererAnsatz — das ist ein anderer. Und genau darum geht’s in diesem Post: zeigen, was möglich ist, wenn man sich KI-Tools zunutze macht, um ein sehr spezifisches Problem zu lösen.\nVideo herunterladen Für meinen Use Case — Linux, NVIDIA-GPU, Echtzeit-Streaming — war das Plugin nahezu unbenutzbar.\nDas Plugin erledigt die gesamte KI-Schwerarbeit auf der CPU, während die GPU Däumchen dreht. Schlimmer noch: Es verarbeitet jedes Bild synchron — die gesamte OBS-Video-Pipeline steht still und wartet, während das KI-Modell grübelt, ob dieser Pixelhaufen jetzt eine Schulter ist oder ein Bücherregal. Das Resultat: Frame Drops, sichtbares Ruckeln, und Maskenkanten, die aussehen, als hätte jemand mit der Bastelschere um mich herumgeschnitten. Beim Streamen sieht das dann so aus wie im Video oben: Du bewegst den Kopf, und die Maske zieht eine halbe Sekunde später hinterher, außerdem ist sie nicht exakt genug.\nWas nun?\nDas Ziel: Echtzeit-Hintergrundentfernung in 1080p bei 30fps mit weichen Kanten in Broadcast-Qualität. Mit einer RTX 2060 Super.\nTabula Rasa Die erste „Änderung“ war die gröbste. Ich hab Claude Code losgeschickt alles zu löschen was nicht „NVIDIA auf Linux“ war. Windows-Support — weg. macOS — weg. AMD, Intel, CPU-Fallback — alles weg. Vier Jahre sorgfältiger Cross-Platform-Arbeit mal eben entfernt.\nDer reinste Vandalismus, sorry dafür. Aber sobald das alles raus war, wurde der kritische Pfad von einem Labyrinth aus #ifdefs zu Code, über den man tatsächlich nachdenken kann.\nManchmal ist das Produktivste, was man tun kann: Löschen.\nDie Optimierung Claude Code hat hier den gesamten Code geschrieben. Mein Job war: Ideen liefern, Richtungsentscheidungen treffen und jeden Zwischenstand testen. Ein Kreislauf aus „Versuch mal X“ → Code → Testen → „Nee, probier’s anders.“\nAsynchrone Verarbeitung. Das Original-Plugin blockierte die gesamte OBS-Video-Pipeline während der Inferenz — jedes Bild wartete, bis die KI fertig war. Lösung: eine threadsichere Warteschlange. OBS schiebt Bilder rein, ein separater Thread verarbeitet sie im Hintergrund, und das nächste Bild greift sich das jeweils letzte Ergebnis. Frame Drops: sofort weg. Der Haken: Die Maske lief jetzt 2-3 Bilder hinter dem Video her. Würde ich später fixen. (Spoiler: Es wurde kompliziert.)\nSpeicher-Diät. Das Plugin kopierte komplette 1080p-Bilder — 8 Megabyte pro Stück — mehrfach pro Frame. Einmal fürs Preprocessing, einmal für den Worker-Thread, einmal für die Ausgabe. Bei 30fps sind das rund 750 MB/s reiner Abfall. Die Lösung: Statt Daten zu kopieren, einfach die Zeiger auf die Daten tauschen — der Computer merkt sich nur, wo das Bild liegt, statt es jedes Mal komplett umzuschaufeln.\nGPU-Preprocessing. Fünf separate CPU-Operationen — Farbkonvertierung, Skalierung, Normalisierung, Formatkonvertierung, Layout-Transposition — ersetzt durch einen einzigen GPU-Kernel, der alles in einem Durchgang erledigt. Preprocessing sank von 3ms auf 1,8ms. Kein Gamechanger allein, aber bei einem Gesamtbudget von 33ms pro Frame zählt jede Millisekunde.\nWissen, wann man aufhört. Das Postprocessing (Glättung, Kantenbereinigung) operierte auf 61 Kilobyte Daten. Das passt komplett in den CPU-Cache. Das auf die GPU zu verschieben wäre tatsächlich langsamer gewesen, weil allein der Datentransfer länger dauern würde als die Berechnung selbst. Nicht alles muss auf der GPU laufen. Manchmal ist die langweilige Antwort die richtige.\nTensorRT. Automatische Erkennung und Engine-Caching für einen Extra-Geschwindigkeitsboost auf Systemen, die es unterstützen (also RTX 2000 und neuer) — mit sauberem Fallback auf CUDA, wenn nicht.\nDie Zahlen sahen auf dem Papier besser aus.\nAber die Maske hing immer noch sichtbar hinter meinen Kopfbewegungen her:\nVideo herunterladen Wo es schmerzhaft wurde Verdächtiger Nr. 1: Frame-Skipping. Das Plugin hatte einen „Ähnlichkeitscheck“, der aufeinanderfolgende Bilder in voller Auflösung verglich, um zu entscheiden, ob die Inferenz übersprungen werden kann. Klingt clever — warum identische Frames verarbeiten? Nur dass es 8-Megabyte-Bilder Pixel für Pixel verglich und 57% aller Frames übersprang. Abgeschaltet. Lagged immer noch.\nVerdächtiger Nr. 2: Masken-Qualität. Wechsel von harten Binärmasken (jeder Pixel ist entweder „Du“ oder „nicht Du“) auf weiche Alpha-Matten — die Rohwahrscheinlichkeit des KI-Modells, bei der Kanten sanfte Übergänge bekommen statt harter Stufen. Echte Qualitätsverbesserung. Lagged immer noch.\nSackgasse: FP16. Halbpräzisions-Version des Modells geladen. OBS crashte beim Start — das Modell erwartete 16-Bit-Eingaben, der Code lieferte 32-Bit. Versuch, das Modell manuell zu konvertieren. Ergebnis: ein kaputter Berechnungsgraph, in dem manche Operationen 16-Bit und andere 32-Bit bekamen. Aufgegeben. Manchmal gewinnt man, manchmal lernt man, und manchmal löscht man den Branch und tut so, als wäre nichts gewesen.\nDer Profiler rettet den Tag. NVIDIAs Nsight Systems — ein Profiling-Tool, das zeigt, wo genau die Zeit verbrannt wird. Die Ergebnisse waren ernüchternd:\nStufe Zeit Nachbearbeitung (Kantenverfeinerung) 13,9ms KI-Modell-Inferenz 7,7ms GPU-Preprocessing 1,8ms Der Kantenverfeinerungs-Filter, den wir zur Verbesserung der Qualität hinzugefügt hatten, brauchte fast doppelt so lang wie die KI-Inferenz selbst. Die „Verbesserung“ war der Flaschenhals. Rausgerissen. Lektion gelernt: Vorher und nachher profilen, nicht nur vorher.\nLagged immer noch. Ohne den Flaschenhals lag die Inferenz bei etwa 10ms. Mehr als schnell genug. Also warum hing die Maske immer noch hinterher? Ich hab Claude analysieren lassen bis der Groschen fiel.\nDie asynchrone Pipeline selbst war das Problem. Sie fügt bauartbedingt 2-3 Frames Latenz hinzu — der Worker-Thread verarbeitet immer ein Bild aus der Vergangenheit. Bei 30fps sind das 66-100ms Verzögerung. Sichtbar. Störend. Innerhalb einer asynchronen Architektur nicht behebbar.\nAber: 10ms Inferenz passen locker in ein 33ms-Frame-Budget. Das Modell war schnell genug, um synchron zu laufen — Bild verarbeiten und Ergebnis im selben Tick liefern, null Latenz. Die asynchrone Queue, die uns am Anfang vor Frame Drops gerettet hatte, hielt uns jetzt zurück.\nEin simpler Check: Wenn das Modell schnell genug ist, Queue überspringen und die Inferenz direkt inline ausführen. Die Maske ging von „hinkt hinterher“ zu „trackt viel besser.“ Null Frames Verzögerung (nicht die Maske sondern die Pipeline, das merkt man nur wenn man davor sitzt und das Video hinter den eigenen Bewegungen ein bisschen her hinkt).\nLies das Paper, nicht nur die API Nach dem gelöschten Code, den GPU-Kernels, der Async-dann-doch-Sync-Pipeline, dem Profiling und den Sackgassen — kam die mit Abstand größte Verbesserung des ganzen Projekts. Und sie kam weder aus Code-Optimierung noch aus meiner Richtung. Claude hat sich das Research Paper zum KI-Modell durchgelesen.\nDas Plugin fütterte das KI-Modell (RVM — Robust Video Matting) mit vorgeschrumpften 320×192-Bildern und streckte die resultierende winzige Maske dann wieder auf 1080p. Natürlich waren die Kanten matschig. Man kann eine 320 Pixel breite Maske nicht einfach hochskalieren und knackige Haarsträhnen erwarten.\nWas Claude im Paper fand: RVM hat einen eingebauten Deep Guided Filter. Das Modell ist dafür konzipiert, das volle 1080p-Bild zu empfangen, es intern für die schnelle Inferenz herunterzurechnen, und dann das originale hochauflösende Bild als Orientierung zu nutzen, um die Maske auf volle Auflösung hochzuschärfen. Es benutzt die tatsächlichen Kanten im Webcam-Bild — Haare, Finger, die Konturen des Hoodies — um pixelgenaue Grenzen zu erzeugen. Schon besser.\nVideo herunterladen Das Plugin umging das komplett. Durch das Vorverkleinern des Bildes und downsample_ratio=1.0 bekam der Guided Filter identische „niedrigauflösende“ und „hochauflösende“ Eingaben. Er war effektiv ein No-Op — er lief zwar, hatte aber nichts, womit er arbeiten konnte. Das beste Feature des Modells wurde einfach übersprungen.\nDer Fix:\nstatic constexpr int INPUT_WIDTH = 1920; static constexpr int INPUT_HEIGHT = 1080; static constexpr float DOWNSAMPLE_RATIO = 0.25f; Drei Zeilen. Gib ihm das echte Bild. Lass das Modell das tun, wofür es gebaut wurde.\nDas Backbone läuft intern weiterhin auf niedriger Auflösung, aber der Deep Guided Filter muss jetzt bei voller 1080p arbeiten — die GPU hat mehr zu tun, passt aber immer noch bequem ins 33ms-Budget. Ich hab den Stream gestartet, die Kamera angemacht und es war tatsächlich besser. Von „ausgeschnitten mit der Bastelschere“ zu beinahenatürlichen Kanten.\nDas Ergebnis Video herunterladen Vorher Nachher Frame Drops bei 1080p Häufig Keine Masken-Latenz 2-3 Frames (66-100ms) 0 Frames Kantenqualität Hart, zackig Weichere Übergänge GPU-Auslastung ~15% ~70% Gesamte Frame-Zeit \u0026gt;33ms (zu langsam) ~20ms (Luft nach oben) An dieser Stelle machen wir einen Break, die Lösung ist immer noch nicht wirklich brauchbar, aber schon eine ganze Ecke weiter. Vor allem 70% GPU Auslastung „nur dafür“, das muss noch besser gehen. Doch dazu mehr im nächsten Beitrag.\nZum Abschluss möchte ich noch einmal reflektieren.\nVor einem Jahr wäre dieses Problem für mich unlösbar gewesen. Nicht „schwierig“ — unlösbar. GPU-optimierte Echtzeit-Video-Pipelines in C++ sind keine Sache, die man sich an einem Nachmittag beibringt. Aber mit Tools wie Claude Code verschiebt sich, was „zu schwierig“ bedeutet. Nicht, weil die KI alles besser kann — sie braucht Richtung, Feedback, jemanden, der testet und entscheidet. Aber sie gibt einem die Möglichkeit, Probleme anzupacken, die vorher schlicht außer Reichweite waren. Es bleibt also spannend.\nDas hier ist Teil 1 meiner Linux-Journey. Als Nächstes: Die Middleware komplett rauswerfen — eine eigenständige TensorRT-Pipeline, die direkt von der Kamera zur virtuellen Webcam geht, in unter 7ms. Die Reise geht weiter.\n-GF\nCODE, NICHT POWERPOINTS: Wie ich mit Claude Code, Skills und n8n mehr automatisiere als ganze Berater-Teams – und Sie das auch können (KI für Business) Anzeige · Amazon-Partnerlink · Preis auf Amazon Claude Code for Product Managers: Harnessing Agentic AI for Strategic Outcomes Anzeige · Amazon-Partnerlink · Preis auf Amazon ","permalink":"https://aibix.io/blog/kein-nvidia-broadcast-fuer-linux-na-und/","summary":"\u003ch3 id=\"dann-müssen-wir-da-eben-selbst-was-bauen-\"\u003eDann müssen wir da eben selbst was bauen …\u003c/h3\u003e\n\u003cp\u003eWer schon mal einen Streamer mit sauberem Webcam-Overlay gesehen hat — kein Greenscreen, einfach die Person freischwebend über dem Gameplay — der hat mit hoher Wahrscheinlichkeit NVIDIA Broadcast bei der Arbeit beobachtet. Eine App, die per GPU den Hintergrund in Echtzeit entfernt — und sie ist \u003cem\u003ehervorragend\u003c/em\u003e. Saubere Kanten um die Haare, weiche Übergänge bei schnellen Bewegungen, null Konfiguration. Ich hab sie jahrelang unter Windows benutzt. Funktioniert einfach.\u003c/p\u003e","title":"Kein NVIDIA Broadcast für Linux? Na und?"},{"content":"Warum die Whitelist nicht funktioniert (und wie man es richtig macht) Wer in OPNsense die Unbound-DNS-Blocklisten nutzt (z. B. Steven Black oder YoYo), kennt vermutlich das Problem: Man trägt eine Domain in die Whitelist ein — und sie wird trotzdem geblockt. Was auf den ersten Blick wie ein Bug aussieht, hat zwei konkrete Ursachen.\nDas Problem: Einfache Domain-Einträge reichen nicht Angenommen, man möchte beispiel-domain.com freigeben und trägt sie brav in das Feld Whitelist Domains unter Services → Unbound DNS → Blocklist ein. Das Ergebnis: Die Hauptdomain wird vielleicht durchgelassen, aber Subdomains wie track.beispiel-domain.com oder click.beispiel-domain.com bleiben weiterhin geblockt.\nUrsache 1: CNAME-Bug Es gibt einen bekannten Bug in der DNSBL-Implementierung: Wenn eine freigegebene Domain ein CNAME-Record ist, der auf eine geblockte Domain zeigt, wird sie trotzdem geblockt. Man müsste also zusätzlich die Zieldomain des CNAME-Records whitelisten — was mühsam und fehleranfällig ist.\nUrsache 2: Subdomains werden nicht erfasst Ein einfacher Eintrag wie beispiel-domain.com matcht eben nur genau diese Domain. Subdomains sind nicht automatisch eingeschlossen.\nDie Lösung: Regex in der Whitelist Was viele nicht wissen: Das Whitelist-Feld unterstützt reguläre Ausdrücke. Damit lässt sich eine Domain inklusive aller Subdomains auf einen Schlag freigeben.\nDas Pattern dafür sieht so aus:\n(.*)?(\\.)?beispiel-domain.com Dieser Ausdruck matcht sowohl beispiel-domain.com selbst als auch beliebige Subdomains wie track.beispiel-domain.com, click.beispiel-domain.com usw.\nWo wird das eingetragen? Ganz normal im Feld Whitelist Domains unter Services → Unbound DNS → Blocklist. Pro Zeile ein Eintrag — entweder eine einfache Domain oder eben ein Regex-Pattern.\nFehlerdiagnose Wenn ein Regex-Ausdruck ungültig ist, erscheint im Log unter /var/log/resolver/latest.log eine Meldung wie:\nblocklist download : skip invalid whitelist exclude pattern \u0026#34;custom_pattern_1\u0026#34; (*\\.example.net) Der Stern allein (*\\.example.net) ist kein gültiger Regex — man braucht das vollständige Pattern mit (.*)?(\\.)?.\nFazit Wer Domains in der OPNsense-Unbound-Blocklist zuverlässig whitelisten will, sollte immer das Regex-Pattern (.*)?(\\.)?domain.com verwenden. Der einfache Domain-Eintrag ohne Regex funktioniert in vielen Fällen schlicht nicht — insbesondere bei Subdomains und CNAME-Auflösungen.\nQuelle: OPNsense Forum – White Listed Domains not working in Unbound DNS: Blocklist\n-GF\nDer OPNsense-Praktiker: Enterprise-Firewalls mit Open Source Anzeige · Amazon-Partnerlink · Preis auf Amazon CWWK Mini PC Core i3 N300 Firewall Appliance, OPNsense Mini Computer mit 6 Port i226-V 2.5GbE LAN, F5 Fanless Micro PC ohne RAM/SSD/OS, USB Type-C, 4K 3-Display, TF, AES-NI N300 6LAN NO RAM NO SSD Anzeige · Amazon-Partnerlink · Preis auf Amazon ","permalink":"https://aibix.io/blog/opnsense-unbound-dns/","summary":"\u003ch3 id=\"warum-die-whitelist-nicht-funktioniert-und-wie-man-es-richtig-macht\"\u003eWarum die Whitelist nicht funktioniert (und wie man es richtig macht)\u003c/h3\u003e\n\u003cp\u003eWer in OPNsense die Unbound-DNS-Blocklisten nutzt (z. B. Steven Black oder YoYo), kennt vermutlich das Problem: Man trägt eine Domain in die Whitelist ein — und sie wird trotzdem geblockt. Was auf den ersten Blick wie ein Bug aussieht, hat zwei konkrete Ursachen.\u003c/p\u003e","title":"OPNsense Unbound DNS:"},{"content":" Dieses Problem hat mich kürzlich mehr Zeit gekostet, als ich zugeben möchte – und die Ursache war so subtil wie frustrierend.\naibix\nDas Symptom\nEin Docker-Container wird gestartet, der Dienst darin läuft korrekt und beantwortet Anfragen. Doch im Traefik-Dashboard taucht er schlicht nicht auf. Kein Router, kein Service, keine Fehlermeldung. Nichts.\nMan prüft die Labels, die Netzwerkkonfiguration, die Docker-Socket-Verbindung – alles sieht korrekt aus. Und doch: Traefik weigert sich, den Container zu routen.\nDie Ursache: Hardcodierte Healthchecks\nViele Docker-Images bringen einen eingebauten HEALTHCHECK mit. Im Dockerfile sieht das typischerweise so aus:\n```dockerfile HEALTHCHECK CMD [ \u0026#34;curl\u0026#34;, \u0026#34;-f\u0026#34;, \u0026#34;http://localhost:8080/health\u0026#34; ] Das Problem entsteht, wenn der Dienst im Container auf einem anderen Port gestartet wird – etwa weil man --port 8000 als Argument übergibt oder eine Umgebungsvariable den Port ändert. Der Healthcheck prüft weiterhin localhost:8080, dort antwortet aber niemand. Docker markiert den Container daraufhin als unhealthy.\nUnd genau hier greift Traefik’s Docker-Provider: Container, die den Status unhealthy haben, werden stillschweigend aus dem Routing ausgeschlossen. Kein Fehler im Dashboard, keine Warnung im Standard-Log. Erst auf Loglevel debug erscheint die Meldung „Filtering unhealthy or starting container“ – und selbst die ist leicht zu übersehen.\nDieses Verhalten ist fest im Docker-Provider von Traefik verankert. Es gibt keine Konfigurationsoption, um es abzuschalten. Entsprechende Feature-Requests existieren seit Jahren (z.B. traefik/traefik#7842), wurden aber bislang nicht umgesetzt.\nDie Fehlerkette im Detail\nDer Container startet mit einem vom Standard abweichenden Port (z.B. 8000) Der Dienst bindet sich an diesen Port und funktioniert einwandfrei Docker’s Healthcheck prüft den im Image hartkodierten Port (z.B. 8080) – Verbindung abgelehnt Docker setzt den Container-Status auf unhealthy Traefik erkennt den Status und schließt den Container komplett vom Routing aus Im Dashboard und in den Standard-Logs gibt es keinen Hinweis auf das Problem Lösungen\nVariante A: Internen Port beibehalten, extern mappen\nDie einfachste und robusteste Lösung: Den Container-internen Port beim Standard belassen und Docker’s Port-Mapping nutzen, um den Dienst auf dem gewünschten Host-Port verfügbar zu machen.\n```bash docker run -d -p 3010:8080 mein-image:latest Der Healthcheck funktioniert, Traefik sieht einen gesunden Container, und der Dienst ist extern auf Port 3010 erreichbar. In der Traefik-Konfiguration zeigt der Loadbalancer weiterhin auf den internen Port:\n```yaml labels: - \u0026#34;traefik.http.services.mein-service.loadbalancer.server.port=8080\u0026#34; Variante B: Healthcheck zur Laufzeit überschreiben\nWenn ein anderer interner Port zwingend erforderlich ist, kann der Healthcheck beim Start des Containers angepasst werden:\n```bash docker run --health-cmd \u0026#34;curl -f http://localhost:3010/health\u0026#34; mein-image:latest Oder in docker-compose.yml:\n```yaml services: mein-service: image: mein-image:latest healthcheck: test: [\u0026#34;CMD\u0026#34;, \u0026#34;curl\u0026#34;, \u0026#34;-f\u0026#34;, \u0026#34;http://localhost:3010/health\u0026#34;] interval: 30s timeout: 10s retries: 3 Variante C: Healthcheck deaktivieren\nFalls kein Healthcheck benötigt wird, lässt er sich komplett abschalten:\n```bash docker run --no-healthcheck mein-image:latest ``` Oder in docker-compose.yml:\n```yaml healthcheck: test: [\u0026#34;NONE\u0026#34;] Ohne definierten Healthcheck meldet Docker keinen Gesundheitsstatus, und Traefik hat keinen Grund, den Container zu filtern.\nFazit\nDieses Problem ist ein Paradebeispiel für eine Fehlerkette, bei der zwei an sich sinnvolle Mechanismen – Docker-Healthchecks und Traefik’s Container-Filterung – in Kombination zu schwer auffindbarem Fehlverhalten führen. Besonders tückisch ist die völlige Abwesenheit von Fehlermeldungen auf Standard-Loglevel.\nWer Traefik als Reverse-Proxy für Docker-Container einsetzt, sollte bei unerklärlichem Routing-Verhalten immer als Erstes den Health-Status der betroffenen Container prüfen:\n```bash docker inspect --format=\u0026#39;{{.State.Health.Status}}\u0026#39; container-name Zeigt dieser unhealthy, ist die Ursache mit hoher Wahrscheinlichkeit gefunden – auch wenn der Dienst selbst einwandfrei läuft.\n-GF\nKeine Produkte gefunden.\n","permalink":"https://aibix.io/blog/wenn-traefik-kranke-container-aussortiert/","summary":"\u003cblockquote\u003e\n\u003cp\u003eDieses Problem hat mich kürzlich mehr Zeit gekostet, als ich zugeben möchte – und die Ursache war so subtil wie frustrierend.\u003c/p\u003e\n\u003cp\u003eaibix\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e\u003cstrong\u003eDas Symptom\u003c/strong\u003e\u003cbr\u003e\nEin Docker-Container wird gestartet, der Dienst darin läuft korrekt und beantwortet Anfragen. Doch im Traefik-Dashboard taucht er schlicht nicht auf. Kein Router, kein Service, keine Fehlermeldung. Nichts.\u003c/p\u003e","title":"Wenn Traefik kranke Container aussortiert"},{"content":"Beim Upgrade einer selbstgehosteten GitLab-Instanz von 18.1 auf 18.6 kann es zu unerwarteten HTTP-400-Fehlern kommen, etwa bei der Nutzung von glab mr create. Besonders betroffen sind Setups, bei denen GitLab hinter einem Reverse-Proxy wie Traefik betrieben wird.\nDas Symptom API-Aufrufe wie:\nGET /api/v4/projects/group%2Fprojektname schlagen mit 400 Bad Request fehl – obwohl sie in älteren GitLab-Versionen problemlos funktionierten.\nDie Ursache Zwei Änderungen treffen hier aufeinander:\nGitLab API Viele API-Endpoints (u. a. Projects, Merge Requests, Resource Groups) akzeptieren Projekt-IDs entweder als numerische ID oder als URL-kodierten Projektpfad. Moderne GitLab-Versionen sind strikter und erwarten korrekt URL-kodierte Pfade (%2F statt /). Traefik (v3.6.3+) Aus Sicherheitsgründen blockiert Traefik standardmäßig kodierte Sonderzeichen im URL-Pfad, darunter %2F. Solche Requests werden direkt von Traefik mit HTTP 400 abgelehnt und erreichen GitLab gar nicht. Das Ergebnis: GitLab „funktioniert nicht mehr“, obwohl in Wirklichkeit der Proxy die Anfrage verwirft.\nDie Lösung In Traefik muss das Zulassen kodierter Slashes global auf EntryPoint-Ebene aktiviert werden:\nentryPoints: https: address: \u0026#34;:443\u0026#34; http: encodedCharacters: allowEncodedSlash: true Nach einem Neustart von Traefik werden API-Requests mit %2F korrekt weitergeleitet, und Tools wie glab funktionieren wieder wie erwartet.\nFazit Der Fehler liegt weder bei glab noch bei GitLab selbst, sondern in einer Sicherheitsverschärfung von Traefik, die mit den strengeren API-Anforderungen neuer GitLab-Versionen kollidiert. Wer GitLab hinter Traefik betreibt, sollte diese Einstellung prüfen – insbesondere nach Updates.\nKurz gesagt: GitLab wollte korrekt kodierte URLs, Traefik hat sie blockiert.\n","permalink":"https://aibix.io/blog/gitlab-18-x-hinter-traefik-warum-ploetzlich-http-400-bei-api-calls-auftreten/","summary":"\u003cp\u003eBeim Upgrade einer selbstgehosteten GitLab-Instanz von \u003cstrong\u003e18.1 auf 18.6\u003c/strong\u003e kann es zu unerwarteten \u003cstrong\u003eHTTP-400-Fehlern\u003c/strong\u003e kommen, etwa bei der Nutzung von \u003ccode\u003eglab mr create\u003c/code\u003e. Besonders betroffen sind Setups, bei denen GitLab \u003cstrong\u003ehinter einem Reverse-Proxy wie Traefik\u003c/strong\u003e betrieben wird.\u003c/p\u003e","title":"GitLab 18.x hinter Traefik: Warum plötzlich HTTP 400 bei API-Calls auftreten"},{"content":"Warum GPU-Sharing mit LXC-Containern? Wenn du einen Proxmox-Server mit einer GPU betreibst und verschiedene Dienste wie Ollama (für KI-Modelle), Plex (für Medien-Transcoding) oder Frigate (für Videoüberwachung) mit Hardware-Beschleunigung nutzen möchtest, stehst du vor einer wichtigen Entscheidung.\nDie zwei Optionen:\nGPU-Passthrough zu einer VM: Funktioniert gut, aber die GPU kann nur an EINE einzige VM weitergegeben werden GPU-Sharing mit LXC-Containern: Mehrere Container können sich die GPU gleichzeitig teilen Da die meisten von uns ihre Dienste isoliert voneinander betreiben möchten, ist Option 2 mit LXC-Containern oft die bessere Wahl. Der einzige „Nachteil“: Du musst LXC-Container statt VMs verwenden – was für die meisten Standalone-Dienste aber kein Problem darstellt.\nVoraussetzungen Bevor wir loslegen, stelle sicher, dass folgende Voraussetzungen erfüllt sind:\nProxmox VE 8.2+ oder 9.0 (empfohlen für Web-UI Device Passthrough) Eine unterstützte GPU (NVIDIA, AMD oder Intel) Root-Zugriff auf den Proxmox-Host Grundkenntnisse in der Linux-Kommandozeile 💡 Neu in Proxmox VE 9.0: Die Version 9.0 (veröffentlicht im August 2025) basiert auf Debian 13 „Trixie“ mit Linux Kernel 6.14.8-2 und bringt LXC 6.0.4 mit verbesserter Ressourcenverwaltung und Cgroup v2-Integration. Die Web-UI Device Passthrough Funktion wurde bereits in Version 8.2.7 eingeführt und ist in Version 9.0 weiter optimiert.\nWichtiger Hinweis: Falls du bereits GPU-Passthrough für VMs konfiguriert hast (mit Blacklisting von Treibern etc.), musst du diese Änderungen rückgängig machen. LXC-Container benötigen funktionierende Treiber auf dem Host!\nModerne Methode: Web-UI Device Passthrough (Proxmox 8.2.7+) Seit Proxmox VE 8.2.7 gibt es eine deutlich einfachere Methode für GPU-Passthrough zu LXC-Containern über die Web-Oberfläche. Diese Methode funktioniert sogar mit unprivilegierten Containern!\nSchritt 1: GPU im Web-UI hinzufügen Wähle deinen Container in der Proxmox Web-UI aus Gehe zu Resources Klicke auf Add → Device Passthrough Gib den Device-Pfad ein (z.B. /dev/dri/card0 für Intel/AMD oder /dev/nvidia0 für NVIDIA) Klicke auf Advanced und setze: Access Mode: 0666 GID: 104 (render group) für unprivilegierte Container UID: Optional, je nach Anwendung Diese Methode ersetzt die manuelle Konfiguration mit lxc.cgroup2.devices.allow und lxc.mount.entry Einträgen!\nNVIDIA GPU Konfiguration Schritt 1: NVIDIA-Treiber auf dem Host installieren Zuerst müssen die NVIDIA-Treiber auf dem Proxmox-Host installiert werden. Lade den passenden Treiber von der NVIDIA-Website herunter.\n# Vorhandene NVIDIA-Pakete entfernen (wichtig!) apt remove --purge nvidia* libnvidia* libnvcuvid1 # Nouveau-Treiber blacklisten echo \u0026#34;blacklist nouveau\u0026#34; \u0026gt;\u0026gt; /etc/modprobe.d/blacklist.conf update-initramfs -u # System neustarten reboot # NVIDIA-Treiber installieren (Beispiel für Version 550.127.05) wget https://us.download.nvidia.com/XFree86/Linux-x86_64/550.127.05/NVIDIA-Linux-x86_64-550.127.05.run chmod +x NVIDIA-Linux-x86_64-550.127.05.run ./NVIDIA-Linux-x86_64-550.127.05.run --dkms Schritt 2: GPU-Geräte identifizieren Nach der Installation überprüfe die NVIDIA-Geräte:\n# NVIDIA-Geräte anzeigen ls -l /dev/nvidia* # Ausgabe sollte etwa so aussehen: crw-rw-rw- 1 root root 195, 0 Nov 25 10:00 /dev/nvidia0 crw-rw-rw- 1 root root 195, 255 Nov 25 10:00 /dev/nvidiactl crw-rw-rw- 1 root root 507, 0 Nov 25 10:00 /dev/nvidia-uvm crw-rw-rw- 1 root root 507, 1 Nov 25 10:00 /dev/nvidia-uvm-tools Schritt 3: Container konfigurieren Option A: Web-UI Methode (empfohlen für Proxmox 8.2.7+/9.0)\nFüge über Resources → Add → Device Passthrough folgende Geräte hinzu:\n/dev/nvidia0 mit Mode: 0666 /dev/nvidiactl mit Mode: 0666 /dev/nvidia-uvm mit Mode: 0666 /dev/nvidia-uvm-tools mit Mode: 0666 /dev/nvidia-modeset mit Mode: 0666 (falls vorhanden) Option B: Manuelle Methode (für ältere Versionen)\nBearbeite die Container-Konfiguration (ersetze 100 mit deiner Container-ID):\nnano /etc/pve/lxc/100.conf Füge folgende Zeilen hinzu (passe die Zahlen an deine Geräte an):\n# NVIDIA GPU Support lxc.cgroup2.devices.allow: c 195:* rwm lxc.cgroup2.devices.allow: c 507:* rwm lxc.mount.entry: /dev/nvidia0 dev/nvidia0 none bind,optional,create=file lxc.mount.entry: /dev/nvidiactl dev/nvidiactl none bind,optional,create=file lxc.mount.entry: /dev/nvidia-uvm dev/nvidia-uvm none bind,optional,create=file lxc.mount.entry: /dev/nvidia-uvm-tools dev/nvidia-uvm-tools none bind,optional,create=file lxc.mount.entry: /dev/nvidia-modeset dev/nvidia-modeset none bind,optional,create=file Schritt 4: NVIDIA-Treiber im Container installieren Starte den Container und installiere die gleiche Treiberversion:\n# Im Container ausführen: wget https://us.download.nvidia.com/XFree86/Linux-x86_64/550.127.05/NVIDIA-Linux-x86_64-550.127.05.run chmod +x NVIDIA-Linux-x86_64-550.127.05.run ./NVIDIA-Linux-x86_64-550.127.05.run --no-kernel-module Wichtig: Der Parameter --no-kernel-module ist essentiell, da der Container den Kernel des Hosts nutzt!\nAMD GPU Konfiguration AMD-GPUs sind besonders interessant für KI-Workloads, da Modelle wie die RX 7900 XTX mit 24GB VRAM ausgestattet sind – perfekt für große LLMs!\nSchritt 1: Geräte überprüfen # AMD GPU-Geräte anzeigen ls -l /dev/dri ls -l /dev/kfd Schritt 2: Container konfigurieren (Web-UI Methode) In Proxmox 8.2.7+ und 9.0:\nWähle deinen Container aus Gehe zu Resources Klicke auf Add → Device Passthrough Füge folgende Geräte hinzu: /dev/dri/card0 mit Mode: 0666, GID: 104 (render) /dev/dri/renderD128 mit Mode: 0666, GID: 104 /dev/kfd mit Mode: 0666 (für ROCm-Support) Der Vorteil: Diese Methode funktioniert auch perfekt mit unprivilegierten Containern!\nSchritt 3: ROCm im Container installieren # ROCm Repository hinzufügen (Ubuntu/Debian) wget -q -O - https://repo.radeon.com/rocm/rocm.gpg.key | apt-key add - echo \u0026#39;deb [arch=amd64] https://repo.radeon.com/rocm/apt/debian/ ubuntu main\u0026#39; \u0026gt; /etc/apt/sources.list.d/rocm.list # ROCm installieren apt update apt install rocm-dkms Intel GPU Konfiguration Intel-GPUs eignen sich hervorragend für Media-Transcoding mit Plex oder Jellyfin. Mit Intel VT-d können in Proxmox 8.2+ sogar bis zu 7 VMs die GPU teilen!\nSchritt 1: Intel GPU-Unterstützung auf dem Host # Intel Media Driver installieren apt update apt install intel-media-va-driver-non-free Schritt 2: Container-Konfiguration (Web-UI Methode) Füge über die Web-UI folgende Geräte hinzu:\n/dev/dri/card0 mit Mode: 0666, GID: 104 /dev/dri/renderD128 mit Mode: 0666, GID: 104 Alternativ für die manuelle Methode in /etc/pve/lxc/100.conf:\n# Intel GPU Support lxc.cgroup2.devices.allow: c 226:* rwm lxc.mount.entry: /dev/dri dev/dri none bind,optional,create=dir Schritt 3: Gruppe im Container anpassen # Im Container die render-Gruppe für den Benutzer hinzufügen usermod -aG video,render plex # Beispiel für Plex-User Unprivilegierte Container – Die sichere Wahl Mit der Web-UI Device Passthrough Funktion ist es jetzt viel einfacher, GPUs auch in unprivilegierten Containern zu nutzen:\nSetze einfach die GID auf 104 (render group) in den Advanced Settings Keine komplexen idmap-Konfigurationen mehr nötig Funktioniert out-of-the-box mit den meisten Anwendungen Dies löst das alte Sicherheitsproblem, bei dem privilegierte Container für einfache GPU-Passthrough benötigt wurden.\nVerifizierung der GPU-Funktionalität Für NVIDIA: # Im Container ausführen: nvidia-smi # Sollte die GPU und aktuelle Auslastung anzeigen Für AMD: # ROCm-Info anzeigen rocm-smi rocminfo Für Intel: # Intel GPU-Tools installieren und testen apt install intel-gpu-tools intel_gpu_top Praktische Anwendungsfälle Ollama für lokale LLMs Nach der GPU-Konfiguration kannst du Ollama einfach installieren:\n# Ollama installieren curl -fsSL https://ollama.com/install.sh | sh # Modell herunterladen und starten ollama run llama3.2 # GPU-Nutzung überprüfen nvidia-smi # sollte Ollama-Prozess zeigen Plex Media Server mit Hardware-Transcoding # Nach Plex-Installation Hardware-Transcoding aktivieren: # 1. Plex Web-Interface öffnen # 2. Einstellungen → Transcoder # 3. \u0026#34;Use hardware acceleration when available\u0026#34; aktivieren Jellyfin mit GPU-Beschleunigung Jellyfin ist besonders beliebt für GPU-Transcoding in LXC-Containern:\n# Jellyfin Installation apt update apt install jellyfin # In Jellyfin Settings → Playback: # Hardware acceleration: VAAPI (Intel/AMD) oder NVENC (NVIDIA) Frigate für Videoüberwachung In der Frigate-Konfiguration config.yml:\nffmpeg: hwaccel_args: preset-nvidia-h264 # für NVIDIA # oder hwaccel_args: preset-vaapi # für Intel/AMD Häufige Probleme und Lösungen Problem: „NVIDIA-SMI has failed“ Lösung: Stelle sicher, dass die Treiberversionen auf Host und Container identisch sind!\nProblem: Permission denied beim GPU-Zugriff Lösung: Bei unprivilegierten Containern: Verwende die Web-UI und setze die GID auf 104 (render group).\nProblem: HDR Tone Mapping funktioniert nicht (Intel) Bekanntes Problem: Bei Intel GPUs in LXC-Containern kann HDR Tone Mapping in Plex problematisch sein. Hardware-Transcoding funktioniert aber weiterhin.\nProblem: Container startet nicht nach GPU-Konfiguration Lösung: Prüfe die Syntax in der Container-Config. Ein fehlendes Komma oder Leerzeichen kann den Start verhindern.\nProxmox VE 9.0 – Was ist neu? Die im August 2025 veröffentlichte Version 9.0 bringt einige Verbesserungen für Container:\nLXC 6.0.4: Verbesserte Ressourcenverwaltung und Sicherheitsisolation Cgroup v2: Bessere Integration für moderne Container-Workloads Kernel 6.14.8-2: Verbesserte GPU-Treiberunterstützung SDN Fabric Support: Komplexere Netzwerkarchitekturen für Container-Cluster Die Web-UI Device Passthrough Funktion wurde bereits in 8.2.7 eingeführt und ist in 9.0 weiter optimiert worden.\nWichtige Überlegungen zur Sicherheit LXC-Container mit GPU-Zugriff haben erweiterte Rechte. Beachte folgende Punkte:\nUnprivilegierte Container (empfohlen): Mit der Web-UI Device Passthrough Methode jetzt einfach umsetzbar Privilegierte Container: Nur verwenden, wenn absolut notwendig Verwende GPU-Sharing nur für vertrauenswürdige Workloads Isoliere kritische Dienste in separaten Containern Nutze die GID-Einstellungen für granulare Zugriffskontrolle Performance-Tipps Mehrere Container können die GPU gleichzeitig nutzen, aber die Performance wird geteilt Für maximale Performance bei einzelnen Workloads: GPU-Passthrough zu einer VM verwenden Überwache die GPU-Auslastung mit nvidia-smi, rocm-smi oder intel_gpu_top Plane GPU-intensive Tasks zeitversetzt, wenn mehrere Dienste die GPU nutzen Nutze die erweiterten Cgroup v2 Features in Proxmox 9.0 für bessere Ressourcenkontrolle Fazit GPU-Sharing mit LXC-Containern in Proxmox ist eine elegante Lösung, um Hardware-Beschleunigung für mehrere Dienste gleichzeitig bereitzustellen. Mit den Verbesserungen in Proxmox 8.2.7+ und besonders in Version 9.0 ist die Einrichtung deutlich einfacher geworden – besonders durch die Web-UI Device Passthrough Funktion.\nDer große Vorteil gegenüber VM-Passthrough: Du bist nicht auf einen einzigen Dienst beschränkt und kannst die GPU-Ressourcen flexibel zwischen verschiedenen Anwendungen teilen. Mit der Unterstützung für unprivilegierte Container ist dies jetzt auch sicher möglich.\nWeiterführende Ressourcen Proxmox LXC Documentation Proxmox VE 9.0 Release Notes Ollama GitHub Repository NVIDIA GPU Virtualization AMD ROCm Documentation Hast du Fragen oder eigene Erfahrungen mit GPU-Sharing in Proxmox? Teile sie gerne in den Kommentaren!\n","permalink":"https://aibix.io/blog/proxmox-gpu-sharing-lxc-container/","summary":"\u003ch2 id=\"warum-gpu-sharing-mit-lxc-containern\"\u003eWarum GPU-Sharing mit LXC-Containern?\u003c/h2\u003e\n\u003cp\u003eWenn du einen Proxmox-Server mit einer GPU betreibst und verschiedene Dienste wie Ollama (für KI-Modelle), Plex (für Medien-Transcoding) oder Frigate (für Videoüberwachung) mit Hardware-Beschleunigung nutzen möchtest, stehst du vor einer wichtigen Entscheidung.\u003c/p\u003e","title":"Proxmox: GPU sharing in LXC Containern"},{"content":"In diesem Artikel zeige ich Ihnen, wie Sie Intel GPU Hardware-Transcodierung in einem Proxmox LXC Container erfolgreich einrichten. Diese Anleitung basiert auf einer getesteten Konfiguration mit Debian 13 (Trixie) und einer Intel Alder Lake-N Grafikkarte.\nSystemvoraussetzungen Für dieses Setup benötigen Sie:\nHost-System: Proxmox VE 9.0 oder höher Container OS: Debian 13 (Trixie) – empfohlen wegen aktueller Treiber Intel GPU: Integrierte Intel Grafik (getestet mit Alder Lake-N) Kernel: Proxmox Kernel 6.14.8-2-pve oder neuer Die GPU muss bereits im Proxmox Container konfiguriert sein (Device Passthrough). In unserem Fall war die PCI-Adresse 0000:00:02.0.\nSchritt 1: Grundlegende Pakete installieren Melden Sie sich als root in Ihrem Container an und installieren Sie zunächst die grundlegenden Tools:\napt update apt install -y pciutils udev Überprüfen Sie, ob die GPU erkannt wird:\nlspci | grep VGA # Ausgabe sollte Ihre Intel GPU zeigen Schritt 2: Intel Treiber und VA-API installieren Installieren Sie alle notwendigen Intel-Treiber und VA-API Komponenten:\n# Intel Media Treiber apt install -y intel-media-va-driver-non-free i965-va-driver # VA-API Bibliotheken und Tools apt install -y libva2 libva-dev vainfo va-driver-all # Intel spezifische Bibliotheken apt install -y libigdgmm12 libvpl2 libmfx-gen1.2 # Monitoring Tools apt install -y intel-gpu-tools Schritt 3: FFmpeg mit Hardware-Unterstützung installieren apt install -y ffmpeg Debian Trixie liefert FFmpeg bereits mit vollständiger Intel QSV (Quick Sync Video) Unterstützung aus.\nSchritt 4: Umgebungsvariablen konfigurieren Erstellen Sie die Datei /etc/environment mit folgendem Inhalt:\nLIBVA_DRIVER_NAME=iHD LIBVA_DRIVERS_PATH=/usr/lib/x86_64-linux-gnu/dri Diese Variablen stellen sicher, dass der Intel iHD Treiber verwendet wird.\nSchritt 5: Installation überprüfen VA-API Test # VA-API Unterstützung prüfen vainfo --display drm --device /dev/dri/renderD128 Sie sollten eine Liste der unterstützten Profile und Entrypoints sehen, einschließlich:\nVAProfileH264Main VAProfileHEVCMain VAProfileVP9Profile0 FFmpeg QSV Support # Verfügbare Hardware-Beschleuniger anzeigen ffmpeg -hide_banner -hwaccels | grep qsv # QSV Encoder auflisten ffmpeg -hide_banner -encoders | grep qsv Schritt 6: Test-Script erstellen Erstellen Sie /root/test_gpu_transcoding.sh mit folgendem Inhalt:\n#!/bin/bash echo \u0026#34;=== Intel GPU Transcoding Test Script ===\u0026#34; echo # Farben für Ausgabe GREEN=\u0026#39;\\033[0;32m\u0026#39; RED=\u0026#39;\\033[0;31m\u0026#39; NC=\u0026#39;\\033[0m\u0026#39; # No Color # Test 1: VA-API Check echo \u0026#34;1. Checking VA-API support...\u0026#34; if vainfo --display drm --device /dev/dri/renderD128 2\u0026gt;/dev/null | grep -q \u0026#34;VAProfileH264Main\u0026#34;; then echo -e \u0026#34;${GREEN}✓ VA-API is working${NC}\u0026#34; else echo -e \u0026#34;${RED}✗ VA-API not working${NC}\u0026#34; exit 1 fi echo # Test 2: FFmpeg QSV Check echo \u0026#34;2. Checking ffmpeg QSV support...\u0026#34; if ffmpeg -hide_banner -encoders 2\u0026gt;/dev/null | grep -q h264_qsv; then echo -e \u0026#34;${GREEN}✓ FFmpeg QSV support detected${NC}\u0026#34; else echo -e \u0026#34;${RED}✗ FFmpeg QSV support not found${NC}\u0026#34; exit 1 fi echo # Test 3: Create test video echo \u0026#34;3. Creating test video...\u0026#34; ffmpeg -f lavfi -i testsrc=duration=5:size=1280x720:rate=30 \\ -f lavfi -i sine=frequency=1000:duration=5 \\ -c:v libx264 -preset ultrafast -c:a aac \\ -y /tmp/test_input.mp4 2\u0026gt;/dev/null echo -e \u0026#34;${GREEN}✓ Test video created${NC}\u0026#34; echo # Test 4: Software encoding echo \u0026#34;4. Testing software H.264 encoding...\u0026#34; START=$(date +%s%N) ffmpeg -i /tmp/test_input.mp4 -c:v libx264 -preset faster \\ -b:v 2M -c:a copy -y /tmp/test_sw.mp4 2\u0026gt;/dev/null END=$(date +%s%N) SW_TIME=$((($END - $START)/1000000)) echo -e \u0026#34;${GREEN}✓ Software encoding: ${SW_TIME}ms${NC}\u0026#34; echo # Test 5: Hardware encoding echo \u0026#34;5. Testing hardware H.264 QSV encoding...\u0026#34; export LIBVA_DRIVER_NAME=iHD START=$(date +%s%N) ffmpeg -hwaccel qsv -qsv_device /dev/dri/renderD128 \\ -i /tmp/test_input.mp4 -c:v h264_qsv -preset faster \\ -b:v 2M -c:a copy -y /tmp/test_hw.mp4 2\u0026gt;/dev/null END=$(date +%s%N) HW_TIME=$((($END - $START)/1000000)) echo -e \u0026#34;${GREEN}✓ Hardware encoding: ${HW_TIME}ms${NC}\u0026#34; echo # Performance comparison SPEEDUP=$(echo \u0026#34;scale=1; $SW_TIME / $HW_TIME\u0026#34; | bc) echo \u0026#34;=== Performance Summary ===\u0026#34; echo \u0026#34;Software encoding: ${SW_TIME}ms\u0026#34; echo \u0026#34;Hardware encoding: ${HW_TIME}ms\u0026#34; echo -e \u0026#34;${GREEN}Hardware acceleration is ${SPEEDUP}x faster!${NC}\u0026#34; echo # Cleanup rm -f /tmp/test_*.mp4 echo \u0026#34;All tests completed successfully!\u0026#34; Machen Sie das Script ausführbar:\nchmod +x /root/test_gpu_transcoding.sh Leistungsvergleich In unseren Tests mit einem 5-Sekunden 720p Video zeigten sich folgende Ergebnisse:\nEncoding-Methode Zeit Geschwindigkeit Software H.264 1471ms Baseline Hardware H.264 (QSV) 405ms 3.6x schneller Hardware HEVC (QSV) 502ms 2.9x schneller Die Hardware-Beschleunigung erreichte dabei eine Transcodierungsgeschwindigkeit von:\n17x Echtzeit für H.264 13x Echtzeit für HEVC Unterstützte Codecs Mit diesem Setup stehen folgende Hardware-Codecs zur Verfügung:\n✅ H.264/AVC (h264_qsv) – Encoding \u0026amp; Decoding ✅ HEVC/H.265 (hevc_qsv) – Encoding \u0026amp; Decoding ✅ VP9 (vp9_qsv) – Encoding \u0026amp; Decoding ✅ MPEG-2 (mpeg2_qsv) – Encoding \u0026amp; Decoding ✅ MJPEG (mjpeg_qsv) – Encoding ⚠️ AV1 (av1_qsv) – Je nach GPU-Generation Praktische FFmpeg Befehle H.264 Transcodierung mit QSV export LIBVA_DRIVER_NAME=iHD ffmpeg -hwaccel qsv -qsv_device /dev/dri/renderD128 -i input.mp4 \\ -c:v h264_qsv -preset faster -b:v 2M -c:a copy output.mp4 HEVC/H.265 Transcodierung ffmpeg -hwaccel qsv -qsv_device /dev/dri/renderD128 -i input.mp4 \\ -c:v hevc_qsv -preset faster -b:v 1M -c:a copy output_hevc.mp4 Vollständige Hardware-Pipeline (Decode + Encode) ffmpeg -hwaccel qsv -c:v h264_qsv -i input.mp4 \\ -c:v hevc_qsv -preset faster -b:v 1M -c:a copy output.mp4 GPU-Auslastung überwachen ⚠️ Wichtiger Hinweis: Das Tool intel_gpu_top erfordert einen privilegierten Container für vollen Zugriff auf GPU-Metriken. Falls der Befehl mit einem Fehler wie „Failed to detect engines“ fehlschlägt, müssen Sie Ihren Container als privilegiert konfigurieren:\nIn der Proxmox Container-Konfiguration unter Options → Features aktivieren Sie:\nNesting (für Container-in-Container) Fügen Sie in der Container-Konfigurationsdatei /etc/pve/lxc/[CTID].conf folgende Zeile hinzu: lxc.apparmor.profile: unconfined\nMit intel_gpu_top können Sie die GPU-Auslastung in Echtzeit beobachten:\nintel_gpu_top Dies zeigt Ihnen die Auslastung der verschiedenen GPU-Engines, einschließlich der Video-Engine während der Transcodierung.\nAlternativ können Sie auch grundlegende GPU-Informationen ohne privilegierten Zugriff abrufen:\n# GPU-Frequenz anzeigen cat /sys/class/drm/card*/gt_cur_freq_mhz # GPU-Speichernutzung cat /sys/kernel/debug/dri/*/i915_gem_objects Anwendungsfälle Dieses Setup eignet sich hervorragend für:\nVideo-Streaming-Dienste: Jellyfin, Plex, Emby mit Hardware-Transcodierung Live-Streaming: OBS Studio mit QSV Encoder Videokonvertierung: Batch-Konvertierung großer Videobibliotheken Überwachungskameras: Motion Detection und Aufzeichnung mit geringer CPU-Last Videokonferenz-Server: Jitsi, BigBlueButton mit Hardware-Beschleunigung Fehlerbehebung Problem: VA-API funktioniert nicht Prüfen Sie die Berechtigungen der DRM-Geräte:\nls -la /dev/dri/ # renderD128 sollte lesbar sein Problem: FFmpeg findet QSV nicht Stellen Sie sicher, dass die Umgebungsvariable gesetzt ist:\nexport LIBVA_DRIVER_NAME=iHD Problem: Schlechte Performance Überprüfen Sie mit intel_gpu_top, ob die GPU tatsächlich verwendet wird. Die Video-Engine sollte während der Transcodierung aktiv sein.\nFazit Die Einrichtung der Intel GPU Hardware-Transcodierung in einem Proxmox LXC Container bietet erhebliche Leistungsvorteile. Mit einer 3-4fachen Geschwindigkeitssteigerung gegenüber Software-Encoding und Unterstützung für moderne Codecs ist das System ideal für medienintensive Anwendungen.\nDie Kombination aus Debian Trixie’s aktuellen Treibern und Proxmox’s Container-Technologie ermöglicht eine effiziente und isolierte Umgebung für Video-Transcodierung mit minimaler CPU-Belastung.\nHaben Sie Fragen oder Erfahrungen mit diesem Setup? Hinterlassen Sie gerne einen Kommentar!\n","permalink":"https://aibix.io/blog/intel-igpu-hardware-transcodierung-in-proxmox-lxc-container-einrichten/","summary":"\u003cp\u003eIn diesem Artikel zeige ich Ihnen, wie Sie Intel GPU Hardware-Transcodierung in einem Proxmox LXC Container erfolgreich einrichten. Diese Anleitung basiert auf einer getesteten Konfiguration mit Debian 13 (Trixie) und einer Intel Alder Lake-N Grafikkarte.\u003c/p\u003e","title":"Intel iGPU Hardware-Transcodierung in Proxmox LXC Container einrichten"},{"content":"Neulich hatte ich ein Gespräch mit einem Kollegen, das mich zum Nachdenken gebracht hat. Er saß vor seinem Laptop, bastelte an irgendwelchen Diagrammen und Planungen herum. Als ich ihm sagte, dass sowas zukünftig auch die KI für ihn machen könnte, kam eine Antwort, die mich aufhorchen ließ: „Das KI-Zeug habe ich dreimal ausprobiert, dreimal eine bescheidene Antwort bekommen – brauche ich nicht.“\nDie Realität außerhalb der Tech-Bubble Mein Kollege ist ein bodenständiger Familienvater, kein Technik-Nerd, sondern jemand mit einem echten Leben außerhalb der digitalen Welt. Und genau solche Menschen gibt es millionenfach. Das muss man respektieren – nicht jeder lebt in einer Technik-Bubble, wo KI allgegenwärtig ist.\nAber hier liegt das Problem: Während mein YouTube-Feed von oben bis unten mit KI-Content gefüllt ist, beschäftigt sich die arbeitende Bevölkerung mehrheitlich noch nicht ernsthaft mit diesem Thema. Viele sehen keinen Grund, sich in ihrer Freizeit damit auseinanderzusetzen oder den Chef zu drängen, entsprechende Schulungen anzubieten.\nKI wird das neue Office Dabei ist KI nichts anderes als das, was damals mit Office-Programmen passiert ist. Outlook, Excel, Word, PowerPoint – das mussten wir alle irgendwann lernen. Auch die Computer-Verweigerer, die sagten: „Ich brauche das nicht, ich habe meinen Ordner, meinen Stift und meinen Kopierer.“\nHeute kann jeder Basic-Office-Programme bedienen, sonst ist man beruflich raus. Bei KI wird es genauso laufen. Wer heute nicht lernt, mit diesen Tools umzugehen, wird morgen ersetzt – nicht durch die KI selbst, sondern durch den Kollegen, der es gelernt hat.\nDer falsche Mythos vom KI-Ersatz Viele Chefs und Investoren glauben fälschlicherweise, sie könnten Informationsmitarbeiter einfach durch KI ersetzen. Das ist grundfalsch. Klar, sie werden es zunächst versuchen: „Warum einen Mitarbeiter für Social Media Postings bezahlen, wenn mein Copilot das auch kann?“\nAber ein ein- oder zweizeiliger Social Media Post ist etwas völlig anderes als ein Businessplan, eine wissenschaftliche Arbeit oder komplexe Programmierung. Für alles Größere braucht die KI das Fachwissen eines Menschen, der sie anleiten kann.\nKI als Produktivitäts-Booster Der Trick liegt darin, KI mit Kontext zu füttern: mit Informationen, Dokumentation, projektspezifischen Daten. Du arbeitest quasi gemeinsam mit der KI einen Plan aus – wie ein Dompteur einer Engineering-Abteilung.\nDie KI erhöht den Output eines Mitarbeiters, der weiß, was er tut und wie er das der KI beibringt. Den Mitarbeiter kann man nicht einfach ersetzen. Aber sehr wohl kann man jemanden ersetzen, der sagt: „Brauche ich nicht“ – denn dessen Job macht dann der Kollege, der sich mit KI beschäftigt hat und plötzlich den zehnfachen Output produziert.\nDas Skillset der Zukunft Was wird zukünftig wichtig sein? Eine Sammlung von „Voreinstellungsdateien“ – Prompts und Anweisungen, mit denen du KI-Systeme für verschiedene Aufgaben konfigurierst. Das ist wie das initiale Priming: „Lege immer ein Git-Repository an, achte auf Versionskontrolle, verwende diese Dateistruktur.“\nDazu kommen projektspezifische Vorgaben. Ob du ein Buch schreibst oder Ausschreibungen erstellst – du baust dir Templates und fütterst sie mit projektspezifischen Daten. Dann gibst du der KI Input für zehn Projekte und sie macht die Arbeit von zehn Leuten gleichzeitig.\nKünstliche Idioten, nicht künstliche Intelligenz Der Begriff „künstliche Intelligenz“ ist Marketing-Blabla. Es sind eher „künstliche Idioten“ – wie Savants, die etwas furchtbar gut können (ganz viel, ganz schnell), aber trotzdem angeleitet werden müssen. Sie können das Telefonbuch auswendig lernen, aber danach niemanden anrufen.\nWir müssen diesen Systemen beibringen, wie die Welt funktioniert. Das kostet Zeit und Lernaufwand, aber es ist unvermeidlich.\nKI für den Menschen, nicht für den Investor Die Zukunft heißt KI für den Menschen, nicht für Investoren oder Chefs, die auf dem Hype-Train sitzen. Es geht darum, der Allgemeinheit zugänglich zu machen, warum dieses Thema wichtig ist.\nDie Wahrheit ist: Du wirst nicht durch KI ersetzt, sondern durch deinen Kollegen, der gelernt hat, mit KI zu arbeiten und dadurch den zehnfachen Output produziert. Die Competition ist nicht mit der KI, sondern mit dem Arbeitskollegen nebenan.\nEs ist wie früher: persönliche Weiterentwicklung, Wissen aneignen, neue Werkzeuge beherrschen. Wer das versteht und umsetzt, bleibt relevant. Wer es ignoriert, wird abgehängt.\nFazit KI ist kein Hype, sondern das nächste Office. Jeder, der beruflich überleben will, muss lernen, brauchbare und wiederholbare Ergebnisse aus diesen Systemen herauszuholen. Die Zeit der Ausreden ist vorbei – entweder du lernst es, oder dein Kollege übernimmt deinen Job mit zehnfacher Produktivität.\nBeschäftige dich damit. Es ist wichtiger, als du denkst.\nVideo abspielen Erst beim Klick wird das Video von YouTube geladen und Ihre IP-Adresse an Google übertragen. Näheres in der Datenschutzerklärung. ","permalink":"https://aibix.io/blog/ki-am-arbeitsplatz-das-neue-office-warum-wir-alle-lernen-muessen-mit-kuenstlicher-intelligenz-zu-arbeiten/","summary":"\u003cp\u003eNeulich hatte ich ein Gespräch mit einem Kollegen, das mich zum Nachdenken gebracht hat. Er saß vor seinem Laptop, bastelte an irgendwelchen Diagrammen und Planungen herum. Als ich ihm sagte, dass sowas zukünftig auch die KI für ihn machen könnte, kam eine Antwort, die mich aufhorchen ließ: „Das KI-Zeug habe ich dreimal ausprobiert, dreimal eine bescheidene Antwort bekommen – brauche ich nicht.“\u003c/p\u003e","title":"KI am Arbeitsplatz: Das neue Office – Warum wir alle lernen müssen, mit künstlicher Intelligenz zu arbeiten"},{"content":"Auf einer meiner OPNsense VMs war die zugewiesene Platte voll. Das lässt sich ganz einfach beheben, wie in folgendem Video beschrieben:\nVideo abspielen Erst beim Klick wird das Video von YouTube geladen und Ihre IP-Adresse an Google übertragen. Näheres in der Datenschutzerklärung. Hier habe ich dir noch schnell die passenden Befehle rausgeschrieben.\nZum Anzeigen der Plattenbelegung:\ngpart show Nach dem Vergrößern der Platte musst du zuerst die Partitionstabelle fixen:\ngpart recover da0 Setze dabei für da0 die Bezeichnung deiner Patte ein.\nJetzt kannst du die Partition vergrößern:\ngpart resize -i 4 da0 Passe dabei auf, die richtige Partitionsnummer einzusetzen.\nÜberprüfe die erfolgreiche Vergrößerung:\ngpart show Jetzt musst du noch das root-Filesystem vergrößern, dazu musst du unterscheiden, ob du ein UFS oder ZFS hast.\nFür UFS:\ngrowfs /dev/gpt/rootfs Und für ZFS:\nzpool online -e zroot da0p4 Hierbei auch wieder aufpassen wegen der Platte und Partition. da0p4 in meinem Fall heißt einfach Platte da0 und Partition 4\nDas war’s auch schon 🙂\n☕ Unterstütze mich auf Ko-fi Falls du noch passende Hardware suchst um deine OPNsense aus der Virtualisierung zu befreien, dann schau doch mal meine Amazon-Links an. Falls etwas für dich dabei ist, würde ich mich freuen wenn du es über meinen Link bestellst, dir entstehen dabei keinerlei Mehrkosten und ich erhalte einen kleinen Anteil von Amazon.\n","permalink":"https://aibix.io/blog/opnsense-vm-platte-voll/","summary":"\u003cp\u003eAuf einer meiner OPNsense VMs war die zugewiesene Platte voll. Das lässt sich ganz einfach beheben, wie in folgendem Video beschrieben:\u003c/p\u003e\n\u003cfigure class=\"yt-facade\" data-yt-id=\"wrkgG1Pdmzo\"\u003e\n  \u003ca class=\"yt-facade__link\" href=\"https://www.youtube.com/watch?v=wrkgG1Pdmzo\" rel=\"noopener\" target=\"_blank\"\u003e\n    \u003cimg class=\"yt-facade__thumb\" src=\"/media/youtube/wrkgG1Pdmzo.jpg\" alt=\"\" loading=\"lazy\" width=\"1280\" height=\"720\"\u003e\n    \u003cspan class=\"yt-facade__play\" aria-hidden=\"true\"\u003e\u003c/span\u003e\n    \u003cspan class=\"yt-facade__label\"\u003eVideo abspielen\u003c/span\u003e\n  \u003c/a\u003e\n  \u003cfigcaption class=\"yt-facade__note\"\u003e\n    Erst beim Klick wird das Video von YouTube geladen und Ihre IP-Adresse an Google übertragen.\n    Näheres in der \u003ca href=\"/datenschutzerklaerung/\"\u003eDatenschutzerklärung\u003c/a\u003e.\n  \u003c/figcaption\u003e\n\u003c/figure\u003e\n\u003cp\u003e\u003cstrong\u003eHier habe ich dir noch schnell die passenden Befehle rausgeschrieben.\u003c/strong\u003e\u003c/p\u003e","title":"OPNsense VM Platte voll?"},{"content":"SSL-Zertifikate? Secure Socket Layer (SSL)-Zertifikate sind das, was dein Browser verwendet, um eine Website sicher zu kontaktieren und Benutzernamen, Passwörter, Kreditkartendaten usw. zu schützen. Auf den Synology-Geräten ist standardmäßig ein „self-signed“ Zertifikat installiert. Diese bieten zwar Sicherheit, aber der Webbrowser beschwert sich darüber und man muss verschiedene Schaltflächen/Links anklicken, um zur Website zu gelangen. Fragt man nahezu jeden Enterprise-Administrator nach dieser Unannehmlichkeit, sind selbstsignierte SSL-Zertifikate ein alter Hut – sie finden sich in zahlreichen Administrations-Tools. Für einen Endnutzer wirkt es jedoch nicht sonderlich vertrauenserweckend, wenn er Fehlermeldungen wegklicken muss, um auf ein System zuzugreifen, das wichtige und potenziell sensible Daten enthält.\nSynology DS223 2-Bay Diskstation NAS (Realtek RTD1619B Quad-Core 2GB Ram 1xRJ-45 1GbE LAN-Port), Schwarz 0TB Anzeige · Amazon-Partnerlink · Preis auf Amazon Synology DiskStation DS224\u0026#43; 2 Bay Dekstop NAS DS224\u0026#43; ohne HDD Anzeige · Amazon-Partnerlink · Preis auf Amazon Es GIBT zwar eine eingebaute Methode, ein gültiges SSL-Zertifikat auf einem Synology-Gerät zu bekommen, doch sie hat einen entscheidenden Nachteil: Dein Synology-Gerät muss dafür auf den Ports 80 und 443 über das öffentliche Internet erreichbar sein ODER du musst den Synology-DDNS-Service nutzen. Für manche Nutzer ist das vielleicht kein großes Problem, aber ich glaube nicht, dass die Mehrheit ihr Synology-Gerät öffentlich zugänglich machen oder eine merkwürdige URL (z. B. DeviceName.synology.me) verwenden möchte, um auf die Daten zuzugreifen.\nDie Lösung? Let’s Encrypt stellt kostenlose SSL-Zertifikate zur Verfügung, und acmesh (https://github.com/acmesh-official/acme.sh) bietet ein Skript, das genutzt werden kann, ohne dass Port 80 und 443 für das öffentliche Internet offen sind.\nWo ist der Haken? Nun ja, ein bisschen gibt es da schon. Du brauchst eine Domain bei einem Registrar, der eine Programmierschnittstelle (API) bereitstellt, um bestimmte Einträge zu aktualisieren. acme.sh unterstützt auch https://IPv64.net – yay! Andere Anbieter sollten ebenfalls problemlos funktionieren, und das meiste in diesem Beitrag sollte auch für sie passen. Getestet habe ich allerdings nur mit IPv64. Deine Ergebnisse können variieren („YMMV“).\nWo fängt man an? Als Erstes: Stell sicher, dass du einen Domainnamen bei deinem bevorzugten Registrar oder DynDNS-Anbieter (IPv64 in meinem Fall) registriert hast und beschaffe dir den API-Key. Bei IPv64 kannst du dir den API-Key in deiner Domainübersicht (für die Domain zu der das Zertifikat dann erstellt werden soll) besorgen, er steht auf der rechten Seite und kann dort kopiert werden. Sobald du den API-Key hast, kann es losgehen!\nErstelle einen Benutzer in Synology DSM Melde dich bei deinem Synology-Gerät an, klicke auf „Systemsteuerung“ und dann auf „Benutzer und Gruppe“. Klicke auf „Erstellen“. Ich habe den Benutzernamen „certadmin“ gewählt und eine entsprechende Beschreibung hinzugefügt. Der Benutzer muss Mitglied der Gruppe „administrators“ sein (das ist erforderlich für den SSH-Zugriff, den wir gleich nutzen werden) und außerdem in der Gruppe „http“ (das ist nötig, damit sich der Prozess im SSH-Session-Kontext bei DSM authentifizieren kann). Der Benutzer „certadmin“ benötigt nur Lese-/Schreibzugriff auf den Ordner „homes“ und du kannst den Zugriff auf alle Anwendungen verweigern. Wenn du den Benutzer erstellt hast, gehe zurück zur „Systemsteuerung“, klicke auf „Terminal \u0026amp; SNMP“ und setze ein Häkchen bei „SSH-Dienst aktivieren“. Klicke auf „Übernehmen“.\nJetzt wird’s spannend! Wahrscheinlich bist du hier, um eine Anleitung zu bekommen und nicht, um meine ganzen Erklärungen zu lesen – also los!\nVerwende einen SSH-Client (z. B. https://www.putty.org für Windows; unter Linux ist SSH standardmäßig verfügbar). Wenn du Putty nutzt, gib dort die IP-Adresse oder den Hostnamen deines Synology-Geräts ein, wähle SSH und klicke auf „Open“. Es erscheint eine Sicherheitswarnung, die du mit „Yes“ bestätigen kannst. Anschließend wirst du nach dem Benutzernamen gefragt („certadmin“ in meinem Fall). Unter macOS oder Linux öffnest du ein Terminal und gibst Folgendes ein:\nssh certadmin@DEINHOSTODERIPADRESSE Wenn du die Sicherheitswarnung bestätigst, wirst du nach deinem Passwort gefragt. Gib das Passwort ein, das du oben für den Synology-Benutzer festgelegt hast (bei der Eingabe erscheint möglicherweise kein Text) und drücke Enter. Lass dich nicht von der SSH-Sitzung abschrecken – die Kommandozeile ist dein Freund!\nDie folgenden Befehle (kopiere sie nacheinander, wenn du möchtest) laden das Skript herunter, entpacken die ZIP-Datei, verschieben die Dateien in einen anderen Ordner, übertragen den Besitz der Dateien an den neuen Benutzer und wechseln in das richtige Verzeichnis. Jeder dieser Befehle sollte in einer einzelnen Zeile ausgeführt werden. Die meisten Befehle stammen aus https://www.driscocity.com/synology-dsm-6-2-lets-encrypt-dns-challenge-route53/.\nwget -O /tmp/acme.sh.zip https://github.com/acmesh-official/acme.sh/archive/master.zip (==\u0026gt; da ist kein Zeilenumbruch, die Zeile wurde nur zu lang) sudo 7z x -o/usr/local/share /tmp/acme.sh.zip sudo mv /usr/local/share/acme.sh-master/ /usr/local/share/acme.sh sudo chown -R certadmin /usr/local/share/acme.sh/ cd /usr/local/share/acme.sh Nun haben wir die notwendigen Dateien. Jetzt müssen wir ein paar Variablen anlegen, damit das Skript funktioniert. Ersetze die Platzhalter unbedingt durch deine eigenen Informationen!\nexport IPv64_Token=\u0026#34;DEIN_GODADDY_KEY\u0026#34; export SYNO_Username=\u0026#34;certadmin\u0026#34; export SYNO_Password=\u0026#34;DEIN_CERTADMIN_PASSWORT\u0026#34; export SYNO_Certificate=\u0026#34;Let\u0026#39;s Encrypt\u0026#34; export SYNO_Create=1 Wenn du nicht IPv64 als Domain-Registrar/DynDNS-Provider verwendest, kannst du unter\nhttps://github.com/acmesh-official/acme.sh/wiki/dnsapi nach den entsprechenden export-Befehlen für andere Registrare schauen.\nVerwende zum Erstellen des ersten Zertifikats folgenden Befehl. Achte darauf, deinen Domainnamen zu ersetzen!\n./acme.sh --server letsencrypt --issue -d \u0026#34;*.DEINEDOMAIN.NAME\u0026#34; --dns dns_ipv64 --home $PWD (==\u0026gt; auch hier: kein Zeilenumbruch!) Wenn du einen anderen Registrar verwendest, musst du in der oben genannten Github-Dokumentation nachlesen, welchen Wert du für --dns benötigst.\nDer Vorgang dauert ca. eine Minute. Keine Sorge: Auf dem Bildschirm siehst du Ausgaben, die den Fortschritt zeigen. Dieser Prozess erstellt und lädt das Zertifikat zwar auf dein Synology-Gerät, sagt diesem aber noch nicht, dass es verwendet werden soll. Das erledigt folgender Befehl:\n./acme.sh -d \u0026#34;*.DEINEDOMAIN.NAME\u0026#34; --deploy --deploy-hook synology_dsm --home $PWD (==\u0026gt; auch hier: kein Zeilenumbruch!) Du solltest einige Meldungen sehen, die anzeigen, dass sich das Skript erfolgreich bei deinem Synology-Gerät anmelden konnte, die Zertifikate abruft, sie anwendet und den Webserver neu startet.\nDas automatische zuweisen der Zertifikate und der Neustart des HTTP-Servers hat bei mir nicht geklappt, ich musste die Zertifikate manuell im DSM zuordnen. Dazu klickst du in der Systemsteuerung auf „Sicherheit“ und dann „Zertifikat“. Dann klickst du auf die Schaltfläche Einstellungen und ordnest dein neues Zertifikat für alle Dienste zu. Beim klicken auf ok werden die Dienste neu gestartet und das neue Zertifikat ist aktiv.\nWenn du dich jetzt per HTTPS bei deinem Synology anmeldest, solltest du ein gültiges Zertifikat sehen!\nWenn du ein gültiges und funktionierendes SSL-Zertifikat hast, stelle sicher, dass deine Browser es verwenden! Melde dich bei deinem Synology-Gerät an, gehe in die Systemsteuerung und rufe „Anmeldeportal“ auf. Setze ein Häkchen bei „HTTP-Verbindungen automatisch zu HTTPS umleiten“ und klicke auf „Speichern“. Sobald alles nach Wunsch funktioniert, gehe wieder zur Systemsteuerung und deaktiviere unter „Terminal \u0026amp; SNMP“ den SSH-Zugriff. Denk dran: Das Deaktivieren unnötiger Dienste ist ein guter Sicherheitsgrundsatz!\nUnd was kommt jetzt? Das Zertifikat ist installiert und funktioniert. Wenn du allerdings prüfst, wirst du feststellen, dass es nur 90 Tage gültig ist. Du kannst es ganz einfach automatisch verlängern, indem du in deinem Synology-Gerät in die Systemsteuerung gehst, den „Aufgabenplaner“ öffnest, auf „Erstellen“ und „Geplante Aufgabe“ klickst und „Benutzerdefiniertes Skript“ auswählst. Gib der Aufgabe einen aussagekräftigen Namen und achte darauf, dass als Benutzer „certadmin“ ausgewählt ist. Plane die Aufgabe so, dass sie täglich ausgeführt wird, und trage im Reiter „Aufgabeneinstellungen“ das benutzerdefinierte Skript ein. In meinem Fall sieht das so aus:\n/usr/local/share/acme.sh/acme.sh --renew -d \u0026#34;*.DEINEDOMAIN.NAME\u0026#34; --home /usr/local/share/acme.sh --server letsencrypt (==\u0026gt; auch hier: kein Zeilenumbruch!) Das war’s! Nur ein paar relativ einfache Schritte, und du hast ein gültiges SSL-Zertifikat auf deinem Synology-Gerät, das sich automatisch verlängert, bevor es abläuft.\n☕ Unterstütze mich auf Ko-fi Quellenangabe Anleitung gefunden auf:\nhttps://dr-b.io/post/Synology-DSM-7-with-Lets-Encrypt-and-DNS-Challenge\nAngepasst für IPv64 und ein wenig bereinigt.\n","permalink":"https://aibix.io/blog/synology-lets-encrypt-dns-challenge-mit-ipv64/","summary":"\u003ch2 id=\"ssl-zertifikate\"\u003eSSL-Zertifikate?\u003c/h2\u003e\n\u003cp\u003eSecure Socket Layer (SSL)-Zertifikate sind das, was dein Browser verwendet, um eine Website sicher zu kontaktieren und Benutzernamen, Passwörter, Kreditkartendaten usw. zu schützen. Auf den Synology-Geräten ist standardmäßig ein „self-signed“ Zertifikat installiert. Diese bieten zwar Sicherheit, aber der Webbrowser beschwert sich darüber und man muss verschiedene Schaltflächen/Links anklicken, um zur Website zu gelangen. Fragt man nahezu jeden Enterprise-Administrator nach dieser Unannehmlichkeit, sind selbstsignierte SSL-Zertifikate ein alter Hut – sie finden sich in zahlreichen Administrations-Tools. Für einen Endnutzer wirkt es jedoch nicht sonderlich vertrauenserweckend, wenn er Fehlermeldungen wegklicken muss, um auf ein System zuzugreifen, das wichtige und potenziell sensible Daten enthält.\u003c/p\u003e","title":"Synology Let’s Encrypt DNS-Challenge mit IPv64"},{"content":"","permalink":"https://aibix.io/blog/willkommen-auf-aibix-io/","summary":"","title":"Willkommen auf aibix.io"}]