Die Entwickler hinter LibreOffice haben eine neue Ausgabe der beliebten Office Suite veröffentlicht. Die Version 25.8.3 richtet sich an alle Nutzer, die mehr Stabilität und ein verlässliches Arbeitsumfeld wünschen. Die Aktualisierung folgt rund fünf Wochen nach der vorherigen Ausgabe und verbessert laut Ankündigung viele Details, die im Alltag stören konnten. Die neue Version behebt insgesamt […]

Der Beitrag LibreOffice 25.8.3 bringt Fehlerkorrekturen für die Office Suite erschien zuerst auf fosstopia.

openSUSE Tumbleweed führt mit neuen Installationen eine deutliche Änderung im Startprozess ein. Das System verwendet nun standardmäßig eine aktualisierte Variante des bekannten Boot Programms Grub. Diese Lösung folgt einem frischen Konzept, das einzelne Einträge für jeden Kernel nutzt und so den Aufbau des Startmenüs einfacher und klarer macht. Der bisher genutzte zentrale Ablaufplan wird damit […]

Der Beitrag openSUSE Tumbleweed setzt künftig auf GRUB2-BLS bei neuen Installationen erschien zuerst auf fosstopia.

Mozilla hat eine neue Version von Thunderbird veröffentlicht. Die beliebte Anwendung steht nun als Ausgabe 145 bereit und bringt einige wichtige Neuerungen für den täglichen Einsatz. Viele Änderungen betreffen die technische Basis, doch auch sichtbare Verbesserungen sind dabei. Eine zentrale Neuerung betrifft die Anbindung an Exchange Systeme. Thunderbird kann nun direkt mit Exchange Web Services […]

Der Beitrag Thunderbird 145 bringt moderne Technik, mehr Sicherheit und Microsoft Exchange Support erschien zuerst auf fosstopia.

Die neue Ausgabe von Debian 13.2 ist knapp zwei Monate nach Debian 13.1 erschienen und vereint zahlreiche Korrekturen der letzten Wochen in einem stimmigen Paket. Das Projekt richtet den Fokus klar auf Sicherheit und Stabilität und liefert damit eine gestärkte Grundlage für neue und bestehende Systeme. Viele weit verbreitete Programme wurden bedacht. Dazu gehören zentrale […]

Der Beitrag Debian 13.2 bringt Korrekturen und stärkt die Sicherheit des Systems erschien zuerst auf fosstopia.

Aktuell schreibe ich hier mehr zu Docker als mir lieb ist. Es ist eigentlich absurd: Ich verwende Docker seit Jahren täglich und in der Regel ohne irgendwelche Probleme. Aber in den letzten Wochen prasseln Firewall-Inkompatibilitäten und anderer Ärger förmlich über Docker-Anwender herein.

Konkret geht es in diesem Beitrag um zwei Dinge:

• Mit dem Update auf containerd 1.7.28 hat Docker eine Sicherheitslücke durch eine zusätzliche AppArmor-Regel behoben. Das ist eigentlich gut, allerdings führt diese Sicherheitsmaßnahme zu Ärger im Zusammenspiel mit gewissen Containern (z.B. immich) unter Host-Systemen mit AppArmor (Ubuntu, Proxmox etc.)

• Docker Engine 29 verlangt die API-Version 1.44 oder neuer. Programme, die eine ältere API-Version verwenden, produzieren dann den Fehler Client Version 1.nnn is too old. Betroffen ist/war unter anderem das im Docker-Umfeld weit verbreitete Programm Traefik.

AppArmor-Problem / net.ipv4.ip_unprivileged_port_start permission denied

Im Anfang war der Bug, in diesem Fall CVE-2025-52881. Ein Angreifer kann runc (das wiederum Teil von containerd.io ist) mit Shared Mounts dazu bringen, /proc-Schreibvorgänge auf andere procfs-Dateien umzuleiten. Das ist wiederum sicherheitstechnisch ziemlich ungünstig (Severity ist High). Docker hat das Problem mit containerd 1.7.28-2 behoben — aber jetzt spießt es sich mit AppArmor, das nicht mehr den kompletten Pfad sieht und deswegen eingreift. Der Docker-Security-Fix kann auf Hosts mit AppArmor also dazu führen, dass auch korrekte Zugriffe blockiert werden. Die beste Beschreibung gibt dieser Blog-Beitrag.

