Connect with us

Entwicklung & Code

ODF statt Lock-in: Wer kontrolliert unsere Dateien?


Wer kontrolliert unsere Dokumente – und wer entscheidet darüber, ob sie auch in zehn oder zwanzig Jahren noch lesbar, bearbeitbar und unabhängig von einem einzelnen Anbieter nutzbar sind? Für Italo Vignoli von der Document Foundation ist die Antwort klar: Die Debatte um digitale Souveränität beginnt nicht bei der Wahl einer Office-Suite, sondern beim Dateiformat. Im Gespräch erklärt er, warum er DOCX, XLSX und PPTX als strategisches Lock-in betrachtet, weshalb ODF aus seiner Sicht weit mehr ist als eine technische Alternative – und warum Behörden, Unternehmen und private Nutzer ihre Dokumentstrategie grundlegend überdenken sollten.

Weiterlesen nach der Anzeige

Der TDF-Blog war lange vor allem für Nachrichten rund um LibreOffice bekannt. Warum habt ihr gerade jetzt eine Reihe über offene Formate, Standards und digitale Souveränität gestartet?

Der TDF-Blog wurde eingerichtet, um über sämtliche Aktivitäten des Projekts zu berichten – nicht nur über LibreOffice, sondern auch über das Dokumentformat ODF, die von Document Liberation entwickelten Filter für ältere Formate, die Unterstützung politischer Initiativen zugunsten von FOSS sowie groß angelegte Migrationsprojekte. Die Liste ist tatsächlich sehr lang.

Die Idee für die aktuelle Artikelserie entstand im Vorfeld des zwanzigsten Jahrestags der Verabschiedung von ODF als OASIS-Standard im Mai 2025 – als Würdigung dieses außerordentlich wichtigen Meilensteins für FOSS. Das äußerst positive Feedback auf die ersten Artikel, die von verschiedenen Medien kommentiert und aufgegriffen wurden, ermutigte uns, die Reihe fortzusetzen und zudem auf weitere Themen auszuweiten, etwa auf digitale Souveränität – die eng mit ODF verbunden ist – und proprietäre Formate.

Die Anzahl der auf den Inhalten dieser Beitragsreihe beruhenden Artikel sowie das Interesse zahlreicher Journalisten an den behandelten Themen haben uns dazu bewogen, weiterzumachen – ursprünglich hatten wir eine Reihe von etwa zwanzig Artikeln vorgesehen – und uns an Diskussionen über digitale Souveränität zu beteiligen, nicht zuletzt, weil dieses Thema zu einem gemeinsamen Anliegen geworden ist.

Warum beginnt die Debatte über freie und unabhängige Bürosoftware bei Dateiformaten und nicht bei der Wahl der Anwendung?

In einer idealen Welt gäbe es ausschließlich Open-Source-Softwarelösungen, die sowohl bei Komponenten als auch bei Dokumentformaten nur offene Standards nutzen. Leider ist die Welt, in der wir leben, alles andere als ideal. Denn seit Jahrzehnten wurde die Kontrolle über Technologie völlig unkritisch in die Hände von Big Tech gelegt – mit den Folgen, die wir alle kennen.

Zu diesen Folgen zählt genau jenes proprietäre Format, das sich als offener Standard ausgibt und uns dazu zwingt, die Diskussion bei den Formaten statt bei den Anwendungen zu beginnen. Tatsächlich verwenden selbst die meisten Open-Source-Office-Suiten – oder jene, die sich als solche bezeichnen – dieses proprietäre Format nativ. Damit vergrößern sie Microsofts Kontrolle über Dokumente, denn Microsoft definiert das Format und entscheidet somit über dessen Interoperabilität.

Weiterlesen nach der Anzeige

„Open Source“, „offenes Format“ und „offener Standard“ werden häufig gleichbedeutend verwendet. Worin liegt der Unterschied – und warum sollte er nichttechnische Nutzer interessieren?

Die drei Begriffe unterscheiden sich grundsätzlich, weil sie sich auf völlig verschiedene Dinge beziehen: „Open Source“ bezeichnet Software, deren Quellcode verfügbar gemacht wird, damit er untersucht, verändert, verbessert und weiterverbreitet werden kann. Ein „offenes Format“ bezeichnet ein Dokumentformat, das transparent entwickelt, gut dokumentiert, versionskontrolliert und für kompetente Entwickler leicht implementierbar ist. Ein „offener Standard“ bezieht sich auf Elemente – Hardware, Software und mehr –, deren Eigenschaften eine einfache Wiederverwendung ohne Einschränkungen oder Begrenzungen ermöglichen.

LibreOffice ist Open Source, weil seine Copyleft-Lizenz MPL Nutzung, Untersuchung, Veränderung und Verbreitung erlaubt. ODF ist ein offenes Format, weil es von einer unabhängigen Organisation öffentlich und transparent entwickelt, entsprechend der jeweiligen Version konsistent dokumentiert, versionskontrolliert und leicht implementierbar ist. ODF ist zugleich ein offener Standard – teilweise aus denselben Gründen, aus denen es ein offenes Format ist, und teilweise, weil es andere offene Standards wiederverwendet und keinerlei proprietäre Elemente enthält.

DOCX, XLSX und PPTX werden fast überall verwendet. Wo genau entsteht dadurch aus Ihrer Sicht eine problematische Abhängigkeit von einzelnen Anbietern?

