Canonical treibt den Ausbau von Ubuntu für ARM64 weiter voran. Mit Ubuntu 26.04 LTS hat ARM64 in vielen zentralen Bereichen zu AMD64 aufgeschlossen. Zu den wichtigsten Neuerungen zählen der Umzug der ARM64-Pakete in das reguläre Ubuntu-Paketarchiv, Live-Kernel-Patching ohne Neustart sowie Fortschritte bei Snapdragon-Laptops, Gaming und der Software-Unterstützung. Das geht aus einem aktuellen Statusbericht der Ubuntu-Entwickler hervor.

Ubuntu unterstützt ARM-Prozessoren seit mehr als einem Jahrzehnt. Canonical konzentrierte sich mit seiner ARM64-Unterstützung zunächst vor allem auf Server, inzwischen ist die Architektur in Cloud-Rechenzentren, Entwicklerrechnern, Einplatinencomputern und zunehmend auch in Notebooks vertreten. Canonical verfolgt deshalb das Ziel, Ubuntu auf ARM64 nicht mehr als Sonderfall zu behandeln, sondern als vollwertige Hauptplattform.

ARM64-Pakete ziehen in das reguläre Ubuntu-Archiv um

Eine grundlegende Änderung betrifft die Paketinfrastruktur. Seit Ubuntu 26.04 LTS werden ARM64-Pakete nicht mehr über das bisherige Archiv ports.ubuntu.com ausgeliefert, sondern über archive.ubuntu.com. Damit nutzt ARM64 dieselbe Infrastruktur wie AMD64.

Der Wechsel sorgt dafür, dass Pakete automatisch über die weltweiten Ubuntu-Spiegelserver verteilt werden. Das soll Downloads beschleunigen und die Verfügbarkeit erhöhen. Für die Umstellung waren laut Canonical Anpassungen an mehreren Komponenten des Ubuntu-Build- und Release-Prozesses nötig. Die Änderungen sollen außerdem auf Ubuntu 24.04 LTS zurückportiert werden.

Livepatch schließt eine weitere Lücke

Seit Ende Juni unterstützt Ubuntu 26.04 LTS außerdem Livepatch auf ARM64. Sicherheitsupdates für den Linux-Kernel lassen sich damit einspielen, ohne das System neu starten zu müssen. Die Funktion stand bislang nur auf AMD64 zur Verfügung.

Nach Angaben von Canonical waren dafür unter anderem Erweiterungen im Linux-Kernel, der Toolchain sowie neue ARM64-spezifische Testverfahren erforderlich. Mit der Einführung erreicht der Livepatch-Dienst auf ARM64 denselben Funktionsumfang wie auf der x86-Plattform.

Fortschritte bei ARM-Notebooks

Canonical baut außerdem die Unterstützung für ARM-Notebooks aus. Ubuntu 25.04 führte die Unterstützung für Qualcomms Snapdragon-X-Elite-Plattform über das generische ARM64-Desktop-Image ein. Mit Ubuntu 25.10 funktioniert dort erstmals Secure Boot. Ubuntu 26.04 LTS ist die erste LTS-Version mit dieser Funktion.

Die Besonderheit: Viele Snapdragon-Notebooks stellen Linux derzeit keine Device Trees über die Firmware bereit. Device Trees beschreiben die vorhandene Hardware und werden vor allem auf ARM-Systemen zur Initialisierung verwendet. Canonical löst das Problem mit einem neuen EFI-Stub namens „stubble“, der die benötigten Device Trees direkt in das signierte Kernel-Abbild integriert. Dadurch bleibt die bestehende Secure-Boot-Vertrauenskette erhalten.

Parallel arbeitet Canonical bereits an der Unterstützung der nächsten Snapdragon-X2-Elite-Generation. Darüber hinaus weitet das Unternehmen die Hardware-Unterstützung auf weitere ARM-Hersteller aus. Als erstes Beispiel nennt Canonical ein Entwickler-Abbild für das Notebook CIX P1. Anders als Snapdragon-Geräte nutzt dessen Firmware den von PCs bekannten ACPI-Startprozess und benötigt deshalb die neue EFI-Lösung nicht.

Mehr Software ohne Umwege

Auch das Software-Angebot wächst. Ein ARM64-Build des Steam-Snaps wurde Anfang Juni als stabile Version veröffentlicht. Da der Linux-Client von Steam weiterhin nur für x86 verfügbar ist, kombiniert Canonical ihn mit dem Userspace-Emulator FEX. Dadurch lassen sich AMD64-Spiele auf unterstützten ARM-Systemen ausführen. Canonical betont allerdings, dass es sich dabei nicht um ein von Valve unterstütztes Projekt handelt.

Ferner verweist Canonical auf weitere native ARM64-Versionen populärer Snap-Pakete wie OnlyOffice, FreeCAD und Teams for Linux. Ein weiterer wichtiger Baustein kommt allerdings von Google: Canonical verweist auf die angekündigte ARM64-Version von Google Chrome, die Widevine-Unterstützung auf Linux bringen soll. Die Verfügbarkeit von Widevine auf ARM64 ermöglicht es auch anderen Snap-Paketen, darunter Firefox und Spotify, Widevine nativ einzubinden.

(fo)

Das neue Rechenzentrum in Lanarkshire, Schottland, soll ein zentraler Baustein in Großbritanniens KI-Strategie sein. Um diesen Status zu erlangen, müssen Projekte einen realistischen Plan vorlegen, wie sie sich mit Energie versorgen wollen. Die Gründer des Zentrums in Lanarkshire, CoreWeave (USA) und DataVita (UK), versprachen, man wolle ausschließlich lokal generierte erneuerbare Energie nutzen. Laut einem Medienbericht haben die Betreiber diese Pläne jedoch nie wirklich verfolgt – mit Kenntnis der britischen Regierung.

