Von Überlagerte Schriften am Mi, 25. Juli 2012 um 20:41 #
Also das gilt auch für KOffice bzw. Calligra. Seit Jahren teste ich immer mal wieder KWord und KSpread bzw. Words und Sheets. Ich brauche es nur aufzurufen und nach spätestens ein paar harmlosen Klicks stürzt das Programm ab. Verstehe absolut nicht, wie da getestet wird. Die sind bald bei Version 2.5 und die Software macht nur solche Zicken. Da macht auch das Erstellen von Bug-Reports nach so langer Zeit keinen Spaß mehr. Rekonq ist für Webseiten da. Man braucht doch nur mal ein paar Seiten aufzurufen und müsste sofort merken, dass da was nicht stimmt.
Von Überlagerte Schriften am Mi, 25. Juli 2012 um 21:43 #
Naja, was heisst, sind noch nicht so weit. Ein bischen Text, einen Frame, mal die Text-Attribute geändert und schon kracht es bei KWord. Hat doch nichts mit Entwicklermangel zu tun. Wenn die absoluten Basics einer Textverarbeitung oder eines Browsers nicht funzen, dann braucht man doch nicht schon vorher x andere Features zu implementieren. Das sind die Basics. Die Entwickler müssten das doch eigentlich selbst merken. Da muss man die Software nicht erst einem groß angelegten Test unterziehen, damit solche Fehler auffallen.
Schon mal bei den Entwicklern nachgefragt? Wenn irgendwelche total grundlegenden Sachen nicht laufen, ist das meist nicht bekannt oder tritt bei ihnen gar nicht auf. Bug reportet? Oft zickt auch die neuste Qt Version z.B. schmiert mit Ubuntu 12.04 die Texteingabe ab, dass war mit der alten Version noch nicht so.
Von Überlagerte Schriften am Do, 26. Juli 2012 um 00:08 #
Wie kann denn der Endanwender feststellen, ob ein Fehler in einer Software, wie z.B. Browser oder Textverarbeitung, an einem Framwork wie Qt, einer Lib, dem Kernel oder eben an der entsprechenden Software selbst liegt? Also den Entwicklern sollte es schon bekannt sein, wenn grundlegende Dinge in einer Version 1.0 oder 2.5 nicht oder nur sehr schlecht funktionieren, wie z.B. eine Textformatierung oder die Anzeige einer einfachen Schrift. Wir sprechen hier ja nicht von Fehlern, die vorher nicht vorhanden waren oder die sich irgendwann mal eingeschlichen haben, sondern von Fehlern die von Beginn an existent waren. Die Entwickler sollten doch mal ihre Software selbst benutzen. Ich vestehe es einfach nicht. Wenn ich die Programme nur 3 Minuten benutze, fallen mir sofort sehr gravierende Fehler auf. Das müsste den Entwicklern doch auch so gehen oder haben die Tomaten auf den Augen. Wenn ich als Entwickler in Qt eine Textverarbeitung entwickeln würde und würde feststellen, dass die Ursache eines bekannten Fehlers nicht in meiner Software selbst liegt, sondern in dem von mir verwendeten Framework, dann müsste ich mich doch als Entwickler mit den Entwicklern des entsprechenden Frameworks auseinander setzen. Nur so kommt man doch zum Ziel, d.h. einer benutzbaren Software. Was nützt es denn, wenn man sich die Fehler nur gegenseitig in die Schuhe schiebt und die Software deswegen nie benutzbar wird.
Die einzige Möglichkeit für den Endanwender ist, die Entwickler zu fragen.
Das hängt auch stark von der Art und Weise ab wie Linux-Software entwickelt wird. Im Gegensatz zu anderen Plattformen wird die komplette Software dynamisch gelinkt. Distributionen können nach Lust und Laune Bibliotheken austauschen. Der Entwickler testet gegen seine Version der Bibliothek und die Distribution liefert dann eine andere Version aus die eventuell kaputt ist.
Wenn so ein Fehler gefunden wird, muss der erst mal bei den Entwicklern der Bibliothek gemeldet werden. Wo er dann von einem Entwickler behoben wird und einen verbesserte Version veröffentlicht wird. LibreOffice hat da den Vorteil, dass sie einen riesigen Klotz veröffentlichen wo alles drin ist.
Abgesehen davon können bei jedem Benutzer andere Bugs auftreten. Das ein Bug offensichtlich ist heißt noch lange nicht das er überall auftritt. Der Entwickler hat wahrscheinlich einen andere Umgebung und benutzt die Software andere z.B. surfen die Rekonq-Entwickler oder die qtwebkit-Entwicker wohl nicht auf golem.de.
Ich hab hier z.B. einen Fehler im Firefox 14.0.1 der der Links in der Wikipedia z.T. nicht anzeigt werden. Der Fehler ist nicht zu übersehen hier. Wessen Schuld ist das dann? Der Fehler könnte praktisch überall liegen.
Wenn die Software so instabil ist, sieht es wohl so aus, als ob es nicht genügend aktive Entwickler für dieses Projekt gibt. Mal so ne Hypothese. Aber sicher ist, wenn Du jedesmal, wenn Du einen Fehler gefunden hättest einen bugreport geschickt hättest, sie auf jeden Fall schon weiter wären. Finde es schade, das die Bemühungen von Leuten in Gemeinschafts-Projekten mit einem Einkaufsladen, einer Firma o. ä. verwechselt werden.
Von Überlagerte Schriften am Do, 26. Juli 2012 um 11:39 #
Zuerst mal, bitte nicht immer die Leier mit den Bug-Reports. Die sind da und auch von mir. Sowas kommt jedesmal bei Kritik. Desweiteren verwechsele ich das nicht mit einem Einkaufladen. Das ist Blödsinn. Aber mal ehrlich. Wozu wird so eine Software entwickelt? Damit andere Personen diese Software nutzen. Und ganz oft auch für die Entwickler selbst. Da ist es doch in Ordnung, wenn man auch mal Dinge anspricht. Und hier geht es doch wirklich um Basics, die seit Jahren nicht behoben werden. Was bringt dann Funktion XYZ wenn eben diese Basics nichtmal funktionieren. Selbst bei sanfter Kritik wird man dann gleich in den Boden gestampft oder als Klugscheißer betitelt. Das geht garnicht. Und nochmal zu den Bug-Reports. Du kannst schon zwischen einem Tester und einem User unterscheiden? Der normale User könnte, selbst wenn er wollte, nicht jedesmal zu jedem Fehler einen Bug-Report schreiben. Dann hätte er nichts anderes mehr zu tun.
Es gibt praktisch keine Unterscheidung zwischen User und Tester bei Open Source Software. Einen Bug-Report zu machen dauert vielleicht fünf Minuten. Warum sollte sich ein unbezahlter Entwickler um ihren Bug kümmern, wenn sie es nicht mal für nötig halten einen Report zu machen? Auch Entwickler haben besseres zu tun und einen Bug zu beheben kostet zig mal soviel Zeit wie das Schreiben des reports.
Wozu soll man einen offensichtlichen Bugs bei grundlegeneden Programmfunktionen die jeder bei Benutzung selbst sieht nochmals beschreiben?
Ein Software-Entwickler hat das nötige KnowHow, sowie die besten Fähigkeiten selbst einen "ordentlichen" Test durchzuführen. Ein Entwickler der sein Projekt mit Herzblut betreibt, sollte sein eigenes Projekt auch ausführlich testen. Dank Virtualisierung stellt das selbst auf verschiedenen Plattformen keinen ernsten Aufwand dar. Und wenn die Distributionen der Grund sein sollen das diverse KDE-Projekte Jahrelang beim Enduser verbuggt sind, sollten sich die Entwickler vuielleicht mal überlegen ob das grundlegene Entwicklungsmodell wirklich optimal ist....
Bei den hier beschriebenen Problemen geht es auch garnicht um irgentwelche selten auftretenden Effekte... sondern um Grundbasics die sofort auffallen müssen.
>> Auch Entwickler haben besseres zu tun und einen Bug zu beheben kostet zig mal soviel Zeit wie das Schreiben des reports. Auch Anwender haben besseres zutun, als sich jahrelang mit fehlerhaften Systemen rumzuschlagen !
Wartet ab bis der Umschwung auf QT5 bevor steht... dann geht der ganze Spass mit den Grundbasics bei der Desktoparbeit wieder von vorne los... und schuld sind dann wieder wie immer alle andern (Graikkarten, Treiber, xorg, Distributoren, oder oder oder)
Da geh ich doch lieber in den Laden kauf mir kommerzielle Software im Wert von 300 EUR und verwende für alles weitere Freeware, das funktioniert dann wenigstens OutOfBox. 30h Arbeit + jährlich 12h Installationszeit - und ich habe fuer 8 Jahre ruhe vor Problemen !
"Da geh ich doch lieber in den Laden kauf mir kommerzielle Software im Wert von 300 EUR und verwende für alles weitere Freeware, das funktioniert dann wenigstens OutOfBox. 30h Arbeit + jährlich 12h Installationszeit - und ich habe fuer 8 Jahre ruhe vor Problemen !"
Ich finde das kurios. Vor allem, weil Du immer noch hier postest. Also von wegen "Ruhe vor Problemen".
Benutzt Du noch das bald schon tote Win XP? Die Uhr tickt, der Totengräber freut sich schon. Sattelst Du noch auf Win7 um, bevor dieses Metrozeugs zum Standard wird? Oder wird RHEL 6 doch noch eine Alternative? :-) Fragen über Fragen ...
>> Benutzt Du noch das bald schon tote Win XP? >> Die Uhr tickt, der Totengräber freut sich schon. >> Oder wird RHEL 6 doch noch eine Alternative?
Stimmt, in ca. 1,5Jahren endet der Support. Damit wurde das OS fuer 120EUR 13Jahre supportet.
Könntest Du mir eine GNU/Linux-Distro nennen die vor über 8Jahren released wurde, bis heute mit Patches versorgt wird, und gleichzeitig es möglich ist per Mausklick moderne Applikationen wie zb. Kdevelop4.x, LibreOffice3.5, Pidgin2.10, Firefox14.x inkl Flash11.3.x usw zu installieren? Vergleichbare Windows-Applikationen laufen auch in aktueller Version noch unter WindowsXP. Dazu bitte ich um eine "stabile" "Desktop-Umgebung" die nicht alle 90min crasht nur weil ich 1 HD-Video laufen lasse, per Dosbox ein Game spiele, und gleichzeitig flash-Videos in der Virtuellen Maschiene laufen lasse. Stabilität bedeutet fürmich das so etwas "ohne" jedwede Probleme möglich sein sollte - auch wenn ich dann im Host noch zusätzlich einen Userwechsel durchführe, und eine weitere virtuelle Maschine beim 2.User laufen lasse. Unter Windows ist so etwas inzwischen seit ca. 10Jahren möglich - 30Tage lang im 24h Dauerbetrieb ohne Neustart. Desweiteren bitte ich darum das Maus-Scrollrad Systemweit auf 12Zeilen pro Raddrehung (Einrastung) Einstellen zu können.
Für so ein System wär ich gern bereit 250EUR einmalig zu bezahlen.
Im übrigen sind Distros von Hausaus lächerlich wenn sie nach 3 Tagen unter o.b. Last dann beim Umschalten zum Bildschirmschoner (=Displayschutz), beim Reactivieren bei falschen Passwörtern für Sekunden den Screen anzeigen ! Das habe ioch bei unterschiedlichen Distros sowohl unter KDE als auch unter Gnome erlebt. Reproduzierbar? Nein !
Auch sehr nervtötend - mit gefühlt jedem neuen Kernel-Patch kann ich mich um ein recompilieren der VMware-Kernelmodule kümmern. Unter Windows (Version 5.x) hat es solche Probleme soweit ich zurückdenken kann nicht gegeben.
Also das gilt auch für KOffice bzw. Calligra. Seit Jahren teste ich immer mal wieder KWord und KSpread bzw. Words und Sheets. Ich brauche es nur aufzurufen und nach spätestens ein paar harmlosen Klicks stürzt das Programm ab. Verstehe absolut nicht, wie da getestet wird. Die sind bald bei Version 2.5 und die Software macht nur solche Zicken. Da macht auch das Erstellen von Bug-Reports nach so langer Zeit keinen Spaß mehr.
Rekonq ist für Webseiten da. Man braucht doch nur mal ein paar Seiten aufzurufen und müsste sofort merken, dass da was nicht stimmt.
Mein Reden:
http://www.pro-linux.de/news/1/14584/comm/419731/koffice-enttaeuscht.html
Schau mal von wann der Post ist...
An der Situation hat sich bis heute nichts geändert, und wird sich auch in Zukunft nichts ändern.
Krita funktioniert super. Die anderen Programme sind noch nicht soweit, liegt allerdings wohl eher an Entwicklermangel.
Naja, was heisst, sind noch nicht so weit. Ein bischen Text, einen Frame, mal die Text-Attribute geändert und schon kracht es bei KWord. Hat doch nichts mit Entwicklermangel zu tun. Wenn die absoluten Basics einer Textverarbeitung oder eines Browsers nicht funzen, dann braucht man doch nicht schon vorher x andere Features zu implementieren. Das sind die Basics. Die Entwickler müssten das doch eigentlich selbst merken. Da muss man die Software nicht erst einem groß angelegten Test unterziehen, damit solche Fehler auffallen.
Schon mal bei den Entwicklern nachgefragt? Wenn irgendwelche total grundlegenden Sachen nicht laufen, ist das meist nicht bekannt oder tritt bei ihnen gar nicht auf. Bug reportet? Oft zickt auch die neuste Qt Version z.B. schmiert mit Ubuntu 12.04 die Texteingabe ab, dass war mit der alten Version noch nicht so.
Wie kann denn der Endanwender feststellen, ob ein Fehler in einer Software, wie z.B. Browser oder Textverarbeitung, an einem Framwork wie Qt, einer Lib, dem Kernel oder eben an der entsprechenden Software selbst liegt?
Also den Entwicklern sollte es schon bekannt sein, wenn grundlegende Dinge in einer Version 1.0 oder 2.5 nicht oder nur sehr schlecht funktionieren, wie z.B. eine Textformatierung oder die Anzeige einer einfachen Schrift. Wir sprechen hier ja nicht von Fehlern, die vorher nicht vorhanden waren oder die sich irgendwann mal eingeschlichen haben, sondern von Fehlern die von Beginn an existent waren. Die Entwickler sollten doch mal ihre Software selbst benutzen. Ich vestehe es einfach nicht. Wenn ich die Programme nur 3 Minuten benutze, fallen mir sofort sehr gravierende Fehler auf. Das müsste den Entwicklern doch auch so gehen oder haben die Tomaten auf den Augen. Wenn ich als Entwickler in Qt eine Textverarbeitung entwickeln würde und würde feststellen, dass die Ursache eines bekannten Fehlers nicht in meiner Software selbst liegt, sondern in dem von mir verwendeten Framework, dann müsste ich mich doch als Entwickler mit den Entwicklern des entsprechenden Frameworks auseinander setzen. Nur so kommt man doch zum Ziel, d.h. einer benutzbaren Software. Was nützt es denn, wenn man sich die Fehler nur gegenseitig in die Schuhe schiebt und die Software deswegen nie benutzbar wird.
sieh an... der Klugscheißer vom Dienst...
Naja, Leute wie Du schreiben so einen Scheiß. Dann lass es lieber gleich oder trag etwas vernünftiges dazu bei.
Die einzige Möglichkeit für den Endanwender ist, die Entwickler zu fragen.
Das hängt auch stark von der Art und Weise ab wie Linux-Software entwickelt wird. Im Gegensatz zu anderen Plattformen wird die komplette Software dynamisch gelinkt. Distributionen können nach Lust und Laune Bibliotheken austauschen. Der Entwickler testet gegen seine Version der Bibliothek und die Distribution liefert dann eine andere Version aus die eventuell kaputt ist.
Wenn so ein Fehler gefunden wird, muss der erst mal bei den Entwicklern der Bibliothek gemeldet werden. Wo er dann von einem Entwickler behoben wird und einen verbesserte Version veröffentlicht wird. LibreOffice hat da den Vorteil, dass sie einen riesigen Klotz veröffentlichen wo alles drin ist.
Abgesehen davon können bei jedem Benutzer andere Bugs auftreten. Das ein Bug offensichtlich ist heißt noch lange nicht das er überall auftritt. Der Entwickler hat wahrscheinlich einen andere Umgebung und benutzt die Software andere z.B. surfen die Rekonq-Entwickler oder die qtwebkit-Entwicker wohl nicht auf golem.de.
Ich hab hier z.B. einen Fehler im Firefox 14.0.1 der der Links in der Wikipedia z.T. nicht anzeigt werden. Der Fehler ist nicht zu übersehen hier. Wessen Schuld ist das dann? Der Fehler könnte praktisch überall liegen.
Wenn die Software so instabil ist, sieht es wohl so aus, als ob es nicht genügend aktive Entwickler für dieses Projekt gibt. Mal so ne Hypothese. Aber sicher ist, wenn Du jedesmal, wenn Du einen Fehler gefunden hättest einen bugreport geschickt hättest, sie auf jeden Fall schon weiter wären. Finde es schade, das die Bemühungen von Leuten in Gemeinschafts-Projekten mit einem Einkaufsladen, einer Firma o. ä. verwechselt werden.
Zuerst mal, bitte nicht immer die Leier mit den Bug-Reports. Die sind da und auch von mir. Sowas kommt jedesmal bei Kritik. Desweiteren verwechsele ich das nicht mit einem Einkaufladen. Das ist Blödsinn. Aber mal ehrlich. Wozu wird so eine Software entwickelt? Damit andere Personen diese Software nutzen. Und ganz oft auch für die Entwickler selbst. Da ist es doch in Ordnung, wenn man auch mal Dinge anspricht. Und hier geht es doch wirklich um Basics, die seit Jahren nicht behoben werden. Was bringt dann Funktion XYZ wenn eben diese Basics nichtmal funktionieren. Selbst bei sanfter Kritik wird man dann gleich in den Boden gestampft oder als Klugscheißer betitelt. Das geht garnicht. Und nochmal zu den Bug-Reports. Du kannst schon zwischen einem Tester und einem User unterscheiden? Der normale User könnte, selbst wenn er wollte, nicht jedesmal zu jedem Fehler einen Bug-Report schreiben. Dann hätte er nichts anderes mehr zu tun.
Es gibt praktisch keine Unterscheidung zwischen User und Tester bei Open Source Software. Einen Bug-Report zu machen dauert vielleicht fünf Minuten. Warum sollte sich ein unbezahlter Entwickler um ihren Bug kümmern, wenn sie es nicht mal für nötig halten einen Report zu machen? Auch Entwickler haben besseres zu tun und einen Bug zu beheben kostet zig mal soviel Zeit wie das Schreiben des reports.
Wozu soll man einen offensichtlichen Bugs bei grundlegeneden Programmfunktionen die jeder bei Benutzung selbst sieht nochmals beschreiben?
Ein Software-Entwickler hat das nötige KnowHow, sowie die besten Fähigkeiten selbst einen "ordentlichen" Test durchzuführen. Ein Entwickler der sein Projekt mit Herzblut betreibt, sollte sein eigenes Projekt auch ausführlich testen. Dank Virtualisierung stellt das selbst auf verschiedenen Plattformen keinen ernsten Aufwand dar. Und wenn die Distributionen der Grund sein sollen das diverse KDE-Projekte Jahrelang beim Enduser verbuggt sind, sollten sich die Entwickler vuielleicht mal überlegen ob das grundlegene Entwicklungsmodell wirklich optimal ist....
Bei den hier beschriebenen Problemen geht es auch garnicht um irgentwelche selten auftretenden Effekte... sondern um Grundbasics die sofort auffallen müssen.
>> Auch Entwickler haben besseres zu tun und einen Bug zu beheben kostet zig mal soviel Zeit wie das Schreiben des reports.
Auch Anwender haben besseres zutun, als sich jahrelang mit fehlerhaften Systemen rumzuschlagen !
Wartet ab bis der Umschwung auf QT5 bevor steht... dann geht der ganze Spass mit den Grundbasics bei der Desktoparbeit wieder von vorne los... und schuld sind dann wieder wie immer alle andern (Graikkarten, Treiber, xorg, Distributoren, oder oder oder)
Da geh ich doch lieber in den Laden kauf mir kommerzielle Software im Wert von 300 EUR und verwende für alles weitere Freeware, das funktioniert dann wenigstens OutOfBox.
30h Arbeit + jährlich 12h Installationszeit - und ich habe fuer 8 Jahre ruhe vor Problemen !
"Da geh ich doch lieber in den Laden kauf mir kommerzielle Software im Wert von 300 EUR und verwende für alles weitere Freeware, das funktioniert dann wenigstens OutOfBox.
30h Arbeit + jährlich 12h Installationszeit - und ich habe fuer 8 Jahre ruhe vor Problemen !"
Ich finde das kurios.
Vor allem, weil Du immer noch hier postest.
Also von wegen "Ruhe vor Problemen".
Benutzt Du noch das bald schon tote Win XP?
Die Uhr tickt, der Totengräber freut sich schon.
Sattelst Du noch auf Win7 um, bevor dieses Metrozeugs zum Standard wird?
Oder wird RHEL 6 doch noch eine Alternative? :-)
Fragen über Fragen ...
Hallo,
>> Benutzt Du noch das bald schon tote Win XP?
>> Die Uhr tickt, der Totengräber freut sich schon.
>> Oder wird RHEL 6 doch noch eine Alternative?
Stimmt, in ca. 1,5Jahren endet der Support. Damit wurde das OS fuer 120EUR 13Jahre supportet.
Könntest Du mir eine GNU/Linux-Distro nennen die vor über 8Jahren released wurde, bis heute mit Patches versorgt wird, und gleichzeitig es möglich ist per Mausklick moderne Applikationen wie zb. Kdevelop4.x, LibreOffice3.5, Pidgin2.10, Firefox14.x inkl Flash11.3.x usw zu installieren? Vergleichbare Windows-Applikationen laufen auch in aktueller Version noch unter WindowsXP. Dazu bitte ich um eine "stabile" "Desktop-Umgebung" die nicht alle 90min crasht nur weil ich 1 HD-Video laufen lasse, per Dosbox ein Game spiele, und gleichzeitig flash-Videos in der Virtuellen Maschiene laufen lasse. Stabilität bedeutet fürmich das so etwas "ohne" jedwede Probleme möglich sein sollte - auch wenn ich dann im Host noch zusätzlich einen Userwechsel durchführe, und eine weitere virtuelle Maschine beim 2.User laufen lasse. Unter Windows ist so etwas inzwischen seit ca. 10Jahren möglich - 30Tage lang im 24h Dauerbetrieb ohne Neustart.
Desweiteren bitte ich darum das Maus-Scrollrad Systemweit auf 12Zeilen pro Raddrehung (Einrastung) Einstellen zu können.
Für so ein System wär ich gern bereit 250EUR einmalig zu bezahlen.
Im übrigen sind Distros von Hausaus lächerlich wenn sie nach 3 Tagen unter o.b. Last dann beim Umschalten zum Bildschirmschoner (=Displayschutz), beim Reactivieren bei falschen Passwörtern für Sekunden den Screen anzeigen ! Das habe ioch bei unterschiedlichen Distros sowohl unter KDE als auch unter Gnome erlebt. Reproduzierbar? Nein !
Auch sehr nervtötend - mit gefühlt jedem neuen Kernel-Patch kann ich mich um ein recompilieren der VMware-Kernelmodule kümmern. Unter Windows (Version 5.x) hat es solche Probleme soweit ich zurückdenken kann nicht gegeben.