Lese-Ansicht

Herstellerunabhängigkeit, Transparenz und 24×7-Support: credativ stellt sich vor

In unserem neuen Mitgliederinterview stellt sich die credativ GmbH vor: Geschäftsführer David Brauner spricht über digitale Souveränität als fundamentalen Wert, die Bedeutung von Herstellerunabhängigkeit und transparentem Quellcode sowie die Rückkehr zur OSBA. Nach dem Management-Buyout startet credativ mit voller Energie in die Open-Source-Zukunft und möchte seine langjährige Expertise in die gemeinsamen Arbeitsgruppen einbringen.

Quelle

  •  

Adfinis als Consulting Partner of the Year ausgezeichnet

Open-Source-Anbieter Adfinis wurde auf dem IONOS Summit 2025 als Consulting Partner of the Year ausgezeichnet. Der Preis wurde im Rahmen der IONOS Partner Awards am 4. November in Berlin verliehen. Die Auszeichnung würdigt den Erfolg von Adfinis bei der Bereitstellung robuster und sicherer Cloud-Native-Plattformen in Partnerschaft mit IONOS.

Quelle

  •  

Business meets Gaming: Hochmobiles Linux-Business-Ultrabook mit Ryzen AI 9 und GeForce-RTX-Grafik

Das brandneue InfinityBook Max 15 erweitert die beliebte InfinityBook-Pro-Reihe um grafisch leistungsstarke und gleichzeitig sehr dünne, leichte und mobile Businessnotebooks für Work & Play. Ausgestattet mit AMD Ryzen AI Prozessoren und NVIDIA GeForce RTX Grafikkarten der schnellen Mittelklasse, bietet das InfinityBook Max 15 starke Rechenpower für Softwareentwicklung, anspruchsvolle Mediengestaltung und Gaming. Kombiniert mit bis zu massiven 128 GB Arbeitsspeicher und einem maximal […]

Quelle

  •  

Red Hat führt Confirmed Sovereign Support für die Europäische Union ein

Um der kritischen strategischen Notwendigkeit der digitalen Souveränität in Europa gerecht zu werden, kündigt Red Hat, der weltweit führende Anbieter von Open-Source-Lösungen, „Red Hat Confirmed Sovereign Support“ für die 27 Mitgliedstaaten der Europäischen Union an. Dieses neue Support-Angebot wurde speziell entwickelt, um dedizierten, von EU-Bürgern gestützten technischen Support innerhalb der EU für Software-Subskriptionen von Red Hat bereitzustellen. Damit soll ein neues Maß an überprüfbarer lokaler Kontrolle über kritische IT-Vorgänge ermöglicht werden.

Quelle

  •  

Linux-News der Woche: AMD wird mehr Open-Source, Farb-API und neue ISOs

Neue ISOs für EndeavourOS und CachyOS stehen zum Download bereit. AMD nutzt für seine Radeon Software Mesa als Basis. Die Online-Office-Suite Collabora bringt eine neue Offline-App. Valve hat in Zusammenarbeit mit AMD die Color-Pipeline-API finalisiert, welche für bessere Hardwarenutzung und einheitliche Farbdarstellung sorgt.

  •  

Docker mit nftables ausprobiert

Die Docker Engine 29 unter Linux unterstützt erstmals Firewalls auf nftables-Basis. Die Funktion ist explizit noch experimentell, aber wegen der zunehmenden Probleme mit dem veralteten iptables-Backend geht für Docker langfristig kein Weg daran vorbei. Also habe ich mir gedacht, probiere ich das Feature einfach einmal aus. Mein Testkandidat war Fedora 43 (eine reale Installation auf einem x86-Mini-PC sowie eine virtuelle Maschine unter ARM).

Inbetriebnahme

Das nft-Backend aktivieren Sie mit der folgenden Einstellung in der Datei /etc/docker/daemon.json:

{ 
  "firewall-backend": "nftables"
}

Diese Datei existiert normalerweise nicht, muss also erstellt werden. Die Syntax ist hier zusammengefasst.

Die Docker-Dokumentation weist darauf hin, dass Sie außerdem IP-Forwarding erlauben müssen. Alternativ können Sie Docker anweisen, auf Forwarding zu verzichten ("ip-forward": false in daemon.json) — aber dann funktionieren grundlegende Netzwerkfunktionen nicht.

# Datei /etc/sysctl.d/99-docker.conf
net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1

sysctl --system aktiviert die Änderungen ohne Reboot.

Die Docker-Dokumentation warnt allerdings, dass dieses Forwarding je nach Anwendung zu weitreichend sein und Sicherheitsprobleme verursachen kann. Gegebenenfalls müssen Sie das Forwarding durch weitere Firewall-Regeln wieder einschränken. Die Dokumentation gibt ein Beispiel, um auf Rechnern mit firewalld unerwünschtes Forwarding zwischen eth0 und eth1 zu unterbinden. Alles in allem wirkt der Umgang mit dem Forwarding noch nicht ganz ausgegoren.

Praktische Erfahrungen

Mit diesen Einstellungen lässt sich die Docker Engine prinzipiell starten (systemctl restart docker, Kontrolle mit docker version oder systemctl status docker). Welches Firewall-Backend zum Einsatz kommt, verrät docker info:

docker info | grep 'Firewall Backend'

 Firewall Backend: nftables+firewalld

Ich habe dann ein kleines Compose-Setup bestehend aus MariaDB und WordPress gestartet. Soweit problemlos:

docker compose up -d

  [+] Running 2/2
  Container wordpress-sample-wordpress-1  Running   0.0s 
  Container wordpress-sample-db-1         Running   0.0s 
  Attaching to db-1, wordpress-1


