Fireplace April 2026

News Linux Mint 23: Cinnamon-Desktop mit vollem Wayland-Support ab Ende 2026

Kein Experte - aber Wayland ist einfach ein Thema seit ich denken kann….. locker schon 12 Jahre oder sk
 
Floxxwhite schrieb:
aber Wayland ist einfach ein Thema seit ich denken kann….. locker schon 12 Jahr
Xorg sogar noch länger und weil es bei Linux 1000 Köche gibt, die es alle besser wissen, zieht sich das alles so lange.

Canonical inklusive, welche als sie noch richtige Euphorie für den Desktop-Markt hatten, Mir als Ersatz neben Wayland etablieren wollten.

Valve hat vor einer einer Weile nochmal etwas Wayland voran gebracht, im Grunde bleibt dir Entwicklung aber schleppend.

Immerhin, mittlerweile ist Wayland unter Plasma gut brauchbar, unter GNOME ebenfalls, dass die kleineren Umgebungen da nachziehen, halte ich nur für vorteilhaft, da man halt schon Vorteile gegenüber X sehen kann.
 
Caramon2 schrieb:
Die 18er Nachkomma-Upgrades liefen wieder ohne Probleme und mit der 18.3 war Schluss: LinuxMint 19 und folgende wurde aufgrund des Ubuntu-Unterbaus für mich unbrauchbar (das konnte ich auch mit Zorin und Elementary reproduzieren - es hatte also nichts mit LinuxMint zu tun).
Gut möglich, dass sich das mit anderen Distris reproduzieren ließ - hat aber auch nichts mit Ubuntu zu tun sondern bedeutet lediglich, dass die darauf basierenden Distris ihre Hausaufgaben nicht gemacht hatten.

Aber zurück zum Thema - ist ja nett, dass Mint jetzt (wahrscheinlich) endlich auch mal so langsam in die Gänge kommt in Sachen Wayland → zumindest mal mit Cinnamon, bei XFCE haben sie es ja nicht selbst in der Hand und ob Mate überleben wird, steht noch in den Sternen. ;)
 
Bin gespannt wie gut Mint die Wayland Umsetzung hinbekommt. Bin schon langjähriger (und sehr zufriedener Nutzer). Hab trotzdem, aus Neugier. Fedora KDE, wo Wayland Standard ist, installiert, und was soll ich sagen: deutlich bessere 1%Lows. Gaming war nochmal deutlich flüssiger !!
Auf ner RTX 4070 Ti Super und alles ohne Probleme und HickHack.
Zusätzlich die Karte mit dem integrierten PenguinBurner (vollautomatisch!!) undervolted. Perfekt !!
 
Habicht schrieb:
Welchen Freeze?
Meinst du den Freeze kurz vor der Veröffentlichung einer neuen Debian-Version? Das sind ein paar Monate, so ca. 3-5, mehr nicht und damit wird ein Laden wie Tuxedo schon umgehen können.
Schön das du so genau liest, was du und ich so schreiben.

Ich sagte nie das Tuxedo damit nicht umgehen kann, ich habe deine Aussage, das Debian Testing ein RR ist, widerlegt.
BxBender schrieb:
Genau so ist es.
Meiner Meinung nach die beste Lösung von allen.
Der Anwender kann mit einem Klick alle Gaming-Sachen nachrüsten, wenn er diese denn braucht.
Ich konnte es noch nie nachvollziehen, wieso man der Benutzer hier bevormunden möchte. Und ich habe lange nach einer Distribution gesucht, die genau das kann und auch was taugt.
 
  • Gefällt mir
Reaktionen: Randnotiz
Zhenwu schrieb:
… ich habe deine Aussage, das Debian Testing ein RR ist, widerlegt.
Ne Schazi, hast du nicht - und wenn in der /etc/apt/sources.list ein testing drin steht, dann bleibt es immer ein testing und ist somit rollend - freeze hin oder her, das ändert nichts an der Geschichte.

Frage: weißt du eigentlich, was "rolling release" bedeutet und wie würdest du denn sonst ein System bezeichnen, das man einmal installiert und dann nie wieder und auch keine System-Upgrades machen muss?
 
Zuletzt bearbeitet:
Habicht schrieb:
Frage: weißt du eigentlich, was "rolling release" bedeutet und wie würdest du denn sonst ein System bezeichnen, das man einmal installiert und dann nie wieder und auch keine System-Upgrades machen muss?
Schon kurios aber wir haben wohl beide recht. Obwohl es aus meiner Sicht bei einem RR kein Freeze geben kann, das widerspricht sich irgendwie 😉

