パスワードを忘れた? アカウント作成
7174 story

OpenBSD開発者Theo de Raadt@本家 31

ストーリー by Oliver
fork()を恐れずに 部門より

yh 曰く、 "「スラッシュドットはLinuxの話題に偏りがちなので、BSDも」というお声をいただいたので、以下の通り、本家掲載のOpenBSD開発者Theo de Raadt氏のインタビューを翻訳してみました。しかしながら、如何せんちょっと古い記事なので、お詳しい方は、事情が変わっているところなど、コメントでご教示ください。
さて、いつもの通り、たくさんの方々のご協力で翻訳が仕上がりましたことを感謝いたします。"

1) コード監査についての書籍は?
LizardKingによる

あなた、もしくは他のOpenBSD開発者の方が(あるいは共著とか)セキュアでバグフリーなコード作成と監査についての書籍を書くつもりはありますか?ほとんどのプログラミングの本には教育目的のサンプルコードが載っています。ほとんどの場合、そんなコードはセキュアなコードのあるべき形とは正反対に、ただ動くだけのもので、多くのプログラマの知識に欠陥を残していきます。コードの監査やコーディング時にセキュリティ上の落し穴を回避する方法についての本はあなたがたの生活を楽にするでしょう――OpenBSD用に監査するコードの量を減らし、素敵な新機能に集中する時間を増やすという形でも!

テオ君:

提案してくれた2つの話題にはたぶん隔たりがある。一つは、原作者がセキュアにコードを書く方法としての、セキュアなコーディング。もう一つは、監査、つまり部外者(あるいは関係者のうち誰か)が後になってコードに残っているごみくちゃをきれいにしようとする過程。問題の一部はたぶん、この2つの間に大きな違いがあるということだ。でも結局、そんな話題について扱った本では、徹頭徹尾、2パラグラフ毎に、同じことをくり返し書く必要があるだろう:
いまコーディングしているインターフェイスを理解しろ!
いまコーディングしているインターフェイスを理解しろ! と。
俺達がソース・ツリーから監査であぶり出したほとんどのセキュリティ上の問題(あるいはただのバグも)はそこから来ている。問題となったコードを書いたプログラマは不注意なのろまで、自分が使っているインターフェイスに注意を払わなかったのだ。ソース・ツリーのそこらじゅうから繰り返し同じ種類のバグが出て来るという現実から俺達は、ほとんどのプログラマが(間違った)用例でコーディングを学んだのだということを知った。堅固なシステムを作るには「動くんだからいいじゃん」という土台で取り組んではいけない。にもかかわらず、何度も何度も、ほとんどの人々がそういうやりかたをするのを目にしてきた。連中は良いソフトウェアには関心がなく、「仕様通り動く」ソフトウェアにしか興味がない。

だからプログラマ達はそんな失敗をし続けられるのだ。そんなわけで、俺は単に悪魔が潜んでいる場所を詳細に教えるだけの本を書くことにはそんなに興味を持てない。今になってもその場所を知らないのなら、他の仕事(きっと引き起こすであろう損害が小さいやつ)を探すべきだ。

2) それ以外もセキュアに
squiggleslashによる

OpenBSDは「独創的」なセキュリティと、組み込まれたツール群がありうべき形の中で最もセキュアであるということについて、なるべくして好評です。しかし、portsシステムはセキュアなアプローチが現在制限されている例でしょう――OpenBSDをインストールして、INN(InterNetNews: http://www.isc.org/products/INN/)のようなポピュラーなサードパーティのソフトを使う場合、INN(あるいは、そういうサードパーティのソフト)を監査するのはBSDの領域から外れるので、そのていどのセキュリティにしかなりえません。

聞きたいのは、OpenBSDチームとして「セキュアなports」ツリー、もしくは何か同様のシステム、を作るにはどうしたらいいか調べるように依頼をされたことがあるかどうかです。そうすることで、OpenBSDのようにセキュアなプラットフォームを運用したいと考えている人々がプラットフォームと同様に多くのアプリケーションに信頼を寄せることが確かなものとなるでしょう。

テオ君:

俺達は、およそ300MBほどになったメインソースツリーで新しいアイディアについて調べたりするのでもう手一杯だね。他にも、ちょっと前に、あるコンポーネントについてXFree86とちょっと関わったりした。これ以上に他のコンポーネントを監査するなんてちょっと非現実的だね。問題を困難にしているのは、コードの分量そのものだけでなく、他にもあるね。いろんな理由で、こういう外部パッケージのメンテナとのコミュニケーションが困難だったりするし。人によっては、俺達がLinuxって言わないからって聞く耳を持たなかったりするんだよ。移植されてくるソフトウェアパッケージの中には、でかすぎて、標準的なシステムとしての品質から本質的に程遠いものもある。

でも一番大事なことなんだが、俺達だって人間で、楽しく人生過ごそうとしているし、いつもいつも心がはやってて吐き気がするようなサイテーなプログラマのゴミに、動かさなければそれで済むのに、突然800時間もムダにするようなことはない。

俺達の監査者がコードを見て、「おや、こいつぁひどい」って言って使うのを避けてしまうということはしょっちゅうあると思う。このやり方が気分のいいものじゃないだろうというのは分かっているが、んじゃ、なんて言ったらいいんだい……

3) OpenBSD,セキュリティ,その他
jdによる