docker compose ps

  NAME                           IMAGE             ...   PORTS
  wordpress-sample-db-1          mariadb:latest          3306/tcp
  wordpress-sample-wordpress-1   wordpress:latest        127.0.0.1:8082->80/tcp

Firewall-Regeln

Auch wenn ich kein nft-Experte bin, wollte ich mir zumindest einen Überblick verschaffen, wie die Regeln hinter den Kulissen funktionieren und welchen Umfang sie haben:

# ohne Docker (nur firewalld)
nft list tables

  table inet firewalld

nft list ruleset | wc -l

    374

# nach Start der Docker Engine (keine laufenden Container)
nft list tables

  table inet firewalld
  table ip docker-bridges
  table ip6 docker-bridges

nft list ruleset | wc -l

    736

Im Prinzip richtet Docker also zwei Regeltabellen docker-bridges ein, je eine für IPv4 und für IPv6. Die zentralen Regeln für IPv4 sehen so aus (hier etwas kompakter als üblich formatiert):

nft list table ip docker-bridges

table ip docker-bridges {
  map filter-forward-in-jumps {
    type ifname : verdict
      elements = { "docker0" : jump filter-forward-in__docker0 }
  }
  map filter-forward-out-jumps {
    type ifname : verdict
      elements = { "docker0" : jump filter-forward-out__docker0 }
  }
  map nat-postrouting-in-jumps {
    type ifname : verdict
      elements = { "docker0" : jump nat-postrouting-in__docker0 }
  }
  map nat-postrouting-out-jumps {
    type ifname : verdict
      elements = { "docker0" : jump nat-postrouting-out__docker0 }
  }
  chain filter-FORWARD {
    type filter hook forward priority filter; policy accept;
    oifname vmap @filter-forward-in-jumps
      iifname vmap @filter-forward-out-jumps
  }
  chain nat-OUTPUT {
    type nat hook output priority dstnat; policy accept;
    ip daddr != 127.0.0.0/8 fib daddr type local counter packets 0 bytes 0 jump nat-prerouting-and-output
  }
  chain nat-POSTROUTING {
    type nat hook postrouting priority srcnat; policy accept;
    iifname vmap @nat-postrouting-out-jumps
      oifname vmap @nat-postrouting-in-jumps
  }
  chain nat-PREROUTING {
    type nat hook prerouting priority dstnat; policy accept;
    fib daddr type local counter packets 0 bytes 0 jump nat-prerouting-and-output
  }
  chain nat-prerouting-and-output {
  }
  chain raw-PREROUTING {
    type filter hook prerouting priority raw; policy accept;
  }
  chain filter-forward-in__docker0 {
    ct state established,related counter packets 0 bytes 0 accept
      iifname "docker0" counter packets 0 bytes 0 accept comment "ICC"
      counter packets 0 bytes 0 drop comment "UNPUBLISHED PORT DROP"
  }
  chain filter-forward-out__docker0 {
    ct state established,related counter packets 0 bytes 0 accept
      counter packets 0 bytes 0 accept comment "OUTGOING"
  }
  chain nat-postrouting-in__docker0 {
  }
  chain nat-postrouting-out__docker0 {
    oifname != "docker0" ip saddr 172.17.0.0/16 counter packets 0 bytes 0 masquerade comment "MASQUERADE"
  }
}

Diese Tabelle richtet NAT-Hooks für Pre- und Postrouting ein, die über Verdict-Maps (Datenstrukturen zur Zuordnung von Aktionen) später dynamisch auf bridge-spezifische Chains weiterleiten können. Für das Standard-Docker-Bridge-Netzwerk (docker0, 172.17.0.0/16) sind bereits Filter-Chains vorbereitet, die etablierte Verbindungen akzeptieren, Inter-Container-Kommunikation erlauben würden und nicht veröffentlichte Ports blocken, sowie eine Masquerading-Regel für ausgehenden Traffic von Containern, damit diese über die Host-IP auf das Internet zugreifen können. Die meisten Chains sind vorerst leer oder inaktiv (nat-prerouting-and-output, raw-PREROUTING, nat-postrouting-in__docker0). Wenn Docker Container ausführt, interne Netzwerk bildet etc., kommen weitere Regeln innerhalb von ip docker-bridges hinzu.

Zusammenspiel mit libvirt/virt-manager

Vor ca. einem halben Jahr bin ich das erste Mal über das nicht mehr funktionierende Zusammenspiel von Docker mit iptables und libvirt mit nftables gestolpert (siehe hier). Zumindest bei meinen oberflächlichen Tests klappt das jetzt: libvirt muss nicht auf iptables zurückgestellt werden sondern kann bei der Defaulteinstellung nftables bleiben. Dafür muss Docker wie in diesem Beitrag beschrieben ebenfalls auf nftables umgestellt werden. Nach einem Neustart (erforderlich, damit alte iptables-Docker-Regeln garantiert entfernt werden!) kooperieren Docker und libvirt so wie sie sollen. libvirt erzeugt für seine Netzwerkfunktionen zwei weitere Regeltabellen:

nft list tables

table inet firewalld
table ip docker-bridges
table ip6 docker-bridges
table ip libvirt_network
table ip6 libvirt_network

Einschränkungen und Fazit

  • Die Docker-Dokumentation weist darauf hin, dass das nftables-Backend noch keine Overlay-Regeln erstellt, die für den Betrieb von Docker Swarm notwendig sind. Docker Swarm funktioniert also aktuell nicht, wenn Sie Docker auf nftables umstellen. Für mich ist das kein Problem, weil ich Docker Swarm ohnedies nicht brauche.
  • Ich habe meine Tests nur unter Fedora durchgeführt. (Meine Zeit ist auch endlich.) Es ist anzunehmen, dass RHEL plus Klone analog funktionieren, aber das bleibt abzuwarten. Debian + Ubuntu wären auch zu testen …

  • Ich habe nur einfache compose-Setups ausprobiert. Natürlich kein produktiver Einsatz.

  • Meine nftables- und Firewall-Kenntnisse reichen nicht aus, um eventuelle Sicherheitsimplikationen zu beurteilen, die sich aus der Umstellung von iptables auf nftables ergeben.

