Mathias Bauer schrieb: > Nur, weil es in der c't steht, muss es noch nicht stimmen. :-)
stimmt, das muß es _deswegen allein_ nicht > Natürlich kann es passieren, dass Extensions nicht mehr funktionieren > oder sich nicht mehr entfernen lassen, weil > > - Anwender händisch in den Verzeichnissen herumfummeln, weil sie mal > irgendwo gelesen haben, dass man das tun soll > > - installierte Extensions sehr buggy sind > > - ... (mir fallen momentan keine weiteren Gründe ein) > > Aber selbst dann klappt es *immer*, alle Extensions zu > entfernen, indem > man den Inhalt des uno_packages Folders löscht. Meine Behauptung, jede > Extension könne rückstandsfrei entfernt werden, ist also korrekt. Nein, das ist sie m.E. nicht, denn sie war: "Die Extension-Methode ist besser, weil man Extensions einfach rückstandslos wieder entfernen kann. Das Hineinkopieren oder gar Überschreiben von xcu-Dateien erlaubt das nicht so ohne weiteres." Es ging also NICHT (nur) darum ob eine Extension irgendwie rückstandslos entfernt werden könnte, sondern um die Behauptung das die 'Extension-Methode' besser sei weil dort das Entfernen rückstandlos und einfach möglich sei. Sofern Du aber jetzt anführst das sich natürlich eine Extension (notfalls) manuell rückstandslos entfernen lässt ist das zwar so, aber kein Vorteil mehr der für Extensions spräche, denn manuell kann man (das nötige Wissen vorausgesetzt) alles rückstandslos entfernen, egal ob per Extension reingebracht oder anders. > Wenn > vorher durch Herumfummeln am uno_packages folder (sei es > durch Anwender > oder durch Code von Extensions oder anderen Tools) dieser in einem > invaliden Zustand ist, muss man ihn dafür halt ganz entfernen. Das > sollte man dann aber sowieso tun und die Extensions neu installieren. Es gibt immer wieder Rückmeldungen von Nutzern die über Probleme reden obwohl sie weder am uno_packages Ordner, noch sonstwo manuell herumgefummelt haben. Ganz egal in welchen Zustand der package-Ordner auch kommt, sollte ein robust programmiertes Programm mit entstehenden Problemen umgehen können und nicht den Nutzer im Regen stehen lassen. Du, ich und etliche Andere werden kein Problem haben notfalls auch manuell einzugreifen, nur Normalnutzer haben damit ein handfestes Problem und eine Software der es nicht gelingt solche Probleme abzufangen hat dann an der Stelle leider auch ein Problem(*). Davon spricht sinngemäß auch die C't und wenn Du den gesamten Artikel liest wird das noch klarer als aus meinem kurzen Zitat, denn die C't benennt teils auch Ursachen, *beispielsweise* die teils schlechte Situation bei der Dokumentation die dazu führt das schlechte/fehlerhafte Extensions entstehen. Auch hier kann man nach Belieben die SChuld auf andere schieben, man kann aber auch anerkennen das eine hinreichend gute Doku genauso essentiell ist wie ein fehlerfreies Programm, man sollte das selbst dann anerkennen können wenn man leider gleichzeitig feststellen muß das die verfügbaren Kräfte derzeitig möglicherweise nicht ausreichen um eine solche Doku zu erstellen. (*) Anmerkung: ich programmiere im Übrigen teils auch beruflich und ich bin mir der Problematik bewußt das es nervig sein kann in Fällen wo in 1:1000 ein Fehler auftritt, der dann leicht in 30 Sekunden manuell beseitigt werden kann, stundenlang zu programmieren, um robuste Fehlerroutinen zu schreiben. Die Wahrheit ist jedoch das das meine ureigenste Aufgabe ist wenn ich programmiere, nämlich alle 'Hintergrund-Probleme' vom Endnutzer fern zu halten und mögliche Fehler abzufangen, denn der Endbenutzer will berechtigterweise(!) eine Software die robust funktioniert und keine Diskussion wer an (Software-)Fehlern schuld ist. Wenn jemand z.B. seine Katze auf der Tastatur spazieren gehen lässt, ist das ganz sicher keine bestimmungsgemäße Nutzung - weder der Katze noch der Tastatur :-) - nur ein gut programmiertes, robustes Programm darf selbst in solchen Fällen nicht einfach die weiße Fahne schwenken nach dem Motto das ja ohnehin die Katze Schuld sei. Gruß Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