Hier mal ein Zitat aus der Wikipedia.

Testing​


testing ist die Entwicklerversion des jeweils kommenden stable. Direkt nach der Veröffentlichung einer neuen stable sind testing und stable identisch, anschließend fließen in testing laufend Aktualisierungen und neue Anwendungspakete aus unstable ein. testing entwickelt sich damit kontinuierlich weiter und bleibt im Normalfall voll einsatzfähig. Obwohl es sich damit rein technisch um ein Rolling Release handelt, wird testing nicht als solches bezeichnet – erstens wegen des Risikos kritischer Konflikte (wenn auch deutlich geringer als in unstable), zweitens wegen des Umstandes, dass Sicherheitsaktualisierungen in testing nur ausnahmsweise direkt eingepflegt werden und meist über unstable erst stark verzögert eintreffen.
Hab die wichtigen Punkte mal fett markiert.
Ergänzung ()

Habicht schrieb:
Frage: weißt du eigentlich, was "rolling release" bedeutet und wie würdest du denn sonst ein System bezeichnen, das man einmal installiert und dann nie wieder und auch keine System-Upgrades machen muss?
Und deiner Meinung nach ist es also okay, wenn bei einem RR mal eben 2-3 Jahre nichts passiert? 💪
 
Zuletzt bearbeitet:
Randnotiz schrieb:
weil es bei Linux 1000 Köche gibt, die es alle besser wissen, zieht sich das alles so lange
Ich glaube, es hat sich bei Wayland auch einfach nur so lange gezogen, weil die Wayland-Leute Fehler gemacht haben. Deren Standpunkt war zu Anfang: "Guckt mal, wir haben hier ein tolles Protokoll und das wollt ihr doch bestimmt alle haben". Bessere wäre es natürlich gewesen zu sagen: "Und übrigens, hier habt ihr eine Bibliothek die euch beim implementieren hilft." (etwas, was dann später Projekte wie wlroots umgesetzt haben).
Oder auch, das man bestimmte Dinge die dazu gehören sollten gar nicht auf dem Schirm hatte.

Klar gabs noch andere Dinge, wie beispielsweise das nvidia kein Support für GBM hatte und solche Dinge.

Trotzdem ist ein wichtiger Punkt die lange Zeit fehlende Einsicht, das eine gute Idee alleine noch keinen Selbstläufer macht.

Randnotiz schrieb:
Mir als Ersatz neben Wayland etablieren wollten.
Naja. Aber ob das als Grund taugt, warum der Wayland-Support ausgebremst wurde, ist fraglich.

Canonicals Idee war ja auch ein stückweit, beim (eigenen) Display-Server die Entwicklung auch selbst in der Hand zu haben, um eben nicht diesen Viele-Köche-verderben-den-Brei-Effekt. Ein Einbringen bei Wayland hätte ja wiederum bedeutet, das man hätte Kompromisse eingehen müssen.
Man muss weder Canonical toll finden noch Mir. Aber die Intention ist erst mal nachvollziehbar.

Randnotiz schrieb:
da man halt schon Vorteile gegenüber X sehen kann.
Der Vorteil liegt ja schon alleine darin, das Xorg ein Dead-End ist. xlibre versucht da zwar noch mal einen Drive reinzukriegen. Aber inwieweit das von Erfolg gekrönt sein wird, wird man abwarten müssen.
Denn letztlich war ja auch die überalterte Codebase verantwortlich dafür, weshalb die Xorg-Entwickler das Handtuch geworfen haben.

Und klar kann man die jetzt aufräumen. Aber das geht halt nicht, ohne das man Kompatibilität verliert. Und damit schwindet auch so ein bisschen der Sinn eines X11. Weil wenn ich das aufräume und dabei die Kompatibilität verliere, dann kann ich es auch gleich ganz neu machen und die Altlasten gänzlich abschütteln. Also quasi das, was ja mit Wayland gemacht wurde.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Randnotiz
Habicht schrieb:
Gut möglich, dass sich das mit anderen Distris reproduzieren ließ - hat aber auch nichts mit Ubuntu zu tun sondern bedeutet lediglich, dass die darauf basierenden Distris ihre Hausaufgaben nicht gemacht hatten.
Das lag an Ubuntu, da das Sachen "tief unter der Haube" betraft, auf die die Distributionen keinen Einfluss nehmen.

