LibreOffice 25.8 ist freigegeben: Die freie Office-Suite bringt zahlreiche Verbesserungen und neue Funktionen für Writer, Calc, Impress, Draw sowie weitere Updates unter der Haube. Zu den wichtigsten Updates zählt die Integration weiterer PDF-2.0-Features, etwa eine AES-256-Verschlüsselung, Unterstützung für PDF/A-4 und der Export von Dokumenten als PDF 2.0.

Updates der einzelnen Programme

Im Textverarbeitungsprogramm Writer können Nutzer das Verhalten der Silbentrennung am Seitenende gezielter steuern. LibreOffice kann entweder Wörter auf der letzten Zeile einer Seite trennen oder stattdessen die betroffene Zeile komplett auf die folgende Seite verschieben. Außerdem können Anwender ihre Änderungen individuell aufzeichnen, wiederherstellen und nachvollziehen – bislang ließ sich das ausschließlich für einzelne Dokumente, aber nicht für Nutzer aktivieren. Ferner führt ein Ablehnen einer Änderung nicht mehr zum vollständigen Verschwinden des Vorschlags, sie finden sich ab sofort im Verlauf des Dokuments wieder.

In Calc wurden viele neue Tabellenfunktionen integriert, etwa SPALTENWAHL, ZEILENWAHL, ERWEITERN, WEGLASSEN und viele weitere. Für den Dialog ‚Textimport‘ gibt es jetzt Kontrollkästchen ‚Beim Import immer anzeigen‘, das standardmäßig gesetzt ist. Wer häufig mit gespeicherten Einstellungen CSV-Dateien in die Tabellenkalkulation importiert, kann den Dialog also ausschalten. Die zugehörigen Einstellungen finden sich unter ‚Filtereinstellungen bearbeiten‘ im Dialog ‚Datei öffnen‘.

Komplett neu ist der anwendungsweite Viewer-Modus. Er öffnet Dateien im schreibgeschützten Modus, den Nutzern stehen keinerlei Bearbeitungswerkzeuge zur Verfügung. Zudem haben die Entwickler wie bei jedem Release die Filter für den Import und Export verbessert, um die Kompatibilität mit Microsoft Office zu erhöhen. Dasselbe gilt für die Geschwindigkeit der Programme, große Dokumente sollen sich jetzt schneller laden lassen.

Ende des Supports

Allerdings fällt mit LibreOffice 25.8 auch der Support alter Betriebssysteme weg: Die Unterstützung für Windows 7 sowie 8 und 8.1 hat das Projekt entfernt und wird auch die 32-Bit-Windows-Builds nicht mehr weiterentwickeln. Außerdem wird das Release das letzte für macOS 10.15 sein, das kommende LibreOffice 26.2 wird wenigstens macOS 11 voraussetzen. Alle Änderungen der neuen Version führen die ausführlichen Release-Notes auf. Hier findet sich auch ein Ausblick auf noch experimentelle Features, darunter ein neuer ‚Makro-Manager‘ und ein neuer Modus der passwortbasierten ODF-Verschlüsselung.

(fo)

Es ist eine verzwickte Lage, in der sich das Gnome-Projekt befindet: Während der verbreitete Linux-Desktop technisch auf sicheren Beinen steht, sieht es finanziell weniger gut aus. In den vergangenen Jahren sind Spenden zurückgegangen, während die Kosten blieben. Trotz der angespannten finanziellen Lage stellte das Gnome-Projekt eine Hybrid-Konferenz auf die Beine. Beteiligte und Interessierte aus Übersee, Europa und weiteren Ländern trafen sich Ende Juli zur jährlichen Gnome-Konferenz GUADEC. Die fand auf Sparflamme in der Lombardei an der Universität in Brescia statt.

Die Vorträge präsentierten einerseits die Fortschritte der letzten Monate bei etwa beim Toolkit GTK, der Gnome-Shell und den für Flatpak wichtigen XDG-Desktop-Portals. Auch Themen wie Barrierefreiheit und Sicherheit sowie die Projektentwicklung, etwa um Maintainer-Burn-out zu verhindern, wurden verhandelt. Auf der während der GUADEC stattfindenden Jahreshauptversammlung der Gnome-Foundation zeigte sich, dass ein Konflikt aus dem vergangenen Jahr die Gnome-Mitglieder weiter beschäftigt.

Fortschritte bei der Barrierefreiheit