DOCX, XLSX und PPTX sind proprietäre Formate, weil sie eine Version des Formats verwenden, die als „Transitional“ bezeichnet wird, da sie weiterhin mit den proprietären Formaten DOC, XLS und PPT verknüpft ist. Diese Variante sollte 2010 durch eine Standardversion namens „Strict“ ersetzt und anschließend vollständig abgeschafft werden – gerade weil sie proprietär war.

Damals setzte ISO auf Microsoft, das all dies bei der Genehmigung des Formats zugesichert hatte. Von einer Standardisierung kann dabei in keiner Weise gesprochen werden, denn kaum etwas ist weiter von einem Standard entfernt als das Microsoft-Format – einschließlich der „Strict“-Version. ISO glaubte damals nicht jenen, die darin eine Strategie sahen, Zeit zu gewinnen und sicherzustellen, dass sich nichts ändert, damit das Microsoft-Office-Format dauerhaft proprietär bleibt. Die Geschichte hat uns recht gegeben.

DOCX, XLSX und PPTX – die ich jetzt unter dem offiziellen Namen des Formats, OOXML, zusammenfassen werde – sind unabhängig von der Software, dem Anwendungsfall oder dem Nutzertyp ein Problem. Proprietäre Formate sind immer ein Problem, weil sie von einem einzigen Unternehmen auf Grundlage eigener Geschäftsstrategien definiert werden, die nie mit den Interessen der Nutzer übereinstimmen.

Darüber hinaus sind diese Formate gezielt darauf ausgelegt, einen Lock-in zu erzeugen, der äußerst schwer zu erkennen ist, sofern man die technischen Eigenschaften des Formats nicht eingehend untersucht. Selbst die Softwareunternehmen, die sich entschieden haben, das OOXML-Format nativ zu unterstützen, sind sich dessen nicht bewusst, weil sie es nicht untersucht haben. Sie verwenden also ein Format, das ihre eigenen Nutzer bindet – allerdings zum Vorteil Microsofts, nicht zu ihrem eigenen.

Ich verstehe vollkommen, dass all dies wie Science-Fiction klingt. Leider handelt es sich jedoch um eine Realität, die selbst dann nicht erfasst wird, wenn man sie einfach – oder besser: so einfach wie möglich – erklärt. Leider gibt es keinen wirklich einfachen Weg, das Problem zu erläutern, denn es wurde bis ins kleinste Detail so konzipiert, dass es äußerst kompliziert ist.

Wie gut funktioniert die tägliche Arbeit mit ODF heute tatsächlich? Bei welchen Dokumenttypen ist der Wechsel unkompliziert, und wo sollten Nutzer realistischerweise Schwierigkeiten erwarten – etwa bei Makros, spezialisierten Vorlagen oder komplexen Tabellen?

ODF ist hinsichtlich der Funktionalität des Formats genauso gut wie OOXML. Es kann daher für jede Aufgabe und in jeder Anwendung problemlos eingesetzt werden und beeinträchtigt die Interoperabilität von Dateien nicht, da es vollständig dokumentiert ist.

OOXML hingegen wurde bewusst so konzipiert, dass es Interoperabilitätsprobleme verursacht. Es ist auch nicht so dokumentiert, dass dieses Problem entschärft würde, da sich die Formatspezifikationen durch regelmäßige Sicherheitsupdates auf nicht dokumentierte und unsichtbare Weise verändern.

Folglich werden Interoperabilitätsprobleme durch OOXML und nicht durch ODF verursacht. Daher sollten die Kosten dafür von OOXML-Nutzern getragen werden, nicht von ODF-Nutzern. Zudem gilt: Wenn ein Dokument im OOXML-Format korrekt erstellt wurde, lässt es sich auch im ODF-Format korrekt öffnen.

Ich nutze seit Jahren Linux und öffne daher alle OOXML-Dateien, die ich erhalte, mit LibreOffice. Es konvertiert sie sofort in das native ODF-Format. Dabei hatte ich noch nie ein Problem. Wenn ich einer Kontaktperson eine Datei im OOXML-Format senden muss, konvertiere ich die ODF-Datei in OOXML. Auch in diesem Fall hatte ich noch nie ein Problem. In meinem Beruf verfasse ich sehr viele Dokumente – wir sprechen von Tausenden Dateien.

Natürlich werden viele Dateien eher unsystematisch erstellt – und Sie können sich kaum vorstellen, wie kreativ Menschen dabei sein können. Deshalb öffnen sie sich in beide Richtungen nicht korrekt.

Meiner Erfahrung nach braucht es weniger Zeit, eine Datei zu korrigieren, als sich über Inkompatibilität zu beklagen, auch wenn sich die meisten Nutzer für Letzteres entscheiden. Solange wir jedoch ein Format haben, das gezielt dafür entwickelt wurde, Interoperabilitätsprobleme zu verursachen, wird sich die Situation nicht grundlegend ändern.

Makros wiederum sind ein komplett eigenes Problem, weil sie in keiner Weise zur Welt der Standards gehören. Eine ODF-Datei mit Makros ist mit einer OOXML-Datei mit Makros identisch – sie ist also mit jedem Standard unvereinbar, sofern keine neutrale Sprache wie Python verwendet wird.

Makros gehören zur ersten Generation von Office-Suiten und ergeben heute nur noch in sehr wenigen Fällen Sinn. Das liegt auch daran, dass viele dieser Funktionen inzwischen direkt in die Software integriert sind. Außerdem zählen sie zu den wichtigsten Sicherheitslücken und sollten deshalb niemals eingesetzt werden – insbesondere nicht in Umgebungen, die besonders stark von Angriffen bedroht sind.