z. B. nutze ich zRAM statt eine physische Swap und update-initramfs hat das immer als Resume-Device übernommen (eine RAM-Disk): Das war bei LinuxMint 19 inkl. aller Pointrealesases so, bei Zorin und Elementary und auch noch bei LinuxMint 20. - Weiter habe ich nicht getestet, sondern nach einer anderen Distribution gesucht, da sich das offenbar nicht mehr ändern wird. - Auch udev- und udisk-Regeln wurden nicht übernommen, wie damals hier beschrieben und auch anderes in der Art.

Beim damaligen LMDE 2 machte update-initramfs nicht solchen Blödsinn und auch die anderen Macken konnte ich damit (im Gegensatz zu allen getesteten Ubuntu-Derivate) nicht reproduzieren. Aber das wurde danals noch zu rudimentär unterstützt, weshalb es keine Option war: Wäre es damals schon gleich auf zur "regulären" Version gewesen, wie es schon seir mindestens LMDE 6 der Fall ist (ältere LMDEs habe ich nicht getestet), wäre ich damals auf LMDE umgestiegen, statt mir per Distrowatch div. Distributionen zu suchen und zu testen.

Habicht schrieb:
wenn in der /etc/apt/sources.list ein testing drin steht, dann bleibt es immer ein testing und ist somit rollend - freeze hin oder her, das ändert nichts an der Geschichte.
Sehe ich auch so. Dass es alle 2-3 Jahre ein paar Monate sozusagen "Urlaub" macht, ändert nichts daran. :)

Sparky nenne das das zwar semi-rolling, aber das ist m. E. falsch. Das trifft eher auf Distributionen Fedora zu.
Ergänzung ()

Zhenwu schrieb:
Hab die wichtigen Punkte mal fett markiert.
Ne, du hast markiert, wie es genannt wird Genau wie man Papiertaschentücher "Tempo", nennt, auch wenn sie von einen anderen Hersteller sind

Die objektive Aussage deines Zitats war: „Obwohl es sich damit rein technisch um ein Rolling Release handelt
 
Caramon2 schrieb:
Sehe ich auch so. Dass es alle 2-3 Jahre ein paar Monate sozusagen "Urlaub" macht, ändert nichts daran. :)
Das widerspricht aber nun mal der Definition von RR.
Zudem kommt hinzu das der Freeze auch mal 2 - 3 Jahre gehen kann.

Und wenn wir ehrlich sind, eure 2 - 3 Monate sind sehr optimistisch. Im Durchschnitt dauert der Freeze 7 Monate
 
Zhenwu schrieb:
Schon kurios aber wir haben wohl beide recht.
hmmm, seh zwar nicht ganz so - aber gut, wenn du meinst und so besser schlafen kannst, dann sei es so.

Und deiner Meinung nach ist es also okay, wenn bei einem RR mal eben 2-3 Jahre nichts passiert?
keine Ahnung wo du das mit den 2-3 Jahren hernimmst, mir ist das so nicht bekannt → haste da mal ne Quelle?

Caramon2 schrieb:
Das lag an Ubuntu, da das Sachen "tief unter der Haube" betraft, auf die die Distributionen keinen Einfluss nehmen.

Schon klar, aber das aufzulösen ist doch Aufgabe der Distributionen die Ubuntu als Basis benutzen - es ist doch nicht die Aufgabe von Ubuntu, ihre Distri so auszuliefern, dass alle anderen wie Mint, Elementary, usw. damit auch zufrieden sind. ;)

Und nein, ich nutze kein Ubuntu und auch nichts, was darauf basiert (ich nutze generell keine "basiert auf" Distris) - aber da jetzt einfach Ubuntu die "Schuld" zuschieben, geht auch nicht.
 
Caramon2 schrieb:
Die objektive Aussage deines Zitats war: „Obwohl es sich damit rein technisch um ein Rolling Release handelt
"wird testing nicht als solches bezeichnet – erstens wegen des Risikos kritischer Konflikte (wenn auch deutlich geringer als in unstable), zweitens wegen des Umstandes, dass Sicherheitsaktualisierungen in testing nur ausnahmsweise direkt eingepflegt werden und meist über unstable erst stark verzögert eintreffe"

Wenn Sicherheitsaktualisierungen nur Ausnahmsweise direkt eingepflegt werden, wie kann das RR sein?

