Tatsächlich fand (!) die Firma mit ihren Tools nur 985 Fehler...
Ich finde auch das meiste nicht wieder, was ich suche. Trotzdem weiss ich aber, dass es da ist. Irgendwo jedenfalls und ganz sicher.
Nach Jahren finde ich dann auch wirklich manchmal Sachen, die ich fast schon vergessen hatte und dann fallen mir auch garantiert noch ein paar andere ein, die auch noch irgendwo sein müssen.
Bisher hab ich mich deswegen eigentlich immer für ziemlich schlampig, was die Ordnung betrifft, gehalten aber jetzt weiss ich endlich, dass dem nicht so ist, sondern sogar das Gegenteil zutrifft:
Je weniger ich wiederfinde, desto überlegener ist nämlich die Qualität meines Ordnungssystems. - Wer hätte das gedacht?
.. zumindest bei groesseren Projekten ;-) Ich wuerde mich auch manchmal schaemen, wenn mein prof. Code freizugeben werden wuerde ... Das liegt aber in der Natur, das alles so billig wie moeglich sein muss.... und bei Closed Source der Kunde die Qualitaet schlechter pruefen kann! Die verlangte Funktionalitaet ist vorhanden, das Programm fertig. Hmm, und wenn ein Fehler (Bug) gefunden wird, dann muss ich halt noch mal ran... Fuer die meisten Kunden ist die Funktionalitaet nur wichtig, nicht, mit welche Qualitaet ...., Diese wirkt sich ja meist auch nicht auf das Konzernergebnis aus ....
Und wenn wir ein sicheres Programm anbieten wuerden, welches laenger dauert, haetten wir den Auftrag nicht .... MfG Sigfried
Sicher ist die Quallität mit den Jahren, durch bessere Arbeitsmethoden, gestiegen. Ich denke aber das dass hauptsächlich an den vielen Alpha- und Beta-Testern liegt. Komerzielle Firmen haben meist nur 10 oder 100 Mann zum testen. Der Linux Kernel wird von 1000-enden als Alpha getestet und von 10 000 bis 100 000 als Beta!!! Und das mit voller Source Code Einsicht / Korrekturmöglichkeit.
Von bierathlet am Mi, 15. Dezember 2004 um 10:53 #
tja, wer in der "professionellen" software-entwicklung arbeitet, kennt die situation:
a: chef, der code hier ist echt müll. ich würde das gerne mal aufräumen. würde maximal 1 tag dauern. chef: ach lass nur, es funktioniert doch, daran ändern wir jetzt nichts mehr!
hab ich x-mal erlebt. und meistens kommt es erst gar nicht soweit, dass sich jemand "einfach so" den alten code nochmal anschaut. bei OSS hingegen hat man kein problem damit, schlechten code "from scratch" neu zu implementieren.
Mal ne blöde Frage, aber werden die Fehler denn irgendwo publiziert, so dass sie gefixt werden können? Oder behält die Firma das für sich? Das geht aus dem Artikel nicht so richtig vor. Denn 25 buffer overflows, 569 Abstürze sowie 100 sicherheitsrelevante Probleme zu fixen wär sicher nicht schlecht für die Kernel-Qualität.
Ich finde es lustig, eine nun wirklich so schlechte Nachricht wie diese, nämlich das unterm Strich eben mindestens 627 neue und nicht gefixte Kernelbugs gefunden worden, mit so einer Überschrift zu versehen.
Zwar ist es natürlich auch ein Gutes, dass man sie gefunden hat, klar aber das Negative überwiegt doch hier unterm Strich nun wirklich eindeutig.
Und was das Fixen angeht:
Naja es wird Gründe haben, warum es selbst jetzt schon 1225 offene Bugs gibt, mit den neuen wären es dann in etwa 2000 und beileibe nicht alle davon sind Pillepalle, das dürfte wohl auch klar sein.
Von bierathlet am Mi, 15. Dezember 2004 um 11:10 #
du begreifst aber auch gar nichts. kein wunder, bist du nicht der, der die relativitätstheorie mal als "blosse theorie" abgetan hat?
es ist keine schlechte sondern eine sensationelle (wenn auch nicht wirklich überraschende) nachricht: - die fehlerrate im linuxkernel ist im vergleich zu proprietärer sw extrem niedrig --> das offene entwicklungsmodell ist der klosettvariante überlegen. - die meisten der entdeckten bugs haben die kernelentwickler inzwischen schon selber gefunden --> die qualitätssicherung der kernelleute funktioniert ziemlich gut. - die übrigen bugs können durch den beitrag von coverity schon bald korrigiert werden --> damit wird die bereits sensationelle codequalität noch einmal besser.
> Naja es wird Gründe haben, warum es selbst jetzt schon 1225 offene Bugs gibt, mit den neuen wären es dann in etwa 2000
und wenn du den artikel gelesen hättest, wäre dir klar dass man in closed source systemen das hundertfache an bugs hat. "Commercial software typically has 20 to 30 bugs for every 1,000 lines of code, according to Carnegie Mellon University's CyLab Sustainable Computing Consortium. This would be equivalent to 114,000 to 171,000 bugs in 5.7 million lines of code."
diese nachricht ist eine PR-katastrophe für das closed-source-entwicklungsmodell. bill gates wird heute abend sicher zu seiner domina gehen und sich mal wieder tüchtig auspeitschen lassen.
Von bierathlet am Mi, 15. Dezember 2004 um 16:57 #
(entschärfte version:) naja, wenn du nur "nach dem gefühl" urteilst, und der nick des posters wichtiger ist als der inhalt des postings, dann wundert es mich auch nicht, dass du keine argumente vorbringen kannst.
Zitat:du begreifst aber auch gar nichts. kein wunder, bist du nicht der, der die relativitätstheorie mal als "blosse theorie" abgetan hat?
Na na, wer lehnt sich denn da soweit aus dem Fenster?? Ich finde es schon erstaunlich, dass du mit deinem Potential überhaupt in der Lage bist das Wort "Relativitätstheorie" zu schreiben, danke Gott dafür. Aber mal im Ernst, du glaubst doch nicht wirklich an diesen Selbstbetrug aller MS-Philosophie?? Diese Strategie hat schon Regierungen gestürzt, die letzte dieser Art war die DDR. Wir erfüllen das Plansoll um 120% indem wir es so niedrig wie möglich ansetzen, also lassen wir ein Tool über den Kernelcode laufen der nur 40% aller Fehler findet und somit sind wir mindesten 60% besser als alles Andere auf dieser Welt. Wohl wissend, das es genug verblendete Fanatiker gibt, die unsere Ausführung als die Erkenntnis verbreiten.
Zitat:ich hab schliesslich physik studiert. da lernt man sowas. mach du erst mal deinen sonderschulabschluss, dann reden wir weiter.
Falsch, du hast dich einschreiben lassen, aber keinen Studienplatz bekommen (NC) und wärst eh nicht hingegangen ;-) Übrigens als Wunschphysiker solltest du doch wenigstens im Abitur mit Deutschkenntnissen geglänzt haben, oder sollte es auch da nicht gereicht haben?
PS: Wenn schon Alkohol, dann mit Stil in Form eines Glases Wein in intellektueller Gesellschaft, oder sind aus deiner imaginären Studienzeit keine Freundschaften übrig geblieben?
Von bierathlet am Do, 16. Dezember 2004 um 13:18 #
> Falsch, du hast dich einschreiben lassen, aber keinen Studienplatz bekommen (NC)
ich kann dir ja mal eine kopie meines diploms schicken ;-) (übrigens: einschreiben lassen kann man sich erst, wenn man einen studienplatz bekommen hat. aber solche zusammenhänge sind dir natürlich fremd).
> solltest du doch wenigstens im Abitur mit Deutschkenntnissen geglänzt haben,
ähm, wer "löst" mit "ß" schreibt, sollte in solchen dingen wohl besser den mund halten. si tacuisses, philosophus mansisses! (ja, grosses latinum habe ich auch). meine deutschkenntnisse sind absolut überdurchschnittlich. ich musste im studium auch dauernd die hausarbeiten und diplomarbeiten meiner kollegen germanisten korrekturlesen. dazu kommt natürlich noch eine handvoll weiterer fremdsprachen. finde dich einfach damit ab, dass ich ein genie und allroundtalent bin!
> Wenn schon Alkohol, dann mit Stil in Form eines Glases Wein
wein ist das, was man trinkt, wenn das bier alle ist (max goldt).
Ja, ich gebe mich geschlagen. Nur einer mit dem grossem Latinium (was es nicht mehr gibt) kann dies! ;-) Mich beeindruckt auch weniger ein wertloses Diplom als Ersatz für einen vermeindlichen Intelligenzquotienten, als eher die Mitgliedschaft in einem angesehenen Institut desjenigen. Übrigens geschickt gelöst, überspielt die kleine Schwäche der Groß- und Kleinschreibung junger Freund.
Küss die Hand
PS: Bitte erschlage mich nicht mit deinen zusammengeglaubten Phrasen (sowohl auch im Latein)
Ein paar echte werden wohl drunter sein. Was aber wohl wirklich beabsichtigt ist, dürfte sein das die Entwickler die Fehlerfindetools in Zukunft nutzen.
Hätte du mal den Text richtig durchgelesen, dann wüsstest du, dass die meisten dieser Bugs innerhalb der genannten vier Jahre behoben wurde. Mich würde allerdings auch interessieren was diese Firma namens Coverity jetzt eigentlich mit ihrem tollen Programm und dessen Ergebnissen machen will? Einfach nur der Linux-Gemeinde melden? Immerhin ist es eine Firma, da sind die doch sicher auf Geld aus, nicht? War die vierjährige Fehlersuche nur eine Art Werbekampagne, damit möglichst viele große Unternehmen sich dieses Programm für teures Geld ergattern bzw. ihre Codes auf Fehler untersuchen lassen? Wer sucht eigentlich nach den Fehlern in einem Fehlersuchprogramm?
Ich glaube, zu eben diesem Programm habe ich schon mal einen Artikel gelesen. Wenn es das gleiche ist, läuft es wie folgt:
Das Programm simuliert den Wert aller Variablen, und läuft damit durch die Verzweigungen im Sourecode. Grundsätzlich ist das unmöglich, da die Anzahl der Variationen sehr schnell zu hoch wird. Der Trick, und damit auch der Wert des Programms, liegt in den Techniken zur Reduktion dieser Anzahl.
Als Ergebnis liefert es Dir dann Stellen im Code, die wahrscheinlich Fehler sind. Natürlich müssen diese untersucht werden, ob das tatsächlich der Fall ist.
Als sie es auf Linux (und Apache scheinbar) angewendet haben, erhielten sie damit Berichte über die Qualität des Programms. Das hätten sie sonst teuer bezahlen müssen. Natürlich lieferte es ihnen auch einen guten Anlass für Public Relations.
Und wie mir scheint, gibt es mindestens ein gewisses anderes Betriebssystem, das ein solche Tool dringend notwendig hat. Glücklicherweise hat die Firma diesen gewissen Betriebssystems auch genügend Kleingeld in der Portokasse.
Ein Betriebssystem statisch zu analysieren ist unmöglich. Es ist ja schon kaum möglich, Buffer-Overflows in C-"Strings" zuverlässig zu erkennen, wie soll man dann ungleich komplexere Fehler (Race Conditions o.ä.) erkennen?
Aber es gibt Möglichkeiten zur Datenflussanalyse, die teilweise auch schon recht brauchbare Ergebnisse liefern. Aber diese Programme haben meistens noch ein Problem mit der Code-Komplexität; der Speicherverbrauch wächst dann recht schnell ist unermessliche, genauso wie die Laufzeit.
Daher müssen heut zumeist Heuristiken herhalten, und deren Ergebnisse werden dann noch von Hand nachgeprüft.
Von bierathlet am Mi, 15. Dezember 2004 um 10:56 #
> werden die Fehler denn irgendwo publiziert
ja. guckst du hier: http://lwn.net/Articles/87538/ da gibts auch info über ein ähnliches (aber noch nicht so ausgereiftes) tool, das l.torvalds geschrieben hat.
> Mal ne blöde Frage, aber werden die Fehler denn > irgendwo publiziert, so dass sie gefixt werden > können? Oder behält die Firma das für sich?
Da gibt und gab es in der Vergangenheit etliche Probleme. Beispielsweise gab es von Mandrake für Probleme extra Patches für den Vanilla-Kernel, die aber nie in offiziellen Kernel integriert wurden. Die Lücken blieben über Monate offen. Ander Bugreports von SuSE gingen einfach unter, obwohl sie publik gemacht wurden. Patches aus alten Kernelversionen werden nicht immer in neue übernommen (sofern möglich). Für bekannte Probleme findet sich niemand, der sie fixt (mWn gab es für das Entladen von Modulen über Jahre eine Race Condition). Das ganze ist teilweise sehr chaotisch. Dazu gab es mal im Linux Magazin eine genauerer Untersuchung mit Statistiken, aber ich weiß leider nicht, in welcher das war. Ist schon länger her.
Aber es gibt natürlich auch eine große Zusammenarbeit, Übernahme von Patches und es werden viele Lücken geschlossen. Vom Optimum ist aber Linux wohl doch einiges entfernt.
Was ist denn mit OpenBSD, willst du uns sagen, dass deren Kernel, der veraltet ist kaum was unterstützt weniger Fehler hat, wundert mich auch nicht. Das ist ja wohl ein Vergleich VW Golf gegen Audi A8
Dein ROFL solltest du auf deinen eigenen Kommentare machen.
Wieso kaum etwas unterstützt? Im Securitybereich steht Linux aber in Sachen Hardwareunterstützung und Features ziemlich weit im Hintergrund. Für sinnvolle Vergleiche muß man dann schonmal zu SE-Linux greifen.
In Sachen Entwicklung ist Linux auch hinter OpenBSD zurück. Es gibt beispielsweise keine regelmäßigen Codeaudits. Changelogs und Security-Listen kann man unter Linux eigentlich ganz vergessen.
Nicht, daß ich Linux schlecht machen will (ich bin auch kein OBSD-Nutzer), aber man muß hier schon differenzieren. Sicherlich unterstützt OpenBSD weniger. Und sicherlich unterstützt Linux weniger.
Von stefan3??? am Mi, 15. Dezember 2004 um 10:26 #
Ja, wer sich OPENN-BSD anguckt, der stellt fest, daß die lange Zeit im Kernel böse Speicherleaks hatten. Fehler passieren, sogar solchen selbsternannten Gottheiten wie Theo.
Von some point of view am Mi, 15. Dezember 2004 um 11:05 #
OpenBSD mit der Funktionalität einer verstaubten Baumwollsocke, kann du doch nicht mit einem Multimedia- und Netzwerkunterstützenden Kernel wie dem von Linux vergleichen *Tsss*
Man muss aber mal den Einsatzzweck von OPEN BSD sehen, das ist j auch keine eierlegende Wollmilchsau, sondern auf Security getrimmt, da gehört es hin. Man sollte Äpfel nicht mit Birnen vergleichen. Im übrigen habe ich Open BSD als Firewallsystem sehr schätzen gelernt. Das Ding funktioniert einwandfrei und wenn es einmal sauber eingerichtet wurde, läuft es auch ziemlich problemlos. Aber als Client System würde ich es auch nicht einsetzen, das ist nämlich absoluter Humbug.
Von Kopfschleuder am Mi, 15. Dezember 2004 um 12:20 #
Wie heißt es doch so schön: Für jeden Zweck das passende Werkzeug. Die BSDs sind eher für Spezialfälle (Router/Firewall, hochverfügbare Server, exotische Hardware) zu verwenden, GNU/Linux eher für den breiten Desktopeinsatz. Das soll aber nicht heißen, dass man es nicht genau anders herum machen könnte, und das das vielleicht nicht sogar keine Vorteile bringen kann.
Geht man von den üblichen Fehlerzahlen proprietärer Software aus, so ist der Code des aktuellen Linux-Kernels von geradezu sensationeller Qualität.
Hmm, das ist ja ein klasse Vergleich: auf der einen Seiten verwende ich eine "übliche Fehlerzahl", auf der anderen Seite laß ich ein Programm laufen, welches (wie auch immer) nach Fehlern sucht, und ich verwende die Anzahl der *gefundenen* Fehler (welche natürlich kleiner der Anzahl der *vorhandenen* Fehler ist). Darüber hinaus geht man auf der sog. proprietären Software vom nicht veröffentlichten Produkt aus. Wen interessieren denn die Fehler darin ? Mal angenommen, der Hersteller der Software findet im Test *vor* Veröffentlichung des Produkts sämtliche Fehler im Code (was natürlich unrealistisch ist, klar, aber nehmen wir es doch mal an), dann können in der Testversion von mir aus tausende Fehler drin sein - solange ich die im *fertigen* Produkt nicht mehr sehe, ist mir das doch wurscht. Auch wundern mich die Zahlen etwas: wenn ich alleine auf Heise Online mal die Überschriften dieses Jahres durchschaue, finde ich wahrscheinlich schon fast so viele entdeckte (und nicht widersprochene !) Buffer Overflows, und da will eine speziell dafür "trainierte" Software in vier Jahren nicht mehr gefunden haben !?! Oder soll der Rest tatsächlich "unkritisch" sein und deswegen nicht beachtet worden sein (unkritische Pufferüberläufe im Kernel - gibt's sowas eigentlich überhaupt ? klingt irgendwie wie eine "unkritische Reifenbeschädigung" beim Auto).
Also, alles in allem denke ich, daß hier Äpfel mit Birnen verglichen werden. Zu welchem Zweck ? Um sich in der Linux-Gemeinde Freunde zu machen ? Dürfte wohl klappen. Um das eigene Test-Programm bekanntzumachen und zu vermarkten ? Könnte auch klappen. Aber sagt das über den Linux-Code aus ? Für mich eigentlich gar nix.
Ganz abgesehen davon dass du wahrscheinlich nicht ganz unrecht hast was die angenommenen Zahlen betrifft usw., würde mich trotzdem Interessieren wo das mit den 4 Jahren der Kernelüberprüfung stand od. steht (kommt auch in anderen Posts vor) ? Ich lese im Text nur etwas davon, dass die in Kernelversion 2.6.9 eine gewisse Anzahl an Fehlern gefunden haben. Das heisst nicht dass die Summe der Fehler die in den letzten 4 Jahren entdeckt wurden irgendwie vergleichbar wäre mit der Zahl der Fehler die in der aktuellen Version noch drinnen sind. Auch glaube ich kaum, dass du über 600 Meldungen von Buffer Overflows den Linux Kernel betreffend im vergangenen Jahr gelesen hast (wenn ich schätzen müsste würde ich sagen ca. 10 Stück die ich gelesen habe, wobei mir im Moment nur diese beiden do_bark() und do_m??? einfallen). Es täuscht vielleicht etwas, da ja auch immer die ganzen Overflows in Libraries und Anwendungen mit einer Überschrift die "Linux" enthält betitelt werden. Aber ansonsten finde ich auch die Formulierung "der üblichen Fehlerzahlen in unveröffentlichter proprietärer Software" (oder so ähnlich) etwas eigenartig, noch dazu wenn keine Angabe gemacht wird woher diese Zahl kommt (Schätzung ? Aufgrund welcher Tatsachen wird so geschätzt ?).
Das Projekt zur Analyse des Linux-Quellcodes mit automatisierten Tools startete bereits im Jahr 2000 an der Stanford University und ...
Die Studie wurde im Jahr 2000 gestartet, wir haben jetzt 2004 - da könnte man daraus ableiten, daß sich das ganze wohl über etwa vier Jahre erstreckte.
Was die Anzahl der Buffer Overflows angeht, das waren ja nicht mehr als 600 (das war die Summe *aller* Fehler), sondern 25, und soviel finde ich allemal bei Heise Online. ;-)
wenigstens eine vernünftige Antwort! Genau das wollte ich auch schon ein paar mal schreiben als ich die Beiträge von oben bis unten gelesen habe. Aber ganz unten kommt ja zum Glück dein Kommentar, dass genau das sagt.
Deshalb kann dieses "Testprogramm" wenn es in endlicher Zeit fertig sein will nur einer sehr kleinen subset des Kernels "simulieren". Aus dem Ergebnis kannst du aber absolut keine Schlüsse ziehen.
Wie gesagt wurde, die Programmkorektheit ist nicht entscheidbar. Wer sich damit näher auseinandersetzen will, dem sei ein gutes Buch zur theoretischen Informatik empfohlen. Stichworte: "Berechenbarkeitstheorie" und "Halteproblem"
Nur weil es nicht allgemein entscheidbar ist, ob eine allgemeines Programm hält, heisst das nicht, das solche Versuche zwecklos sind. Im Übrigen könnte man die Korrektheit eines harten Echtzeit-Betriebssystems in _endlicher_ Zeit entscheiden.
> Geht man von den üblichen Fehlerzahlen proprietärer Software aus,
Was ist denn eine "übliche Fehleranzahl",daß was CyLab behauptet? Das ist die Behauptung einer! Institution, was ist daran "üblich"?
> . . . so ist der Code des aktuellen Linux-Kernels von geradezu sensationeller Qualität.
Also, das ist mal wieder so eine übliche hjb-Werbeaussage. Beim genauen Hinsehen nur lauwarme Luft.
> Bei proprietärer Software kommen während der Entwicklung - nicht im veröffentlichten > Produkt - auf jeweils 1000 Zeilen Code bereits zwanzig bis dreißig Fehler, behauptet > jedenfalls das CyLab Sustainable Computing Consortium an der Carnegie Mellon University.
Leere Behauptung! Beweise! Die man aber nur erbringen könnte, wenn man tausende von Applikationen untersucht. Ist das geschehen?
Dieses Projekt wurde offensichtlich mit dem Grundsatz gestartet, die sog. Überlegenheit von OpenSource-Software zu beweisen - und wenn ich etwas beweisen will, dann beweise ich es auch.
Fazit: Die Überschriften von 'hjb' werden der Bildzeitung immer ähnlicher!
Was gibts denn da zu beweisen, jeder Depp weis, wenn sich 4 Leute nen code ansehen, dass die eher nen Fehler finden, als wenn der der die Software entwickelt hat seinen Code nochmal durchsieht, du wirst mir doch nicht erzählen, dass kommerzielle Projekte nur ansatzweise so viele Leute zum Testen und Coden checken haben wie OpenSource Projekte.
Es liegt ganz einfach in der Natur von OpenSource, dass da mehr Fehler entdeckt werden, was natürlich nicht heist, dass alle OpenSourceprojekte super toll gecodet sind, nicht für jeden Shit interessieren sich kompetente Leute, aber der Linuxkernel ist ein super Beweis dafür, dass dort viele Augen viel finden und an dem Kernel arbeiten wirklich spitzen Leute.
Ich weis nicht wieviel Patches ich schon geschrieben habe, aber die sind nur zustande gekommen, weil der Fehler bei mir unter bestimmten Umständen aufgetreten ist, und da ich die Sourcen hatte konnte ich den Fehler finden, wäre das Zeugs Closed Source gewesen, dann könnte man ne Supportmeldung absetzen wo zu 99% nur Schund zurückkommt und es wird nie gefixt.
Die iX hatte doch vor 8 Monaten einen sehr kurzen und oberflächlichen Test mit flawfinder durchgeführt. Während bei OpenBSD nur sehr wenige (mWn sogar nur einstellig) Warnings produziert wurden, ging es bei Linux in den fünfstelligen Bereich hoch. Natürlich werden da nur potentiell gefährliche Nutzungen von Sprachmitteln und unsicheren Methoden gezählt, und das ist nicht unmittelbar mit tatsächlichen Fehlern gleichzusetzen. Es zeigt aber zumindest die Größenordnungen auf. Der Windows-Code lag in der Mitte.
Linux fehlt es da oft an Planung und regelmäßigen Audits. Wenn ich auf den KML lese, daß der IDE-Code so heruntergekommen ist, daß nur noch zwei Menschen wirklich durchblicken, daß Maintainer deswegen ihre Arbeit niederlegen, dann frage ich mich, wie man dann eine sensationalle Qualität des Codes nachsagen kann. Das mag auf Module und Teile zutreffen, aber sicherlich nicht pauschal stimmen. Zumal es dafür auch zuviel Kritik aus den Ecken andere OSS-OS "hagelt" - wobei solche Kritik und Vergleiche positiv zu werten sind, jeder wird immer irgendwo etwas zu verbessern finden.
In Angesicht immer neuer Einführungen von Syscalls, im schnellen Wachstum von Features und der Komplexität, frage ich mich, ob da nicht einiges auf der Strecke bleibt oder geblieben ist. Die Einfachheit von Linux (und den Userlandtools) war einmal das Argument für Linux und gegen Windows. Solche Argumente mögen noch für viele Teile des Kernel zutreffen, aber sie nehmen ab. Im Userland ist das ohnehin für Mainstreamdistros ein längst überholtes Argument.
Von bierathlet am Mi, 15. Dezember 2004 um 16:04 #
> Linux fehlt es da oft an Planung und regelmäßigen Audits. [usw]
oh wie schlimm! der linux-code wurde hier aber mit code verglichen, der auf noch chaotischere weise entsteht, nämlich nach dem closed-source-modell bei kommerziellen firmen. die studie bringt ja auch kein absolutes urteil (dass linux völlig sauber und fehlerfrei sei), sondern nur einen vergleich: linux ist besser als viele anderen. ist das denn so schwer auseinanderzuhalten?
Natürlich kann man unter den schlechtesten bester sein, aber man kann auch bester unter den besten zu sein. Ich finde, man sollte sich besseren Code als Maßstab setzen, nicht schlechteren.
> linux ist besser als viele anderen. ist das denn > so schwer auseinanderzuhalten?
Nö, wieso? Habe ich das durcheinander gebracht? Allerdings würde ich diese Aussage der Studie nicht entnehmen. Ich kann da so spontan eigentlich gar nicht viel aussagekräftiges finden.
Von bierathlet am Mi, 15. Dezember 2004 um 16:27 #
> aber man kann auch bester unter den besten zu sein.
genau das ist linux ja. oder jedenfalls nahe dran ;-)
> Ich finde, man sollte sich besseren Code als Maßstab setzen, nicht schlechteren.
die linux-kernel-entwickler *nehmen* sich nicht den windows-code oder irgendsonstwas als massstab! eine arbeitsgruppe der uni stanford hat eine untersuchung gemacht und ist zu gewissen ergebnissen gekommen. das ist alles. sie haben auch nicht behauptet, dass es in der linux-entwicklung keinerlei probleme gebe, sondern sie haben sich ein bestimmtes kriterium genauer angeschaut. was ihr da nun alles hineininterpretiert hat mit den ergebnissen herzlich wenig zu tun.
Es ist ein langer Weg von dem Finden eines Fehlers bis zu dem Punkt, wo man ihn wirklich lokalisiert hat.
Praktisch sagt dir jemand: "das programm stürzt hier unter diesen und jenen Umständen ab"... und man muss erstmal herausfinden, wo und warum der Fehler auftritt und sichergehen, dass der Fehler nicht irgendwelche anderen (schlimmeren) Fehler nach sich zieht.
Von bierathlet am Mi, 15. Dezember 2004 um 17:55 #
das stimmt für bugreports von usern, aber bei automatischen tools eben nicht, denn die setzen ja (anders als der user, der nur ein phänomen beobachtet) direkt beim code an. man erhält daher genau den ort des fehlers. zu bedenken ist aber, dass so natürlich nicht alle fehler gefunden werden können, und dass nicht alle so gefundenen fehler tatsächlich zu problemen führen müssen. es könnte theoretisch sein, dass man etliche fehler korrigiert hat, dass sich die stabilität des programms dadurch aber überhaupt nicht verbessert. was sich bessert ist aber die qualität des codes.
zur frage von allo: das tool ist nicht frei zugänglich. man kann es nicht einmal kaufen (wenn ich es recht verstanden habe). allerdings gibt es ähnliche tools, die auch routinemässig eingesetzt werden, aber nicht jedes tool findet die gleichen fehler. es gab ja schon vor urzeiten das unix-tool lint, das gewisse code-schlampereien aufspürt.
Von bierathlet am Mi, 15. Dezember 2004 um 21:09 #
nachtrag: > dass nicht alle so gefundenen fehler tatsächlich zu problemen führen müssen
wie man hier sieht http://linuxbugs.coverity.com/linuxbugs.htm sind 13 prozent der fehler "toter code" und weitere 4 prozent sind unbenutzte variablen -- beides fälle, die der funktionalität des codes keinen abbruch tun, wohl aber der wartbarkeit.
Auch wenn ich den großen Fortschritt im Kernel schätze stelle ich doch immer wieder fest, dass der Kernel, bzw. die darin enthaltenen Treiber nicht robust genug sind. Es ist sehr gut, dass die Treiberentwickler sich so streng an die Standards halten. Dennoch sollte es auch weiterhin laufen, wenn die Hardware sich etwas "großzügig" in der Standardeinhaltung zeigt. Ein Beispiel hierbei ist meine USB-Festplatte aus dem Hause TrekStor. Ich kann von dieser Platten alle Daten problemlos lesen. Wenn es aber ums Schreiben geht, gibts nen Kernelpanic. Linux stürzt dabei nicht ab, sei angemerkt. Aber die Platte ist dann vom Zugriff her tot und in der dmesg gibt es lauter lustige Oops-Fehler mit diversen lustigen Hex-Adressen. Ich habe im Internet gelesen, dass der eingesetzte Controller Mist sein soll. Aber das kann es ja nicht sein. Es ist zu einfach nur auf die Hardware zu verweisen und alle Schuld von sich zu weisen. Immerhin (und jetzt kommts mal wieder *g*) läuft die Festplatte mit den normalen Standard-USB-Speicher-Treibern unter WindowsXP auch. Dumm nur, dass ich XP nicht einsätze. Hier würde man sich doch etwas mehr Spielraum wünschen. Ich programmiere ja auch so, dass bei kleinen Abweichungen nicht gleich das ganze Programm abkackt. Es gibt noch mehr solcher Probleme. Es kann doch auch nicht sein, dass mit einem neueren Kernel ein Computer nicht mehr geht. Wurde da etwa der Interrupt-Controller zu Tode verbessert? Auch wenn die Programmierer beim Kernel wirklich tolle Arbeit leisten - Kritik sollte erlaubt sein
Das Problem an der Sache ist, daß man für jede vom Standar{t|d} abweichende Hardware den Treiber erweitern muß. Das _könnte_ man zwar machen (oftmals macht man es ja auch), aber die Konsequenz daraus ist eine größerer Treiber mit mehr Programm-Code, komplexer, wahrscheinlich langsamer und wahrscheinlich fehleranfälliger. Außerdem muß sich erst einmal jemand finden, der ebenfalls über eine entsprechnende Hardware verfügt, das Wissen, einen Treiber zu Coden (oder einen Vorhandenen zu erweitern) hat und sich dann auch noch die Mühe macht.
Weiter unten schreibst du, daß es nicht sein sollte, daß ein neuer Kernel den Rechner lahmlegt. Vielleicht hat ja jemand versucht, einen Treiber für einen "ungewöhnlichen" Interrupt-Controller zu implementieren. Wenn du selber programmierst, kennst du ja die Probleme, daß eine Änderung in A() manchmal auch ungewollte Auswirkungen in Z() hat.
ihren Tools nur 985 Fehler...
Ich finde auch das meiste nicht wieder, was ich suche.
Trotzdem weiss ich aber, dass es da ist. Irgendwo
jedenfalls und ganz sicher.
Nach Jahren finde ich dann auch wirklich manchmal Sachen,
die ich fast schon vergessen hatte und dann fallen mir
auch garantiert noch ein paar andere ein, die auch noch
irgendwo sein müssen.
Bisher hab ich mich deswegen eigentlich immer für ziemlich
schlampig, was die Ordnung betrifft, gehalten aber jetzt weiss
ich endlich, dass dem nicht so ist, sondern sogar das Gegenteil
zutrifft:
Je weniger ich wiederfinde, desto überlegener ist nämlich die
Qualität meines Ordnungssystems. - Wer hätte das gedacht?
Also, da muss man echt erstmal drauf kommen? :-)
Sebastian.
Full Ack!!
Küss die Hand
Ich wuerde mich auch manchmal schaemen, wenn mein prof. Code freizugeben werden wuerde ...
Das liegt aber in der Natur, das alles so billig wie moeglich sein muss.... und bei Closed Source der Kunde die Qualitaet schlechter pruefen kann! Die verlangte Funktionalitaet ist vorhanden, das Programm fertig.
Hmm, und wenn ein Fehler (Bug) gefunden wird, dann muss ich halt noch mal ran...
Fuer die meisten Kunden ist die Funktionalitaet nur wichtig, nicht, mit welche Qualitaet ...., Diese wirkt sich ja meist auch nicht auf das Konzernergebnis aus ....
Und wenn wir ein sicheres Programm anbieten wuerden, welches laenger dauert, haetten wir den Auftrag nicht ....
MfG Sigfried
Das kann Niemand toppen
a: chef, der code hier ist echt müll. ich würde das gerne mal aufräumen. würde maximal 1 tag dauern.
chef: ach lass nur, es funktioniert doch, daran ändern wir jetzt nichts mehr!
hab ich x-mal erlebt. und meistens kommt es erst gar nicht soweit, dass sich jemand "einfach so" den alten code nochmal anschaut. bei OSS hingegen hat man kein problem damit, schlechten code "from scratch" neu zu implementieren.
Das geht aus dem Artikel nicht so richtig vor.
Denn 25 buffer overflows, 569 Abstürze sowie 100 sicherheitsrelevante Probleme zu fixen wär sicher nicht schlecht für die Kernel-Qualität.
Ich finde es lustig, eine nun wirklich so schlechte Nachricht wie diese,
nämlich das unterm Strich eben mindestens 627 neue und
nicht gefixte Kernelbugs gefunden worden, mit so einer
Überschrift zu versehen.
Zwar ist es natürlich auch ein Gutes, dass man sie gefunden hat, klar
aber das Negative überwiegt doch hier unterm Strich nun wirklich eindeutig.
Und was das Fixen angeht:
Naja es wird Gründe haben, warum es selbst jetzt schon 1225 offene Bugs gibt, mit
den neuen wären es dann in etwa 2000 und beileibe nicht alle davon sind Pillepalle,
das dürfte wohl auch klar sein.
Gruß,
Sebastian.
es ist keine schlechte sondern eine sensationelle (wenn auch nicht wirklich überraschende) nachricht:
- die fehlerrate im linuxkernel ist im vergleich zu proprietärer sw extrem niedrig --> das offene entwicklungsmodell ist der klosettvariante überlegen.
- die meisten der entdeckten bugs haben die kernelentwickler inzwischen schon selber gefunden --> die qualitätssicherung der kernelleute funktioniert ziemlich gut.
- die übrigen bugs können durch den beitrag von coverity schon bald korrigiert werden --> damit wird die bereits sensationelle codequalität noch einmal besser.
> Naja es wird Gründe haben, warum es selbst jetzt schon 1225 offene Bugs gibt, mit den neuen wären es dann in etwa 2000
und wenn du den artikel gelesen hättest, wäre dir klar dass man in closed source systemen das hundertfache an bugs hat.
"Commercial software typically has 20 to 30 bugs for every 1,000 lines of code, according to Carnegie Mellon University's CyLab Sustainable Computing Consortium. This would be equivalent to 114,000 to 171,000 bugs in 5.7 million lines of code."
diese nachricht ist eine PR-katastrophe für das closed-source-entwicklungsmodell. bill gates wird heute abend sicher zu seiner domina gehen und sich mal wieder tüchtig auspeitschen lassen.
Ich habŽso das Gefühl, als hättest Du Dich mit Deinem Bier irgendwie geistig verhoben?!
naja, wenn du nur "nach dem gefühl" urteilst, und der nick des posters wichtiger ist als der inhalt des postings, dann wundert es mich auch nicht, dass du keine argumente vorbringen kannst.
Na na, wer lehnt sich denn da soweit aus dem Fenster??
Ich finde es schon erstaunlich, dass du mit deinem Potential überhaupt in der Lage bist das Wort
"Relativitätstheorie" zu schreiben, danke Gott dafür.
Aber mal im Ernst, du glaubst doch nicht wirklich an diesen Selbstbetrug aller MS-Philosophie??
Diese Strategie hat schon Regierungen gestürzt, die letzte dieser Art war die DDR.
Wir erfüllen das Plansoll um 120% indem wir es so niedrig wie möglich ansetzen, also lassen wir ein
Tool über den Kernelcode laufen der nur 40% aller Fehler findet und somit sind wir mindesten 60%
besser als alles Andere auf dieser Welt.
Wohl wissend, das es genug verblendete Fanatiker gibt, die unsere Ausführung als die Erkenntnis
verbreiten.
PS: Alkohol lößt auch deine Probleme nicht :-)
Küss die Hand
ich hab schliesslich physik studiert. da lernt man sowas.
mach du erst mal deinen sonderschulabschluss, dann reden wir weiter.
> also lassen wir ein Tool über den Kernelcode laufen der nur 40% aller Fehler findet
wen meinst du mit "wir"? die kernel-entwickler haben mit dieser untersuchung schliesslich nichts zu tun.
> PS: Alkohol lößt auch deine Probleme nicht
naja, du scheinst ja eher auf psychopharmaka zu stehen.
mach du erst mal deinen sonderschulabschluss, dann reden wir weiter.
Falsch, du hast dich einschreiben lassen, aber keinen Studienplatz bekommen (NC) und
wärst eh nicht hingegangen ;-)
Übrigens als Wunschphysiker solltest du doch wenigstens im Abitur mit Deutschkenntnissen
geglänzt haben, oder sollte es auch da nicht gereicht haben?
PS: Wenn schon Alkohol, dann mit Stil in Form eines Glases Wein in intellektueller Gesellschaft,
oder sind aus deiner imaginären Studienzeit keine Freundschaften übrig geblieben?
Küss die Hand
ich kann dir ja mal eine kopie meines diploms schicken ;-)
(übrigens: einschreiben lassen kann man sich erst, wenn man einen studienplatz bekommen hat. aber solche zusammenhänge sind dir natürlich fremd).
> solltest du doch wenigstens im Abitur mit Deutschkenntnissen geglänzt haben,
ähm, wer "löst" mit "ß" schreibt, sollte in solchen dingen wohl besser den mund halten. si tacuisses, philosophus mansisses! (ja, grosses latinum habe ich auch). meine deutschkenntnisse sind absolut überdurchschnittlich. ich musste im studium auch dauernd die hausarbeiten und diplomarbeiten meiner kollegen germanisten korrekturlesen. dazu kommt natürlich noch eine handvoll weiterer fremdsprachen. finde dich einfach damit ab, dass ich ein genie und allroundtalent bin!
> Wenn schon Alkohol, dann mit Stil in Form eines Glases Wein
wein ist das, was man trinkt, wenn das bier alle ist (max goldt).
Nur einer mit dem grossem Latinium (was es nicht mehr gibt) kann dies! ;-)
Mich beeindruckt auch weniger ein wertloses Diplom als Ersatz für einen vermeindlichen
Intelligenzquotienten, als eher die Mitgliedschaft in einem angesehenen Institut desjenigen.
Übrigens geschickt gelöst, überspielt die kleine Schwäche der Groß- und Kleinschreibung junger
Freund.
Küss die Hand
PS: Bitte erschlage mich nicht mit deinen zusammengeglaubten Phrasen (sowohl auch im Latein)
Und die "findet" Fehler. Nun denn.
Ein paar echte werden wohl drunter sein. Was aber wohl wirklich beabsichtigt ist, dürfte sein das die Entwickler die Fehlerfindetools in Zukunft nutzen.
Mich würde allerdings auch interessieren was diese Firma namens Coverity jetzt eigentlich mit ihrem tollen Programm und dessen Ergebnissen machen will? Einfach nur der Linux-Gemeinde melden? Immerhin ist es eine Firma, da sind die doch sicher auf Geld aus, nicht?
Das Programm simuliert den Wert aller Variablen, und läuft damit durch die Verzweigungen im Sourecode. Grundsätzlich ist das unmöglich, da die Anzahl der Variationen sehr schnell zu hoch wird. Der Trick, und damit auch der Wert des Programms, liegt in den Techniken zur Reduktion dieser Anzahl.
Als Ergebnis liefert es Dir dann Stellen im Code, die wahrscheinlich Fehler sind. Natürlich müssen diese untersucht werden, ob das tatsächlich der Fall ist.
Als sie es auf Linux (und Apache scheinbar) angewendet haben, erhielten sie damit Berichte über die Qualität des Programms. Das hätten sie sonst teuer bezahlen müssen. Natürlich lieferte es ihnen auch einen guten Anlass für Public Relations.
Und wie mir scheint, gibt es mindestens ein gewisses anderes Betriebssystem, das ein solche Tool dringend notwendig hat. Glücklicherweise hat die Firma diesen gewissen Betriebssystems auch genügend Kleingeld in der Portokasse.
Ein Betriebssystem statisch zu analysieren ist unmöglich. Es ist ja schon kaum möglich, Buffer-Overflows in C-"Strings" zuverlässig zu erkennen, wie soll man dann ungleich komplexere Fehler (Race Conditions o.ä.) erkennen?
Aber es gibt Möglichkeiten zur Datenflussanalyse, die teilweise auch schon recht brauchbare Ergebnisse liefern. Aber diese Programme haben meistens noch ein Problem mit der Code-Komplexität; der Speicherverbrauch wächst dann recht schnell ist unermessliche, genauso wie die Laufzeit.
Daher müssen heut zumeist Heuristiken herhalten, und deren Ergebnisse werden dann noch von Hand nachgeprüft.
ja. guckst du hier: http://lwn.net/Articles/87538/
da gibts auch info über ein ähnliches (aber noch nicht so ausgereiftes) tool, das l.torvalds geschrieben hat.
> irgendwo publiziert, so dass sie gefixt werden
> können? Oder behält die Firma das für sich?
Da gibt und gab es in der Vergangenheit etliche Probleme. Beispielsweise gab es von Mandrake für Probleme extra Patches für den Vanilla-Kernel, die aber nie in offiziellen Kernel integriert wurden. Die Lücken blieben über Monate offen. Ander Bugreports von SuSE gingen einfach unter, obwohl sie publik gemacht wurden. Patches aus alten Kernelversionen werden nicht immer in neue übernommen (sofern möglich). Für bekannte Probleme findet sich niemand, der sie fixt (mWn gab es für das Entladen von Modulen über Jahre eine Race Condition). Das ganze ist teilweise sehr chaotisch. Dazu gab es mal im Linux Magazin eine genauerer Untersuchung mit Statistiken, aber ich weiß leider nicht, in welcher das war. Ist schon länger her.
Aber es gibt natürlich auch eine große Zusammenarbeit, Übernahme von Patches und es werden viele Lücken geschlossen. Vom Optimum ist aber Linux wohl doch einiges entfernt.
guckt euch mal openbsd an!
Dein ROFL solltest du auf deinen eigenen Kommentare machen.
Wieso kaum etwas unterstützt? Im Securitybereich steht Linux aber in Sachen Hardwareunterstützung und Features ziemlich weit im Hintergrund. Für sinnvolle Vergleiche muß man dann schonmal zu SE-Linux greifen.
In Sachen Entwicklung ist Linux auch hinter OpenBSD zurück. Es gibt beispielsweise keine regelmäßigen Codeaudits. Changelogs und Security-Listen kann man unter Linux eigentlich ganz vergessen.
Nicht, daß ich Linux schlecht machen will (ich bin auch kein OBSD-Nutzer), aber man muß hier schon differenzieren. Sicherlich unterstützt OpenBSD weniger. Und sicherlich unterstützt Linux weniger.
Fehler passieren, sogar solchen selbsternannten Gottheiten wie Theo.
:D
ja wieso, wie siehts dort denn aus? hast du konkrete daten?
von geradezu sensationeller Qualität.
Hmm, das ist ja ein klasse Vergleich: auf der einen Seiten verwende ich eine "übliche Fehlerzahl", auf der anderen Seite laß ich ein Programm laufen, welches (wie auch immer) nach Fehlern sucht, und ich verwende die Anzahl der *gefundenen* Fehler (welche natürlich kleiner der Anzahl der *vorhandenen* Fehler ist). Darüber hinaus geht man auf der sog. proprietären Software vom nicht veröffentlichten Produkt aus. Wen interessieren denn die Fehler darin ? Mal angenommen, der Hersteller der Software findet im Test *vor* Veröffentlichung des Produkts sämtliche Fehler im Code (was natürlich unrealistisch ist, klar, aber nehmen wir es doch mal an), dann können in der Testversion von mir aus tausende Fehler drin sein - solange ich die im *fertigen* Produkt nicht mehr sehe, ist mir das doch wurscht. Auch wundern mich die Zahlen etwas: wenn ich alleine auf Heise Online mal die Überschriften dieses Jahres durchschaue, finde ich wahrscheinlich schon fast so viele entdeckte (und nicht widersprochene !) Buffer Overflows, und da will eine speziell dafür "trainierte" Software in vier Jahren nicht mehr gefunden haben !?! Oder soll der Rest tatsächlich "unkritisch" sein und deswegen nicht beachtet worden sein (unkritische Pufferüberläufe im Kernel - gibt's sowas eigentlich überhaupt ? klingt irgendwie wie eine "unkritische Reifenbeschädigung" beim Auto).
Also, alles in allem denke ich, daß hier Äpfel mit Birnen verglichen werden. Zu welchem Zweck ? Um sich in der Linux-Gemeinde Freunde zu machen ? Dürfte wohl klappen. Um das eigene Test-Programm bekanntzumachen und zu vermarkten ? Könnte auch klappen. Aber sagt das über den Linux-Code aus ? Für mich eigentlich gar nix.
Merke, traue keiner Statistik ...
In diesem Sinne,
Carsten
Aber ansonsten finde ich auch die Formulierung "der üblichen Fehlerzahlen in unveröffentlichter proprietärer Software" (oder so ähnlich) etwas eigenartig, noch dazu wenn keine Angabe gemacht wird woher diese Zahl kommt (Schätzung ? Aufgrund welcher Tatsachen wird so geschätzt ?).
Die Studie wurde im Jahr 2000 gestartet, wir haben jetzt 2004 - da könnte man daraus ableiten, daß sich das ganze wohl über etwa vier Jahre erstreckte.
Was die Anzahl der Buffer Overflows angeht, das waren ja nicht mehr als 600 (das war die Summe *aller* Fehler), sondern 25, und soviel finde ich allemal bei Heise Online. ;-)
Carsten
Genau das wollte ich auch schon ein paar mal schreiben als ich die Beiträge von oben bis unten gelesen habe. Aber ganz unten kommt ja zum Glück dein Kommentar, dass genau das sagt.
Deshalb kann dieses "Testprogramm" wenn es in endlicher Zeit fertig sein will nur einer sehr kleinen subset des Kernels "simulieren". Aus dem Ergebnis kannst du aber absolut keine Schlüsse ziehen.
Wie gesagt wurde, die Programmkorektheit ist nicht entscheidbar. Wer sich damit näher auseinandersetzen will, dem sei ein gutes Buch zur theoretischen Informatik empfohlen. Stichworte: "Berechenbarkeitstheorie" und "Halteproblem"
das nicht, das solche Versuche zwecklos sind.
Im Übrigen könnte man die Korrektheit eines harten Echtzeit-Betriebssystems in _endlicher_ Zeit
entscheiden.
Was ist denn eine "übliche Fehleranzahl",daß was CyLab behauptet? Das ist die Behauptung einer! Institution, was ist daran "üblich"?
> . . . so ist der Code des aktuellen Linux-Kernels von geradezu sensationeller Qualität.
Also, das ist mal wieder so eine übliche hjb-Werbeaussage. Beim genauen Hinsehen nur lauwarme Luft.
> Bei proprietärer Software kommen während der Entwicklung - nicht im veröffentlichten
> Produkt - auf jeweils 1000 Zeilen Code bereits zwanzig bis dreißig Fehler, behauptet
> jedenfalls das CyLab Sustainable Computing Consortium an der Carnegie Mellon University.
Leere Behauptung! Beweise! Die man aber nur erbringen könnte, wenn man tausende von Applikationen untersucht. Ist das geschehen?
Dieses Projekt wurde offensichtlich mit dem Grundsatz gestartet, die sog. Überlegenheit von OpenSource-Software zu beweisen - und wenn ich etwas beweisen will, dann beweise ich es auch.
Fazit: Die Überschriften von 'hjb' werden der Bildzeitung immer ähnlicher!
Es liegt ganz einfach in der Natur von OpenSource, dass da mehr Fehler entdeckt werden, was natürlich nicht heist, dass alle OpenSourceprojekte super toll gecodet sind, nicht für jeden Shit interessieren sich kompetente Leute, aber der Linuxkernel ist ein super Beweis dafür, dass dort viele Augen viel finden und an dem Kernel arbeiten wirklich spitzen Leute.
Ich weis nicht wieviel Patches ich schon geschrieben habe, aber die sind nur zustande gekommen, weil der Fehler bei mir unter bestimmten Umständen aufgetreten ist, und da ich die Sourcen hatte konnte ich den Fehler finden, wäre das Zeugs Closed Source gewesen, dann könnte man ne Supportmeldung absetzen wo zu 99% nur Schund zurückkommt und es wird nie gefixt.
Linux fehlt es da oft an Planung und regelmäßigen Audits. Wenn ich auf den KML lese, daß der IDE-Code so heruntergekommen ist, daß nur noch zwei Menschen wirklich durchblicken, daß Maintainer deswegen ihre Arbeit niederlegen, dann frage ich mich, wie man dann eine sensationalle Qualität des Codes nachsagen kann. Das mag auf Module und Teile zutreffen, aber sicherlich nicht pauschal stimmen. Zumal es dafür auch zuviel Kritik aus den Ecken andere OSS-OS "hagelt" - wobei solche Kritik und Vergleiche positiv zu werten sind, jeder wird immer irgendwo etwas zu verbessern finden.
In Angesicht immer neuer Einführungen von Syscalls, im schnellen Wachstum von Features und der Komplexität, frage ich mich, ob da nicht einiges auf der Strecke bleibt oder geblieben ist. Die Einfachheit von Linux (und den Userlandtools) war einmal das Argument für Linux und gegen Windows. Solche Argumente mögen noch für viele Teile des Kernel zutreffen, aber sie nehmen ab. Im Userland ist das ohnehin für Mainstreamdistros ein längst überholtes Argument.
oh wie schlimm! der linux-code wurde hier aber mit code verglichen, der auf noch chaotischere weise entsteht, nämlich nach dem closed-source-modell bei kommerziellen firmen.
die studie bringt ja auch kein absolutes urteil (dass linux völlig sauber und fehlerfrei sei), sondern nur einen vergleich: linux ist besser als viele anderen. ist das denn so schwer auseinanderzuhalten?
> linux ist besser als viele anderen. ist das denn
> so schwer auseinanderzuhalten?
Nö, wieso? Habe ich das durcheinander gebracht? Allerdings würde ich diese Aussage der Studie nicht entnehmen. Ich kann da so spontan eigentlich gar nicht viel aussagekräftiges finden.
genau das ist linux ja. oder jedenfalls nahe dran ;-)
> Ich finde, man sollte sich besseren Code als Maßstab setzen, nicht schlechteren.
die linux-kernel-entwickler *nehmen* sich nicht den windows-code oder irgendsonstwas als massstab! eine arbeitsgruppe der uni stanford hat eine untersuchung gemacht und ist zu gewissen ergebnissen gekommen. das ist alles. sie haben auch nicht behauptet, dass es in der linux-entwicklung keinerlei probleme gebe, sondern sie haben sich ein bestimmtes kriterium genauer angeschaut. was ihr da nun alles hineininterpretiert hat mit den ergebnissen herzlich wenig zu tun.
ausserdem gibt es ja die "shared source" license.
Allo
Praktisch sagt dir jemand: "das programm stürzt hier unter diesen und jenen Umständen ab"... und man muss erstmal herausfinden, wo und warum der Fehler auftritt und sichergehen, dass der Fehler nicht irgendwelche anderen (schlimmeren) Fehler nach sich zieht.
zu bedenken ist aber, dass so natürlich nicht alle fehler gefunden werden können, und dass nicht alle so gefundenen fehler tatsächlich zu problemen führen müssen. es könnte theoretisch sein, dass man etliche fehler korrigiert hat, dass sich die stabilität des programms dadurch aber überhaupt nicht verbessert. was sich bessert ist aber die qualität des codes.
zur frage von allo: das tool ist nicht frei zugänglich. man kann es nicht einmal kaufen (wenn ich es recht verstanden habe). allerdings gibt es ähnliche tools, die auch routinemässig eingesetzt werden, aber nicht jedes tool findet die gleichen fehler.
es gab ja schon vor urzeiten das unix-tool lint, das gewisse code-schlampereien aufspürt.
> dass nicht alle so gefundenen fehler tatsächlich zu problemen führen müssen
wie man hier sieht http://linuxbugs.coverity.com/linuxbugs.htm sind 13 prozent der fehler "toter code" und weitere 4 prozent sind unbenutzte variablen -- beides fälle, die der funktionalität des codes keinen abbruch tun, wohl aber der wartbarkeit.
Ein Beispiel hierbei ist meine USB-Festplatte aus dem Hause TrekStor. Ich kann von dieser Platten alle Daten problemlos lesen. Wenn es aber ums Schreiben geht, gibts nen Kernelpanic. Linux stürzt dabei nicht ab, sei angemerkt. Aber die Platte ist dann vom Zugriff her tot und in der dmesg gibt es lauter lustige Oops-Fehler mit diversen lustigen Hex-Adressen. Ich habe im Internet gelesen, dass der eingesetzte Controller Mist sein soll. Aber das kann es ja nicht sein. Es ist zu einfach nur auf die Hardware zu verweisen und alle Schuld von sich zu weisen. Immerhin (und jetzt kommts mal wieder *g*) läuft die Festplatte mit den normalen Standard-USB-Speicher-Treibern unter WindowsXP auch. Dumm nur, dass ich XP nicht einsätze. Hier würde man sich doch etwas mehr Spielraum wünschen. Ich programmiere ja auch so, dass bei kleinen Abweichungen nicht gleich das ganze Programm abkackt.
Es gibt noch mehr solcher Probleme. Es kann doch auch nicht sein, dass mit einem neueren Kernel ein Computer nicht mehr geht. Wurde da etwa der Interrupt-Controller zu Tode verbessert?
Auch wenn die Programmierer beim Kernel wirklich tolle Arbeit leisten - Kritik sollte erlaubt sein
Weiter unten schreibst du, daß es nicht sein sollte, daß ein neuer Kernel den Rechner lahmlegt. Vielleicht hat ja jemand versucht, einen Treiber für einen "ungewöhnlichen" Interrupt-Controller zu implementieren. Wenn du selber programmierst, kennst du ja die Probleme, daß eine Änderung in A() manchmal auch ungewollte Auswirkungen in Z() hat.
cya, jens:wq