SGIのB1コードのリリースや、多くのUNIXがケーパビリティ、ACL(Access Control List[アクセス制御リスト])等々によってその内容物をセキュアにしようとする試みがありますが、OpenBSDでは、資源制御の課題にどう取り組んでいるのでしょうか?

余談ですが、OpenBSDが分散型カーネル(distributed kernel)の方向に進むということはあるのでしょうか? もしそうならば、セキュリティや資源管理はどのように維持されるのでしょうか? (これは集中型カーネルのシステム[central kernel system]でも十分に難しいことです。)

テオ君:

最初の質問について、オレンジブックの世界に対して大きな誤解があるようだ。多くの人は、オレンジブックをセキュリティについての規定だと思っているが、それは違う。その大部分は、脅威にさらされた場合の説明責任(accountability)についてのものだ。つまり、実はシステムをセキュアにすることについての話じゃない。システムのセキュリティがいつ破られたかを知ることについての話だ。全然違う話なのだ。口角泡を飛ばして「すごい」なんて騒ぐ前に、商業的に展開され、実業務に使われているCや、Bや、さらにはAのシステムがどれくらいあるか数えてみることだ。一方で、オレンジブックに描かれていた世界の一部が、現実のシステムに、実際に使われるのを徐々に見ることになるだろうと思う。ところで、ACLが挙げられているのには驚いたよ。なんせ、それは実際のところB1システムには何の関係もないものだから。

二つ目の質問について、私は分散型カーネルが何なのかまるで分からないし、そういった類のものがシステムのセキュリティや品質を向上させるなんて思わないよ。

(※訳註: オレンジブックとは米国防総省のTCSEC(Trusted Computer System Evaluation Criteria [信頼できるコンピューターシステムの評価基準])のこと。表紙がオレンジだったのでその名がある。レベルの高い方から順にA, B, C, ... とレベル分けをして、それぞれのレベルをさらに1, 2, 3, ... と細分化した。B1というのは大分類Bレベルの小分類1レベルという意味。)

4) フォークと協調
PapaZitによる

OpenBSDはNetBSDからフォークし、いまだに、この2つのグループ間にはかなりの敵意が存在することは多くの人に知られています。個人的な考えですが、その競合は、双方のグループに役立っているのではと思っています。(例えば、現在ではNetBSDでもオープンなサービスはかなり少なくなっています。)

エゴというものはデリケートなものですが、将来には大規模な協調が行われる機会があるとお考えでしょうか? それとも、さらなるフォークや分裂は避けられないものでしょうか?

テオ君:

考えてみろよ。NetBSDは、OpenBSDプロジェクトのネットワークに4年程もブラック・ホール・ルートを続けてやがるくせに、どうやったら高いレベルでの協調なんていうもんができるのか、おれは理解できないね。

まあ、被っているプロジェクトに首を突っ込んでいるデベロッパもいるな。いろんなグループとのトラブルのことで文句を言っていた奴もいたけれども、このところは、ちょっとは落ち着いてきたようだよ。最近じゃ、デベロッパの結びつきってものは、政治的なことで決まるものじゃないのだね。

Linuxの世界じゃ、金銭的な問題でプロジェクトにフォークが起こるようだよ。BSDの世界では、ほんと純粋に政治的な問題でフォークが起ったみたいなんだけどもね。今後何が起こるかなんか、俺にはわからないよ。かれこれ、BSDキャンプでは5年もフォークが起きてないしね。しかし、何であんたらはそうフォークにこだわるんだ? あんたらは、皆に同じ政党に投票させたいとでも言うのかね?

5) カーネル設計
laertesによる

私はまだ少しの間しかOpenBSDを使っていないので、間違った仮定で質問しているなら許してください。

OpenBSDのカーネル設計はモノリシックの類に入ると思います。OpenVMSとNTは2つともマイクロカーネル・アーキテクチャを用いた素晴らしいオペレーティング・システムですね。私にはマイクロカーネル設計というのは、特権的なコード部分が少ないため、本質的により安全なものに思えます。さらに複数のサーバ部の1つが危険な状態になっても、損害は最小化されるのです。