Red-Hat-Mitarbeiter Lukáš Tyrychtr präsentierte die jüngsten Fortschritte bei der Barrierefreiheit von Wayland und Gnome, insbesondere für Blinde. In der Vergangenheit gab es immer wieder Kritik in diesem Bereich. Zunächst erläuterte er den Anwesenden, wie ein Screenreader funktioniert und weshalb daraus spezielle Herausforderungen entstehen. Denn ein Screenreader beschränkt sich nicht auf Vorlesen von Text, sondern muss auch jegliche Keyboard-Events mitbekommen und manche sogar abfangen, sodass die weder beim Compositor, etwa „Mutter“ von der Gnome-Shell, noch bei der aktuell verwendeten Anwendung landen. Beispielsweise nutzen Blinde häufig eine Funktion, um den vorgelesenen Text abzubrechen.

Änderungen beim Accessibility-Dienst AT-SPI2 und die Einführung von GTK 4 mit eigenem Accessibility-Bus hatten dazu geführt, dass GTK-4-Apps unter Wayland nicht mit dem Screenreader Orca zusammenarbeiteten. Dieses Problem blieb mehrere Jahre ungelöst. Gemeinsam mit weiteren Red-Hat-Mitarbeitern entwarf Tyrychtr, der selbst blind ist, einen neuen Ansatz, bei dem Tasten-Events nicht mehr in der App abgefangen werden, sondern schon im Compositor. Da vorher viel Verkehr auf dem Accessibility-Bus unterwegs war, wird jetzt nur noch ein Event gesendet, wenn ein Screenreader auch lauscht. Außerdem wird der DBus-Name gegen eine Allowlist geprüft, damit nicht ein beliebiger Prozess als Keylogger fungieren kann. Die Änderungen sind in AT-SPI2 core ab Version 2.56 sowie im Screenreader Orca 48, Gnome-Shell 48 und KDEs Fenstermanager Kwin 6.4 umgesetzt.

Unabhängig davon wurden die visuellen Warnungen in der Gnome-Shell angepasst, damit diese konform mit dem European Accessibility Act (EAA) sind. Zudem sind nun auf dem Anmeldebildschirm die Barrierefreiheitsoptionen prominenter platziert.

Aus Red Hats Accessibility Team gab es noch weitere Vorträge, etwa einen Barrierefreiheit-Workshop für App- und Shell-Entwickler. Da Blinde fast alles mit der Tastatur erledigen, appellierte Lukáš Tyrychtr an die Anwesenden, die Tastatur-User-Experience dürfe nicht schlechter werden. In einer Diskussionsrunde bezeichnete Gnome-Entwickler Emmanuelle Bassi Accessibility als Zwilling von Usability. Barrierefreiheit sei wichtig, damit auch wirklich alle Zugang zum Computer haben.

Farbenfrohe Gnome-Shell

Nicht nur die Barrierefreiheit hat sich in der Gnome-Shell seit Version 48 verbessert, sondern auch die Unterstützung für HDR hat Einzug erhalten. Nach jahrelanger Überarbeitung des Quellcodes vom Compositor Mutter und weiteren Komponenten lässt sich HDR jetzt systemweit nutzen. Läuft Gnome im Wayland-Modus und ist ein HDR-fähiger Bildschirm angeschlossen, erscheint in den Einstellungen ein entsprechender Schalter. Die Arbeiten sind damit nicht abgeschlossen. Auf der Agenda bleiben Tone-Mapping (HDR-Inhalte auf den vom Bildschirm unterstützten Bereich anpassen), Unterstützung für ICC-Profile, Farbmanagement auch ohne HDR, den Nachtmodus reparieren und die Darstellung von HDR-Inhalten im SDR-Modus.

Das Gnome-Shell-Team hat zudem zahlreiche intern genutzte Wayland-Protokolle allgemein verfügbar gemacht (Upstreaming). Das betrifft Farbmanagement, Farb-Konversionen, besseres Timing bei der Aktualisierung von Bildschirminhalten, etwa um Sprünge und Ruckler zu vermeiden, sowie einen Workaround, um Memory Leaks in Mesa zu umschiffen. Aktuell laufen letzte Arbeiten an einem Session-Management-Protokoll, um Programme und deren Fenster nach einer Neuanmeldung wiederherzustellen. Der aktuelle Entwurf des vielfach gewünschten Features enthält noch zu viele Bugs. Das ist auch aufgrund der eingeschränkten Rechte von Wayland-Clients nicht einfach umzusetzen; Anwendungen haben keinen Zugriff auf die gesamte Bildschirmfläche. Der Compositor hingegen muss beim Start einer Anwendung eventuell lange warten, ob sie selbst die alten Fenster bereitstellt, etwa weil es dauert, ein großes Projekt zu öffnen, oder weil der Nutzer genehmigen muss, dass die vorherige Session wiederhergestellt wird.

