[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"blog-content-tech-news-der-woche-kw-22":3},"\u003Cp>Wenn KW21 die Security-Welle war, ist KW22 die Plattform-Reife-Welle. Fünf Releases stehen im Zentrum, und sie haben eines gemeinsam: Sie schließen Lücken, die seit Monaten auf der Roadmap standen, und legen das Fundament für die nächste Phase. \u003Cstrong>Kubernetes v1.36 \"Haru\"\u003C\u002Fstrong> ist seit April GA und hat am 20. Mai sein offizielles Highlights-Event hinter sich, \u003Cstrong>GitLab 19.0 GA\u003C\u002Fstrong> rollt am 21. Mai mit der Duo Agent Platform aus, \u003Cstrong>GitHub Copilot for Eclipse\u003C\u002Fstrong> wandert unter MIT-Lizenz ins Open-Source-Lager, \u003Cstrong>Node.js v26\u003C\u002Fstrong> macht die Temporal API zum Standard, und \u003Cstrong>Remix 3\u003C\u002Fstrong> beendet die React-Ehe.\u003C\u002Fp>\n\n\u003Cp>Klingt nach viel? Ist es. Aber jede einzelne dieser Releases ist für DACH-Teams direkt relevant — von der Plattform-Engineering-Schicht bis zur Front-End-Strategie 2027. Hier die Einordnung.\u003C\u002Fp>\n\n\u003Ch2>Top-Story: Kubernetes v1.36 \"Haru\" — Highlights-Event und Stable-Features\u003C\u002Fh2>\n\u003Cp>Kubernetes v1.36 ist seit dem 22. April GA und hat am 20. Mai um 16:00 UTC das offizielle \u003Ca href=\"https:\u002F\u002Fkubernetes.io\u002Fblog\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">Release-Highlights-Event\u003C\u002Fa> abgeschlossen. Die Zahlen, kurz: \u003Cstrong>70 Enhancements\u003C\u002Fstrong> (18 Stable, 25 Beta, 25 Alpha), 15-Wochen-Release-Zyklus, \u003Cstrong>491 Contributors aus 106 Companies\u003C\u002Fstrong>. Das ist ein gesundes Tempo für ein Projekt in diesem Reife-Stadium.\u003C\u002Fp>\n\u003Cp>Was wirklich zählt, sind die GA-Features. \u003Cstrong>User Namespaces\u003C\u002Fstrong> sind Stable — endlich. Das ist seit Jahren eine offene Baustelle für Multi-Tenant-Cluster, und jetzt funktioniert sie ohne Alpha-Klausel-Disclaimer. \u003Cstrong>Mutating Admission Policies\u003C\u002Fstrong> ersetzen die historisch fragilen Mutating Webhooks für einen Großteil der Standard-Use-Cases — CEL-basiert, deklarativ, ohne externes Deployment. \u003Cstrong>Fine-Grained Kubelet API Authorization\u003C\u002Fstrong> macht Node-Level-Security feiner steuerbar. Und \u003Cstrong>SELinux Volume Mounting\u003C\u002Fstrong> ist Stable: \u003Ccode>mount -o context=XYZ\u003C\u002Fcode> ersetzt das alte recursive Relabeling, was bei großen Persistent Volumes den Pod-Startup spürbar beschleunigt.\u003C\u002Fp>\n\u003Cp>Daneben zwei Blog-Posts, die in den letzten zwei Wochen erschienen sind und beide Pflichtlektüre sind: \u003Cstrong>Workload-Aware Scheduling\u003C\u002Fstrong> (13. Mai) zeigt, wie der Scheduler 2026 mit AI-Workload-spezifischen Resource-Patterns umgeht, und \u003Cstrong>DRA — Next Era of Dynamic Resource Allocation\u003C\u002Fstrong> (7. Mai) skizziert den Pfad für GPU- und Accelerator-Sharing in den kommenden Releases. Wer Kubernetes-Cluster für GenAI-Workloads betreibt, sollte beide gelesen haben.\u003C\u002Fp>\n\u003Cp>Zusatzmeldung: \u003Cstrong>etcd v3.7.0 Beta\u003C\u002Fstrong> ist am 20. Mai mit dem lang ersehnten \u003Cstrong>RangeStream\u003C\u002Fstrong>-Feature erschienen — endlich kein Memory-Blowup mehr bei großen List-Operations. Für jeden, der etcd-Performance-Probleme im Cluster hatte, ist das eine sehr saubere Nachricht.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Quelle:\u003C\u002Fstrong> \u003Ca href=\"https:\u002F\u002Fkubernetes.io\u002Fblog\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">Kubernetes Blog\u003C\u002Fa> · \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fkubernetes\u002Fkubernetes\u002Freleases\" target=\"_blank\" rel=\"noopener noreferrer\">Kubernetes v1.36 Release Notes\u003C\u002Fa> · \u003Ca href=\"https:\u002F\u002Fwww.cncf.io\u002Fblog\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">CNCF Blog\u003C\u002Fa>\u003C\u002Fp>\n\n\u003Ch2>GitLab 19.0 GA — Duo Agent Platform geht live\u003C\u002Fh2>\n\u003Cp>Am 21. Mai hat GitLab das nächste Major-Release \u003Ca href=\"https:\u002F\u002Fabout.gitlab.com\u002Fblog\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">GitLab 19.0\u003C\u002Fa> ausgeliefert. Der wichtigste Inhalt ist nicht das übliche Set an Pipeline-Verbesserungen — sondern die \u003Cstrong>GitLab Duo Agent Platform\u003C\u002Fstrong>, die parallele Multi-Agent-Workflows zum integralen Bestandteil der Plattform macht.\u003C\u002Fp>\n\u003Cp>Das Modell ist klar: Drei spezialisierte Agents arbeiten parallel auf einer Merge Request. Der \u003Cstrong>Software Developer Agent\u003C\u002Fstrong> schreibt und refactored Code, der \u003Cstrong>Security Analyst Agent\u003C\u002Fstrong> prüft Diffs gegen das eigene SAST\u002FSCA-Setup und CVE-Datenbanken, und der \u003Cstrong>Deep Research Agent\u003C\u002Fstrong> macht das, was Senior-Devs vor jedem komplexen Change tun — relevante Issues, frühere Diskussionen und externe Dokumentation zusammensuchen. Die Agents kommunizieren über ein internes Coordination-Protokoll und können sich gegenseitig blockieren, wenn z.B. der Security-Agent einen Hard-Fail-Befund hat.\u003C\u002Fp>\n\u003Cp>Zwei Features für Compliance-Teams: \u003Cstrong>Model Selection GA\u003C\u002Fstrong> erlaubt es, pro Duo-Workflow den Provider zu wählen (also z.B. den Security Agent auf einer On-Premise-Inference laufen lassen, während der Developer Agent auf Anthropic über die Cloud-API geht). \u003Cstrong>Context Exclusion\u003C\u002Fstrong> macht es möglich, sensible Files oder Patterns aus dem Agent-Context auszuschließen — Personal Data, Crypto-Keys, Customer-Snippets. Plus: getrennte Model-Selection für Chat vs. Agents, also fine-grained Governance je nach Use-Case.\u003C\u002Fp>\n\u003Cp>Für DACH-Teams, die GitLab self-hosted betreiben, ist 19.0 ein wichtiger Punkt: Multi-Agent-Workflows lassen sich stärker an eigene Infrastruktur, Modellwahl und Context-Policies koppeln. Ob Code-Snippets oder Issue-Inhalte an externe Provider gehen, hängt damit weniger an einem pauschalen Tool-Versprechen und mehr an der konkreten Duo-Konfiguration.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Quelle:\u003C\u002Fstrong> \u003Ca href=\"https:\u002F\u002Fabout.gitlab.com\u002Fblog\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">GitLab Blog — GitLab 19.0 GA\u003C\u002Fa> · \u003Ca href=\"https:\u002F\u002Fabout.gitlab.com\u002Fgitlab-duo\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">GitLab Duo\u003C\u002Fa>\u003C\u002Fp>\n\n\u003Ch2>GitHub Copilot for Eclipse — Client-Code wird Open Source unter MIT\u003C\u002Fh2>\n\u003Cp>Am 21. Mai hat Microsoft den \u003Cstrong>Copilot-Plugin-Code für Eclipse\u003C\u002Fstrong> unter \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fcopilot-for-eclipse\" target=\"_blank\" rel=\"noopener noreferrer\">MIT-Lizenz veröffentlicht\u003C\u002Fa> — Repo ist \u003Ccode>microsoft\u002Fcopilot-for-eclipse\u003C\u002Fcode>. Was offen liegt: die Eclipse-spezifische Chat\u002FCompletion\u002FAgent\u002FPrompt-Integration. Was geschlossen bleibt: das AI-Backend selbst. Diese Aufteilung ist mittlerweile Standard bei den großen IDE-Vendoren — und sie funktioniert.\u003C\u002Fp>\n\u003Cp>Für Eclipse-Devs ist das eine kleine, aber wichtige Verbesserung. Bisher waren Eclipse-Nutzer in der Copilot-Welt zweite Klasse — die Integration kam später, hatte weniger Features und wurde langsamer gepatcht. Mit Open-Source-Code im MIT-Modell wird das anders. Patches können direkt von der Community kommen, Forks für regulierte Branchen werden möglich, und die Sichtbarkeit auf den Client-Layer ist gegeben — was für jedes DACH-Unternehmen mit Code-Audit-Anforderungen ein Plus ist.\u003C\u002Fp>\n\u003Cp>Begleitnews aus dem Copilot-Ökosystem dieser Woche: Am 14. Mai ist die \u003Ca href=\"https:\u002F\u002Fgithub.blog\u002Fchangelog\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">GitHub Copilot App im Technical Preview\u003C\u002Fa> gestartet — eine standalone Desktop-Experience für agent-driven Development. Am 18. Mai hat der \u003Cstrong>Copilot Cloud Agent\u003C\u002Fstrong> Fast\u002FCost-efficient Models für simple Tasks bekommen, also kleinere Modelle für triviale Patches statt Frontier-Models für jeden Trivialfix. Und am 20. Mai gab es ein Update der verfügbaren Models in Copilot on Web: \u003Cstrong>alle Gemini-Modelle wurden entfernt, OpenAI und Claude bleiben\u003C\u002Fstrong>. Ein bemerkenswerter Schritt nach Google I\u002FO — und ein klares Signal, wo Microsoft die langfristige Partnerschaft sieht.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Quelle:\u003C\u002Fstrong> \u003Ca href=\"https:\u002F\u002Fgithub.blog\u002Fcategory\u002Fengineering\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">GitHub Blog — Copilot for Eclipse Open Source\u003C\u002Fa> · \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fcopilot-for-eclipse\" target=\"_blank\" rel=\"noopener noreferrer\">microsoft\u002Fcopilot-for-eclipse\u003C\u002Fa>\u003C\u002Fp>\n\n\u003Ch2>Node.js v26.0.0 — Temporal API by Default, V8 14.6\u003C\u002Fh2>\n\u003Cp>Am 5. Mai ist \u003Ca href=\"https:\u002F\u002Fnodejs.org\u002Fen\u002Fblog\u002Frelease\u002Fv26.0.0\" target=\"_blank\" rel=\"noopener noreferrer\">Node.js v26.0.0 GA\u003C\u002Fa> erschienen und seitdem die neue Current-Linie. Der wichtigste Punkt für Application-Entwickler: Die \u003Cstrong>Temporal API ist by default aktiviert\u003C\u002Fstrong>. Wer in den letzten zwei Jahren JavaScript-Datumshandling angefasst hat, weiß, was das bedeutet — die historischen \u003Ccode>Date\u003C\u002Fcode>-Pathologien (Mutability, Timezone-Chaos, fehlende Duration-Arithmetik) sind nicht mehr das einzige Tool. \u003Ccode>Temporal.PlainDate\u003C\u002Fcode>, \u003Ccode>Temporal.ZonedDateTime\u003C\u002Fcode>, \u003Ccode>Temporal.Duration\u003C\u002Fcode> lassen sich ohne Polyfill nutzen.\u003C\u002Fp>\n\u003Cp>Daneben \u003Cstrong>V8 14.6.202.33\u003C\u002Fstrong>, \u003Cstrong>Undici 8\u003C\u002Fstrong> (HTTP-Client mit deutlich besserer Performance bei vielen parallelen Connections), ein Fix für \u003Cstrong>CVE-2026-21717\u003C\u002Fstrong> (V8 Array Index Hash Collision), \u003Cstrong>KeyObject-APIs mit Raw-Key-Format-Support\u003C\u002Fstrong> (relevant für Crypto-Pipelines mit Custom-Provider), \u003Cstrong>ICU 78.3\u003C\u002Fstrong> und \u003Cstrong>libuv 1.52.1\u003C\u002Fstrong>. v26.1.0 ist die aktuelle stable.\u003C\u002Fp>\n\u003Cp>Der LTS-Wechsel ist für Anfang Oktober geplant, dann wird v26 die nächste Long-Term-Linie. Wer heute auf v22 LTS oder v24 läuft, sollte v26 in der Dev-Pipeline schon evaluieren — gerade wegen der Temporal-API, die viele Date-Library-Dependencies ersetzen kann.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Quelle:\u003C\u002Fstrong> \u003Ca href=\"https:\u002F\u002Fnodejs.org\u002Fen\u002Fblog\u002Frelease\u002Fv26.0.0\" target=\"_blank\" rel=\"noopener noreferrer\">Node.js v26.0.0 Release Notes\u003C\u002Fa> · \u003Ca href=\"https:\u002F\u002Ftc39.es\u002Fproposal-temporal\u002Fdocs\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">TC39 Temporal Proposal\u003C\u002Fa>\u003C\u002Fp>\n\n\u003Ch2>Remix 3 verlässt React — Shopifys Framework geht eigene Wege\u003C\u002Fh2>\n\u003Cp>Die mit Abstand größte Front-End-News der Woche steht im \u003Ca href=\"https:\u002F\u002Fjavascriptweekly.com\u002Fissues\u002F786\" target=\"_blank\" rel=\"noopener noreferrer\">JavaScript Weekly #786 vom 19. Mai\u003C\u002Fa>: \u003Cstrong>Remix 3 Beta hat React komplett entfernt\u003C\u002Fstrong>. Shopify, die Remix 2022 übernommen haben, formulieren den Schritt offen — das Framework wird \"full-stack, web standards-first\" und kommt mit einem eigenen UI-Component-Model statt React-Komponenten.\u003C\u002Fp>\n\u003Cp>Klingt erst einmal radikal. Aber wenn du Remix in den letzten zwei Jahren beobachtet hast, war die Richtung absehbar: Loader-Pattern, Form-Actions, Streaming-First — vieles davon arbeitet gegen die React-Konventionen, nicht mit ihnen. Mit Remix 3 wird die Architektur konsistenter, und das eigene Component-Model orientiert sich an Web Components und Standards-First-Patterns. Für Teams, die heute Remix 2 produktiv betreiben, gibt es einen Migration-Pfad, aber Plain-React-Komponenten lassen sich nicht 1:1 mitnehmen.\u003C\u002Fp>\n\u003Cp>Was das strategisch heißt: React bleibt Marktführer für klassische Component-getriebene SPAs, aber das Web-Standards-Camp bekommt mit Remix 3 einen prominenten Vertreter, der nicht aus der Vue\u002FSvelte-Ecke kommt. Wer ein Greenfield-Projekt 2026 startet, sollte Remix 3 ernsthaft anschauen — vor allem, wenn der Use-Case stark Server-Rendered ist (E-Commerce, Content-Sites, klassische Web-Apps mit viel Form-Logik).\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Quelle:\u003C\u002Fstrong> \u003Ca href=\"https:\u002F\u002Fjavascriptweekly.com\u002Fissues\u002F786\" target=\"_blank\" rel=\"noopener noreferrer\">JavaScript Weekly #786\u003C\u002Fa> · \u003Ca href=\"https:\u002F\u002Fremix.run\u002Fblog\" target=\"_blank\" rel=\"noopener noreferrer\">Remix Blog\u003C\u002Fa> · \u003Ca href=\"https:\u002F\u002Fshopify.engineering\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">Shopify Engineering\u003C\u002Fa>\u003C\u002Fp>\n\n\u003Ch2>Fazit — Plattform-Reife in fünf Akten\u003C\u002Fh2>\n\u003Cp>KW22 zeigt Plattform-Engineering im Reife-Modus: Kubernetes v1.36 bringt die Features, die seit Jahren in Beta hingen, in den Stable-Status. GitLab 19.0 macht Multi-Agent-Workflows zum Default. GitHub öffnet einen weiteren Client-Layer (Eclipse) als Open Source, ohne den AI-Stack zu kompromittieren. Node.js v26 räumt mit einem 25 Jahre alten Date-Problem auf. Und Remix 3 zeigt, dass die Web-Standards-Front 2026 wieder konkurrenzfähig wird. Keine dieser News ist \"the next big thing\" — aber jede einzelne sitzt an einer Stelle, an der ein DACH-Team in den nächsten Monaten konkrete Entscheidungen treffen wird.\u003C\u002Fp>\n\n\u003Cp>\u003Cem>Kuratiert von SEADEV Studios. Weekly Tech News erscheint jeden Donnerstag.\u003C\u002Fem>\u003C\u002Fp>\n"]