私の質問はこうです。OpenBSDの設計は本質的に安全なのでしょうか? それとも基本的には欠点のある設計だけど、うまくつくろった実現例にすぎないのでしょうか?

テオ君:

それで何が違ってくるってぇのか、さっぱりわからねぇな。あんたのコンピュータの先生って、80年代に書かれた本で教えてたんじゃねえのか? あの頃はマイクロカーネルって言葉だけで、未来のユートピアだったんだぜ。NTがマイクロカーネルだなんて嘘だろう。OpenVMSもそうだって、あんたほんとに信じているのかい。マイクロカーネルってのは、ローダブル・モジュールで仕事をするカーネルじゃねぇんだがなぁ。まぁな、システムがするべき仕事をちゃんとやってるんなら、そこになんか違いがあるってのがわかんねぇなぁ。

6) コード監査の訓練はどこで学びましたか?
EXTomarによる

コードを監査する原動力は、必要性によるものでしょうか、それともBSDの設計から来たのでしょうか? あるいはもとより思いつきなんでしょうか? 何より、どこでそれを学んだのでしょうか? 共に見ている「先達」がいらっしゃるのは、めりはりのある設計のためなのでしょうか? あなた方チームの圧倒されるようなコードのレビューには、感服せざるを得ません…自分にもあれほどの精細なコーディングの素質があれば良いのですが。

テオ君:

監査過程は、自分たちのOSの質を向上させようという欲求から生まれた。最初にそれを始めたときは、魅惑的で、楽しくて、そしてかなり狂信的に近いものがあった。約10人がその共同作業に携わって、原則としてお互いに教えあいながら事を進めてきた。「ホール」や「バグ」といったものより、ソース・コードにおけるプログラマの基本的な誤りや杜撰な点を探した。ずぼらな点を見つけるたびにソース・ツリーを繰り返したどるということを、ずっとやっていたのだ。プログラマが犯した誤りを見つけるたびに(たとえばmktemp(3)を使ってファイルシステム競合が起こるような場合)、ソース・ツリーを最初から最後までたどって、それら「すべて」を修正する。そうやって一つ直すと、他にも基本的な誤りを見つけるだろう。そうしたらまた「すべて」を修正する。そう、大変手間のかかる作業だ。でもとてもただならぬ見返りがある。ボーイングの技術者が、発生した配線の不具合を「すべて」は直さなかったらどうなるかなんて想像できる? 少なくとも、ソフトウェアも同じようにやるように試みましょう。

7) Firewall/NAT box
yamlaによる

Linuxには、FreeSCO(フリースコ)という、3.5インチ・フロッピーに入る、ルータやNAT(ネットワーク・アドレス変換==rfc1631)として使えるものがあります。私はいつもOpenBSDにもこういうものがあったらいいなと思っていました。というのも、こういった(NATやルータとしての)用途には、LinuxよりOpenBSDの方が信頼できるからです。

こういうものを作る計画はありますか? もっと簡素なユーザ・インタフェイスで素早く容易に設定できるようなものはどうでしょう。OpenBSDは大好きだし、手で設定したいけど、忙しくて。

テオ君:

まず言っとくけど、フロッピー・ルータとか好きじゃないんだよね。基本的に、あんたは一番信頼ならねぇ記憶装置を使おうとしてんだぜ、さらにその上にセキュリティの基盤を築こうとしてる。容量の小さいハードディスクでも買えよ。CDと、(フロッピーじゃなくて)ちゃんとした記憶装置を使ってやるんだったらまだまともだろうよ。でも、頼むから、フロッピーはやめてくれよ。madなの?

8) コード監査
ATによる

コードを監査するに当たって、何かアドバイスをいただけませんか。今までバグを見つけてきた経験から有用だったtipsや方法に関して教えていただけるとありがたいです。出来立ての若いコードの場合は、まずどこを探りますか? 古いコードの場合は?

テオ君:

一番のtipsは、今よりももっと良いプログラマになる、ってことかな。特に、対象のプログラムがどんな関数を使っているのか調べることと、そしてその関数の決まりごとをきっちりと守って使っているか確かめることが重要だ。これを読む人の中の果たして何人が、libcのすべての関数の完全で正しいセマンティクスを知っているんだろう。全部と言わずに、今監査しているプログラムの中で使っているlibcの関数についてだけでも、ちゃんと分かっている人はどれだけいるんだろうね。(どういうことかって言うと、今までソース・ツリー全部を調べてきて、strncat()やstrncpy()の呼び出しのだいたい半分は微妙に間違っていて、一文字余計にコピーしちゃってヌル終端しなくなるだけだとしても、それはやっぱりいい具合じゃないってこと。)

