ChangeLog
メール版
登録

ChangeLog

なぜドライバをクローズドにするとベンダは損をするのか

「 （ハードウェアベンダが、そのデバイスドライバのソースコードを） クローズドにし続けた場合、通常はオープンソースとクローズドソ ースの悪いところばかりがふりかかることになる。あなたの秘密は暴 露され、フリーな開発支援は得られず、より頭の悪い競合相手ら がク ローン製作で時間を浪費することもなくなる。 」

しかし最も重要なのは、ハードウェアベンダにとっては 「ハードウェアの販売が収入源」であるということです。 ドライバが入手困難であったり、 頻繁にアップデートしなければならなかったり、 もっと悪いことには、 動作状態が良くなかったりすると、 商品であるハードウェアが悪く見えることになり、 売上は減少するでしょう。 売上が減少すれば、収益も減少。 そういうことです。

17　補遺: なぜドライバをクローズドにするとベンダは損をするのか

　歴史的に、（イーサネットカード、ディスクコントローラ、ビデオ ボードのよ うな）周辺機器のメーカはオープンにするのを渋ってき た。これは今では変わっ てきていて、Adaptec や Cycladesのようなメー カは自社ボードの仕様とドラ イバのソースコードを当たり前のように 公開し始めている。でも、 一般的には、オープンにすることに対して まだ抵抗がある。この補遺では、そ のような抵抗を長らえさせてい る、いくつかの経済的な誤解を晴すことを試み る。

　ハードウェアのドライバをオープンソース化することに対して出て くる異議の一つは、それがハードの仕組みについて重要な情報を明ら かにしてしまうので、それが競争相手にコピーされて、不公平な競争 優位を与えてしまう、というものだ。製品サイクルが 3 年から 5 年だ った昔なら、これは議論としてなりたっただろう。でも、いまでは競 争相手のエンジニアたちが製品をコピーし、コピーした物を理解する のに費やす時間で、製品サイクルの大半はもう終わってしまってい る。そしてその間に、その連中は自分の製品を革新したり、差別化し たりできなくなるわけだ。盗用は罠で、むしろあなたとしては、競争 相手がそれにはまってほしいと願うべきなんだ。

　いずれにしても最近では、そのような詳細はそう長く隠し通せるも のではない。 ハードウェアのドライバは OS やアプリケーションとは ちがって、小さくて、 逆アセンブルが簡単で、クローンを作るのは簡 単だ。ティーンエイジの初 心者プログラマにだってできる ―― そして 頻繁に行われていることだ。

　Linux や FreeBSD のプログラマで、新しいボード用のドライバを書く 能力と 動機を兼ね備えている人は、文字通り何千といる。これらの熱 心なハッカー たちは、比較的単純なインターフェースと良く知られた 標準規格とを持つ（ディスク コントローラやネットワークカードのよ うな）多くの種類の装置に関して、君 （ハードウェアベンダ）自身の ショップと同じくらいの速さでドライバのプロ トタイプを作ってしま うことがよくある。しかも、ドキュメント無しで、既存 のドライバを ディスアセンブルしたりもしないで、だ。

　ビデオカードのような扱いにくいデバイスについても、逆アセンブ ラで武 装した頭のいいプログラマを止める方法なんてほとんどない。 そんな にお金はかからないし、法的な障壁も穴だらけだからだ。Linux は国際的なプロジェクトだから、リバースエンジニアリング が合法な 司法的管轄地域がいつだってどこかしらに存在している。

　これらの主張が真である動かぬ証拠としては、Linux カーネルでサポ ートされ ているデバイスのリストや Metalab のようなサイトのドライバ のセクションを良く見てみるといい。そして新しい ものが追加される 速度に注目だ。