Losgelöst von den Docker-spezifischen Problemen zeigt dieser Blog-Beitrag auch, dass das Zusammenspiel mehrerer Programme (firewalld, Docker, libvirt, fail2ban, sonstige Container- und Virtualisierungssysteme), die jeweils ihre eigenen Firewall-Regeln benötigen, alles andere als trivial ist. Es würde mich nicht überraschen, wenn es in naher Zukunft noch mehr unangenehme Überraschungen gäbe, dass also der gleichzeitige Betrieb der Programme A und B zu unerwarteten Sicherheitsproblemen führt. Warten wir es ab …

Insofern ist die Empfehlung, beim produktiven Einsatz von Docker auf dem Host möglichst keine anderen Programme auszuführen, nachvollziehbar. Im Prinzip ist das Konzept ja nicht neu — jeder Dienst (Web, Datenbank, Mail usw.) bekommt möglichst seinen eigenen Server bzw. seine eigene Cloud-Instanz. Für große Firmen mit entsprechender Server-Infrastruktur sollte dies ohnedies selbstverständlich sein. Bei kleineren Server-Installationen ist die Auftrennung aber unbequem und teuer.

Quellen/Links

  •  

Linux Coffee Talk 11/2025

Der Linux Coffee Talk ist das entspannte Monatsformat bei fosstopia. Hier fassen wir die spannendsten Ereignisse und Entwicklungen der letzten Wochen für Euch zusammen und ordnen es ein. Also schnappt euch einen Kaffee, Tee oder Euer Lieblingsgetränk, macht es euch gemütlich und lasst uns den November Revue passieren. In dieser Ausgabe blicken wir auf die […]

Der Beitrag Linux Coffee Talk 11/2025 erschien zuerst auf fosstopia.

  •  

Podcast: Linux Coffee Talk 11/2025

Der Linux Coffee Talk ist unser entspanntes Monatsformat bei fosstopia. Hier fassen wir die spannendsten Ereignisse und Entwicklungen der letzten Wochen für Euch zusammen und ordnen sie bestmöglich ein. Also schnappt euch einen Kaffee, Tee oder Euer Lieblingsgetränk, macht es euch gemütlich und lasst uns den November Revue passieren.

Der Beitrag Podcast: Linux Coffee Talk 11/2025 erschien zuerst auf fosstopia.

  •  

Raspberry Pi OS aktualisiert

Raspberry Pi OS ist ein Erhaltungsrelease mit wenigen neuen Funktionen. So wurde dem Control-Panel die Steuerung von HiDPi-Displays spendiert und die Firmware aktualisisert

  •  

Raspberry Pi Imager 2.0

Die Raspberry Pi Foundation hat vor einigen Tagen eine komplett reorganisierte Implementierung Ihres Raspberry Pi OS Imager vorgestellt. Das Programm hilft dabei, Raspberry Pi OS oder andere Distributionen auf SD-Karten für den Raspberry Pi zu schreiben. Mit der vorigen Version hatte ich zuletzt Ärger. Aufgrund einer Unachtsamkeit habe ich Raspberry Pi OS über die Windows-Installation auf der zweite SSD meines Mini-PCs geschrieben. Führt Version 2.0 ebenso leicht in die Irre?

Installation unter Linux

Der Raspberry Pi Imager steht für Windows als EXE-Datei und für macOS als DMG-Image zur Verfügung. Installation und Ausführung gelingen problemlos.

Unter Linux ist die Sache nicht so einfach. Die Raspberry Pi Foundation stellt den Imager als AppImage zur Verfügung. AppImages sind ein ziemlich geniales Format zur Weitergabe von Programmen. Selbst Linux Torvalds war begeistert (und das will was sagen!): »This is just very cool.« Leider setzt Ubuntu auf Snap-Pakete und die Red-Hat-Welt auf Flatpaks. Dementsprechend mau ist die Unterstützung für das AppImage-Format.

Ich habe meine Tests unter Fedora 43 durchgeführt. Der Versuch, den heruntergeladenen Imager einfach zu starten, führt sowohl aus dem Webbrowser als auch im Gnome Dateimanager in das Programm Gnome Disks. Fedora erkennt nicht, dass es sich um eine App handelt und bietet stattdessen Hilfe an, in die Image-Datei hineinzusehen. Abhilfe: Sie müssen zuerst das Execute-Bit setzen:

chmod +x Downloads/imager_2.2.0.amd64.AppImage

Aber auch der nächste Startversuch scheitert. Das Programm verlangt sudo-Rechte.

Der Raspberry Pi Imager muss mit sudo ausgeführt werden

Mit sudo funktioniert es schließlich:

sudo Downloads/imager_2.2.0.amd64.AppImage

Tipp: Beim Start mit sudo müssen Sie imager_n.n.AppImage unbedingt einen Pfad voranstellen! Wenn Sie zuerst mit cd Downloads in das Downloads-Verzeichnis wechseln und dann sudo imager_n.n.AppImage ausführen, lautet die Fehlermeldung Befehl nicht gefunden. Hingegen funktioniert sudo ./imager_n.n.AppImage.

Bedienung