APIを完全に身に付けた時に、簡単にバグを見つけることができるようになるだろう。勤勉さが必要な他の仕事と一緒だと思うよ。注意深くあって欲しい。人は前例から学ぶものなのに、依然としてソフトウェアプログラミングの世界では、その途方もない複雑さが見つけにくいバグを生み、それはさらに新しいコードにコピーされているんだ。関数を間違って定義したマニュアルを見つけたことすらあるんだけれど、その時には多くのプログラマが、間違ったマニュアルに重ねて間違ったプログラムを書いていた…。

9) デュアルプロセッサ対応
dragonfly_blueによる

OpenBSDを2CPUや4CPUのマシンで動かすことに興味があるという意見が散見されますが、こういったことをするために必要な情報も、手を挙げる人も少なすぎるようにみえます。私はOpenBSDをwebサーバに使用していますが、この点については全くといってエキスパートではありません。でも、それでもなお興味津々なんです。

聞くところによると、マルチプロセッサ対応は、特に競合状態をはじめとして多くのexploitを引き起こす可能性があるので、実装にかなりトリッキーなことをしなきゃいけないそうですね。OSの全体の整合性に妥協することなしにSMPのためにコード・ベースの多くを書き直すのはものすごい量の時間と労力が必要になることも理解しています。

以上を念頭に置いて、2CPUや4CPU対応に本腰を入れるためにどういったリソースが必要になりますか? それから、そういったリソースが無尽蔵に使えるとして、-stableリリースが出せるようになるまでにどれぐらいの期間がかかるでしょうか。将来、マルチプロセッサに対応するのが本当に楽しみにしています。もちろん、現在開発チームが十分忙しいということも分かっています。

テオ君:

今のところ、俺達はSMP対応の作業はしてない。こいつは、ものすごく手がかかるし、俺達はそれほど興味がないんだよ。わるいね。

(※訳註: 「OpenBSD SMPプロジェクトで、作業は継続中ですが、まだ、現時点では使用可能なマシンは何もありませんし、OpenBSDのSMPサポートのスケジュールも出せる状況ではありません。ほとんどのプラットフォームで、OpenBSDはSMPマシン上でも動きはするでしょうが、ひとつのプロセッサしか利用できません。」faqの8.12日本語版)参照。ソース・ツリーに初めてSMPタグが打たれたのは2000年2月12日のこと。SMP Projectのページ。)

10) タイム・ワープ
rhoによる

テオの業績に感謝を。私は、OpenBSDをワークステーションとして、またファイアウォールとして毎日使っています。警官がスクリプト小僧を追っかけている柄のTシャツも最高ですね。

もし、時間をOpenBSD開発の始めに戻せて、そこに至った主義主張の話を無視したとすると、何か違ったことをしたいですか? 商業版に焦点をおいたでしょうか? SMPの開発を、もっと早く進めましたか? それとも、両手を振り回しながら、ぐるぐると駆け回りますか?

もう一つ質問は、OpenBSDの商業利用に関してどのように感じているか。つまり、支持しているか、我慢しているかとかの話です。もうちょっと良い例だと、私がOpenBSDの走るセットトップ・ボックスを作ったとして、OSに機能Xを果たしてもらいたいとします。で、あなたに電話して「テオ、OpenBSDでXをサポートして欲しいんだが」と言ったとします。どんな答えが返ってくるんでしょうか?「あっち行け」? 「自分で書けよ」? それとも「金払えばOpenBSDチームでやるよ」なんでしょうか?

テオ君:

俺達のコードのライセンスはごく単純だ。俺達は、ベンダーにコードを使って貰いたいと思っている。商用OSにOpenSSHを載せて出荷して欲しいと思っている。SSHの類を載せずに出荷するのは悲劇をもたらすし、それはSSHの終りの時だ。

同じことがOpenBSDでも言える。ある会社が商用ネットワーク機器を組み上げるのなら、一から書き上げた独自OSを使うよりは、OpenBSDを使ってもらう方が好ましい。たいていの場合、それらの会社は問題をアプリケーション空間で悠々と解決している。たとえ、それらの会社で汚い独自OSの歴史があったとしても、同時にもっと酷いアプリケーションの歴史もあるもんだ。

ルータ、ファイアウォール、電話交換機、ファイルサーバおよびその他もろもろの機器において、信頼でき、それらに感心をもつ人達によって設計された構成要素を使えば、もっと状況はよかっただろうに。

