Hi, als Linux-affiner Mensch bin ich natürlich für alle Computerthemen im Familienkreis der Ansprechpartner ;-/ Nun lese ich von Slowroll und überlege mir, ob damit eventuell die 12-18 monatigen Upgrades von Leap wegfallen könnten. Leider lese ich: https://de.opensuse.org/openSUSE:Slowroll und hier: "20. November 2023: Bitte beachten Sie den Kommentar des Packman-Administrators unter <https://lists.links2linux.de/pipermail/packman/2023-November/017648.html>. " und dort: "I do not have time a energy to debug these edge cases, as builds for Leap and TW are running successful. For the time being I cannot offer any help, Slowroll from Packman is not completely built. All available packages are roughly in their state since late September." Aber hier <https://news.opensuse.org/2024/01/19/clarifying-misunderstandings-of-slowroll/> und hier <https://news.opensuse.org/2024/09/02/slowroll-up/> sieht es so aus als wenn man Slowroll recht problemlos nutzen könnte. Wie ist denn da eure Erfahrung, die die Slowroll bereits einsetzen? Bernd
Am 04.10.24 um 18:12 schrieb bnacht:
Hi,
als Linux-affiner Mensch bin ich natürlich für alle Computerthemen im Familienkreis der Ansprechpartner ;-/
Nun lese ich von Slowroll und überlege mir, ob damit eventuell die 12-18 monatigen Upgrades von Leap wegfallen könnten.
...
Aber hier <https://news.opensuse.org/2024/01/19/clarifying-misunderstandings-of- slowroll/> und hier <https://news.opensuse.org/2024/09/02/slowroll-up/> sieht es so aus als wenn man Slowroll recht problemlos nutzen könnte.
Wie ist denn da eure Erfahrung, die die Slowroll bereits einsetzen?
Im Prinzip ist das ein Tumbleweed mit Downgrade auf Slowroll. Ich habe hier Slowroll auf meinem Laptop, ich mag den Gedanken: Einmal installieren und das war es. Keine Probleme soweit. Wie immer musst du vorher nachsehen, ob das was du brauchst für Slowroll vorhanden ist. Läuft wie vorher Tumbleweed, bekommt aber nicht ständig dessen Massenupdates, diese kommen verspätet so etwa alle 1-2 Monate gebündelt(!), die Sicherheitsupdate sollen sofort kommen. Mit anderen Worten: Ein abgehangenes Rolling Release. Du könntest ja eine virtuelle Maschine einrichten und das Updateverhalten über einem Monat beobachten. Gruß Peter
Am Freitag, 4. Oktober 2024, 18:12:29 CEST schrieb bnacht:
Aber hier <https://news.opensuse.org/2024/01/19/clarifying-misunderstandings-of-slowroll/> und hier <https://news.opensuse.org/2024/09/02/slowroll-up/> sieht es so aus als wenn man Slowroll recht problemlos nutzen könnte.
Slowroll kannst du benutzen. Das Problem sind andere Repos. Packman baut z.B. gegen factory, das kommt kurz danach in Tumbleweed. Slowroll könnte jetzt aber ältere libs beinhalten, sodass dann Pakete für Slowroll nicht in Packman bauen. Und Stefan Botter schriebt ja, das er keine Zeit hätte, so etwas zu ändern. Stephan
bnacht schrieb:
Aber hier <https://news.opensuse.org/2024/01/19/clarifying-misunderstandings-of-slowroll/>
und hier <https://news.opensuse.org/2024/09/02/slowroll-up/> sieht es so aus als wenn man Slowroll recht problemlos nutzen könnte.
Wie ist denn da eure Erfahrung, die die Slowroll bereits einsetzen?
Das würde mich durchaus auch interessieren. Oder allgemeiner, was ist denn jetzt die Richtung, die man am besten einschlägt, wenn man eigentlich bei Suse bleiben will? Ich mag eigentlich die Idee eines Rolling Release. Statt einmal im Jahr bei einem Release-Update "an mehreren Fronten" kämpfen zu müssen, weil mehrere Dinge angepasst werden müssen, ist die Anpasserei über das ganze Jahr "verschmiert", kann immer mal kommen, aber nicht so geballt. Auf der anderen Seite war Leap 15.0 das letzte Release, wo ich wirklich noch einiges anpassen musste. Seitdem gingen die Release-Updates "geschmeidiger". Das kann aber auch wieder daran liegen, dass das alles 15.x war. Tumbleweed habe ich vor längerer Zeit (müsste Mitte der Zehner Jahre gewesen sein) mal getestet und damals für nicht alltagstauglich befunden. Ich hatte mehrere Monate eine Test-VM, mit der ich realistisch getestet habe und eigentlich immer ging irgendwas nicht, was für mich wichtig war und es gab auch keine Workarounds dafür. Vielleicht habe ich auch nur zufällig Pech gehabt und vielleicht ist auch Tumbleweed besser geworden. Slowroll mit etwas gemächlicherem Herangehen an die Updates erschien mir dann als nächstbester Kompromiss. Aber als ich mich so vor einem Jahr mal damit beschäftigen wollte, habe ich den Eindruck gewonnen, dass das noch nicht so ganz ausgereift sei und mehr oder weniger ein Ein-Mann-Projekt, dessen Zukunft noch nicht ganz sicher sei. Ich hab's dann erst mal gelassen bzw. aufgeschoben. Wenn sich das geändert hat, um so besser. Und dann ist noch die Frage, wie geht es denn mit Leap weiter? Die Sache mit dem ALP-Traum ist ja vom Tisch, zumindest soll das kein Zwang werden. Aber da ist die Informations-Lage verwirrend, es wird immer noch gelegentlich das Gegenteil behauptet. Langer Rede kurzer Sinn: Ich habe im Moment keinen Anhaltspunkt, was am besten wäre. Ich muss aber auch nicht heute entscheiden. Leap 15.6 läuft ja sehr gut. -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel
Am 5. Oktober 2024 05:59:01 MESZ schrieb "Manfred Haertel, DB3HM" <Manfred.Haertel@rz-online.de>:
bnacht schrieb:
Aber hier <https://news.opensuse.org/2024/01/19/clarifying-misunderstandings-of-slowroll/> und hier <https://news.opensuse.org/2024/09/02/slowroll-up/> sieht es so aus als wenn man Slowroll recht problemlos nutzen könnte.
Wie ist denn da eure Erfahrung, die die Slowroll bereits einsetzen?
Das würde mich durchaus auch interessieren. Oder allgemeiner, was ist denn jetzt die Richtung, die man am besten einschlägt, wenn man eigentlich bei Suse bleiben will?
Ich mag eigentlich die Idee eines Rolling Release. Statt einmal im Jahr bei einem Release-Update "an mehreren Fronten" kämpfen zu müssen, weil mehrere Dinge angepasst werden müssen, ist die Anpasserei über das ganze Jahr "verschmiert", kann immer mal kommen, aber nicht so geballt.
Auf der anderen Seite war Leap 15.0 das letzte Release, wo ich wirklich noch einiges anpassen musste. Seitdem gingen die Release-Updates "geschmeidiger". Das kann aber auch wieder daran liegen, dass das alles 15.x war.
Tumbleweed habe ich vor längerer Zeit (müsste Mitte der Zehner Jahre gewesen sein) mal getestet und damals für nicht alltagstauglich befunden. Ich hatte mehrere Monate eine Test-VM, mit der ich realistisch getestet habe und eigentlich immer ging irgendwas nicht, was für mich wichtig war und es gab auch keine Workarounds dafür. Vielleicht habe ich auch nur zufällig Pech gehabt und vielleicht ist auch Tumbleweed besser geworden.
Slowroll mit etwas gemächlicherem Herangehen an die Updates erschien mir dann als nächstbester Kompromiss. Aber als ich mich so vor einem Jahr mal damit beschäftigen wollte, habe ich den Eindruck gewonnen, dass das noch nicht so ganz ausgereift sei und mehr oder weniger ein Ein-Mann-Projekt, dessen Zukunft noch nicht ganz sicher sei. Ich hab's dann erst mal gelassen bzw. aufgeschoben. Wenn sich das geändert hat, um so besser.
Und dann ist noch die Frage, wie geht es denn mit Leap weiter? Die Sache mit dem ALP-Traum ist ja vom Tisch, zumindest soll das kein Zwang werden. Aber da ist die Informations-Lage verwirrend, es wird immer noch gelegentlich das Gegenteil behauptet.
Langer Rede kurzer Sinn: Ich habe im Moment keinen Anhaltspunkt, was am besten wäre. Ich muss aber auch nicht heute entscheiden. Leap 15.6 läuft ja sehr gut.
1000% Zustimmung zum gesamten Text. Könnte von mir sein. :-) Gruß Eric
Am 05.10.24 um 5:59 AM schrieb Manfred Haertel, DB3HM:
Ich mag eigentlich die Idee eines Rolling Release. Statt einmal im Jahr bei einem Release-Update "an mehreren Fronten" kämpfen zu müssen, weil mehrere Dinge angepasst werden müssen, ist die Anpasserei über das ganze Jahr "verschmiert", kann immer mal kommen, aber nicht so geballt.
Ich finde eigentlich die Distros mit klassicheem Release besser, weil man da die harten Änderungen besser planen kann. Bei meinem TW muß ich quasi bei jedem Upgrade damit rechenen, dass irgendwas grob kaputt geht. snapper lindert das Problem zwar, dennoch finde ich das als Daliy Driver eher ungünstig. Viele Grüße Ulf
Am Samstag, 5. Oktober 2024, 12:48:48 CEST schrieb Ulf Volmer:
Am 05.10.24 um 5:59 AM schrieb Manfred Haertel, DB3HM:
Ich mag eigentlich die Idee eines Rolling Release. Statt einmal im Jahr bei einem Release-Update "an mehreren Fronten" kämpfen zu müssen, weil mehrere Dinge angepasst werden müssen, ist die Anpasserei über das ganze Jahr "verschmiert", kann immer mal kommen, aber nicht so geballt.
Ich finde eigentlich die Distros mit klassicheem Release besser, weil man da die harten Änderungen besser planen kann. Bei meinem TW muß ich quasi bei jedem Upgrade damit rechenen, dass irgendwas grob kaputt geht. snapper lindert das Problem zwar, dennoch finde ich das als Daliy Driver eher ungünstig.
Viele Grüße Ulf
Hallo, dem stimme ich voll zu. Ich mache ein Distri Upgrade, wenn ich Zeit zum Troubleshooten habe und davor mach ich natürlich ein Backup der Systempartitionen. Ja, mit Snapshots kann man auch jederzeit zurückgehen und das fehlerhafte Paket dann sperren, aber das ist auch nicht das, was ich auf Dauer möchte. Die Frage ist, wie häufig solche Probleme bei TW auftreten. Ich verwende es nicht und kann daher dazu nichts sagen. Die letzten Distri-Upgrades machten jedenfalls nur wenige Problem, die durch die Umstände des Setups begründet waren. Grüße Richard
Am 05.10.24 um 13:40 schrieb Richard Hafenscher:
Am Samstag, 5. Oktober 2024, 12:48:48 CEST schrieb Ulf Volmer:
Am 05.10.24 um 5:59 AM schrieb Manfred Haertel, DB3HM: ... Ich finde eigentlich die Distros mit klassicheem Release besser, weil man da die harten Änderungen besser planen kann. Bei meinem TW muß ich quasi bei jedem Upgrade damit rechenen, dass irgendwas grob kaputt geht. snapper lindert das Problem zwar, dennoch finde ich das als Daliy Driver eher ungünstig.
dem stimme ich voll zu. Ich mache ein Distri Upgrade, wenn ich Zeit zum Troubleshooten habe und davor mach ich natürlich ein Backup der Systempartitionen. ... Auch ich stimme dem voll zu, allerdings: Aus der Diskussion pro/kontra openSUSE Alp entnahm ich, dass schlichtweg nicht genügend Freiwillige für die Alp-Variante plus der klassische Distribution vorhanden sind und der Schwerpunkt der Ressourcen auf die ALP-Variante gelegt werden soll. Verständlich, wenn man bedenkt, dass der Bau von Distries wie openSUSE in der Regel von unbezahltem Enthusiasten bewerkstelligt und wenn die ihren Lebensunterhalt eher im ALP Umfeld verdienen, werden sie auch eher dort mitarbeiten.
Was soll's, so aufwendig wie seinerzeit der Wechsel von Windows zu Linux wird die Umstellung von der klassischen Distribution zu ALP nicht werden, wenn der Unterschied zwischen klassischer Distri und ALP einem Anwender überhaupt auffällt. Gruß Peter
Am 5. Oktober 2024 16:48:05 MESZ schrieb Peter McD <peter.posts@gmx.net>:
Am 05.10.24 um 13:40 schrieb Richard Hafenscher:
Am Samstag, 5. Oktober 2024, 12:48:48 CEST schrieb Ulf Volmer:
Am 05.10.24 um 5:59 AM schrieb Manfred Haertel, DB3HM: ... Ich finde eigentlich die Distros mit klassicheem Release besser, weil man da die harten Änderungen besser planen kann. Bei meinem TW muß ich quasi bei jedem Upgrade damit rechenen, dass irgendwas grob kaputt geht. snapper lindert das Problem zwar, dennoch finde ich das als Daliy Driver eher ungünstig.
dem stimme ich voll zu. Ich mache ein Distri Upgrade, wenn ich Zeit zum Troubleshooten habe und davor mach ich natürlich ein Backup der Systempartitionen. ... Auch ich stimme dem voll zu, allerdings: Aus der Diskussion pro/kontra openSUSE Alp entnahm ich, dass schlichtweg nicht genügend Freiwillige für die Alp-Variante plus der klassische Distribution vorhanden sind und der Schwerpunkt der Ressourcen auf die ALP-Variante gelegt werden soll. Verständlich, wenn man bedenkt, dass der Bau von Distries wie openSUSE in der Regel von unbezahltem Enthusiasten bewerkstelligt und wenn die ihren Lebensunterhalt eher im ALP Umfeld verdienen, werden sie auch eher dort mitarbeiten.
Was soll's, so aufwendig wie seinerzeit der Wechsel von Windows zu Linux wird die Umstellung von der klassischen Distribution zu ALP nicht werden, wenn der Unterschied zwischen klassischer Distri und ALP einem Anwender überhaupt auffällt.
Nicht auffällt? Wenn der heilige Softwarekrahl dann flatpack ist? Nene. Nicht mit mir. Wenn ich nur daran denke, dass wenn man ein Softwarepaket installiert und dann dreimal das rootpasswort eingeben muss. Intransparenter kann das nicht mehr sein. Gruß Eric
Am 05.10.24 um 19:00 schrieb Eric Schirra:
... Was soll's, so aufwendig wie seinerzeit der Wechsel von Windows zu Linux wird die Umstellung von der klassischen Distribution zu ALP nicht werden, wenn der Unterschied zwischen klassischer Distri und ALP einem Anwender überhaupt auffällt.
Nicht auffällt? Wenn der heilige Softwarekrahl dann flatpack ist? Nene. Nicht mit mir.
Wenn ich nur daran denke, dass wenn man ein Softwarepaket installiert und dann dreimal das rootpasswort eingeben muss. Intransparenter kann das nicht mehr sein.
Wie heiß das so schön im Englischen: Milage varies. Ich habe hier zwei Pakete von Flatpak und nichts dergleichen in Erinnerung. Ich sehe das pragmatisch. Ich nutze ein kostenloses Produkt und beklage mich nicht. Es ist halt nun mal so, dass für die Paketzusammenstellung und Wartung Arbeitskraft benötigt wird, wo die fehlt geht es Richtung Flatpak, wo siehst du da eine Alternative? Wenn das Paket für die Disti nur von Flatpak angeboten wird, beißt man in diesen sauren Apfel oder kompiliert selbst oder wechselt die Disti, je nachdem wo die Prioritäten liegen. Gruß Peter
participants (7)
-
bnacht -
Eric Schirra -
Manfred Haertel, DB3HM -
Peter McD -
Richard Hafenscher -
Stephan Hemeier -
Ulf Volmer