heise developer News

Neu in .NET 10.0 [3]: C# 14.0

2025-12-26T08:00:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

C# 14.0 wird mit .NET 10.0 ausgeliefert. Man kann dennoch einige C# 14.0-Sprachfeatures auch in älteren .NET-Versionen nutzen.

(Bild: Pincasso/Shutterstock)

26.12.2025, 09:00 Uhr

Lesezeit: 2 Min.

Developer

Von

Dr. Holger Schwichtenberg

In einem .NET 10.0-Projekt (Projekteinstellung in .csproj-Datei: <TargetFramework>net10.0</TargetFramework>) ist C#-Sprachversion 14.0 der automatisch eingestellte Standard, auch ohne zusätzliches Tag <LangVersion>.

Dr. Holger Schwichtenberg ist technischer Leiter des Expertennetzwerks www.IT-Visions.de, das mit 53 renommierten Experten zahlreiche mittlere und große Unternehmen durch Beratungen und Schulungen sowie bei der Softwareentwicklung unterstützt. Durch seine Auftritte auf zahlreichen nationalen und internationalen Fachkonferenzen sowie mehr als 90 Fachbücher und mehr als 1500 Fachartikel gehört Holger Schwichtenberg zu den bekanntesten Experten für .NET und Webtechniken in Deutschland.

C# 14.0 wird offiziell von Microsoft erst ab .NET 10.0 unterstützt. Auf der Learn-Site von Microsoft heißt es: „C# 14.0 is supported only on .NET 10 and newer versions.“

Entwicklerinnen und Entwickler können allerdings auf eigene Verantwortung einige (aber nicht alle!) C# 14.0-Sprachfeatures in älteren .NET-Versionen einschließlich .NET Framework, .NET Core und Xamarin nutzen. Dazu muss man die <LangVersion> in der Projektdatei (.csproj) auf „14.0“ erhöhen:

<PropertyGroup>
  <TargetFramework>.net8.0</TargetFramework>
  <LangVersion>14.0</LangVersion>
</PropertyGroup>

Bitte beachten Sie aber, dass es für den Einsatz von C#-14.0-Sprachfeatures in .NET-Versionen vor 10.0 keinen technischen Support von Microsoft gibt. Bei Problemen können Sie Ihren Supportvertrag nicht nutzen, um Microsoft um Hilfe zu ersuchen. Dennoch ist der Einsatz höherer C#-Versionen in älteren .NET-Projekten in einigen Unternehmen gängige und problemlose Praxis.

Videos by heise

In C# 14.0 sind gegenüber Version 13.0 acht wesentliche Neuerungen erschienen (die in den folgenden Wochen in dieser Blogserie vorgestellt werden):