Viele Organisationen meinen: „Wir würden gerne offene Formate nutzen, aber unsere Kunden und Partner schicken uns einfach Microsoft-Dateien.“ Wie lautet Ihre pragmatische Antwort darauf?

Die pragmatische Lösung ist zugleich die einfachste. Es handelt sich um die Methode, die wir im Migrationsprotokoll empfehlen – einem Dokument, das TDF auf Grundlage bewährter Verfahren erstellt hat. Diese haben sich in Dutzenden Projekten bewährt, darunter groß angelegte Vorhaben in Schleswig-Holstein und beim österreichischen Verteidigungsministerium.

Jedes eingehende Dokument sollte sofort in das ODF-Format konvertiert werden, um sämtliche Vorteile des Standardformats zu nutzen. Anschließend sollte es als zweite Kopie im OOXML-Format gespeichert werden, um die Interoperabilität mit proprietären Formaten sicherzustellen. Das dauert nur wenige Sekunden, und Speicherplatz ist sicherlich kein Problem.

Darüber hinaus ist das ODF-Format nicht nur wesentlich robuster als OOXML. In den sehr seltenen Fällen, in denen eine Datei beschädigt ist, ermöglicht es aufgrund der Eigenschaften des Standardformats und der perfekt lesbaren XML-Datei, sämtliche Inhalte wiederherzustellen. Eine beschädigte OOXML-Datei ist dagegen praktisch nicht wiederherstellbar.

Deutschland will offene Formate wie ODF bis 2027 stärker zum Standard in der öffentlichen Verwaltung machen. Was müsste passieren, damit dieses politische Ziel im Alltag ankommt?

Jede Migration zum Standardformat ODF ist möglich, sofern sie strukturiert angegangen wird – mit einem Projekt, das sowohl technische Aspekte, die sich leicht lösen lassen, als auch Aspekte der Umsetzung berücksichtigt, nämlich Prozesse und Nutzer.

Das Problem besteht leider darin, dass der Wechsel von OOXML zu ODF auch einen Wechsel von Microsoft Office oder einem seiner Klone zu LibreOffice erforderlich macht, weil die ODF-Unterstützung in diesen Programmen sehr schlecht ist, wie im jüngsten Artikel unserer Reihe erläutert wurde.

Diese Migration der Anwendungen fügt eine weitere Ebene der Komplexität hinzu. Wäre die ODF-Unterstützung ordentlich statt katastrophal, wäre die Migration des Formats allein kein Problem und würde lediglich die Anpassung einiger OOXML-basierter Prozesse erfordern.

Leider ist die schlechte ODF-Unterstützung Teil der Lock-in-Strategie von Microsoft und den Entwicklern seiner Klone. Wir können daher nicht erwarten, dass sie sich verbessert – selbst angesichts von Entscheidungen wie jener der deutschen Bundesregierung. Diesen Lock-in aufzugeben würde nämlich bedeuten, einen Marktanteil im Wert von fast 30 Milliarden US-Dollar nicht mehr zu schützen, bei einem Nettogewinn von mehr als 90 Prozent dieser Summe.

Warum scheitern ODF-Einführungen trotz klarer politischer Entscheidungen so oft: an der Technik, an Beschaffung, Schulungen und Gewohnheiten – oder an den Machtstrukturen des Softwaremarkts?

Tatsächlich haben sich die meisten Migrationen von Microsoft Office zu LibreOffice nie mit der Frage der Dokumentformate befasst, weil sie nicht von dem Ziel digitaler Souveränität angetrieben waren, sondern ausschließlich von den Softwarekosten. Deshalb haben Organisationen fast immer das OOXML-Format beibehalten.

Erst in den vergangenen Jahren hat die stärkere Fokussierung auf digitale Souveränität dazu geführt, dass Organisationen auch eine Migration von OOXML zu ODF in Betracht ziehen. Dies ist im Migrationsprotokoll bereits vorgesehen. Dabei handelt es sich zwar um einen zusätzlichen Schritt, der jedoch kein Problem darstellt.

Frühere gescheiterte Migrationen von proprietärer zu Open-Source-Software waren nie auf technische Probleme zurückzuführen – selbst wenn versucht wurde, sie als technische Probleme darzustellen. Im Fall München wurde beispielsweise das Dokument, das die technischen Probleme auflistete, von HP, einem Microsoft-Partner, erstellt und enthielt Behauptungen, die an Lächerlichkeit grenzten. Ähnliches geschah in Italien bei der Migration der Stadt Pesaro und der Provinz Bozen.

Es wäre außerdem sinnlos, die Tatsache zu ignorieren, dass die Unternehmen, die weltweit – und auch in Europa – am meisten für Lobbyarbeit ausgeben, die Big-Tech-Konzerne sind. Allein auf EU-Ebene belaufen sich ihre Budgets auf Millionen Euro, ganz zu schweigen von den Budgets der einzelnen Länder, die nicht öffentlich bekannt sind. In Brüssel, wo es Daten gibt, kommen auf jedes Mitglied des Europäischen Parlaments mehr als zwei Lobbyisten. Es ist ein ungleicher Kampf zwischen Open-Source-Software und proprietärer Software.

Machen Cloud-Dienste und KI-Werkzeuge offene Formate weniger wichtig, weil einzelne Dateien an Bedeutung verlieren – oder wichtiger, weil die Kontrolle über Inhalte und Metadaten schwieriger wird?