　つまり、何が言いたいか？ドライバを秘密にしておくのは、短期的 には魅力的 に見えるけど、おそらく長期的にはまずい戦略だ。（すで にオープンにしてい る他のベンダと競合している場合には確実に ね。）でもどうしてもクローズド にしておく必要がある場合は、オン ボード ROM にコードを焼き付けるんだ。 そして、それへのインター フェースを公開する。あなた（ハードウェアベンダ）の 市場を構築す るために、また、あなたが重要な点において競争相手よりもより良く 考え、より優れて革新できる能力に自信を持っているということを潜 在的顧客 に示すために、可能な限りオープンにしよう。

　クローズドにし続けた場合、通常はオープンソースとクローズドソ ースの悪いところばかりがふりかかることになる。あなたの秘密は暴 露され、フリーな開発支援は得られず、より頭の悪い競合相手ら がク ローン製作で時間を浪費することもなくなる。最も重要なこと は、早 期採用を普及させる手段を君が取り逃してしまうことだ。巨大で影響 力 のある市場（インターネットのすべてとビジネスデータセンターの 17％以上 を効果的に運用するサーバを管理している人々）は、君が以 上のようなことを 理解しなかったという理由で、君の会社をわかって なくて自己防衛過剰だと正しく見限 るだろう。そして、ちゃんとわか っている他のだれかからボードを買うことにな るんだ。

バーティカルマーケットにおけるオープンソースプロジェクト

FreePM プロジェクトの6月28日のアナウンスにも通じる、 氏の考え方と計画がまとめられています。 バーティカルなオープンソースソフトウェアの有望性と、 そのようなプロジェクトを管理することの潜在的な難点等が 議論されています。

「多くのオープンソースのバーティカルマーケットなアプリケーションは、 実際、インハウス（自社開発）か趣味のプロジェクトとして始められています。 そのような場合、 克服すべき最も難しい点の一つは、 必要に応じて感情的な思い入れ（と実際に良い解決法と）を 分離することです。 」

Comdex Canada：Linux パビリオンレポート

「 トロント・コンベンション・センターの大きな北ホールのバックコーナーに 詰め込まれた Linux パビリオンでしたが、 Linux には人が群がる、ということを再び証明していました。 初日のほとんどを通して、通路は混んでいました。 Linux シアターでのプレゼンテーションも ほぼすべてが立ち見しかなく、 質問が矢のように飛んでいました。」

より高度なサポートサービス

単なる動作確認情報の提供やインストール・導入支援ばかりに留まらず、 カーネルにまで踏み込んだサポートが提供されるようになります。

詳しくは、こちらをご覧下さい。

• でんさテクノ東京（米 LinuxCare 社との提携によって。）
• 日本SGI （日経BP社の記事）

※ SGI の xfs 提供に関しては、発表当時（1999年5月）linux-kernel ML にもか なりの反響を呼び、当然 LWN でも取り上げられました。 ChangeLog ではカットされていましたので、 カーネルコーナのおまけとして付けておきました。

プロジェクト Dice 発進、PJE は開発中止へ

プロジェクト Dice に関しては、 詳しくは今週のディストリビューションコーナー （もちろん新ディストリビューションのコーナーでは「ありません」 ;-） をご覧下さい。

PJE 開発中止に関するアナウンスはまだ公開されていないようなので、 詳細は不明です。日経BP社の Linux Exhibition '99 で発表されたそうです。 （日本の Linux 情報のページ で知りました。 （※ ところで、元 JLA のトップページであるこのページは ユーザ有志からなるボランティア集団 によって運営されるように 運営主体（体制）が変っているそうです。） ）

Lotus に関して（先週のニュース補足）

LWN のバックページへの投稿（英語）で、 LinuxToday で プレスリリース（英語） を発表した会社の方が、 Linux 上で走る Lotus Notes クライアントと IBM 内部での動きに関して言及しました。

それに対し、 Oracle の時も同じようなことがありました （Oracle が正式に Linux をサポートする以前にも、 SCO Unix 用の Oracle を iBCS エミュレーションを利用して Linux 上で稼働させることは可能でした）が、 企業での導入という観点からは、 「動く」ということと「サポートされている」ということとは 全く別物であるとの 指摘（英語） がなされました。

