Im Zuge der Veröffentlichung von VS Code 1.107 wurde bekannt, dass Microsoft die beliebte Erweiterung IntelliCode, die über 60 Millionen Downloads verzeichnete, deaktiviert hat: Die Extension ist nun veraltet (deprecated) und die grauen Inline-Vorschläge funktionieren nicht mehr.

Microsoft verweist in der gut versteckten Ankündigung von Mitte November auf die KI-Erweiterung von Copilot in VS Code, die allerdings nur ein Freivolumen von 2.000 Vorschlägen bietet – eine Grenze, die Entwicklerinnen und Entwickler schnell erreichen, da der Copilot bei jeder Eingabe einen Vorschlag macht. Ab dann benötigen Anwender eine kostenpflichtige Lizenz. Die Nutzung von IntelliCode erforderte ein lokales Modell, war dadurch aber unbegrenzt kostenfrei.

Noch kostenlos gibt es das klassische IntelliSense mit Language Server für die genutzte Sprache – allerdings ohne KI-Unterstützung. Von der Abschaltung betroffen sind die Extensions:

• IntelliCode
• IntelliCode Completions
• IntelliCode for C# Dev Kit
• IntelliCode API Usage Examples

TypeScript 7 und mehr Agenten für VS Code

In der Ankündigung zu VS Code 1.107 ist nichts von IntelliCode zu finden. Neu ist aber die experimentelle Unterstützung von TypeScript 7 mit dem neuen, in Go geschriebenen Compiler. Dieser lässt sich updaten mit:

npm install @typescript/native-preview

Der Aufruf erfolgt mit

npx tsgo

statt tsc. Die Konfiguration in VS Code erfolgt mit

{ "typescript.experimental.useTsgo": true }

Weitere Neuerungen im Editor betreffen Agenten, die sich nun über den Chat steuern lassen. Sie laufen auch weiter, wenn der Anwender den Chat geschlossen hat. Entwicklerinnen und Entwickler können Agenten ferner in andere Umgebungen verschieben, mit Kontext anreichern oder als Unteragenten einordnen. Der Blog spricht militärisch von einem Agent Head Quarter (HQ).

(who)

Das Projekt uutils hat Version 0.5.0 seiner Rust Coreutils veröffentlicht. Die in Rust geschriebene Neuimplementierung klassischer Unix-Kommandozeilenprogramme erreicht damit 87,75 Prozent Kompatibilität zur GNU-Test-Suite – ein Anstieg um knapp zwei Prozentpunkte gegenüber Version 0.4.0. Von insgesamt 645 Tests bestehen die Rust Coreutils nun 566, während 55 fehlschlagen, 23 übersprungen werden und einer zu einem Fehler führt.

Die Entwickler haben die Referenz-Test-Suite von GNU Coreutils 9.8 auf 9.9 aktualisiert, wodurch elf neue Tests hinzukamen. Trotz dieser zusätzlichen Prüfungen konnten 22 weitere Tests erfolgreich absolviert werden. Besonders hervorzuheben sind Verbesserungen bei den Utilities fold, cksum, install, numfmt und seq. Das Tool fold unterstützt nun kombinierende Unicode-Zeichen für korrekte Textumbrüche, während cksum mit hashsum zusammengeführt wurde und nun eine einheitliche Checksum-Funktion bietet.

Plattform-Unterstützung ausgebaut

Mit Version 0.5.0 erweitert das Projekt seinen Plattform-Support erheblich. OpenBSD wurde in die CI-Pipeline aufgenommen, die Redox-OS-Unterstützung reaktiviert und der Cygwin-Support in der uucore-Bibliothek verbessert. Als Folge hiervon können nun zehn zuvor übersprungene Tests ausgeführt werden. Die Rust Coreutils laufen damit offiziell auf Linux-Distributionen wie Ubuntu 25.10, FreeBSD, OpenBSD, Windows via Cygwin und dem experimentellen Betriebssystem Redox.