Durch die weitgehende Entfernung von X11-Code aus der Gnome-Shell fällt auch deren Nested-Option weg, mit der eine Session in einem Fenster geöffnet werden konnte. Das war vorwiegend für Shell-Entwickler zum Testen interessant, eine Aufgabe, die jetzt vom Development Kit übernommen wird, einer eigenständigen GTK-4-Anwendung, welche als separater Prozess läuft. Die kleine Zielgruppe der Shell-Entwickler dürfte freuen, dass es nun einfacher ist, Entwicklungen zu testen. Da das Development Kit die gleiche API wie der Remote-Desktop verwendet, dürfte letzterer davon profitieren, dass jetzt mehr Gnome-Hacker diese API nutzen.

Mehr Sicherheit

Auch wenn es gern behauptet wird, sind Linux-Systeme per se nicht sicherer als andere Betriebssysteme. Allerdings macht die geringe Verbreitung auf Desktop-Systemen Linux für Anwender-Schadsoftware unattraktiv. Darauf wies auch die spanische Sicherheitsforscherin und Freie-Software-Aktivistin Paule de la Hoz hin. Grundsätzlich lauern unter Linux fast die gleichen Gefahren wie anderswo, etwa verdeckte Krypto-Miner, Ransomware und Phishing. Toolkits für Schadsoftware böten mittlerweile auch Payloads für Linux-Systeme an. Gegenüber c’t gab de la Hoz an, dass noch vor allem Server und IoT-Geräte Ziel der Angriffe seien. Sie warnte aber davor, das Risiko von Software aus fragwürdigen Quellen zu unterschätzen oder blindlings Befehle aus dem Internet per Copy & Paste auf dem eigenen System auszuführen.

Der Gnome-Entwickler Michael Catanzaro rief in seinem Vortrag dazu auf, nicht weiter die Sandbox von Flatpak zu unterlaufen. Die sei essentiell, da es mit unsicheren Programmiersprachen wie C nie möglich sei, sicheren Code zu schreiben. Rust sei zwar vom Design her sicherer, aber hier lauern Risiken in den Abhängigkeiten (Supply Chain Security). „Unsere Rust-Anwendungen haben viel zu viele Abhängigkeiten“, warnte Catanzaro mit Verweis auf mehrere Hundert Abhängigkeiten einzelner Apps zu Rusts Cargo-Repository.

Er lobte hingegen die Flatpak-Sandbox, da diese eine abgeschottete Umgebung bereitstelle. Dies entbinde zwar nicht davon, Abhängigkeiten oder Code zu aktualisieren und sei auch nicht absolut sicher. Doch um aus der Sandbox heraus Schaden anzurichten, bräuchte ein Angreifer mindestens zwei Exploits, einen um den Programmcode der App auszutricksen und einen weiteren, um aus der Sandbox auszubrechen. In der Praxis würden allerdings viele Anwendungen zu weitreichende Berechtigungen anfordern, etwa den Zugriff auf das gesamte Dateisystem, und somit die Sandbox nichtig machen.

Die Schuld sieht Catanzaro nicht allein bei den App-Entwicklern, sondern prangerte auch fehlende oder unzureichende XDG-Desktop-Portals an. Diese Portals sind eine Schnittstellensammlung, die Apps dynamisch Zugriff auf Ressourcen einräumt, wenn Nutzer der Freigabe zustimmen, etwa auf eine Webcam oder eine bestimmte Datei. Man müsse mehr bei der Entwicklung der Portale zusammenarbeiten und brauche einen Plan, wie man die größten ausstehenden Fragen löst. Außerdem fehle es an einer Strategie, wie man mit Anwendungen umgeht, die legitimerweise nicht in einer Sandbox laufen könnten.

Angesichts solcher Anforderungen ist es wenig verwunderlich, dass die Keynote von Mirko Brombin, Entwickler der innovativen Linux-Distribution Vanilla OS und des WINE-Tools Bottles, nicht auf besonders fruchtbaren Boden fiel. Brombin stellte cpak vor, ein neuer Weg für Linux, um Kommandozeilentools, Dienste und Anwendungen zu paketieren. Dabei baut cpak auf Standards der Open Container Initiative (OCI) auf, also den von Docker genutzten Container-Images. Diese werden mit einer cpak.json-Datei kombiniert, welche unter anderem die benötigten Rechte und Ressourcen definiert. Laut Brombin ist cpak primär für Embedded-Geräte entwickelt worden und positioniert sich zwischen Docker und Flatpak beziehungsweise Snap. Im Unterschied zu diesen benötige cpak keine Hintergrunddienste, sondern bestehe nur aus einer einzigen eigenständigen Binary (cpak), welche das jeweilige cpak-Bundle ausführe. Viele kritische Rückfragen aus dem Plenum bezogen sich auf Sicherheitsaspekte. Zwar sieht cpak eine Trennung zwischen cpak-Anwendungen und Host-System vor, aber mehrere Anwesende bemängelten, dass diese schon im Aufbau ungenügend sei oder man sie anderweitig unterlaufen könne.

