アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア
バグの年齢とは? (スコア:5, 興味深い)
1.良く使われるプログラムだが、全体にたいした影響がない部分だった。
2.あまり多く使われないプログラムだった。
3.そもそもメインテナーがいなかった。
まぁ、他にも理由はあるでしょうが、「1.」はかなり多いのではないかと。
つまり、放置しておいても問題ない、というレベルのものであったとすると、この「バグとり」の作業は、効率が悪い作業、ということにはならないか?
Re:バグの年齢とは? (スコア:5, 興味深い)
今回の件はたいして影響のないものでしたが、
そういう、かつて問題なかった部分が
64 ビットのときとかメモリが大きいときとか
新たに問題になる場面が増えてるわけですよね。
すると心理的にも (「だってずっと大丈夫だったもん」)
技術的にも(「再現しません。そのメモリ安物じゃね?」)
見付けにくいので、部門名のとおり
バグのパターンで叩いたり、デバグ技術の進歩で潰したり
する必要が出てきます。事前に。
今回の大切な点は、OpenBSD "otto" malloc の意地の悪さ
(パフォーマンス重視のシステムでは考えられない実装かも)
によって実際にバグが取れた (しかも 33 年間も
気付かれていなかったものが) という点であり、
それが影響の大きいものかどうかではないと思います。
まさしく proactive security の問題なのです。
Re:バグの年齢とは? (スコア:5, すばらしい洞察)
Re:バグの年齢とは? (スコア:4, 興味深い)
人生は七転び八起き、一日は早寝早起き
Re:バグの年齢とは? (スコア:3, すばらしい洞察)
だって、自分のところでちゃんと動いていればそれで十分って人がほとんどなんだから。
だからこそ「目玉を増やす」ことは重要なんですよ。
Re: (スコア:0)
つまり「テスト担当者が一人だけ」なんてな企業は一番危険だと。
で、テスト担当者を増やせというよりは、
「ドッグフードを食え」のほうが
どう考えても人数を多く確保できるので、お勧めです。
特に小さい企業ではね。
#MSも馬鹿にならんな。
Re:バグの年齢とは? (スコア:3, すばらしい洞察)
あそこは顧客に押し付けてるよ。
Re:バグの年齢とは? (スコア:1)
MSは、「version 3になるまで手を出すな」が、はるか昔から定着していますが、Appleの製品は、未だに、出たと同時に跳び付く奴らばかり
# 自虐的だけどid