だから、どんどんやってくれ。OpenBSDのどの部分でも、商用システムに組み込んで構わんさ。

11) 完全な情報開示とバージョン番号付け
Effugasによる

まず最初に、OpenBSDの構築に費したあなたの労力に感謝します。OpenBSDは、本当に良いパッケージだと思います。

OpenBSDにおけるほとんどのセキュリティ強化は、ソース・コードから安全じゃないライブラリ呼び出しを洗いだす作業にすっぽりと覆われているわけです。しかし、この作業はもちろんありがたいのですが、最近になって、こういった変更は必ずしも文書化されてないし、アプリケーションやユーティリティのバージョン番号に確実に反映されていないという事実が、だんだん気になり始めています。

バージョン番号は、コード・ベースの存在期間の中で特定のスナップショットを反映するものです。それらは、安全ではない版を参照したり、特に安定版を参照するのに用います。番号のメジャー番号は分岐を示し、マイナー番号はコードの特定の状態を表します。それが、ユーザや管理者がバージョン番号を見た時に期待するものです。バージョン管理に粒度を与えなければ、その番号を信用する/しないの理由がなくなります。個人的にソースを検査して、最終的には自分流のバージョン番号を与えることになるでしょう。

あなたとチームは、コード検査の主幹です。安全な構築物用の変更コードとオリジナルコード(さらに敷衍すれば、あなたの安全なコードと多くの無名の配布者による「とりあえずコンパイルできるようにした」改変物)とを区別できなくして名前空間を汚染するのではなくて、改変したすべてのパッケージに関して名前の拡張をし、完全な情報開示の意図の下に、そこに含まれる妥当な変更履歴を提供するのがスジではないでしょうか?

テオ君:

OpenBSDのすべての構成要素に、二つの番号がある。一つは、どのリリースに含まれるかを示す番号で、例えば2.8とかだ。

もう一つは、構築に使われたすべてのソースファイルが持つ番号がある。その番号は、それらから構築されたバイナリにも含まれている。どのバージョンのソースファイルからそれぞれのバイナリができているかは、what(1)コマンドを使えばわかる。

オリジナルに関しておっしゃっているが、オリジナルというのは存在しない。OpenBSDは、独自の構成要素をもっている。あなたがどのパッケージを意図しているか私にはわからない。catはcatだし、ftpdはftpd、tarはtarだ。特定のリリースに関して言えば、一つしかない。系統だったアプローチだと、他のグループのやっているバージョン番号付けは、不正な場合がある。なぜなら、ライブラリなどの部分全部を、一つの構図にまとめてしまっているからだ。

この間乗った飛行機の前輪が、バージョン2.7だったか2.9だったか? 気にしないだろ? それでもだ。それが完全なことを保証するために「系統だったアプローチ」とやらが使われていることを気にしているわけだ。そして、OpenBSDの場合は、それは特定のバージョンを選び、パッチを当てるということを意味する。

これ以上を望むのならば、俺達により多くの作業をバージョン管理を費して、それだけシステムそれ自体にかける時間を減らすことを望んでいることになるんだが。

12) お金はどこへ?
MrSparklerによる

リリース毎のCD売り上げが10000枚近くになるというレポートを見ました。Tシャツやポスターの売り上げ、寄付金をあわせるとある程度まとまった金額がOpenBSDの周りを流れていることでしょう。このことと、小切手の宛名がde Raadt氏であるという事実を考えあわせると、資金がどのように扱われているのか、疑問を感じます。不正が行われているなどというつもりはありません、ただ誰がお金に責任を持っているか、OpenBSDプロジェクトが非営利組織(NPO)として登録されているのかどうか(もしそうなら、小切手はその団体に振り出されるべきではないか、CDイメージはその団体の著作物とされるべきではないか)ということを知りたいのです。また、ユーザが自分たちのお金がどこへ行ったのか分かるような簡単な財務レポート(アルバータのNPOであれば要求されるであろうもの)を見たいのです。加えて、リリース毎に何枚のCDが売れたのか正確に知りたいのです。

OpenBSDプロジェクトの開発者達が注ぎこんだ業績に感謝していますし、この質問への答えに関わらず、これからもOpenBSDを使い、購入し、寄付し続ける(そして技術的スキルが身につけば参加する)つもりでいます:本当のところ、お金はどこへ消えるのですか?

テオ君:

俺達はリリースあたり10000枚のCDを売り上げたことはない。もうすぐそうなるだろうけど。プロジェクトは、最終的にはCD売り上げ収入の50%よりわずかに少ないくらいのお金を得る。Tシャツ事業はうまくいっているけど、布地を売ったところで儲けはほんのささやかなものだ。ポスターでは差し引きゼロからわずかに上ってところだ。そりゃいくらかはWebで売れるけど、ほとんどは数多くのカンファレンスで無料配布される。それが俺の計画したポスターの使われ方だ。