Ich kann aus eigener Erfahrung nicht viel zu diesem Problem sagen. Ich betreibe aktuell kein System, das betroffen ist. Besonders oft tritt der Bug in Kombination mit Proxmox oder LXC auf (siehe dieses containerd Issue). Aber auch die weit verbreitete immich.app zum Foto-Management ist betroffen (siehe diese Diskussion).

Die in den verlinkten Beiträgen präsentierten Lösungsvorschläge sind leider allesamt wenig überzeugend: Das Docker-Update nicht durchführen/blockieren, eine alte Docker-Version re-installieren, AppArmor-Regeln ändern etc.

Client Version too old

Vollkommen unabhängig vom ersten Probem, aber fast zeitgleich aufgetreten ist der Fehler Client Version 1.nnn too old. Er resultiert daraus, dass die Docker Engine ab Version 29 für die API-Steuerung zumindest die API-Version 1.44 voraussetzt. (Bis zur Docker Enginge 28 reichte die API-Version 1.24.)

docker version

  ...
  Server: Docker Desktop 4.51.0 (210443)
   Engine:
     Version:          29.0.0
     API version:      1.52 (minimum version 1.44)    <------
  ...

Wenn nun ein Programm eine ältere API-Version nutzt, kommt es zum in der Überschrift genannten Fehler. Betroffen ist davon Traefik. (Das ist ein HTTP-Reverse-Proxy für Microservices und Container-Umgebungen.) Dort ist das Problem bekannt und wurde vorgestern mit Traefik Version 3.6.1 behoben.

Wenn Sie also ein Update auf die neueste Docker-Version durchführen, müssen Sie in compose.yaml für die Traefik-Version 3.6.1 oder einfach 3 oder latest angeben. Denken Sie daran, vor einem Neustart der Container ein Update des Traefek-Images mit docker pull traefik zu erledigen!

sudo apt full-upgrade -y
cd /mein/projekt/verzeichnis
docker pull traefik
docker compose down
docker compose up -d

Quellen/Links

AppArmor-Problem / net.ipv4.ip_unprivileged_port_start permission denied (containerd 1.7.28)

• https://github.com/containerd/containerd/issues/12484
• https://nvd.nist.gov/vuln/detail/CVE-2025-52881
• https://github.com/immich-app/immich/discussions/23644
• https://blog.ktz.me/apparmors-awkward-aftermath-atop-proxmox-9/

Client Version 1.nn is too old (Docker Engine 29)

• https://docs.docker.com/engine/release-notes/29/
• https://www.docker.com/blog/docker-engine-version-29/
• https://github.com/traefik/traefik/issues/12253
• https://forums.docker.com/t/docker-29-increased-minimum-api-version-breaks-traefik-reverse-proxy/150384
• https://github.com/traefik/traefik/issues/12253
• https://docs.docker.com/engine/deprecated/#deprecate-legacy-api-versions

Red Hat hat die Verfügbarkeit von Red Hat Enterprise Linux (RHEL) 10.1 bekannt gegeben. Die neue Ausgabe der Unternehmensplattform setzt auf den aktuellen Kernel 6.12. Der Schwerpunkt liegt auf moderner KI und hoher Sicherheit für anspruchsvolle Umgebungen. Die Version richtet sich vor allem an Firmen und Nutzer mit stark regulierten Abläufen. Ein zentrales Thema ist […]

Der Beitrag RHEL 10.1 startet mit neuen Funktionen für KI und Sicherheit erschien zuerst auf fosstopia.

Das KDE Projekt hat die Version 6.4.6 von Plasma veröffentlicht. Es ist die letzte Wartungsausgabe der 6.4 Reihe und bringt zahlreiche Korrekturen, die Stabilität und Alltagstauglichkeit verbessern. Viele kleine, aber spürbare Anpassungen sorgen für ein rundes Nutzererlebnis vor dem Start der kommenden Generation. Ein Schwerpunkt liegt diesmal auf der Behebung von Fehlern in den Systemeinstellungen […]

