Stabile Software: Was bedeutet das eigentlich?

[Stefan]

Hallo,

es wird so oft davon gesprochen, dass ein System oder eine Software stabil sein soll oder eben nicht. Zum Beispiel soll ja Linux "stabil" sein und es gibt sogar dort "stable" und eben "unstable" Versionen.

Aber was heisst das eigentlich? Kann ein stabiles System denn nicht zerstört werde? Hängt sich ein stabiles System nie auf? Wann ist eine Software überhaupt stabil?

Gruss Stefan

[Christian Kruse]

Hallo Stefan,

Aber was heisst das eigentlich? Kann ein stabiles System denn nicht
zerstört werde? Hängt sich ein stabiles System nie auf? Wann ist
eine Software überhaupt stabil?

Eine Software ist dann als »stable« gekennzeichnet, wenn sie
hinreichend getestet wurde und unter normalen Bedingungen keine
Abstuerze oder Fehler festgestellt werden konnten.

Grüße,
 CK

[Mike]

Moin Stefan,

Aber was heisst das eigentlich? Kann ein stabiles System denn nicht zerstört werde? Hängt sich ein stabiles System nie auf? Wann ist eine Software überhaupt stabil?

eine Software als solches kann durchaus stabil sein, wobei ich hier eine 100 prozentige Stabilität ausschließe, denn auch Programmierer sind nur Menschen. Vielmehr werden wohl die Systemvoraussetzungen und das Zusammenspiel mit anderen Komponenten eine stabile Software unter Umständen zum Absturz bringen. Aber das ist Murphys Law.

Gruß
Mike

[Sven Rautenberg]

Moin!

eine Software als solches kann durchaus stabil sein, wobei ich hier eine 100 prozentige Stabilität ausschließe, denn auch Programmierer sind nur Menschen.

Nein, in gewissen Lebensbereichen gibt es tatsächlich Software, die zu 100% stabil läuft. Dies ist da nämlich Voraussetzung, und zwar überall, wo Versagen wirklich üble Folgen hat: In Kernkraftwerken und medizinischen Geräten beispielsweise.

Vielmehr werden wohl die Systemvoraussetzungen und das Zusammenspiel mit anderen Komponenten eine stabile Software unter Umständen zum Absturz bringen. Aber das ist Murphys Law.

Wenn eine Software auf alle denkbaren und möglichen Eingabedaten immer mit den definierten Ausgabezuständen reagiert, dann

• kann sie nicht abstürzen
• gerät in keinen unkontrollierten Zustand
• ist immer stabil.

Die Allerweltssoftware, mit der man so täglich zu tun hat, wird aber wohl dann als stabil bezeichnet, wenn nur noch sehr selten Fehler auftreten, im Allgemeinen aber keinerlei Betriebsstörungen auftreten. Bei Debian wird dieses Prinzip auf die Spitze getrieben: Die stable-Version ist versionsnummernmäßig tatsächlich weit hinter der aktuellen Entwicklung hinterher - dies aber auch nur, weil die derzeitige stable-Version erst dann zur stable wurde, als alle darin enthaltenen Programme wirklich nahezu fehlerfrei liefen.

- Sven Rautenberg

[Dark Sider]

Hi,

Nein, in gewissen Lebensbereichen gibt es tatsächlich Software, >>die zu 100% stabil läuft.

Nein, nicht mal da. Wie willst du _sämtliche_Fälle der Gründe eines möglichen Herzstillstandes durchtesten, oder alle Möglichkeiten eines Angriffes auf ein Atomkraftwerk?

Wenn eine Software auf alle denkbaren und möglichen Eingabedaten >>immer mit den definierten Ausgabezuständen reagiert, dann

• kann sie nicht abstürzen
• gerät in keinen unkontrollierten Zustand
• ist immer stabil.

Diese Software zeigts du mir...

Die Allerweltssoftware, mit der man so täglich zu tun hat, wird >>aber wohl dann als stabil bezeichnet, wenn nur noch sehr selten >>Fehler auftreten, im Allgemeinen aber keinerlei Betriebsstörungen >>auftreten.