※こちら （日本語）に（Linux ではありませんが）Netware に関する 同じような事例が紹介されています。

オープンソース関連文書の日本語訳

• 黙ってソースコードを見せな（日本語）

yomoyomo さんは、 山形浩生氏のページ（日本語）で公開されている ハロウィーン文書FAQ （日本語）を翻訳された方です。

Technical Knockout （日本語）のページには、 その他にも主にコンピュータ・インターネット関連の 興味深い翻訳・オリジナル文書が20篇近くも公開されています。

また、オープンソース関連の翻訳文書としては、 他にも３つ公開されています。 すべて、 わたくし、倉骨訳『オープンソース・ソフトウェア』（オライリー） の翻訳に深い憂慮を抱くものでございます。（山形浩生氏。日本語） （このページ自身に関してはまた後日お伝えさせていただく予定です。） から辿れます。

• ハッカー界小史（日本語） （ A Brief History of Hackerdom（英語）） Eric S. Raymond 著, 山形浩生 訳.
• ハッカーの復讐（日本語） （The Revenge of the Hackers（英語）） Eric.S.Raymond 著, 中元崇と黒木掲示板の常連の皆様方 訳.
• ハッカーの逆襲（日本語） （The Revenge of the Hackers（英語）） Eric.S.Raymond 著, 稲葉祐之訳.

そして、もちろん、 （最近の ChangeLog ではご紹介できませんでしたが） JF プロジェクト （日本語） の方々が多くの文書をコンスタントに公開してくださっています。

「死の青い画面」に永遠の別れを告げる画期的ツール！？

でも面白すぎるので、、、

かの有名な BSOD（"blue screen of death" 「死の青い画面」）は、 実は「設定可能」だということが分かりました。 便利なツール （英語） があって、より好ましい色に変えられるということです。

（訳あって）Linux がインストール出来ない場合は、 おそらくこの方法が BSOD から永久に逃れるためには いちばん簡単な方法だと思われます。 (Found in NTK)

Linus の米 Transmeta 社の極秘プロジェクト、遂に明らかに！？

詳細は、近いうちに Metamiga （英語） に現れるはずです。

とうとう、Linus が何を企んでいたのか分かるときが来たのかも知れません、、、 (Thanks to Anthony Kilna)

※ こちらの記事 （日刊ASCII Linux「次世代AMIGAの謎とLinuxの怪しい関係 」）もご参照下さい。

Mindcraft 事件で、何故 Linux コミュニティは騒ぎ立てたのか？

「Linuxが進むべき方向を示す PC WEEKラボのテスト」（ZDNet。日本語） や 「PC Weekの監査のもと米MindcraftがWindows NT Server 4.0とLinux を公開ベンチマーク，「やはりNTが速い」」（日経BP。日本語） の中で、Linux が NT に「やはり」勝てなかったという表現があります。

これではあまりにも Linux コミュニティが滑稽なので、 少し弁解させてください。 ;-）

結論から書きますと、実際には、 （少なくとも NT クライアントに対するファイルサーバに関しては） あまりにもタイムリーな発見による Microsoft の逆転大勝利という「予想外」の結果だったという表現 が適切だったのではないでしょうか。

まず、Open Benchmark に対する Mindcraft との対話で、 Mindcraft 側が最終的に Linux 側の要求に応える形で、 NT クライアントに対するファイルサーバのテストを ベンチマークに含めることを了承したことは、 ほとんどの方にとってかなりの驚き（それこそ正に予想外）でした。

そして、多くの方は、ファイルサーバに関しては NTクライアントに対するテストも追加されたことから、 オープンベンチマークの条件の下でも Samba が勝てると思っていました。 （Apache （hosted by Linux）は、 オープンベンチマークの条件下では負けるだろうと予想されていました。）