Ist der Start einmal geglückt, lässt sich das Programm einfach bedienen: Sie wählen zuerst Ihr Raspberry-Pi-Modell aus, dann die gewünschte, dazu passende Distribution und schließlich das Device der SD-Karte aus. Vorsicht!! Wie schon bei der alten Version des Programms sind die Icons irreführend. In meinem Fall (PC mit zwei zwei SSDs und einer SD-Karte) wird das SD-Karten-Icon für die zweite SSD verwendet, das USB-Icon dagegen für die SD-Karte. Passen Sie auf, dass Sie nicht das falsche Laufwerk auswählen!! Ich habe ein entsprechendes GitHub-Issue verfasst.

Distributionsauswahl
Die Icons zur Auswahl der SD-Karte sind irreführend. Der obere Eintrag ist eine SSD mit meiner Windows-Installation, der untere Eintrag ist die SD-Karte!

In den weiteren Schritten können Sie eine Vorabkonfiguration von Raspberry Pi OS vornehmen, was vor allem dann hilfreich ist, wenn Sie den Raspberry Pi ohne Tastatur und Monitor (»headless«) in Betrieb nehmen und sich direkt per SSH einloggen möchten.

Diverse Parameter können vorkonfiguriert werden

Bei den Zusammenfassungen wäre die Angabe des Device-Namens der SD-Karte eine große Hilfe.

In der Zusammenfassung fehlt der Device-Name der SD-Karte

Fazit

Die Oberfläche des Raspberry Pi Imager wurde überarbeitet und ist ein wenig übersichtlicher geworden. An der Funktionalität hat sich nichts geändert. Leider kann es weiterhin recht leicht passieren, das falsche Device auszuwählen. Bedienen Sie das Programm also mit Vorsicht!

Quellen/Links

  •  

GNOME 49.2 bringt Pflege für den Linux Desktop

Das GNOME Projekt hat die Version 49.2 veröffentlicht und liefert damit das zweite Pointrelease für die aktuelle Brescia Serie. Rund sechs Wochen nach dem letzten Release folgt nun eine Sammlung von Verbesserungen und Fehlerkorrekturen, die den Alltag vieler Nutzer spürbar erleichtern sollen. Besonders auffällig sind die Änderungen an der Eingabe und Darstellung. Sticky Keys und […]

Der Beitrag GNOME 49.2 bringt Pflege für den Linux Desktop erschien zuerst auf fosstopia.

  •  

Swift 6.2 und Xcode 26.1

Endlich bin ich dazugekommen, einen Blick auf die aktuelle Xcode-Version 26.1.1 zu werfen:

  • Die KI-Integration in Xcode wurde stark verbessert; grandios ist sie noch immer nicht.
  • Der Attribute Inspector wurde ersatzlos gestrichen. Keiner weiß, warum.
  • Neue Projekte verwenden immer noch Swift 5 per Default. (?!)
  • Das primäre neue Feature von 6.2 ist der vereinfachte Umgang mit Multi-Threading (Approachable Concurrency, Default Actor Isolation = MainActor).

Update: Mittlerweile habe ich Xcode 26.2 installiert und den Artikel an ein paar Stellen aktualisiert.

KI-Funktionen

Apple bewegt sich in der schnell-lebigen KI-Landschaft wie ein überladener Supertanker bei der Hafeneinfahrt: behäbig und vorsichtig. Die 2024 versprochene KI-Integration Swift Code wurde im Herbst 2025 endlich ausgeliefert und nennt sich jetzt Coding Intelligence. Das bedeutet, dass es neben der schon länger verfügbaren Code Completion auf Basis eines lokalen Modells nun auch einen Chat-Bereich in Xcode gibt. Dort können Sie den Code eines Projekts analysieren, neue Funktionen entwickeln, Fehler beheben usw. Wie in anderen KI-Editoren verweisen Sie mit @ auf Dateien, Klassen, Funktionen und helfen so dem Sprachmodell bei der Zusammenstellung des richtigen Kontexts.

Analyse eines Projekts durch Claude

Die KI-Chat-Funktionen werden normalerweise nicht lokal ausgeführt, sondern von externen KI-Dienstleistern ausgeführt. Die Xcode-Einstellungen stehen aktuell ChatGPT und Claude direkt zur Auswahl, wobei ChatGPT in beschränkten Ausmaß ohne Login genutzt werden kann. Eine intensivere Nutzung erfordert bei beiden Varianten einen Login.

KI-Backend konfigurieren

Ich habe die KI-Funktionen mit meinem Claude-Konto ausprobiert. Es reicht ein »gewöhnlicher« Account, es muss kein Account speziell zur API-Nutzung sein. Die Xcode-Integration mit Claude ist leider weniger gut als die mit ChatGPT. Insbesondere kann Xcode nicht anzeigen, welche Code-Dateien als Kontext an Claude weitergegeben wurden. (‚Project Context: Viewed Files‘ kann nicht angeklickt werden.)

Andere AI-Dienste können mit Add Model Provider hinzugefügt werden. Erfreulicherweise gibt dieser Dialog auch die Möglichkeit, lokale Modelle (z.B. via Ollama) zu nutzen (siehe z.B. diese Anleitung).

Leider ist die Implementierung der Chat-Funktion noch recht instabil. Bereits in den ersten 15 Minuten meiner Tests ist Xcode zweimal komplett abgestürzt (spinning wheel of death). Xcode musste »sofort beendet« werden. Der Versuch, eine von den KI-Funktionen vorgeschlagene Änderung wieder rückgängig zu machen, scheiterte. Sie sind gut beraten, vor jedem Arbeitsschritt einen Commit Ihres Projekts zu machen.

Funktionen zum Agentic Coding, das in modernen Editoren wie VSCode, Cursor, Windsurf oder AntiGravity im letzten halben Jahr zur Selbstverständlichkeit geworden ist, suchen Sie in Xcode sowieso vergeblich. Immerhin sind die vorhandenen Features gut zugänglich dokumentiert, siehe z.B. das Xcode-Handbuch und dieses WWDC-Video. Das ändert aber nichts daran, dass Xcode noch einen weiten Weg vor sich hat, wenn es in der ersten KI-Liga mitspielen will.