Bitte komplett erfassen und die nachfolgenden Argumente berücksichtigen.
 
Das mag ja alles stimmen was du da so aufführst - bloß wo steht denn, dass ein RR sicherheitstechnisch immer up2date sein muss?

Ich hab dich schon mal gefragt und mach es jetzt nochmal → weißt du überhaupt, was "rolling Release" bedeutet?
Und ja, es wäre nett, wenn du auch mal Fragen beantwortest und nicht immer nur deinen eigenen Gedanken hinterher rennst.

Noch ne Frage: verstehst du eigentlich, was du schreibst? Wenn Testing rein technisch gesehen ein RR ist, dann ist das nun mal so - egal wie es umgangssprachlich bezeichnet wird.
 
Rolling-Release heißt ja erst mal nur, das kontinuierlich aktualisiert wird. Ob dazwischen mal geplante Pausen drin sind oder nicht spielt m.E. nach einer untergeordnete Rolle.

Was gegen Debian testing als Rolling-Release spricht wäre demnach nicht so sehr, ob die Updates verzögert rein kommen oder das es auch mal ein Freeze (und an der Stelle muss man sagen: trotz Freeze wird ja immer noch hier und da updated; halt nur nicht mehr großschrittig), sondern wenn überhaupt eher die Tatsache das nach Release und damit Ende der Freeze-Phase in testing und unstable dann bei vielen Paketen ein großer Sprung gemacht wird (weil mglw. Zwischenversionen aus dem Upstream rausgefallen sind).

Ob man deshalb aber den Rolling-Release-Status quasi aberkennt ist ja so ein bisschen die Frage, wie man Rolling-Release definiert. Und da es keine "amtliche" Definition des Begriffs gibt, ist halt mehr oder weniger Auslegungssache und subjektiv und somit gibts eigentlich keinen Grund ewig über Nuancen in der Auslegung zu streiten.
 
  • Gefällt mir
Reaktionen: Zhenwu
Habicht schrieb:
keine Ahnung wo du das mit den 2-3 Jahren hernimmst, mir ist das so nicht bekannt → haste da mal ne Quelle?
Ja mein Fehler. Da bin ich durcheinander gekommen. Die Entwicklung von Sarge ging fast 3 Jahre.

Aber hier mal eine offizielle Liste von Debian, wie lange so ein Freeze gehen kann. Länger als ein Jahr ist durchaus mal vorgekommen, ansonsten sind eure 2 - 3 Monate eher selten...

Habicht schrieb:
Das mag ja alles stimmen was du da so aufführst - bloß wo steht denn, dass ein RR sicherheitstechnisch immer up2date sein muss?
Weil das, dass Prinzip von RR ist. Eine kontinuierliche Weiterentwicklung ohne Pausen. Zum Teil trifft das natürlich auf Testing zu aber wo ein Freeze da kein echtes RR.
Habicht schrieb:
Ich hab dich schon mal gefragt und mach es jetzt nochmal → weißt du überhaupt, was "rolling Release" bedeutet?
Und ja, es wäre nett, wenn du auch mal Fragen beantwortest und nicht immer nur deinen eigenen Gedanken hinterher rennst.
Du musst doch nur meine Antworten lesen.
Welche eigenen Gedanken denn bitte? Versuch doch mal zu verstehen und zu differenzieren.
Ergänzung ()

andy_m4 schrieb:
Ob man deshalb aber den Rolling-Release-Status quasi aberkennt ist ja so ein bisschen die Frage, wie man Rolling-Release definiert. Und da es keine "amtliche" Definition des Begriffs gibt, ist halt mehr oder weniger Auslegungssache und subjektiv und somit gibts eigentlich keinen Grund ewig über Nuancen in der Auslegung zu streiten.
Darum sagte ich ja bereits vorhin, wir haben beide irgendwo recht, wird aber ungern angenommen.

Ist ja aktuell nur eine gesunde Diskussion und erstmal ist daran nichts auszusetzen 👍
 
Zuletzt bearbeitet:
Ja ok, da sind tatsächlich ein paar dabei, die aus der Reihe tanzen.

Bedenke, auch während des Freeze bekommst du Updates für z.B. Firefox und Thunderbird - und es ändert immer noch nichts an der tatsache, dass du eben nicht neu installieren musst, das System rollt ja dann trotzdem weiter. ;)
 
Zurück
Oben