Der Beitrag KDE Plasma 6.4.6 schließt letzte Lücken vor dem großen Versionssprung erschien zuerst auf fosstopia.

Canonical hat die Supportlaufzeit für Ubuntu Pro deutlich verlängert. Mit dem sogenannten Legacy Add-on erhalten Langzeitversionen von Ubuntu nun bis zu 15 Jahre Sicherheits- und Wartungsunterstützung. Diese Erweiterung richtet sich besonders an Unternehmen, die auf stabile, langjährige IT-Infrastrukturen angewiesen sind. Ursprünglich bot Ubuntu Pro bereits zehn Jahre Support: fünf Jahre reguläre Sicherheitsaktualisierungen und fünf Jahre […]

Der Beitrag Ubuntu Pro erweitert Support: Bis zu 15 Jahre Sicherheit und Stabilität erschien zuerst auf fosstopia.

Red Hat veröffentlichte seine Distributionen Red Hat Enterprise Linux 10.1 und 9.7.

Das Budgie-Team hat Version 10.9.4 seiner beliebten Desktop-Umgebung veröffentlicht. Der Fokus dieses Updates liegt auf technischen Verbesserungen im Hintergrund, weniger auf sichtbaren Neuerungen für Anwender. Die Veröffentlichung bereitet die kommende Hauptversion 10.10 vor und sorgt für eine modernere Basis im Code. Zu den wichtigsten Änderungen gehört die Unterstützung für libpeas 2 und Girepository 2.0. Damit […]

Der Beitrag Budgie 10.9.4 modernisiert die Basis für kommende Version 10.10 erschien zuerst auf fosstopia.

Die Open-Source-Anwendung Bottles, die auf Wine basiert, macht es Linux-Nutzern seit Jahren leichter, Windows-Programme und Spiele auszuführen. Nun ist Version 52.1 erschienen und bringt einige spannende Neuerungen, die den Alltag vieler Anwender verbessern dürften. Die größte Neuerung betrifft die Einführung eines Spielzeit-Trackings. Bottles sammelt nun Sitzungsdaten über einen neuen Backend-Dienst und zeigt erste Statistiken direkt […]

Der Beitrag Bottles 52.1 bringt Spielzeit-Tracking und neue Automatisierung für Linux-Nutzer erschien zuerst auf fosstopia.

MX Linux 25 auf der Basis von Debian 13 »Trixie« setzt für maximale Kompatibilität mit dem Debian-Ökosystem mehr als bisher auf systemd. Im Installer wird zudem jetzt Secure Boot unterstützt.

Das Linux Mint Team hat im Oktober 2025 Newsletter ein neues Cinnamon Menü und zwei neue Werkzeuge vorgestellt, die den Alltag vieler Nutzer vereinfachen sollen: System Information und System Administration. Projektleiter Clement Lefebvre kündigte die Erweiterungen im monatlichen Entwicklungsbericht an und gab einen Einblick in kommende Verbesserungen für die beliebte Linux Distribution. Das neue Menü der kommenden Cinnamon-Version […]

Der Beitrag Linux Mint bringt neues Menü und Werkzeuge für Systemverwaltung und Hardwareanalyse erschien zuerst auf fosstopia.

Mozilla hat die finale Version des Firefox 145 veröffentlicht, deren offizieller Start für den 11. November 2025 geplant ist. Mit diesem Update endet die Unterstützung für 32-Bit-Systeme unter Linux, wie bereits angekündigt. Künftig werden ausschließlich 64-Bit- und ARM64-Versionen des Browsers bereitgestellt. Wie Mozilla erklärt, unterstützen die meisten modernen Linux-Distributionen 32-Bit-Systeme nicht mehr aktiv. Die Pflege […]

Der Beitrag Mozilla beendet 32-Bit-Support für Linux: Firefox 145 markiert den Beginn einer neuen Ära erschien zuerst auf fosstopia.