Neue Operatorüberladungen für +=, -=, *=, /=, %=, &=, |=, ^=, <<=, >>= und >>>
Erweiterungsblöcke mit dem Schlüsselwort extension
Semi-Auto Properties mit dem Schlüsselwort field (die gab es schon in C# 13.0, dort aber experimentell)
Partielle Konstruktoren und partielle Ereignisse
Null-Conditional Assignment
Vereinfachung für nameof() mit generischen Typen
Vereinfachungen bei Lambda-Ausdrücken
Mehr Konvertierungen für Spans

Von den oben genannten neuen Sprachfeatures in .NET 10.0 funktionieren alle bis auf eine Ausnahme auch in älteren .NET-Versionen, sofern man <LangVersion>latest</LangVersion> in der Projektdatei setzt. Die Ausnahme sind die neuen Operatorüberladungen. Um diese geht es im nächsten Artikel dieser Serie.

(rme)

Der beste Full-HD-Beamer für Heimkino, TV & Konsole

Die besten Tuner für DAB+ zum Nachrüsten für die Stereoanlage

Top 10: Die beste Smartwatch 2025 im Test

Ruby 4.0: Viel Umbau unter der Haube, wenig neue Features

2025-12-25T06:36:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Die neue Major-Version mit einem neuen JIT-Compiler, überarbeiteter Parallelsierungs-API und einem reifendem Typsystem ebnet den Weg für die nächste Dekade.

(Bild: Erzeugt mit Midjourney durch heise online)

25.12.2025, 07:36 Uhr

Lesezeit: 16 Min.

iX Magazin

Von

Stefan Wintermeyer

Am 21. Dezember 2025 wurde die Sprache Ruby 30 Jahre alt – und seit rund 20 Jahren veröffentlicht ihr Schöpfer, Yukihiro Matsumoto (Matz), jedes Jahr zu Weihnachten eine neue größere Version, am 25. Dezember 2025 sogar eine mit der runden Versionsnummer 4.0. Die ist, soviel sei vorweggenommen, eher Dekoration und dem Jubiläum geschuldet als tatsächlich durch zahlreiche neue Features gerechtfertigt. Doch da Ruby ohnehin keiner strengen semantischen Versionierung folgt und größere Breaking Changes meidet wie der Teufel das Weihwasser (zumindest seit Ruby 1.9), ist das legitim.

Stefan Wintermeyer ist freier Consultant und Trainer. Er beschäftigt sich mit Phoenix Framework, Ruby on Rails, Webperformance und Asterisk.

Andererseits war 2025 ein spannendes Jahr für Ruby und die Ruby-on-Rails-Welt, so dass dieser Artikel neben dem Blick nach vorn auf Ruby 4 auch auf das zurückblickt, was Ruby in den letzten Monaten technisch erreicht hat und die jetzt erschienene Version in diesem Kontext stellt. Denn obwohl das Vorurteil von Ruby als langsamer Sprache schwer auszurotten ist, hat die Sprache durch langjährige, fortdauernde Entwicklung eine beeindruckende Performance entwickelt.

Der mit Ruby 3.4 noch einmal deutlich optimierte Just-in-Time-Compiler YJIT erreicht in Benchmarks von Shopify eine Leistungssteigerung von 92 Prozent gegenüber dem Interpreter. Der Praxisbeweis kam am Black Friday 2025: Shopify wickelte mit seiner Ruby-on-Rails-Infrastruktur Einkäufe von 81 Millionen Kunden ab. Die Spitzenlast betrug 117 Millionen Requests pro Minute auf den Applikationsservern, während die Datenbanken 53 Millionen Lesezugriffe und 2 Millionen Schreibzugriffe pro Sekunde bewältigten.

Doch auch die Arbeiten an künftigen Performance-Optimierungen gehen weiter voran. Die technisch bedeutendste Neuerung in Ruby 4 ist ZJIT, ein experimenteller Method-Based-JIT-Compiler, den das gleiche Team bei Shopify entwickelt wie YJIT. ZJIT wurde im Mai 2025 nach Matz' Zustimmung auf der Konferenz RubyKaigi in den Master-Branch gemerged.

ZJIT unterscheidet sich architektonisch fundamental von YJIT. Während YJIT den Bytecode der Ruby-VM YARV direkt in Low-Level-IR kompiliert und dabei einen Basic-Block nach dem anderen verarbeitet (Lazy Basic Block Versioning), verwendet ZJIT die Static Single Assignment Form (SSA) als High-Level Intermediate Representation (HIR) und kompiliert komplette Methoden auf einmal. Diese Architektur soll breiteren Community-Beiträgen den Weg ebnen und langfristig die Speicherung kompilierten Codes zwischen Programmausführungen ermöglichen.

Der Name ZJIT hat übrigens keine bestimmte Bedeutung, sondern steht einfach für den Nachfolger von YJIT. Intern wird ZJIT als der „wissenschaftliche Nachfolger“ bezeichnet, da die Architektur klassischen Compiler-Lehrbüchern entspricht und damit leichter zu verstehen und zu erweitern ist. Der Compiler ist als experimentell eingestuft und bringt derzeit in produktiven Projekten noch keine Vorteile. Wer sich damit beschäftigen will, muss Ruby mit der Configure-Option --enable-zjit neu bauen und bei der Ausführung Ruby mit der Option --zjit aufrufen.

Syntaktische Feinheiten

Seit Ruby 3.4 gibt es mit it einen eleganten impliziten Block-Parameter für Einzeiler. Er ist lesbarer als die nummerierten Parameter (_1, _2), die seit Ruby 2.7 existieren, und spart die explizite Parameterdeklaration. Die klassische Deklaration mit explizitem Parameter

users.map { |user| user.name }

und mit impliziten nummeriertem Parameter

users.map { _1.name }

wird also ergänzt durch

users.map { it.name }

Besonders intuitiv und praktisch ist das beim Method Chaining:

files
  .select { it.size > 1024 }
  .map { it.basename }
  .sort { it.downcase }

Der Bezeichner it liest sich wie natürliche Sprache und macht den Code selbstdokumentierend. Wichtig: it funktioniert nur in Blöcken mit genau einem Parameter. Bei mehreren Parametern bleiben _1, _2 oder explizite Namen die richtige Wahl.

Der Splat-Operator (*) entpackt Arrays in einzelne Elemente – etwa um die Elemente aus [1, 2, 3] als drei separate Argumente an eine Methode zu übergeben. Ab Ruby 4.0 ruft der Ausdruck *nil nun nicht mehr nil.to_a auf, sondern liefert direkt ein leeres Array. Das entspricht dem Verhalten des Double-Splat-Operators (**) für Hashes, bei dem **nil bereits seit längerem nil.to_hash nicht mehr aufruft. Diese Vereinheitlichung macht das Verhalten konsistenter und weniger überraschend. Das zeigt sich zum Beispiel, wenn man optionale Elemente, zum Beispiel aus einer Datenbank-Abfrage, in ein Array einfügen will:

optional_tags = nil

Mit Ruby 4.0 funktioniert das sauber – *nil wird zu nichts und muss nicht explizit abgefangen werden:

post = { title: "Ruby 4.0", tags: ["news", *optional_tags, "ruby"] }
#=> { title: "Ruby 4.0", tags: ["news", "ruby"] }

Die binären logischen Operatoren ||, &&, and und or am Zeilenanfang setzen nun die vorherige Zeile fort – analog zum Fluent-Dot-Stil bei Methodenketten. Das ermöglicht elegantere Formatierung von Bedingungen, analog zum Method Chaining:

result = first_condition
   second_condition
  && third_condition

Diese Änderung erlaubt bessere Lesbarkeit bei längeren logischen Ausdrücken, ohne Backslashes oder Klammern zur Zeilenfortsetzung verwenden zu müssen.

Ractors: Echte Parallelität für Ruby

Ractors sind Rubys Antwort auf das Problem der echten Parallelität. Anders als Threads, die durch den Global VM Lock (GVL) serialisiert werden, können Ractors tatsächlich parallel auf mehreren CPU-Kernen laufen. Der Name ist ein Kofferwort aus Ruby und Actor – das Konzept basiert auf dem Actor-Modell, bei dem isolierte Einheiten ausschließlich über Nachrichten kommunizieren. Ractors gelten auch in Ruby 4.0 noch als experimentell. Der IRB zeigt eine entsprechende Warnung an.

Der GVL war lange Zeit Rubys größte Schwäche bei CPU-intensiven Aufgaben. Zwar konnten Threads I/O-Operationen parallelisieren, da der Lock bei I/O freigegeben wird, aber Berechnungen liefen immer sequentiell. Ractors umgehen dieses Problem, da sie sich keinen gemeinsamen GVL mehr teilen; jeder Ractor führt den Code unabhängig aus. Ruby synchronisiert intern nur noch an spezifischen Punkten.

Jeder Ractor besitzt seinen eigenen Speicherbereich. Objekte können nicht zwischen Ractors geteilt werden – außer sie sind unveränderlich. Diese strikte Isolation eliminiert Race Conditions by Design (siehe Listing 1):

Listing 1: Lebenszyklus eines Ractor im IRB

$ irb
irb(main):001> r = Ractor.new { 2 + 2 }
(irb):1: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues.
=> #<Ractor:#2 (irb):1 terminated>
irb(main):002> r.join
=> #<Ractor:#2 (irb):1 terminated>
irb(main):003> puts r.value
4
=> nil

Das Beispiel zeigt den typischen Ractor-Lebenszyklus: Ractor.new startet einen neuen Ractor mit dem übergebenen Block, join wartet auf dessen Beendigung, und value liefert das Ergebnis – hier die berechnete Summe 4. Bei einer so simplen Berechnung wie 2 + 2 ist der Ractor bereits beendet (terminated), bevor der Aufruf von join erfolgt. Der Vollständigkeit halber zeigt das Beispiel trotzdem den kompletten Ablauf – bei längeren Berechnungen ist join essenziell, um auf das Ergebnis zu warten.

Listing 2: Fibonacci-Zahlen mit Ractors

irb(main):004> def fib(n) = n < 2 ? n : fib(n-1) + fib(n-2)
irb(main):005* ractors = [35, 36, 37, 38].map do |n|
irb(main):006*   Ractor.new(n) { fib(it) }
irb(main):007> end
=> 
[#<Ractor:#3 (irb):6 running>,
...
irb(main):008> results = ractors.map(&:value)
=> [9227465, 14930352, 24157817, 39088169]

Ractors zeigen ihre Stärke bei CPU-intensiven Aufgaben. Das Beispiel in Listing 2 demonstriert das. Es berechnet mittelgroße Fibonacci-Zahlen parallel. Auf einem Vier-Kern-System läuft dieses Beispiel nahezu viermal so schnell wie die sequentielle Variante. Im Tarai-Benchmark – einem klassischen Rekursions-Test – erreichen vier parallele Ractors eine 3,87-fache Beschleunigung gegenüber sequentieller Ausführung.

Ruby 4.0 überarbeitet das Ractor-API grundlegend. Die alten Methoden Ractor.yield, Ractor#take und die close_*-Methoden wurden entfernt. An ihre Stelle tritt Ractor::Port für die Kommunikation zwischen Ractors.

Die wichtigste Regel: Ein Port kann nur von dem Ractor empfangen werden, der ihn erstellt hat. Für bidirektionale Kommunikation benötigt daher jeder Ractor seinen eigenen Port (siehe Listing 3)

Listing 3: Kommunikation zwischen Ractors mittels Ports

# Port des Haupt-Ractors für Antworten
main_port = Ractor::Port.new

worker = Ractor.new(main_port) do |reply_port|
  # Worker erstellt eigenen Port für eingehende Nachrichten
  worker_port = Ractor::Port.new
  reply_port.send(worker_port)  # teilt seinen Port mit

  num = worker_port.receive     # empfängt von eigenem Port
  reply_port.send(num * 2)      # sendet Ergebnis zurück
end

worker_port = main_port.receive  # erhält Worker-Port
worker_port.send(21)             # sendet Aufgabe
puts main_port.receive           # => 42

Nicht alles darf geteilt werden

Die strikte Isolation von Ractors bedeutet, dass nicht jedes Objekt zwischen ihnen ausgetauscht werden kann. Ruby unterscheidet zwischen teilbaren (shareable) und nicht-teilbaren Objekten. Unveränderliche Objekte sind automatisch teilbar:

Ractor.shareable?(42)       #=> true
Ractor.shareable?(:symbol)  #=> true
Ractor.shareable?("text")   #=> false

Per Deep Freeze lassen sich aber Objekte explizit teilbar machen:

config = Ractor.make_shareable({ host: "localhost" })

Neu in Ruby 4.0 sind Shareable Procs und Ractor-lokaler Speicher. Damit lassen sich auch komplexere Szenarien umsetzen, bei denen Funktionen zwischen Ractors geteilt oder Daten innerhalb eines Ractors persistiert werden müssen.

Das Typsystem: RBS und die Zukunft

Ruby war und ist eine dynamisch typisierte Sprache und prüft Variablentypen werden erst zur Laufzeit statt bei der Kompilierung. Doch die Arbeit am optionalen Typsystem zeigt, dass statische Analyse und dynamische Flexibilität koexistieren können. Ruby 4.0 markiert einen wichtigen Meilenstein auf diesem Weg.

RBS (Ruby Signature) ist das offizielle Format für Typdefinitionen. Anders als Annotationen im Quellcode werden RBS-Definitionen in separaten .rbs-Dateien gepflegt – ähnlich wie in TypeScript die .d.ts-Dateien. Dieser Ansatz hat einen entscheidenden Vorteil: Bestehender Ruby-Code muss nicht verändert werden, Teams können Typdefinitionen schrittweise einführen (siehe Listing 4).

Listing 4: Typdefinitionen

# sig/user.rbs
class User
  attr_reader name: String    # Pflichtfeld: muss String sein
  attr_reader age: Integer?   # Optional: Integer oder nil

  # Rückgabe: void (kein Rückgabewert relevant)
  def initialize: (String, ?Integer) -> void

  # Prädikatmethode: gibt bool zurück
  def adult?: -> bool
end

Fehler finden mit Steep

Steep, der Referenz-Typchecker für RBS, findet Bugs, die sonst erst zur Laufzeit auffallen würden. Ein vollständiges Beispiel zeigen die Listings 5 und 6.

Diese Fehler würden ohne Typsystem erst zur Laufzeit auffallen. Mit RBS und Steep werden sie bereits beim Entwickeln oder spätestens in der CI-Pipeline erkannt. Das spart nicht nur Debugging-Zeit, sondern verhindert auch, dass solche Bugs überhaupt in Produktion gelangen.

Typechecks und Agentic Coding

KI-gestützte Coding-Assistenten wie GitHub Copilot, Cursor oder Claude generieren heute ganze Funktionen und Klassen auf Knopfdruck. Doch Large Language Models halluzinieren – sie erfinden Methodennamen, verwechseln Parameter-Reihenfolgen oder übergeben Strings, wo Integers erwartet werden. Bei dynamisch typisierten Sprachen wie Ruby fallen solche Fehler erst zur Laufzeit auf – im schlimmsten Fall in Produktion.

Hier entfaltet das RBS-Typsystem seinen vollen Wert: Steep fungiert beim Agentic Coding als Sicherheitsnetz. Generiert ein Assistent eine Funktion, die User.find_by_email mit einem Integer statt String aufruft, meldet Steep den Fehler sofort – noch bevor der Code ausgeführt wird. Die Feedback-Schleife verkürzt sich von „Laufzeitfehler nach Deployment“ auf „rote Unterstreichung im Editor“.

Noch wichtiger: RBS-Definitionen verbessern die Qualität der KI-Vorschläge selbst. Coding-Assistenten nutzen den Kontext – und Typsignaturen sind extrem dichter Kontext. Eine RBS-Datei dokumentiert nicht nur, welche Typen eine Methode akzeptiert, sondern kommuniziert auch die Intention des Codes. KI-Modelle, die auf Typdefinitionen trainiert wurden, generieren präziseren Code, weil sie die Constraints verstehen. Das Zusammenspiel in der Praxis:

Entwickler schreibt RBS-Signatur für neue Methode
KI-Assistent generiert Implementation basierend auf Signatur
Steep validiert generierten Code gegen Typdefinition
Fehler werden sofort sichtbar, Korrektur erfolgt vor Commit

Für Teams, die intensiv mit KI-Assistenten arbeiten, ist ein Typsystem oft keine optionale Ergänzung mehr – es ist die Qualitätssicherung, die verhindert, dass halluzinierter Code in die Codebasis gelangt. Ruby mit RBS bietet hier das Beste aus beiden Welten: die Flexibilität einer dynamischen Sprache mit der Sicherheit statischer Analyse, genau dort, wo man sie braucht.

Videos by heise

Die Vision: Graduelle Typisierung

Das langfristige Ziel ist ein Ökosystem der graduellen Typisierung. Entwickler sollen selbst entscheiden können, wie viel statische Analyse sie wünschen – von gar keine bis strikt überall. Anders als TypeScript, das JavaScript mit Typen erweitert, bleibt Ruby syntaktisch unverändert. Die Typen leben in separaten Dateien und sind vollständig optional.

Die Bausteine für dieses Ökosystem sind bereits vorhanden:

RBS Collection: Eine wachsende Bibliothek von Typdefinitionen für populäre Gems. Die IDE RubyMine lädt diese automatisch herunter und nutzt sie für Autovervollständigung und Fehlerprüfung. In VS Code ist die manuelle Einrichtung via rbs collection install nötig, danach funktioniert die Autovervollständigung mit der Ruby LSP Extension.
Steep: Der offizielle statische Typchecker, der RBS-Definitionen gegen den Quellcode prüft und in CI-Pipelines integriert werden kann.
TypeProf: Ein Inferenz-Tool, das aus bestehendem Code automatisch RBS-Definitionen generiert – ideal für die schrittweise Einführung von Typen in Legacy-Projekten.
Sorbet-Integration: Stripes alternativer Type-Checker erhöht die RBS-Kompatibilität, was die Interoperabilität zwischen beiden Systemen verbessert.

Prism: Der neue Standard-Parser

Ein Parser ist das Programm, das Quellcode liest und in eine strukturierte Darstellung übersetzt – den Abstract Syntax Tree (AST). Erst durch diese Baumstruktur kann der Interpreter verstehen, was der Code bedeutet. Seit Ruby 3.4 ist Prism der Standard-Parser und ersetzt den 30 Jahre alten parse.y. Prism wurde in C99 ohne externe Abhängigkeiten geschrieben, ist fehlertolerant und portabel.

Die Benchmarks sprechen für sich: Prism ist 2,56-mal schneller beim Parsen zu C-Structs gegenüber parse.y und zwölfmal schneller als das Parser-Gem beim AST-Walk. Für Entwickler bedeutet das schnellere IDE-Reaktionen und kürzere CI-Zeiten. Bei Kompatibilitätsproblemen kann der klassische Parser weiterhin aktiviert werden:

ruby --parser=parse.y script.rb

Für die meisten Projekte sollte Prism jedoch problemlos funktionieren.

Ruby-Versionen verwalten – von RVM zu mise

Wer Ruby 4.0 parallel zu älteren Versionen betreiben möchte, braucht einen Version Manager. Diese Tools lösen ein grundlegendes Problem: Jedes Ruby-Projekt kann eine andere Ruby-Version erfordern, und Gems sind nicht zwischen Ruby-Versionen kompatibel.

Version Manager installieren mehrere Ruby-Versionen isoliert voneinander – typischerweise unter ~/.rvm, ~/.asdf oder ~/.local/share/mise. Jede Ruby-Version erhält ihr eigenes Verzeichnis mit einem eigenen gem-Ordner. Fürht man also gem install rails unter Ruby 3.3 aus, landet Rails in einem anderen Verzeichnis als unter Ruby 4.0. Gems müssen daher für jede Ruby-Version separat installiert werden. Bundler (bundle install) erledigt das automatisch basierend auf dem Gemfile.

Welche Ruby-Version für ein Projekt gilt, bestimmt eine Datei im Projektverzeichnis: .ruby-version (einfacher Standard) oder .tool-versions (für asdf und mise, kann auch Node, Python etc. definieren). Wechselt man ins Projektverzeichnis, aktiviert der Version Manager automatisch die richtige Ruby-Version.

Der erste populäre Ruby Version Manager war RVM. Er modifiziert die Shell-Umgebung tiefgreifend und verwaltet zusätzlich Gemsets – isolierte Gem-Umgebungen pro Projekt. Das war vor Bundler (2010) revolutionär, da es keine andere Möglichkeit gab, Gem-Abhängigkeiten pro Projekt zu isolieren. Heute sind Gemsets obsolet, da Bundler diese Aufgabe besser löst.

asdf löste RVM für viele Teams ab. Der entscheidende Vorteil: Ein Tool für alle Sprachen. Über Plugins verwaltet asdf Ruby, Node.js, Python, Elixir und dutzende weitere Runtimes einheitlich. Die .tool-versions-Datei im Projektverzeichnis definiert alle benötigten Versionen. asdf ist weniger invasiv als RVM, in Bash geschrieben und integriert sich sauber in die Shell.

Der aktuelle Trend geht zu mise, benannt nach dem Mise en place bei Köchen. Entwickelt vom asdf-Maintainer Jeff Dickey, ist mise ein kompletter Rewrite in Rust. Die Vorteile: deutlich schneller (Rust statt Bash), kompatibel mit asdf-Plugins und .tool-versions-Dateien, aber auch mit eigenen Backends. mise aktiviert Versionen ohne Shell-Hooks über Shims – ein einfaches mise activate in der Shell-Konfiguration genügt. Zudem kann mise Umgebungsvariablen und Tasks verwalten, was es zu einem universellen Manager für Entwicklungsumgebungen macht. So wird Ruby 4 mit mise installiert:

mise install ruby@4.0.0
mise use ruby@4.0.0
mise activate  # einmalig in .bashrc/.zshrc

Für neue Projekte ist mise die beste Wahl. Es ist schnell, modern und vielseitig. Bestehende asdf-Setups funktionieren weiter, mise liest deren Konfiguration. RVM-Nutzer sollten den Umstieg erwägen.

Breaking Changes im Detail

Die praktische Breaking-Change-Bilanz von Ruby 4.0 ist moderat. Fedora bewertet: Da sich mit Ruby 4.0 der soname, also der Bezeichner für Shared Libraries ändert, müssen Pakete mit binären Erweiterungen neu gebaut werden. Da aber große Aufmerksamkeit auf Quellkompatibilität gelegt wurde, sind keine Code-Änderungen nötig. Weitere Breaking Changes sind:

Binding#local_variables enthält keine nummerierten Parameter mehr
ObjectSpace._id2ref ist deprecated
CGI-Library aus Default Gems entfernt (nur cgi/escape bleibt)
SortedSet entfernt und erfordert die Gem sorted_set
String-Literal-Warnung: In Dateien ohne frozen_string_literal-Kommentar erzeugt Mutation eine Deprecation-Warnung

Problematisch bleibt die Pessimistic-Constraint-Praxis vieler Gems: ~> 3.x in required_ruby_version verhindert die Installation unter Ruby 4.0, auch wenn der Code ohne Änderungen laufen würde.

Fazit: Evolution statt Revolution

Für Entwickler bedeutet Ruby 4.0 vor allem Kontinuität: Bestehender Code läuft weiter, die Performance verbessert sich weiter (YJIT bietet 92 Prozent Speedup gegenüber dem Interpreter), und das Typsystem reift. Die eigentliche Innovation liegt in der Infrastruktur für die nächste Dekade – ZJIT, Modular GC und die verbesserten Ractors werden Ruby für die kommenden Jahre wettbewerbsfähig halten.

(ulw)

Der beste Full-HD-Beamer für Heimkino, TV & Konsole

Die besten Tuner für DAB+ zum Nachrüsten für die Stereoanlage

Top 10: Die beste Smartwatch 2025 im Test

Smart Home: openHAB 5.1 bringt HomeKit-Integration und modernisiertes Main UI

2025-12-23T13:09:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Die Open-Source-Software openHAB kann in Version 5.1 erstmals Apple-HomeKit-Geräte direkt einbinden. Zudem wurde das Main UI grundlegend überarbeitet.

(Bild: Andrey Suslov / Shutterstock.com)

14:09 Uhr

Lesezeit: 5 Min.

Developer

Von

Matthias Parbel

Die openHAB Community hat Version 5.1 der Smart-Home-Plattform veröffentlicht. Neben der Modernisierung der Benutzeroberfläche Main UI lag der Fokus auf einem neuen HomeKit Binding für die Integration von Apple-Ökosystem-Geräten sowie umfangreichen Updates für JavaScript und Python Scripting. Insgesamt haben 124 Mitwirkende 1.967 Commits zu den GitHub-Repositories beigetragen.

HomeKit Binding öffnet Apple-Ökosystem für openHAB

Mit dem neuen HomeKit Binding können Nutzer erstmals Geräte integrieren, die bisher ausschließlich über die Apple Home App steuerbar waren. Das Binding ermöglicht laut der Ankündigung zu openHAB 5.1 ein direktes Pairing mit HomeKit-Zubehör, wobei die Steuerung vollständig lokal im Netzwerk erfolgt – ohne Cloud-Abhängigkeiten.

Zu den unterstützten Geräten zählen nach Angaben der Entwickler unter anderem Dachfenster und Jalousien von Velux sowie Thermostate und Regler von Eve Home und Tado. Da HomeKit ein etabliertes Ökosystem sei, wachse die Liste kompatibler Hardware automatisch weiter, ohne dass für jeden Hersteller ein eigenes openHAB Binding entwickelt werden müsse.

Das neue Binding ergänzt die bereits bestehende HomeKit-Integration, die openHAB-Items nach HomeKit exportiert. Somit lassen sich nun beide Richtungen abdecken: openHAB kann HomeKit-Geräte importieren und gleichzeitig eigene Geräte für Apple Home bereitstellen.

Videos by heise

Main UI erhält umfassende Modernisierung

Die Benutzeroberfläche Main UI hat eine grundlegende technische Überarbeitung erfahren. In deren Zuge hat das openHAB-Team auf Vue 3 und Framework7 v7 aktualisiert, Vuex durch Pinia ersetzt und TypeScript in der Codebase eingeführt. Die Updates und das anschließende Refectoring sollen zu spürbaren Performance-Verbesserungen beitragen – insbesondere auf älteren und leistungsschwächeren Geräten.

Die Code-Tabs für Things und Items zeigen nun dateikompatible Syntax an: YAML entspricht dem offiziellen dateibasierten Format, und eine neue DSL-Ansicht zeigt die äquivalente textuelle Darstellung. Nutzer können zwischen beiden Formaten wechseln.

Die Developer Sidebar unterstützt jetzt eine erweiterte Suchsyntax mit logischen OR- und AND-Verknüpfungen sowie exakte Phrasensuche. Neu sind außerdem Saved Pins, mit denen angeheftete Objekte im Browser persistent bleiben und so das Arbeiten an mehreren Projekten erleichtern sollen. Für Things, Items und Rules gibt es zusätzliche Filteroptionen nach Editierbarkeit, Status beziehungsweise Typ.

Event Source Tracking ermöglicht Nachverfolgung von Befehlen

Eine weitere Neuerung betrifft die Nachverfolgbarkeit von Ereignissen im System. Mit dem sogenannten Event Source Tracking können Nutzer laut openHAB nun nachvollziehen, woher ein bestimmter Befehl stammt. Das System markiert Item-Befehle und -Updates mit Quellinformationen, die auch im Event-Logging erscheinen.

Praktisch bedeutet das: Regeln können unterscheiden, ob ein Befehl von Amazon Echo, der Android-App oder einer anderen Regel gesendet wurde. Als fortgeschrittenen Anwendungsfall nennen die Entwickler die Vermeidung von Befehlsschleifen zwischen zwei Regeln, indem eine Regel prüft, ob das Ereignis von einer anderen Regel stammt, und den Befehl gegebenenfalls ignoriert. Mehr Details sowie Beispiele zum Event Source Tracking finden sich in der Developer-Dokumentation.

Homebrew Tap vereinfacht Installation auf macOS

Für macOS-Nutzer führt openHAB 5.1 einen offiziellen Homebrew Tap ein. Bisher mussten Anwender die Distribution manuell herunterladen und entpacken. Mit dem neuen Tap lässt sich openHAB über den Paketmanager Homebrew installieren, aktualisieren und als Hintergrunddienst über launchd betreiben.

Ein wesentlicher Vorteil ist die Verfügbarkeit des openHAB CLI-Tools, das bisher nur für Debian- und RPM-Pakete existierte. Über die Kommandozeile können macOS-Nutzer nun auf die openHAB-Konsole (Karaf) zugreifen, Backups erstellen und wiederherstellen sowie den Cache verwalten. Der Tap bietet Pakete sowohl für stabile als auch für Milestone-Releases.

Lesen Sie auch

Smarte Thermostate mit Home Assistant ausreizen

Sechs smarte Thermostate im Test

Mehr Komfort, niedrigere Kosten: Warum sich Smart-Home-Technik beim Heizen lohnt

Hue-Lampen mit Matter direkt in Apple Home einbindbar – aber nicht alle

Ring Doorbell Plus im Test: Mehr Cloud-Funktionen, vielleicht bald Biometrie

Der beste Full-HD-Beamer für Heimkino, TV & Konsole

Die besten Tuner für DAB+ zum Nachrüsten für die Stereoanlage

Top 10: Die beste Smartwatch 2025 im Test

TypeScript-Funktionen dekorieren: Nicht nur zu Weihnachten!

2025-12-23T07:27:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Praktische Beispiele für das Implementieren von Decorators zeigt Marco Sieben in diesem Vortragsvideo von der enterJS 2025.

(Bild: Andrey Suslov/Shutterstock.com)

08:27 Uhr

Lesezeit: 1 Min.

Developer

Von

Maika Möbus

In seinem Vortrag auf der enterJS 2025 geht Marco Sieben auf Decorators ein – einen Vorschlag, der in ECMAScript Stufe 3 erreicht hat und somit sehr gute Chancen besitzt, in einer der nächsten ECMAScript-Versionen enthalten zu sein.

Seit Version 5.0 orientiert TypeScript sich an diesem Vorschlag bei seiner Implementierung von Decorators, mit weiteren Ergänzungen und Anpassungen in späteren Releases. Dadurch können Entwicklerinnen und Entwickler Decorators bereits nutzen und bekommen einen Vorgeschmack darauf, was irgendwann nativ in JavaScript möglich sein wird.

Marco Sieben beschäftigt sich in seinem Vortrag damit, wie Decorators funktionieren und wie man sie in seinen Projekten effektiv einsetzt. In praktischen Beispielen demonstriert er, wie sich eigene Decorators implementieren lassen. Er zeigt dabei unter anderem, wie einfach man damit Logging für Funktionen oder Memoisierung umsetzen kann.

Empfohlener redaktioneller Inhalt

Mit Ihrer Zustimmung wird hier eine Vimeo-Video (Vimeo LLC) geladen.

Vimeo-Video immer laden

Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit können personenbezogene Daten an Drittplattformen (Vimeo LLC) übermittelt werden. Mehr dazu in unserer Datenschutzerklärung.

Marco Sieben wurde durch TypeScript vom Frontend-Skeptiker zum -Enthusiasten und liebt es, neue Features auszuprobieren. Bis vor Kurzem war er noch neidisch auf Python-Entwickler, die mit @functools.cache eine elegante Möglichkeit zur Memoisierung zur Verfügung haben. Seit er das mit Decorators in TypeScript genauso einfach umsetzen kann, ist die Welt wieder in Ordnung.

(mai)

Der beste Full-HD-Beamer für Heimkino, TV & Konsole

Die besten Tuner für DAB+ zum Nachrüsten für die Stereoanlage

Top 10: Die beste Smartwatch 2025 im Test

Software Testing: Weihnachtsplausch zu Software-Tests

2025-12-23T07:02:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Richard Seidl, Christian Mercier, Matthias Gross und Wolfgang Sperling sprechen über das Testerjahr 2025, KI im Alltag und Erwartungen an 2026.

Empfohlener redaktioneller Inhalt

Mit Ihrer Zustimmung wird hier ein externer Podcast (Podigee GmbH) geladen.

Podcasts immer laden

Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit können personenbezogene Daten an Drittplattformen (Podigee GmbH) übermittelt werden. Mehr dazu in unserer Datenschutzerklärung.

08:02 Uhr

Lesezeit: 2 Min.

Developer

Von

Richard Seidl
Matthias Gross
Christian Mercier
Wolfgang Sperling

In dieser Episode sprechen Richard Seidl, Christian Mercier, Matthias Gross und Wolfgang Sperling über das Testerjahr 2025, KI im Alltag und Erwartungen an 2026. Nichtfunktionale Qualität rückt nach vorn: Security, Performance, Usability, Compliance. Gefragt sind T-Shaped Skills, technisches Verständnis und Haltung: Intuition, Mut, Resilienz.

Themen im Gespräch sind auch souveräne Cloud, Druck aufs Agile und mehr Validierung in der Produktion. Die Runde betont den Wert aktiver Communitys wie Testland und fragt: Wie gelingt gemeinsames Lernen, das konkrete Probleme löst?

Empfohlener redaktioneller Inhalt

Mit Ihrer Zustimmung wird hier ein externer Podcast (Podigee GmbH) geladen.

Podcasts immer laden

Über die Gäste

Matthias Groß ist Partner von TestGilde und seit 2007 als Berater für Softwarequalitätssicherung und Testmanagement tätig. Seine Schwerpunkte liegen im operativen Testmanagement, der Einführung und Weiterentwicklung von Testmanagementstrukturen sowie der Betreuung kundenspezifischer Testservices. Er engagiert sich zudem an der Dualen Hochschule Baden-Württemberg, ist Mitgründer der Testcommunity The TestLänd und Mitglied des Programmkomitees des QS-Tags.

Christian Mercier begleitet IT-Projekte im Banking-Umfeld. In den klassischen, agilen oder hybriden Projekten nimmt er verschiedene Rollen ein – er ist Projektleiter, Coach, Testmanager, Business-Analyst oder Requirement-Engineer – aber das Thema Qualität steht für ihn immer an zentraler Stelle. Ihm geht es immer um pragmatische Lösungen, die auf fundierten Entscheidungen im jeweiligen Kontext beruhen.

Wolfgang Sperling ist Solution Architekt bei Avanade und Ansprechpartner für den Technologiestack von Microsoft im Kompetenzzentrum für digitale Souveränität bei Accenture. Seit mehr als 15 Jahren beschäftigt er sich mit Qualitätssicherung in Softwareprojekten, einen großen Anteil davon in kritischen oder herausfordernden Projektsituationen. In der Qualitätssicherung ist es ihm wichtig, neben Testen und Testautomatisierung auch Anforderungsmanagement und Releasemanagement in den Softwarelebenszyklus einzuschließen.

Bei diesem Podcast dreht sich alles um Softwarequalität: Ob Testautomatisierung, Qualität in agilen Projekten, Testdaten oder Testteams – Richard Seidl und seine Gäste schauen sich Dinge an, die mehr Qualität in die Softwareentwicklung bringen.

Videos by heise

Die aktuelle Ausgabe ist auch auf Richard Seidls Blog verfügbar: „Software-Test Weihnachtsplausch – Christian Mercier, Matthias Gross und Wolfgang Sperling“ und steht auf YouTube bereit.

(mdo)

Der beste Full-HD-Beamer für Heimkino, TV & Konsole

Die besten Tuner für DAB+ zum Nachrüsten für die Stereoanlage

Top 10: Die beste Smartwatch 2025 im Test

30 Jahre Java – Interview mit Community-Vertretern (Teil 1)

2025-12-22T10:54:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Java ist 2025 schon 30 Jahre alt. Das ist ein guter Zeitpunkt, zurück, aber auch nach vorn zu blicken.

(Bild: Erstellt mit KI (Midjourney) durch iX-Redaktion)

22.12.2025, 11:54 Uhr

Lesezeit: 16 Min.

Developer

Von

Falk Sippach

In den vergangenen 30 Jahren hat sich eine rege Community im Java-Umfeld gebildet. Ich habe im Laufe des Jahres einige deutschsprachige Vertreter zu ihren Erfahrungen befragt. Die Resonanz war überwältigend. Vielen Dank an alle, die mitgemacht haben. In diesem ersten Teil kommen Alexander Culum (Organisator JUG Frankfurt), Birgit Kratz (Co-Organisatorin der Softwerkskammern Köln und Düsseldorf sowie der SoCraTes), Simon Martinelli (Java Champion, Co-Organisator JUG Schweiz), Dierk König (Java Champion und Professor Fachhochschule Nordwestschweiz) und Christian Stein (Open Source Committer und Mitglied Java Platform Group) zu Wort.

Falk Sippach ist bei der embarc Software Consulting GmbH als Softwarearchitekt, Berater und Trainer stets auf der Suche nach dem Funken Leidenschaft, den er bei seinen Teilnehmern, Kunden und Kollegen entfachen kann. Bereits seit über 15 Jahren unterstützt er in meist agilen Softwareentwicklungsprojekten im Java-Umfeld. Als aktiver Bestandteil der Community (Mitorganisator der JUG Darmstadt) teilt er zudem sein Wissen gern in Artikeln, Blog-Beiträgen, sowie bei Vorträgen auf Konferenzen oder User Group Treffen und unterstützt bei der Organisation diverser Fachveranstaltungen. Falk twittert unter @sippsack.

Java prägt viele Entwicklerinnen und Entwickler seit ihren ersten Schritten in der IT – und hat in dieser Zeit Höhen, Tiefen und mehrere Neuerfindungen erlebt. Die folgenden Antworten spiegeln persönliche Anfänge, prägende Erlebnisse, kritische Momente und eine Einordnung von Javas Rolle in der heutigen Softwareentwicklung wider. Abschließend wagen sie einen Blick nach vorn: mit Tipps für die eigene Weiterentwicklung und Erwartungen an Java in den kommenden Jahren.

Wann und mit welcher Version bist du erstmals mit Java in Berührung gekommen?

Alexander Culum: Das war tatsächlich erst im Studium an der Uni Münster; der Professor (Achim Clausing) hatte damals (also tatsächlich schon 1997!) gerade seine komplette Grundstudiumsvorlesung von Ada auf die brandneue objektorientierte Sprache Java umgestellt, im Nachhinein zu diesem Zeitpunkt eine sehr mutige und weitblickende Entscheidung. Auch ein spannender Moment mit Professor Clausing war etwa 1999, als ich mit ihm zusammen saß und er mir Google gezeigt hat, eine neue Suchmaschine aus dem Forschungsbereich. Sie würde dank fortschrittlicher Algorithmen die damaligen Suchmaschinen (Altavista, Yahoo) ablösen. Ich habe das meinen Kommilitonen erzählt und wir haben viel gelacht. Nun ja.

(Bild: DOAG)

Vom 10. bis 12. März 2026 findet die JavaLand-Konferenz statt. Nächstes Jahr zieht die Community-Konferenz in den größten deutschen Freizeitpark, den Europa-Park Rust. Das Programm bietet knapp 130 Vorträge in 13 Themenbereichen.

Birgit Kratz: Ich habe dazu mal in meinem CV nachgeschaut. Anfang 2005 wurde dort erstmals ein Projekt erwähnt, bei dem ich mit Java entwickelt habe. Damals war gerade Java 5 herausgekommen. Aber im Projekt wurde noch Java 1.3 verwendet. Davor habe ich ziemlich viel mit C/C++ gearbeitet. Der Umstieg auf Java war für mich zwar nicht „easy peasy“, aber auch keine unüberwindbare Hürde. Nach nunmehr 20 Jahren finde ich Java immer noch spannend und lerne fast täglich neue Aspekte der Sprache kennen.

Simon Martinelli: Im Jahr 2000 bin ich während eines Nachdiplomstudiums zum ersten Mal mit Java in Berührung gekommen – damals war J2SE 1.3 gerade brandneu.

Dierk König: 1995 mit Java 1.0. Cool waren am Anfang Applets und JDBC.

Videos by heise

Christian Stein: Mich hat Java seit 1997 gepackt, das muss dann wohl laut der kompletten JDK-Matrix eine der 1.1er-Versionen gewesen sein. Ich hatte bis dahin bereits einige Erfahrungen mit Basic, Pascal, Delphi und C vor allem in der Spieleentwicklung gemacht. Und mir war bereits trotz der damaligen Langsamkeit im direkten Vergleich der Sprachen klar, dass eine virtuelle Maschine in Zukunft besser und stabiler dastehen würde.

Was war rückblickend dein schönstes Erlebnis mit der Sprache oder dem Ökosystem Java?

Alexander Culum: Da gibt es eine Menge. Es war toll zu sehen, dass Java sich immer mehr durchsetzte, auch gegen starke Konkurrenten wie C#. Das Release Java 8 fand ich toll und auch die Tatsache, dass ich die Java User Group Frankfurt 2009 gründen konnte und es immer (manchmal gerade genug) Interessenten gab, sodass die JUGF sich bis heute gehalten hat und wir eine kleine, aber sehr feine Community sind. Generell war Spring, nachdem ich es endlich verstanden hatte (und da reden wir von Jahren), auch immer mein treues, manchmal zu magisches Werkzeug, welches ich sehr zu schätzen gelernt habe. Das Java-Ökosystem wäre heute ohne Spring und die tollen Entwickler dahinter sicher ein anderes.

Birgit Kratz: Am schönsten finde ich immer die Momente, in denen es bei mir in Bezug auf neue Sprachfeatures Klick macht. Es liegt wahrscheinlich daran, dass ich aus meiner Sicht manchmal sehr langsam lerne, fast schon begriffsstutzig bin. Ich hatte das damals beim Umstieg von prozeduraler auf OO-Programmierung. Dann kam Java 5 mit Annotationen. Gefühlt habe ich ewig gebraucht zu begreifen, wozu die da sind und was man damit machen kann. Heute sind Annotationen, speziell bei der Benutzung von Frameworks wie beispielsweise Spring Boot, nicht mehr wegzudenken. Mein nächster großer Kampf war die Einführung von Lambdas und damit der Schritt zu mehr funktionaler Programmierung. Auch da hat es für mich sehr lange gedauert, das zu erfassen und dann auch gezielt einzusetzen. Aber wenn es dann Klick gemacht hat, dann ist das ein sehr schönes Gefühl.

Simon Martinelli: Es gibt unzählige schöne Erlebnisse in meiner Karriere. Eines der spannendsten Projekte mit Java war der erste Online-Ticket-Shop der SBB in den Jahren 2002/2003 – mein erstes Mal als Entwickler in einem richtig großen Team. In jüngerer Zeit denke ich oft an die vielen inspirierenden Begegnungen als Speaker auf Java-Konferenzen und JUG-Meetups. Doch das absolute Highlight war zweifellos meine Ernennung zum Java Champion im Jahr 2024.

Dierk König: Ohne Zweifel die Java Community mit Events wie der JavaOne, als sie das Moscone Center noch alleine ausfüllte, und wir zehntausende Entwickler ansprechen konnten, zum Beispiel bei der Vorstellung von Groovy.

Christian Stein: Nur ein Erlebnis? Na gut, nur ein paar wenige aus so vielen schönen: ein in Java geschriebenes Spiel (iRoll) auf den Markt zu bringen, Teil des JUnit-Teams, der Java User Group Bonn und der Java Platform Group geworden zu sein.

Aber es ist nicht alles golden, was glänzt. Was hat dich negativ beeinflusst bzw. was war ein unschöner Moment im Java-Umfeld?

Alexander Culum: Auch da gibt es eine Menge: Am Anfang bin ich gar nicht mit der Sprache warm geworden (wie gesagt, ich bin mit Java 1.0 gestartet). Schrecklich langsam, fürchterlich overengineered (ja genau: Applets und EJB 1.0!). Nach Borlands Delphi ein wahres Grausen. Dann kam der Kauf von Sun durch Oracle, was in der Community als der letzte Sargnagel wahrgenommen wurde, zu einem Zeitpunkt, als die Konkurrenten sich viel dynamischer und schneller entwickelten. Interessant, dass es vielleicht genau andersherum war. Auch der unbedingte Fokus auf Abwärtskompatibilität wurde nicht immer gut aufgenommen und häufig kritisiert. Ohne diesen Fokus wäre aber Java heute vermutlich nur eine Sprache von vielen im Unternehmensumfeld.

Birgit Kratz: Es liegt wahrscheinlich auch wieder daran, dass sich manche Sachen sehr langsam erfassen und dann aber auch schnell wieder vergessen lassen. Ein ewiger Kampf ist für mich immer das Lesen von Dateiinhalten und die Verarbeitung der darin enthaltenen Daten. Files, InputStreams, OutputStreams, Reader, Writer, … – ein großes Wirrwarr in meinem Kopf. Ähnlich ist es beim Arbeiten mit Datum und Zeit: Date, Time, Instance, Zone, Clock, Temporal, Formatter, ... – da hilft nur, jedes Mal aufs Neue, die Doku zu lesen. Leider macht es bei diesen Themen immer nur kurzzeitig Klick bei mir. Und leider schafft es dieses Wissen dann auch nie, sich in meinem Langzeitgedächtnis einzunisten

Simon Martinelli: Schon zu Beginn meiner „Java-Karriere“ hatte ich erste Berührungspunkte mit J2EE-Applikationsservern – eine durchaus spannende Erfahrung. Doch wenn ich an die langen Wartezeiten beim Serverstart zurückdenke, vermisse ich diese Zeiten ganz sicher nicht.

Dierk König: Der Untergang von Sun Microsystems war schmerzhaft.

Christian Stein: Bis heute vermisse ich den UI-Editor von Delphi! Es gab und gibt Nachahmer im Java-Umfeld, aber die reichen nicht an das Original, beziehungsweise an meine Erinnerung daran, heran. Damit verbunden stört es mich, dass das Java Development Kit seit 30 Jahren kein eigenes Build-Tool mitliefert. Zwar geben die einzelnen Tools wie javac, jar, jlink und jpackage einen normierten Ablauf vor, doch fehlt hier eine grundsätzliche Projektstruktur und eben ein Tool, das diese Struktur dann in Aufrufe der anderen Tools umsetzt. Was nicht ist, kann ja noch werden.

Glaubst du, dass Java auch nach 30 Jahren noch relevant ist? Welche Rolle spielt Java deiner Meinung nach in der modernen Softwareentwicklung, insbesondere im Vergleich zu anderen Sprachen und Technologien?

Alexander Culum: Ja, ich denke, Java wird auch in 30 Jahren noch relevant sein. Es wird, trotz unglaublich vieler toller Neuerungen, vermutlich nie die Sprache der „Early Adopter“ und Start-ups sein. Aber viele Rewrites der coolen, schicken JS-serverseitigen Anwendungen werden in Java sein. Und bei der aktuellen Entwicklung sieht man, dass Java mit Leichtigkeit Neuerungen aus anderen Sprachen adaptieren kann, wenn es will, sogar als „schwergewichtige“, statisch typisierte Programmiersprache.

Birgit Kratz: Auf jeden Fall ist Java auch nach 30 Jahren noch relevant. Sehr sogar. Ich denke, Java kommt jetzt gerade in die besten Jahre. Seit der Umstellung auf halbjährliche Releasezyklen gibt es kontinuierlich nützliche Entwicklungen, die einerseits die Sprache modern halten, andererseits aber auch sehr viel Kontinuität garantieren. Sicherlich sieht der Code, den man in Java entwickelt, heute nicht mehr so aus wie vor 30 Jahren. Und das ist auch gut so. Mal ehrlich, wer sieht heute noch so aus wie vor 30 Jahren, und – würde man das wollen? Heutzutage kann man in Java viel prägnanteren Code schreiben, der aber immer noch (oder vielmehr gerade deswegen) sehr gut lesbar ist. Natürlich gibt es andere, neuere Programmiersprachen, mit denen man Aufgaben vielleicht einfacher, kürzer oder „knackiger“ lösen kann. Oft genug sind solche Sprachen aber auch sehr spezialisiert auf die Lösung solcher Aufgaben. Java hingegen bietet ein sehr breites Fundament für die Lösung (fast) aller Probleme.

Simon Martinelli: Java ist nach wie vor äußerst relevant. In meinen aktuellen Softwaremodernisierungsprojekten erlebe ich immer wieder, dass bestehende Systeme einfach analysiert und teilweise sogar wiederverwendet werden können – ein großer Vorteil der statischen Typisierung und der einzigartigen Rückwärtskompatibilität von Java.

Dierk König: Java steht für Verlässlichkeit einer stabilen und weitverbreiteten Ausführungsumgebung.

Christian Stein: Ja, absolut relevant. Gerade weil Java als Plattform sowohl lange dabei und offen ist, weil Java „langweilig“ ist, und auch weil seit Java 9 im Jahr 2017 sich nicht nur durch zwei Releases pro Jahr neu aufgestellt hat: Innovationen erscheinen zuverlässig und planbar! „Lange dabei“: OpenJDK, große Open-Source-Szene, viele Java-User-Gruppen und Konferenzen; „langweilig“: 30 Jahre sind in der IT schon was, bezahlt die Brötchen, andere Sprachen testen Neuerungen aus – Java zieht nach; „Innovationen“: Projekte wie Loom, Valhalla, Babylon und nicht zuletzt Amber schließen Lücken zu anderen Sprachen und gehen manchmal sogar darüber hinaus.

Der beste Full-HD-Beamer für Heimkino, TV & Konsole

Die besten Tuner für DAB+ zum Nachrüsten für die Stereoanlage

Top 10: Die beste Smartwatch 2025 im Test

Die Produktwerker: Das Spannungsfeld zwischen Vertrieb und Produktentwicklung

2025-12-22T10:25:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Die Produktwerker diskutieren darüber, wie unterschiedliche Ziele und Zeithorizonte zu Spannungen zwischen Vertrieb und Produktentwicklung führen können.

Empfohlener redaktioneller Inhalt

Mit Ihrer Zustimmung wird hier ein externer Podcast (Podigee GmbH) geladen.

Podcasts immer laden

22.12.2025, 11:25 Uhr

Lesezeit: 4 Min.

Developer

Von

Dominique Winter
Tim Klein

In dieser Podcastfolge widmen sich Dominique Winter und Tim Klein dem Spannungsfeld zwischen Vertrieb und Produktentwicklung. Beide bringen zahlreiche Erfahrungen aus Organisationen mit, in denen diese beiden Bereiche eng zusammenarbeiten müssen und sich dabei dennoch häufig gegenseitig blockieren, missverstehen oder aneinander vorbeiarbeiten.

Vertrieb und Produktentwicklung verfolgen oft unterschiedliche Ziele und arbeiten in unterschiedlichen Zeithorizonten. Während der Vertrieb stark auf kurzfristige Abschlüsse, Umsatzziele und konkrete Kundenbeziehungen fokussiert ist, denkt die Produktentwicklung in der Regel langfristiger: in Visionen, Roadmaps und Wiederverwendbarkeit. Diese unterschiedliche Perspektive führt regelmäßig zu Reibung, besonders dann, wenn Zusagen gemacht werden, die nicht zur Produktstrategie passen oder wenn Produktentscheidungen den Vertriebsrealitäten zu wenig Rechnung tragen. Das Spannungsfeld entsteht dabei weniger aus bösem Willen als aus strukturellen und kulturellen Unterschieden innerhalb der Organisation.

(Bild: deagreez/123rf.com)

Fachvorträge und Networking-Möglichkeiten: Die Product Owner Days am 5. und 6. Mai 2026 in Köln befassen sich in über 20 Vorträgen mit aktuellen Themen rund um Product Ownership, KI im Produktmanagement, User Research, Product Discovery und Product Economics.

Verkaufsstrategie versus Anwendernutzen

Der Vertrieb und das Produktteam haben unterschiedlichen Zugang zu Kunden und Nutzenden. Vertrieb ist nah an den Einkaufsorganisationen und ihren Entscheidern, Produktentwicklung ist näher an den tatsächlichen Anwenderinnen und Anwendern. Gerade im B2B-Umfeld führt diese Trennung dazu, dass wertvolle Informationen nicht zusammenfließen. Der Vertrieb hört Marktargumente, Wettbewerbsvergleiche und Kaufhindernisse. Die Produktentwicklung sieht Nutzungsprobleme, fehlende Wirksamkeit und Schwächen im Erlebnis. Wenn diese Perspektiven getrennt bleiben, entstehen Situationen, in denen sich weder verkaufen lässt noch nachhaltig und strategisch Produkte entwickelt werden können.

Empfohlener redaktioneller Inhalt

Mit Ihrer Zustimmung wird hier ein externer Podcast (Podigee GmbH) geladen.

Podcasts immer laden

Besonders deutlich wird das Spannungsfeld zwischen Vertrieb und Produktentwicklung bei kundenspezifischen Zusagen. Kurzfristige Deals können dazu führen, dass Features versprochen werden, die nicht zur langfristigen Ausrichtung passen. Dadurch entstehen Einzelfalllösungen, die Entwicklungsressourcen binden und selten echten Produktwert erzeugen. Gleichzeitig ist es zu einfach, diese Situation allein dem Vertrieb zuzuschreiben. Verkaufsziele, Incentives und Zeitdruck erzeugen ein Umfeld, in dem solche Entscheidungen logisch erscheinen. Die Produktentwicklung steht hier vor der Aufgabe, Orientierung zu geben und klarzumachen, wofür das Produkt langfristig stehen soll.

Umgekehrt darf die Produktentwicklung nicht erwarten, dass der Vertrieb die Produktstrategie automatisch versteht oder unterstützt. Wenn Vision, Zielgruppen und strategische Leitplanken nicht klar kommuniziert werden, entsteht Raum für Interpretationen. Der Vertrieb füllt diese Lücke dann mit eigenen Prioritäten. Das Spannungsfeld zwischen Vertrieb und Produktentwicklung verschärft sich dadurch weiter, obwohl beide Seiten eigentlich am gleichen Erfolg interessiert sind beziehungsweise sein sollten.

Videos by heise

Und gerade in dieser Zusammenarbeit steckt enormes Potenzial (oder wird eben verschenkt). Der Vertrieb liefert wertvolle Einblicke in Marktveränderungen, Wettbewerber und Kaufmotive. Die Produktentwicklung kann diese Impulse nutzen, um bessere Entscheidungen zu treffen und Risiken frühzeitig zu erkennen. Wenn der Vertrieb regelmäßig Einblick in Produktentwicklungen bekommt, neue Funktionen versteht und deren Nutzen einordnen kann, steigt die Qualität der Gespräche mit Kunden deutlich. Beide Seiten gewinnen an Sicherheit und Wirksamkeit.

Zusammenarbeit bewusst gestalten und Vertrauen schaffen

Voraussetzung dafür ist eine bewusste Gestaltung der Zusammenarbeit. Regelmäßiger Austausch, gemeinsame Termine und echte Beziehungspflege schaffen Vertrauen. Es geht darum, die Perspektive des jeweils anderen zu verstehen und ernst zu nehmen. Produktentwicklung profitiert davon, Verkaufsrealitäten kennenzulernen. Vertrieb profitiert davon, die Komplexität von Produktentscheidungen zu verstehen. Diese Nähe reduziert Missverständnisse und verhindert Eskalationen, bevor sie entstehen.

Wenn Vertrieb und Produktentwicklung zumindest teilweise an denselben Kennzahlen gemessen werden, verändert sich das Verhalten spürbar. Kundenzufriedenheit, Nutzung oder langfristiger Erfolg rücken dann stärker in den Fokus. Das Spannungsfeld zwischen Vertrieb und Produktentwicklung verliert an Schärfe, weil beide Seiten auf ein gemeinsames Ergebnis hinarbeiten.

Konflikte zwischen Vertrieb und Produktentwicklung sind kein Zeichen von Dysfunktion, sondern Ausdruck unterschiedlicher Verantwortungen. Entscheidend ist, wie Organisationen damit umgehen. Wer den Dialog fördert, Transparenz schafft und gemeinsame Verantwortung ermöglicht, verwandelt Spannung in produktive Energie und schafft die Grundlage für nachhaltigen Produkterfolg.

Auf diese früheren Episoden wird im Gespräch verwiesen:

Wardley Mapping – Produktstrategie wie ein Schachspiel
Technische Schulden und wie wir als Product Owner damit umgehen
Stakeholder Community
Produktmanager in einem Start-up – Erfahrungsbericht eines Buchhalters
(eine von Tims absoluten Lieblingsfolgen)

Die aktuelle Ausgabe des Podcasts steht auch im Blog der Produktwerker bereit: „Das Spannungsfeld zwischen Vertrieb und Produktentwicklung“.

(map)

Der beste Full-HD-Beamer für Heimkino, TV & Konsole

Die besten Tuner für DAB+ zum Nachrüsten für die Stereoanlage

Top 10: Die beste Smartwatch 2025 im Test

Developer-Häppchen fürs Wochenende – Kleinere News der Woche

2025-12-20T08:23:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Kleine, aber interessante Meldungshäppchen vom News-Buffet zu GitHub, Kubernetes, TypeScript, Kotlin, State of HTML, Delphi, Next.js, GitLab und LangGrant.

(Bild: Natalia Klenova/Shutterstock)

20.12.2025, 09:23 Uhr

Lesezeit: 3 Min.

Developer

Von

Die beliebten Developer-Snapshots haben wir neu in leckere Häppchen verpackt. Inhaltlich bleibt alles beim Alten – ein kleiner Überblick über alles, was es zwar nicht in die News geschafft hat, wir aber dennoch für spannend halten:

Die Cloud Native Computing Foundation (CNCF) wirft einen Blick zurück und einen nach vorne: Kubernetes hat in diesem Jahr einige stabile Features hinzugewonnen, darunter Sidecar Containers in Version 1.33 und das Beschränken anonymer Anfragen auf spezifische Endpunkte in Version 1.34. Im kommenden Jahr sollen unter anderem User-Namespaces für HostNetwork-Pods, robuste Image-Pull-Autorisierung und Pod-Zertifikate für mTLS hinzukommen.
Microsoft hat verkündet, dass die C++-Code-Editierungswerkzeuge für GitHub Copilot nun als öffentliche Preview vorliegen. Sie sind in der neuesten Insider-Version von Visual Studio 2026 verfügbar und bieten dem KI-Copiloten neue Möglichkeiten wie das Visualisieren von Klassenvererbungshierarchien oder das Verstehen von Metadaten wie Typ, Deklaration und Scope.
Der State of HTML Report für 2025 ist erschienen und legt dieses Jahr einen Schwerpunkt auf die frei geschriebenen Antworten der Teilnehmerinnen und Teilnehmer, die sie „bei bestimmten Problembereichen“ abgegeben haben.
Für TypeScript veröffentlicht Google ein Agent Development Kit, mit dem Entwicklerinnen und Entwickler Agenten in TypeScript entwerfen und orchestrieren. Darüber hinaus bietet es Tools für Debugging, Testing und Deployment im Ökosystem von Google.

(Bild: avdyachenko/Shutterstock)

Call for Proposals: Die Veranstalter der heise-Konferenz betterCode() API suchen wieder Expertinnen und Experten, die technische Know-how-Vorträge, Berichte aus der Praxis oder auch eintägige Workshops abhalten möchten. Die Online-Konferenz findet am 12. Mai 2026 statt und schon jetzt gibt es günstige Blind-Bird-Tickets.

Kotlin 2.3 unterstützt nun Java 25 in der JVM, ist kompatibel zu Gradle 9, bietet einen Swift-Export, verbessert das Parsen von UUIDs und prüft den Code auf ungenutzte Returns.
Embarcadero hat Delphi 13 und das zugehörige RAD Studio mit C++-Builder angekündigt. Dieser basiert auf Clang 20 und unterstützt C++ 23. Für Delphi gibt es einen kurzen Ternary Operator mit if … then …. Außerdem vervollständigt das RAD Studio die Unterstützung von Windows 64bit als Compiler-Ziel.

Lesen Sie auch

Verbindungsabbrüche bei heise online durch Cookies – eine Spurensuche

Der beste Full-HD-Beamer für Heimkino, TV & Konsole

Die besten Tuner für DAB+ zum Nachrüsten für die Stereoanlage

Top 10: Die beste Smartwatch 2025 im Test

Top 10: Die zehn meist gelesenen Developer-Artikel im Jahr 2025

2025-12-20T08:01:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Die meistgelesenen Fachartikel des Jahres umfassen eine große Spannbreite an Themen, darunter Beiträge zu KI, Entwurfsmustern, RCS, Architektur und Angular.

(Bild: chainarong06/Shutterstock.com)

20.12.2025, 09:01 Uhr

Lesezeit: 8 Min.

Developer

Von

Madeleine Domogalla

Das Jahr 2025 neigt sich allmählich dem Ende zu. Daher ist es an der Zeit, dass wir als Redaktion die beliebtesten Artikel des Jahres auf heise developer in einem Beitrag zusammenfassen. Dieses Jahr findet sich in den Top 10 eine bunte Mischung von Angular Signals, KI-Agenten, Tools und Entwurfsmuster.

Die Liste klammert bewusst die News aus. Die Top-Themen des Jahres in den Meldungen auf heise Developer erscheinen in den kommenden Tagen in einem separaten Beitrag.

Die regelmäßigen Blogbeiträge haben wir ebenfalls nicht in die Aufzählung aufgenommen. Bei den Blogs haben vor allem die Themen rund um die Verwendung bestimmter Programmiersprachen, Softwareentwicklung und den Arbeitsalltag als Softwarearchitekt das Interesse geweckt. Allen voran „Wie niedlich: Du programmierst ernsthaft in dieser Programmiersprache?“, „Ein Tag im Leben eines Softwarearchitekten – Überleben im Unternehmensdschungel“ und „Warum objektive Schätzungen in der Softwareentwicklung nicht funktionieren“.

Platz 10: Angular Signals: Elegante Reaktivität als Architekturfalle

(Bild: KI/iX)

Auf Platz 10 der meistgelesenen heise-Developer-Artikel 2025 steht Nicolai Wolkos Analyse von Angular Signals. Er gibt an, dass die mit Angular 17 eingeführten Signals im UI zwar elegante Reaktivität ermöglichen, in der Applikationslogik aber zur Architekturfalle werden können. Grund ist, dass effect() unkoordiniert auf jede Mutation reagiert, implizite Kopplungen erzeugt und asynchrone Abläufe schwer kontrollierbar macht. Wolko empfiehlt daher, Signals auf UI-nahe Zustände und nebenwirkungsfreie Ableitungen zu beschränken und komplexe Geschäftslogik klar getrennt und architektonisch sauber zu modellieren.

Platz 9: CodeCharta: Software-Qualität sichtbar machen durch Stadtvisualisierung

(Bild: dibrova/Shutterstock.com)

Andreas Blunk erläutert, wie das Open-Source-Tool CodeCharta Softwarequalität sichtbar macht, indem es Codebasen als Stadtlandschaften visualisiert. Dateien werden zu Gebäuden, deren Grundfläche Codezeilen, deren Höhe Komplexität und deren Farbe die Testabdeckung repräsentieren. Am Beispiel eines Sanierungsprojekts der Deutschen Bahn wird sichtbar, wie sich wenige hohe, rote Blöcke schrittweise in eine fein granulare, überwiegend grüne Stadt mit geringerer Komplexität verwandeln – inklusive markierter „Wolkenkratzer“ als verbleibende technische Schulden.

Videos by heise

Platz 8: Warum viele Teams mit Monolithen besser fahren als mit Micro-Frontends

(Bild: Daniel Prudek / Shutterstock)

Nicolai Wolko belegt auch Platz 8 des Rankings und macht deutlich, warum der Hype um Micro-Frontends abflaut und viele kleinere Teams mit modularen Monolithen besser fahren. Er plädiert mit Umfragedaten, Praxisberichten und Code-Audits für Einfachheit und warnt davor, ohne echte Gründe überall Micro-Architekturen einzuführen, weil sonst nur ein „verteilter Monolith“ mit hohem Infrastrukturballast entsteht. Als pragmatischen Standard empfiehlt er den Modulith mit klar getrennten Modulen, gemeinsamem Deployment, guter Performance und niedrigeren Betriebskosten.

Platz 7: GPT-5 im Vergleich: Softwareentwicklung sehr gut, Kreativität nur ausreichend

(Bild: Besjunior/Shutterstock.com)

Christian Winkler zeichnet GPT‑5 als leistungsfähiges, aber weitgehend intransparentes Routing-Modell, das je nach Anfrage ein Reasoning-Modell zuschaltet, Wissens- und Programmieraufgaben meist souverän löst, in Einzelfällen aber weiterhin logische und Rechenfehler produziert. Er ordnet erste Praxiserfahrungen und Community-Stimmen ein. Viele loben die deutlich verbesserten Fähigkeiten in der Softwareentwicklung und vermuten spezialisierte Coding-Modelle im Hintergrund, kritisieren aber gleichzeitig eine im Vergleich zu GPT‑4 spürbar geringere Kreativität, was teils auf das Routing zu einfacheren Submodellen zurückzuführen sein dürfte.

Platz 6: KI-Agenten, Teil 1: Revolution in der digitalen Produktentwicklung

(Bild: maxuser/Shutterstock.com)

Platz 6 belegt der erste Teil der Artikelreihe zu KI-Agenten von Thomas Immich. Er skizziert KI-Agenten als nächste Evolutionsstufe der Softwareentwicklung: Statt dass Menschen Code per Prompt erzeugen und integrieren, planen und programmieren autonome Agenten mit Gedächtnis und Zielen selbstständig und committen wie Entwickler.

Vor diesem Hintergrund – befeuert durch Aussagen von Tech-CEOs, die das Ende des Mid-Level Engineers prognostizieren – fordert der Artikel, klassische Prozesse und Rollen in der digitalen Produktentwicklung neu zu denken. Ferner zeigt er mit Multi-Agenten-Frameworks, wie ganze virtuelle Produktteams aus spezialisierten KI-Rollen gemeinsam Software konzipieren und umsetzen.

Der beste Full-HD-Beamer für Heimkino, TV & Konsole

Die besten Tuner für DAB+ zum Nachrüsten für die Stereoanlage

Top 10: Die beste Smartwatch 2025 im Test

Von den Grenzen großer Sprachmodelle und der Unerreichbarkeit von AGI und ASI

2025-12-19T13:30:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Große Sprachmodelle (LLMs) liefern beeindruckende Ergebnisse, aber sind sie wirklich in der Lage, menschliche Intelligenz zu erreichen oder zu übertreffen?

Das Zufügen menschlicher Fähigkeiten zu LLMs

(Bild: Erstellt vom Autor mit KI)

19.12.2025, 14:30 Uhr

Lesezeit: 22 Min.

Developer

Von

Dr. Michael Stal

Die rasante Entwicklung großer Sprachmodelle hat eine intensive Debatte über ihr Potenzial ausgelöst, künstliche allgemeine Intelligenz und letztlich künstliche Superintelligenz zu erreichen.

Prof. Dr. Michael Stal arbeitet seit 1991 bei Siemens Technology. Seine Forschungsschwerpunkte umfassen Softwarearchitekturen für große komplexe Systeme (Verteilte Systeme, Cloud Computing, IIoT), Eingebettte Systeme und Künstliche Intelligenz. Er berät Geschäftsbereiche in Softwarearchitekturfragen und ist für die Architekturausbildung der Senior-Software-Architekten bei Siemens verantwortlich.

Obwohl diese Systeme bemerkenswerte Fähigkeiten in den Bereichen Sprachverarbeitung, Schlussfolgerungen und Wissenssynthese aufweisen, deuten grundlegende architektonische und theoretische Einschränkungen darauf hin, dass sie die Lücke zu echter allgemeiner Intelligenz nicht schließen können. Diese Analyse untersucht die zentralen technischen Hindernisse, die aktuelle LLM-Paradigmen daran hindern, AGI oder ASI zu erreichen.

Das Ziel verstehen: Definitionen von AGI und ASI

Künstliche allgemeine Intelligenz (AGI – Artificial General Intelligence) ist eine hypothetische Form der künstlichen Intelligenz, die die kognitiven Fähigkeiten des Menschen in allen Bereichen des Wissens und der Schlussfolgerungen erreicht oder übertrifft. Im Gegensatz zu schmalen KI-Systemen, die für bestimmte Aufgaben entwickelt wurden, würde AGI eine flexible Intelligenz aufweisen, die in der Lage ist, Wissen in jedem Bereich mit der gleichen Leichtigkeit wie die menschliche Intelligenz zu lernen, zu verstehen und anzuwenden. Zu den Hauptmerkmalen von AGI gehören autonomes Lernen anhand minimaler Beispiele, Wissenstransfer zwischen unterschiedlichen Bereichen, kreative Problemlösung in neuartigen Situationen und die Fähigkeit, abstrakte Konzepte mit echtem Verständnis und nicht nur durch Mustererkennung zu verstehen und zu manipulieren.

(Bild: Bridgman/Adobe Stock)

Am 22. und 23. April 2026 findet die Minds Mastering Machines in Karlsruhe statt. Im Mittelpunkt der Konferenz stehen Vorträge zu praxisnahen Themen von klassischem Machine Learning bis zu LLMs und Agentic AI.

Künstliche Superintelligenz (ASI – Artificial Superintelligence) geht über AGI hinaus und steht für eine Intelligenz, die die kognitiven Fähigkeiten des Menschen in allen Bereichen, einschließlich Kreativität, allgemeiner Weisheit und Problemlösung, bei weitem übertrifft. ASI würde die menschliche Intelligenz nicht nur erreichen, sondern um ein Vielfaches übertreffen und möglicherweise Erkenntnisse und Fähigkeiten erreichen, die für den Menschen unvorstellbar sind. Die Unterscheidung zwischen AGI und ASI ist entscheidend, da AGI eine allgemeine Intelligenz auf menschlichem Niveau darstellt, während ASI eine grundlegend andere Kategorie von Intelligenz impliziert.

Große Sprachmodelle sind in ihrer derzeitigen Form statistische Systeme, die auf der Grundlage umfangreicher Textkorpora trainiert werden, um das wahrscheinlichste nächste Token in einer Sequenz vorherzusagen. Diese Modelle lernen, Muster aus ihren Trainingsdaten zu komprimieren und zu reproduzieren, wodurch sie in der Lage sind, kohärente und kontextuell angemessene Antworten zu generieren. Ihre Funktionsweise unterscheidet sich jedoch grundlegend von der flexiblen, adaptiven Intelligenz, die AGI auszeichnet.

Videos by heise

Architektonische Einschränkungen von Transformer-basierten Systemen

Die Transformer-Architektur, die den meisten aktuellen LLMs zugrunde liegt, bringt mehrere grundlegende Einschränkungen mit sich, die ihr Potenzial für allgemeine Intelligenz begrenzen. Der Aufmerksamkeitsmechanismus ist zwar leistungsstark für die Verarbeitung von Sequenzen, arbeitet jedoch mit festen Gewichtungsmatrizen, die während des Trainings gelernt wurden. Diese Gewichte kodieren statistische Beziehungen zwischen Token, können sich jedoch ohne erneutes Training nicht dynamisch an völlig neue Konzepte oder Domänen anpassen. Diese statische Natur steht in starkem Kontrast zur biologischen Intelligenz, die ihre neuronalen Verbindungen auf der Grundlage neuer Erfahrungen kontinuierlich anpasst.

Die Feedforward-Verarbeitung von Transformatoren schafft eine weitere bedeutende Einschränkung. Informationen fließen in einer Richtung durch die Netzwerkschichten, wodurch die für die menschliche Kognition charakteristische iterative, zyklische Verarbeitung verhindert wird. Das menschliche Denken beinhaltet kontinuierliche Rückkopplungsschleifen, in denen Konzepte höherer Ebene die Verarbeitung auf niedrigerer Ebene beeinflussen und umgekehrt. Dieser bidirektionale Fluss ermöglicht es dem Menschen, sein Verständnis durch Reflexion und Neukonzeption zu verfeinern – Fähigkeiten, die in aktuellen LLM-Architekturen noch fehlen.

Darüber hinaus führt der diskrete Tokenisierungsprozess, der die kontinuierliche menschliche Sprache in diskrete Token umwandelt, zu Informationsverlusten und schränkt die Fähigkeit des Modells ein, subtile Nuancen und kontextabhängige Bedeutungen zu verstehen. Die Verarbeitung der menschlichen Sprache erfolgt gleichzeitig auf mehreren Ebenen, von der phonetischen und morphologischen bis zur semantischen und pragmatischen Ebene, mit einer kontinuierlichen Integration über diese Ebenen hinweg. Der Engpass der Tokenisierung hindert LLMs daran, auf dieses gesamte Spektrum der Sprachverarbeitung zuzugreifen.

Die Einschränkung des Trainingsparadigmas

Das Ziel der Vorhersage des nächsten Tokens, das das LLM-Training antreibt, schafft grundlegende Einschränkungen in der Art und Weise, wie diese Systeme Informationen verstehen und verarbeiten. Dieses Trainingsparadigma optimiert eher die statistische Korrelation als das kausale Verständnis, was zu einem ausgeklügelten Musterabgleich statt zu echtem Verständnis führt. Dieser Ansatz ermöglicht zwar beeindruckende Leistungen bei vielen Sprachaufgaben, versäumt es jedoch, die für allgemeine Intelligenz wesentlichen Fähigkeiten des kausalen Denkens und der Weltmodellierung zu entwickeln.

Der im LLM-Training verwendete Ansatz des überwachten Lernens stützt sich auf statische Datensätze, die eine Momentaufnahme des menschlichen Wissens zu einem bestimmten Zeitpunkt darstellen. Dies steht im Gegensatz zum menschlichen Lernen, das aktive Erkundung, Hypothesenbildung und -prüfung sowie die kontinuierliche Integration neuer Erfahrungen in das vorhandene Wissen umfasst. Menschen entwickeln Verständnis durch Interaktion mit ihrer Umgebung und bilden und verfeinern mentale Modelle auf der Grundlage von Rückmeldungen aus ihren Handlungen. LLMs fehlt diese interaktive Lernfähigkeit, und sie können kein echtes Verständnis durch Erfahrungslernen entwickeln.

Die Skalierungshypothese, die besagt, dass größere Modelle, deren Training mit immer mehr Daten erfolgt, letztendlich AGI erreichen, steht vor mehreren theoretischen Herausforderungen. Die einfache Vergrößerung des Modells und des Datensatzes berücksichtigt zwar die Quantität, aber nicht die qualitativen Unterschiede zwischen Mustererkennung und Verständnis. Das Entstehen neuer Fähigkeiten in größeren Modellen spiegelt oft eher eine ausgefeiltere Mustererkennung wider als grundlegende Veränderungen in der Form von Intelligenz. Ohne die zugrunde liegenden architektonischen und trainingsbezogenen Einschränkungen zu beseitigen, kann die Skalierung allein die Lücke zwischen statistischer Verarbeitung und echter Intelligenz nicht schließen.

Der beste Full-HD-Beamer für Heimkino, TV & Konsole

Die besten Tuner für DAB+ zum Nachrüsten für die Stereoanlage

Top 10: Die beste Smartwatch 2025 im Test

Innovativ und fast vollständig Open-Source: Nvidia Nemotron 3 Nano

2025-12-19T08:30:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Zuletzt kamen die erfolgreichen, transparenteren KI-Sprachmodelle von chinesischen Entwicklern. Mit Nemotron 3 Nano legt Nvidia jetzt nach.

(Bild: gguy/Shutterstock.com)

19.12.2025, 09:30 Uhr

Lesezeit: 12 Min.

iX Magazin

Von

Dr. Christian Winkler

Kurz vor Weihnachten gab es für die LLM-Community eine unerwartete Überraschung: Nvidia veröffentlichte ein neues Modell mit dem Namen Nvidia-Nemotron-3-Nano-30B-A3B. Schon etwas früher war die Reddit-Community informiert, weil ein aufmerksamer Leser entdeckt hatte, dass ein weniger aufmerksamer Mitarbeiter von Nvidia versehentlich ein übergeordnetes Verzeichnis zu Hugging Face gepusht hatte. In dem am 15. Dezember 2025 veröffentlichten Nvidia-Modell stecken jede Menge neue Ideen, sodass sich ein genauerer Blick lohnt – auch weil es sich nur um das erste Modell aus einer ganzen Familie handelt.

Prof. Dr. Christian Winkler beschäftigt sich speziell mit der automatisierten Analyse natürlichsprachiger Texte (NLP). Als Professor an der TH Nürnberg konzentriert er sich bei seiner Forschung auf die Optimierung der User Experience.

Überblick über die Architektur

Bisher waren die Nemotron-Modelle häufig Finetunes anderer Modelle wie Llama 3.1. Das hätte man aufgrund der ähnlichen Parameteranzahl eines Qwen3-Modells auch bei Nemotron 3 vermuten können. Bei Nemotron 3 hat Nvidia die Modelle von Grund auf neu trainiert und sich dafür eine neue Architektur ausgedacht. Die bisherigen Mixture-of-Experts-Layer (MoE) verwendet Nvidia dabei abwechselnd mit Mamba-Layern, die im strengen Sinne keine Transformer-Architektur nutzen. Der Vorteil ist eine deutlich höhere Ausführungsgeschwindigkeit und ein geringerer Speicherverbrauch, weil der Key-Value-Cache, der sich den Kontext merkt, in den Mamba-Layern nicht mit der Kontextlänge wächst. Vermutlich genau aus diesem Grund konnte Nvidia die Kontextlänge auf eine Million Token erhöhen. Das Modell eignet sich somit für sehr lange Dokumente.

Obwohl das Modell „Nano“ im Namen trägt, ist es nicht wirklich klein, sondern hat 31,6 Milliarden Parameter, von denen es bei jeder Token-Vorhersage 3,6 Milliarden verwendet. Das macht das Modell schnell, dazu tragen außerdem die leichter zu berechnenden Mamba-Layer bei. Nvidia spricht von einem Faktor 3,3 gegenüber vergleichbaren Modellen. Solche Zahlen lassen sich nicht einfach verifizieren, was ebenfalls für die von Nvidia genannte beste Genauigkeit für Reasoning, Coding, Benutzung von Tools und mehrstufigen Agenten-Aufgaben gilt. Hier muss sich das Modell erst noch in der Praxis beweisen.

Im Vergleich mit den Konkurrenten Qwen3-30B-A3B-Thinking-2507 und GPT-OSS-20B-A4B schneidet Nemotron 3 Nano in Nvidias Benchmarks sehr gut ab.

(Bild: Nvidia)

Direkt überprüfbar sind dagegen die Möglichkeiten, das Reasoning ein- und auszuschalten oder darüber die Anzahl der generierten Token zu begrenzen. Das ist besonders für agentische Aufgaben wichtig, weil sonst dort unkontrollierbar hohe Kosten entstehen können.

Nemotron Nano besteht aus 52 Layern mit einer Modelldimension von 2.688 und setzt auf 32 Attention-Heads. Die Mamba-Layern haben 128 Zustandsdimensionen in acht Gruppen, mit jeweils 64 Mamba-Heads in 64 Head-Dimensionen. Insgesamt gibt es 128 Experten, von denen zwei als Shared Experts arbeiten; weiterhin aktiviert das Modell sechs zusätzliche Experten. Da die Experten nur 1.856 Dimensionen haben, erklärt sich so die Anzahl der aktiven Parameter von 3,6 Milliarden. Abgesehen von den Mamba-Layern nutzen andere Modelle ähnliche MoE-Architekturen.

Videos by heise

Trainingsdaten fast vollständig veröffentlicht

Was das Nemotron-Modell allerdings wirklich gegenüber fast allen anderen Modellen auszeichnet, sind die Trainingsdaten. Nahezu alle hat Nvidia veröffentlicht, genau wie auch die im Training verwendeten Algorithmen. Das haben bisher neben den Olmo- und Apertus-Modellen nur wenige Anbieter geleistet. Die Daten finden sich als Pre- und Post-Trainings-Datensatz auf Hugging Face.

Manche der Daten scheinen aus der Zukunft zu stammen und tragen ein Änderungsdatum von 20. Dezember 2025, ein offensichtlicher Fehler. Unabhängig davon reichen die Daten bis zum Juni 2025. Fragen nach dem Wissensstand beantwortet das Modell allerdings mit Juni 2024 – auch eine Inkonsistenz. Insgesamt stehen 10 Billionen Tokens zum Download in den Datensets zur Verfügung. Das lässt sich kaum mit bezahlbarer Hardware trainieren (oder feintunen), dennoch ist es sehr spannend, einen Blick in die Datensets zu werfen oder zumindest Teile davon zu verwenden. In jedem Fall werden die Modelle dadurch deutlich transparenter. Das Nano-Modell steht unter der Nvidia-Open-Model-Lizenz, damit ist auch die kommerzielle Nutzung und Veränderung gestattet.

Laut dem Artificial-Analysis-Index, der Offenheit und Intelligenz von Modellen erfassen will, kann Nemotron 3 Nano in beiden Kategorien gute Werte erzielen.

(Bild: https://blog.vllm.ai/2025/12/15/run-nvidia-nemotron-3-nano.html)

Deutlich mehr Informationen finden sich in Nvidias Blog-Artikel bei Hugging Face, im Nvidia-Blog, einem zugehörigen Whitepaper oder im technischen Bericht. Ein GitHub-Projekt enthält Cookbooks, die zeigen, wie man das Modell mit Frameworks wie SGLang oder vLLM verwendet.

Pre-Training

Unter dem Pre- oder Base-Training versteht man den Teil, in dem das Modell mit sehr großen Datenmengen trainiert wird, um den jeweils nächsten Token vorherzusagen. Üblicherweise verbraucht das Pre-Training bei weitem am meisten Rechenkapazität, auch wenn sich das bei einigen Anbietern (wie Qwen) gerade ändert.

Für das Pre-Traning nutzt Nvidia den Warmup-Stable-Decay als Scheduler und trainiert das Modell mit 25 Billionen Token in 15 unterschiedlichen Kategorien. Dieses Pre-Training haben die Entwickler noch in zwei Phasen unterteilt, die erste Phase nutzt 23,5 Billionen Token aus relativ einfachen Texten, in einer zweiten Phase folgen 1,5 Billionen Token mit deutlich höherer Qualität.

Die größte der 15 Komponenten sind Daten aus dem Web Crawling (Common Crawl), die in fünf Teilbereiche mit verschiedenen Qualitätsstufen zerfallen (crawl-medium, crawl-medium-high, syn-crawl-medium-high, crawl-high, syn-crawl-high). Neben den Crawling-Daten enthält der Mix auch mathematische Daten, weitere aus Wikipedia, speziellen Programmcode und verschiedene andere.

Im Pre-Training verwendet Nvidia auch synthetische Daten, die normalerweise für das Supervised Finetuning Verwendung finden. Unter Crawl++ versteht Nvidia Daten, die aus OpenWebText, BigScience und Reddit kommen. Das Pre-Training erfolgt in 19 Sprachen: Arabisch, Chinesisch (vermutlich Mandarin), Tschechisch, Dänisch, Flämisch, Finnisch, Französisch, Deutsch, Hebräisch, Hindi, Italienisch, Japanisch, Koreanisch, Portugiesisch, Polnisch, Russisch, Spanisch, Schwedisch und Thai. Daten mit höherer Qualität erhalten von Nvidia ein höheres Gewicht im Training; der technische Bericht schweigt sich aber darüber aus, wie die Qualität bestimmt wird.

In den unterschiedlichen Phasen arbeitet Nvidia mit verschieden langen Kontexten. RoPE (Rotational Position Embeddings zur Vergrößerung des Kontexts) benutzt Nvidia dabei wegen der Mamba-Layer zwar nicht, aber mit den höherwertigen Inhalten wird der Kontext auf bis zu 512K Token erhöht. Nemotron-3-Nano trainiert Nvidia in bfloat16, für die größeren Varianten, die noch nicht erschienen sind, kommt das viel kompaktere NVFP4 zum Einsatz. Nvidia behauptet, damit keine großen Quantisierungsfehler zu machen. Nvidia hat auch die nach dem Pre-Training entstandenen Basis-Modelle veröffentlicht, die noch nicht feingetunt sind.

Post-Training

Das Post-Training unterteilt Nvidia in drei Phasen, ein Supervised Finetuning (SFT), ein Reinforcement Learning with Verifiable Rewards (RLVR) für unterschiedliche Umgebungen und schließlich ein Reinforcement Learning with Human Feedback (RLHF).

In der SFT-Phase nutzt Nvidia eine Kontextlänge von 256k Token und Trainingsdaten aus Chats, Dialogen mit Agenten und Reasoning. Letzteres soll dabei helfen, dem Modell ein Limit für das Reasoning anzutrainieren oder es ganz auszuschalten, damit es nicht zu viele Token und damit Kosten erzeugt. Das Modell lernt an dieser Stelle, Reasoning mit Tools durchzuführen. Die Daten hat Nvidia in unterschiedliche Bereiche getrennt: mathematische Probleme mit formalen Beweisen, Programmcode, wissenschaftliche und Softwarethemen sowie verschiedene Sprachen. Auch die Sicherheit berücksichtigt Nvidia hier, damit das Modell seine Grenzen nicht überschreitet. Sehr spezifisch für Nvidia sind die CUDA-Trainingsdaten, Nemotron beherrscht also auch diese Programmiersprache.

Beim RLVR trainiert Nvidia mit Daten in ganz ähnlichen Bereichen parallel. Der Fokus liegt hier auf verifizierbaren Ergebnissen, Programme müssen etwa Unit-Tests durchlaufen. Nvidia erklärt leider nicht, ob es ähnlich wie DeepSeek V3.2 auch die einzelnen Prozessschritte verifiziert, möglicherweise ist das noch eine Optimierung, die zu einem späteren Zeitpunkt eingesetzt werden kann. Der Kontext ist bei RLVR mit 256k Token etwas kleiner als beim SFT.

Neue Ideen bringt Nvidia beim RLHF ein und nutzt ein generatives Belohnungsmodell (GenRM), interessanterweise ein großes Qwen3-Modell (Qwen3-235B-A22B-Thinking-2507). Das Qwen3-Modell wird zunächst feingetunt: Im Trainingsprozess bewertet es mit seinen Reasoning-Fähigkeiten zwei Antworten danach, wie hilfreich sie sind. Die Korrektheit überprüft Nvidia anhand eines synthetischen Datensatzes und dem HelpSteer3-Datenset. Sobald GenRM trainiert ist, kommt es im eigentlichen Reinforcement Learning zum Einsatz und bewertet 16 mögliche Antworten von Nemotron. Um nicht alle 120 möglichen Kombinationen zu bewerten, vergleicht GenRM jeweils nur eine Antwort mit der jeweils nächsten (und die letzte mit der ersten), was zu 16 Bewertungen führt. Das Human Feedback hat Nvidia hier also durch das GenRM-Feedback ersetzt und kann damit sehr viel besser skalieren – an der notwendigen Hardware wird es kaum mangeln. Es ist fast schon erstaunlich, dass Nvidia nicht alle 120 Vergleiche durchführt.

Am Ende quantisiert Nvidia das bfloat16 Modell noch auf FP8 und zeigt, dass damit fast keine Qualität verloren geht. Vermutlich hat man das auch mit NVFP4 probiert und dabei schlechtere Ergebnisse erzielt und daher die größeren Modelle gleich in diesem Datenformat trainiert.

Ausprobieren

Sowohl vllm als auch SGLang unterstützen das neue Nemotron-Modell bereits. Aber auch mit llama.cpp lässt sich das Modell verwenden, da die Architektur mit den Mamba-Layern so ähnlich schon in Qwen3-Next vorkam. Damit lässt sich das Modell auch mit moderater Hardware ausführen und funktioniert ohne GPU auf der CPU in akzeptabler Geschwindigkeit.

Bei der Frage nach dem Heise-Verlag antwortet das Modell etwas zu kreativ, aber immerhin in korrekter deutscher Sprache:

Die ganze Antwort findet sich hier.

Die Anzahl der „e“ in „Erdbeere“ kann das Modell hervorragend zählen und antwortet kurz und knapp – sehr viel knapper als fast alle anderen bisher getesteten Modelle:

Die Geschwindigkeit von Nemotron-Nano ist hoch, auf einem MacStudio (M2 Ultra) erreicht es etwa 80 Token/s beim Generieren von Antworten.

Große Nemotrons

Die noch nicht veröffentlichten größeren Nemotron-Modelle sollen noch mehr Tricks auf Lager haben. Nvidia kündigt etwa LatentMoE an und erklärt, dass das damit verbundene Design der Expert-Layer auf die Hardware optimiert wurde. Das wird wie das verwendete NVFP4-Format dann wohl nur gut mit Nvidia-GPUs funktionieren. Denn diese Fähigkeiten unterstützen nur die neueste Hardware-Generation von Nvidia.

Multi-Token Prediction beherrschen schon einige Modelle, auch das sollen die Super- und Ultra-Modelle dann können. Nvidia verspricht sich davon eine verbesserte Generierung langer Texte und eine insgesamt höhere Modellqualität. Noch ist nicht bekannt, wie groß die weiteren Modelle sein werden und wann mit ihnen zu rechnen ist – Nvidia spricht von „in den nächsten Monaten“.

Fazit

Nvidia hat geliefert. Mit der Nemotron-Familie ist bereits in der kleinsten Nano-Version (endlich!) ein Modell verfügbar, das den chinesischen Anbietern von Open-Weight-Modellen Konkurrenz macht. Glaubt man Nvidias Auswertungen, ist das eigene Modell aktuell führend, wenn man die Kosten pro Token im Vergleich zu der Genauigkeit betrachtet (Grenzlinie von Genauigkeit-Inferenz-Durchsatz). Gleichzeitig ist das Modell mit offenen Gewichten verfügbar und kann kommerziell genutzt werden. Zusätzlich hat Nvidia einen Großteil der Trainingsdaten veröffentlicht und schafft damit fast ein Open-Source-Modell. Es wird spannend zu sehen, wie gut die angekündigten größeren Modelle sein werden.

Ganz aktuell hat Nvidia auch das Framework veröffentlicht, mit dem sie die Performance der Modelle gemessen haben; auch das steht frei zur Verfügung und heißt Open Evaluation Standard. Dies ist sicher ein weiterer Beitrag zur Transparenz der Modelle und motiviert vielleicht auch andere Anbieter, damit ihre Modelle zu benchmarken.

(pst)

Der beste Full-HD-Beamer für Heimkino, TV & Konsole

Die besten Tuner für DAB+ zum Nachrüsten für die Stereoanlage

Top 10: Die beste Smartwatch 2025 im Test

Neu in .NET 10.0 [2]: Support für 36 Monate

2025-12-19T08:07:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

.NET 10.0 ist eine Version mit Long-Term-Support (LTS) für 36 Monate. Für einige Bibliotheken ist der Support aber deutlich kürzer.

(Bild: Pincasso/Shutterstock.com)

19.12.2025, 09:07 Uhr

Lesezeit: 1 Min.

Developer

Von

Dr. Holger Schwichtenberg

Während die vorherige, im November 2024 erschienene Version 9.0 Standard-Term-Support (STS) für 24 Monate (ursprünglich sogar nur 18 Monate, wurde verlängert am 16.09.2025) besitzt und daher noch bis zum November 2026 mit Updates versorgt wird, bietet Microsoft Aktualisierungen und technische Hilfe für .NET 10.0 als Long-Term-Support (LTS) für die Dauer von 36 Monaten an, also bis November 2028.

Der Support für das Ende 2023 erschienene .NET 8.0 mit Long-Term-Support (LTS) läuft noch bis 10. November 2026. Alle anderen .NET-Versionen vor Version 9 sind bereits aus dem Support gelaufen.

Erscheinungstermine und Support-Zyklen für das moderne .NET (Abb. 1)

(Bild: Holger Schwichtenberg)

Für einige von Microsoft veröffentlichte .NET-NuGet-Pakete, die nicht Teil des .NET-SDKs sind, gilt eine andere Support-Richtlinie.

Das betrifft folgende Paketfamilien:

Extensions.*, z.B. Microsoft.Extensions.Http.Resilience und Microsoft.Extensions.Telemetry
AspNetCore.*, z.B. Microsoft.AspNetCore.Testing und Microsoft.AspNetCore.Diagnostics.Middleware

Videos by heise

Für diese Pakete gilt:

Es kann jeden Monat ein neues Minor-Release geben (9.1, 9.2, 9.3 usw.).
Es gibt immer nur Support für die jeweils aktuelle Version.
Die Regeln des Semantic Versioning werden nicht streng befolgt von Microsoft.

Die Liste der betroffenen NuGet-Pakete findet man auf der .NET-Site.

Microsoft erläutert den abweichenden Support für die .NET Platform Extensions (Abb. 2).

(Bild: Microsoft)

(rme)

Der beste Full-HD-Beamer für Heimkino, TV & Konsole

Die besten Tuner für DAB+ zum Nachrüsten für die Stereoanlage

Top 10: Die beste Smartwatch 2025 im Test

Kubernetes 1.35 bringt in-place Pod-Updates und beendet Support für cgroup-v1

2025-12-18T13:45:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Mit Version 1.35 "Timbernetes" lassen sich CPU- und Speicherressourcen von Pods nun ohne Neustart anpassen. Der Support für cgroup v1 und containerd 1.x endet.

(Bild: Travel mania/Shutterstock.com)

14:45 Uhr

Lesezeit: 3 Min.

Developer

Von

Matthias Parbel

Das Kubernetes-Projektteam hat Version 1.35 veröffentlicht, die insgesamt 60 Neuerungen umfasst – davon 17 stabile Features sowie 19 Beta- und 22 Alpha-Funktionen. Aufbauend auf der seit Version 1.34 als stabiles Feature verfügbaren Dynamic Resource Allocation (DRA) erweitert das neue Release die Möglichkeiten für Ressourcenmanagement und Workload-Sicherheit.

In-place Updates für Pod-Ressourcen und Beta-Features für Sicherheit

Das wohl wichtigste neue stabile Feature erlaubt laut der Ankündigung zu "Timbernetes" (The World Tree Release) das Anpassen von CPU- und Speicherressourcen laufender Pods, ohne diese neu starten zu müssen. Bisher erforderten solche Änderungen das Neuerstellen von Pods, was insbesondere bei zustandsbehafteten oder Batch-Anwendungen zu Unterbrechungen führen konnte. Die Funktion soll insbesondere vertikales Skalieren vereinfachen.

Native Pod-Zertifikate für Workload-Identität mit automatisierter Zertifikatsrotation stehen nun im Rahmen der Beta-Phase zur Verfügung: Der kubelet generiert Schlüssel, fordert Zertifikate über PodCertificateRequest an und schreibt Credentials gebündelt in das Dateisystem des Pods. Die Knotenbeschränkung erzwingt der kube-apiserver ab dem Zeitpunkt der Zulassung. So sollen sich auch die beim Einsatz von Signierern durch Drittanbieter häufig auftretenden, versehentlichen Verletzungen der Knotenisolationsgrenzen vermeiden lassen. Laut Ankündigung des Kubernetes-Teams eröffnet sich damit auch der Weg zu reinen mTLS-Flows ohne Bearer-Tokens im Ausstellungspfad.

Lesen Sie auch

Kubernetes-Cluster von Ingress Nginx zu Traefik migrieren

Gegen VMware: HPE will VM-Kosten um bis zu 90 Prozent senken

iX-Workshop: Fortgeschrittene Administration von Kubernetes

On-Prem: Microsofts umfangreiche Erweiterung von Azure Local

Azure: NAT Gateway V2 erreicht 100 GBit/s ohne Aufpreis

Die besten Tuner für DAB+ zum Nachrüsten für die Stereoanlage

Top 10: Die beste Smartwatch 2025 im Test

Top 10: Das beste Mittelklasse-Smartphone mit guter Kamera

Softwareentwicklung ist kein Selbstzweck: Ein Rückblick auf 2025

2025-12-18T09:23:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Von Künstlicher Intelligenz bis Event Sourcing: Diesen Themen habe ich mich dieses Jahr im Blog besonders intensiv gewidmet.

(Bild: amgun/Shutterstock.com)

10:23 Uhr

Lesezeit: 10 Min.

Developer

Von

Golo Roden

Softwareentwicklung ist kein Selbstzweck, sondern folgt immer einer zugrunde liegenden Fachlichkeit.

Golo Roden ist Gründer und CTO von the native web GmbH. Er beschäftigt sich mit der Konzeption und Entwicklung von Web- und Cloud-Anwendungen sowie -APIs, mit einem Schwerpunkt auf Event-getriebenen und Service-basierten verteilten Architekturen. Sein Leitsatz lautet, dass Softwareentwicklung kein Selbstzweck ist, sondern immer einer zugrundeliegenden Fachlichkeit folgen muss.

Dieser Satz steht gefühlt in jedem meiner Blogposts hier bei Heise Developer. Er ist mein Leitsatz, meine Überzeugung, mein Kompass. Aber 2025 war das Jahr, in dem er für mich mehr Bedeutung bekommen hat als je zuvor.

Warum scheitern so viele Softwareprojekte? Warum werden sie teurer als geplant, dauern länger als versprochen, liefern weniger als erhofft? Die Antwort, die ich immer wieder sehe, lautet nicht: „Weil die Technik versagt hat.“ Die Frameworks waren gut genug. Die Datenbanken schnell genug. Die Cloud skalierbar genug. Nein, die Projekte scheitern, weil die Fachlichkeit vergessen wird. Weil Technik zum Selbstzweck wird. Weil man Datenbanktabellen entwirft, statt zu fragen, was eigentlich passiert.

Dieses Jahr habe ich versucht, dagegen anzuschreiben. Und nicht nur das.

EventSourcingDB: Die Konsequenz der These

Im Mai dieses Jahres haben wir EventSourcingDB veröffentlicht, eine Datenbank, die speziell für Event Sourcing entwickelt wurde. Keine weitere NoSQL-Datenbank, kein weiteres Tool "um des Tools willen", sondern die technische Konsequenz einer Überzeugung.

Event Sourcing zwingt zum Nachdenken über Fachlichkeit. Man speichert nicht Zustände, sondern fachliche Ereignisse. Nicht "Kunde hat Adresse Y", sondern "Kundin ist am 15. März an folgende Adresse umgezogen". Das klingt nach lediglich einem kleinen Unterschied, ist aber ein fundamentaler Perspektivwechsel. Die Technik dient der Domäne, nicht umgekehrt.

Dass EventSourcingDB inzwischen über 10.000 Docker-Downloads verzeichnet, freut mich. Aber mich freut noch mehr, dass offenbar immer mehr Entwicklerinnen und Entwickler nach genau so einem Werkzeug gesucht haben – einem Werkzeug, das Fachlichkeit ernst nimmt.

Der rote Faden: Die wichtigsten Artikel des Jahres

Über 40 Blogposts habe ich 2025 hier bei Heise Developer veröffentlicht. Über Event Sourcing, über Architektur, über KI, über Agilität und ihre Abgründe. Aber wenn ich zurückblicke, bilden sieben davon für mich den Kern dessen, worum es mir eigentlich geht. Sie erzählen zusammen eine Geschichte: Die Geschichte, warum Softwareentwicklung anders gedacht werden muss.

Das Problem sichtbar machen

Beginnen möchte ich mit einem Märchen. In meinem Blogpost "Warum CRUD für Märchen und Unternehmen gleichermaßen ungeeignet ist" habe ich versucht, ein komplexes Thema über eine einfache Metapher zugänglich zu machen: Der Wolf hat die Großmutter nicht gelöscht – er hat sie gefressen.

CRUD (Create, Read, Update, Delete) ist das Standardvokabular der meisten Anwendungen. Aber es ist ein technisches Vokabular, kein fachliches. Es versteckt, was wirklich passiert. Es reduziert Geschäftsprozesse auf Datenbankoperationen. Und es macht Systeme zu schwarzen Löchern, in denen die Vergangenheit verschwindet.

Das Märchen hat offenbar einen Nerv getroffen. Vielleicht, weil jede Entwicklerin und jeder Entwickler schon einmal vor einem System stand und sich gefragt hat: "Wie ist dieser Datensatz eigentlich in diesen Zustand gekommen?"

Die konzeptionellen Grundlagen

Wenn CRUD das Problem ist, was ist dann die Lösung? Darauf habe ich in zwei Artikeln geantwortet: "Event Sourcing: Die bessere Art zu entwickeln?" und "CQRS als Grundlage für moderne, flexible und skalierbare Anwendungsarchitektur".

Event Sourcing bedeutet, nicht den Zustand zu speichern, sondern die Ereignisse, die zu diesem Zustand geführt haben. CQRS bedeutet, Lesen und Schreiben zu trennen, weil beide unterschiedliche Anforderungen haben. Zusammen bilden sie die Bausteine für Systeme, die Fachlichkeit ernst nehmen. Systeme, in denen man nachvollziehen kann, was passiert ist, und in denen man neue Fragen an alte Daten stellen kann.

Die Vertiefung

Konzepte sind das eine, Umsetzung das andere. Deshalb habe ich im Sommer eine siebenteilige Serie geschrieben: "Event-Driven". Von den Grenzen klassischer Architekturen über die Bausteine Event-getriebener Systeme bis hin zur praktischen Umsetzung am Beispiel einer Stadtbibliothek.

Es war mein umfassendstes Werk zum Thema in diesem Jahr. Und es war mir wichtig zu zeigen, dass Event-getriebene Architektur kein akademisches Konzept ist, sondern ein praktikabler Weg, Software zu bauen, die die Sprache der Domäne spricht.

Technische Tiefe im Dienst der Fachlichkeit

Wer über Event Sourcing spricht, muss auch über Vertrauen sprechen. Wie kann ich beweisen, dass ein bestimmtes Ereignis zu einem bestimmten Zeitpunkt stattgefunden hat? Wie kann ich Nachvollziehbarkeit garantieren, ohne alle meine Daten offenlegen zu müssen?

In "Merkle-Trees: Datenintegrität kryptografisch beweisen" habe ich gezeigt, wie sich diese Fragen elegant lösen lassen. Merkle-Trees sind keine neue Erfindung. Sie stecken in Git, in Blockchains, in Certificate-Transparency. Aber im Zusammenspiel mit Event Sourcing entfalten sie ihre volle Stärke: Sie machen Nachvollziehbarkeit nicht nur möglich, sondern beweisbar.

Das ist keine technische Spielerei. Das ist relevant für Compliance, für Audits, für die DSGVO. Technik im Dienst realer Anforderungen.

Heilige Kühe hinterfragen

Der letzte Artikel in dieser Reihe ist der jüngste und vielleicht der kontroverseste: "Wendet man DDD auf DDD an, bleibt kein Domain-Driven Design übrig".

Domain-Driven Design ist in meiner Community so etwas wie eine heilige Kuh. Und ich schätze die Grundideen von DDD sehr. Aber ich beobachte auch, wie DDD selbst zur Selbstbeschäftigung wird. Wie Teams Bounded-Contexts definieren, ohne je mit einer Fachexpertin gesprochen zu haben. Wie Aggregate und Value-Objects zum Selbstzweck werden, statt der Domäne zu dienen.

Das ist keine Kritik an Eric Evans oder an DDD als Idee. Es ist eine Kritik daran, wie wir als Community manchmal Methoden über Ergebnisse stellen. Und es ist ein Plädoyer dafür, auch unsere liebsten Werkzeuge kritisch zu hinterfragen.

Die Community: Nicht allein unterwegs

So viel ich auch schreibe, am Ende ist es die Community, die diese Themen lebendig macht. Und 2025 hat mir gezeigt, dass ich mit meinen Überzeugungen nicht allein bin.

Im Oktober waren mein Kollege Rendani und ich auf der KanDDDinsky in Berlin – erstmals als Sponsoren und Aussteller für EventSourcingDB. 250 bis 300 Menschen, die unsere Leidenschaft für Domain-Driven Design, Event-Sourcing und durchdachte Softwarearchitektur teilen. Die Gespräche dort haben mir gezeigt: Das Thema hat Momentum. Event-Sourcing und CQRS sind keine Nischeninteressen mehr, die von einer kleinen Gruppe Enthusiasten in isolierten Ecken praktiziert werden.

Besonders gefreut hat mich die Veröffentlichung von OpenCQRS 1.0 durch Digital Frontiers, ein CQRS- und Event-Sourcing-Framework für die JVM mit nativer EventSourcingDB-Integration. Es entsteht ein Ökosystem. Andere bauen auf dem Fundament auf. Das ist die schönste Bestätigung für die Arbeit, die man in ein Projekt steckt.

Und natürlich danke ich Ihnen, den Leserinnen und Lesern, die kommentiert, diskutiert, widersprochen haben. Gerade die kontroversen Artikel haben mir gezeigt, dass das Thema bewegt. Widerspruch ist kein Problem, Gleichgültigkeit wäre eines.

Ausblick: Fachlichkeit, Architektur und KI

Wenn ich auf 2026 blicke, sehe ich ein Thema, das alles andere überlagern wird: Künstliche Intelligenz. Aber nicht so, wie es oft diskutiert wird.

In meinem Blogpost "Event-Sourcing als perfekte Grundlage für KI" habe ich argumentiert, dass die Diskussion um KI zu oft bei den Modellen beginnt. Welches LLM ist das beste? GPT oder Claude? Aber das ist die falsche Frage. Die richtige Frage lautet: „Welche Daten habe ich?“

Ein durchschnittliches Modell mit hochwertigen Daten wird jedes Spitzenmodell schlagen, das auf minderwertigen Daten trainiert wurde. Und die Daten der meisten Unternehmen sind minderwertig, weil sie in CRUD-Systemen liegen, die nur den aktuellen Zustand kennen. Die Vergangenheit? Überschrieben. Der Kontext? Verloren. Die Kausalität? Nicht rekonstruierbar.

Event Sourcing ändert das. Es liefert kontextreiche, nachvollziehbare Daten. Es beantwortet nicht nur die Frage "Was ist?", sondern auch "Wie ist es dazu gekommen?" Und genau das braucht KI.

Gleichzeitig verschiebt sich die Wertschöpfung in der Softwareentwicklung. In "KI macht Entwickler ersetzbar, aber gute Architekten nicht" habe ich beschrieben, was das bedeutet: Codieren wird zur Commodity. Was bleibt, ist Domänenwissen, Architektur, Modellierung. Das ist kein Untergang für unseren Berufsstand, es ist vielmehr eine Chance für alle, die Fachlichkeit ernst nehmen.

Die Kombination aus Architektur, Fachlichkeit und KI wird in Zukunft immer wichtiger. Wer versteht, wie man Systeme baut, die gute Daten produzieren, wer versteht, wie man KI sinnvoll einsetzt, und wer gleichzeitig die Domäne versteht, für die er entwickelt, der wird gefragt sein. Genau an dieser Schnittstelle arbeite ich gerade an einer Webinar-Reihe für 2026: der tech:lounge 360°. Für alle, die nicht von KI überrollt werden wollen, sondern sie verstehen und nutzen möchten.

Zum Schluss

Softwareentwicklung ist kein Selbstzweck. Das war mein Leitsatz zu Beginn dieses Artikels, und es ist mein Leitsatz am Ende dieses Jahres.

2025 war für mich das Jahr, in dem dieser Satz Gestalt angenommen hat: in EventSourcingDB, in über 40 Blogposts, in Gesprächen auf Konferenzen, in der Arbeit mit Kundinnen und Kunden. Es war ein intensives Jahr, ein produktives Jahr, und ich bin dankbar für alle, die diesen Weg mitgegangen sind.

Ich wünsche Ihnen Zeit zwischen den Jahren. Zeit zum Nachdenken, was eigentlich das fachliche Problem ist, das Sie lösen wollen. Zeit, um innezuhalten und sich zu fragen, ob die Technik, mit der Sie arbeiten, der Fachlichkeit dient oder zum Selbstzweck geworden ist.

Und dann ein Jahr 2026, in dem die Technik wieder das wird, was sie sein sollte: ein Werkzeug im Dienst dieser Fachlichkeit.

Frohe Weihnachten, ruhige und erholsame Feiertage, und einen guten Start ins neue Jahr. (rme)

Die besten Tuner für DAB+ zum Nachrüsten für die Stereoanlage

Top 10: Die beste Smartwatch 2025 im Test

Top 10: Das beste Mittelklasse-Smartphone mit guter Kamera

Drupal 11.3.0 steigert Performance um bis zu 33 Prozent

2025-12-18T08:22:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Das Open-Source-CMS Drupal 11.3.0 bringt massive Performance-Verbesserungen durch HTMX-Integration und Cache-Optimierungen.

(Bild: heise online (Collage))

09:22 Uhr

Lesezeit: 4 Min.

iX Magazin

Von

Moritz Förster

Die Drupal Association hat Version 11.3.0 des quelloffenen Content-Management-Systems veröffentlicht. Nach eigenen Angaben handelt es sich um den größten Performance-Schub seit einem Jahrzehnt – seit Drupal 8. Das Release kombiniert zahlreiche Optimierungen im Rendering- und Caching-Layer und setzt erstmals auf die JavaScript-Bibliothek HTMX.

Die Entwickler berichten von 26 bis 33 Prozent mehr verarbeitbaren Anfragen bei gleicher Datenbanklast. Automatisierte Tests zeigen bis zu 33 Prozent weniger Cache-Operationen bei „kalten“ Caches (wenn Cache-Einträge fehlen oder abgelaufen sind) und bis zu 25 Prozent bei teilweise „warmen“ Caches (relevante Daten sind bereits zwischengespeichert und können schnell zur Verfügung stehen). Unabhängige Tests der Firma MD Systems auf komplexen Websites ergaben noch deutlichere Verbesserungen, besonders bei Sites mit hoher Datenbankauslastung.

HTMX reduziert JavaScript-Overhead drastisch

Ein zentraler Baustein der Performance-Optimierung ist der Wechsel zu HTMX in BigPipe. Die JavaScript-Bibliothek ohne externe Abhängigkeiten ermöglicht AJAX-Anfragen, CSS-Transitions, WebSockets und Server-Sent Events direkt über HTML-Attribute. Dadurch ersetzt HTMX bisherige Drupal-eigene Lösungen wie die Form State API und die AJAX API. Der JavaScript-Overhead für Browser-Server-Interaktionen sinkt um bis zu 71 Prozent.

BigPipe lädt JavaScript nun nur noch bei Bedarf und fängt Platzhalter proaktiv ab, um sie mit bereits „vorgewärmten“ Render-Caches zu ersetzen. Das beschleunigt das Rendering erheblich. In künftigen Versionen planen die Entwickler, BigPipe auch für anonyme Site-Besucher zu aktivieren.

Videos by heise

PHP Fibers ermöglichen paralleles Entity Loading

Drupal 11.3.0 nutzt PHP Fibers, eine Funktion seit PHP 8.1, für optimiertes Entity Loading. Die kooperative Multitasking-Technik erlaubt das Kombinieren von Datenbank- und Cache-Queries, ohne Prozesse zu blockieren. Zusätzlich wurden die Hook- und Field-Discovery-Prozesse überarbeitet, was Datenbank- und Cache-I/O sowie Speicherverbrauch bei „kalten“ Caches reduziert.

Für MySQL- und MariaDB-Nutzer steht ein experimenteller MySQLi-Driver bereit. Dieser nutzt die mysqli-Extension statt PDO und ermöglicht parallele statt sequenzielle Queries. Asynchrone Unterstützung ist geplant. Der Treiber ist noch nicht in der regulären Benutzeroberfläche zu finden und erhält noch keinen vollständigen Support.

Navigation-Modul wird stabil

Das Navigation-Modul gilt jetzt als stabil und bietet eine modernere Alternative zur alten Toolbar. Es eignet sich besonders für Seiten mit komplexer Admin-Struktur, ist aber noch nicht als Standard aktiviert. Die Entwickler empfehlen es für alle Installationen.

Der CKEditor unterstützt nativ On-Site-Links via Autocomplete und Dropdown für Entity References. Neue Optionen für Aufzählungszeichen und Nummerierungen erleichtern die Content-Erstellung. Eine dedizierte Berechtigung „Administer node published status“ trennt die Rechte zum Veröffentlichen von der allgemeinen Node-Administration.

OOP-Hooks für Themes und Content-Export

Themes können wie Module das #[Hook()]-Attribut nutzen. Die Implementierungen liegen in src/Hook/ und werden über Namespaces im Container registriert. Dies ermöglicht saubereren, strukturierten Code.

Ein neuer CLI-Befehl php core/scripts/drupal content:export ENTITY_TYPE_ID ENTITY_ID exportiert Entities samt Abhängigkeiten wie Bilder oder Taxonomie-Terms. Die Funktion nutzt dasselbe Format wie das Modul Default Content.

Drupal 11.3.0 unterstützt vollständig PHP 8.5, das im November 2025 erschien. Die Core-Tests laufen auf der neuen PHP-Version, die als Mindestanforderung für Drupal 12 im Jahr 2026 dient. Drupal 10 erhält noch bis Dezember 2026 Security-Support. Der visuelle Page Builder Drupal Canvas, Anfang Dezember veröffentlicht, ergänzt die neuen Performance-Features um komfortablere Site-Building-Optionen.

Siehe auch:

Drupal bei heise download

(fo)

Die besten Tuner für DAB+ zum Nachrüsten für die Stereoanlage

Top 10: Die beste Smartwatch 2025 im Test

Top 10: Das beste Mittelklasse-Smartphone mit guter Kamera

Docker Inc. macht gehärtete Abbilder kostenlos verfügbar

2025-12-17T18:21:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Gehärtete Docker-Images sind auf ein Minimum reduziert, sodass möglichst wenig Angriffsfläche bleibt. Docker Inc. stellt solche jetzt kostenfrei zur Verfügung.

(Bild: Merlin Schumacher (c't magazin))

17.12.2025, 19:21 Uhr

Lesezeit: 4 Min.

c't Magazin

Von

Jan Mahn

Docker Inc. hat angekündigt, ein bisher kostenpflichtiges Produkt fortan kostenlos anzubieten: Docker Hardened Images (DHI). Der Erfinder der Software Docker und Betreiber des Docker Hubs erklärt, damit auf Lieferkettenangriffe zu reagieren, die auch im Containerumfeld vorkommen. Die gehärteten Abbilder enthalten ein aufs absolut Nötige reduziertes Userland einer Distribution und unterscheiden sich dadurch von den sogenannten „Official Images“, die man ohne Login im Docker Hub (hub.docker.com) für viele Anwendungen findet.

Weniger Spuren der Distribution

Als Beispiel reicht ein Blick auf den Webserver Nginx und dessen Abbild: Im öffentlichen Hub gibt es Abbilder mit dem Namen nginx, die auf den Distributionen Alpine oder Debian aufbauen. Neben dem Webserver selbst stecken Teile der Distribution darin. Die meisten Komponenten sind für den Betrieb des Webservers gar nicht nötig und allenfalls hilfreich, wenn man mit Werkzeugen wie docker exec in einen Container springt und darin Fehler sucht. Über den eingebauten Paketmanager (apt oder apk) kann man beispielsweise einen Texteditor nachinstallieren und auf Fehlersuche im Container gehen. Solche Werkzeuge können aber auch zum Einfallstor für Angreifer werden.

Die gehärteten Abbilder enthalten weniger Spuren der Distribution und damit weniger Einfallstore – im Gegenzug aber auch keine Werkzeuge für die spontane Fehlersuche. Zum Vergleich: Das offizielle Nginx-Abbild auf Alpine-Basis (nginx:alpine) ist 21 MByte groß und kommt mit einer bekannten mittelschweren Sicherheitslücke, für die es einen CVE-Eintrag gibt. Die Debian-Variante (nginx:stable-bookworm) ist sogar 67 MByte groß, hat drei Lücken mit hoher Dringlichkeit, drei mittelschwere und ganze 61 mit der Einstufung „low“. Die gehärtete Version auf Alpine-Basis (dhi.io/nginx:1-alpine3.21) ist nur 4 MByte groß und Docker listet keine einzige bekannte Sicherheitslücke. Ein Blick in den Container zeigt: Der Paketmanager apk, der zu Alpine gehört, fehlt im Abbild.

Kompakt und ohne bekannte Lücken: Das gehärtete Nginx-Abbild auf Alpine-Basis ist nur 4 MByte groß.

Die gehärteten Abbilder gibt es für viele Anwendungen, für die es auch offizielle Abbilder gibt – darunter MySQL, PHP, Node.js, Traefik und MongoDB. Kein gehärtetes Abbild fanden wir für die MySQL-Alternative MariaDB. Um die Abbilder zu finden, müssen Sie sich im Docker Hub mit einem kostenlosen Account anmelden, über den öffentlichen Bereich des Hubs sind sie aktuell nicht zu finden. Sie landen nach dem Login in einer Übersicht namens „My Hub“ und finden links im Menü den Punkt „Hardened Images“. Um die Abbilder auf einem Server, einer Entwicklermaschine oder in einer CI/CD-Umgebung zu nutzen, müssen Sie dort zuerst den Befehl docker login dhi.io ausführen und sich mit Benutzernamen und einem persönlichen Zugangstoken anmelden. Ein solches Token erzeugen Sie, indem Sie oben rechts auf Ihre Initialen klicken, die „Account Settings“ öffnen und links unter „Personal access tokens“ ein Token erzeugen, das Leserechte hat.

Mehr Service gegen Geld

Neben den Abbildern hat Docker Inc. auch Helm-Charts für Kubernetes-Nutzer veröffentlicht, in denen die gehärteten Abbilder zum Einsatz kommen. Die Entscheidung von Docker Inc., sein Angebot für DHI kostenlos zu machen und unter Apache-2.0-Lizenz zu stellen, kann auch als Reaktion auf Bitnamis jüngste Planänderung verstanden werden: Die zu Broadcom gehörende VMware-Sparte hatte angekündigt, seine öffentlichen Abbilder nicht weiter anzubieten und gehärtete Varianten davon nur noch gegen Geld.

Auch in Zukunft möchte Docker Inc. mit den gehärteten Abbildern Geld verdienen, wie der Blogpost zur Ankündigung erklärt. Wer regulatorische Anforderungen hat und beispielsweise FIPS-konforme Abbilder braucht oder sich eine Reaktion auf kritische CVEs innerhalb von sieben Tagen vertraglich zusichern lassen muss, greift zu den kostenpflichtigen „Docker Hardened Images Enterprise“. Außerdem verspricht Docker erweiterten Support für Anwendungen in Versionen, die von den Entwicklern der Anwendungen nicht mehr unterstützt werden („DHI Extended Lifecycle Support“).

(jam)

Die besten Tuner für DAB+ zum Nachrüsten für die Stereoanlage

Top 10: Die beste Smartwatch 2025 im Test

Top 10: Das beste Mittelklasse-Smartphone mit guter Kamera

Chainguard startet EmeritOSS-Programm für verwaiste Open-Source-Projekte

2025-12-17T12:55:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Die Chainguard-Initiative soll die Wartung von OSS-Projekten sicherstellen, deren Maintainer sich zurückgezogen haben – etwa Kaniko, Kubeapps und ingress-nginx.

(Bild: A.Basler/Shutterstock.com)

17.12.2025, 13:55 Uhr

Lesezeit: 3 Min.

Developer

Von

Matthias Parbel

Eine Reihe von Open-Source-Projekten, die weit verbreitet und tief in Produktionssystemen eingebettet sind, befinden sich in einer Grauzone zwischen aktiver Entwicklung und nachlassendem Engagement – bis hin zur vollständigen Aufgabe. Die Anwendungen arbeiten stabil, benötigen aber für den weiterhin zuverlässigen Betrieb in Produktion zumindest eine minimale Wartung für Sicherheitspatches und Dependency-Updates. Ziehen sich jedoch die Maintainer aus diesen Projekten zurück, können sie zu einem Sicherheitsrisiko werden. An dieser Stelle setzt das neue Programm „EmeritOSS“ von Chainguard an.

Das Unternehmen Chainguard, das unter anderem gehärtete Container Images bereitstellt, will laut Ankündigung mit EmeritOSS betroffenen Open-Source-Projekten eine „stabile und verlässliche Heimat“ bieten. Vordringliches Ziel sei nicht die Weiterentwicklung dieser Projekte, sondern die Stärkung der Nachhaltigkeit von Open-Source-Software insgesamt.

Die xz-utils-Backdoor als warnendes Beispiel

Als eine Motivation für das Programm führt Chainguard beispielhaft den Social-Engineering-Angriff auf das Free/Libre-Open-Source-Software-Projekt (FLOSS) xz-utils an. Bei diesem 2024 bekannt gewordenen Vorfall hatte sich der ursprüngliche Maintainer nach langjährigem Engagement aus dem Projekt zurückziehen wollen. Ein neuer Contributor konnte schrittweise dessen Vertrauen gewinnen – und versuchte dann, eine Backdoor einzuschleusen, die unzählige Systeme hätte kompromittieren können.

Lesen Sie auch

Nach XZ-Backdoor: Open-Source-Software als Risiko oder strategischer Vorteil?

Eine Analyse der xz-Hintertür, Teil 1

Die besten Tuner für DAB+ zum Nachrüsten für die Stereoanlage

Top 10: Die beste Smartwatch 2025 im Test

Top 10: Das beste Mittelklasse-Smartphone mit guter Kamera

GitHub stoppt Subventionierung von Actions in privaten Repos

2025-12-17T10:53:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

In privaten Repos waren selbstgehostete Actions bislang kostenlos. Das ändert GitHub nun und führt neue Preise ein. Gehostete Actions werden dafür günstiger.

(Bild: Mali lucky/Shutterstock.com)

Update 17.12.2025, 11:53 Uhr

Lesezeit: 1 Min.

Developer

Von

Wolf Hosbach

Update 18.12.2025, 08:23 Uhr

GitHub hat die angekündigten Gebühren für private, selbstgehostete Actions Runner verschoben – behält die Preissenkung von durch GitHub gehostete Projekte jedoch bei. „Wir haben mit dieser Änderung den Punkt verfehlt, nicht mehr von euch in die Planung miteinzubeziehen“, schreibt der Dienst auf X. „Wir nehmen uns mehr Zeit, um Entwickler, Kunden und Partner zu treffen und ihnen aufmerksam zuzuhören.“

Ab Januar 2026 führt GitHub neue Preise für die automatisierten Aufgaben der Actions in privaten Repositories ein. Für Runner, auf denen die Actions laufen, gibt es eine Preisreduktion um circa vierzig Prozent, wenn GitHub sie hostet. Selbstgehostete Runner kosten ab jetzt hingegen erstmalig eine Gebühr von 0,2 US-Cent pro Minute.

Actions in öffentlichen Repositories bleiben kostenlos und auch für Enterprise Server ändert sich nichts. GitHub begründet die Änderung mit einer faireren Verteilung der Infrastrukturkosten, weil bislang Hostingkunden die Selbsthoster mitfinanzierten. GitHub hat ausgerechnet, dass sich für 96 Prozent der Kunden nichts ändern wird, vom Rest werden 85 Prozent eine Preisreduktion auf der Rechnung finden. Alle anderen müssen mit einer Erhöhung um 13 Dollar im Median pro Monat rechnen. Über einen Preiskalkulator online lassen sich die Kosten planen.

Videos by heise

Im August hatte GitHub eine neue Infrastruktur für die Actions eingeführt, auf der 71 Millionen Jobs am Tag laufen. Die Actions automatisieren Jobs für die Softwareproduktion wie Tests und Builds. Diese laufen auf Runnern, also virtuellen OS-Umgebungen.

Lesen Sie auch

Github Universe 2025: Wie Github sich erneut beweisen will

Goodbye Copilot: Wie Sie KI-Coding-Assistenten lokal betreiben

Die besten Tuner für DAB+ zum Nachrüsten für die Stereoanlage

Top 10: Die beste Smartwatch 2025 im Test

Top 10: Das beste Mittelklasse-Smartphone mit guter Kamera

Model-Schau 1: Schlanke KI-Spezialmodelle im Trend

2025-12-16T11:19:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Die neue Kolumne widmet sich den wichtigsten Neuerungen bei offenen und proprietären Large Language Models.

(Bild: pncha.me/Shutterstock)

16.12.2025, 12:19 Uhr

Lesezeit: 14 Min.

Developer

Von

Dr. Christian Winkler

Beim Blick auf Large Language Models vergeht fast keine Woche ohne neue Modelle, die sich in bestimmten Nischen positionieren oder neue Techniken ausprobieren. Das hat uns dazu bewogen, regelmäßig über diese Updates zu berichten. Bei größeren Neuerungen werden wir den geplanten Zweiwochentakt unterbrechen und neue Modelle direkt untersuchen.

Dieses erste Update fällt etwas umfangreicher aus. Aktuelle Modelle finden sich bei Hugging Face oder durch konsequentes Mitlesen im sehr aktiven LocalLLaMa-Subreddit. Gerne nehmen wir auch Vorschläge über Modelle entgegen, die wir uns näher anschauen sollen.

Kleine Spezialmodelle

Der Trend muss nicht zu immer größeren Modellen gehen. Bei Hugging Face finden sich einige Modelle, die sehr beliebt, aber nicht besonders groß sind.

Ganz vorn steht hier VibeThinker von WeiboAI. Das Reasoning-Modell ist vor allem darauf ausgelegt, mathematische Fragen zu beantworten oder Programmcode zu erzeugen. Für diese Aufgaben ist es sehr gut geeignet. Laut den Benchmarks spielt es in der gleichen Liga wie das (ältere) Gemini 2.5 Flash und überholt teilweise sogar DeepSeek R1.

(Bild: Bridgman/AdobeStock)

Am 22. und 23. April 2026 findet die Minds Mastering Machines in Karlsruhe statt. Im Mittelpunkt der von iX und dpunkt.verlag veranstalteten Konferenz stehen praxisnahe Themen von klassischem Machine Learning bis zu LLMs und Agentic AI. Das Programm bietet unter anderem Vorträge zu folgenden Themen:

Predictive Maintenance in der Praxis
Kommunikationsprotokolle für Agentic AI
Embeddings richtig verstehen
MCP sicher im Unternehmen einsetzen
Lokale LLMs in der Praxis

Erstaunlich ist, dass das Modell mit nur 1,5 Milliarden Parametern auskommt. Die anderen genannten Modelle haben 400-mal mehr Gewichte zu verarbeiten und sind dadurch entsprechend langsam. Die Größe spielt besonders bei Coding-Modellen eine entscheidende Rolle: Erstens will man die Modelle möglicherweise auch lokal ausführen, nachdem man sie potenziell feingetunt hat, und zweitens generieren diese Modelle sehr viele Token – je schneller das geht, desto kürzer ist die Wartezeit auf den generierten Code.

Mit vier Milliarden Parametern etwas größer, aber noch spezialisierter ist AesCoder, das mithilfe von GRPO (Group Relative Policy Optimization) auf die Erledigung von Web-Designaufgaben spezialisiert ist.

Konkurrenzfähige offene Modelle von Olmo

Auch wenn man häufig von Open-Source-Modellen spricht, sind meist lediglich die Gewichte der Modelle frei verfügbar. Nur wenige Anbieter veröffentlichen die Trainingsdaten und die Algorithmen, mit denen sie die Modelle trainiert haben. Neben Hugging Face mit SmolLM gibt es offene Trainingsdaten für das Modell Apertus aus der Schweiz und vor allem für die Olmo-Modelle vom Allen AI Institute. Letzteres braucht sich aufgrund der Investitionen durch Microsoft-Mitgründer Paul Allen keine großen Gedanken um die Finanzierung zu machen.

Besonders die jüngsten Olmo-3-Modelle integrieren viele innovative Techniken und machen damit einen gewaltigen Sprung nach vorn. Sie stehen in zwei Größen mit 7 und 32 Milliarden Parametern zur Verfügung. Das größere Modell gibt es in einer Reasoning-Variante, das kleinere zusätzlich noch als Instruction-Following-Modell ohne Reasoning. Für diejenigen, die die Modelle feintunen möchten, stellt Olmo anders als die meisten anderen Anbieter die Basismodelle zur Verfügung.

Videos by heise

Im Vergleich zu anderen Modellen wie Qwen3 hat Olmo 3 deutlich weniger Token im Training erhalten: 5,9 Billionen aus dem Datensatz Dolma 3 Mix. Das macht sich leider in der Modellperformance bemerkbar, die nach ersten Tests nicht mit den Qwen3-Modellen in der gleichen Größenordnung mithalten kann. Die Strawberry-Challenge mit der Frage nach der Anzahl der „e“ in „Erdbeere“ (oder „r“ in „strawberry“) beantwortet das Modell konsequent falsch. Auch die deutschen Sprachfähigkeiten der kleineren Modelle sind nicht besonders gut ausgeprägt:

Bei der Antwort von Olmo 3 7B sind nicht nur die Inhalte falsch, auch die sprachliche Ausführung ist mangelhaft (Abb. 1).

(Bild: datanizing)

Das Modell Olmo 3 32B macht zwar ebenfalls Fehler, liegt aber häufiger richtig und formuliert deutlich bessere Sätze (Abb. 2).

(Bild: datanizing)

Der Artikel zu Olmo 3 enthält viele Details über die Architektur und das Training des Modells. Das gibt interessante Einblicke in den Trainingsprozess. Insbesondere das Post-Training ist sehr anspruchsvoll, weil Olmo dabei mit unterschiedlichen Datensets arbeitet, um die Qualität zu verbessern. Viele Innovationen gibt es beim Reinforcement Learning des Reasoning-Modells (bei Olmo „Thinking“ genannt).

Einige der GRPO-Optimierungen sind von anderen Modellen bekannt, kommen aber in dieser Kombination erstmals bei Olmo zum Einsatz. Das Modell setzt außerdem die weiterentwickelte Version des Verfahrens Reinforcement Learning with Verifiable Rewards (RLVR) ein, mit dem auch das neue Training von DeepSeek arbeitet. Mit RLVR kann man automatisiert überprüfen, ob Sprachmodelle die richtigen Ergebnisse vorhersagen. Die Besonderheit der weiterentwickelten Version ist, dass man damit Trainingsdaten automatisiert erzeugen kann – in Grenzen und bestimmten fachlichen Domänen.

Die besten Tuner für DAB+ zum Nachrüsten für die Stereoanlage

Top 10: Die beste Smartwatch 2025 im Test

Top 10: Das beste Mittelklasse-Smartphone mit guter Kamera

BOB-Konferenz 2026: Vorträge zur funktionalen Programmierung und mehr

2025-12-16T09:38:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Die Konferenz bringt Vorträge und Tutorials zu Themen jenseits des Mainstreams und KI, von denen sich viele mit funktionaler Programmierung beschäftigen.

(Bild: BOB-Konferenz)

16.12.2025, 10:38 Uhr

Lesezeit: 2 Min.

Developer

Von

Matthias Parbel

Das Programm der dreizehnten BOB-Konferenz, die am 13. März 2026 wie gewohnt in Berlin im Scandic-Hotel Potsdamer Platz stattfindet, steht fest. Traditionell liegt die funktionale Programmierung im Fokus, in der Agenda für das nächste Jahr finden sich aber auch zahlreiche weitere Themen – auf eines verzichten die Organisatoren von der Active Group jedoch: KI. Die BOB 2026 soll ganz bewusst zeigen, „dass es immer noch IT jenseits der KI gibt“.

Vorträge und Tutorials

In seinem Eröffnungsvortrag zur BOB 2026 begibt sich Stefan Kaufmann auf die „Suche nach der Bedeutung in einem Magischen Konzept“. Der Medieninformatiker und Open-Data-Sachverständige geht dabei der Frage nach, was „Digitale Souveränität“ eigentlich genau sein soll.

Videos by heise

Das weitere Programm der BOB-Konferenz umfasst 16 Talks und acht Tutorials, unter anderem zu Themen wie OCaml, Scala, Java, funktionale Softwarearchitektur und funktionale Programmierung mit SwiftUI. Über Beiträge zu Barrierefreiheit, UI-Entwicklung, Datenbank-Joins, Domain-Driven Design und Reactive Systems hinaus verspricht etwa Lutz Hühnken Einblicke in einige exotische Programmiersprachen noch jenseits von Haskell, Rust, Whitespace oder Brainf**k.

Registrierung mit Early-Bird-Rabatt eröffnet

Die BOB 2026 bietet sowohl englischsprachige als auch deutsche Vorträge und Tutorials an. Mit der Veröffentlichung des Programms hat die Registrierung begonnen. Bis zum 16. Januar 2026 gilt der Early-Bird-Rabatt. Auf Anfrage gibt es verschiedene ermäßigte Tickets sowie einige kostenlose für unterrepräsentierte Gruppen. Weitere Details lassen sich der Ankündigung entnehmen.

(map)