何故なら、ファイルサーバベンチマークにおいて、 95(98) をクライアントにした場合には NT が勝ち、 NT クライアントの場合には Linux が勝つ、 という結果が広く知れ渡っていたからです。 （例えば、 PC Week: Drilling down into Windows NT, Samba tests（ZDNet。英語） をご覧下さい。）

（※Linux 側が、NT をクライアントに含めるように要求していたのは、 （もちろんそうすれば勝つことが分かっていたからでもありますが ;-） 95に欠けているセキュリティと信頼性（安定性や耐故障性）の面で、 NT の方が 95 よりも企業向けデスクトップとして優れており、 また、マイクロソフト自身によって 95/98 のコードベースよりも、 NT のコードベースの方が「デスクトップシステムとしての将来性」を 約束されているのだから、NT をクライアントとして全く含めないのは、 不自然だということを根拠にしていました。）

では、何故 Mindcraft (Microsoft) が「予想外」の逆転大勝利を収めること が出来たのかというと、 「Linuxが進むべき方向を示す PC WEEKラボのテスト」（ZDNet。日本語） によれば、

　われわれは以前，Sambaが NTワークステーションのク ライアントを使ったNT 4.0（ “「企業にとって最適な NOSとは？　PC WEEKラボ が徹底的に比較検証する」 を参照）のパフォーマンス を上回ることを発見してい る。この対決が直接の要因 となり，Microsoftのパフォ ーマンスエンジニアはNTサ ーバからNTワークステーシ ョンクライアントへのファ イルスループットを向上さ せる手段の発見に取り組む こととなった。

　NTFS（NT File System）を詳細に調 べたMicrosoftは，データのボリュームが 単一のパーティションとしてコンフィギュ レーションされていると，NTFSのトラン ザクションログの競合がファイルトランザ クションを大幅に低下させることを発見し た。

　データのボリュームを4つのNTFSパー ティションに分割することで（それぞれに トランザクションログが置かれる），トラ ンザクションの書き込みを分散し，ボトル ネックを排除することができた。

そして、おそらくこの tips は （少なくとも一般向けには） 先のオープンベンチマークで初公開されたものでした。 したがって、それを知っていた Mindcraft (Microsoft) 以外の方にとっては、 全くの予想外の結果であった、というわけです。

実際の数値（超概算）で言うと、 以前は、NT サーバの NT クライアントに対する性能は 100〜150 Mbps くらい で、98 クライアントに対する性能は 300を越えていました。 一方、Samba／Linux は NT クライアントに対しても 98 クライアントに対しても、 150 〜 200程度の性能でした。 しかし今回、Microsoft が NT クライアントに対するボトルネックを 解消した結果、NT サーバは、95/98/NT のいずれに対しても、 300を越える性能を発揮することができるようになった、 ということです。

（※ この NT サーバの NT クライアントに対する性能を向上させる tips はありそうな話ですぐに理解できたのですが、 何故、95クライアントに対する性能にはほとんど影響がなく、 NT クライアントに対する性能だけを2倍にも改善するのかが、最初 ChangeLog には理解できませんでした。;-）

なお、 「Linuxが進むべき方向を示す PC WEEKラボのテスト」（ZDNet。日本語） において、Jeremy Allison 氏（Samba開発者）が、

「PC WEEK が5月に行ったマルチOSテストが公正かつ公平なものだったと思っ たので、Microsoft が宣伝に使うとしか考えられないテストに参加する意義を 見い出せなかった」

最後に、Samba の名誉のために、 Linux Today での Jeremy Allison 氏の発言（投稿） （英語） を引用させていただきます。

実際には、 Samba が NT クライアントに対するサーバとして優れているということではなく、 NT クライアントの場合には Win9x クライアントよりも劣るということなんだ。 （意味通じるかな :-）

NT は何年も Win9x クライアントのサーバとして最適化されてきた。 最近まで、公開されているファイルサーバのベンチマークすべてにおいて クライアントに使用されていたのは Win9x だった。 Microsoft には NT クライアントのパフォーマンスを修正する インセンティブがなかった（もちろん、今はある :-）、だから 修正しなかったんだ。 それが、NT クライアントが Samba よりも NT サーバで パフォーマンスが悪い理由だ。 Samba は NT と Win9x の両クライアントに、 ほとんど同じパフォーマンスを提供する。 酷く性能が悪いのは NT サーバなんだ。 NT クライアントに対するサーバとしての場合にね。

