immer die gleichen Fehler nach Updates auf (scanner wird zwar gefunden aber lässt sich mit Sane nicht ansprechen, WLAN wird vermurkst ...)
Ich bin von diesen Fehlern nicht betroffen, aber das kann natürlich je nach Konfiguration individuell sein.
Mint hat zugleich den Vorteil dass es deutlich weniger Systemressourcen braucht
Bedeutet was genau? Ohne Zahlen ist das erst mal schwer nachzuvollziehen. openSUSE KDE 64bit "verbraucht" übrigens direkt nach Systemstart ca. 420 MB RAM, das ist in den letzten Versionen recht stabil und auch mit Leap 15.1 so. Finde ich jetzt nicht unbedingt viel, zumal Kubuntu z.B. eher Richtung >800 MB bei gleichen Voraussetzungen geht.
und die wichtigsten Codecs für Videos sind gleich an Bord.
Ok, vielleicht kann Mint das Risiko gehen, weil bei denen mit Patentklagen sowieso nichts zu holen ist. Ich verstehe aber, das SUSE und Red Hat sich da absichern müssen. Übrigens ist das installieren der benötigten Codecs mittels https://www.opensuse-community.org/ nun auch nicht gerade schwierig...
LinuxMint installiert Codecs standardmäßig seit einigen Versionen auch nicht mehr mit, außer Du wählst die entsprechende Option während der Installation. Solltest Du diese nicht gewählt haben erscheint später im Menü ein Punkt 'Install Proprietary Codecs" über den dies bei Bedarf nachgeholt werden kann.
Die entspricht von der 'Einfachheit' ungefähr der für openSUSE notwendigen Schritte (1-click-install / Repo Priorität setzen).
Bezüglich der beschriebenen Probleme, so kann ich diese ebenfalls nicht nachvollziehen. Insbesondere die Drucker und Scannerunterstützung ist bei openSUSE als sehr gut bekannt. Ob der selbstgeschriebene Netzwerkdienst 'wicked' der Weisheit letzter Schluss ist, steht auf einem anderen Blatt.
Für ein Dist-Upgrade sollten zwingend die hier beschriebenen Anweisungen befolgt werden:
Auch ich kann solche Fehler bei Upgrades schon seit sehr vielen Jahren nicht mehr bestätigen. Gerade Opensuse hat eine der besten Upgrade Funktionen.
Seit meinem Umstieg auf Tumbleweed sind Updates für mich ohnehin kein Thema mehr. Und entgegen so mancher Unkenrufe läuft Tumbleweed zumindest bei mir absolut stabil.
Edit und Nachtrag: Ich nutze Suse/Opensuse seit Suse 8.0.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 11. Okt 2019 um 18:42.
Gerade Opensuse hat eine der besten Upgrade Funktionen.
Da muss ich strikt widersprechen. openSUSE macht hier den gleichen Murks wie Debian oder Ubuntu: Man muss die Paketquellen anpassen (oft manuell), und dann wird das Upgrade im laufenden System drüber installiert. Meistens funktioniert das.
Fedora hat hier einen deutlich besseren Ansatz (dnf system-upgrade): Zuerst werden die benötigten Pakete heruntergeladen, dann wird in ein spezielles systemd-Target gerebootet, in der dann das Upgrade installiert wird. Das ist weit weniger fehleranfällig, da dem laufenden System nicht der Boden unter den Füßen weggezogen wird.
Von Kleiner Geek am Sa, 12. Oktober 2019 um 17:42 #
Solange du das upgrade in der tty ausführst und wie bereits erwähnt wurde alle Pakete zuvor manuell herunterlädst ist das vollkommen unkritisch. Mit snapper kannst du sogar noch einen Snapshot von der alten Version erstellen (btrfs / default).
Wenn dir so ein systemd upgrade mal schief gelaufen ist, wirst du feststellen, dass es auch nicht der Weisheit letzter Schluss ist.
Aber stateless Systeme wie Clear Linux sind ja in Aufwind. Dann kannst du ohne grosse Hacks dein Core / Kernel gar nicht mehr modifizieren. Yippie!
Übrigens ist mir bei zypper dups noch nie etwas kaputt gegangen.
Auf dem Desktop scheint das Ganze wohl teilweise noch etwas hakelig, siehe z.B. auch die hier genannten Fallstricke. Als "fertig" im Sinne von Endanwendern ist das also noch nicht einzustufen.
Solange du das upgrade in der tty ausführst und wie bereits erwähnt wurde alle Pakete zuvor manuell herunterlädst ist das vollkommen unkritisch. Mit snapper kannst du sogar noch einen Snapshot von der alten Version erstellen (btrfs / default).
Das ist genau das, was ich kritisiere: Upgrade in einer TTY ausführen, Pakete vorab downloaden, da versucht man die Probleme zu umgehen, was man mit einem vernünftigen Upgrademechanismus nicht müsste.
Aber stateless Systeme wie Clear Linux sind ja in Aufwind. Dann kannst du ohne grosse Hacks dein Core / Kernel gar nicht mehr modifizieren. Yippie!
Ich glaube, du hast das Konzept dahinter nicht verstanden. Du kannst alles tun, was du bisher auch tun konntest, nur mit weit geringerem Risiko, da du stehts den alten Zustand wieder booten kannst. Wenn du willst, kannst du während eines Upgrades den Stecker ziehen, und nichts geht kaputt.
Übrigens ist mir bei zypper dups noch nie etwas kaputt gegangen.
Dann hast du bisher nur den Happy Path gesehen, aber das solltest du nicht verallgemeinern.
Geht das auch etwas präziser, oder soll das am Ende doch nur Bashing sein. Aber klar, es kann immer etwas schief gehen. So gesehen geht in der IT immer alles nur "meistens".
Natürlich muss man die Paktequellen anpassen, wenn du nicht strikt nur Pakete aus dem Hauptrepository installierst. Mit Verlaub, wenn dich sogar das überfordert, würde ich dir in der Tat das beste OS der Welt aus Redmond empfehlen. Da klappt jedes Upgrade garantiert ohne Probleme.
Geht der Ansatz von Fedora auch im laufenden Betrieb. Wenn da in ein spezielles systemd-Target rebootet werden muss, kann ich mir das nur schwer vorstellen.
Mit Tumbleweed als Rolling Distribution habe ich das Thema Upgrades ohnehin abgehakt. Sorry, dein Beitrag liest sich nach dem üblichen Suse/Opensuse Bashing, wo mit aller Gewalt ein Haar in der Suppe gesucht wird.
Natürlich muss man die Paktequellen anpassen, wenn du nicht strikt nur Pakete aus dem Hauptrepository installierst.
Das Betriebssystem sollte von selbst merken, dass es ein neues Release gibt, das Upgrade anbieten, und dann ggf. die Paketquellen selbst modifizieren. Fedora und Ubuntu kriegen das schon seit Jahren hin. während man bei Debian und Suse selbst herumeditieren muss.
Geht der Ansatz von Fedora auch im laufenden Betrieb. Wenn da in ein spezielles systemd-Target rebootet werden muss, kann ich mir das nur schwer vorstellen.
Man will keine Upgrades im laufenden Betrieb durchführen, weil man dann Dateien löschen oder überschreiben muss, die von Programmen gerade verwendet werden. Genau deswegen macht es Sinn, vorher alle Pakete herunterzuladen und dann während eines Neustarts alles zu installieren.
Noch sauberer sind Ansätze wie in Fedora Silverblue oder openSUSE Kubic, wo überhaupt nicht mehr in-place überschrieben wird.
Mit Tumbleweed als Rolling Distribution habe ich das Thema Upgrades ohnehin abgehakt.
Da hast du genau das gleiche Problem, nur dass Änderungen nicht alle auf einmal kommen, sondern nach und nach.
Sorry, dein Beitrag liest sich nach dem üblichen Suse/Opensuse Bashing, wo mit aller Gewalt ein Haar in der Suppe gesucht wird.
Es wurde behauptet, openSUSE hätte einen besonders guten Upgrademechanismus, und das ist schlicht falsch - und ich habe auch erklärt, wieso. SUSE selbst hat das auch erkannt und arbeitet an neuen Lösungen (transactional-update).
Ich habe nichts gegen (open)SUSE, arbeite selbst damit immer mal wieder. Man muss Software jedoch objektiv betrachten und Probleme benennen dürfen, sonst kann man sie auch nicht lösen.
Man will keine Upgrades im laufenden Betrieb durchführen, weil man dann Dateien löschen oder überschreiben muss, die von Programmen gerade verwendet werden. Genau deswegen macht es Sinn, vorher alle Pakete herunterzuladen und dann während eines Neustarts alles zu installieren.
Doch, will man. Einfach, weil man es kann.
Ist doch nicht so schwer, nach Aufruf von zypper dup einmal zypper ps -s und die dort angezeigten Dienste per systemctl restart [name] neu zu starten. Selbst der systemd-Prozess kann per systemctl daemon-reexec
neu ausgeführt werden. Und schon ist man auf dem neusten Stand, ohne reboot*
* Kernelupgrade ausgenommen; kann Spuren von Haselnüssen enthalten.
Die Betonung liegt hier offensichtlich auf "kann". Nicht jeder weiß, was die Software welches Pakets tut, wie sie arbeitet, wann/wie/wo sie ihren Zustand speichert, welche Bibliotheken sie dabei nutzt und ggf. nachlädt, usw. Es hängt ganz stark von der Software und den spec-/control-Skripte der einzelnen Pakete abhängen (die der DEB-Pakete sollen per Richtlinie idempotent sein [0] - Wer prüft das bitte?; in der RPM-Welt sieht es vermutlich ganz ähnlich aus.), die dort aktualisiert wird. Und dieses Verhalten ist mitunter nicht nur paket- sondern auch versionssepzifisch/-abhängig.
Zudem können sich weitere, von Entwicklern oder Paketierern unbeabsichtigte oder unvorhergesehene Fehlerquellen einschleichen.
Ist doch nicht so schwer, nach Aufruf von [...]
Kann es an dieser Stelle nicht bereits "zu spät" sein? Szenario: Dienst A1 wird aktualisiert während er läuft. Er soll neugestartet werden, wofür aber dessen Zustand serialisiert werden muss. Tut er das mithilfe eines noch gestarteten Prozesses A2, geschieht dies mit den aktualisierten Komponenten/Bibliotheken, welche der Dienst A1 noch nicht geladen hatte, was zu einer fehlerhaften Serialisierung des Zustands führen kann (z.B. soname-Inkrement mangels Abwärtskompatibilität). Der Zustand könnte bspw. eine Konfiguration, ein Benutzerprofil, ein Arbeits- oder Brechnungsfortschritt oder eine Datenbank sein.
Und das wäre nur ein einziges Szenario. Letztlich geht es eigentlich darum, den Zustand des Systems strikter von den Daten zu trennen. Da hilft ein Separierung der Durchführung der Aktualisierung vom Rest, z.B. mittels Neustart, ungemein. Genau deswegen existieren etwaige Bestrebungen, Entwicklungen und Alternativen.
In diesen Zeiten, in denen read-only Systeme oder Container am laufenden Band neu erstellt angepasst, zusammengesetzt, neu erstellt, (neu-)gestartet oder/und beendet werden, spielt diese Form der Systemaktualisierung ein untergeordnetere Rolle (auch für die Entwickler/Paketerierer!), siehe Kubic, Project Atomic / Atomic Host, Silverblue, CoreOS, Docker, Kubernetes etc.
Verschiedene Systeme haben hier unterschiedliche Anforderungen. Aber die müsste der Nutzer kennen. So entstehen bspw. auf dem Desktop folgende Probleme, [1].
Eine Anekdote darf nicht fehlen: Ich persönlich hatte auch mal mit einem Fall zu tun, bei dem Firefox aktualisiert wurde während es lief. Dann wurde eine neue Firefox-Instanz gestartet (nicht besonders "schlau", wenn man es denn weiß), und nach dem Schließen beider Instanzen, gab es bei darauffolgenden Starts einen Dateiformatkonflikt einer Datei des Benutzerprofils. Ich glaube mich zu erinnern, dass es eine von Firefox erstellte und verwendete SQLite-Datenbankdatei betraf.
Ich denke, dass es genügend realistische Hinweise dafür gibt, dass offline-Upgrades robuster sind als online-Upgrades - insbesondere dann, wenn jemand nicht 100% weiß, was sie/er tut.
Du übersiehst, dass bei opensuse die Versionen überlappend gepflegt werden. Ich will nicht, dass opensuse automatisch Upgraded. Und die normalen Updates bekomme ich sehr wohl angezeigt.
Welches Problem ich bei Tumbleweed mit Upgrades haben soll, die es gar nicht geht erschließt sich mir nun wirklich nicht.
Opensuse ist kein Windows, wo mir das System sagt, dass ich upgraden muss. Opensuse lässt mir die Freiheit, selbst zu entscheiden, welche Version ich fahren will. Und genau wegen solcher Freiheiten verwende ich Linux. Auch scheinst du absolut keine Ahnung zu haben, wie ein Upgrade im laufenden Betrieb überhaupt abläuft. Ich mache Updates im laufenden Betrieb ohne Probleme, seit das bei Opensuse geht. Und das ist schon sehr lange Zeit der Fall. Mach dich erst einmal kundig, bevor du etwas behauptest.
Du magst mit Opensuse immer wieder mal arbeiten. Ich arbeite mit Suse/Opensuse seit Suse 8.0, also 15 Jahre kontinuierlich. Mit allem Respekt, du schreibst Unsinn.
Bleib bei deinem Ubuntu. Ich will kein Windows mit einem Linux Kernel. Ich will ein Linux, dass sich auch so verhält. Du hast entweder gar keine Ahnung, wie das bei Opensuse überhaupt läuft, oder willst tatächlich nur Bashing betreiben, um nicht zu sagen trollen. Sorry für meine sehr deutliche Wortwahl.
Du übersiehst, dass bei opensuse die Versionen überlappend gepflegt werden. Ich will nicht, dass opensuse automatisch Upgraded. Und die normalen Updates bekomme ich sehr wohl angezeigt.
Das habe ich nicht gefordert. Nur, wenn der User sagt "Upgrade auf die nächste Version", dann soll das System das tun. Man sollte nicht manuell Paketquellen eintragen müssen.
Fedora hat dafür bspw. den Befehl dnf system-upgrade, SLE hat zypper migration, openSUSE hat sowas nicht, warum auch immer.
Auch scheinst du absolut keine Ahnung zu haben, wie ein Upgrade im laufenden Betrieb überhaupt abläuft. Ich mache Updates im laufenden Betrieb ohne Probleme, seit das bei Opensuse geht. Und das ist schon sehr lange Zeit der Fall. Mach dich erst einmal kundig, bevor du etwas behauptest.
Schau mal hier, der User klopskind hat es schön erklärt, was die Probleme sind: https://www.pro-linux.de/umfragen/2/547/comm/645296/re8-3-5-opensuse.html
Es wird unter Linux-Entwicklern schon lange diskutiert, wie man die Probleme bei in-place Upgrades lösen könnte. Auch bei SUSE übrigens, die deshalb an einem Werkzeug namens "transactional-update" arbeiten. Du hättest schon längst davon hören müssen, das wurde auf den openSUSE-Blogs schon oft angesprochen, inzwischen wird es sogar als experimentelles Feature im Installer angeboten (seit Leap 15.1 glaub ich).
Du magst mit Opensuse immer wieder mal arbeiten. Ich arbeite mit Suse/Opensuse seit Suse 8.0, also 15 Jahre kontinuierlich. Mit allem Respekt, du schreibst Unsinn.
Du bist also ein langjähriger openSUSE-Anwender - aber dadurch hast du nicht automatisch Ahnung von den technischen Interna, wie du immer wieder unter Beweis stellst.
Bleib bei deinem Ubuntu. Ich will kein Windows mit einem Linux Kernel. Ich will ein Linux, dass sich auch so verhält. Du hast entweder gar keine Ahnung, wie das bei Opensuse überhaupt läuft, oder willst tatächlich nur Bashing betreiben, um nicht zu sagen trollen. Sorry für meine sehr deutliche Wortwahl.
Ich benutze kein Ubuntu (das hat übrigens die gleichen Probleme beim Upgrade wie openSUSE, wie ich schon schrieb) und wie kommst du dauernd auf Windows? Reflektiere dich mal. Es geht hier um Upgrade-Prozesse. Die sind bei verschiedenen Distributionen fehlerhaft (auch bei openSUSE) und deren Entwickler bauen gerade bessere Lösungen (auch die SUSE-Entwickler).
Ich verstehe nicht, warum du mir Bashing vorwirfst. Du steckst mich reflexartig in eine Kiste, ins "feindliche" Lager ("Ubuntu", "Windows",...). Das ist typisches Troll-Verhalten.
Von Ach herrje ... am Sa, 19. Oktober 2019 um 20:33 #
Nur, wenn der User sagt "Upgrade auf die nächste Version", dann soll das System das tun. Man sollte nicht manuell Paketquellen eintragen müssen. Fedora hat dafür bspw. den Befehl dnf system-upgrade, SLE hat zypper migration, openSUSE hat sowas nicht, warum auch immer.
Ist nicht deine erste Falschaussage zum Thema openSUSE. Natürlich hat openSUSE das auch, wenn man das möchte:
/> zypper migration --help Usage: zypper migration [options] --[no-]allow-vendor-change Allow vendor change -v, --[no-]verbose Increase verbosity -q, --[no-]quiet Suppress normal output, print only error messages -n, --non-interactive Do not ask anything, use default answers automatically ... ... ...
Von Was mache ich nur falsch? am So, 13. Oktober 2019 um 17:42 #
Sorry, dein Beitrag liest sich nach dem üblichen Suse/Opensuse Bashing, wo mit aller Gewalt ein Haar in der Suppe gesucht wird.
Geht mit ähnlich. Sobald in diesem Forum jemand etwas Gutes über openSUSE schreibt, kommen immer dieselben langweiligen Bashings hoch. Seit der 8er Version hatte ich SuSE immer mal wieder nebenbei laufen. Seit der openSUSE 13.2 (2015) ständig als einziges System auf dem PC. Hätte ich nur halb soviel Schlechtes festgestellt, wie hier immer wieder kolportiert wird, wäre ich längst mit einem anderen System unterwegs.
Apropos anderes System: ich habe vor einem Monat die Mint 19.2 als Live-System angesehen und bin einigermaßen ernüchtert. Irgendwelche Vorteile der Oberfläche gegenüber KDE-Plasma fand ich nirgends, eher hatte ich den Eindruck, da wurde (eher schlecht als recht) abgekupfert.
Merkwürdiges bei den Systemeinstellungen für Audio: alle Möglichkeiten der Soundwiedergabe wurden erkannt, nur beim Betätigen des Test-Button: Stille überall. Der Medien-Player spielte dagegen die mp3 klaglos ab, sehr seltsam.
Kernel-Verson 4.15, bei einer aktuellen Distribution hätte ich wenigstens eine 5er Version erwartet.
Dann schaute ich mir die die Stände der Software an: Gparted Version 0.3. Gibt es noch ältere Versionen im Umlauf? Aktuell nach etlichen Zwischenständen ist die 1.0.
Dann LibreOffice: Version 6.0, ohjemine. Und auch noch mit Fehlern, die in späteren Versionen längst gefixed sind.
Also wissen Sie ... also wissen Sie neee. An der Stelle habe ich dann abgebrochen und mich nicht weiter umgesehen. Z. B. ob und wie hochauflösende Videos laufen. Da bin ich ziemlich verwöhnt.
Geht mit ähnlich. Sobald in diesem Forum jemand etwas Gutes über openSUSE schreibt, kommen immer dieselben langweiligen Bashings hoch.
Ich habe konkrete Kritik an openSUSE, Debian, Ubuntu, Arch Linux etc. geäußert bzw. an In-Place-Upgrades generell und auf Alternativen verwiesen, von denen eine übrigens von SUSE selbst vorangetrieben wird (transactional-update).
Tatsächlich halte ich viel von openSUSE, bspw. die Integration von snapper ist sehr gelungen bzw. haben die Mädels und Jungs snapper ja überhaupt erst entwickelt. Es ist schade, dass du sachliche Kritik pauschal als Bashing diskreditierst.
Apropos anderes System: ich habe vor einem Monat die Mint 19.2 als Live-System angesehen und bin einigermaßen ernüchtert. Irgendwelche Vorteile der Oberfläche gegenüber KDE-Plasma fand ich nirgends, eher hatte ich den Eindruck, da wurde (eher schlecht als recht) abgekupfert.
Du vergleichst hier ein Desktop-System mit einer Distribution? Mint bietet ja unterschiedliche Oberflächen an, war es denn Cinnamon, Mate, Xfce?
Kernel-Verson 4.15, bei einer aktuellen Distribution hätte ich wenigstens eine 5er Version erwartet.
Du weißt aber schon, dass die aktuelle openSUSE Leap 15.1 den Kernel 4.12 verwendet? Das ist nämlich der gleiche Kernel wie bei SLE 15. Mint verwendet wiederum den Kernel aus Ubuntu LTS. Eine neue Version gibt es erst mit SLE 16 bzw. Ubuntu 20.04.
Dann schaute ich mir die die Stände der Software an: Gparted Version 0.3. Gibt es noch ältere Versionen im Umlauf? Aktuell nach etlichen Zwischenständen ist die 1.0.
openSUSE Leap 15.1 hat hier auch die 0.31. Das ist eben so bei LTS-Distros, dass die Paketversionen etwas abgehangen sind. openSUSE Tumbleweed ist natürlich bei der 1.0, das ist aber auch Rolling Release.
Jeder darf ja gerne seine Lieblingsdistribution haben, aber wir werden doch wohl fair darüber diskutieren können?
Von Was mache ich nur falsch? am Mo, 14. Oktober 2019 um 11:16 #
Ich habe konkrete Kritik an openSUSE, Debian, Ubuntu, Arch Linux etc. ...
Und ich habe eine Tatsache geschildert. Nämlich, dass hier openSUSE grundsätzlich schlecht geredet wird, sobald es jemand auch nur erwähnt.Kann ja jeder nachlesen.
Du weißt aber schon, dass die aktuelle openSUSE Leap 15.1 den Kernel 4.12 verwendet?
Ach gääähn, sicher weiß ich das. Denn im Gegensatz zu dir - und ich schrieb es ja auch ausdrücklich - ist openSUSE hier im täglichen Gebrauch. Und dort habe ich halt auch die aktuellen Versionen im Angebot. Z. B. gerade den Kernel 5.3.6: uname -r 5.3.6-1.g519ea7b-default
Vielleicht habe ich ja auch zu hohe Erwartungen an eine "brandneue Version" von Mint gehabt. Da ist der Kernel ja noch die am wenigstens alte Sache, die anderen Beispiele sind fast 2 Jahre alt. So etwas als brandneu zu präsentieren ist ziemlich schräg. Bei LibreOffice erreichen mich die aktuellen Anpassungen der 6.3.2 wöchentlich und erinnern mich daran, wie vorbildlich da gearbeitet wird. Und wer lieber bei der 6.2 bleiben möchte, kann dies auch tun.
Wenn eine "brandneue" Version mit LibreOffice 6.0 ankommt, weiß ich nicht, ob ich lachen oder weinen soll.
openSUSE Leap 15.1 hat hier auch die 0.31. Das ist eben so bei LTS-Distros, dass die Paketversionen etwas abgehangen sind. openSUSE Tumbleweed ist natürlich bei der 1.0, das ist aber auch Rolling Release.
Die 0.31 ist immerhin schon von 2018 und nicht von 2017 wie die 0.30. Und Leap15.1 ist auch seit einem halben Jahr raus und nicht "brandneu" wie Mint 19.2. Abgesehen davon ist es auch für Leap-Anwender kein Problem, die aktuellen Versionen zu erhalten (s. o.). Man kann für sich halt jede individuelle Abstufung zwischen Rolling Release und "abgehangen" aus den eigenen Repositories erzeugen.
Jeder darf ja gerne seine Lieblingsdistribution haben, aber wir werden doch wohl fair darüber diskutieren können?
Sobald hier einmal jemand openSUSE loben darf, ohne dass sofort Märchen kolportiert werden, dass openSUSE instabil sei und immer noch dieselben alten Fehler aktiv seien und seit Yast2 fragil sei, werde ich dir zustimmen. Und solange das passiert, nenne ich derlei bashing. Denn diese Behauptungen sind unwahr und kommen entweder von Leuten, die seit Jahren openSUSE nicht einmal sahen (die schreiben dann gerne noch SuSE) oder von Leuten, die vorsätzlich lügen.
Und andere lesen das und plappern diesen Unfug nach. Was ja wohl auch der tiefere Sinn dieses Bashing ist: man will Leute von openSUSE fernhalten, damit sie sich mit anderen Distributionen befassen.
1. openSUSE wird hier meines Empfindens nach nicht grundsätzlich schlecht geredet. Tamaskan hat keine Märchen verbreitet, sondern lediglich einen kritischen Einwand geäußert.
2. Ich kann nicht erkennen, inwiefern jene Kritik etwas mit alten Versionen von openSUSE oder YaST zu tun hätte. Meiner Warte ging es um den aktuellen Zustand in openSUSE und anderen Distributionen bzw. deren Vergleich.
3. Handelt es sich tatsächlich um "Bashing", wenn mehrere Distributionen simultan für die selben Dinge kritisiert werden? Genau das hat Tamaskan doch getan: so wurden neben openSUSE auch Debian und Ubuntu genannt. Fedora als ein Alternative. (Wobei Ubuntu wie Fedora auch ein Werkzeug fürs Release-Upgrade mitbringt. Aber das nur Rande.)
4. Die Plausibilität der von Ihnen suggerierten Absichten nicht nur Tamaskans (siehe die letzten zwei letzten Sätze Ihres Kommentars) kann ich in diesem Zusammenhang nur mit Mühe erkennen.
Von Was mache ich nur falsch? am Mo, 14. Oktober 2019 um 15:50 #
1. Es geht mir gar nicht um die Einlassungen von Tamaskan, ich habe ihm lediglich etwas ausführlich geschildert, was mir in diesem Forum in der Vergangenheit negativ auffiel.
2. Der Vorposter "skinnie" schrieb: "Sorry, dein Beitrag liest sich nach dem üblichen Suse/Opensuse Bashing, wo mit aller Gewalt ein Haar in der Suppe gesucht wird." und ich kommentierte "Mir geht es ähnlich" mit Bezug auf übliches Bashing. Das ist wohl nicht klar geworden und schon zieht sich wieder einer einen Schuh an.
3. Und weil hier in der Vergangenheit openSUSE gebasht wurde, schau ich nur noch sporadisch hier herein. Und stolpere prompt über die o. g. Anmerkung von skinnie. Meinetwegen nenne das einen Beißreflex, ich sage dann: wo Rauch ist, ist auch Feuer.
zu 1.: Wessen Äußerungen kritisierten Sie dann? skinnie? lilili? Warum dann auf Kommentare Tamaskans mit antworten, wobei Sie "bashing" (wem?) unterstellen? Es ist doch offensichtlich, dass das zu Missverständnissen führt.
zu 2.: Wenn es Ihnen ähnlich geht wie skinnie mit Bezug auf's vermeintliche "Bashing", dann mussten Sie dieses ja irgendwo wahrgenommen haben. Meine Frage (auch an skinnie): Wo genau?
zu 3.: Aha, unter anderen Artikeln als diesem. Das ist mir nicht klar geworden. Jedenfalls kann ich in dieser Diskussion, hier unter dieser Umfrage, bisher keinen Hinweis auf "Bashing" in Richtung openSUSE erkennen. Tut mir leid.
Vorzeitiges Sensationalisieren und Überdramatisieren ist so eine Sache... Die 112 rufe ich erst, wenn ich das Feuer bzw. die Gefahr tatsächlich erkenne.
Leider fehlt es Ihrer Kritik an der inhaltlich-sachlichen Komponenten. Damit verbleibt nur der Teil des argumentum ad hominem/personam. Und das ist ein weiteres starkes Indiz für einen Troll.
Ach gääähn, sicher weiß ich das. Denn im Gegensatz zu dir - und ich schrieb es ja auch ausdrücklich - ist openSUSE hier im täglichen Gebrauch. Und dort habe ich halt auch die aktuellen Versionen im Angebot. Z. B. gerade den Kernel 5.3.6: uname -r 5.3.6-1.g519ea7b-default
Du solltest vielleicht fairerweise erwähnen, dass dieser Kernel aus dem Open Build Service stammt. Etwas vergleichbares gibt es bei etwa bei Ubuntu/Mint mit den Hardware Enablement Stacks oder bei Debian mit den Backports auch. Du kannst also bei allen drei Distributionen einen aktuellen Kernel bekommen. Die Unterstützung seitens der Entwickler ist dann aber eingeschränkt, was etwa Sicherheitsupdates anbelangt.
Ich habe den Eindruck, dass du deine Distribution noch nicht ganz verstanden hast. Offizielle openSUSE-Pakete sind nur jene, die aus dem "OSS"-Repository stammen, bzw. "openSUSE" im "Vendor"-Feld stehen haben. Alles andere mag auf download.opensuse.org gehostet sein, wird aber von der Community verwaltet. Das gleiche gilt für Packman und andere Repositories.
Bei anderen Distributionen ist das ähnlich, Ubuntu hat etwa seine PPAs, unter Arch Linux gibt es das AUR und bei RHEL/CentOS gibt es EPEL und RPMFusion. Wenn man Distributionen vergleicht, sollte man fairerweise zwischen offiziellen und inoffziellen Paketen trennen.
Von Lass es sein ... am Di, 15. Oktober 2019 um 15:26 #
Ich habe den Eindruck, dass du deine Distribution noch nicht ganz verstanden hast. Offizielle openSUSE-Pakete sind nur jene, die aus dem "OSS"-Repository stammen, bzw. "openSUSE" im "Vendor"-Feld stehen haben.
Und ich habe den Eindruck, du willst hier Korinthen kacken. Das Repository
wird von openSUSE vorgegeben und verwaltet. Wer deine Haarspaltereien nicht teilen mag, hat also etwas nicht verstanden.
Die Einlassung des Vorposters skinnie "das übliche openSUSE-Bashing" hast du soeben eindrucksvoll bestätigt. Ich glaube nicht, dass ich dir jemals wieder antworten möchte.
Du hast mich nicht verstanden. Das Analogon bei Ubuntu wäre das hier: https://kernel.ubuntu.com/~kernel-ppa/mainline/
Ja, das ist auf ubuntu.com gehostet und wird von Ubuntu-Entwicklern gepflegt, aber nein, es ist kein offizieller Bestandteil der Distribution. Wie das entsprechende Repository bei openSUSE. Oder die Backports bei Debian.
Es wurde aber von deinem Vorposter kritisiert, dass der Kernel im offiziellen Ubuntu/Mint-Repository zu alt sei, worauf ich erwiderte, dass der Kernel im offiziellen openSUSE-Repository noch viel älter sei. Er argumentierte dann mit dem inoffiziellen openSUSE-Kernel-Repository - aber dann müsste er das fairerweise mit dem inoffiziellem Ubuntu-Kernel-Repository vergleichen und dann kommen wir auf die gleiche Kernel-Version (5.3).
Ich möchte nicht openSUSE bashen! Ich wollte nur anmerken, dass man doch bitteschön nicht mit verschiederlei Maß messen sollte. Meine Unterstellung, der Vorposter kenne seine Distribution nicht, war gut gemeint, da man ansonsten annehmen müsste, er hätte mich täuschen wollen.
openSUSE KDE 64bit "verbraucht" übrigens direkt nach Systemstart ca. 420 MB RAM, das ist in den letzten Versionen recht stabil und auch mit Leap 15.1 so. Finde ich jetzt nicht unbedingt viel, zumal Kubuntu z.B. eher Richtung >800 MB bei gleichen Voraussetzungen geht.Ok, vielleicht kann Mint das Risiko gehen, weil bei denen mit Patentklagen sowieso nichts zu holen ist. Ich verstehe aber, das SUSE und Red Hat sich da absichern müssen.
Übrigens ist das installieren der benötigten Codecs mittels https://www.opensuse-community.org/ nun auch nicht gerade schwierig...
LinuxMint installiert Codecs standardmäßig seit einigen Versionen auch nicht mehr mit, außer Du wählst die entsprechende Option während der Installation. Solltest Du diese nicht gewählt haben erscheint später im Menü ein Punkt 'Install Proprietary Codecs" über den dies bei Bedarf nachgeholt werden kann.
Die entspricht von der 'Einfachheit' ungefähr der für openSUSE notwendigen Schritte (1-click-install / Repo Priorität setzen).
Bezüglich der beschriebenen Probleme, so kann ich diese ebenfalls nicht nachvollziehen. Insbesondere die Drucker und Scannerunterstützung ist bei openSUSE als sehr gut bekannt. Ob der selbstgeschriebene Netzwerkdienst 'wicked' der Weisheit letzter Schluss ist, steht auf einem anderen Blatt.
Für ein Dist-Upgrade sollten zwingend die hier beschriebenen Anweisungen befolgt werden:
https://de.opensuse.org/SDB:Distribution-Upgrade
Auch ich kann solche Fehler bei Upgrades schon seit sehr vielen Jahren nicht mehr bestätigen. Gerade Opensuse hat eine der besten Upgrade Funktionen.
Seit meinem Umstieg auf Tumbleweed sind Updates für mich ohnehin kein Thema mehr. Und entgegen so mancher Unkenrufe läuft Tumbleweed zumindest bei mir absolut stabil.
Edit und Nachtrag: Ich nutze Suse/Opensuse seit Suse 8.0.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 11. Okt 2019 um 18:42.Da muss ich strikt widersprechen. openSUSE macht hier den gleichen Murks wie Debian oder Ubuntu: Man muss die Paketquellen anpassen (oft manuell), und dann wird das Upgrade im laufenden System drüber installiert. Meistens funktioniert das.
Fedora hat hier einen deutlich besseren Ansatz (dnf system-upgrade): Zuerst werden die benötigten Pakete heruntergeladen, dann wird in ein spezielles systemd-Target gerebootet, in der dann das Upgrade installiert wird. Das ist weit weniger fehleranfällig, da dem laufenden System nicht der Boden unter den Füßen weggezogen wird.
Solange du das upgrade in der tty ausführst und wie bereits erwähnt wurde alle Pakete zuvor manuell herunterlädst ist das vollkommen unkritisch. Mit snapper kannst du sogar noch einen Snapshot von der alten Version erstellen (btrfs / default).
Wenn dir so ein systemd upgrade mal schief gelaufen ist, wirst du feststellen, dass es auch nicht der Weisheit letzter Schluss ist.
Aber stateless Systeme wie Clear Linux sind ja in Aufwind. Dann kannst du ohne grosse Hacks dein Core / Kernel gar nicht mehr modifizieren. Yippie!
Übrigens ist mir bei zypper dups noch nie etwas kaputt gegangen.
In diesem Zusammenhang wären die sogenannten transactional-updates, welche vom Kubic-Project abstammen, aber auch in Leap/Tumbleweed ihren Einzug fanden, zu nennen.
Auf dem Desktop scheint das Ganze wohl teilweise noch etwas hakelig, siehe z.B. auch die hier genannten Fallstricke.
Als "fertig" im Sinne von Endanwendern ist das also noch nicht einzustufen.
Das ist genau das, was ich kritisiere: Upgrade in einer TTY ausführen, Pakete vorab downloaden, da versucht man die Probleme zu umgehen, was man mit einem vernünftigen Upgrademechanismus nicht müsste.
Ich glaube, du hast das Konzept dahinter nicht verstanden. Du kannst alles tun, was du bisher auch tun konntest, nur mit weit geringerem Risiko, da du stehts den alten Zustand wieder booten kannst. Wenn du willst, kannst du während eines Upgrades den Stecker ziehen, und nichts geht kaputt.
Dann hast du bisher nur den Happy Path gesehen, aber das solltest du nicht verallgemeinern.
Geht das auch etwas präziser, oder soll das am Ende doch nur Bashing sein. Aber klar, es kann immer etwas schief gehen. So gesehen geht in der IT immer alles nur "meistens".
Natürlich muss man die Paktequellen anpassen, wenn du nicht strikt nur Pakete aus dem Hauptrepository installierst. Mit Verlaub, wenn dich sogar das überfordert, würde ich dir in der Tat das beste OS der Welt aus Redmond empfehlen. Da klappt jedes Upgrade garantiert ohne Probleme.
Geht der Ansatz von Fedora auch im laufenden Betrieb. Wenn da in ein spezielles systemd-Target rebootet werden muss, kann ich mir das nur schwer vorstellen.
Mit Tumbleweed als Rolling Distribution habe ich das Thema Upgrades ohnehin abgehakt. Sorry, dein Beitrag liest sich nach dem üblichen Suse/Opensuse Bashing, wo mit aller Gewalt ein Haar in der Suppe gesucht wird.
Das Betriebssystem sollte von selbst merken, dass es ein neues Release gibt, das Upgrade anbieten, und dann ggf. die Paketquellen selbst modifizieren. Fedora und Ubuntu kriegen das schon seit Jahren hin. während man bei Debian und Suse selbst herumeditieren muss.
Man will keine Upgrades im laufenden Betrieb durchführen, weil man dann Dateien löschen oder überschreiben muss, die von Programmen gerade verwendet werden. Genau deswegen macht es Sinn, vorher alle Pakete herunterzuladen und dann während eines Neustarts alles zu installieren.
Noch sauberer sind Ansätze wie in Fedora Silverblue oder openSUSE Kubic, wo überhaupt nicht mehr in-place überschrieben wird.
Da hast du genau das gleiche Problem, nur dass Änderungen nicht alle auf einmal kommen, sondern nach und nach.
Es wurde behauptet, openSUSE hätte einen besonders guten Upgrademechanismus, und das ist schlicht falsch - und ich habe auch erklärt, wieso. SUSE selbst hat das auch erkannt und arbeitet an neuen Lösungen (transactional-update).
Ich habe nichts gegen (open)SUSE, arbeite selbst damit immer mal wieder. Man muss Software jedoch objektiv betrachten und Probleme benennen dürfen, sonst kann man sie auch nicht lösen.
Ist doch nicht so schwer, nach Aufruf von
zypper dupeinmalzypper ps -sund die dort angezeigten Dienste per
systemctl restart [name]neu zu starten. Selbst der systemd-Prozess kann persystemctl daemon-reexec
neu ausgeführt werden. Und schon ist man auf dem neusten Stand, ohne reboot*
* Kernelupgrade ausgenommen; kann Spuren von Haselnüssen enthalten.
Zudem können sich weitere, von Entwicklern oder Paketierern unbeabsichtigte oder unvorhergesehene Fehlerquellen einschleichen.
Kann es an dieser Stelle nicht bereits "zu spät" sein? Szenario: Dienst A1 wird aktualisiert während er läuft. Er soll neugestartet werden, wofür aber dessen Zustand serialisiert werden muss. Tut er das mithilfe eines noch gestarteten Prozesses A2, geschieht dies mit den aktualisierten Komponenten/Bibliotheken, welche der Dienst A1 noch nicht geladen hatte, was zu einer fehlerhaften Serialisierung des Zustands führen kann (z.B. soname-Inkrement mangels Abwärtskompatibilität). Der Zustand könnte bspw. eine Konfiguration, ein Benutzerprofil, ein Arbeits- oder Brechnungsfortschritt oder eine Datenbank sein.Und das wäre nur ein einziges Szenario. Letztlich geht es eigentlich darum, den Zustand des Systems strikter von den Daten zu trennen. Da hilft ein Separierung der Durchführung der Aktualisierung vom Rest, z.B. mittels Neustart, ungemein. Genau deswegen existieren etwaige Bestrebungen, Entwicklungen und Alternativen.
In diesen Zeiten, in denen read-only Systeme oder Container am laufenden Band neu erstellt angepasst, zusammengesetzt, neu erstellt, (neu-)gestartet oder/und beendet werden, spielt diese Form der Systemaktualisierung ein untergeordnetere Rolle (auch für die Entwickler/Paketerierer!), siehe Kubic, Project Atomic / Atomic Host, Silverblue, CoreOS, Docker, Kubernetes etc.
Verschiedene Systeme haben hier unterschiedliche Anforderungen. Aber die müsste der Nutzer kennen. So entstehen bspw. auf dem Desktop folgende Probleme, [1].
Eine Anekdote darf nicht fehlen: Ich persönlich hatte auch mal mit einem Fall zu tun, bei dem Firefox aktualisiert wurde während es lief. Dann wurde eine neue Firefox-Instanz gestartet (nicht besonders "schlau", wenn man es denn weiß), und nach dem Schließen beider Instanzen, gab es bei darauffolgenden Starts einen Dateiformatkonflikt einer Datei des Benutzerprofils. Ich glaube mich zu erinnern, dass es eine von Firefox erstellte und verwendete SQLite-Datenbankdatei betraf.
Ich denke, dass es genügend realistische Hinweise dafür gibt, dass offline-Upgrades robuster sind als online-Upgrades - insbesondere dann, wenn jemand nicht 100% weiß, was sie/er tut.
Quellen:
[0] - Debian-Richtlinie: idempotente Maintainer-Skripte
[1] - "dnf update" considered harmful
Du übersiehst, dass bei opensuse die Versionen überlappend gepflegt werden. Ich will nicht, dass opensuse automatisch Upgraded. Und die normalen Updates bekomme ich sehr wohl angezeigt.
Welches Problem ich bei Tumbleweed mit Upgrades haben soll, die es gar nicht geht erschließt sich mir nun wirklich nicht.
Opensuse ist kein Windows, wo mir das System sagt, dass ich upgraden muss. Opensuse lässt mir die Freiheit, selbst zu entscheiden, welche Version ich fahren will. Und genau wegen solcher Freiheiten verwende ich Linux. Auch scheinst du absolut keine Ahnung zu haben, wie ein Upgrade im laufenden Betrieb überhaupt abläuft. Ich mache Updates im laufenden Betrieb ohne Probleme, seit das bei Opensuse geht. Und das ist schon sehr lange Zeit der Fall. Mach dich erst einmal kundig, bevor du etwas behauptest.
Du magst mit Opensuse immer wieder mal arbeiten. Ich arbeite mit Suse/Opensuse seit Suse 8.0, also 15 Jahre kontinuierlich. Mit allem Respekt, du schreibst Unsinn.
Bleib bei deinem Ubuntu. Ich will kein Windows mit einem Linux Kernel. Ich will ein Linux, dass sich auch so verhält. Du hast entweder gar keine Ahnung, wie das bei Opensuse überhaupt läuft, oder willst tatächlich nur Bashing betreiben, um nicht zu sagen trollen. Sorry für meine sehr deutliche Wortwahl.
Das habe ich nicht gefordert. Nur, wenn der User sagt "Upgrade auf die nächste Version", dann soll das System das tun. Man sollte nicht manuell Paketquellen eintragen müssen.
Fedora hat dafür bspw. den Befehl dnf system-upgrade, SLE hat zypper migration, openSUSE hat sowas nicht, warum auch immer.
Schau mal hier, der User klopskind hat es schön erklärt, was die Probleme sind: https://www.pro-linux.de/umfragen/2/547/comm/645296/re8-3-5-opensuse.html
Es wird unter Linux-Entwicklern schon lange diskutiert, wie man die Probleme bei in-place Upgrades lösen könnte. Auch bei SUSE übrigens, die deshalb an einem Werkzeug namens "transactional-update" arbeiten. Du hättest schon längst davon hören müssen, das wurde auf den openSUSE-Blogs schon oft angesprochen, inzwischen wird es sogar als experimentelles Feature im Installer angeboten (seit Leap 15.1 glaub ich).
Du bist also ein langjähriger openSUSE-Anwender - aber dadurch hast du nicht automatisch Ahnung von den technischen Interna, wie du immer wieder unter Beweis stellst.
Ich benutze kein Ubuntu (das hat übrigens die gleichen Probleme beim Upgrade wie openSUSE, wie ich schon schrieb) und wie kommst du dauernd auf Windows? Reflektiere dich mal. Es geht hier um Upgrade-Prozesse. Die sind bei verschiedenen Distributionen fehlerhaft (auch bei openSUSE) und deren Entwickler bauen gerade bessere Lösungen (auch die SUSE-Entwickler).
Ich verstehe nicht, warum du mir Bashing vorwirfst. Du steckst mich reflexartig in eine Kiste, ins "feindliche" Lager ("Ubuntu", "Windows",...). Das ist typisches Troll-Verhalten.
Nur, wenn der User sagt "Upgrade auf die nächste Version", dann soll das System das tun. Man sollte nicht manuell Paketquellen eintragen müssen.
Fedora hat dafür bspw. den Befehl dnf system-upgrade, SLE hat zypper migration, openSUSE hat sowas nicht, warum auch immer.
Ist nicht deine erste Falschaussage zum Thema openSUSE. Natürlich hat openSUSE das auch, wenn man das möchte:
/> zypper migration --help
Usage: zypper migration [options]
--[no-]allow-vendor-change Allow vendor change
-v, --[no-]verbose Increase verbosity
-q, --[no-]quiet Suppress normal output, print only error messages
-n, --non-interactive Do not ask anything, use default answers automatically
... ... ...
Geht mit ähnlich. Sobald in diesem Forum jemand etwas Gutes über openSUSE schreibt, kommen immer dieselben langweiligen Bashings hoch. Seit der 8er Version hatte ich SuSE immer mal wieder nebenbei laufen. Seit der openSUSE 13.2 (2015) ständig als einziges System auf dem PC. Hätte ich nur halb soviel Schlechtes festgestellt, wie hier immer wieder kolportiert wird, wäre ich längst mit einem anderen System unterwegs.
Apropos anderes System: ich habe vor einem Monat die Mint 19.2 als Live-System angesehen und bin einigermaßen ernüchtert. Irgendwelche Vorteile der Oberfläche gegenüber KDE-Plasma fand ich nirgends, eher hatte ich den Eindruck, da wurde (eher schlecht als recht) abgekupfert.
Merkwürdiges bei den Systemeinstellungen für Audio: alle Möglichkeiten der Soundwiedergabe wurden erkannt, nur beim Betätigen des Test-Button: Stille überall. Der Medien-Player spielte dagegen die mp3 klaglos ab, sehr seltsam.
Kernel-Verson 4.15, bei einer aktuellen Distribution hätte ich wenigstens eine 5er Version erwartet.
Dann schaute ich mir die die Stände der Software an: Gparted Version 0.3. Gibt es noch ältere Versionen im Umlauf? Aktuell nach etlichen Zwischenständen ist die 1.0.
Dann LibreOffice: Version 6.0, ohjemine. Und auch noch mit Fehlern, die in späteren Versionen längst gefixed sind.
Also wissen Sie ... also wissen Sie neee. An der Stelle habe ich dann abgebrochen und mich nicht weiter umgesehen. Z. B. ob und wie hochauflösende Videos laufen. Da bin ich ziemlich verwöhnt.
Ich habe konkrete Kritik an openSUSE, Debian, Ubuntu, Arch Linux etc. geäußert bzw. an In-Place-Upgrades generell und auf Alternativen verwiesen, von denen eine übrigens von SUSE selbst vorangetrieben wird (transactional-update).
Tatsächlich halte ich viel von openSUSE, bspw. die Integration von snapper ist sehr gelungen bzw. haben die Mädels und Jungs snapper ja überhaupt erst entwickelt. Es ist schade, dass du sachliche Kritik pauschal als Bashing diskreditierst.
Du vergleichst hier ein Desktop-System mit einer Distribution? Mint bietet ja unterschiedliche Oberflächen an, war es denn Cinnamon, Mate, Xfce?
Du weißt aber schon, dass die aktuelle openSUSE Leap 15.1 den Kernel 4.12 verwendet? Das ist nämlich der gleiche Kernel wie bei SLE 15. Mint verwendet wiederum den Kernel aus Ubuntu LTS. Eine neue Version gibt es erst mit SLE 16 bzw. Ubuntu 20.04.
openSUSE Leap 15.1 hat hier auch die 0.31. Das ist eben so bei LTS-Distros, dass die Paketversionen etwas abgehangen sind. openSUSE Tumbleweed ist natürlich bei der 1.0, das ist aber auch Rolling Release.
Jeder darf ja gerne seine Lieblingsdistribution haben, aber wir werden doch wohl fair darüber diskutieren können?
uname -r
5.3.6-1.g519ea7b-default
Vielleicht habe ich ja auch zu hohe Erwartungen an eine "brandneue Version" von Mint gehabt. Da ist der Kernel ja noch die am wenigstens alte Sache, die anderen Beispiele sind fast 2 Jahre alt. So etwas als brandneu zu präsentieren ist ziemlich schräg. Bei LibreOffice erreichen mich die aktuellen Anpassungen der 6.3.2 wöchentlich und erinnern mich daran, wie vorbildlich da gearbeitet wird. Und wer lieber bei der 6.2 bleiben möchte, kann dies auch tun.
Wenn eine "brandneue" Version mit LibreOffice 6.0 ankommt, weiß ich nicht, ob ich lachen oder weinen soll.
Die 0.31 ist immerhin schon von 2018 und nicht von 2017 wie die 0.30. Und Leap15.1 ist auch seit einem halben Jahr raus und nicht "brandneu" wie Mint 19.2. Abgesehen davon ist es auch für Leap-Anwender kein Problem, die aktuellen Versionen zu erhalten (s. o.). Man kann für sich halt jede individuelle Abstufung zwischen Rolling Release und "abgehangen" aus den eigenen Repositories erzeugen.
Sobald hier einmal jemand openSUSE loben darf, ohne dass sofort Märchen kolportiert werden, dass openSUSE instabil sei und immer noch dieselben alten Fehler aktiv seien und seit Yast2 fragil sei, werde ich dir zustimmen. Und solange das passiert, nenne ich derlei bashing. Denn diese Behauptungen sind unwahr und kommen entweder von Leuten, die seit Jahren openSUSE nicht einmal sahen (die schreiben dann gerne noch SuSE) oder von Leuten, die vorsätzlich lügen.Und andere lesen das und plappern diesen Unfug nach. Was ja wohl auch der tiefere Sinn dieses Bashing ist: man will Leute von openSUSE fernhalten, damit sie sich mit anderen Distributionen befassen.
1. openSUSE wird hier meines Empfindens nach nicht grundsätzlich schlecht geredet. Tamaskan hat keine Märchen verbreitet, sondern lediglich einen kritischen Einwand geäußert.
2. Ich kann nicht erkennen, inwiefern jene Kritik etwas mit alten Versionen von openSUSE oder YaST zu tun hätte. Meiner Warte ging es um den aktuellen Zustand in openSUSE und anderen Distributionen bzw. deren Vergleich.
3. Handelt es sich tatsächlich um "Bashing", wenn mehrere Distributionen simultan für die selben Dinge kritisiert werden? Genau das hat Tamaskan doch getan: so wurden neben openSUSE auch Debian und Ubuntu genannt. Fedora als ein Alternative. (Wobei Ubuntu wie Fedora auch ein Werkzeug fürs Release-Upgrade mitbringt. Aber das nur Rande.)
4. Die Plausibilität der von Ihnen suggerierten Absichten nicht nur Tamaskans (siehe die letzten zwei letzten Sätze Ihres Kommentars) kann ich in diesem Zusammenhang nur mit Mühe erkennen.
1. Es geht mir gar nicht um die Einlassungen von Tamaskan, ich habe ihm lediglich etwas ausführlich geschildert, was mir in diesem Forum in der Vergangenheit negativ auffiel.
2. Der Vorposter "skinnie" schrieb:
"Sorry, dein Beitrag liest sich nach dem üblichen Suse/Opensuse Bashing, wo mit aller Gewalt ein Haar in der Suppe gesucht wird."
und ich kommentierte "Mir geht es ähnlich" mit Bezug auf übliches Bashing. Das ist wohl nicht klar geworden und schon zieht sich wieder einer einen Schuh an.
3. Und weil hier in der Vergangenheit openSUSE gebasht wurde, schau ich nur noch sporadisch hier herein. Und stolpere prompt über die o. g. Anmerkung von skinnie. Meinetwegen nenne das einen Beißreflex, ich sage dann: wo Rauch ist, ist auch Feuer.
Und damit bin ich wieder weg ...
zu 1.: Wessen Äußerungen kritisierten Sie dann? skinnie? lilili? Warum dann auf Kommentare Tamaskans mit antworten, wobei Sie "bashing" (wem?) unterstellen?
Es ist doch offensichtlich, dass das zu Missverständnissen führt.
zu 2.: Wenn es Ihnen ähnlich geht wie skinnie mit Bezug auf's vermeintliche "Bashing", dann mussten Sie dieses ja irgendwo wahrgenommen haben. Meine Frage (auch an skinnie): Wo genau?
zu 3.: Aha, unter anderen Artikeln als diesem. Das ist mir nicht klar geworden. Jedenfalls kann ich in dieser Diskussion, hier unter dieser Umfrage, bisher keinen Hinweis auf "Bashing" in Richtung openSUSE erkennen. Tut mir leid.
Vorzeitiges Sensationalisieren und Überdramatisieren ist so eine Sache... Die 112 rufe ich erst, wenn ich das Feuer bzw. die Gefahr tatsächlich erkenne.
Leider fehlt es Ihrer Kritik an der inhaltlich-sachlichen Komponenten. Damit verbleibt nur der Teil des argumentum ad hominem/personam.
Und das ist ein weiteres starkes Indiz für einen Troll.
Du solltest vielleicht fairerweise erwähnen, dass dieser Kernel aus dem Open Build Service stammt. Etwas vergleichbares gibt es bei etwa bei Ubuntu/Mint mit den Hardware Enablement Stacks oder bei Debian mit den Backports auch. Du kannst also bei allen drei Distributionen einen aktuellen Kernel bekommen. Die Unterstützung seitens der Entwickler ist dann aber eingeschränkt, was etwa Sicherheitsupdates anbelangt.
Ich habe den Eindruck, dass du deine Distribution noch nicht ganz verstanden hast. Offizielle openSUSE-Pakete sind nur jene, die aus dem "OSS"-Repository stammen, bzw. "openSUSE" im "Vendor"-Feld stehen haben. Alles andere mag auf download.opensuse.org gehostet sein, wird aber von der Community verwaltet. Das gleiche gilt für Packman und andere Repositories.
Bei anderen Distributionen ist das ähnlich, Ubuntu hat etwa seine PPAs, unter Arch Linux gibt es das AUR und bei RHEL/CentOS gibt es EPEL und RPMFusion. Wenn man Distributionen vergleicht, sollte man fairerweise zwischen offiziellen und inoffziellen Paketen trennen.
Und ich habe den Eindruck, du willst hier Korinthen kacken. Das Repository
http://download.opensuse.org/repositories/Kernel:/openSUSE-15.1/
wird von openSUSE vorgegeben und verwaltet. Wer deine Haarspaltereien nicht teilen mag, hat also etwas nicht verstanden.
Die Einlassung des Vorposters skinnie "das übliche openSUSE-Bashing" hast du soeben eindrucksvoll bestätigt. Ich glaube nicht, dass ich dir jemals wieder antworten möchte.
Du hast mich nicht verstanden. Das Analogon bei Ubuntu wäre das hier: https://kernel.ubuntu.com/~kernel-ppa/mainline/
Ja, das ist auf ubuntu.com gehostet und wird von Ubuntu-Entwicklern gepflegt, aber nein, es ist kein offizieller Bestandteil der Distribution. Wie das entsprechende Repository bei openSUSE. Oder die Backports bei Debian.
Es wurde aber von deinem Vorposter kritisiert, dass der Kernel im offiziellen Ubuntu/Mint-Repository zu alt sei, worauf ich erwiderte, dass der Kernel im offiziellen openSUSE-Repository noch viel älter sei. Er argumentierte dann mit dem inoffiziellen openSUSE-Kernel-Repository - aber dann müsste er das fairerweise mit dem inoffiziellem Ubuntu-Kernel-Repository vergleichen und dann kommen wir auf die gleiche Kernel-Version (5.3).
Ich möchte nicht openSUSE bashen! Ich wollte nur anmerken, dass man doch bitteschön nicht mit verschiederlei Maß messen sollte. Meine Unterstellung, der Vorposter kenne seine Distribution nicht, war gut gemeint, da man ansonsten annehmen müsste, er hätte mich täuschen wollen.