Ab wann ist deiner Meinung nach eine Software "stabil"?
Da widersprichst du dir zu deinen Aussagen im ersten / zweiten Absatz deines Postings selbst... ,  denn Fehler treten dummerweise erst dann auf, wenn sie passieren.

Eine 100% Sicherheit wirst du also nie haben.

w.z.b.w

Dark Sider

[Christian Kruse]

Hallo Dark,

Nein, in gewissen Lebensbereichen gibt es tatsächlich Software,
die zu 100% stabil läuft.

Nein, nicht mal da. Wie willst du _sämtliche_Fälle der Gründe
eines möglichen Herzstillstandes durchtesten, oder alle
Möglichkeiten eines Angriffes auf ein Atomkraftwerk?

Erstmal: man kann auch anders als durch ausprobieren beweisen, dass
ein Programm 100% korrekt ist. Zweitens: es gehoert nicht zu den
Aufgaben einer fehlerfreien Software, auf Angriffe auf Atom-Reaktoren
so reagieren zu koennen, dass nichts passiert.

Wenn eine Software auf alle denkbaren und möglichen Eingabedaten
immer mit den definierten Ausgabezuständen reagiert, dann

• kann sie nicht abstürzen
• gerät in keinen unkontrollierten Zustand
• ist immer stabil.

Diese Software zeigts du mir...

1;

Grüße,
 CK

[Dark Sider]

Hi,

ich bin dennoch der Meinung, dass kein Mensch in der Lage sein wird, ein 100% sicheres Programm erstellen zu können; egal, wie sie getestet wird.

1

Doch, eine Software muss "eigenständig" auf solche Situationen reagieren können, bzw., diese erkennen (und entsprechende Maßnahemn ergreifen, warnen, etc.)

Erstmal: man kann auch anders als durch ausprobieren beweisen, dass
ein Programm 100% korrekt ist.

Wie?
automatisierte Tests? Derjenige, der die meisten Bugs findet, ist der DAU.
Eine 100% Sicherheit kannst du nicht garantieren. (Meine Meinung)

Du wirst NIEMLAS eine Software finden, die 100% stabil, auf alle Situationen angepasst und fehlerfrei läuft. (Ich lasse mich gerne eines Besseren belehren)

MfG

Dark Sider

[Christoph Zurnieden]

Hi,

Du wirst NIEMLAS eine Software finden, die 100% stabil, auf alle Situationen angepasst und fehlerfrei läuft. (Ich lasse mich gerne eines Besseren belehren)

Wahrscheinlich war die einzelne Zeile Programmcode ein wenig kurz (Aber nicht kürzestmöglich! ;-) und wurde übersehen, deshalb hier ein vollständiges Programm, dessen 100% Stabilität ich Dir garantieren kann:

int main(){return 42;}

Ein wenig ärmlich? Aber entspricht Deinen Vorgaben!
genau: es geht um Komplexität in der Software und genau da wird auch angesetzt: solche sicheren Programme bestehen nur aus sehr wenigen Programmzeilen und sehr wenigen Funktionen. Das kann runtergehen bis auf "eine Handvoll".

Sowas kann dann auch komplett durchdesigned sein, und vielleicht sogar vollständig durchgetestet.

Nicht zu vergessen einige Mainframeprogramme, die teilweise schon ein Vierteljahrhundert und länger durchrödeln ,-)

so short

Christoph Zurnieden

[Christian Kruse]

Hallo Dark,

ich bin dennoch der Meinung, dass kein Mensch in der Lage sein
wird, ein 100% sicheres Programm erstellen zu können; egal, wie
sie getestet wird.

Ich habe dir den Gegenbeweis doch schon erbracht. Genau wie
Christoph Zurnieden.

1
Doch, eine Software muss "eigenständig" auf solche Situationen
reagieren können, bzw., diese erkennen (und entsprechende
Maßnahemn ergreifen, warnen, etc.)

Wovon redest du? Das zitierte hat keinen Zusammenhang mit dem, was
du sagst, irgendwie.

