アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
計算機科学者とは、壊れていないものを修理する人々のことである
マイクロソフトに学ぶリリース日の守り方 (スコア:3, おもしろおかしい)
Re:マイクロソフトに学ぶリリース日の守り方 (スコア:1)
Re:マイクロソフトに学ぶリリース日の守り方 (スコア:2, おもしろおかしい)
Windows Vistaなら2006年の30月位。
#もう一ひねり欲しいが、疲れてるので、これ位で
---------+---------+----------+
年をとるのは素敵なことです。
Re:マイクロソフトに学ぶリリース日の守り方 (スコア:1, おもしろおかしい)
しかし出荷した製品はセキュリティホールの嵐。
対症療法でパッチを出していればユーザーは「セキュリティの重要性を
ユーザーに教えてくれた」と喜ぶ。
そんなプログラマに私もなりたいけど絶対無理だorz
Re:マイクロソフトに学ぶリリース日の守り方 (スコア:0)
Re:マイクロソフトに学ぶリリース日の守り方 (スコア:1)
Re:マイクロソフトに学ぶリリース日の守り方 (スコア:1, 興味深い)
バグを取り切らずに、さっさとリリースしている。つまり品質と
時間のトレードオフでは時間の方を優先しているってことじゃない
でしょうか。ソフト屋なら誰でも知ってると思いますが、そうでも
しない限り、ああいう風にきっちり半年おきには出せないと思います。
あと、大規模な変更が必要な開発作業をそもそもやってないというのも
理由の一つかもしれません。UBC が実装されてなくて、しかも pthread
ライブラリにカーネルサポートがないフリー UNIX って、OpenBSD ぐらい
ですよね。
Re:マイクロソフトに学ぶリリース日の守り方 (スコア:2, 参考になる)
OpenBSDの状況は具体的には知りませんが、傍から見ていて、おそらく↑の説明の逆じゃないかという気がしますけどね。新機能であれ、具体的なパッチであれ、次のリリース予定までに取りきれないバグが入りそうなものは焦って入れたりせず、ちゃんと導入に優先順位を付けて作業しているのでしょう。そうすれば、「怪しいコードが入ってくるケースがそれほど多くない->バグ発生率が極端に下がる->時間守れる」となりそうなもんですよね。
...とか書いちゃうと単純な話のようですが、OpenBSDのような立場で「他のFree UNIXには標準で入ってて、とっても便利なhogehoge機能を入れる」という誘惑に負けないのは、それはそれで一つの才能というか能力だと思いますね。それと、上記のように機能やコードの取捨する際の見極めの才能が求められます。
最近ではLinuxも「バグフィックス以外のパッチについては受付期間が極端に短くなったorする予定」とかいう話らしいですし、FreeBSDも(5系でドツボになって以降は怪しいけど)stableブランチからのリリース日程は(変なMFCとか入ってこない限り)ワリと守られてた気がします。(FreeBSDのcurrentブランチからの初期リリースは、その性質上、そもそも大幅に遅れても当然としか思えません)
Re:マイクロソフトに学ぶリリース日の守り方 (スコア:0)
> 明の逆じゃないかという気がしますけどね。新機能であれ、具体的なパッチで
> あれ、次のリリース予定までに取りきれないバグが入りそうなものは焦って入
> れたりせず、ちゃんと導入に優先順位を付けて作業しているのでしょう。そう
> すれば、「怪しいコードが入ってくるケースがそれほど多くない->バグ発生率
> が極端に下がる->時間守れる」となりそうなもんですよね。
scalability benchmark
http://bulk.fefe.de/scalability/
の時の結果を見ると、そういうわけではないようですよ。
Re:マイクロソフトに学ぶリリース日の守り方 (スコア:1)
変更規模については、その例が正しいのかどうか私にはわかりません。言えることは、彼らの目指しているものは他と全く違うらしい、ということですか。パフォーマンスのベンチマークを取られた際にも言っていたと思いますが、とにかくセキュアするために、そのために開発しているようなので。