Connect with us

Entwicklung & Code

Python Software Foundation: Chancengleichheit wichtiger als US-Fördergelder


Die Python Software Foundation (PSF) hat einen Anfang des Jahres gestellten Antrag auf Fördergelder der US-Regierung zurückgezogen.Konkret hatte die PSF bei der National Science Foundation der US-Regierung 1,5 Millionen US-Dollar Fördergelder nach dem Safety, Security, and Privacy of Open-Source Ecosystems (Safe-OSE) beantragt. Das Programm soll die Sicherheit in Open-Source-Ökosystemen stärken und gegen Angriffe schützen.

Weiterlesen nach der Anzeige

Nach einigen Monaten wurde der Antrag offenbar für die Förderung empfohlen. Laut des PSF-Blogs sind nur 36 Prozent, also gut ein Drittel, aller Erstanträge erfolgreich.

Die anfängliche Freude wich allerdings schnell ernsten Bedenken, als die Stiftung die Bedingungen für die Förderung zugesandt bekam.

Konkret fand sich darin die Aussage, dass geförderte Organisationen „keine Programme durchführen und während der Laufzeit dieser finanziellen Unterstützung auch keine Programme durchführen werden, die DEI oder eine diskriminierende Gleichstellungsideologie fördern oder unterstützen, die gegen die Bundesgesetze gegen Diskriminierung verstößt“.

DEI steht für Diversity, Equity and Inclusion, also Vielfalt, Gerechtigkeit und Inklusion. Es geht vor allem darum, unterrepräsentierte Gruppen zu fördern. Kurz nach dem Start seiner zweiten Amtszeit hat US-Präsident Donald Trump in seinem Kampf gegen „Wokeness“ die DEI-Programme massiv eingeschränkt. In der Ankündigung auf der offiziellen Seite des Weißen Hauses ist von „illegalen und unmoralischen Diskriminierungsprogrammen“ die Rede, die von der Biden-Administration erzwungen worden seien.

Die Bedingungen für die Förderungen inklusive der Anti-DEI-Vorgaben gelten nicht nur für die Security-Bemühungen, sondern für die gesamte Arbeit der geförderten Organisationen.

Weiterlesen nach der Anzeige

Die Python Software Foundation hat die Chancengleichheit in ihrem offiziellen Mission-Statement verankert. Darin heißt es „Die Mission der Python Software Foundation besteht darin, die Programmiersprache Python zu fördern, zu schützen und weiterzuentwickeln sowie das Wachstum einer vielfältigen und internationalen Gemeinschaft von Python-Programmierern zu unterstützen und zu erleichtern.“




(Bild: Python Software Foundation)

Der Autor der Programmiersprache Python Guido van Rossum hat am 6. März 2001 die Python Software Foundation als US-amerikanischen Non-Profit-Organistion gegründet.

Die PSF kümmert sich um die Weiterentwicklung von Python und verwaltet zudem den Paketmanager Python Package Index (PyPI). Letzterer ist ebenso wie der JavaScript-Paketmanager npm immer wieder Ziel von Supply-Chain-Angriffen.

Laut des Blogbeitrags hat die PSF keinen Weg gefunden, die Fördergelder zu erhalten und gleichzeitig an der Mission festzuhalten. Da sie zu dem Schluss gekommen sei, dass sie die Gelder nicht annehmen kann, ohne ihre eigene Mission zu verraten.

Die PSF ist nicht die erste Organisation, die ihren Fördergeldantrag wegen der Bedingungen zurückzieht. Im Juni war die in Deutschland wenig bekannte Organisation The Carpentries denselben Schritt gegangen. The Carpentries bietet Trainings für Softwareentwicklung und Data Science an, und stellt alle Schulungsmaterialien unter der Creative-Commons-Lizenz bereit.

Die Gelder der National Science Foundation wären nicht die erste finanzielle Unterstützung für die Python Software Foundation zur Förderung der Sicherheit gewesen. Im Juni 2022 hatte die Open Source Security Foundation (OpenSSF), die unter dem Dach der Linux Foundation steht, die PSF mit 400.000 US-Dollar unterstützt.


(rme)



Source link

Entwicklung & Code

Firefox: Neue Erweiterungen müssen Datenerhebung offenlegen


close notice

This article is also available in
English.

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

Ab dem 3. November 2025 müssen Entwickler neuer Firefox-Erweiterungen in der Manifest-Datei deklarieren, welche persönlichen Nutzerdaten ihre Software erhebt oder überträgt. Die Angaben müssen im Schlüssel browser_specific_settings.gecko.data_collection_permissions der manifest.json hinterlegt werden.

Weiterlesen nach der Anzeige