Dokumente bleiben Dokumente, auch in der Cloud und bei der Nutzung von KI-Werkzeugen. Was die meisten Menschen nicht erkennen, ist, dass sich das Dokument im Laufe der Jahre von einem einfachen Blatt Papier zu einer ausführbaren Datei entwickelt hat. Diese enthält die Anweisungen, die eine Software benötigt, um den Inhalt der Datei auf dem Bildschirm darzustellen. Sie ist daher nicht mehr so „unschuldig“ wie ihre gedruckte Version – jenes einfache Blatt Papier, aus dem sie hervorgegangen ist.

Deshalb ist das Format von Dokumenten wichtiger denn je. Der Unterschied zwischen einem standardisierten, offenen Format und einem proprietären Format ist vergleichbar mit dem Unterschied zwischen Open-Source-Software und proprietärer Software. Bei Dokumenten betrifft dieser Unterschied die Verwaltung der Inhalte: Beim Standardformat ist sie transparent dokumentiert, beim proprietären Format dagegen verschleiert dokumentiert und verwendet Verweise, die nur dem Autor bekannt sind – nämlich Microsoft.

Um eine leicht verständliche Parallele zu ziehen: Es ist, als läge der Schlüssel zu unserer Haustür in den Händen einer externen Instanz, die entscheiden kann, ob und wann wir unser eigenes Zuhause betreten dürfen. Bei einem Standardformat bleibt der Schlüssel immer in den Händen des Eigentümers.

Gibt es aus Ihrer Sicht einen allgemein akzeptierten Kriterienkatalog dafür, wann ein Format wirklich offen ist – oder bewertet die TDF Formate nach eigenen Maßstäben?

Es gibt mehrere Kriterien dafür, wann ein Format wirklich offen ist, auch wenn eine einheitliche Definition fehlt. Im TDF-Blog haben wir deshalb eine Definition veröffentlicht, die wir bei TDF verwenden.

Ihre Frage hat jedoch das Problem der fehlenden einheitlichen Definition deutlich gemacht. Deshalb werde ich auf der kommenden LibreOffice-Konferenz in Pordenone einen Vortrag halten, in dem ich gemeinsame Kriterien für eine solche Definition vorschlage. Mit diesem Thema beschäftige ich mich bereits, denn das Fehlen einer einheitlichen Definition sorgt auf dem Markt für einige Verwirrung.

Wenn eine Verwaltung morgen beginnen wollte: Was wäre die zentrale erste Maßnahme, die Sie unabhängig von Softwarepolitik und Lobbydruck empfehlen würden?

Für öffentliche Verwaltungen gibt es meines Erachtens ein zentrales Problem zu lösen, das in unserem Blogbeitrag „What is Digital Sovereignty?“ beschrieben wird: sicherzustellen, dass nichts Wesentliches verloren gehen kann.

Das entscheidende Wort ist dabei „wesentlich“. Eine Institution muss nicht selbst Eigentümerin der Cloud sein. Sie muss aber sicher sein, dass ihre Daten nicht ebenfalls verschwinden, wenn ein Anbieter morgen vom Markt verschwindet. Sie muss proprietäre Werkzeuge nicht verbieten. Sie muss jedoch gewährleisten, dass das, was sie diesen Werkzeugen anvertraut – ihre Akten, Verträge und Bürgerdaten –, auch für andere als den Anbieter, der das Werkzeug verkauft hat, lesbar, übertragbar und rekonstruierbar bleibt.

Souveränität bedeutet nicht, eine Mauer um den eigenen Besitz zu errichten. Sie ist eine Garantie dafür, aus einer Abhängigkeit aussteigen zu können.

Um dieses Ziel zu erreichen, kann die technische Entscheidung im Kern nur eine sein: Technologien und Werkzeuge zu wählen, die nicht von einem einzigen Unternehmen kontrolliert werden – es sei denn, sie sind vollständig Open Source. Natürlich kann diese Entscheidung angesichts der Entwicklungen der vergangenen Jahrzehnte äußerst schwierig und herausfordernd sein.

Es gibt öffentliche Verwaltungen, deren Infrastruktur auf Lösungen verschiedener Anbieter beruht, und andere, deren Infrastruktur von einem einzigen Anbieter abhängt. Erstere setzen in der Regel bereits zumindest teilweise auf Open Source, während Letztere meist ausschließlich proprietäre Software nutzen.

Der Weg zur digitalen Souveränität ist schwierig, weil dieses Konzept über zu viele Jahre hinweg ignoriert wurde. Es ist ironisch, dass heute alle über digitale Souveränität sprechen, während dieselben Akteure früher die Forderungen von Open-Source-Befürwortern ignoriert haben. Wir verwendeten damals zwar nicht den Begriff „digitale Souveränität“, vertraten aber bereits dasselbe Konzept.

Wenn Sie Nutzern und Organisationen nur eine einzige Regel für den langfristigen Umgang mit wichtigen Dokumenten geben könnten: Welche wäre das?

Die Regel ist sehr einfach: „aktive“ Dokumente – also solche, die bearbeitet werden müssen – sollten im ODF-Format verwaltet werden. „Historische“ Dokumente – also solche mit Referenzinformationen, die nicht verändert werden dürfen – sollten im PDF-Format verwaltet werden. Natürlich ist es auch möglich, alle Dokumente im ODF-Format zu speichern.

Herr Vignoli, vielen Dank für die Antworten!

Das Interview wurde auf Englisch geführt. Das Original findet sich hier.


(fo)



Source link

Entwicklung & Code

Linux-Kernel: Maintainer wollen „Assisted-by“-Tag streichen


KI-gestützte Patches für den Linux-Kernel benötigen künftig keinen „Assisted by“-Tag in der Commit-Nachricht mehr. Dafür sprach sich eine Mehrheit der rund 30 geladenen Entwicklerinnen und Entwickler auf dem Maintainers Summit aus, der am 8. Oktober in Prag stattfand.