Canonical hatte bereits angekündigt, die Rust Coreutils in Ubuntu standardmäßig einzusetzen – primär aufgrund der Vorteile von Rust in puncto Speichersicherheit. Die Version 0.3.0 hatte bereits gezeigt, dass das sort-Tool in CPU-lastigen Szenarien bis zu 3,7-mal schneller arbeitet als sein GNU-Pendant – andere Tools wie expand (1,8×) oder nl (1,57×) zeigen ebenfalls deutliche Geschwindigkeitsgewinne als die GNU-Pendants. Bei IO-gebundenen Operationen fallen die Unterschiede geringer aus.

Noch 12 Prozent bis zur vollen Kompatibilität

Trotz der Fortschritte gibt es weiterhin Herausforderungen. Von den 55 fehlgeschlagenen Tests betreffen einige kritische Edge-Cases bei Tools wie cksum (crc32b mit --raw-Flag), od (Floating-Point-Operationen) und chroot. Auf GitHub verzeichnet das Projekt rund 380 offene Issues, die sich mit verbliebenen Inkompatibilitäten befassen. Für Administratoren, die einen produktiven Einsatz erwägen, empfehlen sich umfangreiche Tests der eigenen Skripte – insbesondere solche mit GNU-spezifischen Flags oder ungewöhnlichen Optionskombinationen.

Die Sicherheitsvorteile von Rust kommen bei den Coreutils zum Tragen: Speicherfehler wie Buffer-Overflows und unsichere Path-Traversal-Operationen gehören der Vergangenheit an. Tools wie chmod nutzen bereits sichere Traversierungsmethoden. Allerdings warnen Kritiker vor neuen Fehlerklassen, die durch Rust-spezifische Ownership-Semantik entstehen könnten. Im Gegensatz zu den jahrzehntelang gehärteten GNU Coreutils ist die Rust-Variante noch vergleichsweise jung.

An Version 0.5.0 haben sechs neue Contributor mitgewirkt. Das Projekt ruft zu Übersetzungen via Weblate auf und bittet um Unterstützung über GitHub Sponsors. Die Maintainer-Basis umfasst etablierte Entwickler wie Sylvestre Ledru von Debian und Daniel Hofstetter, der in einem iX-Interview die langfristigen Ziele des Projekts erläuterte.

Für Distributionen stellt sich die Frage nach der Paketierung: Ubuntu 25.10 setzt die Rust Coreutils standardmäßig ein, Nutzer können per apt purge coreutils-from-uutils zu den GNU-Varianten zurückkehren. FreeBSD bietet einen Port über FreshPorts an. Die MIT-Lizenz der Rust Coreutils ist mit der GPL der GNU Coreutils kompatibel und erlaubt eine problemlose Integration in Distributionen.

Die Download-Binaries für Version 0.5.0 stehen auf der Projekt-Website und über die GitHub-Releases bereit. Anwender sollten vor einem produktiven Einsatz die Test-Coverage-Dokumentation konsultieren und kritische Workflows prüfen.

(fo)

In der Webentwicklung schreiben wir nicht nur neue Software, sondern es erreichen uns natürlich auch Fehlermeldungen. Meistens können wir schnell helfen oder den Bugfix auf jeden Fall für einen der nächsten Sprints einplanen. Aber manche Fehler sind hartnäckiger und haben am Ende eine ganz simple Ursache. Um solch einen Fehler geht es heute.

Eine Zeit lang erreichten uns immer mal wieder Berichte, dass bei Usern die Verbindung zu www.heise.de mit der Meldung ERR_HTTP2_PROTOCOL_ERROR nicht zustande kam. Schnell kristallisierte sich heraus, dass die betroffenen User noch ein paar Gemeinsamkeiten hatten: Alle nutzten Chrome als Browser und waren regelmäßige Besucher unseres Angebots. Damit war der Fehler zwar schon etwas eingegrenzt, aber unser größtes Problem war: Wir selbst konnten den Fehler lange Zeit nicht nachstellen.