Zunächst gilt die Regelung ausschließlich für neu eingereichte Erweiterungen. Updates bestehender Add-ons sind vorerst von der Pflicht ausgenommen. Ferner müssen Extensions, die keine Daten sammeln, dies explizit durch den Eintrag „none required“ deklarieren. Sobald eine Erweiterung erstmals die neuen Schlüssel verwendet, sind diese für alle künftigen Versionen verpflichtend.

Firefox zeigt die vom Entwickler deklarierten Informationen künftig bereits beim Installationsdialog an – zusammen mit den angeforderten Berechtigungen. Zusätzlich werden die Angaben auf der Detailseite der jeweiligen Erweiterung auf addons.mozilla.org sowie im Bereich „Berechtigungen und Daten“ der about:addons-Seite in Firefox sichtbar. Damit setzt Mozilla die im April angekündigte Standardisierung der Datenerhebungs-Dialoge um.

Für Erweiterungen, die noch ältere Firefox-Versionen vor 140 (Desktop) beziehungsweise 142 (Android) unterstützen, gelten Übergangsregelungen: Entwickler müssen Nutzern in diesem Fall weiterhin unmittelbar nach der Installation eine eigene Möglichkeit zur Kontrolle der Datenerhebung anbieten.

Extensions, die die erforderlichen Deklarationen nicht korrekt setzen, werden künftig nicht mehr zur Signierung auf addons.mozilla.org zugelassen. Das System weist Entwickler in diesem Fall mit einer Fehlermeldung auf das Problem hin. Mozilla will so sicherstellen, dass Nutzer vor der Installation transparent über den Umgang mit ihren Daten informiert werden.

Die im Extension Workshop veröffentlichte Dokumentation zeigt Entwicklern, welche konkreten Datentypen sie deklarieren müssen. Hierunter fallen unter anderem Browserverlauf, Standortdaten oder persönliche Kommunikation.

Weiterlesen nach der Anzeige

In der ersten Jahreshälfte 2026 plant Mozilla, die Anforderungen auf sämtliche Firefox-Erweiterungen auszuweiten – also auch auf bestehende Add-ons. Details zu dieser Umstellung sowie zusätzliche Werkzeuge für Entwickler und Nutzer will das Unternehmen rechtzeitig über den Add-ons-Blog bekanntgeben. Die schrittweise Einführung soll Entwicklern Zeit geben, ihre Extensions entsprechend anzupassen. Alle Informationen finden sich im Blogeintrag von Mozilla.


(fo)



Source link

Weiterlesen

Entwicklung & Code

Electron-Nerv: App zeigt, welche Programme mit macOS Tahoe Probleme machen


close notice

This article is also available in
English.

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

Spätestens seit dem offiziellen Release von macOS 26 alias Tahoe ist klar, dass manche App, die mit dem populären Electron-Framework erstellt wurde, massive Probleme unter dem neuen Mac-Betriebssystem bereiten können. Der Grund ist simpel: Werden ältere Versionen des Cross-Platform-Systems eingesetzt und gleichzeitig ein bestimmter privater AppKit-API-Override verwendet, bremst eine einzige solche Anwendung das komplette System aus. Warum dies nicht schon während der monatelangen Betaphase von Tahoe auffiel, ist nach wie vor unklar. Abhilfe für das Problem können nur die Entwickler solcher Apps selbst liefern, indem sie das Framework intern aktualisieren. Um festzustellen, ob man betroffen ist, gibt es nun ein neues Werkzeug.

Weiterlesen nach der Anzeige

Die App stammt von Craig Hockenberry, Macher des Softwareanbieters und Designstudios Icon Factory. Mit dem Tahoe Electron Detector kann man prüfen, ob Electron-basierte Apps bereits mit dem notwendigen Bugfix ausgerüstet wurden oder nicht. Die Anwendung basiert auf einem Script von Entwickler Tomas Kafka, das um einige Xcode-Spezialitäten entschlackt wurde. Heraus kam ein AppleScript-Applet, das nach Freigabe das System auf Electron-Anwendungen scannt und dann mitteilt, ob diese betroffen sind oder nicht.

Anschließend kann man prüfen, ob die jeweilige App bereits ein Electron-Update erhalten hat oder aber nicht – sollte das nicht der Fall sein, muss man mit der Anwendung vorsichtig umgehen und sie gegebenenfalls deinstallieren (oder man weiß zumindest, warum der Mac derart lahmt, wenn sie läuft). Der Detektor hilft hoffentlich auch dabei, bei den entsprechenden Entwicklern Druck zu machen.

Tatsächlich waren zumindest zwischenzeitlich diverse bekannte Apps betroffen, die Electron nutzen – von Dropbox über GitHub Desktop bis hin zu Slack. Weiterhin gibt es mittlerweile auch eine eigene Website auf GitHub, die sich nur dem „Shaming“ von Entwicklern widmet, die das Framework in ihrer App noch nicht aktualisiert haben. Bislang noch nicht aktualisiert wurden laut der Seite unter anderem die Apps von Superhuman, Loom, Logi Options+ oder Notion (Mail und Calendar).