Wo ist der Attribute Inspector? (»Unapproachable SwiftUI«)

In meinem Swift-Buch weise ich mehrfach auf den Attribute Inspector hin, der gerade für SwiftUI-Einsteiger eine große Hilfe war, um die wichtigsten Modifier einer View einzustellen. Natürlich lässt sich das alles auch per Code erledigen. Aber gerade bei den ersten Experimenten mit SwiftUI kennen Sie die ganzen Modifier-Namen ja noch nicht auswendig. Insofern empfand ich den Attribute Inspector als eine wichtige Hilfe.

Apple hat das anders gesehen und hat dieses UI-Element von Xcode in Version 26 einfach eliminiert. Apple empfand den Attribute Inspector offenbar als so unwichtig, dass seine Entfernung nicht einmal in den Release Notes erwähnt wurde. Und so haben sich nicht wenige Entwickler gefragt: Gibt es das Teil wirklich nicht mehr? Ist es woanders in Xcode versteckt? Ist das ein Bug?

Update 15.12.2025: Mit dem Attribute Inspector hat Apple auch einige Refactoring-Werkzeuge aus Xcode eliminiert. Extract Subview gibt es nicht mehr (siehe developer.apple.com/forums), aus Embed in Xxx wurde das weniger flexible Embed etc. Es ist eigentlich absurd: Will Apple den Zugang zu SwiftUI absichtlich erschweren? Einsteigern das Leben schwerer als notwendig machen?

Swift 5 forever …

Zusammen mit Xcode wird Swift 6.2 ausgeliefert:

swift --version

  swift-driver version: 1.127.14.1 Apple Swift version 6.2.1 (swiftlang-6.2.1.4.8 clang-1700.4.4.1)
  Target: arm64-apple-macosx26.0

Da würde man annehmen, dass diese Version bei neuen Xcode-Projekten auch zum Einsatz kommt. Weit gefehlt! Per Default verwenden neue Projekte weiterhin Swift 5 (siehe den folgenden Screenshot). Wenn Sie Swift 6 wünschen, müssen Sie diese Version explizit in den Build Settings einstellen. Setzt Apple selbst so wenig Vertrauen in Version 6?

Unverständlicherweise verwenden neue Projekte per Default noch immer Swift 5

Update 13.12.2025: Auch mit Xcode 26.2 bleibt Swift 5 die Default-Version.

Swift 6.2: »Approachable Concurrency«

Apple hat nicht nur bei seinen Produkten einen perfektionistischen Ansatz — dieser gilt auch für die Programmiersprache Swift. Dieser Perfektionismus hat der Sprache in den letzten Jahren eine Flut von Features beschert, aber auch eine immer schwerer zugängliche, abstrakte Syntax.

Offensichtlich über das Ziel hinausgeschossen sind die Entwickler bei den asynchronen Funktionen (Nebenläufigkeit, Concurrency): Seit Version 6 überschüttet Sie der Swift-Compiler mit Warnungen und Fehlermeldungen (Race Conditions, Isolation-Konflikte etc.). Der Compiler ist so pingelig, dass die Entwicklung asynchronen Codes sowie die Umstellung von Swift-5-Projekten auf Swift 6 zum Albtraum geworden sind. Swift hat es nicht bei Task, async und await belassen, sondern eine Menge weiterer Sprachmerkmale, Schlüsselwörter und Zusatz-Features geschaffen hat: Task-Gruppen, Aktoren, verteilte Aktoren, das Sendable-Protokoll, isolated und nonisolated Methoden usw.

Zum Glück hat auch Apple erkannt, dass es praktisch niemanden mehr gibt, der die vielen Features versteht und richtig anwenden kann (siehe auch Concurrency Migration / Common Problems). Daher hat Apple Anfang 2025 neue Zielvorgaben formuliert, wie die asynchrone Swift-Programmierung vereinfacht werden soll. Den ersten großen Schritt zurück zu mehr Einfachheit macht nun Swift 6.2.

In neuen Projekte gilt die Option »Approachable Concurrency«, der gesamte Code ist dem MainActor zugeordnet.

Es gibt zwei neue Einstellungen:

  • Approachable Concurrency = Yes soll in Zukunft diverse Features zur Vereinfachung der asynchronen Programmierung aktivieren. Was die Einstellung aktuell (also in Swift 6.2) bewirkt, ist nur dürftig dokumentiert. Höchstwahrscheinlich wird damit nur SE-470 aktiviert. SE-470 (SE steht für Swift-Evolution) bewirkt, dass bei einem Typ, der einem Aktor (meist @MainActor) zugeordnet ist, die dort implementierten Protokolle automatisch ebenfalls diesem Aktor zugeordnet werden. Das war bisher nicht der Fall. In Zukunft (Swift 6.3?) wird wohl auch SE-461 aktiviert (siehe unten).
  • Default Actor Isolation = MainActor aktiviert ein Compiler-Feature, das alle asynchronen Typen/Funktionen innerhalb des Moduls automatisch dem Main Actor zuordnet. Kurz gesagt erspart Ihnen diese Einstellung, dass Sie alle selbst definierten Klassen sowie oft auch deren Methoden mit dem Attribut @MainActor kennzeichnen müssen. Dieses Attribut gilt nun per Default. Und das ist in den meisten Fällen gut so! Downloads, Netzwerk-Aktionen usw. blockieren die Oberfläche dennoch nicht, weil sie bei Wartezeiten suspend nutzen. Probleme schaffen nur lang andauernde, CPU-intensive Vorgänge. Diese dürfen nicht mit dem MainActor verbunden werden, sonst »hängt« die Oberfläche Ihrer App. Derartige Vorgänge sind in typischen Apps aber die Ausnahme. Insofern ist die neue Einstellung Default Actor Isolation = MainActor für den Großteil aller Apps die richtige Wahl und geht ganz vielen Concurrency-Problemen und -Konflikten von vorne herein aus dem Weg.

