In der US-Softwarebranche wird Python-Code inzwischen zu fast 30 Prozent von KI geschrieben. Zu diesem Ergebnis kommt eine Analyse des Complexity Science Hub (CSH) in Wien in Zusammenarbeit mit der Universität Utrecht. Sie berücksichtigt den Zeitraum von Anfang 2019 bis Ende 2024. Europa folgt bei der Nutzung auf dem zweiten Platz.

Die in der Fachzeitschrift Science veröffentlichte Studie zeigt, dass es regional große Unterschiede bei der Akzeptanz von KI-geschriebenem Python-Code gibt. Am höchsten ist sie in den USA mit einem Anteil von 29 Prozent. Im Jahr 2022 lag der Wert dort noch bei rund fünf Prozent. Frankreich erreicht einen Anteil von 24 Prozent, gefolgt von Deutschland mit 23 Prozent und Indien mit 20 Prozent. Russland (15 %) und China (12 %) lagen am Ende der Studie hingegen noch deutlich zurück.

Die Datenbasis für die Studie wurde ebenfalls mithilfe von KI ermittelt. Dazu kam ein speziell trainiertes KI-Modell zum Einsatz, das mehr als 30 Millionen Python-Codeblöcke von rund 160.000 Entwicklern auf GitHub analysierte. Dabei prüfte das KI-Modell, ob die Python-Beiträge beispielsweise über ChatGPT oder GitHub Copilot erstellt wurden.

Je unerfahrener, desto mehr KI

Zwischen Frauen und Männern ließen sich in der Studie keine Unterschiede hinsichtlich der KI-Nutzung feststellen. Eine große Rolle spielt dagegen die Erfahrung. Während weniger erfahrene Programmiererinnen und Programmierer generative KI in 37 Prozent ihres Codes nutzten, betrug der Anteil bei der erfahrenen Klientel nur 27 Prozent. Geholfen hat es ersteren kaum, denn Produktivitätssteigerungen ließen sich nur bei letzteren feststellen. Die genaue Einordnung ist allerdings schwierig, weil Entwicklerinnen und Entwickler KI-Tools auf sehr unterschiedliche Weise verwenden.

Laut dem CSH hat der Einsatz generativer KI die Produktivität von Programmierern bis Ende 2024 um 3,6 Prozent gesteigert. Was nach wenig klingt, bedeute aber eine erhebliche Wertschöpfung. So würden in den USA jährlich schätzungsweise 637 Milliarden bis 1,06 Billionen US-Dollar in Programmieraufgaben investiert. Eine Produktivitätssteigerung von 3,6 Prozent entspreche daher einem zusätzlichen Wert zwischen 23 und 38 Milliarden US-Dollar pro Jahr. Die Studie schränkt jedoch ein, dass dieser Wert die Messungen von Python-Code verallgemeinert.

(who)

Die Entwickler der Open-Source-Suchmaschine Typesense haben Version 30.0 veröffentlicht. Das Update bringt grundlegende API-Änderungen für Synonyme und Kuratierungsregeln (Curation Rules) sowie neue Features wie Maximale Marginale Relevanz (Maximum Marginal Relevance, MMR) zur Diversifizierung von Suchergebnissen. Die bisher sammlungsspezifischen Synonyme und Kuratierungsregeln sind nun globale Ressourcen, die zwischen Sammlungen (Collections) geteilt werden können.

