FreeBSD コアチームへのインタビュー 20
ストーリー by GetSet
行間に垣間見える情熱 部門より
行間に垣間見える情熱 部門より
BSD 曰く、 " OSNewsに興味深い インタビュー記事が掲載されている。 出席者はコアチームから3人(Wes Peters、Greg Lehey、M. Warner Losh)と 開発者の1人(Scott Long)である。 記事はかなり長く、以下の8つの話題から構成されている。
- JAVAのサポート
- Linuxとの競合、デスクトップ市場
- 5.xの完成度、Linuxと比べた開発の速さ
- 他のUnixとどう違うのか
- バグ解決、チームワーク、GUI インストーラー
- 最適化、いくつかのCPUへの移植、第三者からのツール
- XFree86の問題、BSDが統合できるとしたら、UFS2
- 最近のSCOからの問題
メーリングリスト等からでは伝わらない生の雰囲気のようなものが 読めて非常に興味深い記事であると思う。 これからも、自分たちと多くのBSD利用者のために開発を続けていくと いうことであり、今後のFreeBSDの発展が期待される。"
コアチームへの質問内容 (スコア:5, 参考になる)
1. Java 1.4.xのFreeBSDへの移植はどんな状況ですか？ それがなかったことで市場防衛にどんな影響がありましたか？ （編注:Javaパッチセット3はリリースされた）
2. 数年前、WindRiver/BSDiのような企業が、宣伝活動やデバイスドライバに関する企業との関係を取りもったり等と いろいろFreeBSDへの援助を続けていました。現在、FreeBSDプロジェクトは自活していますが、このような問題を どうしていますか？
3. FreeBSDには、1999年に最初の熱狂的宣伝活動の波に乗り多くの人々の心をつかんだGNU/Linuxという競争者がいます。 そして、Linuxはサーバ領域と同様デスクトップ領域でもうまく動くということを確信させてきました。FreeBSDプロジェ クトはこの状況をどのように見ますか？ そして、デスクトップ用FreeBSDというようなサブプロジェクトは考えないので しょうか？
4. FreeBSD 5.0 が出てきましたが、ほとんどプレビュー版ですね。多くの人がFreeBSD 4.xに比べて、その不安定さと 遅さに幸せにはなれませんでした。LinuxはIBMやRedHatやSGIのような大きな営利企業で働く技術者からの支援でカーネ ルを改良していますが、FreeBSDのロードマップは競争相手にお手上げ同然ということをどう思いますか？ 営利企業抜き のプロジェクトがSolarisやLinuxチームよりも速く長所を伸ばしていくことが出来ると信じているのでしょうか？
5. 技術的な話に限定しますが、今日の時点でSolarisやLinux、IRIX、AIXに対するFreeBSDの最大の長所は何でしょうか？ また、これらのUNIX互換OSに比べて未だ欠けているところはどこでしょうか？
6. アーキテクチャ的な問題や5.xのコーディングバグの解決で、一番難しい部分は何でしたか？ この期間、5.xに 関わっていた人は何人いたのですか？
7. GUIベースのFreeBSD用インストーラーや、NATやDHCP、ファイアーウォールのような主要なサービスに対する ある程度GUI的な、ある程度カーソル移動で動く設定用フロントエンドツールを提供する計画はありませんか？
8. FreeBSDをi386アーキテクチャではなく、i586やi686のみに最適化する計画はありますか？ PPCへの移植はどう 進んでいますか？ SPARCへの移植計画はありませんか？ 一番重要なことですが、AMDのOpteronやIntelのItanium のサポートはどうするのですか？
9. Intelが彼らのコンパイラとツール類をネイティブなFreeBSDとして移植するという話はありませんか？
10. XFree86プロジェクトが分裂しましたが、FreeBSDの公式な立場はどうなっていますか？
11. 完全に空想世界の話ですが、3大BSDであるFreeBSD、OpenBSD、NetBSDが、それぞれの特徴を共通のソースコード にまとめて1つのプロジェクトという傘の下に入るという、そんな再統合についてどう感じますか？
12. たくさんの人がUFS2とXFS/Reiser/JFS、NTFSとの違いを尋ねます。他の新しいファイルシステムに対し、UFS2の 強みは何ですか？ また、技術的な観点からその弱点は何ですか？
13. SCOはIBMを訴え、今度はLinuxを訴えるようです。また、SCOはMac OS Xも彼らのUNIXの知的財産を使用している ようだと言っています。Mac OS XはFreeBSDや4.4BSD、Machなどを部分的に取り入れています。こういう状況はFreeBSD プロジェクトにどんな影響を与えていますか？ FreeBSDはクリーンなコードを使っているのですか？ それともSustem V のコードが部分的に残っているのですか？ 加えて、FreeBSDはLinuxのエミュレーションライブラリを一緒に出荷して います。FreeBSDの中にあるLinuxコードのこの部分は問題のSCOの知的財産部分を含んでいませんか？
一問目の翻訳 (フィーリングのみ) (スコア:3, 参考になる)
数ヶ月前に、FreeBSD FoundationはJava 1.4.1をFreeBSDを移植するための資金援助を行いました。しかし不幸にもSunからライセンスを得るプロセスは非常に長いために、それが完全になる前に利用できる資金は底をついてしまいました。それでもまだ、このためになされてきた仕事は非常に立派なものです。
(たとえば？)Tomcatのような(Linuxでも共通して使われる)アプリケーションが、Linuxよりも比較的速く、しかもバグが少ないと、たいていのユーザーが報告しています。
また、それ(Tomcat?)は非常に大きなインターネットポータル会社の手によって、作られている最中でもあります。
そして、現在もSunから証明を得るためにFreeBSD Foundationは資金を増やして活動をし続けています。
ウェズ・ピーターズ:
今の移植状況はスコット・ロングによって説明されました。
で、まず市場普及率について唯一可能な答えは、我々がマーケッティング課を持たないために部分的にも「我々には分からない」です。
私は成功裏にFreeBSDとJavaを埋め込むことができた会社を知っています。しかし私はそのパフォーマンスや顧客のニーズに対してコメントできるような立場ではありません。ただ、私や開発者仲間たちはJava 1.4.xをバイナリ配布できるようになることを楽しみにしています。また、それを待たずともソースによる配布はうまくいっているはずです。
私たちが、JVMと新しいスレッド機構をFreeBSD 5.xに実装し終われば、途端にJavaのスレッドパフォーマンスは劇的な向上を見るでしょう。しかし、このことはFreeBSD 5.1リリースの後に(やっと)完了するとおもいます。
グレッグ・ふらふら・レーシー:
こいつがあなたの最初の質問とは。比較的面白くないなぁ。
ワーナー・ロッシュ:
ちょっと失礼だったかもしれないですね。
グレッグ・ふらふら・レーシー:
(移植については)スコットが現状を説明しました。
もちろん、(市場におけるFreeBSDの影響は)、他の方々がいったように算定することは難しいです。しかし私は現在Sunがとっているライセンス戦略はFreeBSDのもとでJavaを利用することにおいて大きな影響になっていると思います。これはソフトウェアが受け取る真の痛みでしょう。
たぶんLinuxユーザーはソフトウェアをインストールするために、輪を通ってジャンプするような曲芸めいたことに慣らされているでしょう。しかしFreeBSDユーザーは"make install"とタイプすることが可能で、しかもその裏で自動的にインストールできることを期待しています。Sunのライセンスはこのことを不可能にしています。
# by AC2020
フィーリング訳2 (スコア:3, 参考になる)
2. 数年前、WindRiver/BSDiのような企業が、宣伝活動やデバイスドライバに関する企業との関係を取りもったり等といろいろFreeBSDへの援助を続けていました。現在、FreeBSDプロジェクトは自活していますが、このような問題をどうしていますか？
たとえば、NDAを必要とするような、ドライバ製作に必要な情報を手に入れたりすることについて。(例: ATi/nVIDIA関係)
スコット・ロング:
BSDiのような企業の支持を失ったことは、疑いなくFreeBSDの開発速度を遅くしました。誰かが中心となって指揮することをなくし、FreeBSDは後援者たちの配布物にいっそう頼ることになりました。後援者たちとはNAI LabやYahoo!, The Weather Channel, Appleといった企業です。彼らはキーディベロッパーに雇用を提供し、他の会社との同格のNDA契約を補佐してくれ、そしてプロジェクトにサーバースペースと帯域幅を用意してくれました。
このような問題を抱えてきた我々の経験は長い時間を通して増大していますが、我々は5.1のリリースで跳ね返そうと思っています。
ウェズ・ピーターズ:
スコットは非常に上手に答えてくれました。
私は、FreeBSDが今までずっとBSDiやWind Riverといった企業の製品の一部(に過ぎないようなもの)とならなかったことを強調しておきます。ただ、FreeBSDに常に自治権があった、ということは不正確です。このことはあなたの記事にきちんと反映しておいてください。BSDi(そしてそれ以前のWalnut CreekのCD-ROM)はいろんな意味でFreeBSDプロジェクトに役に立ちました。Wind Riverが意義ある貢献をしたかは(私には)定かではありませんが。
グレッグ・ふらふら・レーシー:
これは面白い認識ですね。私たちは決して、それほどの自治権があるようには感じませんでした。
はい、確かにいろいろなグループが私たちをサポートしてくれました。Wind River、その前はWalnut Creek CD-ROM、そして今はFreeBSDモールです。また、同じようなものが多くあります。
ワーナー・ロッシュ:
FreeBSDは過去にサポートしてくれた企業を越えて成長してきました。その開発の多くがさまざまなところから出資された資金によって行われてきました。私の現在の雇用者は私に、配置された部門の業務に影響を与えるかもしれない、FreeBSDのバグに取り組む時間を毎月ある程度認めてくれています。この成果は時折FreeBSDの基幹部分に反映されます。多くの人が私と同じような状況下にいます。
グレッグ・ふらふら・レーシー:
FreeBSD Foundationはこれらの問題を処理してくれます。あなた(記者)は彼らとの接触を望むでしょう。(しかし)ここでそれ以上のことを見ていってください。私は、この質問への私の答えが、スコットの発言を否定するものだと指摘しておきます。ここでの(私の)認識が意味を持つことは明らかです。
ワーナー・ロッシュ:
私はここでグレッグと意見が異なります。
ほとんどいつもNDA問題が存在するとき、開発者個人が相手企業との協定に入るだろうが、またはその開発者の雇用企業が中に入って行われるでしょう。私たちは、多くのドライバがその内部情報にアクセスできる人によって配布できるようにしてきた。このうち若干のものが、個別の基礎の上に成り立っています。(たとえば、Prism 2, 2.5, 3チップセットのためのドライバに対する私の仕事の大半が、私がIntersilとの間に持っているNDA契約のもとにあります)
また、私はnVidiaのドライバが、nVidiaスタッフと開発者の間での契約の基に開発されたことを知っています。
グレッグ・ふらふら・レーシー:
しかしながら、多くの開発者がFreeBSD自体にかかわる資金量以上にやる気に満ちています。それは、彼らの趣味や激しい感情といえます。そして彼らは、その熱望がFreeBSDを使用しその恩恵にあずかるために役立っていることを見いだすでしょう。
# by AC2020
9問目の翻訳。(フィーリングなことに変わりなく) (スコア:3, 参考になる)
新しいリリースがあるまで、私たちは公式な見解を持てません。ただ、FreeBSD 5.0はX Window systemの最新の安定版であるXFree80 4.3でリリースされるでしょう。
ウェズ・ピーターズ:
私たちは、(分裂したとしても)それらをひとつのグループと考えなくてはいけないとおもいます。これは少しもFreeBSDプロジェクトの公式見解ではありません。あくまで私の考えです。
私たちはこのプロジェクトをコントロールするのを、たった9人でやっています。したがって、私たちに政策方針書や理事会といったものはないんです。FreeBSDの方向性はプロジェクトに貢献する人々によって決定されています。
ただ、私個人の意見として分裂したことはいいか悪いかどちらかの状態(でしかない)でしょう。Apacheチームが分裂したとき、彼らのコードはほとんど問題(wimper??)を出しませんでした。Sambaも同様です。彼らは共に開発者がそれを本当に必要とされたシステムを再構築するために、その確かな理由のために、最良の行動として行われました。
私たちが新しいFreeBSDのブランチを作るときはいつも、基本的にこれと同じようなことを行っています。そうしてこれまでに少なくとも5回ブランチをふまえた開発をやってきました。そのことからいうと、もし開発者が一人でうまくやっていけないためにXFree86が分裂してしまったのなら、その後のプロジェクトの成功はすべてその開発者の肩にかかっています。
OpenBSDは似たような状態からスタートしましたが、その後OpenBSDプロジェクトはコンピューティングにかかわる多くの貴重な貢献を一般に、そしてFreeBSDやインターネット社会に対して行ってくれました。
グレッグ・ふらふら・レーシー:
FreeBSDプロジェクトは他のプロジェクトの分裂に関しての何らの公式見解も持っていません。私たちが利用するソフトウェアのプロジェクトに関するどんな分裂に対しても、私たちはその結果(そのことによる成果)を評価するでしょう。そうして、どちらか一方もしくはその両方のブランチをサポートすることになるかもしれません。今回のXFree86のケースでは、両方ともサポートすることは難しいでしょうが、不可能ではないと思っています。
M・ワーナー・ロッシュ:
私はほとんどのコミュニティが状況を静観していると思います。またFreeBSDは伝統的に基本システムの融合のためにもっとも利用可能な技術を選んできています。時々、新しいバージョンがあまり多くリリースされてくるために、FreeBSDがわざとX11やgccの最新リリースに追いつかないこともありました。それでも私は将来的にもこの伝統を続けていって、利用可能な技術で一番のものを(選び出して、それを)基礎にリリースしていくとおもいます。もちろんユーザーが自分たちのニーズに合わせたものを選ぶ選択肢も用意していきます。
とはいえ、XFree86の分裂からまだ数ヶ月しか経っていません。まだどんな判断を下すにも時期尚早でしょう。
# by AC2020 (キャラのかき分けなんてできないよ…)
Re:9問目の翻訳。(フィーリングなことに変わりなく) (スコア:0)
９問目の答え（短かそうだったので） (スコア:3, 参考になる)
Scott Long: インテルの 'icc' と ラショナルの Purify はどちらもFreeBSD の Linux エミュレーションレイヤでとてもうまく動く．このレイヤは Linux ライクなカーネルおよびユーザランド環境を Linux アプリケーションに提供するものだ．Quake 3, Return To Castle Wolfenstien それに NeverWinter Nights のような Linux のゲームもこのレイヤを介して FreeBSD 上で完璧に走る．ネイティブの Linux 上よりパフォーマンスがいいと言う人さえいるくらいだ．
Wes Peters: 私の知る限り，どちらの話もない．Linux 用のインテルのコンパイラは，FreeBSD 上で十分に動き，かつ C のソースファイルをコンパイルしてオブジェクトファイルにし，FreeBSD の実行ファイルにリンクするのに使える．インテルのコンパイラが Pentium 4 上でかなり速いオブジェクトファイルを生成する場合もあるけれども，これら Linux ネイティブな開発ツールに単に接続するだけじゃないコンパイラを作ることは興味深いステップだった．
もし彼らがソースコードをそのようなコンパイラ向けに公表したとすれば，我々はインテルに手間をとらせることなく即座に FreeBSD への移植版を手にすることができるだろう．しかし，近い将来にそんなことが起こるとは思っていない．
Re:９問目の答え（短かそうだったので） (スコア:1)
FreeBSD に興味があるとメールが来ています。
そのメールは僕のところにも回ってきました (ifc の maintainer をしているので)。
ですが、それから音沙汰はないです :)
１３問目その１ (スコア:3, 参考になる)
それからここ数年SCOはオープンライセンスで次から次へとソースコードをリリースしようとしてきたことに注目すると面白い。おいらも何年か前にリリースに関与してたことがあったけど、BSDコミュニティの人は誰も興味なかったっす（訳注・sar？）。SCOが過去にやってきた貢献やら献身やらを理解しない新しい経営陣が乗り込んできたんじゃないかって印象だった。
SCOがいってるIBMが自分らのSMP技術を盗んだっていう主張がトチ狂ってるってことにも注目。SCOはいままでいちどもまともなSMP技術なんか持ってたことはなかったし、Linuxに入ったのもIBMの関与する前で、SCOの実装とはぜんぜん違ってる。
FreeBSDにはSystem V由来のコードがいくつかあるね。これは明確にこの目的でリリースされているし、それを巡る争いなんかなかったよ。1992年-1994年のBSD大戦はResearch UNIXから移植されたコードを巡るもので、System Vのじゃないし。SCO（当時はCaldera）は全部のResearch UNIXのソースコードをBSDスタイルのライセンスで2002年の一月にリリースしてるわけだから、連中がこれについて文句をいう筋合いはありませーん。
M. Warner Losh : コードはSystem V由来ではおじゃらん、むしろUnix第六版か第七版、32Vの嫡出でござる。著作権だけはSystem Vのソースファイルと似ておるがの。問題のコードはUSLに言祝がれておるだけで、評議員達にもその出自は認知されておるのじゃ。まあいいからここでも嫁 [daemon.org]。
調停案ではSecond Networking Releaseの特定のファイルのさらなる利用と配布は禁止され、USLの著作権表示を含む4.4 BSD-Liteの特定のファイルを必要としているのでおじゃる。それに加えていくつか拡張を施すために新しい4.4 BSD-Liteのリリースでは禁止されたファイルの大半を差し替えて、合意の上の修正全部とお知らせを組み込んであるのじゃ。ゆえに、4.4 BSD-LiteはUSLからのライセンス供与や支払いを必要とせんというわけじゃよ。大学側は4.4 BSD-LiteをNet2に入れ替えなされと強く勧めておる。
いずれにせよ、USLの著作権表示のあるファイルは一連の裁判にけりをつけんがためにカリフォルニア大学の評議員から特別に配布の許可を得ておるものばかりじゃ。ついでにノベル（とその相続人）が4.4-Lite由来のシステムを訴えんように追加の合意を得ておる。
FreeBSD 2.0は4.4Liteの新しい移植版をもとにしちょる。4.4 Liteには入っとらんかったnet2リリースからのコードは一切なし。FreeBSD 1.xは訴えられるようなコードが入っとったが、FreeBSDが何年もそのコードは手に入らんようにしておったもんで、ボクはIPのクレームからは安全と思っておりますです。
Greg 'groggy' Lehey: カルデラのソフトのリリースの仕方に問題があるとは思ってたんだよねえ。今IBMを訴えてるのだって去年のリリースと完璧に矛盾してるし。関わってる人がお互い全然知らないからだろうってことくらいしか想像できんけど。おいらたち（UNIX選民一派 [tuhs.org]）はSCOに自分とこのサイトでリリース情報を告知せいって頼んだんだけど、今のところまだやってないでしょ。オリジナルのコピーはここ [lemis.com]にあるぜよ。よかったらURLをもってけどろぼー。
「Linuxエミュレーション用ライブラリ問題」おいらはそんなのあり得ないと思うけど、さっきもいった通りSCOはすごい曖昧な感じだからねえ。FreeBSDはただ既存のLinuxライブラリをエミュレーターに使ってるだけだから、FreeBSDプロジェクトがその中身に責任があるとかいわれる理由がわけわからん。
M. Warner Losh : SCOの主張はIBMの悪しき振る舞いに端を発しておる。彼奴らがIBMを訴えておるのはおよそこんな具合じゃ：IBMはAIXをSystem Vからパクった。IBMはAIXの一部をLinuxに入れた。ゆえに、だってAIXはSystem Vをパクってんだもん、俺たちのIPをLinuxに入れたんだい。
Re:１３問目その１ (スコア:3, 参考になる)
Mac OS Xのソースについての彼奴らのコメントは無知なるが為なり。Mac OSもFreeBSDもUSLの著作権表示のあるあらゆるコードツリーは1992年のカリフォルニア大学の評議会とノベル（係争中にUSLを買い取った）の裁判で達した合意に基づいておる。その合意ではノベルとその相続者は4.4Liteからシステムを派生させた者を訴えることまかりならぬと明示されておるのじゃ。FeeBSDは4.4Liteをベースにしており、ゆえにこの手の著作権絡みの法的手段からは予防されているのでおじゃるよ。UCBは自分らのところはいくつかファイルを削除し、他のところは書き直して、さらに他のファイルには著作権表示を追加しておった。FreeBSDにはSCOグループの知的財産からのおこぼれコードはおじゃらん。
どのBSDにもSystem V由来のコードがあった試しがないのじゃ。USLが1992年の訴訟で主張した知的財産は第六、第七、32Vに含まれていることに基づいておった。これらはSystem VやSystem IIIコードベースの前身なのじゃが、特にSystem VでもSystem IIIでもない。さらに、SCOは古のUNIXプログラムに隠れて実際より先の日付の入ったSystem VやSystem IIIをBSD風のライセンスで自由に配布できるようリリースしおった。これには明らかに第六版、七版、32Vが含まれておる。
儂の記憶が確かなら、IBMはこれまで一度もFreeBSDプロジェクトにこれといった貢献はしておらん。SCOの知的財産の主張が著作権法に基づくのであれば、FreeBSDはこのベクトルからの主張には安泰じゃ。
Linuxのライブラリも同じくSCOの知的財産からは完全に自由じゃよ。過去１５年かそこいらをかけてスクラッチから書かれたglibcに基づいておるのじゃから。その他のライブラリも同じようにスクラッチから書かれたか、あるいはよく知られた系統（例えばX11ライブラリ）のコードベースに基づいておる。ゆえに、FreeBSDはこの方面からも安泰なのじゃ。
ibcsエミュレーションを走らせるのに必要なibcs共有ライブラリを組み込むとなれば、ありきたりの著作権の訴えには弱みもあろう。じゃが儂らはそれはせんから報道されている方面での訴えからは安全でおじゃる。
今のところ知る限りではSCOとは関係ないようじゃが、中にはSCOは自分らのUnixの知的財産から特許侵害の申し立てを行うと疑う者もおる。Unix上の重要なコンセプトの大半がソフトウェア特許よりも以前に発明されており、それに何年も前に特許は失効するか、パブリックドメインに置かれる、あるいは一度も主張されておらん。SCOがこのエリアで主張を通す見込みはないじゃろう。SCOの主張をよく読めば、彼奴らはUnixの知的財産と著作権法だけを頼りにIBMとの訴訟を正当化しておるのがわかる。たとえそうでなくとも、FreeBSDはやはり安泰じゃよ、儂の知る限りではな。
最後に、FreeBSDのコアチームはSCOの代表と一度も連絡を取ったことはおじゃらん。儂らは報道を読んだが、正確に何が主張され、SCOが儂らに連絡してくるのか知るには不十分じゃった。さらに、SCO自身のウェブサイトでも著作権のあるコードがIBMのあいＸカラLinuxに移植されたということしか謳っておらん。AIX由来のコードがFreeBSDにない以上、儂らには自分らがこの訴えからは安全だと察することくらいが関の山じゃ。いま述べたようなわけで儂らがこの動きからは安全じゃと信じておるが、しかし儂らを特定した主張がないままでは確信をもってああだこうだいうことはできんの。
Re:１３問目その１ (スコア:0)
キャラの書き分けをする訳って楽しくよめますね:-)
Re:１３問目その１ (スコア:0)
この辺りが非常に不安 :)
Re:１３問目その１ (スコア:0)
ここ、逆ですね。
原文 The University strongly recommends that 4.4 BSD-Lite be substituted for Net2.
Re:１３問目その１ (スコア:0)
出遅れたけど、11の和訳 (スコア:3, 参考になる)
Wes Peters: 最初にすることは、そのファンタジーの国 (再統合BSD) がパラダイスなのか、それともただの地獄のブランチなのか見極めることだろな。:^)
君の質問はこれまたポジティブなアウトプットだと仮定してる；僕はそう思わないね。思うに、三つのプロジェクトの最良の部分は、それとLinux由来の良いアイディアも、すでに共有されてんだ。協調のレベルは年々確かに大きくなってきてる。
３つのグループの焦点が違ってるってことは、異なる解決策だけじゃなく、異なる問題も導き出すよな。
他のプロジェクトのどれかが同じ問題にぶつかった時、彼は"先人の知恵"が自分たちの問題の解決法にならないか検討できる。
大抵の場合、コードとアイディアが共有されて、場合によっては新しい解決法が試されるわけだ。元のソリューションが第二のシステムにうまく適用できないなら、その経験から学ばれたいろんなことを分析して、独立したソリューションが作られるか、それか、もっといいソリューションが発見されるんだ。
Greg 'groggy' Lehey: 完全な再統合はよろしくないねえ。僕らの多くは他のプロジェクトにも貢献してるから、それはNIHのケースじゃないわなあ。
でさ、
* 巨大なソフトウェアプロジェクトの管理は個人レベルじゃ難しいんだよね。コアチームの作業は大抵、開発者同士の論争をどうにかまとめるって作業になるんだけど。もし僕らがマージするとすれば、開発チームのサイズは倍増するわけで、論争はきっと四倍になっちゃうだろうね。
* その "ある機能をどう実装するかを最強の開発者が決定する" って問題は気になるなあ。この問題の一つの解は、複数のプロジェクトを持つことなんだよね。 NetBSDはなんらかの一つの方法で実装するし、OpenBSDは別の方法で、FreeBSDは第三の方法でやるわけだ。するとそのうち、三つのアプローチの正否を比較することができて、最良のやつを採用するわけだ。これは何度も起こってるよね。マージするとしたら、この長所は無くなっちゃうわな。
* で、どんな利点があるんかなあ？この世には異なるバージョンのLinuxがいくつもあるけどさ、その多くのユーザインタフェースはBSDのそれよりずっと違うわけでしょ。ダイバーシティには利点があるってことでしょ。
でもねえ、プロジェクト間でもっと首尾一貫したメンテナンスをするのは良い考えだよね。首尾一貫したユーザインタフェースのメンテナンスをもっとやっていく、とかさ。協調するとかなんとかってことは、それに掛かる時間の問題より大したことないよね。
M. Warner Losh : 再統合に関して言いたいことはいろいろあります。紙の上では良さそうに聞こえますが、様々なプロジェクトに属す人々が話を難しくしています。FreeBSD、NetBSD、それにOpenBSDはどれも違う臭いがします。どれか一つの臭いが他より好きだという人もいるわけです。すべての臭いを同じものにするのは困難で、望みはないと思いますね。グループの間での健全な競争はイノベーションの促進を助けますし、それにコードベースは、他のプロジェクトの仕事から抜き出したり選んだりするには十分に閉じています。
ユーザランドの大枠は共通化できるでしょう、それには同意します。でも我々はそれを起こす道具を持っていないのです。そういう試みは、様々な理由からどれも失敗に終わっています。
------
ふーむ、そうか、臭いが違うんだ :-)
＃訳は間違いだらけであることを保証します
12問目 (スコア:3, 参考になる)
ウェス・ペータース: ぼくのかんがえでは、UFS2の最強な点は、25年以上も製品で使われきている、吟味されたコードを基にしてるってことさ。なんたって、FreeBSDのUFS2を開発してるメンバの何人かは、UFSより若いんだぜ！ つっても、UFS2が天与のものを下賜たまわったというわけではなくて、どんな用途でも完全無欠だなんていってるわけでもないよん。でも、思ったより簡単だったやね。
思うんだけど、LinuxではXFSとRaiserFS、JFSとかに開発努力がさんざっぱら 投下されてきたわけだけど、あれって結局ext2がへなちょこだったせいじゃん。 FreeBSDはそんな「強化型」ファイルシステムにはあんまり興味がないんだにゃ。 だって、LinuxでReiserFSが使えるようになる前に、UFSではソフトアップデー トが動いてたんだもんね。UFS＋ソフトアップデートでだいたいは十分なんだ。
ここにいるヤシらは、ファイルシステムについてもっと良く知ってるから、機能ごとに比較について詳細を語ってくれるだろね。興味あるならね。
～ここまで～
ソフトアップデートについてはネットワーク・ファイル・システム チューニング [iij4u.or.jp]は参考になるます。
Re:12問目 (スコア:0)
このページ微妙に間違ってませんか? どうもSoftUpdateとBerkeray FFSを取り違えている気がするんですが。
私の理解では、従来のFFSの内で、書き
5.0R は不安定？ (スコア:1)
僕はグローバルIPを振って、Apache 2.0、Tomcat（mod_webapp）、jdk141-linux、mobwiki、postfix、SquirrelMail、fml などを動かしていますけど、運転をはじめてから１ヶ月半、異常が発生したことはありません。まだまだ実績は浅いので安定していると言い切れませんが、不安定ということもありません。
# デスクトップ環境は、4.8から移行している暇がない...
Re:5.0R は不安定？ (スコア:1)
4.x 系に比べたら *相対的* に不安定なのは確かだと思う。
パフォーマンスもデバッグ用コードとか入ってて
落ちてるしね。
# 5.1-RELEASE が待ち遠しい～
main(){printf("Hello World\n");}
Re:5.0R は不安定？ (スコア:1)
> パフォーマンスもデバッグ用コードとか入ってて
> 落ちてるしね。
デバッグ用オプションを外したところでの質問4に対するワーナー・ロッシュさんの回答:
5と4でベンチマークをやってみると, いろいろな所で5が遅いですね. でも一番大きいのはgccです. gcc3.2は2.95よりも良いコードを出すんですけど, かなり時間を食います. これが開発者にとって5が4よりも遅いように感じる要因なのではないでしょうか. 私のラップトップで立ち上げた4と5は, 対話的な使い方では大体同じ程度の反応です.
Re:5.0R は不安定？ (スコア:0)
前に比べて中が相当いじられていますから、ドライバとかの相性があるのかもしれません。
しっくり来ると、ちゃんと本来の安定性を示してくれるんですけど…。
# 実際、手元ではインストールに失敗するってのが多いです。