Man unterscheidet halt, ob es bei der normalen Verwendung abstürzt, oder weil man etwas macht, was man nicht machen sollte (oder etwas was man nicht oft macht=
JuK stürzt bei mir z.B. ab, wenn man im System einen Ordner löscht, welcher von JuK verwaltet wird (und vorher nicht aus JuK entfernt wurde). Sollte zwar nicht vorkommen, aber wie oft tut man das (bzw. kann man darüber streiten, ob man es überhaupt so machen soll)
>> Man unterscheidet halt, ob es bei der normalen Verwendung abstürzt, oder weil man etwas macht, was man nicht machen sollte (oder etwas was man nicht oft macht=
Aha ... ich sehe das eher so das alle möglichen Optionen des Desktops einwandfrei laufen sollten. zb schliessen von gesplitteten Ansichten in Kate, oder das intensive Verwenden von Nepomuk.
Auch sehe ich absolut nichts verwerfliches daran IMAP einzusetzen, IMAP-Ordner anzulegen, zu löschen Emails in diversen Ordnern hin&Herzuschieben usw... -. und einen haufen Filteroptionen anzulegen.
>> JuK stürzt bei mir z.B. ab, wenn man im System einen Ordner löscht, welcher von JuK verwaltet wird (und vorher nicht aus JuK entfernt wurde). Sollte zwar nicht vorkommen, aber wie oft tut man das (bzw. kann man darüber streiten, ob man es überhaupt so machen soll)
Robuste Programme sollten Abstütze möglichst vermeiden - das ist jetzt aber nichts grundlegend neues in der Desktop-Entwicklung.
Ja sie sollten nicht abstürzen. Nichtsdestotrotz kann man als Mensch nicht jeden Fehler im Vorfeld ausschließen. Außerdem wird man auf die meisten Probleme erst dann aufmerksam, wenn ein Absturz stattfindet und die Probleme werden wirklich schnell behoben.
Stabilität ist stark abhängig von der Komplexität, und die ist bei KDE SC (einer Sammlung von Programmen für alles Mögliche) extrem hoch.
Man kann's auch nicht wie ein statisches Objekt sehen, Software (und die Systeme auf denen sie laufen) sind ständig in Bewegung, Use-cases, und natürlich die Software selber, die weiterentwickelt wird, Performanceupdates erhält, Bugfixes, und neue Funktionen.
Dabei schleichen sich Bugs ein, das ist ein natürlicher Prozess. Es ist komplett sinnvoll die Anwesendheit von Bugs zu akzeptieren, und sich hinzusetzen, diese zu fixen, nicht einmal, sondern immer wieder.
Wenn man sich exemplarisch einen Bug wie den Crasher in Kate's Splitview genauer anschaut, wird dies besonders deutlich: Der Fehler wurde zusammen mit einem neuen Feature (der Code Minimap Scrollbar) eingeführt, den Bug gab's beim vorigen Release noch gar nicht, da diese Funktion erst Anfang Februar mit KDE SC 4.10 dazugekommen ist. Er wurde am 18. Februar von einem Benutzer gemeldet, am 19. Februar wurde er in der stable Branch gefixed, dieser Fix ist mit dem aktuellen Release den Benutzern bereitgestellt worden. Das ist ein gut funktionierender Entwicklungsprozess.
Für den Benutzer ist es wesentlich wichtiger, schnelle Respons auf Fehlerberichte zu bekommen, als Software deren Entwickler Bugs ignorieren, oder sie sogar abstreiten, oder Software die nie das Licht der Welt erblickt, weil die Entwickler perfektionistisch sind. Perfect is the enemy of good.
Manchen kann man es eben nie recht machen. Da kommt ein .0-Release raus, und sie schreien "Lauter Abstürze!" (ich war übrigens von keinem einzigen der aufgeführten betroffen...), einen Monat später kommt das .1-Release mit Behebung der Fehler, und statt Danke kommt höchstens etwas wie "hätte nie passieren sollen".
Ich freue mich auf 4.10.1 und hoffe, dass es heute noch in Chakra Desktop landet. Und ein Danke an die Entwickler!
.. Wieso sollte ich als Anwender Ahnung von Entwicklungsprozessen haben muessen?!
Ich kann nur sagen das Windows, Textpad, Outlook, MS-Office bei mir trotz intensivem Einsatz (privat wie kommerziell) in den letzten 10jahren im Desktopbereich nicht ansatzweise so viele crashs verursacht haben wie kde+kate+kmail+koffice. MacOS10 ist nach ersten Tests auch deutlich stabiler.
Als Anwender muss man natürlich keine Ahnung vom Entwicklungsprozess haben. Aber es gibt auch so eine alte Redewendung in etwa "Wenn man von etwas keine Ahnung hat, sollte man besser die Klappe halten".
Der erste Kommentar in dem Thread hier, klingt halt wie ein typischer Trollpost oder wie ein Kommentar von jemandem, der nicht versteht wie Softwareentwicklung funktioniert und dass es immer Softwarefehler gibt.
Da aber hier (und anderswo) kritisiert wird, dass wir Fehler beheben, wäre es für uns viel einfacher keine Bugfix Releases mehr zu machen. Mir ist das ja egal, ich hab master und damit sofort die neuesten Fehlerbehebungen. Spart uns viel Zeit. Dann können wir aber auch nicht Regressionen in Treibern umgehen, wie in 4.10.1 geschehen um auf ein Problem in Mesa 9.1, welches nach 4.10.0 veröffentlicht wurde, zu reagieren.
Leider scheinen diese im freien OpenSource-Bereich im Desktop-Betrieb häufiger vorzukommen als im kommerziellen Bereich.
>> Da aber hier (und anderswo) kritisiert wird, dass wir Fehler beheben, wäre es für uns viel einfacher keine Bugfix Releases mehr zu machen.
Fehlerbehebungen werden nicht kritisiert - sondern das solche Fehler in einem stabilen Release überhaupt in der Form vorkommen. Längere Testphasen könnten das Problem imho reduzieren. Ein anderer Mechanismus der Fehlerbehebung bzw der Patch-Verteilung könnte imho auch dafür sorgen das Bugfixes deutlich schneller beim Endanwender ankommen.
Warum kann ich als Anwender nicht zwischen verschiedenen Applikationsversionen frei wählen? zb "foobar 2.6.10, 2.6.11 oder 2.8.20", und wenn die app-version mir nicht mehr passt wieder zurück nach "foobar 2.2.10"? Dann könnte ich eine schlecht funktionierende App einfach via Mausklick gegen eine ältere Version austauschen. MacOS hat dies auf einem Unix-System imho sehr vorbildlich gelöst. Auch ist hier die Gesamtstabilität des Desktops imho deutlich besser als unter KDE.
Leider scheinen diese im freien OpenSource-Bereich im Desktop-Betrieb häufiger vorzukommen als im kommerziellen Bereich.
Schwachsinn. Eine der Philosophien von OpenSource ist "Release Early, Release Often". Bei KDE ist das 6 Monate, was ich persönlich zu lange finde. Wenn du lieber einen lange Testphase hast und nur alle paar Jahre ein Release wie bei Microsoft Windows üblich, dann empfehle ich Debian stable, RHES oder SLED.
Fehlerbehebungen werden nicht kritisiert - sondern das solche Fehler in einem stabilen Release überhaupt in der Form vorkommen.
Ja da gib ich dir vollkommen Recht und gebe das dann doch an die Nutzer weiter, die nicht getestet haben. Ich bin immer enttäuscht, wenn wir einen Bugreport nach dem Release bekommen. Würde ja gerne jetzt auf einen Blogpost von mir linken wo ich das vor Kurzem thematisiert habe, aber Hetzner hat mir mal wieder die Resourcen runtergesetzt.
Warum kann ich als Anwender nicht zwischen verschiedenen Applikationsversionen frei wählen? zb "foobar 2.6.10, 2.6.11 oder 2.8.20", und wenn die app-version mir nicht mehr passt wieder zurück nach "foobar 2.2.10"?
De Frage ist natürlich, wieso es keine Testinfrastruktur geben kann, die das von vornherein ausschließt. Sicherlich hilft auch crossplattform, weil man dann die tollen Entwicklungs-Tools anderer Systeme auch nutzen kann.
>> Debian stable, RHES oder SLED. Bei DebianStable hatte ich auch schon repoduzierbare Crashes (Debian 4.0 > "u.a." kaffeine, beim Abspielen von ogg-Audiofiles beim vor/zurückspulen).
Dazu kommt insbesondere das SLED leider in den Versionen die ich getestet hatte die Multimediatauglichkeit eher eingeschränkt war. SuSE propagiert hier auch kommerzielle Software zum absielen von nicht 100% freien codecs. Da mir die Programme nicht gefallen muss ich dann praktisch quellen von Drittanbietern (Packman) hinzufügen - das ist dann unschön. Auch sind diverse Desktop-Applikationen schon "spürbar" veraltet.
Aber im Grunde finde ich den Weg von SLED schon sehr gut. Ich würde "gerne" im Jahr 250EUR bezahlen wenn ich dafür einen "langzeitstabilen, langzeitzuverlässigen" Desktop mit guter Multimedia-Fähigkeiten, "aktuellen" Applikationen sowie guter kommerzieller Applikations-Unterstützung (vmware & co) erhalten könnte.
Und das mein ich nicht als Trollerei - sondern als wirklichen Wunsch.
>> Frag besser den Distributor deines Vertrauens Die brauch ich nicht zu fragen.... die finden ihre Paketsysteme hervorragend. Auch hier wird man für solche Wünsche regelmäßig zerrissen.
>> Ich bin immer enttäuscht, wenn wir einen Bugreport nach dem Release bekommen. Wo gibt es zu "RC"-Zeit eine aktuelle GNU/Linux-Version per ISO-CD zum Download welche ich via VMware oder Co booten kann, um die aktuelle KDE-RC Version ausführlich testen zu können? Wo gibt es die Hilfstools - mit denen ich ohne Aufwand, ohne Registration, ohne Suche ob es den Bug schon gibt Fehler melden kann?
Warum testen Entwickler ihre Software nicht selbst? Gerade in der frühen KDE4-Phase (Kde4.1-4.4) sind etliche Bugs/Ungereimtheiten oder Usability-Unschömnheiten einem massiv entgegen gesprungen - da hätte es keinen Test benötigt um das zu sehen.
Meine Freizeit ist Berufsbedingt eingeschraenkt. Da möchte ich keine grossen Ressourcen mit Bugsuchen und Co verschwenden, sondern schnell unkompliziert den Fehler melden - fertig. Wie gesagt - ich bin gerne bereit Geld auszugeben - so wie ich das heute bei der konkurrenz tue, und von 1998-2004 schon bei SuSE tat.
>> Ich bin immer enttäuscht, wenn wir einen Bugreport nach dem Release bekommen. Wo gibt es zu "RC"-Zeit eine aktuelle GNU/Linux-Version per ISO-CD zum Download welche ich via VMware oder Co booten kann, um die aktuelle KDE-RC Version ausführlich testen zu können?
Von ............... am So, 10. März 2013 um 20:10 #
"Wie gesagt - ich bin gerne bereit Geld auszugeben - so wie ich das heute bei der konkurrenz tue, und von 1998-2004 schon bei SuSE tat."
Dafür ist es im Linuxbereich zu spät. Sowohl Suse wie auch Red Hat werden keine kommerziellen Privatanwenderdistributionen mehr anbieten. Wenn man der Pleite ins Auge gesehen hat, macht man nur sehr selten den gleichen Fehler zweimal.
Andererseits hat dieses heutzutage fast durchweg kostenlose und mittlerweile bestens funktionierende Linux noch immer die Chance, auch den momentanen Windows-Privatnutzer-Desktopmarkt in wirtschaftlicher Hinsicht - langfristig gesehen - komplett zu zerstören.
Dazu fehlt nur ein bisschen Aufklärung: Was kostet eine Windows-OEM-Lizenz aus Endanwenderansicht gemeinhin, wenn man sich z.B. einen Quadcore-PC für 310 Euro kauft? Knapp 90 Euro kostet dieses vorinstallierte Etwas. Wenn diese Windowspreise beim Rechnerkauf ausgewiesen sein müssten, würden viele Anwender endlich aufwachen und mit Windows ginge es steil bergab. Eine solche Art versteckter Einpreisung mag niemand. Da hat jemand Angst, "seinen" wahren Preis zu nennen. Man sollte ihn dazu zwingen.
Ich brauche keine Ahnung von Aerodynamik und Flugzeugbau zu haben. Trotzdem erwarte ich, dass ich nicht abstürze mit einem Flugzeug, und die Botschaft "Du stürzt nur einmal ab" ist kein Trost.
Sprich, ein Desktopoberfläche, die häufiger abstürzt, ist für den Anwender schlichtweg unbrauchbar. An welchen Ursachen das liegt auf Entwicklerseite ist mir eigentlich vollkommen egal. Es wäre ja schon viel geholfen das bestehende Problem nicht abzustreiten, und dann sich dieser Herausforderung anzunehmen.
... und ich dachte kde4 wäre seid "jahren" (kde4.4) stabil ...
jedesmal wenn man etwas andere behauptet hat wurde bzw wird man dafuer hier zerrissen.
aber jetzt ist kde bestimmt ganz stabil
So gesehen ist keine Software stabil. Weder Windows noch MacOS noch Gnome, Xfce, .... von den Anwendungen ganz zu schweigen. Denn schließlich bekommen all diese Betriebssysteme, Desktop-Oberflächen und Anwendungen updates, wobei Fehler behoben werden.
>> So wurde der Datenverwaltungsdienst unter anderem von diversen Abstürzen befreit.
>> Zahlreiche weitere Änderungen flossen auch in den Editor Kate ein, der unter anderem beim Schließen der gesplitteten Ansicht nicht mehr abstürzt
>> Ferner haben die Entwickler Kwin von diversen Fehlern befreit und diverse Abstürze in Nepomuk eliminiert.
... und ich dachte kde4 wäre seid "jahren" (kde4.4) stabil ...
jedesmal wenn man etwas andere behauptet hat wurde bzw wird man dafuer hier zerrissen.
aber jetzt ist kde bestimmt ganz stabil
Man unterscheidet halt, ob es bei der normalen Verwendung abstürzt, oder weil man etwas macht, was man nicht machen sollte (oder etwas was man nicht oft macht=
JuK stürzt bei mir z.B. ab, wenn man im System einen Ordner löscht, welcher von JuK verwaltet wird (und vorher nicht aus JuK entfernt wurde). Sollte zwar nicht vorkommen, aber wie oft tut man das (bzw. kann man darüber streiten, ob man es überhaupt so machen soll)
>> Man unterscheidet halt, ob es bei der normalen Verwendung abstürzt, oder weil man etwas macht, was man nicht machen sollte (oder etwas was man nicht oft macht=
Aha ... ich sehe das eher so das alle möglichen Optionen des Desktops einwandfrei laufen sollten.
zb schliessen von gesplitteten Ansichten in Kate, oder das intensive Verwenden von Nepomuk.
Auch sehe ich absolut nichts verwerfliches daran IMAP einzusetzen, IMAP-Ordner anzulegen, zu löschen Emails in diversen Ordnern hin&Herzuschieben usw... -. und einen haufen Filteroptionen anzulegen.
>> JuK stürzt bei mir z.B. ab, wenn man im System einen Ordner löscht, welcher von JuK verwaltet wird (und vorher nicht aus JuK entfernt wurde). Sollte zwar nicht vorkommen, aber wie oft tut man das (bzw. kann man darüber streiten, ob man es überhaupt so machen soll)
Robuste Programme sollten Abstütze möglichst vermeiden - das ist jetzt aber nichts grundlegend neues in der Desktop-Entwicklung.
Ja sie sollten nicht abstürzen. Nichtsdestotrotz kann man als Mensch nicht jeden Fehler im Vorfeld ausschließen. Außerdem wird man auf die meisten Probleme erst dann aufmerksam, wenn ein Absturz stattfindet und die Probleme werden wirklich schnell behoben.
Stabilität ist stark abhängig von der Komplexität, und die ist bei KDE SC (einer Sammlung von Programmen für alles Mögliche) extrem hoch.
Man kann's auch nicht wie ein statisches Objekt sehen, Software (und die Systeme auf denen sie laufen) sind ständig in Bewegung, Use-cases, und natürlich die Software selber, die weiterentwickelt wird, Performanceupdates erhält, Bugfixes, und neue Funktionen.
Dabei schleichen sich Bugs ein, das ist ein natürlicher Prozess. Es ist komplett sinnvoll die Anwesendheit von Bugs zu akzeptieren, und sich hinzusetzen, diese zu fixen, nicht einmal, sondern immer wieder.
Wenn man sich exemplarisch einen Bug wie den Crasher in Kate's Splitview genauer anschaut, wird dies besonders deutlich: Der Fehler wurde zusammen mit einem neuen Feature (der Code Minimap Scrollbar) eingeführt, den Bug gab's beim vorigen Release noch gar nicht, da diese Funktion erst Anfang Februar mit KDE SC 4.10 dazugekommen ist. Er wurde am 18. Februar von einem Benutzer gemeldet, am 19. Februar wurde er in der stable Branch gefixed, dieser Fix ist mit dem aktuellen Release den Benutzern bereitgestellt worden. Das ist ein gut funktionierender Entwicklungsprozess.
Für den Benutzer ist es wesentlich wichtiger, schnelle Respons auf Fehlerberichte zu bekommen, als Software deren Entwickler Bugs ignorieren, oder sie sogar abstreiten, oder Software die nie das Licht der Welt erblickt, weil die Entwickler perfektionistisch sind. Perfect is the enemy of good.
Manchen kann man es eben nie recht machen.
Da kommt ein .0-Release raus, und sie schreien "Lauter Abstürze!" (ich war übrigens von keinem einzigen der aufgeführten betroffen...), einen Monat später kommt das .1-Release mit Behebung der Fehler, und statt Danke kommt höchstens etwas wie "hätte nie passieren sollen".
Ich freue mich auf 4.10.1 und hoffe, dass es heute noch in Chakra Desktop landet.
Und ein Danke an die Entwickler!
Die Frage ist doch gar nicht, warum und wieso. Die Frage ist doch, was man tun kann, damit es besser wird.
Dass KDE lange Zeit die Stabilitätsanforderungen auch hartgesottener Fans nicht bedienen konnte, ist mittlerweile bekannt.
- Du hast keine Ahnung von Rechtschreibung
- Du hast keine Ahnung von Entwicklung
.. Wieso sollte ich als Anwender Ahnung von Entwicklungsprozessen haben muessen?!
Ich kann nur sagen das Windows, Textpad, Outlook, MS-Office bei mir trotz intensivem Einsatz (privat wie kommerziell) in den letzten 10jahren im Desktopbereich nicht ansatzweise so viele crashs verursacht haben wie kde+kate+kmail+koffice. MacOS10 ist nach ersten Tests auch deutlich stabiler.
Als Anwender muss man natürlich keine Ahnung vom Entwicklungsprozess haben. Aber es gibt auch so eine alte Redewendung in etwa "Wenn man von etwas keine Ahnung hat, sollte man besser die Klappe halten".
Der erste Kommentar in dem Thread hier, klingt halt wie ein typischer Trollpost oder wie ein Kommentar von jemandem, der nicht versteht wie Softwareentwicklung funktioniert und dass es immer Softwarefehler gibt.
Da aber hier (und anderswo) kritisiert wird, dass wir Fehler beheben, wäre es für uns viel einfacher keine Bugfix Releases mehr zu machen. Mir ist das ja egal, ich hab master und damit sofort die neuesten Fehlerbehebungen. Spart uns viel Zeit. Dann können wir aber auch nicht Regressionen in Treibern umgehen, wie in 4.10.1 geschehen um auf ein Problem in Mesa 9.1, welches nach 4.10.0 veröffentlicht wurde, zu reagieren.
>> und dass es immer Softwarefehler gibt.
Leider scheinen diese im freien OpenSource-Bereich im Desktop-Betrieb häufiger vorzukommen als im kommerziellen Bereich.
>> Da aber hier (und anderswo) kritisiert wird, dass wir Fehler beheben, wäre es für uns viel einfacher keine Bugfix Releases mehr zu machen.
Fehlerbehebungen werden nicht kritisiert - sondern das solche Fehler in einem stabilen Release überhaupt in der Form vorkommen.
Längere Testphasen könnten das Problem imho reduzieren. Ein anderer Mechanismus der Fehlerbehebung bzw der Patch-Verteilung könnte imho auch dafür sorgen das Bugfixes deutlich schneller beim Endanwender ankommen.
Warum kann ich als Anwender nicht zwischen verschiedenen Applikationsversionen frei wählen? zb "foobar 2.6.10, 2.6.11 oder 2.8.20", und wenn die app-version mir nicht mehr passt wieder zurück nach "foobar 2.2.10"? Dann könnte ich eine schlecht funktionierende App einfach via Mausklick gegen eine ältere Version austauschen. MacOS hat dies auf einem Unix-System imho sehr vorbildlich gelöst. Auch ist hier die Gesamtstabilität des Desktops imho deutlich besser als unter KDE.
De Frage ist natürlich, wieso es keine Testinfrastruktur geben kann, die das von vornherein ausschließt. Sicherlich hilft auch crossplattform, weil man dann die tollen Entwicklungs-Tools anderer Systeme auch nutzen kann.
Ich glaube, dass KDE auf dem richtigen Weg ist.
>> Debian stable, RHES oder SLED.
Bei DebianStable hatte ich auch schon repoduzierbare Crashes (Debian 4.0 > "u.a." kaffeine, beim Abspielen von ogg-Audiofiles beim vor/zurückspulen).
Dazu kommt insbesondere das SLED leider in den Versionen die ich getestet hatte die Multimediatauglichkeit eher eingeschränkt war. SuSE propagiert hier auch kommerzielle Software zum absielen von nicht 100% freien codecs. Da mir die Programme nicht gefallen muss ich dann praktisch quellen von Drittanbietern (Packman) hinzufügen - das ist dann unschön. Auch sind diverse Desktop-Applikationen schon "spürbar" veraltet.
Aber im Grunde finde ich den Weg von SLED schon sehr gut.
Ich würde "gerne" im Jahr 250EUR bezahlen wenn ich dafür einen "langzeitstabilen, langzeitzuverlässigen" Desktop mit guter Multimedia-Fähigkeiten, "aktuellen" Applikationen sowie guter kommerzieller Applikations-Unterstützung (vmware & co) erhalten könnte.
Und das mein ich nicht als Trollerei - sondern als wirklichen Wunsch.
>> Frag besser den Distributor deines Vertrauens
Die brauch ich nicht zu fragen.... die finden ihre Paketsysteme hervorragend. Auch hier wird man für solche Wünsche regelmäßig zerrissen.
>> Ich bin immer enttäuscht, wenn wir einen Bugreport nach dem Release bekommen.
Wo gibt es zu "RC"-Zeit eine aktuelle GNU/Linux-Version per ISO-CD zum Download welche ich via VMware oder Co booten kann, um die aktuelle KDE-RC Version ausführlich testen zu können?
Wo gibt es die Hilfstools - mit denen ich ohne Aufwand, ohne Registration, ohne Suche ob es den Bug schon gibt Fehler melden kann?
Warum testen Entwickler ihre Software nicht selbst?
Gerade in der frühen KDE4-Phase (Kde4.1-4.4) sind etliche Bugs/Ungereimtheiten oder Usability-Unschömnheiten einem massiv entgegen gesprungen - da hätte es keinen Test benötigt um das zu sehen.
Meine Freizeit ist Berufsbedingt eingeschraenkt. Da möchte ich keine grossen Ressourcen mit Bugsuchen und Co verschwenden, sondern schnell unkompliziert den Fehler melden - fertig.
Wie gesagt - ich bin gerne bereit Geld auszugeben - so wie ich das heute bei der konkurrenz tue, und von 1998-2004 schon bei SuSE tat.
"Wie gesagt - ich bin gerne bereit Geld auszugeben - so wie ich das heute bei der konkurrenz tue, und von 1998-2004 schon bei SuSE tat."
Dafür ist es im Linuxbereich zu spät. Sowohl Suse wie auch Red Hat werden keine kommerziellen Privatanwenderdistributionen mehr anbieten. Wenn man der Pleite ins Auge gesehen hat, macht man nur sehr selten den gleichen Fehler zweimal.
Andererseits hat dieses heutzutage fast durchweg kostenlose und mittlerweile bestens funktionierende Linux noch immer die Chance, auch den momentanen Windows-Privatnutzer-Desktopmarkt in wirtschaftlicher Hinsicht - langfristig gesehen - komplett zu zerstören.
Dazu fehlt nur ein bisschen Aufklärung:
Was kostet eine Windows-OEM-Lizenz aus Endanwenderansicht gemeinhin, wenn man sich z.B. einen Quadcore-PC für 310 Euro kauft? Knapp 90 Euro kostet dieses vorinstallierte Etwas. Wenn diese Windowspreise beim Rechnerkauf ausgewiesen sein müssten, würden viele Anwender endlich aufwachen und mit Windows ginge es steil bergab. Eine solche Art versteckter Einpreisung mag niemand. Da hat jemand Angst, "seinen" wahren Preis zu nennen. Man sollte ihn dazu zwingen.
Ich brauche keine Ahnung von Aerodynamik und Flugzeugbau zu haben. Trotzdem erwarte ich, dass ich nicht abstürze mit einem Flugzeug, und die Botschaft "Du stürzt nur einmal ab" ist kein Trost.
Sprich, ein Desktopoberfläche, die häufiger abstürzt, ist für den Anwender schlichtweg unbrauchbar. An welchen Ursachen das liegt auf Entwicklerseite ist mir eigentlich vollkommen egal. Es wäre ja schon viel geholfen das bestehende Problem nicht abzustreiten, und dann sich dieser Herausforderung anzunehmen.
So gesehen ist keine Software stabil. Weder Windows noch MacOS noch Gnome, Xfce, .... von den Anwendungen ganz zu schweigen. Denn schließlich bekommen all diese Betriebssysteme, Desktop-Oberflächen und Anwendungen updates, wobei Fehler behoben werden.
Deine Argumentation kannst du also vergessen.