Administratoren müssen vor dem Update auf Version 30.0 einen Snapshot anlegen, da die neue Version eine automatische Migration durchführt. Dabei werden bestehende sammlungsspezifische Synonyme und Überschreibungen (Overrides) in globale Synonym-Sets und Kuratierungs-Sets überführt. Die API-Endpunkte ändern sich dabei von /collections/{collection}/synonyms/* zu /synonym_sets/* und von /collections/{collection}/overrides/* zu /curation_sets/*. Bestehende Suchanfragen funktionieren nach der Migration weiter, für Lese- und Schreibzugriffe auf die neuen Sets müssen Entwickler ihre Anwendungen jedoch an die neuen Endpunkte anpassen.

Diversifizierung mit MMR

Ein zentrales neues Feature ist die Diversifizierung von Suchergebnissen per MMR. Der Algorithmus diversifiziert die obersten 250 Treffer basierend auf einer vordefinierten Ähnlichkeitsmetrik (Similarity-Metric). Die MMR-Formel berücksichtigt dabei sowohl die Relevanz eines Dokuments zur Suchanfrage als auch dessen Ähnlichkeit zu bereits ausgewählten Ergebnissen. Der Lambda-Parameter steuert die Balance zwischen Relevanz und Diversität, wobei der Standardwert 0,5 beträgt. Administratoren können MMR über Curation Sets mit verschiedenen Ähnlichkeitsmetriken wie Jaccard für Arrays oder Vector Distance für Embeddings konfigurieren.

Die globale Struktur von Synonymen und Kuratierungsregeln reduziert Redundanzen, da diese Ressourcen nicht mehr für jede Sammlung separat angelegt werden müssen. Dies führt zu geringerem Speicherbedarf und potenziell besseren Cache-Hits bei der Wiederverwendung. Synonym-Sets unterstützen sowohl One-way- als auch Multi-way-Synonyme und können sprachspezifisch konfiguriert werden. In Kuratierungsregeln lassen sich nun auch Synonyme und Stemming verwenden, außerdem unterstützen sie MMR-Diversifizierung sowie dynamisches Filtern und Sortieren.

Erweiterte JOIN-Funktionen und Cloud-Integration

Version 30.0 erweitert die JOIN-Features deutlich. Der facet_by-Parameter unterstützt nun referenzierte Felder aus verknüpften Sammlungen, etwa facet_by=$Customers(product_price). Entwickler können mit include_fields die Anzahl verknüpfter Dokumente abrufen sowie Sortierung und Limits auf verknüpfte Felder anwenden. Neu ist auch die cascade_delete: false-Option, die verhindert, dass referenzierte Dokumente automatisch gelöscht werden, wenn alle Referenzen entfernt wurden. Diese Option erfordert async_reference: true im Schema.

Für die Suche in natürlicher Sprache (Natural Language Search) und Auto-Embedding unterstützt Typesense 30.0 nun OpenAI-Modelle von Azure sowie GCP Service Account Authentication. Dies ermöglicht die Integration in Cloud-Umgebungen mit Azure- und Google-Cloud-Modellen. Für die vektorbasierte Bildsuche stehen neue CLIP Multilingual Models zur Verfügung, die mehrsprachige Ähnlichkeitssuche (Similarity) in Bildern ermöglichen. Der neue IPv6-Support erlaubt Binding und Serving über IPv6-Adressen, was die Integration in moderne Dual-Stack- und IPv6-only-Netzwerke erleichtert.

Performance-Verbesserungen und Bugfixes

Zu den Verbesserungen gehören ein truncate-Parameter für String-Felder zur besseren Suche mit einem exakten Treffer (Exact Match) bei langen Strings sowie group_max_candidates für exakte found-Werte bei group_by-Operationen. Die Synonym-Matching-Logik wurde verbessert und sortiert Ergebnisse nun nach Match-Qualität. Ein Transliterator-Pool beschleunigt die Tokenisierung für kyrillische und chinesische Zeichen. Die Vereinigungssuche (Union Search) unterstützt nun group_by, pinned_hits und ein remove_duplicates-Flag.

Version 30.0 behebt zahlreiche Fehler, darunter Probleme mit Analytik-IDs bei unterschiedlichen filter_by– und analytics_tag-Parametern sowie feldspezifische Token-Separatoren im Highlighting. Pagination-Parameter werden nun korrekt an die Vereinigungssuche übergeben, und Deadlocks bei asynchronen Referenzen wurden beseitigt. Das Highlighting wurde so angepasst, dass bei Phrasensuchen (Phrase Queries) nur noch exakte Treffer markiert werden und bei der Suche in natürlicher Sprache die tatsächliche Abfrage (Query) hervorgehoben wird.

Details zur neuen Version finden sich in den Release Notes auf GitHub.

(fo)

Der schlanke Xfce-Desktop hat bereits zaghaft die Fühler Richtung Wayland ausgestreckt, allerdings bislang nur experimentell und eingeschränkt. Jetzt soll Xfce jedoch mit Anlauf zügig bessere Wayland-Unterstützung durch einen eigenen Compositor – xfwl4 – bekommen.

Das hat das Xfce-Team jetzt in einem Blog-Beitrag angekündigt. Offenbar konnte das Projekt nennenswerte Spenden aus der Community einsammeln und hat sich entschieden, daraus den bereits seit langer Zeit als Xfce-Kernentwickler aktiven Brian Tarricone zu finanzieren. Tarricone soll xfwl4 erstellen, „einen brandneuen Wayland-Compositor für Xfce“. Dafür werde ein signifikanter Teil der Projektspenden draufgehen, jedoch glaubt das Xfce-Team, dass das eine wichtige Investition in die Zukunft der Xfce-Desktop-Umgebung ist.

Xfce: Ziele für Wayland-Compositor

Xfwl4 soll dieselben Funktionen und Verhaltensweise wie xfwm4 liefern – so weit wie möglich, in Anbetracht der Unterschiede von X11 und Wayland. Als Ziel setzen sich die Entwickler, dass sich das Benutzen von xfwl4 genauso anfühlt wie xfwm4 unter X11. „Wir planen sogar, bestehende xfwm4-Konfigurationsdialoge und xfconf-Einstellungen wiederzuverwenden, um einen nahtlosen Übergang zu gewährleisten“, schreiben die Entwickler. Xfwl4 soll nicht auf bestehendem xfwm4-Code aufsetzen, sondern von Grund auf neu in Rust programmiert werden. Die Entwickler haben sich entschieden, den Compositor auf Basis der Bausteine von smithay zu programmieren.

Der erste Versuch, einen Wayland-Compositor für Xfce durch Anpassungen im vorhandenen xfwm4-Code umzusetzen, was in gleichzeitiger Unterstützung für X11 und Wayland münden würde, erwies sich als der falsche Weg. Der Aufbau von xfwm4 mache es schwierig, Window-Management-Verhalten in generische Schnittstellen zu gießen, die keine X11-Spezifikationen enthalten. Die Refaktorierung des Codes sei riskant, da dadurch neue Fehler in X11 einschleichen können – mit zwei parallelen Code-Basen zu arbeiten, erlaube schnellere Entwicklung und Experimentieren mit dem Wayland-Compositor, ohne Risiko, dabei xfwm4 kaputtzumachen. Außerdem würde die bestehende Codebasis die Entwickler dazu nötigen, C und wlroots zu nutzen, wo es doch bessere Alternativen gibt.

Brian Tarricone hat wlroots und smithay evaluiert und sich für letzteres als Basis für xfwl4 entschieden, da es den Großteil der offiziellen Wayland-Protokollerweiterungen sowie das wlroots- und einige KDE-Protokolle unterstützt. Außerdem bevorzugt Tarricone Rust vor C, das vereinfacht zudem, speicherbasierte Fehler zu vermeiden und damit die Wahrscheinlichkeit etwa für Abstürze zu verringern.

Weitere Aufgaben fällig

Es fallen einige Aufgaben an. Zunächst muss xfwl4 erst einmal funktional zu xfwm4 aufrücken. Dazu sind größere Änderungen am Session-Start-up nötig, da der Wayland-Compositor die Wurzel einer Session ist, anstatt xfce4-Session. Auch soll Unterstützung für das xdg-Session-Management kommen, zudem steht auch Support für XWayland auf der Roadmap. Ferner muss das Build-System dafür angepasst und aktualisiert werden. Tarricone hat bereits mit dem Projekt losgelegt. Erste Entwicklungs-Releases könnten bereits in der Jahresmitte erscheinen, hofft das Xfce-Team.

(dmk)