Weiterlesen nach der Anzeige

Ganz umgesetzt ist dieser Konsens noch nicht. Auf der Linux-Kernel-Mailingliste ist ein entsprechender Patch indes schon eingereicht. Sasha Levin, Distinguished Software Engineer bei Nvidia und Co-Maintainer der Stable- und LTS-Kernel, beantragte dort am 9. Oktober, die Tag-Vorgabe aus der Dokumentation zu streichen. Der zuständige Maintainer Jonathan Corbet hat den Patch inzwischen in den Entwicklungszweig docs-next übernommen, in den Mainline-Kernel muss er es aber noch schaffen.

Die Chancen dafür stehen gut, denn Linus Torvalds und Greg Kroah-Hartman, ebenfalls einer der prominentesten Kernel-Entwickler, unterstützen die Änderung. Auf der Mailingliste sind die Meinungen allerdings geteilt.

Was Entwickler bei KI-gestützten Kernel-Patches beachten müssen, regelt seit Linux 7.0 die Richtlinie AI Coding Assistants, basierend auf dem Konsens des Maintainers Summit 2025 und einem am 23. Dezember 2025 eingereichten Patch, den Jonathan Corbet im Januar 2026 absegnete.

Seitdem werden Entwicklerinnen und Entwickler darum gebeten, einen „Assisted by“-Tag für ihre Commits zu verwenden, wenn diese mithilfe eines fortgeschrittenen Coding-Tools wie eines LLM zustande kommen. Initiiert hatte die Richtlinie ebenfalls Sasha Levin, der nun für die Abschaffung des Tags plädiert hat. Ein erster Vorschlag, ihn zu streichen, war im Juli noch gescheitert; damals hatte sich auch Kroah-Hartman für die Beibehaltung ausgesprochen.

Die Begründung für die Abschaffung reichte Levin in seinem überarbeiteten Patch vom 13. Oktober nach: Nur rund 10 Prozent der 18.533 Commits in Linux 7.3 bis -rc7 tragen den Tag, Merge-Commits nicht mitgezählt. Tatsächlich werde KI aber viel häufiger eingesetzt. Manche Entwickler kennen die Regel laut Levin nicht, andere lassen den Tag absichtlich weg, und kaum ein Maintainer fragt nach. Ein fehlender Tag sage deshalb nichts darüber aus, wie ein Patch entstanden ist. Bei Entwicklern, die KI für fast alles nutzen, sage aber auch ein gesetzter Tag wenig.

Der Grundgedanke, Maintainern Transparenz über die Entstehung eines Patches zu verschaffen, soll aber weiterhin gelten. Wie KI-Tools eingesetzt wurden, sollen Entwickler künftig im Cover-Letter beschreiben, der Begleitmail zu einem Patch oder einer Patch-Serie. In die Commit-Nachricht gehört es nicht mehr.

Weiterlesen nach der Anzeige

Landet der Patch im Mainline-Kernel, erschließt sich aus der Git-Historie künftig nicht mehr direkt, welche Änderungen mit KI-Hilfe entstanden sind. Verlässlich war das allerdings schon bisher nicht. Unverändert bleibt die Verantwortung: KI-Agenten dürfen keine Signed-off-by-Zeile setzen.

Linus Torvalds hält wenig von Regeln für KI-Werkzeuge. Regeln, die den Einsatz bestimmter Werkzeuge verbieten, nennt er „stupid“. Er erwarte, dass Leute verstehen, was sie tun. Mit den verwendeten Werkzeugen habe dieses Verständnis aber wenig zu tun.

Torvalds hat fast zeitgleich mit dem Summit selbst Kernel-Code mit einem LLM entwickelt. In der Commit-Nachricht schreibt er, der Code, die Testprogramme, die Prüfung, auf der die Liste bekannter Probleme beruht, und der erste Entwurf des Textes seien mit Claude Code unter seiner Anleitung entstanden. Die Patches sollen das Lesen aus dem Page-Cache deutlich beschleunigen, wenn viele Threads gleichzeitig kleine Blöcke aus derselben Datei lesen.

Lesen Sie auch


(mro)



Source link

Weiterlesen

Entwicklung & Code

Kolibri-1 denkt deutsch. Hilft das auch beim Antworten?


Lange mussten wir auf ein Modell warten, das speziell auch mit deutschen Texten gut umgehen kann. Zwischenzeitlich kam mit der Ankündigung des Soofi-Modells Hoffnung auf. Diese zerstreute sich aber sehr schnell wieder, weil das Modell bis heute nicht frei zugänglich ist und das Konsortium wohl auch beim Training sehr kreativ Benchmark-Daten mitverwendet hat. Umso gespannter kann man auf das nun veröffentlichte Kolibri-1-Modell von Aleph Alpha sein.

Weiterlesen nach der Anzeige

iX-plore ist die Online-Serie des iX-Magazins für alle, die neue Tools und Technologien entdecken möchten. In kurzen Beiträgen stellen wir vor, was sie können, wofür sie sich eignen und warum sich ein genauerer Blick lohnen könnte.

Zuerst fällt die Größe des Modells ins Auge: Sie ist mit 78 Milliarden Parametern relativ unkonventionell. Bei vielen Modellen haben sich zwischenzeitlich Standardgrößen etabliert. In dieses Schema passt das Modell nicht. Die Anzahl der Experten ist mit 384 für diese Anzahl an Parametern verhältnismäßig groß, was bei sechs gerouteten und einem festen Experten zu nur 3,46 Milliarden aktiven Parametern in der Inferenz führt. Die Gewichte der regulären Veröffentlichung liegen überwiegend quantisiert in FP8 vor; einzelne Modellbestandteile bleiben in bfloat16. Daneben bietet Aleph Alpha eine BF16-Version an.

