Debian 13 „Trixie“ veröffentlicht

 (debian.org)
2 Punkte von GN⁺ 2025-08-10 | 4 Kommentare | Auf WhatsApp teilen
  • Nach etwa 2 Jahren, 1 Monat und 30 Tagen Entwicklungszeit stellte das Debian-Projekt die neue stabile Version Debian 13 „Trixie“ vor
  • Standardmäßig werden mehrere Desktop-Umgebungen wie GNOME 48, KDE Plasma 6.3, LXDE 13, LXQt 2.1.0 und Xfce 4.20 unterstützt
  • Über 14.100 neue Pakete wurden hinzugefügt, die Gesamtzahl liegt bei 69.830 Paketen, und 8.840 Pakete wurden wegen Veralterung entfernt
  • 44.326 Pakete wurden aktualisiert und es gab eine umfassende Bereinigung der Codebasis; der gesamte Festplattenverbrauch beträgt 403 GB und die Anzahl der Codezeilen liegt bei 1,4 Milliarden
  • Unterstützte Architekturen: amd64, arm64, armel, armhf, ppc64el, riscv64, s390x
    • Die offizielle Unterstützung für riscv64 wurde erstmals eingeführt
    • Die i386-Unterstützung wurde eingestellt: Es werden kein offizieller Kernel und keine offiziellen Installationswerkzeuge bereitgestellt, die Nutzung ist auf 64-Bit-CPUs nur eingeschränkt möglich
    • Die armel-Architektur wird mit diesem Release zum letzten Mal unterstützt
  • Auf allen Architekturen außer i386 wird die 64-Bit-time_t-ABI eingesetzt, sodass Datumsangaben über 2038 hinaus unterstützt werden

  • Software und Entwicklungswerkzeuge

    • Über 63 % der Gesamtpakete wurden aktualisiert
    • Zu den wichtigsten Software- und Entwicklungstools zählen Apache 2.4.64, Bash 5.2.37, BIND 9.20, curl/libcurl 8.14.1, Emacs 30.1, GNU Compiler Collection 14.2, GIMP 3.0.4, LibreOffice 25.2, Linux kernel 6.12 LTS, LLVM/Clang 19, Python 3.13, Rustc 1.85, Systemd 257, Vim 9.1
    • Geeignet für verschiedene Verwendungszwecke wie arch, Server, Desktop, Cluster, Datenbank-, Web- und Storage-Server
    • Der Qualitätssicherungsprozess wurde mit automatisierten Installations- und Upgrade-Tests verbessert

  • Cloud- und Live-Installationsunterstützung

    • Es werden Images für Cloud-Dienste wie Amazon EC2, Microsoft Azure, OpenStack, PlainVM und NoCloud bereitgestellt
    • Die Cloud-Images enthalten cloud-init-Automatisierung sowie Kernel-/Bootloader-Optimierungen für ein schnelles Booten von Instanzen
    • Die Live-Images sind für amd64 und arm64 als DVD-, USB- und Netzwerk-Boot-Varianten verfügbar
    • Live-Images können mit mehreren Desktop-Umgebungen ausprobiert werden, und es steht auch ein Standard-Image ohne GUI zur Verfügung
    • Die Installation ist mit Calamares und dem Standard-Debian-Installer möglich; mit HTTP Boot und weiteren Methoden stehen unterschiedliche Installationswege zur Verfügung

Verwandte Beiträge

4 Kommentare

 
zihado 2025-08-12

An die Leute im Debian-IRC-Kanal: Ich hoffe, euch geht es gut. In der Debian-Potato-Zeit habe ich im IRC viel herumgechattet … haha
 
jungmin1237 2025-08-12

Das Docker-Tag ist auch schon da.
https://hub.docker.com/layers/library/…
 
dongjinahn 2025-08-12

Ich bin ebenfalls von Ubuntu auf einem VPS mit 512 MB RAM für 2,5 USD im Monat zu Debian gewechselt, und es gefällt mir. Da ich von Ubuntu gekommen bin, ist es natürlich vertraut, und es verbraucht auch weniger Speicher.
 
