also ich wuerde es ja gern mal sehen (aus neugierde) wieviele fehler bei openbsd gefunden werden. da openbsd ja ein anderen code audit durchfuehrt wie andere projekte duerfte da theoretisch weniger kaputter code drinn sein. openssh sollte meines erachtens immer als erste applikation nach fehlern durchsucht werden, da ssh wohl der serverdienst ist der sogut wie immer am netz haengt und von ueberall her erreichbar ist.
Dort waren relativ viel Fehler vorhanden, als dieses Uniprojekt OpenSourceprogramme analysierte u.a. auch OpenBSD. Linux ist zwar viel komplexer aber es wurden vergelichsweise wenig Fehler gefunden.
Wobei ich jetzt auch nicht weiss welche Module dort im Detail untersucht wurden.
Bei der ganzen Diskussion finde ich es immer Schade, dass von Fehlern oder Defekten geredet wird. Die gefundenen Punkte sind oft keine Fehler, sondern ungewöhnliche Programmiertechniken. In Java gibt es Tools wie z.B. Checkstyle, welche einen "Defekt" melden, wenn man einen Punkt am Ende eines Kommentars vergessen hat. Wenn das als Defekt durchgeht, dann habe ich an einem Tag 2000 (in Worten zweitausend) Defekte aus einer Software entfernt.
Klar helfen solche Tools auch echte Fehler zu finden, aber nur die Zahl von vielen tausend Regelverletzungen sagt nichts über die wirkliche Qualität des Produktes/Codes aus. Zum Teil kann es auch das Gegenteil bewirken: Man konzentriert sich auf Regeln und nicht mehr so sehr auf die eigentliche Funktionalität.
Fehler bedeutet hier: Fehler die Sicherheitslecks nach sich ziehen.
Klar helfen solche Tools auch echte Fehler zu finden, aber nur die Zahl von vielen tausend Regelverletzungen sagt nichts über die wirkliche Qualität des Produktes/Codes aus. Doch. Eine alte Testerweisheit ist: Wenn viele Bugs in einem Modul auftauchen kann man davon ausgehen, dass dort noch mehr drinn stecken, das bewahrheitet sich immer und wurde durch eine Vielzahl an Untersuchungen bestätigt. Besser das Modul wegwerfen und nochmal neu schreiben. Selbst diese Binsenweisheit ist vielen Entwicklern gar nicht bekannt oder wollen sie nicht wahrhaben, auch im OpenSourcebereich, wo ja angeblich so viele Profis codieren.
Zum Teil kann es auch das Gegenteil bewirken: Man konzentriert sich auf Regeln und nicht mehr so sehr auf die eigentliche Funktionalität. Ja, wenn man keine Ahnung von Softwaretesting hat. Wer damit überfordert oder zu faul ist, wird nie gute grosse Softwareprojekte abliefern. Professionelles Testen gehört zum Softwareentwickeln dazu, wer das nicht wahrhaben will der ist hochgradig unprofessionell das trifft auf eine Vielzahl von Software zu aber auch und vor allem freie Software, die immer von sich behauptet alles besser zu machen, professionelles Testing spielt in den meisten dieser Projekte aber keine bis eine geringe Rolle. Klockwork und Co beweisen dies immer wieder eindrucksvoll. Viele wissen ja nicht mal wie man Software richtig testet, da wird dann rumprobiert und geschaut was passiert, mit grep nach bösen Befehlen gesucht, ... das ist halt zu wenig.
>Besser das Modul wegwerfen und nochmal neu schreiben. Selbst diese Binsenweisheit ist vielen Entwicklern >gar nicht bekannt oder wollen sie nicht wahrhaben, auch im OpenSourcebereich, wo ja angeblich so viele >Profis codieren.
also bitte sag das mal den jungs von MS die aus kompatibilitätsgründen noch 16-bit code in vista mitschleppen. Wenn deine Weisheit so richtig wäre müssten bei MS ja lauter Idioten arbeiten. Ich wüsste auch mal gerne woher diese "Weisheit" stammt. Code wegzuwerfen ist meist völliger Unsinn, vor allem wenn der Code sich jahrelang auf zig-tausend Systemen bewährt hat. So einfach mal neuen Code zu schreiben geht nicht, selbst der beste Programmierer schafft niemals fehlerfreien Code sondern ist immer aufs Testen angewiesen.
Ich würde da auch eher Hero zustimmen man sollte sich weniger auf die Regeln konzentrieren, vor allem als Autor. Wenn jemand Externes den Code durchsieht und aufräumt ist das natürlich immer gut. Überhaupt sollten Sichehrheitschecks am besten immer von jemand gefahren werden der von ausserhalb kommt (Viele Programmieren entwickeln eine emotionale Nähe zum Code und weigern sich zu akzeptieren, dass es dort Fehler gibt)
>Viele wissen ja nicht mal wie man Software richtig testet, Ja dann erklär uns dass bitte mal grosser Guru, anstatt hier nur zu nörgeln. Tatsächlich sind viele Fehler weitaus zu komplex um mit solchen Auto-tests jemals gefunden zu werden.
Hier steht übrigens: "Wieviele der von Klocwork gemeldeten Probleme real sind und wieviele »falsche Positive« des Programmes," schön das es bei Prolinux qualifizierte Poster gibt, die es dafür schon wissen echt super.
> also bitte sag das mal den jungs von MS die aus kompatibilitätsgründen noch 16-bit code > in vista mitschleppen. Wenn deine Weisheit so richtig wäre müssten bei MS ja lauter > Idioten arbeiten.
Du verwechselst das Ganze hier hier wohl Abwärtskompatibilität. Wenn Du 16-Bit Apps ausführen willst, brauchst du halt in Gottes Namen auch 16-Bit Libs. Ohne jetzt MS verteidigen zu wollen, das ist ein Punkt, der mich als Softwareengineer bei Linux wirklich oft ankotzt, ständig werden Schnittstellen ohne Not verändert. (Ich hab noch immer sooo nen Hals, dass mein teures Maple V 5.0 heute nicht mehr brauchbar ist, weil es gegen ne uralte LibC linkt.) Aber das ist ein anderes Thema...
> Ich wüsste auch mal gerne woher diese "Weisheit" stammt.
Die Weißheit, dass Code, der bei Tests oder Inspektionen viele Fehler (und seien es auch nur die fehlenden Punkte in den Kommentaren) aufweißt, noch viel mehr versteckte Fehler enthält ist empirisch begründbar. Das Ganze stellt auch eines der Grundkonzepte des Cleanroom-Development dar. Kurzgefasst kann man sagen, dass man Qualität nicht in eine Software hineinprüfen kann, sondern sie einbauen muss.
> Code wegzuwerfen ist meist völliger Unsinn, vor allem wenn der Code sich jahrelang auf > zig-tausend Systemen bewährt hat. So einfach mal neuen Code zu schreiben geht nicht, > selbst der beste Programmierer schafft niemals fehlerfreien Code sondern ist immer aufs > Testen angewiesen.
Das ist korrekt. Aber besser ein einmal als untuglich erkanntes Modul wegwerfen, als sich jahrelang mit dessen Problemen rumschlagen.
> Ich würde da auch eher Hero zustimmen man sollte sich weniger auf die Regeln > konzentrieren, vor allem als Autor.
Bullshit. Schonmal was von ego-less Programming gehört? *Sinnvolle* Regeln sind das Fundament für erfolgreiche größere/verteilte Softwareprojekte. Alles andere ist deppenmäßiges Rumgefrickel. Ich finde, dass das eine Schwäche vieler OSS und auch CS Projekte ist, dass es keine Regeln gibt, oder diese nicht durchgesetzt werden.
> Wenn jemand Externes den Code durchsieht und aufräumt ist das natürlich immer gut.
Und noch besser ist es, wenn er deinen Code auch noch versteht, weil du dich an die Regeln gehalten hast. Wann kapieren die Leute, dass Code wesentlich öfter gelesen wird, als er geschrieben wird?
> Überhaupt sollten Sichehrheitschecks am besten immer von jemand gefahren werden der von > ausserhalb kommt (Viele Programmieren entwickeln eine emotionale Nähe zum Code und > weigern sich zu akzeptieren, dass es dort Fehler gibt)
Korrekt, wie überhaupt alle Tests sollte das von einer nicht in Design/Implementierung involvierten Person gemacht werden.
>>Viele wissen ja nicht mal wie man Software richtig testet, >Ja dann erklär uns dass bitte mal grosser Guru, anstatt hier nur zu nörgeln. Tatsächlich >sind viele Fehler weitaus zu komplex um mit solchen Auto-tests jemals gefunden zu werden.
Das sind keine Test, was Coverity und Klocwork machen, das sind mehr oder minder intelligente statische Codeanalysen. Sowas kann auf keinen Fall Tests ersetzen, aber es kann ein guter Fingerzeig für weitere von Menschen gemachte Inspektionen des Codes sein.
Viele wissen ja nicht mal wie man Software richtig testet, da wird dann rumprobiert und geschaut was passiert, mit grep nach bösen Befehlen gesucht, ... das ist halt zu wenig.
Naja - man sollte aber auch hinzufügen, dass Testen jetzt auch nicht unbedingt so populär ist. Es ist einfach Zusatzaufwand, der nicht immer so honoriert wird, wie er es verdient hätte (auch im professionellen Umfeld).
ember, der jetzt auch nicht SO gern Testklassen schreibt
kennt jemand von euch eine downloadmöglichkeit für die beiden systeme? beide verlangen eine registrierung auf die ich keinen bock habe. ich werde eh nix kaufen und will nur meine eigenen bescheidenen programme testen.
Möglicherweise möchte die Firma ihr Programm nicht verschenken. (Oder vermeiden, dass kommerzielle Programmierer es für ihre Programme einsetzen.) Nachgeschaut habe ich jedoch nicht.
openssh sollte meines erachtens immer als erste applikation nach fehlern durchsucht werden, da ssh wohl der serverdienst ist der sogut wie immer am netz haengt und von ueberall her erreichbar ist.
Wobei ich jetzt auch nicht weiss welche Module dort im Detail untersucht wurden.
Wenn das als Defekt durchgeht, dann habe ich an einem Tag 2000 (in Worten zweitausend) Defekte aus einer Software entfernt.
Klar helfen solche Tools auch echte Fehler zu finden, aber nur die Zahl von vielen tausend Regelverletzungen sagt nichts über die wirkliche Qualität des Produktes/Codes aus. Zum Teil kann es auch das Gegenteil bewirken: Man konzentriert sich auf Regeln und nicht mehr so sehr auf die eigentliche Funktionalität.
Klar helfen solche Tools auch echte Fehler zu finden, aber nur die Zahl von vielen tausend Regelverletzungen sagt nichts über die wirkliche Qualität des Produktes/Codes aus.
Doch. Eine alte Testerweisheit ist: Wenn viele Bugs in einem Modul auftauchen kann man davon ausgehen, dass dort noch mehr drinn stecken, das bewahrheitet sich immer und wurde durch eine Vielzahl an Untersuchungen bestätigt. Besser das Modul wegwerfen und nochmal neu schreiben. Selbst diese Binsenweisheit ist vielen Entwicklern gar nicht bekannt oder wollen sie nicht wahrhaben, auch im OpenSourcebereich, wo ja angeblich so viele Profis codieren.
Zum Teil kann es auch das Gegenteil bewirken: Man konzentriert
sich auf Regeln und nicht mehr so sehr auf die eigentliche Funktionalität.
Ja, wenn man keine Ahnung von Softwaretesting hat. Wer damit überfordert oder zu faul ist, wird nie gute grosse Softwareprojekte abliefern.
Professionelles Testen gehört zum Softwareentwickeln dazu, wer das nicht wahrhaben will der ist hochgradig unprofessionell das trifft auf eine Vielzahl von Software zu aber auch und vor allem freie Software, die immer von sich behauptet alles besser zu machen, professionelles Testing spielt in den meisten dieser Projekte aber keine bis eine geringe Rolle. Klockwork und Co beweisen dies immer wieder eindrucksvoll.
Viele wissen ja nicht mal wie man Software richtig testet, da wird dann rumprobiert und geschaut was passiert, mit grep nach bösen Befehlen gesucht, ... das ist halt zu wenig.
also bitte sag das mal den jungs von MS die aus kompatibilitätsgründen noch 16-bit code in vista mitschleppen. Wenn deine Weisheit so richtig wäre müssten bei MS ja lauter Idioten arbeiten. Ich wüsste auch mal gerne woher diese "Weisheit" stammt. Code wegzuwerfen ist meist völliger Unsinn, vor allem wenn der Code sich jahrelang auf zig-tausend Systemen bewährt hat. So einfach mal neuen Code zu schreiben geht nicht, selbst der beste Programmierer schafft niemals fehlerfreien Code sondern ist immer aufs Testen angewiesen.
Ich würde da auch eher Hero zustimmen man sollte sich weniger auf die Regeln konzentrieren, vor allem als Autor. Wenn jemand Externes den Code durchsieht und aufräumt ist das natürlich immer gut. Überhaupt sollten Sichehrheitschecks am besten immer von jemand gefahren werden der von ausserhalb kommt (Viele Programmieren entwickeln eine emotionale Nähe zum Code und weigern sich zu akzeptieren, dass es dort Fehler gibt)
>Viele wissen ja nicht mal wie man Software richtig testet,
Ja dann erklär uns dass bitte mal grosser Guru, anstatt hier nur zu nörgeln. Tatsächlich sind viele Fehler weitaus zu komplex um mit solchen Auto-tests jemals gefunden zu werden.
Hier steht übrigens:
"Wieviele der von Klocwork gemeldeten Probleme real sind und wieviele »falsche Positive« des Programmes,"
schön das es bei Prolinux qualifizierte Poster gibt, die es dafür schon wissen echt super.
> in vista mitschleppen. Wenn deine Weisheit so richtig wäre müssten bei MS ja lauter
> Idioten arbeiten.
Du verwechselst das Ganze hier hier wohl Abwärtskompatibilität. Wenn Du 16-Bit Apps ausführen willst, brauchst du halt in Gottes Namen auch 16-Bit Libs. Ohne jetzt MS verteidigen zu wollen, das ist ein Punkt, der mich als Softwareengineer bei Linux wirklich oft ankotzt, ständig werden Schnittstellen ohne Not verändert. (Ich hab noch immer sooo nen Hals, dass mein teures Maple V 5.0 heute nicht mehr brauchbar ist, weil es gegen ne uralte LibC linkt.) Aber das ist ein anderes Thema...
> Ich wüsste auch mal gerne woher diese "Weisheit" stammt.
Die Weißheit, dass Code, der bei Tests oder Inspektionen viele Fehler (und seien es auch nur die fehlenden Punkte in den Kommentaren) aufweißt, noch viel mehr versteckte Fehler enthält ist empirisch begründbar. Das Ganze stellt auch eines der Grundkonzepte des Cleanroom-Development dar. Kurzgefasst kann man sagen, dass man Qualität nicht in eine Software hineinprüfen kann, sondern sie einbauen muss.
> Code wegzuwerfen ist meist völliger Unsinn, vor allem wenn der Code sich jahrelang auf
> zig-tausend Systemen bewährt hat. So einfach mal neuen Code zu schreiben geht nicht,
> selbst der beste Programmierer schafft niemals fehlerfreien Code sondern ist immer aufs > Testen angewiesen.
Das ist korrekt. Aber besser ein einmal als untuglich erkanntes Modul wegwerfen, als sich jahrelang mit dessen Problemen rumschlagen.
> Ich würde da auch eher Hero zustimmen man sollte sich weniger auf die Regeln
> konzentrieren, vor allem als Autor.
Bullshit. Schonmal was von ego-less Programming gehört? *Sinnvolle* Regeln sind das Fundament für erfolgreiche größere/verteilte Softwareprojekte. Alles andere ist deppenmäßiges Rumgefrickel. Ich finde, dass das eine Schwäche vieler OSS und auch CS Projekte ist, dass es keine Regeln gibt, oder diese nicht durchgesetzt werden.
> Wenn jemand Externes den Code durchsieht und aufräumt ist das natürlich immer gut.
Und noch besser ist es, wenn er deinen Code auch noch versteht, weil du dich an die Regeln gehalten hast. Wann kapieren die Leute, dass Code wesentlich öfter gelesen wird, als er geschrieben wird?
> Überhaupt sollten Sichehrheitschecks am besten immer von jemand gefahren werden der von
> ausserhalb kommt (Viele Programmieren entwickeln eine emotionale Nähe zum Code und
> weigern sich zu akzeptieren, dass es dort Fehler gibt)
Korrekt, wie überhaupt alle Tests sollte das von einer nicht in Design/Implementierung involvierten Person gemacht werden.
>>Viele wissen ja nicht mal wie man Software richtig testet,
>Ja dann erklär uns dass bitte mal grosser Guru, anstatt hier nur zu nörgeln. Tatsächlich >sind viele Fehler weitaus zu komplex um mit solchen Auto-tests jemals gefunden zu werden.
Das sind keine Test, was Coverity und Klocwork machen, das sind mehr oder minder intelligente statische Codeanalysen. Sowas kann auf keinen Fall Tests ersetzen, aber es kann ein guter Fingerzeig für weitere von Menschen gemachte Inspektionen des Codes sein.
Kloc(k)work würde mein Analysetool z. B. bei Dir bemängeln.
Gruß
Tuxracer
Naja - man sollte aber auch hinzufügen, dass Testen jetzt auch nicht unbedingt so populär ist. Es ist einfach Zusatzaufwand, der nicht immer so honoriert wird, wie er es verdient hätte (auch im professionellen Umfeld).
ember, der jetzt auch nicht SO gern Testklassen schreibt
Nachgeschaut habe ich jedoch nicht.
MfG