Suse versteht wohl endlich, dass Opensuse auch eine Art Testfeld für SLES12 und 15 darstellt und da sind zum einen LTS-ähnliche Unterstützungszyklen zum einen und reibungslose Updates zur Leap-Folgeversion und zu den SLES-Parallel-Versionen zum anderen sehr wichtig.
Außerdem kann man Leap 42.3 auch auf das viel länger unterstützte SLES12 hochziehen. Läuft Leap 42.3, gibt es auch keine Überraschungen mit SLES12.
Auch wenn es bei Suse niemand hören will: Leap ist Suses CentOS und CentOS hat Red Hat nicht im geringsten geschadet.
Zumindest Niedersachsen könnte die Linuxe mit Leap 42.2 auf Opensuse Leap 42.3 hochziehen und dann auf Opensuse Leap 15 oder SLES 12 oder SLES 15. Nirgendwo existiert hier irgendeine Art von Support-Sackgasse mit Suse/Opensuse.
Na ja, das scheint schon ein recht spezielles Problem zu sein: "running Leap 15.0 in a KVM virtual machine" und dann auch nur mit einem bestimmten grafischen Backend (QXL). Ich habe auf meiner "echten" Maschine keinerlei Probleme mit .12.14-lp150.12.10-default.
Und BTW: "Reported: 2018-08-07 22:35 UTC" - "The next kernel update including the fix for this bug is on the way. 2018-08-09 13:00:26 UTC" Ist doch in Ordnung, passiert bei anderen Distributionen auch mal.
Übrigens finde ich, diese ganze Geschichte spricht sehr FÜR die Theorie, das Leap mittlerweile zur Qualitätssicherung für SLE verwendet wird. Man hat einfach noch mal mehr Tester für das Basissystem. Wie CentOS für RedHat, da hat der Vorposter schon recht.
Und nein, so etwas ist mit in mehr als 11 Jahren auf den Rechner ohne Suse/openSuse noch nie passiert. Meiner Meinung nach ist das Verhältnis genau umgedreht: Ohne SLE wäre openSuse schon längst den Bach runter gespült.
Ich bin mal wieder böse: Ich verwende Suse wegen 42.3 derzeit nicht mehr. Dass man anfangs nach einem Update noch einiges erst wieder zum Laufen gebracht werden muss, ist bei Suse normal. Aber zumindest auf meiner damals neu gekauften Hardware war es diesmal so weit, dass ich mich gefragt hatte, was das gerade soll.
Da hatte ich neben meinem Job auch so viel zu tun, dass ich keinen Bock auf Bugreports hatte. Opensuse hat da einfach zu viel Zeit verbraucht.
Da stimmt irgendwas prinzipielles nicht. Eventuell wird Opensuse nicht ernsthaft von Suse in einem Hardwarelabor getestet. Schon garnicht mit KDE, Nvidia mit Display Port High Dpi, Wayland (das habe ich leider viel zu spät wieder rausgeschmissen) und einigem mehr.
Edit: Sorry. Auf dem Foto habe ich den BRTFS-Fehler mit Ubuntu hinbekommen (BRTFS critical (device ...): corrupt node, bad key order: block=... --- [ end kernel panic - not ...). Da hatte so einiges nicht funktioniert.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 10. Aug 2018 um 01:32.
Meiner Meinung nach ist das Verhältnis genau umgedreht: Ohne SLE wäre openSuse schon längst den Bach runter gespült.
Das openSUSE mit der Kapazität im Projekt so seine Probleme hat, ist bekannt und unbestritten. Tumbleweed funktioniert wohl recht gut, das "klassische" openSUSE war relativ verwaist.
Trotzdem, versuch es doch mal so zu sehen: Die Nutzung des Basissystems von SLE bringt beiden Seiten etwas: openSUSE kann weiter ein nicht-Rolling-Release herausbringen, indem die Enterprise-Basis benutzt wird. SUSE profitiert in einem gewissen Rahmen aber ebenfalls, denn genau diese Enterprise-Basis wird auf noch mehr Geräten installiert und im echten Leben getestet. Außerdem kann man so Interessierte mit openSUSE Leap beginnen lassen und später vielleicht davon überzeugen, auf SLE zu wechseln. Oder zumindest auf Leap Software für SLE zu entwickeln (statt zur Konkurrenz zu gehen).
ein gewisser unterschied besteht schon CentOS ist RH ohne Support mit anderem Branding. Leap ist SLE Unterbau + diverse Aktualisierungen.
Man sollte sich viel mehr hinterfragen, warum man bei derartigen Großprojekten nicht auf SLES/SLED mit garantierten Support setzt. Statt dessen nimmt man sich irgendeine kostenfrei verfügbare Distribution und verbastelt diese solange, bis Updates nicht mehr möglich sind und hält diesen "Bastard" so lange wie möglich am laufen. Irgendwann kommt der Knall.
Die Lösung ist doch einfach, entweder man kauft sich ein Enterpriselinux ein und bastelt da nichts dran rum. Oder die Alternative, man entwickelt eine komplett eigenständige Behördendistribution, welche von einem festen Entwicklerstamm gepflegt wird und ohne große Eingriffe mit der passenden Software für die einzelnen Behörden ergänzt wird.
ein gewisser unterschied besteht schon CentOS ist RH ohne Support mit anderem Branding. Leap ist SLE Unterbau + diverse Aktualisierungen.
Da hast Du recht, das Modell ist nicht exakt identisch. Geht aber durch das Basissystem von SLE und den (für Leap 15) garantierten Migrationspfad zu SLE schon stark in die Richtung.
BTW: Für mich als Privatnutzer mit Desktopnutzung ist Leap wesentlich attraktiver als CentOS, eben weil noch "diverse Aktualisierungen", insbesondere bei Desktop und den Anwendungsprogrammen, enthalten sind. Wäre alles so abgehangen wie in CentOS oder Debian Stable, incl. Anwendungen, käme es für mich zur Nutzung nicht in Frage, da ich gerne leidlich moderne Anwendungen haben möchte. Das Basissystem darf dagegen "veraltet" sein.
Was die Nutzung für ein Großprojekt angeht, stimme ich Dir zu: Ich würde da auch zu einem richtigen Enterprise-Linux raten, wenn man den Aufwand einer Migration alle 1-2 Jahre scheut. Gibt ja mit CentOS sogar eine kostenlose Variante, die über 10 Jahre und mehr gepflegt wird. Solange die Fachanwendungen laufen, wäre das doch egal, ob es "alt" ist.
> Man sollte sich viel mehr hinterfragen, warum man bei derartigen Großprojekten nicht auf SLES/SLED mit garantierten Support setzt. Statt dessen nimmt man sich irgendeine kostenfrei verfügbare Distribution und verbastelt diese solange, bis Updates nicht mehr möglich sind und hält diesen "Bastard" so lange wie möglich am laufen. Irgendwann kommt der Knall.
Schon richtig. Aber das kann im Fall Niedersachsen kein Grund gewesen sein. Ein Upgrade selbst von oS-12.3/-13.2 auf ein aktuelles oS-Leap oder eben SLE wäre doch wohl um ein Vielfaches leichter als die komplette Umstellung auf Windows.
Es handelt sich hier um eine politische Entscheidung. Und *die* sollte man mal hinterfragen. Wäre eigentlich Aufgabe der Opposition. Aber vielleicht gibt es die ja nicht in NS.
Sofern die entweder kein KDE einsetzen oder KDE4 für 42.3 ausgiebig getestet ist. Ansonsten wäre das eine Migration, die man nicht unterschätzen sollte. Suse sollte Niedersachsen einfach ein unschlagbares Angebot machen und da selbst für sorgen, dass es weitergeht.
Eventuell hat Suse ja sogar das Recht, bei der Ausschreibung berücksichtigt zu werden und kann das einklagen.
https://www.pro-linux.de/-0h21660f
"Die eingesetzte Opensuse-Version hätte offenbar wieder einmal ein Update nötig" (Ja es ist Leap 42 laut Heise)
Das verschafft ihnen eine Zeitspanne von 6 Monaten um erfolgreich auf Windows zu korruptieren...nicht.
Suse versteht wohl endlich, dass Opensuse auch eine Art Testfeld für SLES12 und 15 darstellt und da sind zum einen LTS-ähnliche Unterstützungszyklen zum einen und reibungslose Updates zur Leap-Folgeversion und zu den SLES-Parallel-Versionen zum anderen sehr wichtig.
Außerdem kann man Leap 42.3 auch auf das viel länger unterstützte SLES12 hochziehen. Läuft Leap 42.3, gibt es auch keine Überraschungen mit SLES12.
Auch wenn es bei Suse niemand hören will: Leap ist Suses CentOS und CentOS hat Red Hat nicht im geringsten geschadet.
Zumindest Niedersachsen könnte die Linuxe mit Leap 42.2 auf Opensuse Leap 42.3 hochziehen und dann auf Opensuse Leap 15 oder SLES 12 oder SLES 15. Nirgendwo existiert hier irgendeine Art von Support-Sackgasse mit Suse/Opensuse.
Jetzt hab' ich aber gelacht!
3 Eimer voll, die keiner auskippen wollte!
Das habe ich das erste mal gehört, so um das Ende von SuSE 9.3 herum, als die ersten drastischen Einbrüche in der Qualität durch "open"SUSE kamen.
Nachtrag
Deswegen rollt man seit gestern offenbar mal wieder mit dem 4.12.14-lp150.12.10-default ein kaputten Kernel aus.
https://lists.opensuse.org/opensuse-bugs/2018-08/msg00882.html
Na ja, das scheint schon ein recht spezielles Problem zu sein: "running Leap 15.0 in a KVM virtual machine" und dann auch nur mit einem bestimmten grafischen Backend (QXL).
Ich habe auf meiner "echten" Maschine keinerlei Probleme mit .12.14-lp150.12.10-default.
Und BTW: "Reported: 2018-08-07 22:35 UTC" - "The next kernel update including the fix for this bug is on the way. 2018-08-09 13:00:26 UTC"
Ist doch in Ordnung, passiert bei anderen Distributionen auch mal.
Übrigens finde ich, diese ganze Geschichte spricht sehr FÜR die Theorie, das Leap mittlerweile zur Qualitätssicherung für SLE verwendet wird. Man hat einfach noch mal mehr Tester für das Basissystem.
Wie CentOS für RedHat, da hat der Vorposter schon recht.
Es haut auch Rechner mit Nvidia/Nouveau und AMG-GPU-Treibern raus.
z.B.
https://lists.opensuse.org/opensuse-de/2018-08/msg00040.html
Und nein, so etwas ist mit in mehr als 11 Jahren auf den Rechner ohne Suse/openSuse noch nie passiert.
Meiner Meinung nach ist das Verhältnis genau umgedreht: Ohne SLE wäre openSuse schon längst den Bach runter gespült.
Ich bin mal wieder böse: Ich verwende Suse wegen 42.3 derzeit nicht mehr. Dass man anfangs nach einem Update noch einiges erst wieder zum Laufen gebracht werden muss, ist bei Suse normal. Aber zumindest auf meiner damals neu gekauften Hardware war es diesmal so weit, dass ich mich gefragt hatte, was das gerade soll.
Da hatte ich neben meinem Job auch so viel zu tun, dass ich keinen Bock auf Bugreports hatte. Opensuse hat da einfach zu viel Zeit verbraucht.
Da stimmt irgendwas prinzipielles nicht. Eventuell wird Opensuse nicht ernsthaft von Suse in einem Hardwarelabor getestet. Schon garnicht mit KDE, Nvidia mit Display Port High Dpi, Wayland (das habe ich leider viel zu spät wieder rausgeschmissen) und einigem mehr.
Edit: Sorry. Auf dem Foto habe ich den BRTFS-Fehler mit Ubuntu hinbekommen (BRTFS critical (device ...): corrupt node, bad key order: block=... --- [ end kernel panic - not ...). Da hatte so einiges nicht funktioniert.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 10. Aug 2018 um 01:32.Trotzdem, versuch es doch mal so zu sehen: Die Nutzung des Basissystems von SLE bringt beiden Seiten etwas:
openSUSE kann weiter ein nicht-Rolling-Release herausbringen, indem die Enterprise-Basis benutzt wird.
SUSE profitiert in einem gewissen Rahmen aber ebenfalls, denn genau diese Enterprise-Basis wird auf noch mehr Geräten installiert und im echten Leben getestet. Außerdem kann man so Interessierte mit openSUSE Leap beginnen lassen und später vielleicht davon überzeugen, auf SLE zu wechseln. Oder zumindest auf Leap Software für SLE zu entwickeln (statt zur Konkurrenz zu gehen).
Eben genau das CentOS-Modell.
ein gewisser unterschied besteht schon
CentOS ist RH ohne Support mit anderem Branding.
Leap ist SLE Unterbau + diverse Aktualisierungen.
Man sollte sich viel mehr hinterfragen, warum man bei derartigen Großprojekten nicht auf SLES/SLED mit garantierten Support setzt. Statt dessen nimmt man sich irgendeine kostenfrei verfügbare Distribution und verbastelt diese solange, bis Updates nicht mehr möglich sind und hält diesen "Bastard" so lange wie möglich am laufen. Irgendwann kommt der Knall.
Die Lösung ist doch einfach, entweder man kauft sich ein Enterpriselinux ein und bastelt da nichts dran rum. Oder die Alternative, man entwickelt eine komplett eigenständige Behördendistribution, welche von einem festen Entwicklerstamm gepflegt wird und ohne große Eingriffe mit der passenden Software für die einzelnen Behörden ergänzt wird.
Geht aber durch das Basissystem von SLE und den (für Leap 15) garantierten Migrationspfad zu SLE schon stark in die Richtung.
BTW: Für mich als Privatnutzer mit Desktopnutzung ist Leap wesentlich attraktiver als CentOS, eben weil noch "diverse Aktualisierungen", insbesondere bei Desktop und den Anwendungsprogrammen, enthalten sind. Wäre alles so abgehangen wie in CentOS oder Debian Stable, incl. Anwendungen, käme es für mich zur Nutzung nicht in Frage, da ich gerne leidlich moderne Anwendungen haben möchte. Das Basissystem darf dagegen "veraltet" sein.
Was die Nutzung für ein Großprojekt angeht, stimme ich Dir zu: Ich würde da auch zu einem richtigen Enterprise-Linux raten, wenn man den Aufwand einer Migration alle 1-2 Jahre scheut. Gibt ja mit CentOS sogar eine kostenlose Variante, die über 10 Jahre und mehr gepflegt wird.
Solange die Fachanwendungen laufen, wäre das doch egal, ob es "alt" ist.
> Man sollte sich viel mehr hinterfragen, warum man bei derartigen Großprojekten nicht auf SLES/SLED mit garantierten Support setzt. Statt dessen nimmt man sich irgendeine kostenfrei verfügbare Distribution und verbastelt diese solange, bis Updates nicht mehr möglich sind und hält diesen "Bastard" so lange wie möglich am laufen. Irgendwann kommt der Knall.
Schon richtig. Aber das kann im Fall Niedersachsen kein Grund gewesen sein. Ein Upgrade selbst von oS-12.3/-13.2 auf ein aktuelles oS-Leap oder eben SLE wäre doch wohl um ein Vielfaches leichter als die komplette Umstellung auf Windows.
Es handelt sich hier um eine politische Entscheidung. Und *die* sollte man mal hinterfragen. Wäre eigentlich Aufgabe der Opposition. Aber vielleicht gibt es die ja nicht in NS.
Sofern die entweder kein KDE einsetzen oder KDE4 für 42.3 ausgiebig getestet ist. Ansonsten wäre das eine Migration, die man nicht unterschätzen sollte. Suse sollte Niedersachsen einfach ein unschlagbares Angebot machen und da selbst für sorgen, dass es weitergeht.
Eventuell hat Suse ja sogar das Recht, bei der Ausschreibung berücksichtigt zu werden und kann das einklagen.
2006 war es KDE.