Die Architektur kann man durchaus als traditionell bezeichnen: Kolibri-1 verwendet zwar eine hybride Attention-Architektur mit vier Sliding-Window-Attention-Layern (SWA), die sich mit einem Layer mit voller Attention abwechseln. Für letztere nutzt das Modell aber Grouped Query Attention, die Anbieter wie DeepSeek oder Qwen schon seit einigen Generationen aussortiert haben. Möglicherweise führt das auch zu dem etwas kleineren Kontext von „nur“ 256K Token, den man bei der Inferenz auf rund eine Million Token extrapolieren kann.


Architektur eines Kolibri-Blocks mit Aufmerksamkeits- und Mixture-of-Experts-Schichten.

Architektur eines Kolibri-Blocks mit Aufmerksamkeits- und Mixture-of-Experts-Schichten.

Die Architektur von Kolibri-1.

(Bild: Aleph Alpha)

Kolibri-1 beherrscht außerdem Reasoning; es kann also seine Antworten in einer Art „Denkprozess“ begründen. Dessen Länge lässt sich in drei Stufen steuern. So kann man verhindern, dass das Modell bei einfachen Fragen unnötig lange nachdenkt. Bis dahin bietet das Modell keine großen Überraschungen.

Weiterlesen nach der Anzeige

Diese folgen allerdings bei den Trainingsdaten, die anders aufbereitet sind als die der Wettbewerber. Das fängt schon „ganz vorn“ im Modell an, nämlich im Tokenizer.

Der Tokenizer verantwortet die Aufteilung der Texte in Wörter beziehungsweise deren Bestandteile, die Token. Viele mehrsprachige Modelle, insbesondere die der chinesischen Anbieter, müssen hier Kompromisse eingehen, damit sich möglichst viele Wörter (oder Wortbestandteile) der unterschiedlichen Sprachen effizient darstellen lassen. Da Aleph Alpha sich auf Deutsch und Englisch konzentriert, gibt es dieses Problem hier so nicht. Daher kann Kolibri englische und insbesondere deutsche Wörter mit weniger Token darstellen. Das ist nicht nur interessant, wenn man nach Token bezahlen muss, sondern auch in der internen Verarbeitung. Spart man 10 Prozent der Token ein, kann das die Verarbeitung nahezu genauso stark beschleunigen.

Kolibri-1 eignet sich auch besonders für rechtliche und politische Inhalte. Spaßeshalber kann man ausprobieren, wie viele Token es für das gesamte Glossar des Bundestags benötigt. Kolibri-1 benötigt dafür 1137 Token, das zum Vergleich hinzugezogene sehr innovative DeepSeek-V4.1-Flash braucht 1910 Token – was für ein Unterschied! Hier kann man also viele Token sparen und mit kürzeren Kontexten arbeiten. Außerdem kann die Verarbeitung damit schneller werden, weil viele Wörter nicht mehr aus ihren Bestandteilen zusammengesetzt werden müssen. Dies erhöht gleichzeitig die Präzision der Vorhersagen.

Ausgestattet mit diesem Tokenizer hat Aleph Alpha das Modell mit 20 Billionen Token im Pre-Training trainiert und dabei Inhalte bis zum 18. Juni 2026 genutzt. Das ist also sehr aktuell, denn das Basis-Training dauert üblicherweise viele Wochen oder Monate. Wie viele andere Anbieter verwendet auch Aleph Alpha Common-Crawl-Daten, beschreibt dafür aber sehr ausführlich einen Deduplikationsprozess, für den die Entwickler neben statischen Tests zusätzlich andere LLMs wie Gemma-4-26B-A4B verwenden. Um auf den im Tech Report genannten Anteil von 21,3 Prozent zu kommen, genügen die darin enthaltenen Daten allerdings nicht. Stattdessen haben die Entwickler ein weiteres Modell (Mistral-NeMo-12B) verwendet, um englische Inhalte auf Deutsch neu formulieren zu lassen. Zusätzlich kamen auch übersetzte Daten zum Einsatz, die man teilweise manuell kuratiert hat, um bei der Übersetzung nicht zu wörtlich zu bleiben.

Viel Aufwand widmet Aleph Alpha der Qualitätssicherung, in der andere Modelle als „Judge“ zum Einsatz kommen. Damit und mithilfe daraus berechneter Korrelationen kann man besonders „gute“ Dokumente identifizieren, die anschließend in einen „Data-Mix“ kommen. Dabei erhalten unterschiedliche Quellen verschieden hohe Gewichte, die mit der Güte ihrer Dokumente zusammenhängen.

Diese eigene Datenpipeline erlaubt es dem Anbieter, später neuere Daten leichter über den Trainingsprozess in künftige Modellversionen zu integrieren.


Tabelle mit Domänen, Datensätzen und Token-Anzahl, daneben ein Kreisdiagramm mit Prozentangaben.

Tabelle mit Domänen, Datensätzen und Token-Anzahl, daneben ein Kreisdiagramm mit Prozentangaben.

Die Verteilung der Pre-Training-Daten.

(Bild: Aleph Alpha)