GN⁺ 2025-08-10
Hacker-News-Kommentar

  • Ich schreibe diesen Beitrag auf einem Debian-System als mein tägliches Hauptsystem und bin damit sehr zufrieden. Nachdem Ubuntu für mich deutlich schlechter geworden ist, bin ich auf Debian 6 gewechselt und habe es nie bereut. Debians Balance zwischen Prinzipien und Pragmatismus gefällt mir: Es setzt auf Freie Software, erlaubt aber bei Bedarf unkompliziert auch non-free Software oder Firmware, und mir gefallen die Paket-Richtlinien, dpkg und die sehr robuste Dokumentation (bezüglich Dokumentation ist Arch nach wie vor besser). Mit den Streams stable/testing kann man zwischen der Sicherheit älterer Versionen und neueren, fast stabilen Versionen wählen. Vor allem hatte ich mit Debian keine einzigen Ausfälle durch interne Fehler, solange ich selbst nichts kaputt mache. Wenn schwere Boot-Probleme auftraten, lag es meist daran, dass ich ein Drittanbieter-Repository hinzugefügt oder eine Einstellung falsch geändert hatte.

    • Debian ist großartig, aber ich kann die Erfahrung nicht bestätigen, dass ein System bis zu einem eigenen Fehler unverwüstlich bleibt. Besonders beim Debian-stable-Kernel gibt es viele Patches, und im schnelllebigen DRM-Subsystem hatte ich mehrfach hartnäckige Abstürze beim Backporting erlebt, die sich kaum debuggen ließen. Die offizielle Kernel-Version bleibt zwar in der Release-Phase gleich, aber bei Ubuntu ist es oft weniger stresstreibend, wenn man laufend neuere Kernel (ähnlich HWE) nutzt. Deshalb nutze ich Debian auf VMs und Ubuntu auf Bare Metal. Mit debian-backports habe ich bisher keinen Kernel ausprobiert.

    • Ich habe selbst mit Ubuntu Server viele Upgrade-Probleme erlebt und es deshalb weggelassen. Ich betreibe über 75 VPS; bei jeder Wartungsupdaterunde hatte ich oft Sorge, dass ein System nicht mehr bootet. Diese Wiederherstellungen kosteten pro VPS zusätzliche 1–2 Stunden. Seitdem ich 2015/um die 8.x-Ära auf Debian umgestiegen bin, ist es deutlich stabiler. Wenn ich nichts falsch mache, ist bisher nichts kaputtgegangen.

    • Ich frage mich, in welchen Punkten du Ubuntu so stark schlechter findest.

    • Der einzige Nachteil von Debian ist für mich, dass neue Server-Software sofort startet. Meist sind die Defaults sicher, aber es ist schon beängstigend, wenn ein Dienst hochfährt, noch bevor ich ihn konfiguriert habe. Bei Red Hat gefällt mir, dass Dienste so lange nicht starten, bis ich sie selbst aktiviere.

    • Debian ist die Basis meines Serverbetriebs. Ich lasse produktive Systeme auf oldstable laufen und teste neue Release-Funktionen in temporären Umgebungen. Ich habe auf Bookworm nftables benutzt und auf Trixie labwc getestet. labwc ist spannend, weil es Wayland unterstützt und dennoch eine Konfiguration im Stil von Openbox erlaubt.

  • Ich bin den ehrenamtlichen Helferinnen und Helfern der Debian-Community sehr dankbar. Dass Debian und so viele darauf aufbauende Projekte existieren, verdanke ich euch. Viele Menschen und Unternehmen profitieren von eurer Arbeit. Für mich persönlich ist dieses Trixie-Release besonders aufregend: In meinem Side-Projekt ntfy ist ntfy als Paket aufgenommen worden. Erst im späten Teil des Release-Zyklus habe ich durch eine Lizenzanfrage des ntfy-Paketierers erfahren, dass in Debian die Web-App fehlt und einige Funktionen per Patch entfernt wurden. Ich habe deshalb build tags ergänzt, um das Entfernen von Stripe, Firebase, WebPush usw. zu erleichtern, und hoffe, dass in der nächsten Debian-Veröffentlichung deutlich weniger Patches nötig sein werden. Als Upstream-Maintainer ist es ärgerlich, dass es keine klare Erläuterung gibt, warum die Web-App entfernt wurde. Mir ist klar, dass das bewusst passiert ist, aber ich weiß nicht genau, wie man es beim nächsten Release wieder aufnehmen kann. Wenn apt install ntfy ausgeführt wird und die Web-App nicht läuft, werden viele Nutzer enttäuscht sein. Ich freue mich über Hinweise oder eine Anleitung. Der Quellcode kann als Referenz dienen.

    • Der Paket-Maintainer hat dazu eine Erläuterung hinzugefügt: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1098866#10. Die Web-App basiert auf Node.js, und diese Node.js-Pakete sind in Debian nicht vorhanden. In der Debian-Philosophie vermeidet man es, Quellabhängigkeiten direkt ins Paket einzubauen. Dafür müsste man auch die abhängigen Pakete selbst anlegen und pflegen, was offenbar zu aufwendig gewesen wäre.

    • Debian verlangt, dass ein npm-Paket buildbar ist. Also müssen npm-Abhängigkeiten entweder in eine Debian-spezifische package.json übersetzt, portiert oder als separate Pakete bereitgestellt werden. Das kann sehr viel Aufwand sein – bei großen lockfiles vor allem enorm viel. Vermutlich war der Umfang für den Maintainer zu hoch. Debian-gerecht wirkt es natürlicher, ein separates Paket wie ntfy-web anzubieten.

    • Ich bin dankbar für ntfy. Zuhause nutze ich es täglich, wenn ich von meinem Meshtastic-Knoten Event-Benachrichtigungen erhalte.

    • Die ntfy-Software nutze ich wirklich intensiv.

    • Wenn man Abhängigkeitsprobleme lösen will, könnte eine Bereitstellung als Container-Image der bessere Weg sein.

  • Debian ist die stabile Basis meiner „freien“ Rechnernutzung gewesen. Aus Condorcet-Abstimmungen, prozeduralem Konsens und prinzipienbasierter Entscheidungsfindung habe ich viel mitgenommen. Der Einfluss dieses Projekts und dieser Kultur auf die Welt ist kaum abzuschätzen. Herzliche Glückwünsche.

  • i386 als regulär unterstützte Architektur ist nun weg (kein aktueller Kernel oder Installer mehr, Nutzung nur noch auf 64-Bit-CPUs empfohlen, ein Upgrade auf reine 32-Bit-Hardware wird nicht mehr empfohlen). Dass die i386-Unterstützung bis August 2025 andauerte, ist bemerkenswert. Ich hatte Debian 10 Buster bis zuletzt (EOL Juni 2024) sogar noch auf Pentium-3-Hardware am Laufen. Ich bin froh, dass der Support für alte Hardware so lange gehalten hat. Wer ein aktuelles OS auf i386 möchte, kann sich auch OpenBSD anschauen.

    • Ich dachte, ich hätte 2007 zuletzt Pentium 3 genutzt, aber heute bekommt man für 1$ einen 100-mal schnelleren PC.

    • Wenn i386 in die aktuelle Debian-Ports-Infrastruktur (z. B. m68k) wandert, kann man es in Debian 14 oder 15 vermutlich weiterhin experimentell nutzen.

    • Nach meinem Wissen bekommt oldstable noch etwa ein Jahr zusätzlichen Support, d. h. es endet nicht sofort nach 2025.

    • Das ist die Debian-Unterstützung, nicht der Linux-Kernel selbst. Der Kernel unterstützt weiterhin 32-Bit-CPUs bis zum ursprünglichen Pentium (einige Clone-Chipsätze außer Acht gelassen).

    • Verwechselst du hier nicht „386“ mit 32-Bit? Im Regelfall ist 686 die übliche 32-Bit-Architektur; 386 ist eher aus den 1980er-Jahren.

  • sysvinit ist weiterhin nutzbar. Ich habe es bereits auf Servern und Desktops getestet. Bei Paketabhängigkeiten kann man durch gleichzeitiges Entfernen/Installieren mit folgendem Ansatz oft Probleme umgehen. Laut Debian-Bug-Report ist der Kern der Sache, systemd-sysv und systemd mit - zu entfernen. Mit dieser Methode ist das in debootstrap erstellte sysvinit fast identisch zu Bookworm (inklusive Desktop). Wie bei Bookworm oder Buster hilft es, in den apt-preferences libsystemd0 zu belassen und die übrigen systemd-Pakete mit Priority -1 zu blockieren.

    • Ich frage mich ernsthaft, ob sysvinit unter Debian 13 wirklich funktioniert, also ob ein Server mit sysvinit ohne systemd laufen kann.

    • Danke für den Tipp, ich werde es wenigstens im lxc-Container testen.

    • Ich wundere mich, warum man das so weit treiben sollte.

  • Falls du Schwierigkeiten hast, die x86-64-.torrent-Images zu finden, hier die Links: Minimal: netinstall ISO
    Full: DVD ISO

    • Die meisten Nutzer brauchen kein DVD(full)-Image. Für die Installation reicht die minimale Netinst-CD aus, die die Pakete beim Installieren nachlädt.

  • Die sieben offiziell unterstützten Architekturen in Trixie:

    • amd64(64-Bit-PC)
    • arm64
    • armel(ARM EABI)
    • armhf(ARMv7 EABI hard-float)
    • ppc64el(64-Bit little-endian PowerPC)
    • riscv64(64-Bit little-endian RISC-V)
    • s390x(IBM System z)
      RISC-V hat in der Praxis noch nicht viele wirklich brauchbare Geräte, aber es ist schön zu sehen, dass es endlich als Plattform der ersten Klasse gilt. Mich würde interessieren, wo Power und z heute eingesetzt werden, wenn man neben amd64/arm64/riscv64 noch weitere Plattformen betrachtet.

    • Power und z sind weiterhin milliardenschwere Geschäfte. Beide Architekturen werden vor allem im Finanzsektor und bei Banken genutzt. IBM ist bei z weiterhin stolz, bei Power wirkt es eher wie reiner Erhaltungsbetrieb, was ich schade finde. Power ist als Architektur und System einfach sehr gut gemacht.

    • Mainframes haben ihren Platz dort, wo ein Server über Jahrzehnte durchlaufen muss. Dabei lassen sich sogar Komponenten wie CPU und RAM hot-swap austauschen, und unabhängig vom OS ist permanentes Hardware-Monitoring/Diagnose möglich. Wenn ein Hardwarefehler erkannt wird, werden Eigentümer und IBM automatisch benachrichtigt. IBM unterstützt Linux seit den frühen 2000ern auf Mainframes als erstklassiges OS. Für Entwickler ist s390x der letzte verbleibende Big-Endian-Architektur-Typ (SPARC existiert zwar noch, ist aber praktisch im Wartungsmodus, Oracle kümmert sich dort im Wesentlichen nur um Solaris). Dadurch ist es nützlich für Endianness-Bugtests. Aktuell verbleiben als 32-Bit-Architekturen nur armel und armhf, und diese Release ist die letzte mit armel-Support (Hinweis). Die offizielle 32-Bit-Unterstützung wird daher vermutlich bald enden.

    • IBM investiert ziemlich viel, um sicherzustellen, dass diese beiden Architekturen in den großen Distributionen weiterhin zuverlässig laufen. Deshalb wirken sie nicht wie automatisch im Ökosystem erhalten, sondern eher durch fortgesetzte IBM-Unterstützung.

  • Wenn dich systemd-Interface-Naming-Sorgen beschäftigen, kannst du die Release Notes lesen: https://debian.org/releases/trixie/…. Mit udevadm lässt sich vor einem Upgrade prüfen, wie Interface-Namen vermutlich geändert werden. Für alle Schnittstellen außer bond und lo kann man die Liste auch über den folgenden One-Liner anzeigen. Bisher hatte ich in meinen eigenen Tests keine Fälle, in denen ein Upgrade tatsächlich den Interfacenamen geändert hat; daher bin ich mir nicht sicher, ob der Ansatz echte Änderungen zuverlässig vorhersagt.

    • Vermutlich wird dies der letzte große Umbau bei der Interface-Namensvergabe sein. enoX-Namen sollen stabil bleiben, weil BIOS/ACPI (Tabellen) angeben, welcher Port welche ID hat. ensX orientiert sich zwar an PCIe-Slots, aber wegen der PCIe-Baumstruktur können in einem Slot mehrere NICs stecken, wodurch es komplex wird. systemd hat die Logik der Interface-Namensvergabe mehrfach geändert, um solche Randfälle zu lösen. Einmal wurde die indirekte Ermittlung der PCIe-Slotnummer als Kollision gelöst; das ist in systemd 257 gefixt.

    • Mich interessiert, ob sich die Interface-Namen auch ändern können, wenn man vor dem Upgrade die Predictable Network Interface Names in systemd schon deaktiviert hat.

  • Ich nutze Debian seit der Slink-Zeit. Heute gebe ich immer noch apt-get ... ein und es läuft weiterhin einigermaßen stabil. Über 25 Jahre Upgrades mit kleinen und großen Problemen hinweg waren zwar anstrengend, aber der zusätzliche Aufwand war im Vergleich zu anderem Linux oder Closed-Source-Software wirklich überschaubar. Einziger Wermutstropfen: ich habe zu wenig zur Community beigetragen. Der große Vorteil von Debian ist, dass man die Systemfunktionalität zumindest teilweise selbst verstehen muss, um es nutzen zu können. Ich glaube daher, dass die Philosophie „so einfach wie möglich, aber nicht zu einfach“ tatsächlich gut eingehalten wird.

  • Ein typischer Vorteil von Debian ist ein Upgrade von Stable auf Stable innerhalb von 15 Minuten oder weniger. Mein erstes System brauchte für den Migrationsdurchlauf inklusive Download und Reboot weniger als 10 Minuten. Der Rechner war dabei nicht besonders leistungsstark, sondern nur ein 50-Mbps-mini-PC.