Erstmal: man kann auch anders als durch ausprobieren beweisen,
dass ein Programm 100% korrekt ist.
Wie?

Oh, das ist ein wirklich kompliziertes Verfahren. Fuer eine einfache
while()-Schleife braucht es da schon etwa zwei bis drei DIN
A4-Seiten an Beweis.

Eine 100% Sicherheit kannst du nicht garantieren. (Meine Meinung)

Wissenschaft gibt wenig auf Meinungen. Nur, weil du dir etwas nicht
vorstellen kannst, heisst das nicht, dass es das nicht gibt. Wie
gesagt, das einfachste Beispiel, dass ich mir gerade vorstellen
kann, ist »1;«.

Du wirst NIEMLAS eine Software finden, die 100% stabil, auf alle
Situationen angepasst und fehlerfrei läuft. (Ich lasse mich gerne
eines Besseren belehren)

»Noch viel lernen du musst, junger Skywalker.«

Grüße,
 CK

[Sven Rautenberg]

Moin!

ich bin dennoch der Meinung, dass kein Mensch in der Lage sein wird, ein 100% sicheres Programm erstellen zu können; egal, wie sie getestet wird.

Nur weil wir uns dran gewöhnt haben, dass Windows ständig abstürzt und die in C oder C++ geschriebenen Programme so ihre Macken haben, bedeutet das nicht, dass niemand fehlerfreie Programme schreiben kann.

Zum einen hängt die Fehlerfreiheit extrem von der gewählten Programmiersprache ab. C und C++ sind zwar vermeintlich sehr performant, aber sie verleiten auch zu Flüchtigkeitsfehlern, die man mit anderen Programmiersprachen garnicht erst machen kann. Und ich würde auch behaupten, das Assembler einerseits eine Sprache ist, die extrem wenig unentdeckte Fehler zulässt, wenn das Programm nur hinreichend klein ist, andererseits bei größeren Programmen C von der Fehleranfälligkeit her noch um Längen schlagen kann.

Zweitens hängen die Fehler deutlich vom Entwicklungsprozess der Software ab. Wenn man den Aussagen über den relativ neuen Ansatz "Extreme Programming" Glauben schenkt, dann hat das dort angewandte "Pair Programming" (ein Rechner, ein Programmierer tippt ein und erzählt, was er da macht, ein zweiter schaut ständig über die Schulter und kommentiert und korrigiert den ersten, wenn nötig) eine extrem viel geringere Fehlerrate, als das einzelne Programmieren im stillen Kämmerlein.

Und drittens: Man kann auch versuchen, mathematisch zu beweisen, dass eine Software zu 100% korrekt ist. Ist zwar aufwendig, aber dann auch bombensicher.

Doch, eine Software muss "eigenständig" auf solche Situationen reagieren können, bzw., diese erkennen (und entsprechende Maßnahemn ergreifen, warnen, etc.)

Dein Reaktorangriffszenario ist etwas zu undetailliert. Insbesondere was deine Erwartungen an die Software angeht. Aber nehmen wir das Szenario mal an.

In einem Reaktor sind sehr viele Systeme eingebaut. Diese funktionieren alle unabhängig voneinander mit ihrer eigenen Software, sofern eine Software für die Aufgabe überhaupt notwendig ist. Das bedeutet: Es gibt eben gerade KEIN "Reaktor-Windows" als riesige, unübersichtliche, schwer wartbare Mega-Applikation, sondern eine Vielzahl von kleinen Programmen mit exakt definiertem Aufgabenbereich. Eine Regelung für ein Ventil hat beispielsweise nichts anderes zu tun, als die Ventilstellung festzustellen, den Durchfluß zu kontrollieren, die Daten an einen Zentralrechner weiterzumelden und von diesem neue Befehle zur Änderung der Ventilstellung entgegenzunehmen.