Viele Kekse

Die Überlegungen gingen dennoch weiter. Was sammeln User (leider heutzutage) zuhauf, wenn sie auf einem weitgehend werbefinanzierten Angebot wie heise online unterwegs sind? – Cookies. Ein Test mit betroffenen Usern sorgte dann immerhin für einen Workaround: Cookies löschen half.

Zunächst hatten wir die Cookie-Größe im Verdacht und testeten mit besonders großen Cookies, aber auch damit ließ sich das Problem für uns nicht reproduzieren. Doch dann meldete sich ein Kollege aus der Redaktion mit demselben Fehler – er bekam ihn sogar regelmäßig. Wir baten ihn um Hilfe bei der Lösung, und er gab Bescheid, sobald der Bug erneut auftrat. Endlich konnten wir das Problem direkt beobachten.

Mit tcpdump schnitten wir den Netzwerkverkehr zwischen uns und dem Browser auf dem Load-Balancer (BigIP) mit, der TLS und HTTP2 termininiert. Dabei stellte sich heraus, dass BigIP selbst die HTTP2-Verbindung wegen eines „Protokollfehlers“ beendete. Da heise online nicht einfach eine direkte Verbindung vom Browser des Users zu unserem Webserver hat, sondern noch diverse (Netzwerk-)Infrastruktur dazwischen liegt, war es für uns schon mal sehr hilfreich, den Punkt ausfindig zu machen, an dem die Verbindung bricht und welcher Teil in der Kette diesen Abbruch auslöst.

Blick in die Bug-Reports

Mit den gewonnenen Erkenntnissen durchforsteten wir die Chrome-Bug-Reports. Bei einem Report war ein HTTP2-Protokoll-Mitschnitt angefügt, bei dem wir sehen konnten, dass Chrome jeden Cookie im HTTP2-Request mit einem separaten Set-Cookie-Header sendete. Das brachte uns auf die Idee, statt der Cookie-Größe einfach mit der schieren Anzahl zu experimentieren, und siehe da: Mit sehr vielen, kleinen Cookies ließ sich das Problem reproduzieren.

Ab hier wurde es dann einfach. Mithilfe unserer Admins fanden wir eine Einstellung in der BigIP, die die maximal zulässige Anzahl der Header setzte. Dieses Limit verschoben wir nun deutlich nach oben und schon war das Problem gelöst. Jedenfalls fürs Erste, denn natürlich ist das neue höhere Limit mit noch mehr Cookie-Headern ebenfalls wieder erreichbar, und der Fehler käme zurück.

Am Fehler sind aber noch ein paar Dinge interessant. In HTTP/1.x waren mehrere Cookie-Header noch unzulässig (siehe RFC 6265), in HTTP/2 hingegen kann der User Agent jedes Cookie als einzelnen Header senden (siehe RFC 7540) und genau das hat Chrome hier getan. Dieses Verhalten ist offensichtlich eine Optimierung, denn das Übertragen sich wiederholender Header lässt sich in HTTP/2 mit der HPACK-Header-Komprimierung (siehe RFC 7541) enorm optimieren. Das funktioniert aber nur für Header, die sich nicht ständig ändern. Ein großer Cookie-Header für alle Cookies müsste also immer wieder komplett neu übertragen werden, sobald sich auch nur ein einzelnes Cookie ändert.

Chrome zeigte leider in den Developer-Tools nichts davon an. Dort wird immer nur ein Cookie-Header gelistet, was die Fehlersuche nicht unbedingt erleichtert hat.

Ob das nun eine Problemlösung oder lediglich ein großes Pflaster ist, wird die Zeit zeigen. Die Ursachenforschung war aber definitiv mal wieder eine der interessanteren Recherchen im Developer-Alltag.

(rme)