Das Debian-Gnome-Team hat beschlossen, zu versuchen, GNOME 48 mit der im Sommer zu erwartenden Veröffentlichung von Debian 13 »Trixie« auszuliefern. GNOME 48 soll am 19. März erscheinen. Ein Datum für das Release von Debian 13 steht noch aus, wird aber vermutlich im Spätsommer liegen. Um GNOME 48 integrieren zu können, sind die Termine des Freeze für Debian 13 wichtig, die vor zwei Wochen mit einiger Verspätung bekannt gegeben wurden.
Noch vor dem Transition Freeze, der am 15. März einsetzt und die erste Stufe des Freeze darstellt, soll GNOME 48 als Release Candidate integriert werden. Bevor am 15. Mai der Hard Freeze einsetzt, soll dann das am 12. April zur Veröffentlichung anstehende GNOME 48.1 den Weg in die Repositories finden. Das sollte ausreichend Zeit zur Evaluierung bieten. Eine Ausnahme für eine verspätete Aufnahme während des Hard Freeze wird es bei der Größe von GNOME eher nicht geben.
Die Nachricht wird viele Anwender freuen, denn wenn das gelingt, wird Debian 13 nicht nur mit KDE Plasma 6.3 ausgeliefert, sondern auch mit GNOME 48. »Best of Both Worlds« sozusagen.
Ich bin gespannt und würde mich riesig freuen. Allerdings sollte Debian hier nichts über stürzen. Wenn das passt, dann passt es und wenn nicht, dann nicht.
Das Vorhaben ist schon einmal sehr positv.
Und ein aktuelles GNOME und Plasma zum Zeitpunkt des Realise garantiert Debian eine hohe Attraktivität für die die Desktop-Anwender über die gesammte Laufzeit hinweg..
und dann bitte noch Kernel 6.14 (dort sind einige bcachefs patches drin)
Wie geht es denn mit bcachefs und der Kerneilentwicklung jetzt weiter.
Ich kann mir vorstellen, dass das derzeitige freeze von bcachefs intensiv dazu genutzt wird die strittigen Punkte zu klären. Gibt es dazu schon neue Nachrichten?
Bei Linux 6.14 darf Kent wieder mitspielen, seine Patches sind schon eingeflossen. Mal schaun, ob er Linus von seiner Teamfähigkeit überzeugen kann.
Danke für die Info. Das ist eine sehr gute Nachricht.
Was die angeblich mangelnde Teamfähigkeit angeht, so halte ich die Argumentation für Kinderkram.
Linus muss bellen und ihn zurechtweisen, sonst tanzen ihm morgen alle anderen Kernelentwickler auf der Nase rum. Aber Kent ist teamfähig das hat er auch schon Jahre lang unter Beweis gestellt.
Die Sache um die es hier geht ist aber auch technisch nicht ganz trivial. Und so ein Stopp ist dann mal ganz gut dafür die Dinge sachlich in Ruhe und der nötigen Sorgfalt zu klären.
Da hab ich eigentlich vollstes Vertrauen, denn sonst wäre die Kernelentwicklung nicht so dynamisch über so viele Jahre gelaufen und bcachefs ist eine sehr spannende Sache die auch wirklich gebraucht wird.
Ich bin auch dafür, obwohl ZFS eigentlich erprobt und besser ist IMHO?
Erprobt ja, weil älter.. aber was meinst du mit besser?
Die ZPools, Administration und so? Ist robust und läuft Bchachfs und Btrfs müssen das noch beweisen
Robust muss es erst noch beweisen, richtig. Aber was meinst du mit zpools und Administration? Bitte etwas präziser bzw mit Beispielen erklären, bei meta aussagen ist das immer schwer zu deuten was man meint 😉
Ich hab da doch extra IMHO geschrieben. Also gut, ich benutze ZFS auf meinen FreeBSD Installationen. Da spielt die Lizenzproblematik nicht so die Rolle, so dass man bei der Installation ZFS als Dateisystem auswählen kann (bei Ubuntu auch). Ich habe früher genug Systeme händisch mit mdadm und LVM aufgesetzt, so dass ich integrierte Tools für diese Zweck zu schätzen weiss. Das können Btrfs und BcacheFS auch, da sie LVs und Raid ebenso kombinieren, bcachefs sogar wie ZFS mit Verschlüsselung, aber es ist soweit ich weiß noch nicht für den produkiven Einsatz empfohlen. Bei Btrfs sehe ich das ähnlich, Schaue mal im arch Wiki, was da alles rot markiert ist. Insbesondere Raid 5/6 CoW und rescue/recovery.
Für ZFS sei das folgende Handbuch empfohlen:
https://www.zfshandbook.com/docs/zfs-administration/zpool-administration/
Ich kenn ZFS 😉 läuft bei uns in einem HA betrieb mit 1PB netto in einem RAID1 😉
Richtig bcachefs sollte man ohne gutem Backup noch nicht produktiv einsetzen, wobei laut Kent single Device oder nur ein einfaches RAID1 mindestens genauso stabil sind wie btrfs, falls mal was schief ging, konnte man im IRC um hilfe bitten und man ist bis jetzt immer wieder an seine Daten rangekommen. Vorteil bei bcachefs ist das mit dem Schreib und Lese cache (und nein ZFS hat KEIN richtigen Schreibcache), welcher Lesecachealgorythmus besser ist ARC(zfs) oder LRU(bcachefs) müsste man mal mit echten Daten benchmarken.
Auch kann man bei ZFS Pro Ordner/Datei sagen was das für ein RAID sein soll und wie viele replicas man davon haben möchte, bei zfs geht das “nur” auf pool ebene.
Aber prinzipiell ist bcachefs noch unterlegen (send/rec gibts noch garnicht).. aber warten wir mal noch 2-3Jahre – maximal
Meine letzte Antwort ist wohl dem “link shredder” zum Opfer gefallen.Habe wohl versehntlich gegen die Benutzungsbedingungen verstossen. Aber bchachfs vs btrfs vs Zfs ist hier auch nicht on topic
Es gibt hier keinen “link shredder” und solange es Linux und Open Source ist, ist es auch nicht off topic.
Interessant; das ist ja mal ein Ding. Da bin ich ja mal gespannt, ob das funktioniert.