Connect with us

Entwicklung & Code

Machtwort: Yukihiro “Matz“ Matsumoto beendet Streit in der Ruby-Community


Nachdem ein wochenlanger Streit zwischen Ruby Central und Teilen der Community um die Herrschaft über das Paket-Repository RubyGems die Ruby-Gemeinschaft in Atem gehalten hat, zeigt sich nun eine Deeskalation.

Weiterlesen nach der Anzeige

Am 17. Oktober 2025 veröffentlichte Ruby-Erfinder Yukihiro „Matz“ Matsumoto persönlich eine Erklärung auf der offiziellen Ruby‑Website: Das Ruby‑Core‑Team werde künftig die Verantwortung für RubyGems und Bundler übernehmen. Die Projekte würden unter das Dach der Sprache selbst zurückkehren, während Ruby Central als gemeinnützige Organisation den operativen Betrieb über Infrastruktur und RubyGems.org sicherstelle.

Diese Entscheidung brachte Ruhe in die Community. Viele sahen darin einen Kompromiss: Kontrolle und Stabilität bei Ruby Central, offene Entwicklung unter dem Dach des Core‑Teams. Ruby Central begrüßte den Schritt und sprach von einem „gemeinsamen Bekenntnis zur Zukunft des Ruby‑Ökosystems“.

Nach den hitzigen Wochen hat Ruby Central sich bemüht, verlorenes Vertrauen zurückzugewinnen. In der Reihe Source of Truth legte die Organisation wöchentlich Berichte und Q&As vor, in denen sie Fragen der Community beantwortete. Die Betreiber räumten Fehler ein: Die Kommunikation sei zu langsam, die Tonlage zu formal gewesen. Nun wolle man „Sichtbarkeit und Beständigkeit schaffen“.

Ruby Central betonte mehrfach, dass Sponsoren – allen voran Shopify – keinen operativen Einfluss auf Entscheidungen gehabt hätten. Zugleich wurden neue Verträge für Maintainer und Betreiber eingeführt, um Zuständigkeiten eindeutig zu regeln.

Während Ruby Central an seiner neuen Governance arbeitete, gründeten ehemalige Maintainer das Projekt gem.coop – einen alternativen Spiegel‑ und später eigenständigen Gem‑Server. Damit entstand erstmals ein dezentraler Ansatz im Ruby‑Ökosystem: mehrere Orte, ein gemeinsames Ziel – Software sicher und offenzuhalten. Aktuell sieht es aber stark danach aus, als wenn weiterhin rubygems.org die zentrale Anlaufstelle für Pakete bleibt.

Weiterlesen nach der Anzeige

Entstanden war der Streit, als Ruby Central Mitte September 2025 den langjährigen Maintainern der zentralen Projekte RubyGems und Bundler die Zugriffsrechte entzog. Damit begann einer der größten Konflikte in der Geschichte der Ruby‑Community. Die Organisation begründete ihren Schritt mit Sicherheitsbedenken und der Notwendigkeit, die Lieferkette des Ökosystems zu schützen. Doch für viele Entwickler klang das nach einem Vorwand – nach einem Machtwechsel hinter den Kulissen, nicht nach Sicherheit.

Seit Jahren ist RubyGems.org ein zentraler Bestandteil des Ruby‑Universums – hier liegen über 175.000 frei verfügbare Bibliotheken, ohne die viele Anwendungen nicht laufen würden. Hinter dem Dienst stand eine kleine, weitgehend ehrenamtliche Gruppe von Maintainern. Sie hielten Server am Laufen, schrieben Code und kümmerten sich um die Sicherheit. Ruby Central finanzierte Infrastruktur und Hosting, doch die operative Kontrolle lag bislang bei Freiwilligen.

Das änderte sich im September abrupt, als Ruby Central das GitHub Repository unter ihre Kontrolle brachte und den Admins sämtliche Rechte entzog. In der Community bekannte Namen wie Ellen Marie Dash, Samuel Giddins und André Arko verschwanden über Nacht aus den Organisationen. Die Erklärung: Man wolle „formale Zuständigkeiten“ schaffen und „kritische Schlüsselstellen absichern“. Doch in den Augen vieler war es eine Entmachtung.

Der Aufschrei ließ nicht lange auf sich warten. Entwickler Joel Drapper sprach von einer „feindlichen Übernahme“ und legte interne Abläufe offen, die Zweifel an Ruby Centrals Kommunikation aufwarfen. Arko selbst, seit Jahren Gesicht und Stimme von Bundler, reagierte empört.

Die Lage eskalierte, als neue Details ans Licht kamen. Nach internen Mails hatte Ruby Central schon Wochen zuvor erwogen, Zugriffe zu entziehen – aus Sorge, einzelne Maintainer könnten zu viel Kontrolle besitzen. Arko stand dabei im Fokus.

Laut Ruby-Central‑Bericht vom 10. Oktober 2025 verfügte Arko auch nach seiner Abberufung noch über Root‑Zugriff auf die AWS‑Systeme von RubyGems.org. Der Account sei in den frühen Morgenstunden genutzt worden. Zwar habe es keine Hinweise auf Datenmanipulation gegeben, aber der Vorfall habe Sicherheitsprozesse offengelegt, „die dringend verbessert werden mussten“.

Arko wies die Vorwürfe zurück. Er habe gehandelt, weil er befürchtete, die Infrastruktur könne ohne seine Zugangsdaten kompromittiert werden. Nach eigener Darstellung habe er Ruby Central schließlich informiert und den Zugang geordnet zurückgegeben. Die Organisation sah wiederum darin einen klaren Verstoß gegen Verantwortlichkeiten.

