... auf eine feste Basis setzt, liegt wahrscheinlich daran, dass es an Manpower mangelt um eine RR-Distribution auf Basis von Debian Testing stabil zu halten.
Wenn die Macher von LinuxMint schon Probleme haben mit dem sechsmonatigen Zyklus von Ubuntu mitzuhalten, dürfte es ein noch größeres Problem sein mit Debian Testing mitzuhalten.
Der Hauptgrund für das Festhalten an SysVInit dürfte dann wohl auch darin liegen, dass Cinnamon und die anderen LinuxMint-eigene Entwicklungen auf einer uralten Version von GNOME3 basieren und es schlichtweg an Wissen und Manpower mangelt um diese an die systemd-Komponenten anzupassen.
Wer sich mal die Mühe macht und die Git-Quellen der einzelnen Mint-eigenen Programme anschaut, merkt schnell, dass die eigentliche technische Basis seit den Forks nicht verändert hat. Bis auf ein paar Bugfixes, hat man eigentlich nur die Optik und die Bedienung der Programme verändert.
Könnte! Machen sie aber nicht. Schau dir einfach mal die Git-Quellen von Cinnamon und Co an. Da passiert nicht viel. Jedenfalls keine echte Weiterentwicklung der technischen Basis.
dürfte, könnte, es wird wohl, man merkt, wahrscheinlich, jaja.
Wenn dir dir aber sicher bist und du das alles so gut weißt, und dir so viel dran liegt, dass du darüber so viel schreiben musst, dann nutz deine Energie und dein Wissen doch lieber und hilf ihnen - oder spende ein paar Euro.
Das dürfte der Stabilität sehr gut tun. Bei Bedarf können ja jederzeit einzelne Pakete backported werden. Eine positive Sache
In dem Zusammenhang ist wohl auch der Wechsel weg von Ubuntu auf debian zu sehen. Damit ist Linux Mint ja nicht allein. Letztes prominentes Beispiel ist SteamOS. Ubuntu hat seine eigenen Probleme oben drauf auf denen von debian. Ob man sich das antun eill ist jedem selbst überlassen. So einige Distributionen wollen das offensichtlich nicht. Halt auch Mint.
Der Hauptgrund für das Festhalten an SysVInit ist dann wahrschrinlich auch genau derselbe Grund. Stabilität. Einfacher wäre es wahrscheinlich gewesen einfach das selbe zu verwenden was in debian Jessi Standard ist. Aber offensichtlich will man systemd mehr Zeit zum reifen geben. Auch wieder eine sehr positive Sache. Stabilitât vor hype, sehr gut.
Von Nur ein Leser am Di, 20. Januar 2015 um 16:07 #
Mag sein, das der Wechsel auf Debian Stable lange geplant war.
ABER die Idee von LMDE war doch ursprünglich, ein "immer aktuelles" System auf Basis von Debian Testing zu haben. Punkt. Das konnte das Team offensichtlich nicht gewährleisten, erst kamen die "Update Packages", dann kamen sie nur noch selten , jetzt kommt der Wechsel auf Stable.
Mit der ursprünglichen Idee hat das nichts mehr zu tun.
Und was einen angeblichen Wechsel von Mint weg von Ubuntu angeht, den gibt es nicht. Die Mint-Haupteditionen werden nach wie vor auf Ubuntu (LTS) basieren. LMDE ist nur ein weiterer Spin.
Die Idee hinter LMDE war mal zu schauen ob man eine andere Basis Mintifizieren kann (so als Backup, falls Ubuntu neben Unity auch noch in ganz anderen bereichen Wege eingeschlagen hätte, die das Mitteam nicht bereit gewesen wäre mitzugehen. Dann war es irgendwie gleichzeitig ein wenig ein Spielplatz für rolling und "semi-rolling" via update Packages. Und ja, das Team hat dann einfach die Prioritäten anders gesetzt, nachdem sie gemerkt haben, daß das Interesse an dem Modell nicht so sehr da war. Schließlich gibt es andere Rolling Releases. Den Wechsel haben sie auch dementsprechend begründet (zu geringes Interesse PLUS zu viel Aufwand). Es bleibt LMDE als zweites Standbein neben Ubuntu zu haben, und die Resourcen zu haben das einigermaßen pflegen zu können (als stable).
Schau die mal Manjaro an, ein sehr engagiertes Team, machen quasi nur rolling (mit Update ansage), und sind damit gut ausgelastet. Ist eine tolle Distri, nur hakt es scheinbar immer mal wieder hier und da. Mint verfolgt einfach einen sehr viel konservativeren Ansatz (mittlerweile durchgehend, früher nur in Teilgebieten).
Das Interesse an RR war und ist nach wie vor vorhanden. Problematisch war wohl eher die Umsetzung und die seltenen Updates. Bei Firefox z.B. konnte man zum Schluss lange warten - und da gab es nun wirklich nicht viel zu ändern, da ja im Gegensatz zu debian das Original verwendet wurde. Aber bei LMDE wie auch bei debian muss man eben öfter mit der Bash arbeiten als bei Ubuntu weil viele Dinge nicht so weitgehend vorkonfiguriert sind. Da aber viele Mint installieren, weil im Multimediabereich fast alle Codecs dabei sind (im Gegensatz zu Ubuntu) ist die Mehrarbeit bei LMDE (auch noch auf der Bash anstatt GUI), für die "üblichen" Nutzer subjektiv genau die falsche Richtung.
Ich für meinen Teil finde RR immer noch gut - wenn's funktioniert, denn seien wir mal ehrlich: die reine Installation des OS ist bei weitem der geringste Aufwand auf dem Weg zum persönlich optimalen System mit allen dazu gehörenden Programmen und ihrer Konfiguration.
Ja, das stimmt, das Interesse am RR war (und ist) tatsächlich vorhanden und nicht wenige, mich eingeschlossen, waren etwas enttäuscht, wie wenig rolling der RR war. Verstehen konnte ich die Entscheidung vom Mint-Team dennoch (viel Feind, wenig Ehr' ...
Aber gerade bei Firefox dachte ich, dass das immer eine Mintanpassung bekommen hat (Stichwörter: Suchmaschine, Sponsor). Aber letztlich haben sie ja selber zugegeben, dass sie LMDE nicht so pflegen konnten/können, wie sie sich das vorgestellt hatten.
Das Problem mit RR ist: wenn es funktioniert. openSuse Tumbleweed hat für mich auch etwa 8 Monate lang gut funktioniert ... dann gab es Apper-Krampf, Grafikprobleme und andere kosmetische Probleme (unnötige GRUBeinträge von Kerneln, die lang schon nicht mehr waren; und ja ich habe den offiziellen Tumbleweed --> Tumbleweed update-Path gemacht und die Susi läuft auch noch (mit festgenagelter Kernelversion). Aber für Bekannte/Verwandte und für die wirkliche Arbeitspartition wäre mit RR Tumbleweed ein wenig zu nomen est omen. Und das ist mein Eindruck von beinahe allen RR-Distros. Es ist schön, wenn es funktioniert, nur muss man (die Zeit haben) sich um die Schlaglöcher (zu) kümmern.
Schau die mal Manjaro an, ein sehr engagiertes Team, machen quasi nur rolling (mit Update ansage), und sind damit gut ausgelastet. Ist eine tolle Distri
Nichts gegen Manjaro - aber letztlich reichen die auch nur Arch-Pakete weiter.
Von Nur ein Leser am Di, 20. Januar 2015 um 16:14 #
Cinnamon basiert auf einer alten Version von GNOME3. (Ursprünglich 3.4, glaube ich)
Wenn das Mint-Team diese Basis nicht anrührt, gehen sämtliche Verbesserungen der Zwischenzeit flöten. Eine Weile funktioniert das, ist klar. Aber GNOME passt sich ja selbst auch an Upstream an.
Irgendwann kommt doch der Punkt, an dem GNOME 3.4 "broken" und inkompatibel zu anderen Upstream-Komponenten ist.
Meinst Du, das Mint-Team kann dann mit ein paar kleinen Bugfixes alles lösen? Ich bin da skeptisch (was auch ein Grund für mich war, die Distribution zu wechseln)
Auf genau diesen Punkt wollte ich auch hinaus. Wenn Clem jetzt sagt, dass er SysVInit weiterbenutzt, liegt das mit 100% Wahrscheinlichkeit einfach daran, dass den Cinnamon-Entwicklern das Wissen und/oder die Manpower fehlt um den Desktop an systemd anzupassen.
1) Vielleicht waren die "Verbesserungen" einfach keine im Kontext von Cinnamon? Im übrigen gewinnt man zuweilen den Eindruck GNOME glaubt, es wäre der upstream.
2) Wenn sie es zu 3.4 Zeit forken und anpassen konnten, wieso sollten sie das zu 3.14 Zeiten nicht können?
Von Nur ein Leser am Mi, 21. Januar 2015 um 08:54 #
ad 1) Ja, das hat Clem sicher so gesehen. Hat er ja auch entsprechend im Blog kommuniziert und dann wurden Nautilus und Co. geforkt. Allerdings waren sicher auch funktionale Änderungen dabei, die für Stabilität, Performance etc. sinnvoll wären oder sich an einen geänderten Upstream anpassen. Die hat Cinnamon folglich nicht bekommen.
ad 2) Können kann man viel. Die Frage ist doch, ob man mit GNOME 3.14 wirklich noch mal (fast) bei Null anfangen will? Der Aufwand wird doch immer größer, je mehr sich GNOME in der Zwischenzeit ändert. Die komplette Arbeit, die man in Cinnamon gesteckt hat, müsste man noch einmal investieren...
1) Ja, vielleicht. Aber ich denke, wenn man einen Bug zu Nemo einreicht, dann bekommt der auch seinen Teil Aufmerksamkeit. Vielleicht findet dann redundante Arbeit statt. Platt gesprochen: wenn ich mit Nemo keine Probleme habe, was jucken mich die Änderungen von Nautilus?
2) Ist fast siehe 1). Sie haben extra darauf hingearbeitet, dass GNOME3 für sie kein upstream mehr ist. Das hat nachteile, die Du beschreibst (man kann fixes nicht einfach "mitnehmen"), aber auch Vorteile, z.B. dass sie nicht jeder Bibliothekenänderung, die schlicht inkompatibel mit dem eigenen Produkt ist hinterherprogrammieren müssen.
Tatsache ist doch, dass bis vor kurzem, JEDES GNOME3 Update die vorhandenen Extensions zum größten Teil "zerschossen" hat. Sie hätten also, um im Bild zu bleiben, seit 3.4 alle halbe Jahr "von Neuem" anfangen müssen. Kann ich einsehen, dass man dann lieber eine brauchbare Version forkt und seinen Kram dann darauf basiert.
Von Nur ein Leser am Mi, 21. Januar 2015 um 10:57 #
Ich denke, wir stimmen da in unserer Sichtweise überein. Ist alles richtig, was Du sagst. Wir sind nur aus verschiedenen Richtungen herangegangen
Ich kann auch Clems Entscheidungen alle nachvollziehen.
Das Ding ist, ich traue Clem und seinem Team nicht zu, dass Sie mittel- oder langfristig den ganzen geforkten Kram maintainen können. Sie haben sich halt von GNOME3 abgenabelt, sind aber dennoch GNOME3-basiert... ist ein bisschen die Quadratur des Kreises.
Sie haben jetzt durch den nachvollziehbaren Schwenk auf LTS-Versionen von Ubuntu ein paar Kapazitäten freigeschaufelt. Vielleicht hilft das.
Aber ich persönlich habe für die Zukunft von Cinnamon ein ungutes Gefühl und habe deshalb vor über einem Jahr eine Distributions- und GUI Wechsel hin zu OpenSUSE/KDE vollzogen.
Das mulmige EOL-Gefühl habe ich eher bei Mate ... kann es aber nachvollziehen. Was mich ein klein wenig wundert, ist, dass Cinnamon bisher nur sehr spärlich von anderen Distries aufgegriffen wurde. Evtl. ändert sich das, da es jetzt tatsächlich konfliktfrei neben neuen GNOME3 Bibliotheken exisiteren kann. Vielleicht auch nicht.
Ich bin jedenfalls KDE auch nur übergangsweise untreu geworden (mit Netrunner 12.12 war ich zurück) und benutze es mit Mint 17 (jetzt 17.1) sehr gerne. Mint KDE ist für mich einfach ein zu Ende gedachtes Kubuntu. Die KDE Implementation von openSuse habe ich als Backup auch auf der Platte.
Der Grund ist wohl, dass Suse und Red Hat in Ihren Firmendistros zu hundert Prozent auf Gnome setzen und die Gnome-Entwickler nicht vor den Kopf stoßen wollen. Das geht sogar soweit, dass Suse wie Red Hat Ihre eigenen Classic Gnome-Oberflächen selbst entwicklen, damit diese nicht Cinnamon nehmen "müssen". Würden beide dies nämlich tun, wäre Cinnamon noch viel weiter als heute.
Ich habe keine Ahnung, wieso es denen an Wissen mangeln soll, wenn sie auf eine GNOME Komponente setzen, die in ihren Kontext augenscheinlich prima funktioniert. systemd Integration ist nebenbei für Cinnamon 2.6 geplant und ich bin mir recht sicher, dass sie das dann technisch durchaus hinbekommen.
Und der 6M Zyklus von Ubuntu ist nicht nur für Entwickler ein Problem, sondern oft genug auch für den Endanwender. Die non-LTS Releases bekommen unpraktisch kurzen Support von Ubuntu, sind oft genug Spielwiese gewesen die einen echt geärgert hat (Regressionen, neue Bugs, etc.). Ich sehe völlig ein, dass ein Entwicklerteam *mit der Zielsetzung von Mint* keinen Bock hat auf non-LTS aufzubauen.
Ich glaube, Du verstehst die Zielsetzung von Mint nicht ganz recht, die ist seit einigen Jahren sehr konservativ und besteht darin, den Endanwendern eine funktionierende Installation vor die Nase zu setzen, bei der das was die Distri bietet auch funktioniert und die den Anwender nicht mit ungewollt "modernen Benutzerkonzepten" konfrontiert. Darauf konzentrieren sie sich (recht erfolgreich übrigens). Was sie nicht machen, ist der wandernden GNOME API hinterherrennen, sonst hätten Sie wohl statt Cinnamon einen Satz GNOME Erweiterungen geschrieben. Ich würde nicht einmal ausschließen, dass sie eines Tages Cinnamon als Satz von GNOME Extensions implementieren, wenn sich abzeichnet, dass das letztlich weniger Ressourcen schluckt als Cinnamon zu maintainen.
Bei Mint war (mir) immer klar, was sie tun und warum, das wurde immer klar kommuniziert (im Blog). Meist geht es um die Frage, wie setzen wir unsere Ressourcen am besten ein, um eine reibungslose Endanwendererfahrung zu generieren? Die Zielgruppe ist ebenfalls klar: Leute, die nicht viel am System fuddeln wollen und die mit dem "klassischen" Desktoplayout arbeiten wollen. Aka *konservative* Anwender.
In manchen Dingen ist mir Mint auch zu konservativ z.B. die Updates die als Level 4 und 5 "brandmarkiert" werden, allerdings heißt es hier auch ganz klar: Level 4 ist ham wa nicht getestet ist eine zentrale Systemkomponente, kann Ärger machen und Level 5 = es gab bei wem ein Probelm, schau Dir die Doku an, ob dich das "Problem" betrifft. So, ein Blick ins Changelog des jeweiligen Pakets und dann eben ab dafür.
Nach meinem persönlichen Geschmack könnte man auch Updates von Kernkomponenten einfach Level 3 machen, wenn es im Changelog nur Sicherheitspatches gibt, aber hey, da ist das Mint Team eben *noch* konservativer.
Ich jedenfalls habe immer eine Mint-Installation im Haus. Die haben alle immer bis EOL wunderbar funktioniert und das jetzige EOL ist bequem weit weg. Zum "Schnuppern" kommt einmal im Jahr was anderes auf eine Parallelpartition.
... ich konnte die Gehässigkeiten zwischen den Systemd Beführwortern und Gegnern nie verstehen.
Es wird immer Distributionen geben, die entweder das eine, oder das andre können und wenn es irgendwann nur noch Systemd Distributionen geben sollte, wird das wohl auch seinen Grund haben warum alle dorthin wechseln, wenn nicht, dann nicht.
Ich nutze Systemd hier auf nem Gentoo und ich find es toll, es ist so viel flotter als OpenRC, funktioniert problemlos ( was ich von OpenRC ned immer behaupten konnte ) und es handhabt sich auch eingängiger.
Ein Bussi für Euch. Danke!
... auf eine feste Basis setzt, liegt wahrscheinlich daran, dass es an Manpower mangelt um eine RR-Distribution auf Basis von Debian Testing stabil zu halten.
Wenn die Macher von LinuxMint schon Probleme haben mit dem sechsmonatigen Zyklus von Ubuntu mitzuhalten, dürfte es ein noch größeres Problem sein mit Debian Testing mitzuhalten.
Der Hauptgrund für das Festhalten an SysVInit dürfte dann wohl auch darin liegen, dass Cinnamon und die anderen LinuxMint-eigene Entwicklungen auf einer uralten Version von GNOME3 basieren und es schlichtweg an Wissen und Manpower mangelt um diese an die systemd-Komponenten anzupassen.
Wer sich mal die Mühe macht und die Git-Quellen der einzelnen Mint-eigenen Programme anschaut, merkt schnell, dass die eigentliche technische Basis seit den Forks nicht verändert hat. Bis auf ein paar Bugfixes, hat man eigentlich nur die Optik und die Bedienung der Programme verändert.
Laut dem Blog erhielt Linux Mint allein im Dezember 14.000 US-Dollar an Spenden. Wenn man denn wollte könnte man sich Knowhow satt einkaufen.
Könnte! Machen sie aber nicht. Schau dir einfach mal die Git-Quellen von Cinnamon und Co an. Da passiert nicht viel. Jedenfalls keine echte Weiterentwicklung der technischen Basis.
dürfte, könnte, es wird wohl, man merkt, wahrscheinlich, jaja.
Wenn dir dir aber sicher bist und du das alles so gut weißt, und dir so viel dran liegt, dass du darüber so viel schreiben musst, dann nutz deine Energie und dein Wissen doch lieber und hilf ihnen - oder spende ein paar Euro.
;-)
Der Wechsel von debian testing auf debian stable ist schon lange geplant und wurde nun umgesetzt.
http://www.zdnet.com/article/the-future-of-lmde-and-derivatives/
Das dürfte der Stabilität sehr gut tun. Bei Bedarf können ja jederzeit einzelne Pakete backported werden. Eine positive Sache
In dem Zusammenhang ist wohl auch der Wechsel weg von Ubuntu auf debian zu sehen. Damit ist Linux Mint ja nicht allein. Letztes prominentes Beispiel ist SteamOS. Ubuntu hat seine eigenen Probleme oben drauf auf denen von debian. Ob man sich das antun eill ist jedem selbst überlassen. So einige Distributionen wollen das offensichtlich nicht. Halt auch Mint.
Der Hauptgrund für das Festhalten an SysVInit ist dann wahrschrinlich auch genau derselbe Grund. Stabilität. Einfacher wäre es wahrscheinlich gewesen einfach das selbe zu verwenden was in debian Jessi Standard ist. Aber offensichtlich will man systemd mehr Zeit zum reifen geben. Auch wieder eine sehr positive Sache. Stabilitât vor hype, sehr gut.
Mag sein, das der Wechsel auf Debian Stable lange geplant war.
ABER die Idee von LMDE war doch ursprünglich, ein "immer aktuelles" System auf Basis von Debian Testing zu haben. Punkt.
, jetzt kommt der Wechsel auf Stable.
Das konnte das Team offensichtlich nicht gewährleisten, erst kamen die "Update Packages", dann kamen sie nur noch selten
Mit der ursprünglichen Idee hat das nichts mehr zu tun.
Und was einen angeblichen Wechsel von Mint weg von Ubuntu angeht, den gibt es nicht.
Die Mint-Haupteditionen werden nach wie vor auf Ubuntu (LTS) basieren.
LMDE ist nur ein weiterer Spin.
Die Idee hinter LMDE war mal zu schauen ob man eine andere Basis Mintifizieren kann (so als Backup, falls Ubuntu neben Unity auch noch in ganz anderen bereichen Wege eingeschlagen hätte, die das Mitteam nicht bereit gewesen wäre mitzugehen. Dann war es irgendwie gleichzeitig ein wenig ein Spielplatz für rolling und "semi-rolling" via update Packages. Und ja, das Team hat dann einfach die Prioritäten anders gesetzt, nachdem sie gemerkt haben, daß das Interesse an dem Modell nicht so sehr da war. Schließlich gibt es andere Rolling Releases. Den Wechsel haben sie auch dementsprechend begründet (zu geringes Interesse PLUS zu viel Aufwand). Es bleibt LMDE als zweites Standbein neben Ubuntu zu haben, und die Resourcen zu haben das einigermaßen pflegen zu können (als stable).
Schau die mal Manjaro an, ein sehr engagiertes Team, machen quasi nur rolling (mit Update ansage), und sind damit gut ausgelastet. Ist eine tolle Distri, nur hakt es scheinbar immer mal wieder hier und da. Mint verfolgt einfach einen sehr viel konservativeren Ansatz (mittlerweile durchgehend, früher nur in Teilgebieten).
Das Interesse an RR war und ist nach wie vor vorhanden.
Problematisch war wohl eher die Umsetzung und die seltenen Updates. Bei Firefox z.B. konnte man zum Schluss lange warten - und da gab es nun wirklich nicht viel zu ändern, da ja im Gegensatz zu debian das Original verwendet wurde.
Aber bei LMDE wie auch bei debian muss man eben öfter mit der Bash arbeiten als bei Ubuntu weil viele Dinge nicht so weitgehend vorkonfiguriert sind. Da aber viele Mint installieren, weil im Multimediabereich fast alle Codecs dabei sind (im Gegensatz zu Ubuntu) ist die Mehrarbeit bei LMDE (auch noch auf der Bash anstatt GUI), für die "üblichen" Nutzer subjektiv genau die falsche Richtung.
Ich für meinen Teil finde RR immer noch gut - wenn's funktioniert, denn seien wir mal ehrlich:
die reine Installation des OS ist bei weitem der geringste Aufwand auf dem Weg zum persönlich optimalen System mit allen dazu gehörenden Programmen und ihrer Konfiguration.
Ja, das stimmt, das Interesse am RR war (und ist) tatsächlich vorhanden und nicht wenige, mich eingeschlossen, waren etwas enttäuscht, wie wenig rolling der RR war. Verstehen konnte ich die Entscheidung vom Mint-Team dennoch (viel Feind, wenig Ehr' ...
Aber gerade bei Firefox dachte ich, dass das immer eine Mintanpassung bekommen hat (Stichwörter: Suchmaschine, Sponsor). Aber letztlich haben sie ja selber zugegeben, dass sie LMDE nicht so pflegen konnten/können, wie sie sich das vorgestellt hatten.
Das Problem mit RR ist: wenn es funktioniert. openSuse Tumbleweed hat für mich auch etwa 8 Monate lang gut funktioniert ... dann gab es Apper-Krampf, Grafikprobleme und andere kosmetische Probleme (unnötige GRUBeinträge von Kerneln, die lang schon nicht mehr waren; und ja ich habe den offiziellen Tumbleweed --> Tumbleweed update-Path gemacht und die Susi läuft auch noch (mit festgenagelter Kernelversion). Aber für Bekannte/Verwandte und für die wirkliche Arbeitspartition wäre mit RR Tumbleweed ein wenig zu nomen est omen. Und das ist mein Eindruck von beinahe allen RR-Distros. Es ist schön, wenn es funktioniert, nur muss man (die Zeit haben) sich um die Schlaglöcher (zu) kümmern.
Nichts gegen Manjaro - aber letztlich reichen die auch nur Arch-Pakete weiter.
die technische Basis [...] nicht verändert hat. Bis auf ein paar Bugfixes
Was du gegen Bugfixes hast und warum du die technische Basis ständig umschreiben willst verstehe ich nicht.
Cinnamon basiert auf einer alten Version von GNOME3. (Ursprünglich 3.4, glaube ich)
Wenn das Mint-Team diese Basis nicht anrührt, gehen sämtliche Verbesserungen der Zwischenzeit flöten.
Eine Weile funktioniert das, ist klar. Aber GNOME passt sich ja selbst auch an Upstream an.
Irgendwann kommt doch der Punkt, an dem GNOME 3.4 "broken" und inkompatibel zu anderen Upstream-Komponenten ist.
Meinst Du, das Mint-Team kann dann mit ein paar kleinen Bugfixes alles lösen?
Ich bin da skeptisch (was auch ein Grund für mich war, die Distribution zu wechseln)
Auf genau diesen Punkt wollte ich auch hinaus. Wenn Clem jetzt sagt, dass er SysVInit weiterbenutzt, liegt das mit 100% Wahrscheinlichkeit einfach daran, dass den Cinnamon-Entwicklern das Wissen und/oder die Manpower fehlt um den Desktop an systemd anzupassen.
1) Vielleicht waren die "Verbesserungen" einfach keine im Kontext von Cinnamon? Im übrigen gewinnt man zuweilen den Eindruck GNOME glaubt, es wäre der upstream.
2) Wenn sie es zu 3.4 Zeit forken und anpassen konnten, wieso sollten sie das zu 3.14 Zeiten nicht können?
ad 1)
Ja, das hat Clem sicher so gesehen. Hat er ja auch entsprechend im Blog kommuniziert und dann wurden Nautilus und Co. geforkt.
Allerdings waren sicher auch funktionale Änderungen dabei, die für Stabilität, Performance etc. sinnvoll wären oder sich an einen geänderten Upstream anpassen. Die hat Cinnamon folglich nicht bekommen.
ad 2)
Können kann man viel.
Die Frage ist doch, ob man mit GNOME 3.14 wirklich noch mal (fast) bei Null anfangen will? Der Aufwand wird doch immer größer, je mehr sich GNOME in der Zwischenzeit ändert.
Die komplette Arbeit, die man in Cinnamon gesteckt hat, müsste man noch einmal investieren...
1) Ja, vielleicht. Aber ich denke, wenn man einen Bug zu Nemo einreicht, dann bekommt der auch seinen Teil Aufmerksamkeit. Vielleicht findet dann redundante Arbeit statt. Platt gesprochen: wenn ich mit Nemo keine Probleme habe, was jucken mich die Änderungen von Nautilus?
2) Ist fast siehe 1). Sie haben extra darauf hingearbeitet, dass GNOME3 für sie kein upstream mehr ist. Das hat nachteile, die Du beschreibst (man kann fixes nicht einfach "mitnehmen"), aber auch Vorteile, z.B. dass sie nicht jeder Bibliothekenänderung, die schlicht inkompatibel mit dem eigenen Produkt ist hinterherprogrammieren müssen.
Tatsache ist doch, dass bis vor kurzem, JEDES GNOME3 Update die vorhandenen Extensions zum größten Teil "zerschossen" hat. Sie hätten also, um im Bild zu bleiben, seit 3.4 alle halbe Jahr "von Neuem" anfangen müssen. Kann ich einsehen, dass man dann lieber eine brauchbare Version forkt und seinen Kram dann darauf basiert.
Ich denke, wir stimmen da in unserer Sichtweise überein. Ist alles richtig, was Du sagst.
Wir sind nur aus verschiedenen Richtungen herangegangen
Ich kann auch Clems Entscheidungen alle nachvollziehen.
Das Ding ist, ich traue Clem und seinem Team nicht zu, dass Sie mittel- oder langfristig den ganzen geforkten Kram maintainen können. Sie haben sich halt von GNOME3 abgenabelt, sind aber dennoch GNOME3-basiert... ist ein bisschen die Quadratur des Kreises.
Sie haben jetzt durch den nachvollziehbaren Schwenk auf LTS-Versionen von Ubuntu ein paar Kapazitäten freigeschaufelt. Vielleicht hilft das.
Aber ich persönlich habe für die Zukunft von Cinnamon ein ungutes Gefühl und habe deshalb vor über einem Jahr eine Distributions- und GUI Wechsel hin zu OpenSUSE/KDE vollzogen.
Das mulmige EOL-Gefühl habe ich eher bei Mate ... kann es aber nachvollziehen. Was mich ein klein wenig wundert, ist, dass Cinnamon bisher nur sehr spärlich von anderen Distries aufgegriffen wurde. Evtl. ändert sich das, da es jetzt tatsächlich konfliktfrei neben neuen GNOME3 Bibliotheken exisiteren kann. Vielleicht auch nicht.
Ich bin jedenfalls KDE auch nur übergangsweise untreu geworden (mit Netrunner 12.12 war ich zurück) und benutze es mit Mint 17 (jetzt 17.1) sehr gerne. Mint KDE ist für mich einfach ein zu Ende gedachtes Kubuntu. Die KDE Implementation von openSuse habe ich als Backup auch auf der Platte.
Der Grund ist wohl, dass Suse und Red Hat in Ihren Firmendistros zu hundert Prozent auf Gnome setzen und die Gnome-Entwickler nicht vor den Kopf stoßen wollen. Das geht sogar soweit, dass Suse wie Red Hat Ihre eigenen Classic Gnome-Oberflächen selbst entwicklen, damit diese nicht Cinnamon nehmen "müssen". Würden beide dies nämlich tun, wäre Cinnamon noch viel weiter als heute.
Ich habe keine Ahnung, wieso es denen an Wissen mangeln soll, wenn sie auf eine GNOME Komponente setzen, die in ihren Kontext augenscheinlich prima funktioniert. systemd Integration ist nebenbei für Cinnamon 2.6 geplant und ich bin mir recht sicher, dass sie das dann technisch durchaus hinbekommen.
Und der 6M Zyklus von Ubuntu ist nicht nur für Entwickler ein Problem, sondern oft genug auch für den Endanwender. Die non-LTS Releases bekommen unpraktisch kurzen Support von Ubuntu, sind oft genug Spielwiese gewesen die einen echt geärgert hat (Regressionen, neue Bugs, etc.). Ich sehe völlig ein, dass ein Entwicklerteam *mit der Zielsetzung von Mint* keinen Bock hat auf non-LTS aufzubauen.
Ich glaube, Du verstehst die Zielsetzung von Mint nicht ganz recht, die ist seit einigen Jahren sehr konservativ und besteht darin, den Endanwendern eine funktionierende Installation vor die Nase zu setzen, bei der das was die Distri bietet auch funktioniert und die den Anwender nicht mit ungewollt "modernen Benutzerkonzepten" konfrontiert. Darauf konzentrieren sie sich (recht erfolgreich übrigens). Was sie nicht machen, ist der wandernden GNOME API hinterherrennen, sonst hätten Sie wohl statt Cinnamon einen Satz GNOME Erweiterungen geschrieben. Ich würde nicht einmal ausschließen, dass sie eines Tages Cinnamon als Satz von GNOME Extensions implementieren, wenn sich abzeichnet, dass das letztlich weniger Ressourcen schluckt als Cinnamon zu maintainen.
Bei Mint war (mir) immer klar, was sie tun und warum, das wurde immer klar kommuniziert (im Blog). Meist geht es um die Frage, wie setzen wir unsere Ressourcen am besten ein, um eine reibungslose Endanwendererfahrung zu generieren? Die Zielgruppe ist ebenfalls klar: Leute, die nicht viel am System fuddeln wollen und die mit dem "klassischen" Desktoplayout arbeiten wollen. Aka *konservative* Anwender.
In manchen Dingen ist mir Mint auch zu konservativ z.B. die Updates die als Level 4 und 5 "brandmarkiert" werden, allerdings heißt es hier auch ganz klar: Level 4 ist ham wa nicht getestet ist eine zentrale Systemkomponente, kann Ärger machen und Level 5 = es gab bei wem ein Probelm, schau Dir die Doku an, ob dich das "Problem" betrifft. So, ein Blick ins Changelog des jeweiligen Pakets und dann eben ab dafür.
Nach meinem persönlichen Geschmack könnte man auch Updates von Kernkomponenten einfach Level 3 machen, wenn es im Changelog nur Sicherheitspatches gibt, aber hey, da ist das Mint Team eben *noch* konservativer.
Ich jedenfalls habe immer eine Mint-Installation im Haus. Die haben alle immer bis EOL wunderbar funktioniert und das jetzige EOL ist bequem weit weg. Zum "Schnuppern" kommt einmal im Jahr was anderes auf eine Parallelpartition.
Bei systemd wird es gerne emotional, deswegen ist es gut, ein paar Distros zu haben, die auf systemd verzichten.
Ich freunde mich gerade mit systemd an und finde es nicht schlecht.
... ich konnte die Gehässigkeiten zwischen den Systemd Beführwortern und Gegnern nie verstehen.
Es wird immer Distributionen geben, die entweder das eine, oder das andre können und wenn es irgendwann nur noch Systemd Distributionen geben sollte, wird das wohl auch seinen Grund haben warum alle dorthin wechseln, wenn nicht, dann nicht.
Ich nutze Systemd hier auf nem Gentoo und ich find es toll, es ist so viel flotter als OpenRC, funktioniert problemlos ( was ich von OpenRC ned immer behaupten konnte ) und es handhabt sich auch eingängiger.