Das berichtet der Guardian nach Einsicht von Regierungsdokumenten. Man habe unter Regierungsvertretern bereits diskutiert, ob das Rechenzentrum sich mit eigenen Gaskraftwerken selbst versorgen soll. Auf Nachfrage des Guardian hieß es nun, man wolle den Komplex ans reguläre Netz anschließen. Hierauf wartet man in Großbritannien jedoch, egal ob als Klinik oder als Privatperson, wohl um die zehn Jahre. Ob das Datenzentrum also erst dann in Betrieb geht, oder beim Netzanschluss priorisiert wird, bleibt offen. Es solle jedoch nach wie vor zu einem „überwiegenden“ Anteil von Erneuerbaren versorgt werden, heißt es von Regierungsseiten.

Keine hinreichenden Bemühungen um erneuerbaren Strom erkennbar

Doch selbst daran gibt es Zweifel. DataVita gibt an, dass das Rechenzentrum mit mehr als 1 GW erneuerbarer Energie versorgt werden soll, darunter 400 MW Solarenergie und 800 MW Windenergie. Das ist mehr als das Eineinhalbfache der Windenergie, die von Whitelee, dem größten Onshore-Windpark Großbritanniens, erzeugt wird. Um das zu realisieren, würden je nach Technik für das Rechenzentrum schätzungsweise 40 bis 100 Quadratkilometer Land benötigt. Doch die derzeit vorliegenden Bauanträge von DataVita belaufen sich auf rund 2 km² in Lanarkshire. Auf seiner Website gibt DataVita an, über „mehr als 1.000 Acres“ an Anlagen zur Erzeugung erneuerbarer Energien zu verfügen, was 4 km² entspricht. Also bei Weitem nicht genug. Die HFD Group, die Muttergesellschaft von DataVita, plant laut veröffentlichten Konzepten bis zu neunzehn Windräder. Auch das würden nur etwa 5 Prozent von dem liefern, was DataVita produzieren will.

Ähnliche Diskrepanzen zwischen Ankündigung und Realität zeigen sich auch anderswo: Das britische KI-Prestigeprojekt Stargate UK entpuppte sich laut Guardian als PR-Stunt – ein Großteil der beworbenen 20-Milliarden-Pfund-Investition war nie als verbindliche Zusage hinterlegt. Es steht die Vermutung im Raum, dass auch hier vor allem Marketing betrieben wurde und das neue Rechenzentrum entgegen aller Ankündigungen also nicht ab 2030 voll mit erneuerbaren Energien betrieben wird – und das auch nie wirklich geplant war.

Zeitgleich drängt die Tech-Lobby die EU zur Aufweichung von Klimaregeln für Rechenzentren – die EU-Kommission erwägt, geplante Nachhaltigkeitsvorgaben für KI-Rechenzentren deutlich zu lockern.

(rie)

Das Node.js-Team diskutiert derzeit darüber, den Workflow für die Flut an eingereichten, LLM-generierten Sicherheitsmeldungen zu ändern. Ideen sind, die Meldungen öffentlich zu bearbeiten und mit künstlicher Intelligenz vorzusortieren.

Das Team hat das Problem jetzt auf die Agenda des nächsten Treffens der Security Working Group am 7. Juli gesetzt. Der Initiator Rafael Gonzaga schreibt, dass alle bisherigen Maßnahmen nicht geholfen haben: „Wir sind nach wie vor überlastet.“

Daher schlägt er vor, die eingereichten Meldungen zu veröffentlichen und als Pull Requests (PR) abzuarbeiten. Bei den Einreichungen handelt es sich oft nur um Bugs, die auch gefixt gehören, aber weniger um wirkliche sicherheitsrelevante Lücken. Außerdem kommen so viele gleichartige Meldungen an, die quasi jeder mit LLM erzeugen kann: „Diese Funde sind praktisch eh schon öffentlich.“ Als PR kann sich die Community darum kümmern und das Kernteam ist entlastet.

Eine Vorsortierung durch KI könnte nur die wirklich ernsthaften Lücken erkennen und nicht öffentlich an das Sicherheitsteam zur Bearbeitung weiterleiten.

Gegenstimmen geben zu bedenken, dass der Vorschlag die Masse an Sicherheitsreports durch eine Masse an PRs ersetzt, die auch vom Kernteam geprüft werden müssen. Außerdem könnten die veröffentlichten Lücken Hacker anziehen, „als kostenlose Quelle für Ideen für automatisierte Attacken.“ Daher schlagen andere Maintainer vor, nicht die komplette Öffentlichkeit einzubeziehen, aber den Kreis auf alle Mitarbeitenden (collaborators) zu erweitern.

Kampf gegen den AI-Slop

Wie viele andere Projekte kämpft Node.js mit AI Slop und hat im April bereits das Bug-Bounty-Programm zur Belohnung von Warnungen gestrichen. Auch zu solchen Maßnahmen waren andere Projekte bereits gezwungen. Das hat laut Gonzaga aber keine Erleichterung gebracht, da es den Einreichenden eher um den Ruhm als Autor auf einer offiziellen CVE-Warnmeldung zu erscheinen geht, als um Geld.

Auch andere Maßnahmen führten nicht zum Erfolg: höhere Hürden bei der Reporting-Plattform HackerOne, engere Relevanzkriterien und automatisiertes Schließen von Reports minderer Qualität. Letzteres hat sogar dazu geführt, dass mehr Meldungen bei der Mutter OpenJS landeten. „Bald wird auch dieses Team überlastet sein“, schließt Gonzaga.

(who)