Im Nachhinein wurde klar, dass beide Seiten Fehler gemacht hatten. Ruby Central hielt eine brisante Sicherheits‑ und Governance‑Frage zu lange intern; Arko handelte ohne Mandat, aber nach eigener Aussage mit der Überzeugung, Schaden abzuwenden.

Im Kern ging es um die Frage: Wer trägt Verantwortung für Open Source? Ruby Central hatte über Jahre Serverkosten getragen, Fördergelder verwaltet und Sponsorengelder akquiriert. Doch die Entwicklung selbst blieb ein Community‑Projekt – rechtlich, aber auch ideell. Als Ruby Central im September die Kontrolle übernahm, prallten zwei Selbstverständnisse aufeinander: Betriebssicherheit versus Gemeinschaftseigentum.

Die Debatte spitzte sich zu, als bekannt wurde, dass Arko den Namen Bundler zuvor als Marke registriert hatte. Damit wollte er verhindern, dass Ruby Central den Namen für eigene Forks verwenden kann. Aus juristischer Sicht war das legal, aus Community‑Sicht aber ein symbolischer Bruch. Ruby Central sprach von einer „inakzeptablen Vereinnahmung“.

Für normale Ruby-Entwickler ergab das alles über mehrere Wochen eine Situation, in der keiner sicher sein konnte, wie es weitergeht. Es fühlte sich oft wie eine dramatische Telenovela an, nur mit dem bitteren Beigeschmack, dass alle Ruby-Entwickler auf eine funktionierende RubyGems Infrastruktur angewiesen sind.

Als Besonderheit der Ruby-Community muss man auch die involvierten und sehr unterschiedlichen Kulturkreise betrachten. Ein bedeutender Teil der Community kommt aus dem asiatischen Raum und löst Probleme ganz anders als die nordamerikanischen Entwickler. Europa war und ist im Ruby-Core-Team eher unterrepräsentiert.

Als Besonderheit in diesem Universum gilt weiterhin die kanadische Firma Shopify, die von Anfang an ganz auf Ruby on Rails gesetzt hat. Selbst wenn die Firma an sich keinen direkten Einfluss ausübt, ist die schiere Anzahl an Ruby-Entwicklern dort schon ein wichtiger Machtfaktor. Außerdem ist Shopify aktuell der größte Sponsor. Shopify braucht Ruby und Ruby braucht Shopify.

Die RubyGems‑Affäre zeigte, wie fragil Open‑Source‑Projekte sind, wenn Vertrauen und Transparenz fehlen. Zugleich bewies sie, wie anpassungsfähig eine Community sein kann. Peter Zhu, Ruby Core Mitglied und selbst früher bei Shopify, brachte es auf den Punkt: Open Source sei „das zerbrechlichste und zugleich widerstandsfähigste Ökosystem“. Genau das hat sich hier bestätigt.

Heute, wenige Wochen nach dem Sturm, ist Ruby Centrals Kommunikationsfrequenz höher, die Dokumentation besser, und das Core‑Team hat die Codebasis übernommen. Die Maintainer, die einst gingen, arbeiten an neuen Projekten. Und die Community diskutiert offener über Finanzierung, Verantwortung und Governance.

Die Krise hat Spuren hinterlassen – aber auch Strukturen geschaffen, die künftige Konflikte abfedern können. Vielleicht war dieser Bruch schmerzhaft, aber nötig: ein Weckruf, dass Open Source nicht nur vom Code lebt, sondern vom Vertrauen zwischen denen, die ihn schreiben, finanzieren und schützen.


(who)



Source link

Entwicklung & Code

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


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:

Weiterlesen nach der Anzeige

  • 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.


Aufmacher betterCode() API

Aufmacher betterCode() API

(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 ifthen …. Außerdem vervollständigt das RAD Studio die Unterstützung von Windows 64bit als Compiler-Ziel.

  • Next.js 16.1 bringt ein Update für Turbopack und einen experimentellen Bundle Analyzer. Mit diesem interaktiven Tool optimieren Entwicklerinnen und Entwickler ihren Code. Eine Vereinfachung gibt es zudem für den Debugger, der sich mit next dev --inspect aufrufen lässt.
  • Mit Version 18.7 integriert GitLab künstliche Intelligenz stärker in die Plattform, beispielsweise bei der Diagnose abgebrochener Pipelines oder beim statischen Testen. Die generelle Verfügbarkeit der Duo-Agenten-Plattform ist für den Januar mit Version 18.8 angekündigt.
  • LangGrant (vormals Windocks) hat den LEDGE MCP-Server vorgestellt, der helfen soll, die Entwicklung agentenbasierter KI zu beschleunigen. Die Plattform soll es ermöglichen, das Reasoning von LLMs über mehrere Datenbanken wie Oracle, SQL Server, Postgres oder Snowflake hinweg zu skalieren und mehrstufige Analysepläne auszuführen – ohne dass dabei Daten an das LLM gesendet werden müssen.

Solltest du ein schmackhaftes Thema vermissen, freuen wir uns über deine Mail.


(mai)



Source link

Weiterlesen

Entwicklung & Code

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


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.

Weiterlesen nach der Anzeige


Michael Stal

Michael Stal

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.

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.

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.

Weiterlesen nach der Anzeige

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.

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.



Source link

Weiterlesen

Entwicklung & Code

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


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

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.

Weiterlesen nach der Anzeige


Der Dotnet-Doktor – Holger Schwichtenberg

Der Dotnet-Doktor – Holger Schwichtenberg

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.

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.


Diagramm .NET-Support

Diagramm .NET-Support

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

Für diese Pakete gilt:

Weiterlesen nach der Anzeige

  • 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.


Screenshot Release Cadence

Screenshot Release Cadence

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

(Bild: Microsoft)


(rme)



Source link

Weiterlesen

Beliebt