俺達はNPO化については検討したことがあるけど、あまりいいアイディアじゃない。全く何の現実的な利益も――あなた方に対して、ということだけど-もたらさない。特にカナダでは、NPO化にはコストと重大な責任が要求される。多くの自由を手放さなきゃならないし、繁雑な経理のために誰かを雇わなきゃいけない。それに、多くの寄付金がカナダ国外から寄せられているから、あなた方に課税対象となるような利益も生み出してやれない。(そして俺はあなた方に尋ねることになる、本当の寄付でなく、税金控除の対象になる金額しか寄付してくれないとは、あんたたちはなんてケチンボなんだ? ってね。実際、そんなのはフリだけだと分かっている。)

プロジェクトから得られるお金はいろんなことに消えていく。第1に、お金は俺がフルタイムでOpenBSDのために働くことができ、他の仕事をしなくてもいいと保証してくれる。フルタイムOpenBSDのために働くことに興味があると言ってくれている、プロジェクトの他の開発者たちにも同じようにしてやりたい。第2に、多少汚れた、面白くもない、そして重要な開発作業では開発者達のポケットに少しのお金が入る。OpenSSHの作業のいくつかは、OpenBSDの資金のうちVanDykeからの寄付金に見合う金額によって賄われている。第3に、プロジェクトで妥当な量のハードウェアを購入している。PowerPCだけだが、今年は4台のマシンを購入した。第4に、カンファレンスへの出荷コストがときどき売り上げ収入を上回ることがある。最後に、開発者がハッキングのために集まるとき、プロジェクトの資金がいろいろなことに支払われる、例えば航空券、滞在費、時にはビール代にも。ビールはアイディアに化け、アイディアは新しいコードに化ける。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2004年01月05日 11時20分 (#465714)
    > しかしながら、如何せんちょっと古い記事なので、お詳しい方は、
    > 事情が変わっているところなど、コメントでご教示ください。

    元記事は、3年前の2000年12月のものなんですね。
    ここで延べられている「NetBSDは、OpenBSDプロジェクトの
    ネットワークに4年程もブラック・ホール・ルートを続けて」
    という件は、2000年の12月の時点でも正確な表現かどうかは
    良く分かりません。(後述)

    ただし、この時点では、Theo氏の出したメールに対するフィルタ
    リング措置は確かにありました。これについても、日本の itojun
    さんが NetBSD プロジェクト内での意見とりまとめに労力を割いた
    こともあって、最終的に 2002年7月に終了しました。終了のアナウ
    ンスは下記にあります。
    http://mail-index.netbsd.org/netbsd-announce/2002/07/30/0000.html

    Theo氏の延べているブラックホール・ルートというのは、メール・
    フィルタリングの一手段だったわけですが、いつごろからか、フィル
    タリングの手段はブラックホール・ルートから、Theo氏からのメール
    をモデレータに転送し内容が適切である場合のみ配送を許可するという
    ものに、変わっていたようです。実際、Theo氏のメールが何通か、NetBSD
    のメーリングリストに流れています。

    このメール・フィルタリングのそもそもの発端は、
    http://docs.freebsd.org/cgi/getmsg.cgi?fetch=56044+0+archive/1996/freebsd-hackers/19961020.freebsd-hackers
    や、
    http://mail-index.netbsd.org/current-users/1996/10/20/0004.html
    にあります。
    ここにあるとおり、Theo氏からのメールに対するフィルタリングは、
    FreeBSD プロジェクトも、NetBSD プロジェクトと同時に始めています。
    なぜフィルタリングが必要になったかについては、リンク先を参照して
    ください。
    • by Anonymous Coward on 2004年01月05日 11時27分 (#465715)
      > いつごろからか、フィルタリングの手段はブラックホール・ルートから、
      > Theo氏からのメールをモデレータに転送し内容が適切である場合のみ
      > 配送を許可するというものに、変わっていたようです。

      ちょっと分かりづらい書き方でしたが、このモデレータに転送するという
      措置についても、2002年7月をもって終了したという意味です。
      親コメント
  • こうしてみると (スコア:2, すばらしい洞察)

    by Naotosdot (17855) on 2004年01月03日 10時47分 (#464968)
    #翻訳ご苦労様です。

    実際Theoがしゃべってるの見たことないんですけど
    Linusの1人称が「僕」でTheoの1人称が「俺」なのは
    Theoって べらんめえ的な、江戸っ子みたいな人だから
    なんでしょうか?
  • by kaityo (16162) on 2004年01月03日 4時45分 (#464930)
    BSDを使ったことがないからかも知れないけど、
    11番の質問と、その答えの意図が良く分かりません。

    変更履歴はCVSみたいな奴で取れないんですか?
    その時に、何を直したかをきちんと書いてあればよいと
    思うのですが、それ以上のことを求めているんでしょうか?

    全体のバージョンとリビジョン番号が対応付けされていれば、
    更新履歴も自動で作れるはずですよね。

    それとも、
    T (Temporary) とりあえず動く
    B (now deBugging) デバッグ中
    C (completed)完了

    とか定義して、「Ver 2.7.1B」とかしてほしい、と 言っているのでしょうか?

    #はずしているかもしれないけどIDで。
    • by jmk (11245) on 2004年01月03日 12時35分 (#464991)
      BSD使ったことないと確かに実感湧かないかもしれません。
      BSDはカーネルだけを指す表現ではないので、一緒についてくる cat も tar も ftpd も libc も「BSDの一部」なわけです。で、それを一意に「OpenBSD 3.x」とか呼ぶことについて、質問者は問題にしているのでしょう。
      話がややこしいのは、ベースにしているプログラムがあることです。たとえば tar は GNU tar をベースにしていたと思います。しかし、それなりの改変を加えた上で配布しています(jオプションがついたりとか)。 OpenBSD の場合、「やっぱ一から書き直そう」っていうことも多いですけど。
      なので、それらの配布物を一括して「OpenBSD 3.x の tar」とか呼ぶのではなく、 GNU tar 1.13 + OpenBSD patch 1.1 とか(バージョン番号は適当)にして欲しいというのが質問者の意図だと思います。
      「んな面倒なことせんでも、 OpenBSD 3.x の tar でええやん」ていうのが Theo の返事だと思います。
      親コメント
      • by Anonymous Coward on 2004年01月03日 13時23分 (#465003)
        まぁこまかいことだが、OpenBSDは最初のリリースからGNU tarをバンドルしてないね。

        今はdiffもgrepもgzipもGNUのものではないです。
        親コメント
      • by kaityo (16162) on 2004年01月03日 15時21分 (#465023)
        なるほど。感謝です。

        僕自身はdebian使いなので、それらアクセサリは全部別パッケージという感覚がありました。

        GNUの血統がまじると特にライセンス関係とかややこしい気がしますね。
        GPLを改変したらBSDライセンスで配布できないのか、と思って 調べてみたのですが、GPLとBSDは矛盾しない [gnu.org]のか・・・

        親コメント
        • by Anonymous Coward on 2004年01月03日 16時07分 (#465033)
          矛盾しないと言っても
          「BSDLなコードをGPLなコードとリンクしてGPLの下で配布できる」
          という話であってGPLなコードをBSDLで配布するのは無理ですぜ。
          #GPLなコードの著作権者から別に許諾を受けた場合はまた別の話。
          親コメント
          • by Anonymous Coward on 2004年01月03日 17時43分 (#465056)
            それもそうだけど、そもそもkaityo氏は単一のプログラムを形成する場合の話とプログラムの集成に関する話を混同しているように見える。後者についてはGPLは何の影響も及ぼさない。ちなみにオープンソースの定義(OSD)には「他のソフトウェアを制限するライセンスの禁止」も含まれている。
            親コメント
            • >>GPLを改変したらBSDライセンスで配布できないのか
              >プログラムの集成に関する話

              集成として配布する場合でもGPLなソフトウェアはGPLの下で
              配布しなければならないのでBSDLで配布する事は出来ませんね。
              BSDLとGPLのソフトウェアを一緒にパッケージして配布しても
              BSDLな部分はBSDLのままですしGPLな部分はGPLのままです。
  • by KAMUI (3084) on 2004年01月03日 10時57分 (#464971) 日記
    翻訳ご苦労様でした。OpenBSD は触った事無い為
    内容については手が出せないので(苦笑)

    >11) 完全な情報開示とバージョン番号付け
    >ソース・コードから安全じゃないライブララリ呼び出しを

    「ライブララリ」は・・・多分 typo ですよねぇ?
  • by Anonymous Coward on 2004年01月03日 13時14分 (#464999)
    Q3でオレンジブックのB1をたとえに出しているのは、Windows NT 3.5がC2セキュリティを取得しているということに対しての皮肉なんでしょうねぇ。

    # 高い順にA,B3,B2,B1,C2,C1,D
  • 仲悪い (スコア:1, 参考になる)

    by Anonymous Coward on 2004年01月03日 20時08分 (#465087)
    > NetBSDは、OpenBSDプロジェクトのネットワークに4年程もブラッ
    > ク・ホール・ルートを続けてやがるくせに、
    そうしないと耐えられないような嫌がらせのようなメール、DoSまがいが行われて、filter outせざるを得なかったと聞いたことがあります。

    結局はTheo君の行動というか、性格がきっかけだったと言えるでしょう。
  • by yuu3261 (11831) on 2004年01月05日 0時27分 (#465449)
    以前ここでも話題になった スケーラビリティの件 [srad.jp] は誰も質問してないんですね。残念。

    OpenBSD 3.4 was a real stinker in these tests. The installation routine sucks, the disk performance sucks, the kernel was unstable, and in the network scalability department it was even outperformed by it's father, NetBSD. OpenBSD also gets points deducted for the sabotage they did to their IPv6 stack. If you are using OpenBSD, you should move away now.

    の件。
    #でも今、上のサイト見たらOpenBSDの人々と話した結果なんかが掲載されてるからもう済んだ話なのかな?

  • by yh (6046) on 2004年01月18日 19時53分 (#475520) ホームページ 日記
    本家インタビュー: OpenBSD開発者Theo de Raadt

    各設問の翻訳を下記の方々に頂戴いたしました。(敬称略)

     1) k3c
     2) umq
     3) numa
     4) harux
     5) BSD
     6) float
     7) umq
     8) SOggy
     9) umq
     10) Jadawin
     11) Jadawin
     12) k3c

    翻訳やコメントをくださったみなさま、ご協力ありがとうございました。また、ずいぶん時間がかかりまして、大変おまたせいただいました。
  • by Anonymous Coward on 2004年01月03日 2時41分 (#464912)
    痛い。

    :うごけばいいじゃん:時間に追われてるとはいえ。。。。
    • by Anonymous Coward on 2004年01月03日 16時09分 (#465034)
      動くものの方が,動かないVaperwareよりマシである
      親コメント
      • by Anonymous Coward
        あなたは*BSDには縁がない方のようですね。
        こんなとこ見てないでLinuxでも使ってなさい。
        • by Anonymous Coward on 2004年01月04日 21時01分 (#465310)

          なぜ#465034がプラスモデ、#465061がマイナスモデなのか、理解に苦しみます。

          OpenBSD [openbsd.org]では、

          私たちのプロジェクトが特に力を入れているのは、移植性、標準化、 正しさ、積極的なセキュリティと 暗号機能の統合です。

          といっており、 フォーク元のNetBSD [netbsd.org]では、

          NetBSD プロジェクトのおそらく第一の目的は、正しい設計とうまく書けたコードとを強調することです。

          "動けば正しい" の哲学を持つシステムもあるようですが、 NetBSD を同様に記述するならば、"正しくない限り動かない" となります。

          といっています。

          親コメント
    • by partial (18305) on 2004年01月04日 18時09分 (#465272)
      営利なのか趣味なのかによって方針が違っていいはず。
      親コメント
    • by Anonymous Coward
      そもそも、品質より納期を優先させる上司、営業、顧客が悪いのでつ。
      プログラマーはしわ寄せを受けているだけ。はっきり「NO!」と言えばいいのですよ。

      最近は専用ソフトよりも、表計算ソフトでデータ処理することが多くなりました。
      専用に作られて、統合されたソフトの場合、バグがあったらどうしようもないですからね。
      • by Anonymous Coward
        >そもそも、品質より納期を優先させる上司、営業、顧客が悪いのでつ。
        >プログラマーはしわ寄せを受けているだけ。はっきり「NO!」と言えばいいのですよ。

        後半の製造側が NOと言えば良いはまったく同感なのだけど
        前半は *その記述だけでは* 同意できないですね。

        その辺り、要求される品質とコスト、納期遅れによる影響の
        それぞれのバランスは
        • by Anonymous Coward
          説得したもん勝ちですよね

          # なんか元インタビューから大幅に脱線して愚痴大会になっている。
  • by Anonymous Coward on 2004年01月03日 4時47分 (#464931)
    # 荒らし認定で頼む

    > 「スラッシュドットはLinuxの話題に偏りがちなので、BSDも」
    で上記インタビューの英日翻訳との事だが、この事から何を学ぶ?

    BSDは何も変わらない、そういう理解でFA?
    大丈夫、日本では湘南の分校とかが、かたくなに伝統を守ってくれるよ。

    # あ、翻訳作業ご苦労様です。>翻訳者さん
    # もちろん皮肉などではなく、その作業には純粋に感謝を。


    BSD難民時代がトラウマなのでもちろんAC

typodupeerror

UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie

読み込み中...