Die Entwickler der Linux-Distribution Mint habe im Januar 2026 den Plan verkündet, künftig längere Entwicklungszyklen für einzelne Mint-Versionen anzustreben. Das Release-Management verbrät einfach viel Zeit, die man lieber in einige andere Dinge stecken möchte. Was genau geplant ist, steht aber noch nicht fest.
Nicht nur Microsoft ist zur Erkenntnis gelangt, dass recht kurze Entwicklungszyklen für ein Betriebssystem zu Problemen führt. Bei Microsoft wurde der halbjährliche Release-Zyklus für Windows-Funktionsupdates auf jährlich umgestellt. Und ich erinnere mich so um das Jahr 2000, dass SUSE alle drei Monate eine neue Version herausbrachte. Einer meiner Nachbarn war CTO bei der SUSE und erklärte mir am Gartenzaun, dass man die drei Monate Release-Zyklen brauche, um die Finanzierung (durch Verkauf von DVDs) sicherzustellen. Das Ergebnis ist bekannt: Irgendwann gab es die SUSE so als unabhängige deutsche Firma nicht mehr, denen ging das Geld auch und die wurden von Novell gekauft (siehe diesen heise-Artikel von 2003).
Mint-Entwickler zur Entwicklung und zu Release-Zyklen
Zum 11. Februar 2026 hat sich das Mint Team in den Monthly News – January 2026 zu verschiedenen Punkten ausgelassen (ist hier aufgefallen). So soll die nächste Version von Linux Mint mit mintsysadm ein Administrator-Tool bekommen, um die Benutzer- und Kontodetails zu verwalten. Das soll ein Problem beheben, dass die meisten Desktop-Umgebungen ihre eigenen Benutzertools bereitstellen. Diese Lösungen leiden darunter, dass sie oft nicht ordnungsgemäß gewartet werden und keine Unterstützung für moderne Anwendungsfälle bieten.
In weiteren Abschnitten lässt man sich über bestimmte Entscheidungen in Bezug auf die Mint-Entwicklung aus und gibt an, dass man die Unabhängigkeit schätze. Diese ermöglicht den Mint-Entwicklern eigene Lösungen zu entwickeln, wenn sie mit der Alternative nicht zufrieden sind. Man habe in der Vergangenheit einige Schritte diesbezüglich unternommen, indem an LTS festgehalten, Snap abgelehnt und Alternativen zu einem neuen GNOME entwickelt wurden, welches sich nicht wie GNOME anfühlte. Diese Entscheidungen seien nicht leicht zu treffen gewesen, und einige von ihnen kosteten viel Zeit und Ressourcen für die Umsetzung, heißt es.
Unabhängig davon, ob wie Mint als Distribution verteilt werde (z. B. mit KDE) oder wie man aktiv Lösungen entwickele (z. B. mit XApp und Cinnamon), verbringe das Team viel Zeit mit dem Release-Management. Häufige Releases seien wichtig, da das Team so viel Feedback und Fehlerberichte im Hinblick auf Änderungen erhalte. Das Ganze führt aber dazu, dass das Team immer wieder denselben Prozess wiederholen muss. Dieser Prozess funktioniert sehr gut und führt zu schrittweisen Verbesserungen von Release zu Release.
Aber er sei sehr zeitaufwendig und schränke die Ambitionen des Teams in Bezug auf die Entwicklung ein. Mit einem Release alle sechs Monate plus LMDE verbringen die Entwickler mehr Zeit mit Testen, Fehlerbehebung und Releases als mit der Entwicklung. Das ist also quasi die gleiche Falle, die ich oben bei Microsoft mit den semi-annual Feature-Updates bei Windows 10 gelaufen ist.
Microsoft ist dann auf einen jährlichen Release-Zyklus übergegangen. Das Mint-Team ist noch nicht zu einer Entscheidung gelangt, schreibt aber: "Wir denken darüber nach, dies zu ändern und einen längeren Entwicklungszyklus einzuführen. Zufälligerweise wird unsere nächste Veröffentlichung auf einem neuen LTS basieren und uns sind gerade die Codenamen ausgegangen "
MVP: 2013 – 2016
Etwas Nostalgie rund um SuSE
==========================
SuSE war um 1998/9 rum mein ersten Berührungspunkte mit Linux.
Anfangs mochte ich SuSE wegen seiner "Einfachheit" dank YaST und SAX sehr.
Später fingen mich aber verschiedene Punkte an zu stören:
* SuSE baute damals mit jeder neuen Distro ihre internen Services um:
z.B. Heute war pureFTPD das Tool, nächste DistroVersion ProFTPD, übernächste DistroVersion die nächste Version. Jedesmal durfte man alles wieder neu lernen.
Debian bleibt da deutlich Langzeitstabiler auch bei den verwendeten Services.
* SuSE Pro baute in den Services Enterprise-Funktionen wie z.B. MySQL/Postgres-Support nicht in den Mail-Server ein. DH inststallierte man einen Mailserver, hatte man Out-Of-Box keine Möglichkeiten die User Verwaltung via Datenbank zu konfigurieren, und durfte sich erst eigene Pakete compilieren und später selbst Bugfixen.
* SuSE hatte in den verschiedenen Distro-Versionen irgendwelche Bugs: Mal war KDE instable, mal crashte UnixODBC sporadisch (falsch Compilierte Version), Heute dies morgen jenes. Gestern war KDE standard, heute ist Gnome Standard, dann wieder KDE.
* Zum Thema Compilieren: Damals hatte YaST keine automatische Header-Abhängigkeits-Auflösung. DH wolltest Du den Mail-Server recompilieren mit Datenbank-Support musste ich manuell die benötigten Header-Packages durch Trail&Error selbst herausfinden.
* YaST/SAX vereinfachen zwar alles, aber: Wenn man einmal selbst verstanden hat welche Configs man anpassen muss, ist man Distrounabhängig.
Später kamen dann weitere Punkte hinzu:
* SuSE macht es mir umständlich Media-Codex hinzuzufügen
* SuSE begann sein YaST/RPM-System zu überarbeiten, und die Distro wurde über Jahre hinweg unfassbar langsam.
===============
Irgendwann um 2001/2 bin ich dann primär zu Debian-Based Distros gewechselt.
Debian empfand ich Anfangs deutlich schwieriger, weil ConsoleLastiger, aber hatte all die o.g. Nachteile nicht – und war insbesondere im KDE-Umfeld spürbar stabiler. Der einzige echte Nachteil war für mich damals, das man ständig veraltete Desktop-Software hatte.
==============
Heute würde ich sagen:
Anfänger und Anwender die einen einfachen Desktop wünschen, sind mit Linux-Mint sehr gut aufgestellt. Ich persönlich favorisiere für privat Linux-Mint Debian-Edition, oder gleich natives Debian.
Im betrieblichen Server/Oracle Umfeld setz ich auf Oracle-Linux (kostenlose RHEL Variante).
Wenn man Linux in seiner "tiefe" verstehen will:
6 Monate Linux-From-Scratch Bootcamp:
3x abreissen und neu bauen – kein copy/paste, abtippen
Danach kann man Linux grundsätzlich :-)
Das muss man sich auf der Zunge zergehen lassen: »Häufige Releases seien wichtig, da das Team so viel Feedback und Fehlerberichte im Hinblick auf Änderungen erhalte.«
– Man ändert was, um Schmerzenslaute der Nutzerschaft zu provozieren. Ich würde das als ziemlich kaputte Form der Kommunikation sehen. Der Rücklauf von den Beta-Testern scheint nicht allzu ergiebig zu sein.
Wer unüberlegt Feedback herausfordert, kann leicht in einen Shitstorm geraten.
Wenn sie breite Rückmeldung von ihren Nutzern wollen, dann müssten sie dazu bloß eine Art „Kummerkasten" in ihr System einbauen, einen Formular-Assistenten, mit dem auch ein ambitionierter Laie beschreiben kann, wann er womit Probleme feststellt, ergänzt durch einen freiwilligen Telemetrie-Schnappschuss. Und das Ganze bitte nicht bloß auf englisch: weil es den wohlmeinendsten Nutzer demotiviert, wenn er zu dem Zeitaufwand, den der Fehler selbst verursacht, auch noch herausfinden soll, wie die jeweiligen Menüpunkte auf englisch heißen würden.
Aber dann würde womöglich viel mehr Rückmeldung kommen, als die Entwickler verarbeiten können.
Das mit dem Feedback kann aber die Telekom auch "gut". Für einen einfachen Technikereinsatz und vorher mit der Hotline kommunizieren brauchen die ja dringend eine Mobilfunknummer. Ok man denkt dass der Techniker im Fall des Falles anrufen kann das Festnetz geht ja da nicht optimal. Aber nein man bekommt dann dauernd SMS mit Links zugeschickt weil ja "dringend" Feedback gebraucht wird. Wenn man die einfach ignoriert geht der Spaß etwas über eine Woche bis es mal aufhört. Warum muss man unbedingt Feedback haben. Wenn alles optimal läuft gut ansonsten beschwer ich mich schon. Und wird nicht immer gewarnt keinesfalls Links in SMS und Emails anzuklicken? Aber die Telekom zieht es durch.
Komisch, hier wird ein Feedback-Hub gefordert. Unter Windows ist das natürlich Teufelszeugs.
Das Müllsystem aus Redmond hier nicht das Thema, also lass den Off Topic Spam, wenn du nichts Sinnvolles beizutragen hast!
Aber wenn du schon vergleichst: bei deinem geliebten Müllsystem gehen ja sogar die normalen Updates regelmäßig komplett schief – trotz Feedback, Telemetrie und wahrscheinlichlicher Spyware im System. Insofern lief deine Polemik vollkommen ins Leere ;-)
Linux-Updates gehen auch regelmäßig schief, Soundkarten, WLAN funktioniert nicht mehr, grafische Oberfläche startet nicht mehr, usw… Manchmal zerhaut es auch das ganze System weil eine falsche Basis-Lib installiert wurde und dann nicht mal mehr der Kernel hoch kommt.
Da ich ein Verfechter von Linux Mint bin, wäre ich dir sehr dankbar, wenn du konkrete Beispiele samt Belege liefern könntest. Falls das nicht geht, dann ist deine Kritik leider auf Sand gebaut.
Das kennt man nur von Rolling Releases auf Arch Basis.
Mein Mint bekommt seit 3 Jahren Updates. Ein einziges Mal kam es zu einem Problem, das ich durch einen Wechsel der Kernelversion wieder beheben konnte. Die restliche Zeit hat es einfach Updates gemacht, ohne das es danach zu Problemen gab.
Typisches "1ST1"-Gelaber! Unermüdlich Linux ans Bein pinkeln!
Bei mir, jahrelang keine Update Probleme, teilweise inkl. Versions-Wechsel. Auch bei Familienmitgliedern, keinerlei Probleme.
Nur hin und wieder Probleme mit Drucker/Scanner nach Versions-Wechsel, konnte aber schnell behoben werden.
Zitat (McAlex777):
" SuSE macht es mir umständlich Media-Codex hinzuzufügen"
—
Das liegt an den Patenten für die Codecs.
Dieses Problem betrifft nicht nur openSUSE, sondern auch Fedora oder Ubuntu und generell jede Firma, die keine Lizenzgebühren für die Codecs zahlen möchte und auch nicht verklagt werden möchte.
Betroffene Pakete sind:
1.
MESA
(seit Version 22.2 von August 2022 enthält MESA einen Parameter zur Codec-Aktivierung bevor man MESA compiliert. Ohne diesen Parameter sind nicht alle Codecs enthalten.)
2.
ffmpeg
(gibt es als kastrierte Variante ohne patentierte kommerzielle Codecs oder als Vollversion)
3.
gstreamer
(Die Variante "ugly" enthält die patentierten kostenpflichtigen Codecs, die Varianten "base", "good", "bad" enthalten nicht alle Codecs.)
4.
Chromium
(wird oft ohne integrierte Codecs ausgeliefert.)
5.
Firefox
(VA-API bzw VDPAU, Hardwarebeschleunigung für Codecs ist meist deaktiviert bzw nicht auf einen der drei Grafikkartenhersteller Nvidia, AMD, Intel korrekt eingestellt. Diese 3 Hersteller sind offenbar zu blöd, um sich mal auf einen einzigen Standard zu einigen. Dann wird die CPU zu stark belastet anstatt die Dekodierung von der Grafikkarte machen zu lassen,)
6.
libavcodec, vlc-codecs
(Pakete sind nicht installiert, muss man manuell nachinstallieren)
Die Patente für h264 sind im Januar 2025 ausgelaufen, deswegen kann man diesen Codecs als openh264 jetzt kostenlos installieren (libopenh264, gstreamer-plugin-openh264, mozilla-openh264).
Bei openSUSE sind alle Codecs auch im "Packman"-Repository enthalten. Dieses Packman gibt es als große Variante und als kleine "essentials".
Falls man die große Variante installiert, dann hat man für einige Pakete zwei Quellen, einmal aus dem normalen openSUSE Repo und einmal aus Packman. Das kann und wird zu Problemen führen, wenn in dem einen Repo ein Update verfügbar ist, aber dessen Abhängigkeiten auf das andere Repository zeigen, welches noch nicht upgedatet worden ist.
Es ist ein ziemlicher Aufwand, alle oben genannten Pakete so zu installieren, dass sie auch die patentierten geblacklisteten Codecs können und es nicht zusätzlich zu Konflikten bei zukünftign Updates kommt zwischen den unterschiedlichen Repositories, die dieselben Pakete in unterschiedlichen Varianten und Versionen anbieten mit ihren jeweils anderen Abhängigkeiten.
Man muss auch noch Prioritäten in der Paketverwaltung setzen, damit ein Paket nicht aus dem falschen Repo upgedatet wird.
Man muss aufpassen mit dem Parameter "–allow-vendor-change" beim Paketmanager zypper, damit er nicht im falschen Repo nach Updates sucht.
Das ist echt komplex, wenn man es richtig machen will.
Bei Fedora heißt das zu "Packman" analoge Repository "RPM Fusion", wo die Codecs ausgelagert worden sind.
Dieser Umstand ist wirklich ein dicker Minuspunkt bei den Distributionen, hinter denen Firmen stecken, die sich an die Patentrechte halten und deshalb die Codecs nicht bei einer Standardinstallation ausliefern (dürfen).
Bei openSUSE gibt es ein Open-Building-System, wo normale User ihre Projekte auf den openSUSE-Servern selber kompilieren lassen können. Falls man allerdings dort die Parameter für die Codec-Integration aktiviert, dann wird das von einem Blacklist-Wächter erkannt und das Projekt wird gelöscht. Die nehmen die Codec-Lizensierung sehr ernst, um Klagen und Strafzahlungen zu verhindern.
Bei den "Arch"-Distributionen CachyOS, Nobara, Bazzite, Manjaro hat man dieses Problem nicht.
Bei Linux Mint wird einem die Codec Installation direkt bei der Installation im Assistenten angeboten, ist nur ein Haken. Dann lädt der die einmal separat runter und installiert die mit. Und selbst wenn man es dort nicht macht gibt es später auch immer noch eine einfache Möglichkeit der Nachinstallation über einen Assistenten.
Das funktioniert da recht problemlos und komfortabel.
Ich begrüße das. Klar, es gibt immer welche, die immer das Neueste haben wollen. Endanwender wollen das aber in der Regel nicht, die wollen, dass ein einmal installiertes, stabil laufendes System lange läuft.