パスワードを忘れた？ アカウント作成
Close
9343 story

Linuxカーネルは商用ソフトよりバグが少ない 162

ストーリー by yoosee
多くの目フィルター 部門より

otk曰く、"CNET日本語版の記事より。米国のコード分析会社Coverityは、同社の開発するコード分析ツールを用いて、Linuxカーネルのソースコード約570万行に含まれるバグの数を調査した。その結果、985箇所のバグを発見したという（調査結果のサマリ）。しかし、カーネギーメロン大学のデータによると、同等のコード量をもつ商用プログラムには通常5000以上の欠陥が存在するとされており、Coverity社のCEO、Seth Hallem氏は「バグ検出密度という点では、Linuxは非常に良いシステムであるといえる」、また「オープンソースという開発手法が安全なOSを生み出していることが分かる」と結論付けているそうだ。"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

Linuxカーネルは商用ソフトよりバグが少ない More

  • Bug探しツールのBug探し (スコア:5, すばらしい洞察)

    by kaiton (24046) on 2004年12月15日 9時33分 (#666183) ホームページ 日記
    「同社の開発するコード分析ツール」にはまったくBugはないんだろうか？
    そもそもがなんだか先に結果ありきのような気がするのだが。

  • fix (スコア:4, おもしろおかしい)

    by Anonymous Coward on 2004年12月15日 9時24分 (#666177)
    見つけたついでに直してあげればいいのに。

    • Re:fix (スコア:3, すばらしい洞察)

      by ryokiwind (22763) on 2004年12月15日 11時19分 (#666252)
      マジレスすると、バグを修正する場合、
      そのバグ修正における影響範囲を考慮せねばならず、
      単純にバグ修正しました→OKで終わらないから手をつけられないのだと思います。
      ひとつのバグ修正するにしても、
      コード検証し、バグ修正＆影響範囲調査、
      その上で影響範囲分テスト、でリリースとなります。
      それを考えるとおいそれと簡単に直せないでしょう。

      ぱっとみ単純に見えても、影響範囲多大なことはよくある話ですから。
      シェア
      親コメント
  • 日本語記事ではカットされていますが、元の英文記事 [com.com]（の後ろのほう）には、カーネギーメロン大学の調査データについて詳細な記述があります。
    概要を書くと、
    　・以下は、公の報告書（National Cybersecurity Partnership's Working Group on the Software Lifecycleが4月に発表したリポート）に基づく。なお、そのデータはカーネギー大のソフトウェア工学研究所の分析を引用している
    　・一般的に、プロプライエタリなソフトウェアは、1,000行のコードあたり1～7つの欠陥（バグ）を持っている
    　・これを570万行のコードに換算すると、「ざっと5,700～40,000個のバグ」に相当する
    　……ということで、「985個のバグは少ない」と結論付けているようです。
    　＃ここはカットしないでほしかった＞CNET日本

  • 5000以上の根拠はなんだ？ (スコア:2, おもしろおかしい)

    by Fuyuki (221) on 2004年12月15日 9時30分 (#666181)
    >同等のコード量をもつ商用プログラムには通常5000以上の欠陥が存在するとされており、
    まさか、Windwosが基準とか言うことはないよな。
    --
    # 数学は科学の女王にして奴隷

  • コード分析方法 (スコア:2, 興味深い)

    by micangel (24043) on 2004年12月15日 9時36分 (#666184)
    で、Coverityとやらのコード分析ツールとカーネギーメロン大学が
    調べた方法は同等のものなの？

    Coverityのコード分析ツールがろくにバグを抽出出来ない欠陥品な
    だけの可能性はないの？

    • Re:コード分析方法 (スコア:2, 参考になる)

      by boo (899) on 2004年12月15日 9時57分 (#666200) 日記
      このコード分析ツールがどういうものなのか Coverityのページを見てもイマイチはっきりいしないんだけど、
      どうやら静的なソースコード検査ツールのようですね。

      日本の会社でも何社か似たようなツールを出してるんで、誰かこれらの会社に声かけて、
      ツール対決でもけしかければ面白いんじゃないかなぁ
      --
      あぁ、「ン」が消えてるんですよ。「ビーフン・カレー」ね。
      シェア
      親コメント

      • Re:コード分析方法 (スコア:1)

        by parsley (5772) on 2004年12月15日 14時28分 (#666344) 日記
        >どうやら静的なソースコード検査ツールのようですね。

        動的なソースコード検査ツールだと…

        ガクガクブルブル？

        # 週なかで疲れて来たのでID
        --
        Copyright (c) 2001-2014 Parsley, All rights reserved.
        シェア
        親コメント
    • Coverityのコード分析ツールの信頼性についてはその気になれば第三者が検証できるのでさほど問題ではないと思います。問題はどうやって調べたのか、分析ツールを使ったものかすら不明な「カーネギーメロン大学から提供されたデータ」のほうで。

      （正確かはともかく）根拠のはっきりしたデータと、どうやって調べたかすら分からないデータを同列に扱われてもなあ、という感じです。普通にプレゼン資料とかで使ったら「（後者の）根拠は？」とか突っ込まれて終わりだと思うのですが。
      よくても参考以上にはならないでしょう。雑談ネタにはいいですがオープンソースの優位性とか真面目に語るための論拠としては脆弱ではないかと。

      Windowsのソースコードが開示されている政府機関等に、同じ条件で分析ツールかけてみてもらいたいですねえ。
      --

      -May the sakura-cards be with you.-
      シェア
      親コメント
      • プロプラエタリな開発手法と、オープンソースとのコード品質の差を検証するなら、ソースコードを公開した直後のInterbaseと、その後のFireBirdを比較するとか考えられますね。
        カーネギーメロン大学の研究も、そんなにうさんくさいものではないと思いますが、テスト自体の「バグ」の定義自体も違うでしょうし、そのまま比較することはできないと思います。
        なんとなく広告のための話題作りのような気が・・・。
        シェア
        親コメント

  • それでもバグは存在すると考えよう (スコア:2, すばらしい洞察)

    by abilitei (1889) on 2004年12月15日 9時38分 (#666185)
    他のソフトなんて関係ない。より安全で確実な物を目指すために努力することが大事だ。
    コード分析会社が調査するだけで1000近いバグを発見できたのだから問題ありと考えたほうが良いだろう。

  • 多くの目にさらせば、バグは枯れる? (スコア:2, 参考になる)

    by k3m (12461) on 2004年12月15日 12時37分 (#666292) 日記
    ソフトウエア開発 55の真実と10のウソ [amazon.co.jp] には

    嘘8: 多くの目にさらせば、バグは枯れる

    と書かれていて、オープンソースのバグが少ないという主張に対して、反論を述べています。この本自体も読む価値はあると思います。

  • 比較対照は (スコア:1, 興味深い)

    by Anonymous Coward on 2004年12月15日 9時42分 (#666190)
    商用プログラムよりも、他のオープンソースソフトウェアにした方が面白いと思う。
    OpenBSDとかdjbwareとか…

  • バグ要因 (スコア:1, おもしろおかしい)

    by Anonymous Coward on 2004年12月15日 10時07分 (#666206)
    検出結果のサマリ読んで、やっぱ一番多いバグ要因は、

    　 ∧＿∧
    　（　´∀｀）＜ ぬるぽ

    なんだなと思った、ある冬の寒い朝。

  • んで結論は (スコア:1, すばらしい洞察)

    by Anonymous Coward on 2004年12月15日 10時36分 (#666225)
    ＞Converityは、CおよびC++で書かれたソフトウェアの欠陥を検出するツールを開発する企業。

    我が社の欠陥検出ツールをぜひご利用ください。

    なわけ？

  • 仕様 (スコア:1, すばらしい洞察)

    by lunatic_sparc (15416) on 2004年12月15日 10時56分 (#666241)
    ツールで解析できるレイヤとは異なるが、「仕様ですから」直らない問題はオープンなソースであれば少ないし、減ることも可能ですね。

    Linux でもディスク I/O まわりがアレだったりするのはどうだろう、とか思わなくもないですが、3つも（3つ?4つ）もメモリ使用のインタフェースがあって、ちゃんとつかってもリークしまくりってものよりはましだってことは確かですねぇ。

    ＃ちゃんとディスクに書いてから戻ってきてくれるバージョンの Linux がほしい。

  • とりあえず分かった事 (スコア:1, おもしろおかしい)

    by Anonymous Coward on 2004年12月15日 12時10分 (#666281)
    5,700,000 / 5,000 = 1,140

    1,000行以下でコーディングすれば、通常はバグが０になるのですね！

  • ホントにバグ? (スコア:1)

    by Elbereth (17793) on 2004年12月15日 12時18分 (#666284)
    ホントのバグかどうかは確認してからにした方がいいと思うんですけどねー。
    検出方法とその調査の結果ソースのどの部分にバグがあるかという
    詳細な結果見ないと一概に信用はできんでしょ。
    みんなおめでたいなぁ。

    • Re:ホントにバグ? (スコア:1, すばらしい洞察)

      by Anonymous Coward on 2004年12月15日 18時20分 (#666437)
      同意

      この手のバグ検出ツールというのは限界があります。
      たとえばハードウェアのドライバなどで、ハードウェアからは仕様上0～3の値（下位2bitのみ変化し、上位ビットは必ず0）しか返らない場合、4以上の値があり得ない事を前提としてコードを書いたらツールでArray BoundsとかNULL PointerとかUninitializedと検出されたとかね。
      コードに現れない制限というのは、たいていこの手のツールではエラーとして報告されます。

      もちろんハード側の仕様が変更されればバグとして現出し得るという意味で「バグ」と言えない事も無いかもしれませんが、いかなる仕様変更に対しても動作するようにというのはムチャな話だし、厳密にチェックして仕様が変更されたら全てエラー終了してしまうようになると、下位互換性のある仕様変更でもエラーになってしまったりして「下位互換性があるハードウェアなのに動作しないというバグ」になります。

      この辺りをバグとするかしないかというのはツールによっても違ってきますので、精査もせずに違うツールの結果の数字だけを多い少ないと言っても仕方ないですね。

      シェア
      親コメント

  • バスタブ曲線ならぬ・・・ (スコア:1, 興味深い)

    by Anonymous Coward on 2004年12月15日 12時20分 (#666285)
    オープンソースになることによって、潜在的バグ数、顕在化するバグ数、修正されるバグ数の推移を時間軸グラフを描くと面白いかもしれませんね。バスタブ曲線にはならないと思いますが、どんな曲線になるんでしょう？

    オープンソース化直後は顕在化するバグが大量にでてきて大変そうだ。
typodupeerror

ナニゲにアレゲなのは、ナニゲなアレゲ -- アレゲ研究家