Ca. seit 2020 kommt nftables (Kommando nft) per Default als Firewall-Backend unter Linux zum Einsatz. Manche Distributionen machten den Schritt noch früher, andere folgten ein, zwei Jahre später. Aber mittlerweile verwenden praktisch alle Linux-Distributionen nftables.

Alte Firewall-Scripts mit iptables funktionieren dank einer Kompatibilitätsschicht zum Glück größtenteils weiterhin. Viele wichtige Firewall-Tools und -Anwendungen (von firewalld über fail2ban bis hin zu den libvirt-Bibliotheken) brauchen diese Komaptibilitätsschicht aber nicht mehr, sondern wurden auf nftables umgestellt.

Welches Programm ist säumig? Docker! Und das wird zunehmend zum Problem.

Update 11.11.2025: In naher Zukunft wird mit Engine Version 29.0 nftables als experimentelles Firewall-Backend ausgeliefert. (Aktuell gibt es den rc3, den ich aber nicht getestet habe. Meine lokalen Installationen verwenden die Engine-Version 28.5.1.) Ich habe den Artikel diesbezüglich erweitert/korrigiert. Sobald die Engine 29 ausgeliefert wird, werde ich das neue Backend ausprobieren und einen neuen Artikel verfassen.

Docker versus libvirt/virt-manager

Auf die bisher massivsten Schwierigkeiten bin ich unter Fedora >=42 und openSUSE >= 16 gestoßen: Wird zuerst Docker installiert und ausgeführt, funktioniert in virtuellen Maschinen, die mit libvirt/virt-manager gestartet werden, das NAT-Networking nicht mehr. Und es bedarf wirklich einiger Mühe, den Zusammenhang mit Docker zu erkennen. Die vorgebliche »Lösung« besteht darin, die libvirt-Firewall-Funktionen von nftables zurück auf iptables zu stellen. Eine echte Lösung wäre es, wenn Docker endlich nftables unterstützen würde.

# in der Datei /etc/libvirt/network.conf
firewall_backend = "iptables"

Danach starten Sie den libvirt-Dämon dann neu:

sudo systemctl restart libvirtd

Weitere Infos gibt es hier und hier. Die openSUSE-Release-Notes weisen ebenfalls auf das Problem hin.

Sicherheitsprobleme durch offene Ports

Weil Docker iptables verwendet, ist es mit nftables oder firewalld nicht möglich, Container mit offenen Ports nach außen hin zu blockieren. Wenn Sie also docker run -p 8080:80 machen oder in compose.yaml eine entsprechende Ports-Zeile einbauen, ist der Port 8080 nicht nur auf dem lokalen Rechner sichtbar, sondern für die ganze Welt! nftables- oder firewalld-Regeln können dagegen nichts tun!

Deswegen ist es wichtig, dass Docker-Container möglichst in internen Netzwerken miteinander kommunizieren bzw. dass offene Ports unbedingt auf localhost limitiert werden:

# Port 8080 ist nur für localhost zugänglich.
docker run -p localhost:8080:80 ...

Ihre Optionen in compose.yaml sehen so aus:

```bash
# compose.yaml
# Ziel: myservice soll mit anderem Container
# in compose.yaml über Port 8888 kommunizieren
services:
  myservice:
    image: xxx
    ports:
      # unsicher!
      # - "8888:8888"
      # besser (Port ist für localhost sichtbar)
      # - "127.0.0.1:8888:8888"
      # noch besser (Port ist nur Docker-intern offen)
      - "8888"
  otherservice:
    ...

Die sicherste Lösung besteht darin, die Container ausschließlich über ein Docker-internes Netzwerk miteinander zu verbinden (siehe backend_network im folgenden schablonenhaften Beispiel). Die Verbindung nach außen für die Ports 80 und 443 erfolgt über ein zweites Netzwerk (frontend_network). Die Angabe des drivers ist optional und verdeutlicht hier nur den Default-Netzwerktyp.

# compose.yaml
# am besten: die beiden Services myservice und
# nginx kommunizieren über das interne Netzwerk 
# miteinander
services:
  myservice:
    build: .
    ports:
      - "8888:8888"
    networks:
     - backend_network
  nginx:
    image: nginx:alpine
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf
      - /etc/mycerts/fullchain.pem:/etc/nginx/ssl/nginx.crt
      - /etc/mycerts/privkey.pem:/etc/nginx/ssl/nginx.key
    depends_on:
      - myservice
    networks:
      - frontend_network
      - backend_network
networks:
  # Verbindung zum Host über eine Bridge
  frontend_network:
    driver:   bridge
  # Docker-interne Kommunikation zwischen den Containern
  backend_network:
    driver:   bridge
    internal: true

Restriktive Empfehlungen

Docker hat es sich zuletzt sehr einfach gemacht. Auf https://docs.docker.com/engine/install/ubuntu/#firewall-limitations steht:

If you use ufw or firewalld to manage firewall settings, be aware that when you expose container ports using Docker, these ports bypass your firewall rules. For more information, refer to Docker and ufw.

Docker is only compatible with iptables-nft and iptables-legacy. Firewall rules created with nft are not supported on a system with Docker installed. Make sure that any firewall rulesets you use are created with iptables or ip6tables, and that you add them to the DOCKER-USER chain, see Packet filtering and firewalls.

Und https://docs.docker.com/engine/security/#docker-daemon-attack-surface gibt diese Zusammenfassung:

Finally, if you run Docker on a server, it is recommended to run exclusively Docker on the server, and move all other services within containers controlled by Docker. Of course, it is fine to keep your favorite admin tools (probably at least an SSH server), as well as existing monitoring/supervision processes, such as NRPE and collectd.

Salopp formuliert: Verwenden Sie für das Docker-Deployment ausschließlich für diesen Zweck dezidierte Server und/oder verwenden Sie bei Bedarf veraltete iptable-Firewalls. Vor fünf Jahren war dieser Standpunkt noch verständlich, aber heute geht das einfach gar nicht mehr. Die Praxis sieht ganz oft so aus, dass auf einem Server diverse »normale« Dienste laufen und zusätzlich ein, zwei Docker-Container Zusatzfunktionen zur Verfügung stellen. Sicherheitstechnisch wird dieser alltägliche Wunsch zum Alptraum.

Land in Sicht?

Bei Docker weiß man natürlich auch, dass iptables keine Zukunft hat. Laut diesem Issue sind 10 von 11 Punkte für die Umstellung von iptables auf nftables erledigt. Aber auch dann ist unklar, wie es weiter gehen soll: Natürlich ist das ein massiver Eingriff in grundlegende Docker-Funktionen. Die sollten vor einem Release ordentlich getestet werden. Einen (offiziellen) Zeitplan für den Umstieg auf nftables habe ich vergeblich gesucht.

Docker ist als Plattform-überschreitende Containerlösung für Software-Entwickler fast konkurrenzlos. Aber sobald man den Sichtwinkel auf Linux reduziert und sich womöglich auf Red-Hat-ähnliche Distributionen fokussiert, sieht die Lage anders aus: Podman ist vielleicht nicht hundertprozentig kompatibel, aber es ist mittlerweile ein sehr ausgereiftes Container-System, das mit Docker in vielerlei Hinsicht mithalten kann. Installationsprobleme entfallen, weil Podman per Default installiert ist. Firewall-Probleme entfallen auch. Und der root-less-Ansatz von Podman ist sicherheitstechnis sowieso ein großer Vorteil (auch wenn er oft zu Netzwerkeinschränkungen und Kompatibilitätsproblemen führt, vor allem bei compose-Setups).

Für mich persönlich war Docker immer die Referenz und Podman die nicht ganz perfekte Alternative. Aber die anhaltenden Firewall-Probleme lassen mich an diesem Standpunkt zweifeln. Die Firewall-Inkompatibilität ist definitiv ein gewichtiger Grund, der gegen den Einsatz der Docker Engine auf Server-Installationen spricht. Docker wäre gut beraten, iptables ENDLICH hinter sich zu lassen!

Update 11.11.2025: Als ich diesen Artikel im Oktober 2025 verfasst und im November veröffentlicht habe, ist mir entgangen, dass die Docker-Engine in der noch nicht ausgelieferten Version 29 tatsächlich bereits ein experimentelles nftables-Backend enthält!

Version 29 liegt aktuell als Release Candidate 3 vor. Ich warte mit meinen Tests, bis die Version tatsächlich ausgeliefert wird. Hier sind die Release Notes, hier die neue Dokumentationsseite. Vermutlich wird es ein, zwei weitere Releases brauchen, bis das nftables-Backend den Sprung von »experimentell« bis »stabil« schafft, aber immerhin ist jetzt ganz konkret ein Ende der Firewall-Misere in Sicht.

Quellen / Links

• https://github.com/moby/moby/issues/49634
• https://github.com/docker/for-linux/issues/1472
• https://fedoraproject.org/wiki/Changes/LibvirtVirtualNetworkNFTables\
• https://doc.opensuse.org/release-notes/x86_64/openSUSE/Leap/16.0/html/~|~release-notes-leap-160\
• https://docs.docker.com/engine/install/ubuntu/#firewall-limitations
• https://docs.docker.com/engine/network/packet-filtering-firewalls\
• https://docs.docker.com/engine/security/#docker-daemon-attack-surface

Das neue nftables-Backend für Docker

• https://docs.docker.com/engine/release-notes/29/
• https://docs.docker.com/engine/network/firewall-nftables/
• https://www.docker.com/blog/docker-engine-version-29/

Der Trinity Desktop Environment (TDE), Nachfolger des klassischen KDE 3.5, hat Version 14.1.5 veröffentlicht. Die neue Ausgabe richtet sich an Nutzer, die ein leichtgewichtiges, traditionelles Desktop-Erlebnis bevorzugen, ohne auf moderne Stabilität und Kompatibilität zu verzichten. Die wichtigste Neuerung betrifft den Fenstermanager TWin, der nun Tiling bei Mehrschirmkonfigurationen unterstützt. Damit lassen sich Arbeitsflächen auf mehreren Monitoren […]

Der Beitrag Trinity Desktop 14.1.5 bringt frischen Glanz für das klassische KDE Erlebnis erschien zuerst auf fosstopia.

Das Team hinter MX Linux hat die neue Version 25 mit dem Namen „Infinity“ veröffentlicht. Die Distribution basiert nun auf Debian 13 „Trixie“ und bringt zahlreiche Verbesserungen für Stabilität, Leistung und Bedienkomfort. MX Linux 25 erscheint in drei Editionen: Xfce, KDE Plasma und Fluxbox. Alle Desktop-Umgebungen kommen mit aufgefrischten aber nicht mehr taufrischen Versionen. Mit […]

Der Beitrag MX Linux 25 „Infinity“: Neuer Glanz für den beliebten Debian Fork erschien zuerst auf fosstopia.

IONOS und Nextcloud haben auf dem IONOS Summit 2025 in Berlin eine gemeinsame Plattform vorgestellt, die sich als europäische Antwort auf Microsoft 365 positioniert. Angekündigt wurde das Projekt bereits im Sommer. Der neue IONOS Nextcloud Workspace soll Unternehmen, Behörden und Organisationen eine sichere, datenschutzkonforme und vollständig souveräne Alternative für die digitale Zusammenarbeit bieten. Die Lösung basiert auf […]

Der Beitrag IONOS Nextcloud Workspace: Europäische Microsoft 365 Alternative startet erschien zuerst auf fosstopia.

Nach einer längeren Entwicklungsphase meldet sich Flatpak eindrucksvoll zurück. Sebastian Wick von Red Hat hat kürzlich Einblicke in die Arbeit am beliebten Linux-Sandboxing-Framework gegeben. Die Pre-Release-Version 1.17 markiert die erste Aktualisierung seit sechs Monaten und startet eine neue instabile Serie und beerbt Version 1.16.1. Wick räumte ein, dass Flatpak Anfang 2025 eine eher ruhige Phase […]

Der Beitrag Flatpak 1.17 – das steht uns bevor erschien zuerst auf fosstopia.

SUSE hat die allgemeine Verfügbarkeit von Linux Enterprise Server 16 (SLES 16) bekanntgegeben. Die neue Version setzt Maßstäbe für Enterprise Linux. Sie bietet eine stabile Grundlage für die IT der nächsten Dekade. Erstmals integriert SUSE ein Agentic-KI-Framework direkt in das Betriebssystem. Die Lösung soll Infrastrukturmanagement vereinfachen, Kosten senken und Prozesse beschleunigen. Administratoren profitieren von automatisierter […]

Der Beitrag SUSE Linux Enterprise Server 16: KI und langfristige Enterprise Stabilität erschien zuerst auf fosstopia.

Red Hat hat einen neuen Service angekündigt: Red Hat Confirmed Sovereign Support. Er richtet sich an Unternehmen in allen 27 Mitgliedstaaten der EU. Ziel ist es digitale Souveränität zu fördern. Der Support wird ausschließlich von EU-Bürgern erbracht und lokal innerhalb der EU bereitgestellt. Das Unternehmen betont, dass echte digitale Souveränität nur mit Open Source möglich […]

Der Beitrag Red Hat startet souveränen Support für alle EU-Staaten erschien zuerst auf fosstopia.

Beim diesjährigen Ubuntu Summit in London zeigte sich, wie stark Canonical das Linux-Ökosystem weiterhin prägt. Mehrere Unternehmen stellten Projekte vor, die sich direkt auf Ubuntu stützen, oft verbunden mit der Integration von Snap-Paketen, die die Verteilung und Wartung von Anwendungen deutlich vereinfachen sollen. Damit festigt Ubuntu seine Rolle als zentrale Plattform im offenen Softwareumfeld. Ein […]

Der Beitrag Ubuntu Summit 2025: Snap-Pakete, KI und neue Partnerschaften prägen das Bild erschien zuerst auf fosstopia.

Canonical hat die Entwicklungsphase für Ubuntu 26.04 LTS offiziell eingeläutet. Die neue Version trägt den Codenamen Resolute Raccoon und soll am 23. April 2026 erscheinen. Wie bei allen LTS-Versionen wird Ubuntu 26.04 fünf Jahre lang mit regulären Updates versorgt. Über das Programm Ubuntu Pro gibt es zusätzlich erweiterte Sicherheitsupdates bis ins Jahr 2036. Noch ist unklar, welche neuen Funktionen das System im Detail […]

Der Beitrag Ubuntu 26.04 LTS „Resolute Raccoon“: Das Drehbuch steht erschien zuerst auf fosstopia.

Das KDE-Projekt hat die Veröffentlichung von Plasma 6.5.2 bekannt gegeben. Es handelt sich um das zweite Wartungsupdate der aktuellen Version 6.5. Neue Funktionen gibt es diesmal keine, stattdessen konzentriert sich das Team auf Stabilität, Leistung und ein einheitliches Benutzererlebnis. Besonders der Fenstermanager KWin erhielt zahlreiche Verbesserungen. Ein Absturz, der Nutzer von FreeBSD betraf, wurde behoben. […]

Der Beitrag KDE Plasma 6.5.2 bringt Stabilität und Feinschliff für den Linux Desktop erschien zuerst auf fosstopia.

Am 7. und 8. November 2025 öffnen die Tux-Tage erneut ihre virtuellen Tore. Die live moderierte Online-Veranstaltung bringt bereits zum sechsten Mal Linuxbegeisterte und Open-Source-Interessierte aus aller Welt zusammen. Unter dem Motto „Menschen und Wissen vernetzen“ präsentiert das engagierte Organisationsteam ein vielseitiges Programm mit Vorträgen, Diskussionen und Workshops. Die Themenvielfalt richtet sich an Einsteiger, erfahrene Nutzer und […]

Der Beitrag Tux-Tage 2025: Das Online-Event für Linux und Open Source steht bevor erschien zuerst auf fosstopia.