Im sich anschließenden sogenannten Mid-Training verwendet Aleph Alpha 3,4 Billionen Token „höherwertiger“ Inhalte, darunter logische Schlussfolgerungen, mathematische Dokumente und Programmcode. Im Mid-Training verlängert sich der Kontext von 16K auf 64K, um in der letzten Pre-Training-Phase schließlich 256K zu erreichen. Das spart erhebliche Rechenkapazität in den aufwendigen ersten Trainingsphasen. Auch im Mid-Training nutzt Kolibri-1 Daten aus der Pipeline, die je nach Qualität gemischt werden. Dabei verwenden die Entwickler jeweils eine Variante von DeepSeeks Auxiliary Free Load Balancing, die sie Exact Quantile Balancing nennen, um alle Experten „gleichmäßig“ zu trainieren. Aleph Alpha nutzt daneben noch die sogenannte Load-Error Injection, um auch in den Micro-Batches alle Experten zu berücksichtigen. Unterschiedliche Weiterentwicklungen dieser „Balancier“-Methoden haben sich nun bei fast allen Anbietern durchgesetzt, insbesondere wenn sie viele Experten nutzen.

Im Post-Training muss das Modell lernen, Fragen richtig zu beantworten. Auch dafür verwenden die Entwickler deutsche und englische Daten aus unterschiedlichen Bereichen wie Toolnutzung, Instruction Following und Code. Auch diese Daten sind zum Teil von anderen Modellen generiert, nämlich von GLM-5.2, GLM-5.3 und Qwen3.8-27B. Letzteres erstaunt, denn das Modell steht erst seit Ende August zur Verfügung. Aleph Alpha bringt dem Modell bei, seine Denktiefe zu steuern und seine Gedankengänge auf Deutsch zu formulieren. In letzterem Punkt unterscheidet es sich damit von fast allen anderen verfügbaren Modellen, die immer Englisch denken. Eine weitere Besonderheit ist das Merlin-Arthur-Protokoll. Damit versucht man, dem Modell Halluzinationen abzutrainieren. Es funktioniert wie ein Spiel, bei dem man relevante und irrelevante Teile der Antwort verdeckt. Das Modell muss dann ohne dieses Wissen entscheiden, welche Antwort besser passt, und erhält für die richtige Wahl eine Belohnung. Offenbar zeigt das Verfahren Wirkung, denn in den Benchmarks kann man erkennen, dass das Modell spürbar seltener halluziniert.

Bei allen Trainingsdaten achtet Aleph Alpha darauf, den EU AI Act und die DSGVO einzuhalten. Außerdem passt der Anbieter das Modell auf den „demokratischen Konsens“ in Europa an. Man könnte die Formulierung so verstehen, dass es auch Antworten gibt, die chinesischen Modellen aus politischen Gründen nicht erlaubt sind.

Natürlich ist der Trainingsprozess enorm aufwendig. Er verwendet dazu den Muon-Optimizer, um die Modellgewichte anzupassen, für die Skalierungsfaktoren und Gewichte der Embeddings ist weiterhin der allgegenwärtige AdamW-Optimizer zuständig.

Die dafür notwendige Infrastruktur ist gewaltig: Das Pre-Training fand auf 768 Nvidia-B200-GPUs über 96 Knoten statt, dafür fielen laut Modellkarte rund 392.000 GPU-Stunden an (also etwa 45 GPU-Jahre). Für das Reinforcement Learning im Post-Training setzte Aleph Alpha einen Cluster aus 256 Nvidia-B300-GPUs ein. Besonders interessant daran ist, dass 144 GPUs nur für die Inferenz zuständig waren. Das liegt vermutlich daran, dass das GRPO-Verfahren unterschiedliche Antworten benötigt, die es dann gegeneinander bewertet. Es handelt sich um eine beachtliche Leistung, das alles nach dem Knowledge-Cutoff Mitte Juni bis Ende September zu erledigen. Sicher gab es dazu Vorarbeiten: Aleph Alpha hat zuvor das Modell Kolibri Origin trainiert.

Um das Training reproduzierbar zu machen, arbeitet Aleph Alpha mit einer sogenannten ModelFactory. Das kann man sich als eine Art Rezept (in Form von Code) vorstellen, das das Training des Modells genau beschreibt. Diese Rezepte sind einer Versionskontrolle unterworfen, sodass sich das gesamte Training reproduzieren lässt. Dies setzt voraus, dass man über die nötige Infrastruktur verfügt und bereit ist, entsprechend viel Rechenzeit zu investieren. Energiekosten darf man dabei auch nicht vernachlässigen, Aleph Alpha schätzt 950 MWh, was bei einem kWh-Preis von 0,30 Euro (der für solche Großkunden sicher niedriger ist) 285.000 Euro entspricht.

Da das Modell mit offenen Gewichten bereitsteht, kann man es problemlos ausprobieren. vLLM unterstützt das Modell mit einem Plugin, auch für llama.cpp gibt es schon Unterstützung mit einem kleinen Patch.

Erwartungsgemäß funktioniert das Modell sehr schnell. Das liegt an den nur knapp vier Milliarden aktiven Parametern. Es spielt damit fast in der gleichen Geschwindigkeitsliga wie Qwen3.5-35B-A3B. Die Antworten des Modells sind alle richtig. Besonders auffällig ist der (antrainierte) deutsche Reasoning-Prozess. Die Antwort zur Waschanlage ist zwar etwas umständlich, bei vielen anderen Modellen liegt jedoch der Verdacht nahe, dass diese Frage bereits in der Trainingsmenge enthalten ist, wenn die Antwort sehr kurz und teilweise auch noch mit Emojis ironisch formuliert ist.