In zukünftigen Swift-Versionen sollen laut SE-461 asynchrone Funktionen/Methoden automatisch im Kontext des gerade aktuellen Aktors laufen (siehe auch Upcoming Language Features. In welchem sonst, werden Sie vielleicht fragen? Aktuell werden non-isolated Funktionen automatisch dem global generic executor zugeordnet. Aus Effizienzgründen mag das vorteilhaft sein, allerdings muss das asynchron ermittelte Ergebnis später mit der Benutzeroberfläche synchronisiert werden. Und das ist schwierig. Wenn ich es richtig verstanden habe, wird dieses Feature in Swift 6.2 trotz Approachable Concurrency = Yes noch NICHT aktiviert. Es kann aber mit -enable-upcoming-feature NonisolatedNonsendingByDefault:migrate schon jetzt ausprobiert werden.

Die Zielsetzung all dieser Neuerungen ist es, dass das Concurrency-Verhalten von Swift per Default ein einfacher zu beherrschen ist. Für die meisten iOS- und macOS-Apps sollte das Default-Verhalten ausreichend sein. Nur wenn Ihr Code ganz spezielle Wünsche erfüllen muss (z.B. für Server-Anwendungen oder im Gaming-Bereich), können/müssen Sie die Fülle der sonstigen asynchronen Features von Swift explizit aktivieren und nutzen.

Tipp Wenn Sie ein vorhandenes Projekt umstellen, werden die neuen Optionen Approachable Concurrency und Default Actor Isolation in den normalen Build Settings nicht angezeigt und können daher auch nicht aktiviert werden. Wechseln Sie die Ansicht von Basic auf All und suchen Sie nach Default Actor bzw. Approachable!

Bei vorhandenen Projekten werden die neuen Features werden in den ‚Basic Build Settings‘ nicht angezeigt. Aktivieren Sie ‚All Build Settings‘ und verwenden Sie die Such-Funktion!

Sonstige Neuerungen in Swift 6.2 können Sie im Swift-Blog sowie auf den wie immer großartigen Seiten von Hacking with Swift nachlesen.

Quellen/Links

Swift 6.2 / Multi-threading / Concurrency

  •  

TUXEDO stoppt Entwicklung an ARM Notebook und sorgt für Kernel Streit

TUXEDO Computers hat überraschend die Arbeiten am geplanten Snapdragon X Elite Notebook eingestellt. Das ambitionierte Linux Gerät wird nicht erscheinen. Die Entwickler wollen ihre bisherige Arbeit jedoch nicht komplett verwerfen. Sie haben neue Device Tree Patches veröffentlicht und hoffen auf Nutzen für andere Systeme. Die Entscheidung stößt jedoch auf Widerstand in der Kernel Gemeinschaft. Zwar […]

Der Beitrag TUXEDO stoppt Entwicklung an ARM Notebook und sorgt für Kernel Streit erschien zuerst auf fosstopia.

  •  

GNOME 48.7 bringt Verbesserungen für den Linux Desktop

Das GNOME Projekt hat die Version 48.7 veröffentlicht und spricht von einem unspektakulären Wartungsupdate. Dennoch steckt in diesem Release mehr als nur Routinearbeit. Viele zentrale Module der Desktopumgebung erhielten neue Versionssprünge und kleinere Optimierungen. Besonders die GNOME Shell wurde überarbeitet und beseitigt mehrere lästige Probleme. Dazu gehören ein falsches Netzwerksymbol bei Verbindungsverlust, eine bessere Sortierung […]

Der Beitrag GNOME 48.7 bringt Verbesserungen für den Linux Desktop erschien zuerst auf fosstopia.

  •  

Bottles 60.0 bringt frischen Wind für Windows Apps auf Linux

Die Entwickler von Bottles haben Version 60.0 veröffentlicht und liefern damit ein starkes Update für alle, die Windows Anwendungen bequem unter Linux nutzen möchten. Die Software baut auf Wine auf und bietet eine grafische Oberfläche, die den Umgang mit komplexen Konfigurationen deutlich erleichtert. Eine der wichtigsten Neuerungen ist die native Wayland Unterstützung. Nutzer moderner Linux […]

Der Beitrag Bottles 60.0 bringt frischen Wind für Windows Apps auf Linux erschien zuerst auf fosstopia.

  •  

Daily Stand-ups und Meetings für soziale Interaktion

Am Montag des 24. November 2025 gab es im Matrix-Kanal des TILpod eine kurze Diskussion über den (Un-)Sinn und Nutzen von täglichen Besprechungen (Dailys) und darüber warum der regelmäßige Austausch gerade in ausschließlich verteilt arbeitenden Teams wichtig ist. Die Diskussion hat mich dazu motiviert, einmal aufzuschreiben wie wir dies bei uns im Team handhaben.

Dieser Text soll euch informieren, wie wir es mit den Meetings halten und mag euch als Inspiration dienen. Darüber hinaus freue ich mich, wenn ihr die in eurem Team gelebte Praxis und die Erfahrungen damit in den Kommentaren teilt.

Was ist denn überhaupt ein Team und wenn ja, wie viele?

Inspiriert vom buzzzoom.de habe ich Wikipedia und die Mistral AI befragt, was denn überhaupt ein Team ist:

Der Anglizismus Team [tiːm] (altenglisch in der Bedeutung „Familie, Gespann, Gruppe, Nachkommenschaft“) bezeichnet in der Soziologie eine aus mindestens zwei Personen bestehende Organisationseinheit, die eine bestimmte Aufgabe erfüllen und/oder gemeinsame Ziele verfolgen soll.

Quelle: https://de.wikipedia.org/wiki/Team

Mistral antwortet wie folgt auf die Frage: „Was ist ein Team?“

Ein Team ist eine Gruppe von Menschen, die gemeinsam an einem Ziel arbeiten. Teams zeichnen sich durch folgende Merkmale aus:

  • Gemeinsames Ziel: Alle Mitglieder streben dasselbe Ergebnis an.
  • Zusammenarbeit: Die Mitglieder ergänzen sich mit ihren Fähigkeiten und arbeiten koordiniert.
  • Verantwortung: Jedes Mitglied übernimmt Aufgaben und trägt zur Lösung bei.
  • Kommunikation: Offener Austausch ist essenziell für den Erfolg.

Teams gibt es in vielen Bereichen: im Beruf, im Sport, in der Schule oder auch in der Familie. Wichtig ist, dass die Mitglieder sich gegenseitig unterstützen und Vertrauen zueinander haben.

Möchtest du wissen, wie man ein gutes Team aufbaut oder welche Rollen es in einem Team gibt?

Beruflich betrachte ich mich der obigen Definition folgend als Bestandteil der folgenden Teams:

  • TAM-Team DACH (TAM == Technical Account Management)
  • EMEA TAM Team

Beide Teams haben gemeinsam, dass meines Wissens nach alle TAMs zu 100% remote oder hybrid arbeiten und keiner von uns einem Büro fest zugeordnet ist. Bis auf seltene Ausnahmen treffen und besprechen wir uns also ausschließlich in der Videokonferenzlösung unserer Wahl.

Das EMEA Platform Daily Standup

Diese Besprechung ist ein Angebot an das EMEA Platform TAM Team. Es findet jeden Werktag statt und dauert maximal 30 Minuten. Die Teilnahme ist freiwillig. Hier diskutieren wir offene Fragen, aktuelle Themen und nutzen es zum Informationsaustausch.

Die Teilnehmenden tragen ihre Punkte mit Referenzen in eine fortlaufende Agenda ein, so dass die Informationen auffindbar bleiben. Zuerst werden die Punkte von dieser Agenda nach Reihenfolge des Eintrags besprochen. Anschließend wird gefragt, ob es noch spontan weitere Themen gibt. Falls nicht hören wir einfach früher auf. Wer möchte, darf verbleibende Zeit selbstverständlich für persönliche Gespräche nutzen.

Mir gefällt neben dem sehr guten fachlichen Austausch besonders, dass die Teilnehmenden ihre Kameras immer eingeschaltet haben und wir uns gegenseitig sehen können. Dadurch entsteht zumindest für mich ein Gefühl der Zusammengehörigkeit und Nähe, so dass ich es in keinster Weise vermisse, dass wir nicht zusammen in einem Büro sitzen.

Nicht alle haben jeden Tag Zeit, an dieser Besprechung teilzunehmen, doch gibt es einen harten Kern auf den fast immer Verlass ist. Dieses Standup lebt vom Engagement der Teilnehmenden, die hier ihr Wissen teilen, so dass wir gemeinsam lernen und wachsen können.

Ein wichtiger Unterschied zu vielen anderen Dailys: Hier ist kein Chef oder Manager anwesend, der einen Arbeitsfortschritt kontrollieren oder neue Aufgaben verteilen möchte. Soetwas ist in unserer Job-Rolle als Technical Account Manager unüblich.

Open Coffee Chat und Beer-o-clock

Das Wichtigste gleich vorweg:

  • Wer Tee oder Wasser trinkt, ist im Open Coffee Chat ebenfalls willkommen.
  • Ich habe im Beer-o-clock noch niemanden Bier trinken sehen.

Beides sind wöchentliche Angebote zur sozialen Interaktion und ersetzen den Flurfunk. Auch wenn ich persönlich nicht regelmäßig an diesen Treffen teilnehme, halte ich sie für wichtig. Viele Behörden und sonstige Organisationen funktionieren nur wegen des informellen Informationsflusses. Da man sich in verteilten Teams nur selten an der Kaffeemaschine trifft, sind diese Formate in meinen Augen eine gute Alternative.

Hier wird nicht nur über die Arbeit gesprochen, sondern auch über persönliche Dinge. Was treibt die Kolleg:innen um, wie macht sich der neue 3D-Drucker daheim, etc. Aber auch wenn man eine schwere Zeit mit einem Kunden oder einer Schwesterabteilung hat, findet man hier Trost, Zuspruch und aufmunternde Worte (oder drei Pfund Salz in die Wunde gerieben).

Auch hier ist die Teilnahme selbstverständlich freiwillig und die Zahl der Teilnehmenden schwankt.

Ob ich jetzt mit 3-6 Personen in einem Glaskasten sitze oder mich mit diesen im Coffee Chat treffe, macht für mich persönlich keinen Unterschied. Mir gefällt, dass auch hier alle ihre Kamera eingeschaltet haben und man sich sehen kann.

Gleichzeitig gefällt mir, dass man sich diesen informellen Gesprächen einfach entziehen kann, wenn man Ruhe benötigt. Eine Sache, die mir früher im Büro deutlich schwerer gefallen ist.

Die Kaffee- und Zigaretten-Pause zwischendurch

Manche Büromenschen können dies vielleicht nicht nachvollziehen, doch aus dies gelingt virtuell.

Wenn ich allein in meinem Arbeitszimmer sitze, kann es manchmal ganz schön still sein. Während ich konzentriert an einer Aufgabe arbeite, stört mich dies nicht. Im Gegenteil, ich genieße die Ruhe und bin deutlich effizienter, als wenn ich ständig von irgendetwas oder irgendjemanden abgelenkt werde. Doch gibt es auch Phasen, wo ich die Stimmen von Kollegen vermisse.

Für diese Phasen haben einige Kollegen und ich einen Chat, in dem wir kommunizieren, wenn wir eine Kaffeepause gebrauchen können. Dann schalten wir uns in einer Videokonferenz zusammen und atmen kurz durch.

Wer ungestört arbeiten möchte, hat seinen Chat stumm geschaltet und wird nicht gestört.

Selbst wenn man nicht die ganze Zeit miteinander spricht, sondern jeder für sich an seinen Themen arbeitet, kann das Kamerabild der anderen einem doch das Gefühl vermitteln, nicht allein zu sein. Und nach einem kurzen Gespräch kann es oft mit neuer Energie weitergehen.

Funktioniert das für alle und jeden?

Nein. Natürlich nicht.

Wir Menschen sind verschieden und haben unterschiedliche Bedürfnisse. Ich denke, dass die Fähigkeit zur effizienten und effektiven Remote-Arbeit eine gewissen persönliche Reife, Fähigkeit zur Selbstorganisation und Disziplin voraussetzt. Zudem muss man seine Werkzeuge beherrschen, um nicht von ihnen beherrscht zu werden. Und selbst wenn all diese Dinge auf einen Menschen zutreffen, mag dieser doch in einem Büro unter Seinesgleichen besser aufgehoben sein.

Es gibt nun mal nicht die eine Lösung für alle. Siehe auch: Eierlegende Wollmilchsau.

Es gibt jedoch auch Teams wie unsere, wo dies hervorragend funktioniert. Ich fühle mich hier sehr wohl und kann mir gar nicht mehr vorstellen, täglich in ein lautes Büro zu pendeln.

Noch Fragen? Wie macht ihr das?

Mit diesem Text habe ich euch einen kleinen Einblick in unsere Meeting-Kultur gegeben. Falls ihr dazu Fragen habt, stellt sie doch bitte in den Kommentaren oder in diesem Matrix-Kanal.

Ihr möchtet gerne mitteilen, wie dies bei euch gelebt wird? Dann teilt eure Erfahrungen doch gerne in den Kommentaren oder lasst einen Link zu eurem Blog dort.

Und nun zurück an die Arbeit. ;-)

  •  