ここで、Solaris の分析を以下のページで注意深く見てみよう。

ZDNet 記事（英語）

興味深い一節がある。

「 ボトルネックとなっているディスクサブシステムの影響を受けないようにするために、 テストファイルを保持しておく一時的な RAM ディスクを作成した。 これにより、 データのために RAID アレーをヒットする必要が効果的に除去された。 この設定では、 Solaris 7 のネットワークカーネルの強力な能力が爆発した -- NetBench で 360M bps を記録した。 」

これが意味するのは、 Samba を Solaris のようにちゃんと最適化された SMP OS 上で 走らせると（ディスクサブシステムのことは少し置いといて）、 Samba が他の *すべて* のシステムを打ち負かすパフォーマンスを示す 数字を産み出すということだ。 （NT のピーク値は、340 だと思う。） ここで Solaris をダメにしてしまっていたのは、 そのひどいディスクシステムなんだ。 Solaris の SMP はとても優れているから、 もっとマシなディスクファイルシステムがあれば、 Samba を Win95 クライアントのサーバとして使った時に、 NT を打ち負かすことができるだろうね。

これは、僕が SGI ラボで、 これまた素晴らしく最適化された SMP OS である IRIX （ただし優れたディスクファイルシステム、XFS がある :-） を使って得た結果とも一致するんだ。 SMP マシン上の IRIX と Samba を使用して、 NT を気持ち良く打ち負かすことができた。 でも IRIX は、SGI の MIPS マシン上でしか走らない。 （※ だから残念ながら NT との単純な比較はできない。）

これが Linux にとってどういう意味を持つのかというと、 Samba がここでボトルネックではないことから、 Linux カーネルでの SMP のスケーラビリティに関して もっと作業が必要だということなんだ。 現在僕は Samba 側で役に立てるよう、 ユーザ領域のキャッシュに関する作業を多くやっている。 でも、Linux には、後もう少し SMP の作業が必要とされているんだ。 でも心配ないよ。もうすぐさ。 （僕はこれに取り掛かっている人達を *いっぱい* 知ってるからね。）

Alan Cox 氏インタビュー「Linux 開発よりもずっと大切なこと。」

LWN が1999年1月に行ったインタビュー（英語） の日本語訳と、 その後、さらに追加の質問をさせていただき、 ChangeLog が LWN で 3月に公開したインタビュー （英語）の日本語訳です。

（当時の）感想としては、 一番の当事者達（カーネル開発者の方々）が実際にどう感じているのか を知ることが出来、大変感慨深く感じました。

「世界征服は間近だ。そしてそれは最初の一歩に過ぎない。」 という Linus の発言のニュアンスが分かったような分からないような。 ^^;

最も印象的だったのは、 （プレスや Linux を推す強気の企業ではなく） カーネル開発者自身は、 （まだ全然準備が出来てるつもりはないのに、 もうこんなんで良いの？という感じで） ビジネスに「突然」発見されたと思っている、ということでした。 2000年（2001年）というのは、 ミッションクリティカルなエンタープライズ用途に要求されるような スケーラビリティや耐故障性の向上に関連する機能の数々 （Linus の言葉を借りれば 「大抵の OS のパンフレットに載っている、 あーだこーだと書かれているもの」）が 安定カーネルに本格的に実装され枯れていく頃とちょうど重なる （と予想される）というのも、偶然ではないように思えます。

Linux はまだ最初の一歩を踏み出したばかりで、 本当にブレイク（躍進）するのはまだまだこれから。

だとしたら、大変楽しみですよね。

• Alan Cox 氏インタビュー（日本語）

関連 URL

LWN

LWN コラム原文（英語）