Alles in allem funktioniert das Modell sehr gut. Ob es Halluzinationen wirklich besser vermeiden kann als andere, muss sich im Praxisbetrieb noch zeigen. Auch mit Fragen wie „Organisierte der in Hannover ansässige Heise Verlag, der viel zu Computern schreibt, auch die Computermesse CeBIT?“ ließ sich das Modell nicht durcheinanderbringen, sondern antwortete richtig, dass die Deutsche Messe AG die CeBIT bis 2018 organisierte. Versucht man es umgekehrt mit „Welche Messen organisiert der Heise Verlag aus Hannover?“, erhält man die Antwort, dass das Modell keine Antwort wisse und man auf die Website schauen solle – nicht schlecht!

Kolibri-1 ist ein wirklich solides Modell, das sehr gut Deutsch spricht und auch auf Deutsch argumentiert. Damit ist es für die vorgesehenen Anwendungsfälle in Unternehmen und Behörden prädestiniert. Technisch ist es dafür gut gerüstet, denn man kann es autark und souverän auf eigener Infrastruktur betreiben.

Sehr interessant liest sich der technische Bericht, der auch dort nicht mit Details spart, die andere gern auslassen. So erfährt man nicht nur vom Design des Tokenizers, sondern auch, wie die Trainingsmenge entstand, welche anderen Modelle dabei eine Rolle spielten und wie alles zusammenfloss. Deutlich kann man erkennen, wie viel Engineering da eingeflossen ist. Das tröstet etwas über die „altbackene“ Architektur hinweg.

Spannend ist auch die ModelFactory, die aus einfachen, lesbaren Code-Bausteinen die Modelle entstehen lässt. Ein Muster an Nachvollziehbarkeit, das ein DSGVO- und EU-AI-Act-kompatibles Modell auszeichnet.

Lesen Sie auch


(fo)



Source link

Weiterlesen

Entwicklung & Code

Nie mehr Schaltsekunden | heise online


Die Schaltsekunde wird zum 20. Mai 2027 abgeschafft. Beschlossen hat dies am Donnerstag die Generalkonferenz für Maß und Gewicht in Paris. Bis Mai wird es auch keine Schaltsekunde mehr geben. Stattdessen sind nun Schaltstunden vorgesehen. Bis eine Schaltstunde erforderlich ist, wird geraume Zeit verstreichen, jedenfalls mehr als 1.000 Jahre. heise online wird berichten.

Weiterlesen nach der Anzeige

Schaltsekunden wurden 1972 eingeführt, um die mit Atomuhren exakt bestimmte koordinierte Weltzeit (UTC) mit der auf der nicht ganz so exakten getakteten Rotation der Erde basierenden Weltzeit (UT1) zu synchronisieren. Ab 0,9 Sekunden Differenz wurde dem 30. Juni oder 31. Dezember eine Sekunde (23:59:60) hinzugefügt. 27 mal war das der Fall, zuletzt Ende 2016.

Doch in den letzten Jahren hat sich der Trend umgekehrt: Ungefähr seit Beginn des Jahrzehnts dauert eine Erdrotation im Durchschnitt nicht mehr länger, sondern kürzer als 86.400 Atomsekunden. Mit der Zeit könnte das eine negative Schaltsekunde erfordern, auf die technische Systeme nicht vorbereitet sind. 2025 haben Experten haben die Wahrscheinlichkeit der Notwendigkeit einer negativen Schaltsekunde bis 2035 auf 30 Prozent taxiert.

Nicht zuletzt Technikbetreiber mit Einfluss haben sich daher für die generelle Abschaffung von Schaltsekunden eingesetzt, seien sie nun negativ oder positiv. Daher hat 2022 die 27. Generalkonferenz für Maß und Gewicht beschlossen, mit der Internationalen Fernmeldeunion und anderen Betroffenen darüber zu diskutieren, wie die zulässige Abweichung spätestens 2035 erhöht werden soll. Mindestens 100 Jahre sollten keine Maßnahmen notwendig sein; gedacht wurde insbesondere an Schaltminuten.

Die Konsultationen haben zu einer drastischeren Maßnahme geführt: UTC und UT1 dürfen in Zukunft bis zu eine ganze Stunde abweichen, wie nun bei der 28. Generalkonferenz für Maß und Gewicht bestimmt worden ist (Resolution 5). Erst ab 3.600 Sekunden Abweichung soll eine Schaltstunde wieder für Ordnung sorgen. Bis dahin dürften mehr als 1.000, vielleicht sogar 3.000 Jahre vergehen, schätzen Experten.

Wesentliches Argument für die theoretische Schaltstunde statt vielleicht echter Schaltminuten ist, dass viele Länder bereits Zeitzonen haben, die mehr als eine Stunde von der wahren Sonnenzeit abweichen. Der jüngste Trend zu ganzjährigen Sommerzeitzonen hat diese Fehler noch verstärkt. Da kommt es auf die Schwankung der Erdrotation auch nicht mehr an.

Weiterlesen nach der Anzeige

Außerdem haben verschiedene technische Systeme die bisherigen Schaltsekunden unterschiedlich umgesetzt. Beispielsweise ignorieren die Uhren in GPS-Satelliten Schaltsekunden und sind daher der UTC 18 Sekunden voraus. GLONASS hingegen übernimmt Schaltsekunden direkt in seine Zeitgeber.

Fortan sollen sich Programmierer darüber nicht mehr den Kopf zerbrechen müssen. Falsche Schaltsekundenbefehle gehören damit hoffentlich der Vergangenheit an.


(ds)



Source link

Weiterlesen

Beliebt