Diskussion:Programmfehler/Archiv/2006

aus Wikipedia, der freien Enzyklopädie
Letzter Kommentar: vor 16 Jahren von Bodo Thiesen in Abschnitt Bugs im Englischen
Zur Navigation springen Zur Suche springen

Bugs im Englischen

Hallo, liebe Leute. Mit Bug kann zwar auch mal ein Käfer gemeint sein. In der Regel gibt es aber zwei Worte für Käfer: Beetle und Chafer, die eher das audrücken, an was Deutsche beim Wort Käfer denken. Bug heisst auf Deutsch zunächst mal: Wanze und nicht Käfer(z.b. Bedbug= Bettwanze). Ja, da sind wir bei den weniger erfreulichen Krabeltieren. Genau das ist die erweiterte Bedeutung von Bug: Ungeziefer, Insekten, Schaben - Krabelzeugs. Ein Käfer ist natürlich auch ein Insekt nur: Wer denkt bei Käfer schon an Motten oder Schaben? Spätestens, wenn die Herkunft des Begriffes "Bug" über "Motte" versucht wird zu erklären, führt diese typisch deutsche Falschübersetzung von Bug als Käfer zur Verwirrung. Bug ist nicht Käfer sondern alles, was das Skelett aussen hat und mit Kammerjäger in Werbindung gebracht wird: Ungeziefer. --[[Benutzer:84.56.14.8|84.56.14.8] 08:15, 17. Sep. 2006 (nachträglich signiert von Bodo Thiesen)

Mag zwar stimmen, aber unter einer Wanze verstehe ich, wenn es nicht ums Tierreich geht, eine Abhörvorrichtung. Mag zwar jetzt nur ein schwaches Argument sein, aber Bug heißt nun mal (auch) Käfer. Schlußendlich wird das deutsche Wort sowieso nicht benutzt, entweder findet man einen Bug oder einen Fehler, ich habe noch nie eine Wanze oder einen Käfer in einem Programm gefundne ;) --Bodo Thiesen 04:06, 11. Mär. 2008 (CET)

Ariane 5

Soweit ich weiß, hat man bei der Ariane-5 das bewährte Steuerungssystem der Ariane-4 verwendet. Der Prozessor war aber für die erhöhten Anforderungen der Ariane-5 zu langsam. Die Rakete kam dadurch so weit vom Kurs ab, dass sie gesprengt werden musste. Wenn das stimmt, wäre das kein Softwarefehler.

Meines Wissens (übrigens auch nachzulessen in "Objektorientiertes Testen" von Uwe Vigenschow) kam es bei der Ariane 4 zu einem Integer Overflow. Genau 30 Sekunden nach dem Abheben erreichte die Ariane 5 ein Horizontalgeschwindigkeit von 32768 internen Einheiten des Sensors. Dieser Wert lage etwas fünfmal höher als beim Vorgängermodell Ariane 4, bedingt duch die höhere Schubkraft. Der redundant ausgelegte Reserverechner hatte das gleiche Problem bereits 72ms vorher und schaltete sich ab. Also doch ein sehr gutes Beispiel für einen Softwarefehler. --Gudi 10:59, 21. Jul 2006 (CEST)
Nein, sowas kann halt passieren, wenn man Software zweckentfremdet. Die Software selber hat ihren Zweck im davor vorgesehenen System einwandfrei erfüllt - sie war für die Ariane 4 geschrieben und arbeitete dort wie vorgesehen. Das man sie unverändert (und scheinbar auch ungeprüft) in das Nachfolgemodell übernahm beweist ja, das die Ingenieure damit zufrieden waren. Ihr Fehler war, nicht nachzuprüfen, ob die alte Software kompatibel mit der neuen Hardware ist. Klarer Fall von Anwenderfehler... --213.61.162.162 16:41, 6. Jun. 2007 (CEST)

Aber wie wäre es damit: Ich habe gehört, dass ein großer Stromausfall in den USA in den 80er Jahren auf eine fehlende break-Anweisung in einem C-Programm zurückgeführt werden konnte. Weiß jemand mehr darüber?

--Juhox 20:41, 8. Sep 2003 (CEST)


Mir ist etwas unklar, warum der Beitrag nur Ada unter "siehe auch" gelistet hat. Ich persönlich würde hier anraten, auf Programmiersprachen#Besondere Ausprägungen weiter zu verweisen. -- Manny 17:01, 25. Feb 2004 (CET)

Badewannenkurve

Warum in alles in der Welt sollte sich die Anzahl der Softwarefehler eines Programmes wie eine Badewannenkurve verhalten? Sind die Programme erst einmal den Kinderschuhen entwachsen sollten sie einigermaßen stabil sein. Ein Anwachsen der Fehlerzahl nach der stabilen Phase ist - so weit ich weiß - bisher bei keinem Program beobachtet worden. Geänderte Umgebungsbedingungen, wie Prozessoren der nächsten Generation und neuere Betriebssystemversionen sollten dabei unberücksichtigt bleiben. Also, weg mit der Badenwannenkurve, Softwarefehler während der Lebensdauer eines Programmes gehen gegen einen relativ kleinen Wert (hoffentlich Null). --217.87.76.253 21:20, 6. Mai 2006 (nachträglich signiert von JonnyJD)

Bin selber Softwareingenieur und sehe das ebenso. MV --217.224.53.237 09:46, 8. Mai 2006 (CEST)
Das halte ich für totalen Quatsch. Beim Thema Badewannenkurve denkt der studierte Software Engineer auch eher an eine andere Badewannenkurve, die mit dem hier beschriebenen Fehlerverhalten nicht besonders viel zu tun hat. Hätte gerne auch nur ein Beispiel einer größeren Software, bei der dies der Fall sein soll. -PG 10:39, 23.11. 2007
Gründe für ein Ansteigen der Fehler in Abschnitt III:
  • Funktionsanreicherung
  • fortgeschrittenes Herumfutzeln beim Beseitigen von Bugs
  • die Software ist technisch überholt oder muss neuen Anwendungsgebieten standhalten (die beim Design nicht vorgesehen waren)
Sowas in der Art führt dazu, dass auch bei Software am Ende die Fehler wieder ansteigen. Man sollte das aber vielleicht auch geschickt im Artikel erklären und vielleicht auch mit einer Quelle belegen. Bin für Hilfe dankbar. --JonnyJD 02:47, 20. Apr. 2007 (CEST)
Ich habe gerade entschieden, dass ich mich um einen Artikel Softwarealterung kümmern werde. Das dauert aber noch ein bisschen. --JonnyJD 15:20, 20. Apr. 2007 (CEST)

Ich habe jetzt einen Artikel zur Softwarealterung erstellt. Warum ihr geänderte Umgebungsbedingungen unberücksichtigt lassen wollt ist mir unklar. Geänderte Vorraussetzungen sind ja gerade der Grund warum viele Sachen (auch ausserhalb der Software) "veraltet" sind. -- JonnyJD 19:08, 23. Sep. 2007 (CEST)