KeePassXC 2.7.11 bringt frischen Schwung und neue Funktionen

Nach acht Monaten Pause meldet sich KeePassXC mit Version 2.7.11 zurück. Der freie Passwortmanager bleibt ein zentraler Baustein für Nutzerinnen und Nutzer, die Wert auf Sicherheit und Plattformvielfalt legen. Windows, macOS und Linux werden weiterhin unterstützt und die Community treibt die Entwicklung konsequent voran. Besonders auffällig ist der neue Anhangsviewer. Bilder, HTML und Markdown lassen […]

Der Beitrag KeePassXC 2.7.11 bringt frischen Schwung und neue Funktionen erschien zuerst auf fosstopia.

  •  

Mozilla Common Voice 23: 149 neue Sprachen und Spontane Sprache

Mit Common Voice stellt Mozilla den weltweit größten öffentlichen Datensatz menschlicher Stimmen bereit – kostenlos und für jeden nutzbar. Mozilla hat Version 23 seines Datensatzes veröffentlicht. Mit 149 neuen Sprachen werden jetzt mehr als doppelt so viele Sprachen unterstützt. Außerdem gibt es ab sofort zusätzliche Datensätze für spontane Sprache.

Der Markt für Spracherkennung wird von den ganz großen Namen kommerzieller Anbieter dominiert: Amazon, Apple, Google, Microsoft. Darum hat Mozilla im Jahr 2017 das Projekt Common Voice gestartet. Mit Common Voice bietet Mozilla eine kostenlose Alternative an, zu der jeder beitragen kann und die jedem zur Verfügung steht. Damit möchte Mozilla Innovation und Wettbewerb in der Sprachtechnologie auf Basis von Maschinenlernen fördern.