Wenn es jetzt zu deinem Angriffsszenario kommt, ist davon auszugehen, dass die Infrastruktur des Reaktors irgendwie beschädigt wird. Es gehört hinsichtlich der Softwareentwicklung für das Ventil dazu, alle möglichen (und nicht nur die wahrscheinlichen) Beeinflussungen in der Software zu berücksichtigen. Was passiert also, wenn das Ventil klemmt, wenn der Durchfluß trotz der weitest offenen Stellung immer geringer wird - oder umgekehrt immer weiter steigt, was ist, wenn der Zentralrechner keine Befehle mehr gibt oder keine Datensendungen mehr quittiert?

All diese Szenarien müssen durchgespielt und von der Software berücksichtigt werden. Dabei ist es absolut egal, ob der Bruch der Leitung vor dem Ventil nun durch ein Flugzeug, eine Bombe oder Materialversagen verursacht wurde - das ist für das Ventil irrelevant. Für den Zentralrechner natürlich nicht.

Und weil du das natürlich hören willst: Wenn man gezielt den Zentralrechner killt, und gleichzeitig auch die gesamte elektrische Versorgung, dann wird der Reaktor wahrscheinlich hochgehen. Das ist dann aber kein Softwarefehler, sondern schlicht der Situation anzulasten.

Du wirst NIEMLAS eine Software finden, die 100% stabil, auf alle Situationen angepasst und fehlerfrei läuft. (Ich lasse mich gerne eines Besseren belehren)

Auf dem PC sicherlich nicht. Das fängt schon mit Bugs in der CPU an, geht mit Bugs im Betriebssystem weiter, Bugs in Treibern, Peripherie-Firmware etc., und ganz am Ende dann auch Bugs in den Applikationen.

Aber wenn man einen bewiesen korrekt arbeitenden Zentralchip mit einem bewiesen korrekt arbeitenden Betriebssystem oder direkt mit der bewiesen korrekt arbeitenden Software betreibt, dann ergibt das ein zu 100% korrekt laufendes Programm.

Sowas kauft man aber nicht von der Stange beim Aldi, sondern diese Entwicklung ist sauteuer und extrem darauf angewiesen, dass alle Komponenten exakt wie vorgesehen verwendet werden. Mal eben was austauschen gegen anderen Ersatz (um es zu verdeutlichen: Festplatte von Hitachi ersetzen gegen eine von Maxtor) ist strengstens verboten.

- Sven Rautenberg

[Christian Kruse]

Hallo Sven,

Zum einen hängt die Fehlerfreiheit extrem von der gewählten
Programmiersprache ab.

Nein. Die Fehlerquote, ja. Die Fehlerfreiheit: nein.

Und drittens: Man kann auch versuchen, mathematisch zu beweisen,
dass eine Software zu 100% korrekt ist. Ist zwar aufwendig, aber
dann auch bombensicher.

Lass das versuchen weg :-)

Du wirst NIEMLAS eine Software finden, die 100% stabil, auf alle
Situationen angepasst und fehlerfrei läuft. (Ich lasse mich gerne
eines Besseren belehren)

Auf dem PC sicherlich nicht. Das fängt schon mit Bugs in der CPU
an, geht mit Bugs im Betriebssystem weiter, Bugs in Treibern,
Peripherie-Firmware etc., und ganz am Ende dann auch Bugs in den
Applikationen.

Nur um das klarzustellen (weil du das etwas undeutlich formuliert
hast): Fehler in der Peripherie haben nichts mit Fehlern in der
Software zu tun. Ich kann dir beweisen, dass ein Programm korrekt
ist -- trotz allem kann es noch zu undefinierten Zustaenden kommen,
einfach weil die Hardware Macken haben kann. Das aendert aber nichts
daran, dass die Software korrekt ist.

Grüße,
 CK

[rob]

Diese Software zeigts du mir...
1;

Läßt sich nicht mal compilieren, der Krams...

1: 'class' or 'interface' expected
1;
^
1 error

*SCNR*

[Christian Kruse]

Hallo rob,

Diese Software zeigts du mir...
1;
Läßt sich nicht mal compilieren, der Krams...

1: 'class' or 'interface' expected
1;
^
1 error

Benutze  halt eine Programmiersprache:

ckruse@sunshine cforum $ perl -wle '1;'
ckruse@sunshine cforum $

*SCNR*

Dito ;-)

Grüße,
 CK