Schuld und Scham erweisen sich in Gesellschaften als wirksames Mittel, um dafür zu sorgen, dass Individuen Teamplayer bleiben. Diese emotionalen Fähigkeiten lassen Menschen Handlungen bereuen und machen sie kooperativer. In einer im Journal of the Royal Society Interface veröffentlichten Studie haben Forschende jetzt getestet, ob sich derselbe Ansatz auch auf Künstliche Intelligenz (KI) übertragen ließe. Dabei haben sie festgestellt, dass dies unter den richtigen Umständen möglich sein könnte.

Die kooperative KI?

KI wird zunehmend leistungsfähiger – gleichzeitig ist deren Verwendung aus dem Leben vieler Menschen nicht mehr wegzudenken. Eine Kernherausforderung liegt dabei darin, KI-Systeme dazu zu bringen, sich gemäß menschlicher Präferenzen und ethischer Normen zu verhalten. Dass sich auch Menschen untereinander nicht unbedingt einig über diese Dinge sind, macht es nicht leichter.

Es gibt bereits erste Forschungsgruppen, die sich der Maschinen-Psychologie widmen und die Fähigkeiten und das Verhalten von Algorithmen untersuchen. Jetzt deuten neue Ergebnisse aus der Spieltheorie darauf hin, dass Modelle kooperativer werden, wenn man ihnen Schuldgefühle vermittelt.

Gefangenendilemma mit Software-Agenten

Die Tests wurden mit einfachen Software-Agenten (ohne KI) durchgeführt, die eine Version eines klassischen spieltheoretischen Tests namens „Gefangenendilemma“ spielen mussten: ein Szenario, in dem Zusammenarbeit für alle Beteiligten den größten Vorteil bringt, während individuelles „Verraten“ kurzfristig lohnender erscheint.

In jeder Runde müssen die Spieler entscheiden, ob sie zusammenarbeiten oder den anderen verraten. Kooperieren beide, bekommen sie jeweils eine Belohnung. Entscheiden sich jedoch beide dagegen, also handeln egoistisch, erhalten sie beide eine Strafe. Wenn aber nur einer kooperiert und der andere egoistisch handelt, profitiert Letzterer besonders stark. Der kooperative Spieler erhält hingegen die größte Strafe.

Soziale und nicht-soziale Schuld

Außerdem modellierten die Forschenden zwei Arten von Schuld: soziale und nicht-soziale Schuld. Im ersten Fall fühlten sich die Agenten dann schuldig, wenn sie wussten, dass sich ihr Gegner ebenfalls schuldig fühlen würde. Im zweiten Fall fühlten sie sich unabhängig vom Gegner schuldig.

Um den Agenten ein Schuldgefühl zu vermitteln, haben die Forschenden sie mit einem Zähler für unkooperative Handlungen ausgestattet. Überschritt der Zähler den definierten Schwellenwert, reagierten die Agenten, indem sie einen Teil ihrer Punkte aufgaben. Das führte letztlich wieder zu mehr Kooperation.

Während des Spiels sind Gruppen von Agenten mit leicht unterschiedlich programmierten Schuld-Strategien wiederholt gegeneinander angetreten. Das Ergebnis: Empfundene soziale Schuld erwies sich als besonders wirksam, um die Kooperation der Agenten zu fördern.

Wird KI jetzt kooperativer?

„Der Bau ethischer Maschinen könnte ihnen die emotionale Fähigkeit verleihen, sich selbst zu bewerten und ihre Handlungen zu bereuen“, schreiben die Autorinnen und Autoren des Papers. Wenn KI-Agenten also mit der Fähigkeit, Schuld zu fühlen, ausgestattet werden, könnten sie sich Fehlverhalten eingestehen und sogar Maßnahmen zur „Wiedergutmachung“ ergreifen – so zumindest wird das im Paper nahegelegt.

Es ist jedoch fraglich, inwiefern sich diese vereinfachten Simulationen mit Software-Agenten auf die deutlich komplexeren, auf großen Sprachmodellen basierenden KI-Agenten übertragen lassen. Demnach ist unklar, ob sich das Verhalten von KI-Systemen auf ähnliche Weise beeinflussen ließe. Dennoch liefern die Ergebnisse spannende Hinweise darauf, wie die Ausstattung von KI-Agenten mit Emotionen dazu beitragen könnte, ihre Entscheidungsfindung zu moderieren und zu lenken.

Dieser Beitrag ist zuerst auf t3n.de erschienen.

(jle)