> ihr könnt ja mal googeln und schauen was vor eurem linux war.
Musste das jetzt sein? Niemand hat versucht, *BSD runterzumachen, im Gegenteil war das ein ziemlich lockerer und humorvoller Beitrag. Wir in der Open-Source-Community leben voneinander und miteinander, und ich schätze, wir alle wissen, dass der Referenzstack von FreeBSD kommt, da brauchen wir nicht erst zu googlen. Wenigstens zwischen BSDlern und Linuxern sollte es keinen Streit geben, wir alle hocken im selben Luxusliner.
Denke ich auch, alles was man so hoert deutet darauf hin dass die BSD-Stacks um einiges besser als der von Linux sind. Habe uebrigens seit Umstellung meines Servers von Linux auf FreeBSD eine deutlich schnellere Netzwerk-Performance als mit Linux. Bei gleicher Hardware.
Na interessant wäre es trotzdem. Hat jemand nen passenden Link?
Achso ich habe mich dort auf der Seite angemeldet da ich die Untersuchungsergebnisse gerne mal gesehen habe. Aber von der versprochenen Mail mit den Link zum Download ist bisher nichts zu sehen...
Letzthin stand im Linux-Magazin mal, dass bei einem Test wegen Optimierungen des Distributors diese Distri extrem schnellere Zugriffszeiten hatte als FreeBSD, mus aber nicht stimmen... Aber sicher ist auch hier vieles eine Frage der richtigen Einstellungen ...
Von catconfuser am Fr, 14. Februar 2003 um 07:34 #
Die Argumente, warum OpenSource (eine ausreichende Basis vorausgesetzt) bessere Ergebnisse erzielen kann sind ja (wie auch oben gesagt) altbekannt.
Zu dem Argument >Viele Entwickler sehen den Code der anderen Entwickler, wodurch viele Fehler entdeckt werden< frage mich nur immer eins: M$ beschäftigt tausende von Programmierern. Vollzeit. Was tun die denn alle die ganze Zeit, wenn da so oft so viel Schrott rauskommt?
Das soll jetzt kein plumper Pöbelversuch gegen M$ sein, ich verstehŽs wirklich nicht.
Jeder arbeitet an seinem eigenen Häufchen Code und schaut allenfals die Sachen an, die er direkt benötigt. Angeblich ist die Trennung bei MS so strikt, dass ganze Abteilungen nicht wissen, was andere Abteilungen im Detail tun. Aufgekomme ist dieses Gerücht be ider Entdeckung der NSA-Keys in Windows. Da war die Erklärung, wie man sowas hat reinschmuggeln können, ohne dass es jemandem auffält, nämlich genau die, dass die Abteilungen es generell hinnehmen, das von anderer Stelle "irdendwas" eingebaut wird.
Mag sein, dass das auch nur eine Verschwörungstheorie ist, aber Echelon war ja auch mal eine
Ich arbeite ja bei Der Firma, wir haben auch unmenge Code. Meinst Du ernsthaft, daß jemand die Zeit hat neben seiner Arbeit den Code von anderen zu kontrollieren. Ich bekomme mein Geld dafür, die Fehler in dem Coding unserer Abtelung zu finden, wenn der Fehler in anderem Code auftritt, dann schicke ich das Problem zu den Entwicklern.
Das Problem ist aber ein anderes, bei OS werben ja die meisten Entwickler mit ihrem Namen dafür, daß das Coding von ihnen stammt, da sorgt man auch dafür, das die Qualität stimmt. Aber das Beispiel mit den 5 Fehlern, die alle gefixt haben zeigt, es gibt auch closed source, die qualitativ hochwertig ist.
Wer redet von kontrollieren? Ich weiß wie die Softwareentwicklung in der Größenordnung von ca. 100 Entwicklern aussieht. Natürlich macht kein Mensch Codereciew in sämtlichem Files, aber man kommt da eben auch _nicht_ drumrum, über den Tellerrand zu schauen und sich das Gesamtsystem statt nur die direkt genutzten Schnittstellen anzusehen, wenn es was werden soll. Und genau das ist wohl bei M$ Usus: die Leute von Informationen abschotten, die sie (scheinbar) nicht zu interessieren haben. Das dürfte auch ein Grund dafür sein, warum noch kein M$-Entwickler über die wirklichen Strategien ausgepackt hat: Die kriegen eben nur zu hören, welche Details sie zu implementieren haben, wissen aber nicht, für welches größere Ganze das gut ist.
>Was tun die denn alle die ganze Zeit, wenn da so oft so viel Schrott rauskommt?
Mit VIM rumspielen Einer unserer Board Mitglieder arbeitet bei MS und hat erzaehlt das da sehr viele C/C++ Programmierer VIM bevorzugen. Deswegen wurde auch von den MS Entwickler an den Spendenfond des VIM Entwicklers gespendet (siehe vim.org). Zu der Frage ob die denn bei MS auch Linux Server laufen haben kam leider keine Antwort
Eine Sache des Softwareengineering. Es gibt in der Tat Mittel und Wege sauber qualitativ hochwertige Software zu produzieren. Aber bei M$ werden die nicht wirklich benutzt. Unser SE-Prof meinte mal, dass M$-Mitarbeiter zugegeben hätten, dass es bei M$ keine Spezifikation gibt. Was willst du da erwarten...
Von Kai Lahmann am Fr, 14. Februar 2003 um 17:14 #
Da müssen diverse Deppen zwischen sein! Es fällt immer wieder auf, dass zwar alles ganz toll integriert ist, aber die meisten Teile für sich genommen unglaublicher Mist sind. Vermutlich gibt es da ein paar super tolle Obermufdis, die die Kommunikation zwischen den einzelnen Teilen überwachen, wie aber ein Teil jeweils für sich arbeitet, ist denen egal.
Von Benjamin B. am Mo, 17. Februar 2003 um 00:09 #
Das dürfte IMHO korrekt sein. Die relativ strikte Trennung der Abteilungen und die Hierarchie tragen dazu bei, daß der eine nicht weiß, daß er an einem Programm mitschreibt, für das der andere grad völligen Mist einprogrammiert.
Und welche Fehler geflickt werden, hängt bei vielen kommerziellen Produkten letztenendes davon ab, ob die *zahlende* Kundschaft das überhaupt interessiert, es also wirtschaftlich genug ist.
Trotzdem ist es natürlich gut zu sehen, daß es auch unter Kommerziellen Anbietern noch Qualität gibt. Zwar nur vereinzelt, aber immerhin.
so toll open source auch ist, es ist wirklich sehr schade daß man realistisch gesehen mit kommerzieller os software kaum gewinn machen kann. ausnahmen bestätigen die regel ...
so toll Äpfel auch sind, es ist wirklich sehr schade daß man realistisch gesehen mit Äpfeln nicht gut Kirschen essen ist. ausnahmen bestätigen die regel ...
Von philipp naseweiss am Fr, 14. Februar 2003 um 11:09 #
Das freut zu hören, das der Linux TCP/IP Stack so gut ist. Seit dem 2.4 Kernel dürfte er FreeBSD ebenbürtig vielleicht sogar besser sein. Ist doch schön zu Wissen mit was für Qualitativ hochwertiger Software unser Tux bestückt ist
Hi, Stabilität ist für mich die wichtigste Eigenschaft von Software, aber an zweiter Stelle steht die Performance. Werden in dem Test irgendwelche Aussagen gemacht, welche TCP/IP Implementierung die schnellste war?
Leider nein. Noch interesanter wäre gewesen, welcher Stack am besten mit den Standards konform ist.
So aber ist die Studie eher enttäuschend ausgefallen. Es gibt sicher Stellen im Kernel-Code, die so eine Analyse besser brauchen könnten, besonders diverse Treiber.
>TCP/IP ist das Protokoll des Internets und damit wohl derzeit das wichtigste Protokoll überhaupt. Im TCP/IP-Stack von Linux, der in Kernel 2.4.19 81.852 Zeilen Code umfaßt, fand Reasoning ganze 8 »Defekte«
Es gibt beim Programmieren eine Faustregel die besagt, daß auf etwa 1000 Zeilen 1 Fehler kommt. Diesen "Idealzustand" erreicht aber kaum ein Programm. In der Regel sind es mehr.
Die Behauptung, daß es auf rund 80.000 Zeilen Code nur 8 Fehler gäbe, würde bedeuten, nur 1 Fehler auf 10.000 Zeilen. - Das wäre geradezu nobelpreis verdächtig! So etwas gibt es nicht!
Was diese 'Reasoning Inc' da "festgestellt" haben will ist entweder gelogen, oder das sind Idioten!
>Die Array-Zugriffe seien keine echten Fehler, ...
Ach, nein! Das sind nur halbe Fehler, so wie es auch nur 'halbe Schwangerschaften' gibt.
Diese Studie ist ein Haufen Mist! Die ist genau so glaubhaft, wie die Behauptung, das sich die Sonne um die Erde drehen würde.
Ich frag mich, was du willst, selbst in deinem Zitat steht es drin: "der in Kernel 2.4.19 81.852 Zeilen Code umfaßt, fand Reasoning ganze 8 »Defekte«"
Niemand habt behauptet, dass es nur 8 Fehler gibt, sondern dass nur 8 gefunden wurden. Wenn man die Anzahl der Fehler eines so grossen Projektes so einfach genau bestimmen könnte, würden wohl bald keine mehr da sein
Und wenn ich nun bei gleichem Zeitaufwand 8 oder 80 Fehler in 81.852 Zeilen finde, kann ich schon eine Aussage über die Qualität des Codes machen.
gehen wir mal zu den nicht initialisierten variablen; wenn ich denen irgendwann zur laufzeit einen wert zuweise, ist es total egal, ob sie initilisert wurden oder nicht....
und jetzt lässt du so ein blödsinn vom stapel, als hättest du den code gelesen .... dann such den fehler und dokumentiere ihn HIER FÜR ALL und schick in gleichzeitig an kernel.org .... ich glaube, dann wäre allen geholfen ansonsten ..
>Die Array-Zugriffe seien keine echten Fehler, ...
Heißt im Klartext, daß kein fehlerhafter Zugriff erfolgt, lediglich die Tools von Reasoning Inc. sind nicht in der Lage, das zu beweisen. Die Entwickler dagegen wissen etwas mehr über den Code als ein beschränktes Tool.
WinNT?
Seitdem kann man mit Windows sogar begrenzt ins Netz gehen
Zudem hat Linux auch Teile von BSD ausgeborgt.
Schön zu sehen am Linux Quellcode. Einfach mal nach BSD suchen
und man findet etliche Stellen.
mfg chuck
Musste das jetzt sein? Niemand hat versucht, *BSD runterzumachen, im Gegenteil war das ein ziemlich lockerer und humorvoller Beitrag.
Wir in der Open-Source-Community leben voneinander und miteinander, und ich schätze, wir alle wissen, dass der Referenzstack von FreeBSD kommt, da brauchen wir nicht erst zu googlen.
Wenigstens zwischen BSDlern und Linuxern sollte es keinen Streit geben, wir alle hocken im selben Luxusliner.
> Wenigstens zwischen BSDlern und Linuxern sollte es keinen Streit geben, wir alle hocken im selben Luxusliner.
Aber was meinst du mit Luxusliner?
Ich würde beide eher als funktional ausgestattete Frachtschiffe bezeichnen
Grüße
Sturmkind
Aber bitte jetzt nicht flamen hier.
Achso ich habe mich dort auf der Seite angemeldet da ich die Untersuchungsergebnisse gerne mal gesehen habe. Aber von der versprochenen Mail mit den Link zum Download ist bisher nichts zu sehen...
Grüße
Sturmkind
hier ist auch noch nix da
Na gleich mal durchlesen bevor ich zur Arbeit muß
Grüße
Sturmkind
Hat jemand Quellen???
)
Letzthin stand im Linux-Magazin mal, dass bei einem Test wegen Optimierungen des Distributors diese Distri extrem schnellere Zugriffszeiten hatte als FreeBSD, mus aber nicht stimmen...
Aber sicher ist auch hier vieles eine Frage der richtigen Einstellungen ...
Zu dem Argument >Viele Entwickler sehen den Code der anderen Entwickler, wodurch viele Fehler entdeckt werden< frage mich nur immer eins: M$ beschäftigt tausende von Programmierern. Vollzeit. Was tun die denn alle die ganze Zeit, wenn da so oft so viel Schrott rauskommt?
Das soll jetzt kein plumper Pöbelversuch gegen M$ sein, ich verstehŽs wirklich nicht.
> Was tun die denn alle die ganze Zeit, wenn da so oft so viel Schrott rauskommt?
Vielleicht bringen sie ja der Bueroklammer neue Kunststueckchen bei.
SCNR
Marc
Mag sein, dass das auch nur eine Verschwörungstheorie ist, aber Echelon war ja auch mal eine
Das Problem ist aber ein anderes, bei OS werben ja die meisten Entwickler mit ihrem Namen dafür, daß das Coding von ihnen stammt, da sorgt man auch dafür, das die Qualität stimmt. Aber das Beispiel mit den 5 Fehlern, die alle gefixt haben zeigt, es gibt auch closed source, die qualitativ hochwertig ist.
Mit VIM rumspielen
Einer unserer Board Mitglieder arbeitet bei MS und hat erzaehlt das da sehr viele C/C++ Programmierer VIM bevorzugen. Deswegen wurde auch von den MS Entwickler an den Spendenfond des VIM Entwicklers gespendet (siehe vim.org).
Zu der Frage ob die denn bei MS auch Linux Server laufen haben kam leider keine Antwort
wer sich zuerst bewegt hat verloren!
MfG,
Eric_Fish
Eine Sache des Softwareengineering. Es gibt in der Tat Mittel und Wege sauber qualitativ hochwertige Software zu produzieren. Aber bei M$ werden die nicht wirklich benutzt. Unser SE-Prof meinte mal, dass M$-Mitarbeiter zugegeben hätten, dass es bei M$ keine Spezifikation gibt. Was willst du da erwarten...
Schönen Tag noch...
ihminen
Und welche Fehler geflickt werden, hängt bei vielen kommerziellen Produkten letztenendes davon ab, ob die *zahlende* Kundschaft das überhaupt interessiert, es also wirtschaftlich genug ist.
Trotzdem ist es natürlich gut zu sehen, daß es auch unter Kommerziellen Anbietern noch Qualität gibt. Zwar nur vereinzelt, aber immerhin.
Stabilität ist für mich die wichtigste Eigenschaft von Software, aber an zweiter Stelle steht die Performance. Werden in dem Test irgendwelche Aussagen gemacht, welche TCP/IP Implementierung die schnellste war?
Gruß,
Marc
So aber ist die Studie eher enttäuschend ausgefallen. Es gibt sicher Stellen im Kernel-Code, die so eine Analyse besser brauchen könnten, besonders diverse Treiber.
Es gibt beim Programmieren eine Faustregel die besagt, daß auf etwa 1000 Zeilen 1 Fehler kommt. Diesen "Idealzustand" erreicht aber kaum ein Programm. In der Regel sind es mehr.
Die Behauptung, daß es auf rund 80.000 Zeilen Code nur 8 Fehler gäbe, würde bedeuten, nur 1 Fehler auf 10.000 Zeilen. - Das wäre geradezu nobelpreis verdächtig!
So etwas gibt es nicht!
Was diese 'Reasoning Inc' da "festgestellt" haben will ist entweder gelogen, oder das sind Idioten!
>Die Array-Zugriffe seien keine echten Fehler, ...
Ach, nein! Das sind nur halbe Fehler, so wie es auch nur 'halbe Schwangerschaften' gibt.
Diese Studie ist ein Haufen Mist! Die ist genau so glaubhaft, wie die Behauptung, das sich die Sonne um die Erde drehen würde.
Niemand habt behauptet, dass es nur 8 Fehler gibt, sondern dass nur 8 gefunden wurden. Wenn man die Anzahl der Fehler eines so grossen Projektes so einfach genau bestimmen könnte, würden wohl bald keine mehr da sein
Und wenn ich nun bei gleichem Zeitaufwand 8 oder 80 Fehler in 81.852 Zeilen finde, kann ich schon eine Aussage über die Qualität des Codes machen.
iGEL
wenn ich denen irgendwann zur laufzeit einen wert zuweise, ist es total egal, ob sie initilisert wurden oder nicht....
und jetzt lässt du so ein blödsinn vom stapel, als hättest du den code gelesen .... dann such den fehler und dokumentiere ihn HIER FÜR ALL und schick in gleichzeitig an kernel.org ....
ich glaube, dann wäre allen geholfen ansonsten ..
...erst denken dann schreiben
thx
>>Die Array-Zugriffe seien keine echten Fehler, ...
>Ach, nein! Das sind nur halbe Fehler, so wie es auch nur 'halbe Schwangerschaften' gibt.
der 1. absatz war nur ein beispiel
Heißt im Klartext, daß kein fehlerhafter Zugriff erfolgt, lediglich die Tools von Reasoning Inc. sind nicht in der Lage, das zu beweisen. Die Entwickler dagegen wissen etwas mehr über den Code als ein beschränktes Tool.
fbe