Ohne solche Erwartungen zumindest Optional zu erfüllen wird Linux aber vermutlich nie wirklich relevante Anteile am Markt (abseits der Server) ergattern können. Das gefällt mir zwar auch nicht so ganz aber ich persönlich kann (zum Beispiel in form von Flatpak's) damit leben.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 09. Okt 2018 um 14:13.
Deutlicher hättest du mir meine Ängste nicht vor Augen führen können :shock:
Dann hätten die GNU/Linux Distros mal die Probleme beseitigen müssen. Man hat aber lieber mit jeder Distro Version ein neues Snapshot vom Upstream erstellt was inkompatible mit älteren Anwendungen ist. Je nach Distro kann dieser Snapshot wenige Stunden, Tage, Wochen oder Monate alt sein, oder mehrere Jahre.
Ich will nicht mal wissen wie viele Stunden vollkommen nutzlos verschwendet worden sind durch das "Maintainen" der Distros. Das könnte man auch gemeinsam im Upstream machen.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 09. Okt 2018 um 18:41.
Und genau deshalb ist die wahrscheinlich wichtigste Distro, Debian, so erfolgreich?! Da werden Jahre alte Programmstände "maintained". Upstream hat eben vollkommen andere Ziele als Debian und dennoch arbeiten die Maintainer und Upstream meist gut zusammen. Ich habe mit dem gut abgehangenen Debian exzellente Erfahrung gemacht und kann daher kein Problem erkennen.
Der Upstream ist nicht immer mit Debians Politik glücklich und oft auch Kontraproduktiv. Ein Beispiel aus der nicht zu fernen Vergangenheit war xscreensaver. Der Upstream war sehr verärgert weil Debian eine alte Version weiterhin verteilt obwohl sie Fehlerbehaftet war. Die Fehler aus der alten Version wurden in Debian nicht beseitigt und so haben sich User weiterhin beim Upstream darüber beklagt. Dieser hat daraufhin eine Überprüfung der Version in ihre Software eingebaut und beim erkennen einer neuen Version darauf hingewiesen. Der Maintainer hat die Meldung über die neue Version einfach entfernt.
Oder Owncloud/Nextcloud. Debian bestand auf einer Version für die es nur noch Sicherheitsfixes geben sollte. Das Releasemodell passte aber da nicht dazu und so mussten die User mit einer sehr alten Version auskommen und ein Upgradepfad wurde extrem erschwert bis Unmöglich.
Ein Klassischer Fall ist auch ffmpeg und avconv. Der Debain Maintainer war auf Seiten von avconv und hat erst mal ffmpeg raus geworfen es für depricated und totes Projekt erklärt. Bei avconv wurde schnell die Kompatibilität fallen gelassen das alle Scripte nicht mehr liefen und man hat dennoch lib Namen übernommen die es fast unmöglich machten beides gleichzeitig zu nutzen. Hier wurde also nun noch mehr Arbeit in das Patchen von Upstream Projekten investiert die ffmpeg nutzen damit man den Willen einer Person umsetzen konnte. Denn darüber gab es keinen Diskurs ob man nun weiterhin ffmpeg nutzen wolle oder auf den Fork wechseln wollte.
Aber noch mal zum eigentlichen Thema der alten Anwendungen. Ich habe nichts gegen alte Version. Mein Problem ist das ja nicht nur Debian solch alten Versionsstände pflegt. Auch Ubuntu macht das für ihre LTS Versionen die mal jünger oder älter sein können als das was ich in Debian Stable bekomme. Auch Red Hat und Suse pflegen teils alte Versionen über einen längeren Zeitraum. Jeder macht das nur für sich alleine. Genau hier setzt meine Kritik an. Man verschwendet unglaublich viel Arbeitszeit in das Pflegen seiner eigenen kleinen alten Version. Wenn man das im Upstream bündelt, könnten viele Entwickler sich mit wichtigerem Beschäftigen. Aber dann müsste man ja zusammenarbeiten und noch schlimmer, mit einander Sprechen.
Dann ist da noch das große was, wäre, wenn. Wenn ich doch mal neue Versionen einer Lib oder Anwendung brauche lässt einen Debian und co. vollkommen im Regen stehen. Dann geht das gebastelt los was erst mal die richtigen Löcher aufreißt. Oder noch schlimmer, das einbinden von Fremdquellen.
Mein Rechner mit Debian 9 fasse ich daher nun eine sehr lange Zeit nicht mehr an. Denn ein Upgrade wird wohl nicht mehr sauber funktionieren oder alles was ich am Repo vorbei erledigen musste würde nach einem Upgrade garantiert nicht mehr laufen.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 10. Okt 2018 um 13:07.
Mir ist schon bewusst, dass es nicht konfliktfrei ist, deshalb schrieb ich "meist" und habe darauf hingewiesen, dass Upstream und Debian "völlig unterschiedliche Ziele" haben. Klar will ein Entwickler, dass "seine" User immer die aktuellste Version nutzen, da er keine Bug-Reports von alten Versionen bekommen möchte und seine neuesten Features präsentieren möchte. Nur wie will man eine rock solid Distro hinbekommen, wenn man nicht wie Debian arbeitet? Es ist schon der richtige Weg, einen Stand einzufrieren und diesen dann nur noch zu patchen. Sonst hat man eine rolling Distro und die ist eben NICHT vergleichbar mit Debian.
Wenn man das im Upstream bündelt, könnten viele Entwickler sich mit wichtigerem Beschäftigen. Aber dann müsste man ja zusammenarbeiten und noch schlimmer, mit einander Sprechen.
Es reicht eben nicht, miteinander zu sprechen. Man müsste auch die gleichen Ziele verfolgen und das tut man eben nicht. Das ist keine Kritik an einer der Seiten, sondern eine nüchterne Feststellung. Ich kann hervorragend damit leben, dass ich mit Debian eine etwas veraltete, aber dafür sehr stabile Distro habe. Wenn ich mal eine spezielle aktuelle Version einer Software benötige, dann installiere ich mir ein Flatpak, von dem ich weiß, dass es auch regelmäßig aktualisiert wird. Für mich ist das eine großartige Ergänzung. Ich nutze also Debian stable (ohne weitere Fremdquelle) plus 2-3 Flatpaks. Und wer andere Präferenzen hat, der kann ja eine rolling-Distro verwenden.
OT: Dein erstes Beispiel:
Dieser hat daraufhin eine Überprüfung der Version in ihre Software eingebaut und beim erkennen einer neuen Version darauf hingewiesen.
Das ist eine freundliche Untertreibung! Der Entwickler von xscreensaver hatte eine Popup-Timebomb eingebaut, um Debian/Ubuntu-User zu ärgern.
Ich störe mich nicht prinzipiell an der Arbeitsweise von Debian. Denn genau das will ich ja in der Regel. Ein stabiles System an dem ich nicht alle paar Wochen Handanlegen muss weil ein Patch etwas kaputt gemacht hat. Ich kritisiere die mangelnde Zusammenarbeit in der Langzeitpflege unter den Distributionen. Diese Zusammenarbeit klappt nicht mit jedem wie du selbst ja auch schon sagst. Aber das ist auch nicht schlimm, denn ich kann mir ja anschauen wer ähnliche oder die gleichen Ziele verfolgt. Dabei lande ich idr. bei Ubuntu LTS, Red Hat und Suse. Aber jeder macht sein eigenes Ding. Wenn die vier im Upstream ihre LTE Version einer Bibliothek oder Anwendung Maintainen wollen, glaube ich kaum das es abgelehnt wird. Ansonsten können die vier das noch immer gemeinsam Forken.
Dann kritisiere ich das z.B. Debian einen im Regen stehen lässt wenn ich doch mal was aktuelleres brauche. Ein Ausweichen auf selber compilieren, Frem-Repos oder gar ein weiteres Paketformat das getrennt vom System ihre Anwendung mitbringt halte ich für ganz furchtbare Lösungen. Seit über 20 Jahren gibt es die zentralen Softwareverzeichnisse der Distributionen. Das Problem was wir heute haben hätte seit dem bereits gelöst sein können. Aber man will sich Absolut nur auf eine Version festlegen. Ich verstehe warum man es machen wollte, aber das entspricht nun mal nicht der Softwarelandschaft und auch nicht dem wie sich Entwickler verhalten.
Es kann ja erst mal die Stabile Default Version installiert werden, aber wenn ich eine aktuelle Version brauche soll es mir die auch geben können. Das ich dann die eine oder andere Bibliothek in zwei unterschiedlichen Versionen auf dem System habe ist bei Speichergrößen kein Problem.
Eine Rolling Release Distro löst auch nicht das Problem, denn wenn nicht alles dem mitgeht laufen Anwendungen die man extern installiert hat irgendwann nicht mehr.
Dann kritisiere ich das z.B. Debian einen im Regen stehen lässt wenn ich doch mal was aktuelleres brauche.
Debian bietet Backports.
Das ein oder andere Schätzchen findet man da durchaus. So z.B. das neue KiCad Version 5 für Debian stable, welches Standardmäßig eigentlich nur KiCad 4.x mitliefert.
Das Backports Angebot müsste lediglich noch etwas weiter ausgebaut werden, vor allem um die Endanwendersoftware und davon vor allem die, die nicht ständig die neuesten Libs benötigen. Mit solchen wäre das gut umsetzbar, ohne bei der alten Version in stable hängen bleiben zu müssen.
Von Grenzgänger am Do, 11. Oktober 2018 um 10:19 #
Debian bietet Backports.
Du hast nicht wirklich verstanden, was dir dein Vorposter vermitteln wollte.
Das Backports Angebot müsste lediglich noch etwas weiter ausgebaut werden, vor allem um die Endanwendersoftware und davon vor allem die, die nicht ständig die neuesten Libs benötigen. Mit solchen wäre das gut umsetzbar, ohne bei der alten Version in stable hängen bleiben zu müssen.
Falsch, die Debian Entwickler und Maintainer konzentrieren sich - völlig richtig - auf den Langzeitsupport. Ein Indiz für dich sollte sein, dass die Backports nicht durch das Security-Team betreut wird. Die Backports werden eher Stiefmütterlich behandelt.
Ein Indiz für dich sollte sein, dass die Backports nicht durch das Security-Team betreut wird. Die Backports werden eher Stiefmütterlich behandelt.
Dass die Sicherheitspolitik bei den Debian Backports verbesserungswürdig sind, sehe ich auch so.
Aber die Wahrscheinlichkeit dass man sich mit flatpacks mehr Sicherheitslücken installiert, als über die Backports ist weitaus größer, weil auch die flatpacks selbst eine wesentlich größere Angriffsfläche bieten. Da ist nämlich nicht nur diese eine Endanwendersoftware dabei, sondern auch noch ein paar Dutzend libs. Bei den Backports ist diese eine Endanwendersotware oft nur gegen die libs aus main compiliert und die libs aus main, die kriegen wiederum Sicherheitspatches.
Du hast das schlimmste Ereignis bei Debian vergessen.
Die Ersetzung der cdrtools durch cdrkit. Letzteres hat bei mir nicht nur jede Menge CDs kaputt gebrannt, sondern der Maintainer hat es zwar geforgt und behauptet, er kriegt was besseres hin, aber nach ein paar Monaten wurde dann der Support eingestellt.
Ich hätte daher ganz gerne ein cdrtools in wenigstens Debian non-free, wenn es schon nicht in main klappt. Und wenn das nur im Source vorliegen darf, dann eben als Script, das mir das Ding baut.
OpenMandriva und OpenSUSE haben cdrtools jedenfalls wieder eingebaut.
Deutlicher hättest du mir meine Ängste nicht vor Augen führen können
Ohne solche Erwartungen zumindest Optional zu erfüllen wird Linux aber vermutlich nie wirklich relevante Anteile am Markt (abseits der Server) ergattern können. Das gefällt mir zwar auch nicht so ganz aber ich persönlich kann (zum Beispiel in form von Flatpak's) damit leben.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 09. Okt 2018 um 14:13.Deutlicher hättest du mir meine Ängste nicht vor Augen führen können :shock:
Dann hätten die GNU/Linux Distros mal die Probleme beseitigen müssen. Man hat aber lieber mit jeder Distro Version ein neues Snapshot vom Upstream erstellt was inkompatible mit älteren Anwendungen ist. Je nach Distro kann dieser Snapshot wenige Stunden, Tage, Wochen oder Monate alt sein, oder mehrere Jahre.
Ich will nicht mal wissen wie viele Stunden vollkommen nutzlos verschwendet worden sind durch das "Maintainen" der Distros. Das könnte man auch gemeinsam im Upstream machen.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 09. Okt 2018 um 18:41.Und genau deshalb ist die wahrscheinlich wichtigste Distro, Debian, so erfolgreich?! Da werden Jahre alte Programmstände "maintained". Upstream hat eben vollkommen andere Ziele als Debian und dennoch arbeiten die Maintainer und Upstream meist gut zusammen. Ich habe mit dem gut abgehangenen Debian exzellente Erfahrung gemacht und kann daher kein Problem erkennen.
Der Upstream ist nicht immer mit Debians Politik glücklich und oft auch Kontraproduktiv. Ein Beispiel aus der nicht zu fernen Vergangenheit war xscreensaver. Der Upstream war sehr verärgert weil Debian eine alte Version weiterhin verteilt obwohl sie Fehlerbehaftet war. Die Fehler aus der alten Version wurden in Debian nicht beseitigt und so haben sich User weiterhin beim Upstream darüber beklagt. Dieser hat daraufhin eine Überprüfung der Version in ihre Software eingebaut und beim erkennen einer neuen Version darauf hingewiesen. Der Maintainer hat die Meldung über die neue Version einfach entfernt.
Oder Owncloud/Nextcloud. Debian bestand auf einer Version für die es nur noch Sicherheitsfixes geben sollte. Das Releasemodell passte aber da nicht dazu und so mussten die User mit einer sehr alten Version auskommen und ein Upgradepfad wurde extrem erschwert bis Unmöglich.
Ein Klassischer Fall ist auch ffmpeg und avconv. Der Debain Maintainer war auf Seiten von avconv und hat erst mal ffmpeg raus geworfen es für depricated und totes Projekt erklärt. Bei avconv wurde schnell die Kompatibilität fallen gelassen das alle Scripte nicht mehr liefen und man hat dennoch lib Namen übernommen die es fast unmöglich machten beides gleichzeitig zu nutzen.
Hier wurde also nun noch mehr Arbeit in das Patchen von Upstream Projekten investiert die ffmpeg nutzen damit man den Willen einer Person umsetzen konnte. Denn darüber gab es keinen Diskurs ob man nun weiterhin ffmpeg nutzen wolle oder auf den Fork wechseln wollte.
Aber noch mal zum eigentlichen Thema der alten Anwendungen. Ich habe nichts gegen alte Version. Mein Problem ist das ja nicht nur Debian solch alten Versionsstände pflegt. Auch Ubuntu macht das für ihre LTS Versionen die mal jünger oder älter sein können als das was ich in Debian Stable bekomme. Auch Red Hat und Suse pflegen teils alte Versionen über einen längeren Zeitraum.
Jeder macht das nur für sich alleine.
Genau hier setzt meine Kritik an. Man verschwendet unglaublich viel Arbeitszeit in das Pflegen seiner eigenen kleinen alten Version. Wenn man das im Upstream bündelt, könnten viele Entwickler sich mit wichtigerem Beschäftigen. Aber dann müsste man ja zusammenarbeiten und noch schlimmer, mit einander Sprechen.
Dann ist da noch das große was, wäre, wenn. Wenn ich doch mal neue Versionen einer Lib oder Anwendung brauche lässt einen Debian und co. vollkommen im Regen stehen. Dann geht das gebastelt los was erst mal die richtigen Löcher aufreißt. Oder noch schlimmer, das einbinden von Fremdquellen.
Mein Rechner mit Debian 9 fasse ich daher nun eine sehr lange Zeit nicht mehr an. Denn ein Upgrade wird wohl nicht mehr sauber funktionieren oder alles was ich am Repo vorbei erledigen musste würde nach einem Upgrade garantiert nicht mehr laufen.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 10. Okt 2018 um 13:07.Mir ist schon bewusst, dass es nicht konfliktfrei ist, deshalb schrieb ich "meist" und habe darauf hingewiesen, dass Upstream und Debian "völlig unterschiedliche Ziele" haben. Klar will ein Entwickler, dass "seine" User immer die aktuellste Version nutzen, da er keine Bug-Reports von alten Versionen bekommen möchte und seine neuesten Features präsentieren möchte. Nur wie will man eine rock solid Distro hinbekommen, wenn man nicht wie Debian arbeitet? Es ist schon der richtige Weg, einen Stand einzufrieren und diesen dann nur noch zu patchen. Sonst hat man eine rolling Distro und die ist eben NICHT vergleichbar mit Debian.
Es reicht eben nicht, miteinander zu sprechen. Man müsste auch die gleichen Ziele verfolgen und das tut man eben nicht. Das ist keine Kritik an einer der Seiten, sondern eine nüchterne Feststellung. Ich kann hervorragend damit leben, dass ich mit Debian eine etwas veraltete, aber dafür sehr stabile Distro habe. Wenn ich mal eine spezielle aktuelle Version einer Software benötige, dann installiere ich mir ein Flatpak, von dem ich weiß, dass es auch regelmäßig aktualisiert wird. Für mich ist das eine großartige Ergänzung. Ich nutze also Debian stable (ohne weitere Fremdquelle) plus 2-3 Flatpaks. Und wer andere Präferenzen hat, der kann ja eine rolling-Distro verwenden.OT: Dein erstes Beispiel:
Das ist eine freundliche Untertreibung! Der Entwickler von xscreensaver hatte eine Popup-Timebomb eingebaut, um Debian/Ubuntu-User zu ärgern.Ich störe mich nicht prinzipiell an der Arbeitsweise von Debian. Denn genau das will ich ja in der Regel. Ein stabiles System an dem ich nicht alle paar Wochen Handanlegen muss weil ein Patch etwas kaputt gemacht hat.
Ich kritisiere die mangelnde Zusammenarbeit in der Langzeitpflege unter den Distributionen. Diese Zusammenarbeit klappt nicht mit jedem wie du selbst ja auch schon sagst. Aber das ist auch nicht schlimm, denn ich kann mir ja anschauen wer ähnliche oder die gleichen Ziele verfolgt. Dabei lande ich idr. bei Ubuntu LTS, Red Hat und Suse. Aber jeder macht sein eigenes Ding. Wenn die vier im Upstream ihre LTE Version einer Bibliothek oder Anwendung Maintainen wollen, glaube ich kaum das es abgelehnt wird. Ansonsten können die vier das noch immer gemeinsam Forken.
Dann kritisiere ich das z.B. Debian einen im Regen stehen lässt wenn ich doch mal was aktuelleres brauche. Ein Ausweichen auf selber compilieren, Frem-Repos oder gar ein weiteres Paketformat das getrennt vom System ihre Anwendung mitbringt halte ich für ganz furchtbare Lösungen.
Seit über 20 Jahren gibt es die zentralen Softwareverzeichnisse der Distributionen. Das Problem was wir heute haben hätte seit dem bereits gelöst sein können. Aber man will sich Absolut nur auf eine Version festlegen. Ich verstehe warum man es machen wollte, aber das entspricht nun mal nicht der Softwarelandschaft und auch nicht dem wie sich Entwickler verhalten.
Es kann ja erst mal die Stabile Default Version installiert werden, aber wenn ich eine aktuelle Version brauche soll es mir die auch geben können. Das ich dann die eine oder andere Bibliothek in zwei unterschiedlichen Versionen auf dem System habe ist bei Speichergrößen kein Problem.
Eine Rolling Release Distro löst auch nicht das Problem, denn wenn nicht alles dem mitgeht laufen Anwendungen die man extern installiert hat irgendwann nicht mehr.
Das ein oder andere Schätzchen findet man da durchaus. So z.B. das neue KiCad Version 5 für Debian stable, welches Standardmäßig eigentlich nur KiCad 4.x mitliefert.
Das Backports Angebot müsste lediglich noch etwas weiter ausgebaut werden, vor allem um die Endanwendersoftware und davon vor allem die, die nicht ständig die neuesten Libs benötigen. Mit solchen wäre das gut umsetzbar, ohne bei der alten Version in stable hängen bleiben zu müssen.
Du hast nicht wirklich verstanden, was dir dein Vorposter vermitteln wollte.
Falsch, die Debian Entwickler und Maintainer konzentrieren sich - völlig richtig - auf den Langzeitsupport.
Ein Indiz für dich sollte sein, dass die Backports nicht durch das Security-Team betreut wird.
Die Backports werden eher Stiefmütterlich behandelt.
Dass die Sicherheitspolitik bei den Debian Backports verbesserungswürdig sind, sehe ich auch so.
Aber die Wahrscheinlichkeit dass man sich mit flatpacks mehr Sicherheitslücken installiert, als über die Backports ist weitaus größer, weil auch die flatpacks selbst eine wesentlich größere Angriffsfläche bieten.
Da ist nämlich nicht nur diese eine Endanwendersoftware dabei, sondern auch noch ein paar Dutzend libs.
Bei den Backports ist diese eine Endanwendersotware oft nur gegen die libs aus main compiliert und die libs aus main, die kriegen wiederum Sicherheitspatches.
Du hast das schlimmste Ereignis bei Debian vergessen.
Die Ersetzung der cdrtools durch cdrkit.
Letzteres hat bei mir nicht nur jede Menge CDs kaputt gebrannt, sondern der Maintainer hat es zwar geforgt und behauptet, er kriegt was besseres hin, aber nach ein paar Monaten wurde dann der Support eingestellt.
Ich hätte daher ganz gerne ein cdrtools in wenigstens Debian non-free, wenn es schon nicht in main klappt.
Und wenn das nur im Source vorliegen darf, dann eben als Script, das mir das Ding baut.
OpenMandriva und OpenSUSE haben cdrtools jedenfalls wieder eingebaut.