*Was* läuft gut? Die alte 42.2 oder die neue Version 42.3? Und was will uns das jeweils sagen? Bisschen Redundanz hilft manchmal bei der eindeutigen Dechiffrierung von Botschaften...
Dem kann ich mich anschließen. Leap ist sehr stabil und mit den richtigen Repos fast immer aktuell.
Hab vorher Tumbleweed drauf gehabt. Leider hatte ich damit aber zu oft Schwierigkeiten, gerade mit verschlüsselter Festplatte kann ich Tumbleweed nicht empfehlen. Mein System wurde vier mal zu Schrott upgedatet, weil irgendetwas nicht funktioniert und ich die Festplatte nicht entschlüsseln konnte. Anscheinend arbeiten zu Wenige mit verschlüsselten Festplatten um solche gravierenden Fehler, vor Freigabe neuer Snapshots, zu entdecken.
Nach dem Desaster mit Tumbleweed bin ich auf Leap umgestiegen. Ich muss sagen, es läuft! Bisher keine Probleme gehabt. Ein paar mal ist die Taskleiste abgestürzt, doch die taucht meistens innerhalb von wenigen Sekunden wieder auf. Ich habe Leap mit den entsprechenden Repos auch aufgebohrt und nur bei den Paketen einen Repowechsel gemacht wo es notwendig war. Den Leap-Unterbau lasse ich weitestgehend unverändert.
Hab auch Plasma 5.10 ausprobiert, aber einige Anwendungen gingen nicht mehr und auf die Tumbleweed Pakete wollte ich nicht zurückgreifen. Wie hast du dieses Problem gelöst?
Ich hab seit langem Tumbleweed drauf, nicht das geringste Problem. Grund unter 42.2 kein Eingabefenster für die Passphrase der verschlüsselten Partitionen, hab ich dann über zusatz Repos mit neuerem X-Server gelöst, hats aber nicht lange Spaß gemacht, weil die Abhängigkeiten irgendwann auseinandergelaufen sind.
Dann auf Tumbleweed umgestiegen, wenn man bleeding edge HW hat, kommt man ab und zu nicht an hoch aktuellen Distris vorbei.
Was bei Tumbleweed allerdings nervt, dass sie jede Woche hunderte von Paketen ziehen muss, irgendnen Tod stirbt man. Drum bin ich auch seit 15 Jahren nicht mehr bei Gentoo, eigentlich soll der Rechner nur laufen, ist nicht zum rumspielen gedacht.
Wie gut läuft denn das Upgrade von Y.X auf Y.X+1 ab? Habe mich heute mal umgeschaut, da muss ja eine Reihe von Hand gemacht werden und so 100% sauber läuft es ja auch nicht durch. An sich hört sich das Upgrade-Prozedure so ähnlich an wie bei Fedora mit FedUp. So richtig überzeugt bin ich von solchen Verfahren ehrlich gesagt ja eher nicht.
Hat bei mir schon nicht funktioniert. Zumindest nicht in der VB. Da gehört ein bisschen mehr dazu, als diese 4 Zeilen. War bei mir bei Upgrade von 42.1 auf 42.2 auch so.
Vermutlich keine oder nur sehr wenige und gute Drittrepos. Da man nicht weiß wie das System des anderen aussieht sollte man mit derartigen "Anleitungen" vorsichtig umgehen. Die zwei Minuten mehr sollte man sich jedenfalls nehmen.
Du hast bestimmt ca. 1GB neue Rpms heruntergeladen, nur um nach einem Upgrade von Leap 42.2 auf 42.3 immer noch die gleiche KDE Plasma-Version, die gleiche Gnome3-Version, die gleiche Glibc-Version und die gleiche Kernelversion wie in Leap 42.2 zu haben.
Das gesamte derzeitige openSUSE-Konstrukt sehe ich als Armutszeugnis für die Rester der SUSE Community und ein leider aber nicht offen ausgeprochenes Eingeständnis, dass man eigentlich nicht in der Lage ist aus eigener Kraft eine akzeptable Distribution zu Stande zu bringen.
"Habe ich jetzt weniger Platz oder Software doppelt? "
Nein, nein.
Du hast Dir offenbar die gleichen Softwareversionen nochmals heruntergeladen und damit die vorher schon auf Deinem Rechner befindliche 42.2-Software größtenteils mit neuer 42.3-Software in der genau oder fast genau gleichen Version ersetzt.
Du hast also Glibc 2.22 aus Leap 42.3 heruntergeladen und damit die vorhandene Glibc 2.22 in Leap 42.2 ersetzt, also glibc-2.22-4.9.1 (42.2) durch glibc-2.22-8.4 (42.3). Das gleiche Spiel hast Du u.a. mit dem Kernel 4.4 wiederholt: Der 42.2-Kernel kernel-default-4.4.74-18.20.1 wurde auf den 42.3-Kernel kernel-default-4.4.76-1.1 geupgradet und das bestimmt ganz ohne drpm-Option (die in Kürze bestimmt in Leap 42.2 angeboten wird, um auf Kernel 4.4.76 oder 4.4.78 aktualisieren zu können).
Das war bestimmt das effektivste Distributionsupgrade aller Zeiten.
Wenn man so weiter verfährt, braucht man Leap 42.2 gar nicht in sechs Monaten für EOL zu erklären, denn Leap 42.3 und 42.2 scheinen ja ohnehin binärkompatibel zu sein.
Das ist eigentlich ein Fall für openSUSE Evergreen: Leap 42.2 wäre das am einfachsten supportbare openSUSE Evergreen, das es je gegeben hat.
Für Opensuse geht es offenbar genau hierum, um Versionitis. Ansonsten bräuchte man kein GB-fressendes Distributionsupgrade von 42.2 auf 42.3, wenn Leap 42.2 und 42.3 in punkto Software sowieso dasselbe sind. 42.3 ist 42.2, was für mich völlig o.k. wäre, wenn 42.3 samt GB-konsumierendem Quasi-Zwangsdistributionsupdate in 6 Monaten nicht existieren würde. 42.2 würde unterstützt werden bis Anfang 2019, fertig (siehe hierzu auch die Anmerkungen zur Lifetime von 42.2 weiter unten).
42.3 ist nichts weiter als ein Minor Point Release zu 42.2, so wie er in der Debian-Welt z.B. beim Update von Jessie 6.7 auf 6.8 vorkommt und genauso wie dieser schon zig Mal bei Opensuse 42.1 und 42.2 selbst vorgekommen ist (u.a. als Update des zugrundeliegenden Zypper-, KDE- oder Gnome-Stacks ohne Point Release-Bezeichnung).
Das Distributionsupgrade an sich von Leap 42.2 nach 42.3 ist somit vollkommen sinnlos. Man lädt sich nicht einen Haufen Software herunter, nur um nach dem Einspielen die genau gleiche Software wie zuvor zu haben. Ein 150MB- (nicht ein GB-) Update wäre natürlich o.k.
Denn Opensuse selbst hat ja einen wunderbaren Mechanismus für so etwas: drpm-Updates innerhalb einer Distributionsversion. Das macht ein neues, aber weitgehend identisches 42.3 mit traditionellem Distributionsupdate noch umso überflüssiger.
----------------------------
Und hier noch eine weitere Unstimmigkeit in punkto Lebensdauer: Jeder Leap-Zwischenrelease sollte ja 18 Monate Support bekommen.
Nur wird Leap 42.2 laut den eigenen Regeln (Veröffentlichungszeitpunkt der Folgeversion plus 6 Monate) nur 12 Monate unterstützt werden, da das EOL von Leap 42.2, das im November 42.2 erschien, in den Januar 2018 fallen wird. Leap 42.1 hatte wenigstens diese 18 Monate Support, von November 2015 bis Mai 2017, also sogar 19 Monate.
Irgendwie ist da etwas gehörig schief gelaufen.
Siehe hierzu https://en.opensuse.org/Lifetime
"A Leap Minor Release (42.1, 42.2, etc.) is expected to be released annually. Users are expected to upgrade to the latest minor release within 6 months of its availability, leading to a support life cycle of 18 months. "
Leap 42.3 kam demzufolge viel zu früh heraus, nämlich rund ein halbes Jahr.
Wenn man die Installation sauber gehalten hat, sollte nicht viel von Hand zu machen sein. Hat man keine Repos hinzugefügt sollte ein sed und zypper dup reichen (siehe https://en.opensuse.org/SDB:System_upgrade#Running_the_Upgrade ). Übrigens werden die Upgrades mittels openqa getestet. Zum Beispiel mittels DVD https://openqa.opensuse.org/tests/451704# oder mittels zypper dup https://openqa.opensuse.org/tests/451723#step/boot_to_desktop/1 . Wenn man zum Beispiel Repos hinzugefügt hat sollte man natürlich etwas überlegter vorgehen. Größere Probleme hatte ich dabei aber nie wobei das natürlich davon abhängt wie man mit seiner Installation umgeht.
Probleme hab ich beim eeePC. Da hängt die Installation nach dem HW-Check, die Installationspakete werden nicht gelesen. Hat jemand ne Idee? nomodeset acpi=off apm=off hab ich schon probiert.
Sonst keine Probleme (Thinkpad, "Homeserver", vmplayer)
LOL dachte ich auch grade bin selber mittlerweile bei Debian gelandet weil bei jeder Distro die man Probiert hat und das waren nicht wenige über kurz oder lang Probleme auftraten nur bei Debian nicht und mit Testing bin ich zufrieden auf 3 Rechnern am laufen und 0 Probleme. Vor allem keine Codec Probleme wie bei jeder 2. Distri.
Vor allem würde mich wirklich mal interessieren wem dadurch wo, welcher konkret benennbare Schaden dadurch entstanden ist? So etwas ist man mir bisher immer schuldig geblieben.
Hahaha, typisch Debianer. Über andere Distributionen herziehen, aber wenn es um die Sicherheitslöcher der eigenen Distribution geht, dann hört man tausend Ausreden ala "kein Schaden entstanden", Schau dir mal die Sicherheitslücken in anderen Linux-Distributionen an", usw. usw...
Also wieder das übliche: Eine konkrete und ernst gemeinte Frage wird mit haltlosen und durch nichts zu beweisenden Anschuldigungen und Vermutungen beantwortet. Wieder nur sinn- und inhaltsloses Geplupper eines notorischen Störers.
Lade dir das Image erstelle dir einen USB Stick damit einlegen Booten Update fertig hat bis jetzt immer ohne Probleme geklappt, über Terminal habe ich es nie gemacht weil weil von dem Projekt das so auch Empfohlen wird.
Lade dir das Image erstelle dir einen USB Stick damit einlegen Booten Update fertig hat bis jetzt immer ohne Probleme geklappt, über Terminal habe ich es nie gemacht weil weil von dem Projekt das so auch Empfohlen wird. *Toll Hing die Seite Doppelpost*
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 28. Jul 2017 um 06:47.
Packman braucht man noch für den vollen Genuss, alleine schon deshalb, weil es mit mp3 alleine doch wohl kaum getan ist... Ich zumindest habe keine MP3 mehr (stattdessen FLAC für den Rechner und AAC für Mobilgeräte), benötige aber andere Codecs, von denen leider viele Patentgeschützt sind.
Von Hannibal Lecter am Fr, 28. Juli 2017 um 17:16 #
Ich war immer ein zufriedener openSUSE Nutzer bis zur Version 13.2 - aufgrund der hervorragenden KDE Intregration. Seitdem es Leap gibt mit KDE Plasma 5, bin ich lieber wieder bei Debian 8 und kann noch das stabile KDE4 nutzen.
Klar openSUSE kann nichts für das instabile KDE Plasma 5, aber die kurzen Supportzeiten (kein Evergreen seit 13.1 mehr) und das grässliche Design seit Leap sind doch ein klarer Nachteil. Natürlich kann man sein Design selbst einstellen, aber alleine schon das billige Hintergrundbild mit grauem KDE und blauen Desktop Symbolen erweckt einfach den Eindruck, dass man sich keine Mühe gibt was ausgereiftes zu veröffentlichen. Man schaue sich nur Manjaro an, wie schick das aussieht oder selbst Debian hat ein klares und zusammenhängendes Design. Die Optik spielt schließlich auch eine Rolle (-:
Von Idiotenpfleger am Sa, 29. Juli 2017 um 08:57 #
Natürlich kann Suse etwas dafür, wenn KDE bei denen schlecht läuft. Denn sie müssten es einfach nur ordentlich implementieren. Tun oder können sie aber nicht.
Leap 42.2 und Tumbleweed mit KDE 5 sind so dermaßen instabil und nicht-funktional, dass es einem schon fast leidtut, dass man seinem Rechner solchen Müll zugemutet hat. Da ja Leap 42.3 eigentlich keine großen Änderungen bringt, ist davon auszugehen, dass es der gleiche Schrott sein wird.
Selbst die Amateurtruppe von Kubuntu kann KDE 5 besser implementieren. Die Leute die bei Suse für diese "Ergebnisse" verantwortlich sind, sollten sich schämen, so etwas als Ergebnis ihrer Arbeit dem breiteren Publikum vorzustellen.
"Da ja Leap 42.3 eigentlich keine großen Änderungen bringt, ist davon auszugehen, dass es der gleiche Schrott sein wird."
Du musst IMO Leap 42.3 erst testen, bevor Du so etwas behaupten kannst.
Übers Restwochenende werde ich genau das tun.
Das Hauptproblem mit Leap 42.2 ist, dass es in 6 Monaten EOL sein wird, man also quasi zwangsupgraden muss, wenn man Leap weiterbenutzen möchte.
Die Kritikpunkte, die ich oben angebracht habe, hängen zum einen mit noch nicht implementierten Update-Features zusammen (zypper dup kann einfach keine Delta-Updates im Moment), zum anderen ist die ganze Leap-Geschichte für Opensuse selbst Neuland. Offenbar hatte niemand vor zwei Jahren die Möglichkeit in Betracht gezogen, dass ein voll aktualisiertes Leap 42.2 und ein neu herausgebrachtes Leap 42.3 u.a. in punkto KDE Plasma-Desktop und in punkto Kernel quasi vollkommen identisch sein könnten. Genausowenig wie man bei der Namensgebung von Leap 42 unmöglich schon wissen konnte, dass die nächste Leap-Version die Versionsnummer 15 tragen wird.
Ein kreatives Planungschaos sozusagen mit Learning by Doing und Anpassung an die durch die SLES-Basis vorgegebenen Sachzwänge.
Ich frage mich, wie lange will denn SuSE- Verzeihung: openSUSE denn noch lernen? Dieses mehr oder weniger plan- und ziellose herumirren dauert doch nun schon Jahre? Für mich gefühlt seit dem NOVELL-Deal und dem Ende von SuSE 9.3. Die seit diesem Zeitpunk gegenüber anderen Distributionen drastisch eingebrochene Zahl der Benutzer, je nach Lesart nur noch zwischen 13 und 16% wohl, zeigt das Dilemma eigentlich nur zu deutlich.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 30. Jul 2017 um 11:12.
Von Idiotenpfleger am So, 30. Juli 2017 um 12:24 #
genau das frage ich mich auch. Ich meine, Suse ist ja nun nicht erst seit gestern auf dem Linux-Markt. Eigentlich müssten DIE diejenigen sein, von denen andere lernen. Stattdessen sieht man sich um und entdeckt diverse Community-Distros, die alles besser machen, als Suse. Und kommerzielle Konkurrenten findet man auch zuhauf, die irgendwie mehr Plan haben als Suse.
Das böse C. z.B. braucht keinen Enterpriseunterbau für seine Desktop-Distro und umgekehrt. Bei denen ist alles eins und wenn sie eine Spezialdistro auf den Markt bringen, dann hat das auch irgendwie Hand und Fuss. Aber das hier, von Suse ist ja peinlich.
Der Nutzereinbruch ist viel höher und zwar ab Opensuse 11.1 gerechnet. Die Nutzer-Peaks waren damals so hoch im Vergleich zu heute, dass man in jeder aktuellen Statistik nur noch einen riesigen Berg in punkto 11.1 sieht. Kommentar des Autors dieser Übersichten dazu: "Yes, Opensuse 11.1 was a monster."
Ich habe das Update auf Leap 42.3 übrigens durchgeführt. Wie erwartet, gibt es auf dem Desktop zwischen Leap 42.2 und 42.3 keinerlei sichtbaren Unterschied. Das einzige, was mich dabei stört, sind die 1,75GB an Updates, die ich quasi durch den Schornstein gejagt habe, nur weil Opensuse nicht einfach der Wahrheit ins Auge schauen kann und sagen: O.K., Leap 42.3 bringt nun fast gar nichts Neues, updaten wir deshalb Leap 42.2 wie gewohnt und zwar weiterhin bis Anfang 2019. Schließlich ist dieser konservative Aspekt ja jetzt das Hauptfeature von Leap.
Leap 42.3 funktioniert aber. Im Gegensatz zu früher laufen Distributionsupgrades ohne Neuinstallation nun sauber durch.
Die Planung selbst ist IMO aktuell in katastrophalem Zustand. Trotz zahlreicher Postings hat OpenSuse noch keine Stellung zu dem voraussichtlichen Supportzeitfenster von Leap 42.2 von nur rund 13 bis 14 statt 18 Monaten genommen. Aktuell existiert Leap 42.2 ja erst seit acht Monaten, was auch die Armut an neuen Features beim Upgrade von 42.2 nach 42.3 erklärt. Beim Übergang von 42.1 nach 42.2 war das noch vollkommen anders gewesen.
Wenn man nicht der Auffassung ist, dass eine Distribution supertoll ist und alles wunderbar klasse macht, dann soll man diese nicht benutzen?
Das Grundkonzept von Leap ist schon o.k. für mich (es ähnelt Evergreen), es wird nur chaotisch und nicht nach (einem bekannten) Plan umgesetzt.
Auf meinem Hauptrechner ist Leap aktuell tatsächlich nur eine von insgesamt 8 installierten Distributionen, ich teste und wurstle halt gerne. VM-Installationen lassen halt nun einmal die gesamte real hardwarebezogene Fehlerbandbreite vermissen.
Laut Richard Brown, dem chairman von openSUSE, wurde in den Kernel 4.4.76 vieles aus dem Kernel 4.9 rückportiert: "We backported the entire kernel 4.9 stack to kernel 4.4." Quelle: "openSUSE Leap 42.3" Lunduke Hour, July 25, 2017 (https://www.youtube.com/watch?v=ipgskaR70Ys ab 5:10 min.). Mit mehr Information in den release notes hätte man wohl die Verwirrung oder den Ärger über die Kernelversion verhindern können. Es handelt sich wohl eher um ein PR-Desaster.
Die Rückportierung stammt wohl vom SLES-Team und wurde null im Opensuse-Bereich kommuniziert.
Auch in den Release Notes steht davon nichts.
Die ganzen Fragen, die mittlerweile aufgetaucht sind, muss Herr Brown mittlerweile aber kennen, schließlich kamen diese u.a. auch auf reddit.com auf, das er offensichtlich häufig mitliest.
Gerade eben wurden die 42.3-Release Notes per Update geändert und folgender Absatz korrigiert bzw. neu eingefügt:
"1.4. Update of Kernel Graphics Stack
On openSUSE Leap 42.3, the upgrade of the graphics stack up to 4.9.x kernel code is provided via the package drm-kmp-default instead of backporting tons of patches into the kernel itself. Usually this package is installed automatically at installation when a corresponding graphics device is found on your machine.
The KMP gives users also another benefit: you can roll back to the 4.4.x kernel code simply by uninstalling this package. If you often face critical issues, like a hung GPU, try to uninstall the package once like below, reboot and retest.
Von Stefan Becker am Sa, 5. August 2017 um 17:11 #
Die Susianer haben zuviel rumgefuddelt.
Die haben Sachen aus Kernel >= 4.9 nach 4.4 zurückportiert. Jetzt funktionieren versionsspezifische Defines in den VMWARE und auch VirtualBox Kernelmodulen nicht mehr.
Mit Vanilla wird es gehen, weil da nix gefummelt ist.
Ich habe "old school" die VMWARE Module entpackt und selbst gepatcht. Nervig, so was.
Die 42.2 läuft hier völlig problemlos und "rock stable". Wie immer gute Eingriffsmöglichkeiten für den, der das möchte und toller KDE-Support.
Habe per Repo auf das neueste KDE umgestellt (Plasma 5.10) und kann das jedem empfehlen.
*Was* läuft gut? Die alte 42.2 oder die neue Version 42.3? Und was will uns das jeweils sagen?
Bisschen Redundanz hilft manchmal bei der eindeutigen Dechiffrierung von Botschaften...
Dem kann ich mich anschließen. Leap ist sehr stabil und mit den richtigen Repos fast immer aktuell.
Hab vorher Tumbleweed drauf gehabt. Leider hatte ich damit aber zu oft Schwierigkeiten, gerade mit verschlüsselter Festplatte kann ich Tumbleweed nicht empfehlen. Mein System wurde vier mal zu Schrott upgedatet, weil irgendetwas nicht funktioniert und ich die Festplatte nicht entschlüsseln konnte. Anscheinend arbeiten zu Wenige mit verschlüsselten Festplatten um solche gravierenden Fehler, vor Freigabe neuer Snapshots, zu entdecken.
Nach dem Desaster mit Tumbleweed bin ich auf Leap umgestiegen. Ich muss sagen, es läuft!
Bisher keine Probleme gehabt. Ein paar mal ist die Taskleiste abgestürzt, doch die taucht meistens innerhalb von wenigen Sekunden wieder auf.
Ich habe Leap mit den entsprechenden Repos auch aufgebohrt und nur bei den Paketen einen Repowechsel gemacht wo es notwendig war. Den Leap-Unterbau lasse ich weitestgehend unverändert.
Hab auch Plasma 5.10 ausprobiert, aber einige Anwendungen gingen nicht mehr und auf die Tumbleweed Pakete wollte ich nicht zurückgreifen. Wie hast du dieses Problem gelöst?
Ich hab seit langem Tumbleweed drauf, nicht das geringste Problem. Grund unter 42.2 kein Eingabefenster für die Passphrase der verschlüsselten Partitionen, hab ich dann über zusatz Repos mit neuerem X-Server gelöst, hats aber nicht lange Spaß gemacht, weil die Abhängigkeiten irgendwann auseinandergelaufen sind.
Dann auf Tumbleweed umgestiegen, wenn man bleeding edge HW hat, kommt man ab und zu nicht an hoch aktuellen Distris vorbei.
Was bei Tumbleweed allerdings nervt, dass sie jede Woche hunderte von Paketen ziehen muss, irgendnen Tod stirbt man. Drum bin ich auch seit 15 Jahren nicht mehr bei Gentoo, eigentlich soll der Rechner nur laufen, ist nicht zum rumspielen gedacht.
Upgrade lief sauber durch. Bis jetzt ist noch nichts Negatives erkennbar.
Danke an die Entwickler!
Wie gut läuft denn das Upgrade von Y.X auf Y.X+1 ab? Habe mich heute mal umgeschaut, da muss ja eine Reihe von Hand gemacht werden und so 100% sauber läuft es ja auch nicht durch. An sich hört sich das Upgrade-Prozedure so ähnlich an wie bei Fedora mit FedUp. So richtig überzeugt bin ich von solchen Verfahren ehrlich gesagt ja eher nicht.
4 Zeilen (als root) in die Konsole getippselt, etwas warten, fertig.
cp -Rv /etc/zypp/repos.d /etc/zypp/repos.d.Old
sed -i 's,42\.2,42.3,g' /etc/zypp/repos.d/*
zypper --gpg-auto-import-keys ref
zypper dup
Vorsicht!
Hat bei mir schon nicht funktioniert. Zumindest nicht in der VB. Da gehört ein bisschen mehr dazu, als diese 4 Zeilen. War bei mir bei Upgrade von 42.1 auf 42.2 auch so.
Tja, hier lief es durch und gerade schreibe ich diesen Text unter 42.3.
In meinem Fall reichten die 4 Zeilen dann wohl doch - oder ich hab' was falsch gemacht.
Vermutlich keine oder nur sehr wenige und gute Drittrepos. Da man nicht weiß wie das System des anderen aussieht sollte man mit derartigen "Anleitungen" vorsichtig umgehen. Die zwei Minuten mehr sollte man sich jedenfalls nehmen.
Drittrepos: Packman u. Infinality
Ich supporte hier nicht, sondern schrieb nur meine (!) Vorgehensweise auf. Ein Leap-Upgrade ist keine Zauberei und i.d.R. unproblematisch.
Mit Irgendwelchen Basteleien in virtuellen Umgebungen habe ich allerdings keine Erfahrung ...
Das sehe ich auch so, dass ein Leap-Upgrade keine Zauberei ist.
Und was hast Du durch das Update erreicht?
Du hast bestimmt ca. 1GB neue Rpms heruntergeladen, nur um nach einem Upgrade von Leap 42.2 auf 42.3 immer noch die gleiche KDE Plasma-Version, die gleiche Gnome3-Version, die gleiche Glibc-Version und die gleiche Kernelversion wie in Leap 42.2 zu haben.
IMO ist das ziemlich sinnfrei.
Das gesamte derzeitige openSUSE-Konstrukt sehe ich als Armutszeugnis für die Rester der SUSE Community und ein leider aber nicht offen ausgeprochenes Eingeständnis, dass man eigentlich nicht in der Lage ist aus eigener Kraft eine akzeptable Distribution zu Stande zu bringen.
"Du hast bestimmt ca. 1GB neue Rpms heruntergeladen,..."
Habe ich jetzt weniger Platz oder Software doppelt? :)
Gab es keine sinnvollen Neuerungen und einen längeren Supportzeitraum für Leap?
"IMO ist das ziemlich sinnfrei."
Da gebe ich dir recht, aber du musstest das ja unbedingt schreiben. ^^
"Habe ich jetzt weniger Platz oder Software doppelt? "
Nein, nein.
Du hast Dir offenbar die gleichen Softwareversionen nochmals heruntergeladen und damit die vorher schon auf Deinem Rechner befindliche 42.2-Software größtenteils mit neuer 42.3-Software in der genau oder fast genau gleichen Version ersetzt.
Du hast also Glibc 2.22 aus Leap 42.3 heruntergeladen und damit die vorhandene Glibc 2.22 in Leap 42.2 ersetzt, also glibc-2.22-4.9.1 (42.2) durch glibc-2.22-8.4 (42.3). Das gleiche Spiel hast Du u.a. mit dem Kernel 4.4 wiederholt: Der 42.2-Kernel kernel-default-4.4.74-18.20.1 wurde auf den 42.3-Kernel kernel-default-4.4.76-1.1 geupgradet und das bestimmt ganz ohne drpm-Option (die in Kürze bestimmt in Leap 42.2 angeboten wird, um auf Kernel 4.4.76 oder 4.4.78 aktualisieren zu können).
Das war bestimmt das effektivste Distributionsupgrade aller Zeiten.
Wenn man so weiter verfährt, braucht man Leap 42.2 gar nicht in sechs Monaten für EOL zu erklären, denn Leap 42.3 und 42.2 scheinen ja ohnehin binärkompatibel zu sein.
Das ist eigentlich ein Fall für openSUSE Evergreen: Leap 42.2 wäre das am einfachsten supportbare openSUSE Evergreen, das es je gegeben hat.
Hach, wie es sich ereiferst ... ^^
Du hast echt nichts begriffen und haust das dann hier auch noch raus. Herrlich erfrischend.
LTS/Enterprise ist nicht Versionitis-Blingbling.
Für Opensuse geht es offenbar genau hierum, um Versionitis. Ansonsten bräuchte man kein GB-fressendes Distributionsupgrade von 42.2 auf 42.3, wenn Leap 42.2 und 42.3 in punkto Software sowieso dasselbe sind. 42.3 ist 42.2, was für mich völlig o.k. wäre, wenn 42.3 samt GB-konsumierendem Quasi-Zwangsdistributionsupdate in 6 Monaten nicht existieren würde. 42.2 würde unterstützt werden bis Anfang 2019, fertig (siehe hierzu auch die Anmerkungen zur Lifetime von 42.2 weiter unten).
42.3 ist nichts weiter als ein Minor Point Release zu 42.2, so wie er in der Debian-Welt z.B. beim Update von Jessie 6.7 auf 6.8 vorkommt und genauso wie dieser schon zig Mal bei Opensuse 42.1 und 42.2 selbst vorgekommen ist (u.a. als Update des zugrundeliegenden Zypper-, KDE- oder Gnome-Stacks ohne Point Release-Bezeichnung).
Das Distributionsupgrade an sich von Leap 42.2 nach 42.3 ist somit vollkommen sinnlos. Man lädt sich nicht einen Haufen Software herunter, nur um nach dem Einspielen die genau gleiche Software wie zuvor zu haben. Ein 150MB- (nicht ein GB-) Update wäre natürlich o.k.
Denn Opensuse selbst hat ja einen wunderbaren Mechanismus für so etwas: drpm-Updates innerhalb einer Distributionsversion. Das macht ein neues, aber weitgehend identisches 42.3 mit traditionellem Distributionsupdate noch umso überflüssiger.
----------------------------
Und hier noch eine weitere Unstimmigkeit in punkto Lebensdauer:
Jeder Leap-Zwischenrelease sollte ja 18 Monate Support bekommen.
Nur wird Leap 42.2 laut den eigenen Regeln (Veröffentlichungszeitpunkt der Folgeversion plus 6 Monate) nur 12 Monate unterstützt werden, da das EOL von Leap 42.2, das im November 42.2 erschien, in den Januar 2018 fallen wird. Leap 42.1 hatte wenigstens diese 18 Monate Support, von November 2015 bis Mai 2017, also sogar 19 Monate.
Irgendwie ist da etwas gehörig schief gelaufen.
Siehe hierzu
https://en.opensuse.org/Lifetime
"A Leap Minor Release (42.1, 42.2, etc.) is expected to be released annually. Users are expected to upgrade to the latest minor release within 6 months of its availability, leading to a support life cycle of 18 months. "
Leap 42.3 kam demzufolge viel zu früh heraus, nämlich rund ein halbes Jahr.
Ja, ich war auch erschüttert als mir das klar geworden ist. Und nachher musste ich sogar ein wenig weinen....
Danke, hat super geklappt, summt wie eine Biene!
Wenn man die Installation sauber gehalten hat, sollte nicht viel von Hand zu machen sein. Hat man keine Repos hinzugefügt sollte ein sed und zypper dup reichen (siehe https://en.opensuse.org/SDB:System_upgrade#Running_the_Upgrade ). Übrigens werden die Upgrades mittels openqa getestet. Zum Beispiel mittels DVD https://openqa.opensuse.org/tests/451704# oder mittels zypper dup https://openqa.opensuse.org/tests/451723#step/boot_to_desktop/1 . Wenn man zum Beispiel Repos hinzugefügt hat sollte man natürlich etwas überlegter vorgehen. Größere Probleme hatte ich dabei aber nie wobei das natürlich davon abhängt wie man mit seiner Installation umgeht.
Probleme hab ich beim eeePC. Da hängt die Installation nach dem HW-Check, die Installationspakete werden nicht gelesen. Hat jemand ne Idee? nomodeset acpi=off apm=off hab ich schon probiert.
Sonst keine Probleme (Thinkpad, "Homeserver", vmplayer)
beim Installieren/Upgrade mit dem aktuellen Tumbleweed läuft's auf dem eeePC bis zu "Systemdateien suchen". Hmm.
Installier dir Debian oder so, ist stressfreier als der verbuggte Müll hier.
LOL dachte ich auch grade bin selber mittlerweile bei Debian gelandet weil bei jeder Distro die man Probiert hat und das waren nicht wenige über kurz oder lang Probleme auftraten nur bei Debian nicht und mit Testing bin ich zufrieden auf 3 Rechnern am laufen und 0 Probleme.
Vor allem keine Codec Probleme wie bei jeder 2. Distri.
EDebian ist mir ganz einfach zu unsicher. Haben die z.B. inzwischen die seit über einem Jahrzehnt veralteten SHA-1 Schlüssel entsorgt?
Dann sollten Sie besser keinen Computer verwenden, denn theoretisch ist jede Software von Haus aus unsicher, ebenso openSUSE.
Theorie hin oder her: Den Debian openSSL-Bug gab's aber, verursacht durch einen unfähigern Packager, nur bei Debian?
Schau dir mal die Sicherheitslücken in anderen Linux-Distributionen an, manche sind sogar weitaus schlimmer als dieser Pipikram bei Debian.
Vor allem würde mich wirklich mal interessieren wem dadurch wo, welcher konkret benennbare Schaden dadurch entstanden ist?
So etwas ist man mir bisher immer schuldig geblieben.
Hahaha, typisch Debianer. Über andere Distributionen herziehen, aber wenn es um die Sicherheitslöcher der eigenen Distribution geht, dann hört man tausend Ausreden ala "kein Schaden entstanden", Schau dir mal die Sicherheitslücken in anderen Linux-Distributionen an", usw. usw...
Was ein Glück dass ich mich von Linux abgewendet habe und ich zu *BSD gewechselt bin
Ich hoffe du benutzt Debian GNU/kFreeBSD?
Alle anderen *BSD sind selbstredend nicht zu empfehlen.
Merkel ist auch nicht zur Bundestagswahl zu empfehlen.
Also wieder das übliche:
Eine konkrete und ernst gemeinte Frage wird mit haltlosen und durch nichts zu beweisenden Anschuldigungen und Vermutungen beantwortet.
Wieder nur sinn- und inhaltsloses Geplupper eines notorischen Störers.
Mann, das ist nun über 8 Jahre her. Da war wahrscheinlich manch ein Kindskopf, der da permanent drauf rum reitet, noch nicht mal geboren.
hab dann eine Neuinstallation von 42.2 gemacht, danach ging auch 42.3. War wohl etwas in meinen Systemdateien.
Lade dir das Image erstelle dir einen USB Stick damit einlegen Booten Update fertig hat bis jetzt immer ohne Probleme geklappt, über Terminal habe ich es nie gemacht weil weil von dem Projekt das so auch Empfohlen wird.
Lade dir das Image erstelle dir einen USB Stick damit einlegen Booten Update fertig hat bis jetzt immer ohne Probleme geklappt, über Terminal habe ich es nie gemacht weil weil von dem Projekt das so auch Empfohlen wird.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 28. Jul 2017 um 06:47.*Toll Hing die Seite Doppelpost*
Wie sieht es mit Multimedia aus?
Braucht man Packman noch für den vollen Genuss,
oder sind die Lizenzprobleme jetzt behoben,
nachdem MP3 nun frei ist?
Packman braucht man noch für den vollen Genuss, alleine schon deshalb, weil es mit mp3 alleine doch wohl kaum getan ist...
Ich zumindest habe keine MP3 mehr (stattdessen FLAC für den Rechner und AAC für Mobilgeräte), benötige aber andere Codecs, von denen leider viele Patentgeschützt sind.
Ich war immer ein zufriedener openSUSE Nutzer bis zur Version 13.2 - aufgrund der hervorragenden KDE Intregration. Seitdem es Leap gibt mit KDE Plasma 5, bin ich lieber wieder bei Debian 8 und kann noch das stabile KDE4 nutzen.
Klar openSUSE kann nichts für das instabile KDE Plasma 5, aber die kurzen Supportzeiten (kein Evergreen seit 13.1 mehr) und das grässliche Design seit Leap sind doch ein klarer Nachteil. Natürlich kann man sein Design selbst einstellen, aber alleine schon das billige Hintergrundbild mit grauem KDE und blauen Desktop Symbolen erweckt einfach den Eindruck, dass man sich keine Mühe gibt was ausgereiftes zu veröffentlichen. Man schaue sich nur Manjaro an, wie schick das aussieht oder selbst Debian hat ein klares und zusammenhängendes Design. Die Optik spielt schließlich auch eine Rolle (-:
Natürlich kann Suse etwas dafür, wenn KDE bei denen schlecht läuft. Denn sie müssten es einfach nur ordentlich implementieren. Tun oder können sie aber nicht.
Leap 42.2 und Tumbleweed mit KDE 5 sind so dermaßen instabil und nicht-funktional, dass es einem schon fast leidtut, dass man seinem Rechner solchen Müll zugemutet hat. Da ja Leap 42.3 eigentlich keine großen Änderungen bringt, ist davon auszugehen, dass es der gleiche Schrott sein wird.
Selbst die Amateurtruppe von Kubuntu kann KDE 5 besser implementieren. Die Leute die bei Suse für diese "Ergebnisse" verantwortlich sind, sollten sich schämen, so etwas als Ergebnis ihrer Arbeit dem breiteren Publikum vorzustellen.
"Da ja Leap 42.3 eigentlich keine großen Änderungen bringt, ist davon auszugehen, dass es der gleiche Schrott sein wird."
Du musst IMO Leap 42.3 erst testen, bevor Du so etwas behaupten kannst.
Übers Restwochenende werde ich genau das tun.
Das Hauptproblem mit Leap 42.2 ist, dass es in 6 Monaten EOL sein wird, man also quasi zwangsupgraden muss, wenn man Leap weiterbenutzen möchte.
Die Kritikpunkte, die ich oben angebracht habe, hängen zum einen mit noch nicht implementierten Update-Features zusammen (zypper dup kann einfach keine Delta-Updates im Moment), zum anderen ist die ganze Leap-Geschichte für Opensuse selbst Neuland. Offenbar hatte niemand vor zwei Jahren die Möglichkeit in Betracht gezogen, dass ein voll aktualisiertes Leap 42.2 und ein neu herausgebrachtes Leap 42.3 u.a. in punkto KDE Plasma-Desktop und in punkto Kernel quasi vollkommen identisch sein könnten. Genausowenig wie man bei der Namensgebung von Leap 42 unmöglich schon wissen konnte, dass die nächste Leap-Version die Versionsnummer 15 tragen wird.
Ein kreatives Planungschaos sozusagen mit Learning by Doing und Anpassung an die durch die SLES-Basis vorgegebenen Sachzwänge.
Ich frage mich, wie lange will denn SuSE- Verzeihung: openSUSE denn noch lernen? Dieses mehr oder weniger plan- und ziellose herumirren dauert doch nun schon Jahre? Für mich gefühlt seit dem NOVELL-Deal und dem Ende von SuSE 9.3.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 30. Jul 2017 um 11:12.Die seit diesem Zeitpunk gegenüber anderen Distributionen drastisch eingebrochene Zahl der Benutzer, je nach Lesart nur noch zwischen 13 und 16% wohl, zeigt das Dilemma eigentlich nur zu deutlich.
genau das frage ich mich auch. Ich meine, Suse ist ja nun nicht erst seit gestern auf dem Linux-Markt. Eigentlich müssten DIE diejenigen sein, von denen andere lernen. Stattdessen sieht man sich um und entdeckt diverse Community-Distros, die alles besser machen, als Suse. Und kommerzielle Konkurrenten findet man auch zuhauf, die irgendwie mehr Plan haben als Suse.
Das böse C. z.B. braucht keinen Enterpriseunterbau für seine Desktop-Distro und umgekehrt. Bei denen ist alles eins und wenn sie eine Spezialdistro auf den Markt bringen, dann hat das auch irgendwie Hand und Fuss. Aber das hier, von Suse ist ja peinlich.
Der Nutzereinbruch ist viel höher und zwar ab Opensuse 11.1 gerechnet. Die Nutzer-Peaks waren damals so hoch im Vergleich zu heute, dass man in jeder aktuellen Statistik nur noch einen riesigen Berg in punkto 11.1 sieht. Kommentar des Autors dieser Übersichten dazu: "Yes, Opensuse 11.1 was a monster."
Ich habe das Update auf Leap 42.3 übrigens durchgeführt. Wie erwartet, gibt es auf dem Desktop zwischen Leap 42.2 und 42.3 keinerlei sichtbaren Unterschied. Das einzige, was mich dabei stört, sind die 1,75GB an Updates, die ich quasi durch den Schornstein gejagt habe, nur weil Opensuse nicht einfach der Wahrheit ins Auge schauen kann und sagen: O.K., Leap 42.3 bringt nun fast gar nichts Neues, updaten wir deshalb Leap 42.2 wie gewohnt und zwar weiterhin bis Anfang 2019. Schließlich ist dieser konservative Aspekt ja jetzt das Hauptfeature von Leap.
Leap 42.3 funktioniert aber. Im Gegensatz zu früher laufen Distributionsupgrades ohne Neuinstallation nun sauber durch.
Die Planung selbst ist IMO aktuell in katastrophalem Zustand. Trotz zahlreicher Postings hat OpenSuse noch keine Stellung zu dem voraussichtlichen Supportzeitfenster von Leap 42.2 von nur rund 13 bis 14 statt 18 Monaten genommen. Aktuell existiert Leap 42.2 ja erst seit acht Monaten, was auch die Armut an neuen Features beim Upgrade von 42.2 nach 42.3 erklärt. Beim Übergang von 42.1 nach 42.2 war das noch vollkommen anders gewesen.
Mein Gott, warum nutzt du es denn überhaupt? Masochismus o. der Wunsch in diversen Portalen, wie dein Vorredner, mitwimmern zu können?
Befreie dich doch endlich von dem Schmerz, den dir diese grottenschlechte Distribution bringt und installiere etwas anderes.
Wenn man nicht der Auffassung ist, dass eine Distribution supertoll ist und alles wunderbar klasse macht, dann soll man diese nicht benutzen?
Das Grundkonzept von Leap ist schon o.k. für mich (es ähnelt Evergreen), es wird nur chaotisch und nicht nach (einem bekannten) Plan umgesetzt.
Auf meinem Hauptrechner ist Leap aktuell tatsächlich nur eine von insgesamt 8 installierten Distributionen, ich teste und wurstle halt gerne. VM-Installationen lassen halt nun einmal die gesamte real hardwarebezogene Fehlerbandbreite vermissen.
Laut Richard Brown, dem chairman von openSUSE, wurde in den Kernel 4.4.76 vieles aus dem Kernel 4.9 rückportiert: "We backported the entire kernel 4.9 stack to kernel 4.4."
Quelle: "openSUSE Leap 42.3" Lunduke Hour, July 25, 2017 (https://www.youtube.com/watch?v=ipgskaR70Ys ab 5:10 min.). Mit mehr Information in den release notes hätte man wohl die Verwirrung oder den Ärger über die Kernelversion verhindern können. Es handelt sich wohl eher um ein PR-Desaster.
Die Rückportierung stammt wohl vom SLES-Team und wurde null im Opensuse-Bereich kommuniziert.
Auch in den Release Notes steht davon nichts.
Die ganzen Fragen, die mittlerweile aufgetaucht sind, muss Herr Brown mittlerweile aber kennen, schließlich kamen diese u.a. auch auf reddit.com auf, das er offensichtlich häufig mitliest.
"Houston, wir haben ein 42.3-Update."
"Und?"
"Tja, keine Ahnung."
Gerade eben wurden die 42.3-Release Notes per Update geändert und folgender Absatz korrigiert bzw. neu eingefügt:
"1.4. Update of Kernel Graphics Stack
On openSUSE Leap 42.3, the upgrade of the graphics stack up to 4.9.x kernel code is provided via the package drm-kmp-default instead of backporting tons of patches into the kernel itself. Usually this package is installed automatically at installation when a corresponding graphics device is found on your machine.
The KMP gives users also another benefit: you can roll back to the 4.4.x kernel code simply by uninstalling this package. If you often face critical issues, like a hung GPU, try to uninstall the package once like below, reboot and retest.
zypper rm drm-kmp-default "
Weiß jemand, ob durch das Entfernen des Pakets die VMware Workstation auch wieder funktioniert (wie in Leap 42.2)?
Siehe auch: goo.gl/H6CSDm
ich antworte mir selber.
VMware WS 12.5.7 läuft nach Installation des 4.4-76-1-vanilla kernels (im Leap Repo drin)
Die Susianer haben zuviel rumgefuddelt.
Die haben Sachen aus Kernel >= 4.9 nach 4.4 zurückportiert. Jetzt funktionieren versionsspezifische Defines in den VMWARE und auch VirtualBox Kernelmodulen nicht mehr.
Mit Vanilla wird es gehen, weil da nix gefummelt ist.
Ich habe "old school" die VMWARE Module entpackt und selbst gepatcht. Nervig, so was.