Die betroffenen Apps verwenden einen Override-Hack einer privaten AppKit-API, um bestimmte (eigentlich eher sinnfreie) Fenstereffekte zu generieren. Das kollidiert wiederum mit macOS 26 respektive dessen Implementierung des WindowServer-Tasks, der für die macOS-Fensterdarstellung zuständig ist, heißt es im GitHub-Forum des Electron-Projekts. Resultat: Eine Electron-App generiert Last, die unter anderem zu verlangsamtem Scrollen führt. Mit mehreren Apps wird es noch schlimmer.

Weiterlesen nach der Anzeige


(bsc)



Source link

Weiterlesen

Entwicklung & Code

Rust Coreutils 0.3.0: Bis zu 3,7-mal schneller als GNU-Tools


close notice

This article is also available in
English.

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

Das Projekt Rust Coreutils hat Version 0.3.0 veröffentlicht und liefert damit erhebliche Geschwindigkeitsverbesserungen gegenüber den traditionellen GNU Core Utilities. Nach Angaben der Entwickler übertrifft das sort-Kommando die GNU-Variante beim regulären Sortieren um den Faktor 3,72. Auch andere Werkzeuge wurden deutlich beschleunigt: expand arbeitet 1,8-mal schneller, nl ist 1,57-mal flotter unterwegs.

Weiterlesen nach der Anzeige

Die Rust Coreutils sind eine Neuimplementierung der über 100 klassischen Unix-Kommandozeilenprogramme wie ls, cp oder rm, die ursprünglich in C geschrieben wurden. Einige Nutzer sind bereits umgestiegen: Canonical setzt die Rust-Tools in Ubuntu 25.10 standardmäßig ein. Die Entwickler der Rust-Coreutils streben eine hundertprozentige Kompatibilität mit GNU an, damit bestehende Skripte der Anwender ohne Anpassungen weiter funktionieren.

Für die kontinuierliche Überwachung der Performance-Entwicklung haben die Entwickler die Plattform CodSpeed in ihre CI/CD-Pipeline integriert. Das System erkennt automatisch Performance-Verschlechterungen und stellt sicher, dass Optimierungen auch langfristig erhalten bleiben. Die Benchmarks decken mittlerweile über 15 zentrale Werkzeuge ab, darunter sort, ls, uniq, du und base64. Auch base64 (1,2-mal schneller), unexpand (1,5-mal schneller) und uniq -c (1,13-mal schneller) profitieren von den Anpassungen.

Ein wesentlicher Schwerpunkt der Version 0.3.0 liegt auf der verbesserten Sicherheit. Die Entwickler haben für die Werkzeuge rm, du, chmod und chgrp eine sichere Directory-Traversal-Implementierung umgesetzt, die auf den Systemaufrufen openat und unlinkat basiert. Statt unsicherer libc-Aufrufe kommt dabei das nix-Crate zum Einsatz, das speichersichere Abstraktionen bereitstellt – einer der Hauptvorteile von Rust gegenüber C.

Bei der Kompatibilität mit der GNU-Test-Suite erreichen die Rust-Coreutils aktuell 532 bestandene Tests – eine Quote von 83,91 Prozent. Gegenüber Version 0.1 (damals: 87,06 Prozent) scheint das zunächst ein Rückschritt zu sein. Die Entwickler erklären dies jedoch mit dem Upgrade der Referenzimplementierung von GNU Coreutils 9.7 auf 9.8, wodurch sich Testerwartungen bei bestehenden Prüfungen änderten und 16 neue Tests hinzukamen. Somit stieg die Gesamtzahl der Tests von 618 auf 634. Von den neuen Tests schlagen 68 fehl, 33 werden übersprungen und einer führt zu einem Fehler.

Weiterlesen nach der Anzeige

Für Entwickler bringt das Update ebenfalls Verbesserungen: Die Generierung von Dokumentation und Shell-Completions wurde aus den Binaries ausgelagert, was die Build-Zeiten verkürzt. Die CI-Pipeline kompiliert Benchmarks nun parallel, und das Makefile unterstützt verschiedene Build-Konfigurationen besser.

Die aktuelle Version steht auf der Projektwebsite zum Download bereit. Neben den genannten Verbesserungen wurden zahlreiche weitere Details optimiert, darunter die Unicode- und Non-UTF8-Pfadunterstützung sowie das Fehlerhandling quer durch verschiedene Utilities. Weitere Informationen finden sich in den Release Notes auf GitHub.


(fo)



Source link

Weiterlesen

Beliebt