149 zusätzliche Sprachen

Mozilla Common Voice war bereits der vielfältigste mehrsprachige Sprachkorpus der Welt. Der nun veröffentlichte Datensatz Common Voice 23 bringt sage und schreibe Unterstützung für 149 neue Sprachen. Damit wurde die Anzahl mehr als verdoppelt. Common Voice unterstützt jetzt 286 Sprachen.

Insgesamt bringt die neue Version 2.105 Stunden zusätzliche Sprachdaten, was zu einer neuen Gesamtzahl von 35.921 Stunden führt. Der deutschsprachige Datensatz ist von 1.476 Stunden auf 1.484 Stunden gewachsen. In Summe waren 20.355 Menschen am deutschsprachigen Datensatz beteiligt.

Spontane Sprache

Parallel zu den bestehenden Datensätzen für geschriebene Sprache, bei denen vordefinierte Sätze vorgelesen werden, baut Mozilla mittlerweile auch Datensätze für sogenannte spontane Sprache auf, um die Stimme auf natürlichere Weise einzubringen. Dabei werden Fragen in eigenen Worten beantwortet und anschließend transkribiert.

Common Voice 23 bringt die ersten Datensätze hierfür und beinhaltet 357 Stunden spontaner Sprache, verteilt auf 51 Sprachen. Speziell der deutschsprachige Datensatz beinhaltet 48 Clips mit einer Gesamtlänge von einer Stunde, beigetragen von zwei Personen.

Zum Download der Mozilla Common Voice Datensätze
Zu Mozilla Common Voice beitragen

Der Beitrag Mozilla Common Voice 23: 149 neue Sprachen und Spontane Sprache erschien zuerst auf soeren-hentzschel.at.

  •  
❌