doc/ja_JP.eucJP/FAQ/misc.sgml

<!-- $Id: misc.sgml,v 1.11 1999-05-12 04:46:25 motoyuki Exp $ -->
<!-- The FreeBSD Japanese Documentation Project -->
<!-- Original revision: 1.16 --> 

  <sect>
    <heading>その他の質問<label id="misc"></heading>
    <p><em>訳: &a.yoshiaki;, &a.sugimura;, &a.fukuma;.
    <newline>10 November 1997 - 8 May 1999.</em>

    <sect1>
      <heading>
        FreeBSD は Linux より多くのスワップ領域を消費するのはなぜですか? 
      </heading>

      <p>FreeBSD は Linux よりもスワップを多く使っているように見えるだけです.
      実際にはそうではありません. この点における FreeBSD と
      Linux の主な違いは, FreeBSD はより多くのメインメモリを有効利用できるように
      するため, 完全にアイドルになったものやメインメモリ上の使われなくなった
      ページをスワップにあらかじめ積極的に移動しているということです.
      Linux では最後の手段としてページをスワップに移動させるだけという
      傾向があります. このスワップの使い方は, メインメモリをより効果的に
      使用することによってバランスが保たれています.

      <p>FreeBSD はこのような状況では先手策を取りますが, システムが
      本当に空き状態の時に, 理由も無くページをスワップしようと決めることはない
      ということに注意してください.
      したがって, 夜中に使わずにおいたシステムが
      朝起きたときにすべてページアウトされているということはないのです.

    <sect1>
      <heading>
        FreeBSD の実行フォーマットの a.out はどのようなものですか, a.out を使う理由, ELFを使う理由は何でしょう?
      </heading>

      <p>FreeBSD の <tt>a.out</tt>フォーマットを理解するためには, 
      まず UNIXにおいて現在 「優勢」な 3種類の実行フォーマットについて
      いくらか知っておく必要があります:

      <itemize>
        <item><htmlurl url="http://www.freebsd.org/cgi/man.cgi?a.out(5)"
        name="a.out">

        <p>最も古く 「由緒正しい」 unix オブジェクトフォーマットです. 
        マジックナンバを含む短くてコンパクトなヘッダが先頭にあり, 
        これがフォーマットの特徴とされています (参照
        <htmlurl url="http://www.freebsd.org/cgi/man.cgi?a.out(5)"
        name="a.out(5)"> 
        より詳細な内容があります). ロードされる 3種類のセグメント:
        .text, .data, .bss と加えてシンボルテーブルと文字列テーブルを
        含みます. 

        <item><bf>COFF</bf>
        <p>SVR3 のオブジェクトフォーマットです. ヘッダは単一の
        セクションテーブルから成り,  .text, .data, .bss セクション以外
        の部分を持つことができます. </item>

        <item><bf>ELF</bf>
        <p> <tt/COFF/の後継です. 複数のセクションをサポートし, 32-bit
        と 64-bitのいずれの値も可能です. 大きな欠点の一つは, <tt/ELF/ 
        はそれぞれのシステムアーキテクチャ毎に単一の ABI のみが存在する
        という仮定で設計されていることです. この仮定はまったく
        正しくありません. 商用の SYSV の世界でさえそうです 
        (少なくとも SVR4, Solaris, SCO の 3種類の ABI があります). 

        <p>FreeBSD はこの問題を解決するための試みとして, 既知の <tt/ELF/
        実行ファイルに ABI に応じた情報を <em>書き加える</em>
        ユーティリティを提供しています.
        <htmlurl url="http://www.freebsd.org/cgi/man.cgi?brandelf"
        name="brandelf"> のマニュアルページ
        を参照してください. より多くの情報があります. 
      </itemize>

      <p>FreeBSD は伝統的な立場をとり, 数多くの世代の BSD のリリース
      で試され, 実証されてきた
      <htmlurl url="http://www.freebsd.org/cgi/man.cgi?a.out(5)"
      name="a.out">フォーマットを伝統的に使用しています. 
      いつかは FreeBSDシステムでネイティブ <tt/ELF/ バイナリを作り, 
      実行することができるようになるかもしれませんが, 初期の頃 FreeBSD
      では <tt/ELF/ をデフォルトのフォーマットに変更するという動きは
      ありませんでした. なぜでしょうか? ところで Linux においては, 
      <tt/ELF/ への苦痛をともなった変更は, その時に <tt/a.out/ 
      実行フォーマットから逃れたというよりは, ジャンプテーブルベース
      の共有ライブラリのメカニズムの柔軟性の低さからの脱却でした. 
      これはベンダや開発者全体にとって共有ライブラリの作成が非常に
      難しかった原因でした. 
      <tt/ELF/のツールには共有ライブラリの問題を
      解決することができるものが提供されており, またいずれにせよ
      一般的に「進歩」していると考えられます. このため移行のコストは
      必要なものとして容認され, 移行はおこなわれました. 

      <p>FreeBSDの場合は, 共有ライブラリのメカニズムは Sun の
      <tt>SunOS</tt>スタイルの共有ライブラリのメカニズムに極めて近い
      ものになっていて非常に使いやすいものになっています.
      しかしながら, FreeBSD では 3.0 から <tt/ELF/ バイナリをデフォルトの
      フォーマットとして公式にサポートしています. <tt/a.out/
      実行フォーマットはよいものを私達に提供してくれているものの, 私達の
      使っているコンパイラの作者である GNU の人々は <tt/a.out/ フォーマット
      のサポートをやめてしまったのでした. このことは, 私達に別バージョンの
      コンパイラとリンカを保守することを余儀なくされることとなり, 最新の
      GNU 開発の努力による恩恵から遠ざかることになります. その上, ISO-C++
      の, とくにコンストラクタやデストラクタがらみの要求もあって, 今後の
      FreeBSD のリリースでネイティブの <tt/ELF/ のサポートされる方向へと
      話が進んでいます.


    <sect1>
      <heading>それにしても, なぜそんなに多くのフォーマットがあるのですか?</heading>

      <p>もうおぼろげになってしまった暗い過去に, 単純なハードウェアが
      ありました.  この単純なハードウェアは, 単純で小さなシステムを
      サポートしていました. a.out はこの単純なシステム (PDP-11) での
      作業を行なうバイナリとして完全に適したものだったのです.
      人々はこの単純なシステムから UNIX を移植する際に, a.out
      フォーマットをそのまま使いました. というのは Motorola 68k, VAXen,
      といったアーキテクチャへの UNIX の初期の移植ではこれで十分だったからです.

      <p>やがてある聡明なエンジニアがソフトウェアでちょっとした
      トリックを使うことを決めました.  彼はいくつかのゲートを削り取って
      CPU のコアをより速く走らせることができたのです.  これは
      新しい種類のハードウェア (今日では RISC として知られています) で
      動いたのです.  <tt/a.out/ はこのハードウェアには
      適していなかったので, このハードウェア上で多くのフォーマットが,
      限定された単純な <tt/a.out/ フォーマットでのものよりもより良い
      パフォーマンスを出すことを目指して開発されたのです.
      <tt/COFF/, <tt/ECOFF/, そしていくつかの有名でないフォーマットが
      <tt/ELF/ が標準になる前に開発され, それらの限界が探求されたのです.

      <p>さらに, プログラムサイズは巨大になり, ディスク (および物理メモリ)
      は依然として相対的に小さかったため, 共用ライブラリのコンセプトが
      誕生しました.
      また, VM システムはより複雑なものになりました.
      これらの個々の進歩は <tt/a.out/ フォーマットを使用して遂げられましたが,
      その有用性は新しい機能とともにどんどん広がってきました.
      これらに加え, 実行時に必要なものを動的にロードする, または
      初期化コードの実行後にプログラムの一部を破棄し, コアメモリおよび / 
      またはスワップ空間を節約するという要望が高まりました.
      プログラミング言語はさらに複雑になり, main 関数の前に自動的に
      コールされるコードの要望が高まりました.
      多くの機能拡張がおこなわれ, <tt/a.out/ フォーマットがこれらすべてを
      実現できるようになり, それらはしばらくは基本的に動作していました.
      やがて, <tt/a.out/ はコードでのオーバヘッドと複雑さを増大させずに
      これらの問題すべてを処理することに無理がでてきました.
      一方, <tt/ELF/ はこれらの問題の多くを解決しますが, 現状稼働している
      システムからの切替えは厄介なものになるでしょう.
      そのため <tt/ELF/ は, <tt/a.out/ のままでいることが<tt/ELF/ への
      移行よりももっと厄介なものになるまで待つ必要がありました.

      <p>しかし時が経つにつれ, FreeBSD のビルドツールの元となったツー
        ル群(特にアセンブラとローダ)と FreeBSD のビルドツール群は異なっ
        た進化の経路をたどりました. FreeBSD のツリーでは, 共有ライブラ
        リが追加され, バグフィックスも行われました. もともとのツール群
        を作成した GNU の人たちは, プログラムを書き直し, クロスコンパ
        イラのサポート, 異なるフォーマットを任意に取り込む機能などを追
        加していきました. 多くの人々が FreeBSD をターゲットとしたクロ
        スコンパイラの構築を試みましたが, FreeBSD の使っている as と 
        ld の古いプログラムコードはクロスコンパイルをサポートしておら
        ず, うまくいきませんでした. 新しい GNU のツール群 (binutils) 
        は, クロスコンパイル, 共有ライブラリ, C++ 拡張などの機能をサポー
        トしています. さらに数多くのベンダが <tt/ELF/ バイナリをリリー
        スしています.  FreeBSD にとって <tt/ELF/ バイナリが実行できる
        ことは, 非常にメリットがあります. <tt/ELF/ バイナリが FreeBSD 
        で動くのなら, <tt/a.out/ を動かすのに手間をかける必要はありま
        せんね. 長い間忠実によく働いた老いた馬は, そろそろ牧草地で休ま
        せてあげましょう.

      <p><tt/ELF/ は a.out に比べてより表現力があり, ベースのシステム
        に対してより幅広い拡張性を提供できます. <tt/ELF/ 用のツールは
        よりよく保守されています. また多くの人にとって重要なクロスコン
        パイルもサポートしています. <tt/ELF/ の実行速度は, ほんの少し 
        a.out より遅いかもしれませんが, 実際に速度の差をはかるのは困難
        でしょう. <tt/ELF/ と a.out の間には, ページマッピング, 初期化
        コードの処理など多くの違いがありますが, とりたてて重要なものは
        ありません. しかし違いがあるのは確かです. ほどなく, GENERIC カー
        ネルから <tt/a.out/ のサポートが外さます. <tt/a.out/ のプログ
        ラムを実行する必要性がなくなれば, 最終的に <tt/a.out/ のサポー
        トはカーネルから削除されます.

    <sect1>
      <heading>なぜシンボリックリンクのパーミッションは chmod で変えられないのですか?</heading>

      <p>この場合, ``<tt/-H/'' か ``<tt/-L/'' のどちらかのオプションを 
      ``<tt/-R/'' と同時に使う必要があります. 
      <htmlurl url="http://www.freebsd.org/cgi/man.cgi?chmod"
      name="chmod"> と
      <htmlurl url="http://www.freebsd.org/cgi/man.cgi?symlink" 
      name="symlink"> のマニュアルページにはもっと詳しい情報があります. 

      <p><bf/注意/ ``<tt/-R/'' オプションは <bf/再帰的に/ <tt/chmod/
      を実行します. ディレクトリやディレクトリへのシンボリックリンクを 
      <tt/chmod/ する場合は気をつけてください. シンボリックリンクで
      参照されている単一のディレクトリのパーミッションを変更したい場合は,
      <htmlurl url="http://www.freebsd.org/cgi/man.cgi?chmod" name="chmod"> 
      をオプションをつけずにシンボリックリンクの名前の後ろにスラッシュ 
      (``<tt>/</tt>'') をつけて使います. 例えば, ``<tt/foo/'' がディレクトリ 
      ``<tt/bar/'' へのシンボリックリンクである場合, ``<tt/foo/'' (実際には 
      ``<tt/bar/'') のパーミッションを変更したい場合にはこのようにします:

      <verb>
        chmod 555 foo/
      </verb>

      <p>後ろにスラッシュをつけると,
      <htmlurl url="http://www.freebsd.org/cgi/man.cgi?chmod"
      name="chmod"> はシンボリックリンク 
      ``<tt/foo/'' を追いかけてディレクトリ ``<tt/bar/'' 
      のパーミッションを変更します. 

    <sect1>
      <heading>
        login 名が<bf/いまだに/ 8文字に制限されているのはなぜですか
      </heading>

      <p> <bf/UT_NAMESIZE/を変更して全体を作り直せば十分で, それだけで
      うまくいくだろうとあなたは考えるかもしれません. 
      残念ながら多くのアプリケーションやユーティリティ
      (システムツールも含めて) は小さな数値を構造体やバッファなどに
      使っています ( 必ずしも "8" や "9" ではなく, "15" や "20" 
      などの変った値を使うものもあります).  (固定長のレコードを期待
      するところで可変長レコードになるために) 台無しになった
      ログファイルを得ることになるということだけでなく, Sun の NIS の  
      クライアントの場合は問題が起きますし, 他の UNIX システムとの関連
      においてこれら以外の問題も起きる可能性があります.

      <p>しかし, FreeBSD 3.0 以降では 16文字となり, 多くのユーティリティ
      のハードコードされた名前の長さの問題も解決されます. 実際には
      システムのあまりに多くの部分を修正するために, 3.0 になるまでは
      変更が行われませんでした.

      <p>それ以前のバージョンでは, これらの問題が起こった場合に, 問題
      を自分自身で発見し, 解決できることに絶対的な自信がある場合は 
      /usr/include/utmp.h を編集し, UT_NAMESIZE の変更にしたがって,
      長いユーザ名を使うことができます.
      また, UT_NAMESIZE の変更と一致するように 
      /usr/include/sys/param.h の MAXLOGNAME 更新しなくてはなりません.
      最後に, ソースからビルドする場合は  /usr/include を毎回
      アップデートする必要があることを忘れないように! 
      /usr/src/.. 上のファイルを変更しておいて置き換えましょう.</p>

    <sect1>
      <heading>FreeBSD 上で DOS のバイナリを動かすことはできますか? </heading>

      <p>はい, 3.0 からは, 統合と改良が重ねられた BSDI の <tt/rundos/
      DOS エミュレーションサブシステムを使ってできるようになりました.
      今なお続けられているこの努力に興味を持って参加していただけるなら
      <url url="mailto:freebsd-emulation@freebsd.org"
      name="The FreeBSD emulation discussion list">
      へメールを送ってください. 

      <p>3.0 以前のシステムでは, 
      <htmlurl url="http://www.freebsd.org/cgi/ports.cgi?^pcemu" 
      name="pcemu"> という巧妙なユーティリティが ports 
      コレクションにあり, 8088 のエミュレーションと DOS の
      テキストモードアプリケーションを動かすに十分な BIOS 
      サービスをおこないます. これは X ウィンドウシステムが必要です 
      (XFree86 として提供されています)

    <sect1>
      <heading>
        ``<tt/sup/'' とは何で, どのようにして使うものなのでしょうか?
      </heading>

      <p><htmlurl url="http://www.freebsd.org/cgi/ports.cgi?^sup" 
      name="SUP">
      とはソフトウェアアップデートプロトコル (Software Update
      Protocol) で CMU で開発ツリーの同期のために開発されました. 
      私たちの中心開発ツリーをリモートサイトで同期させるために
      使っていました. 

      <p>SUP はバンド幅を浪費しますので, 今は使っていません. ソースコードの
      アップデートの現在のおすすめの方法は <url
      url="../handbook/synching.html#CVSUP" name="ハンドブックの CVSup の項"> 
      にあります. 

    <sect1>
      <heading>FreeBSD をクールに使うには?</heading>

      <p>Q. FreeBSD を動かす時に温度測定をおこなった人はいますか? Linux 
      は dos よりも温度が下がるということは知っていますが, FreeBSD
      についてはこのようなことに触れたものを見たことはありません. 
      実際熱くなっているように見えます. 

      <p>A. いいえ. 私たちは 250 マイクログラムの LSD-25 をあらかじめ
      与えておいたボランティアに対する目隠し味覚テストを大量に
      おこなっています. 
      35% のボランティアは FreeBSD はオレンジのような味
      がすると言っているのに対し Linux は紫煙のような味わいがある
      と言っている人もいます. 私の知る限り両方のグループとも温度の
      不一致については触れていません. この調査で, 非常に多くの
      ボランティアがテストをおこなった部屋から不思議そうに出てきて, 
      このようなおかしな結果を示したことに私たちは当惑させられました. 
      私は, ほとんどのボランティアは Apple にいて彼らの最新の
      「引っかいて匂いをかぐ」 GUI を使っているのではないかと
      考えています. 私たちは奇妙な古い仕事をしているのでしょう!

      <p>真面目に言うと, FreeBSD や Linux は共に ``<tt/HLT/'' (停止) 
      命令をシステムのアイドル時に使い, エネルギーの消費を押えて
      いますので熱の発生も少なくなります. また, APM (automatic power
      management) を設定してあるなら FreeBSD は CPU をローパワーモード
      にすることができます.

    <sect1>
      <heading>誰かが私のメモリカードをひっかいているのですか??</heading>

      <p>Q. FreeBSDでカーネルのコンパイルをしている時にメモリから
      引っかいているような奇妙な音が聞こえるようなことはあるのでしょうか? 
      コンパイルをしている時 (あるいは起動時にフロッピドライブを
      認識した後の短い間など), 奇妙な引っかくような音がメモリカードの
      あたりから聞こえてきます.

      <p>A. その通りです. BSDのドキュメントでしばしば「デーモン」に
      ついて述べられている理由がわかるでしょう. しかし多くの人は本当の
      事については触れていません. 非物質的な存在があなたのコンピュータ
      にあるのです. メモリからの引っかいたような音は, 実際に色々な
      システム管理タスクの扱いをいかに最善なものにするかという内容を交わす, 
      デーモンたちのかん高いささやきなのです.

      <p>「雑音」があなたに DOS プログラムの ``<tt>fdisk /mbr</tt>'' 
      を使ってうまくささやきを取り除かせようとしているように聞こえても, 
      彼らは逆にそうすることをやめさせようとしているのかもしれません. 
      本当は内蔵スピーカからのビル ゲイツの悪魔的な声が
      あなたに影響を与えているのかもしれません. 
      実行するのは止めましょう, そして振り返ってはいけません!
      BSD の守護神 (daemon) の力により, 
      繰り返しあなたのマシンを支配下に置こうとし, あなたの魂を
      無限地獄に突き落そうとする DOSと Windows の双子の悪鬼 (demon) の
      影響から自由になりましょう. 
      選択の機会は与えられました. 私自身はこの引っかくような音が
      聞こえていたことを嬉しく思っています. 

    <sect1>
      <heading>'MFC' とはどういう意味ですか</heading>

       <p>MFC とは 'CURRENT との合流(Merged From -CURRENT.)'の
       頭文字をとったものです. CVS ログで CURRENT から STABLE ブランチ
       への合流を示します.

    <sect1>
      <heading>'BSD' とはどういう意味ですか</heading>

      <p>この言葉は, 仲間うちだけに分かる隠語で何とかという意味です.
      文字どおりに訳すことはできませんが, BSD の訳は「F1 のレーシング
      チーム」か「ペンギンはおいしいスナック」, あるいは「俺たちゃ
      Linux より洒落は利いてるぜ」とかそのへんだと言っておけばおっけー
      でしょう. :-)

      <p>閑話休題. BSD とは, Berkeley CSRG (コンピュータシステム
      評議会) が彼らの UNIX の配布形態の名前として当時選んだ
      'Berkeley Software Distribution' の略です.

    <sect1>
      <heading>ひとつの電球を取り替えるのに, 何人の FreeBSD ハッカーが必要?</heading>

      <p>1,172人です.

      <p>電球が消えていると -current で文句を言うのに 23人,

      <p>設定上の問題で -questions で話をすべきことについて騒ぐのに
      4人,

      <p>それを send-pr (訳注: 障害報告) するのに 3人 (そのうちの
      ひとつは間違って doc カテゴリに送りつけられたうえに, 内容が「暗くなった」
      というだけのもの),

      <p>buildworld を失敗させ, 5分後には元に戻されるような電球を
      テストもせずにコミットするのに 1人,

      <p>send-pr した人に, パッチが含まれていないといちゃもんを
      付けるのに 8人,

      <p>buildworld が失敗すると文句を言うのに 5人,

      <p>自分のところではちゃんと動く, cvsup したタイミングが
      悪かったんだろうと答えるのに 31人,

      <p>新しい電球のためのパッチを -hackers に投げるのに 1人,

      <p>自分は 3年も前にパッチを作ったが, それを -current に投げた
      ときには無視されただけだった, 自分は send-pr のシステムには嫌な経験が
      あると (おまけに, 提案された新しい電球には柔軟性が無いとまで)
      文句を言うのに 1人,

      <p>電球が基本システムに組み込まれていない, committer は
      コミュニティの意見を聞くこと無しにこんなことをする権利は無いと
      叫び, 「こんなときに -core は何をやってるんだ!?」とわめき
      ちらすのに 37人,

      <p>自転車置き場の色に文句を言うのに 200人,

      <p>パッチが style(9) 違反だと指摘するのに 3人,
 
      <p>提案された新しい電球は GPL の下にあると文句を言うのに 70人,

      <p>GPL と BSD ライセンスと MIT ライセンスと NPL と, 某 FSF
      創立者らの個人的な健康法の優位性についての論争を戦わすのに
      586人,

      <p>スレッドのあちこちの枝を -chat や -advocacy に移動するのに
      7人,

      <p>提案された電球を, 古いのよりずっと薄暗いのに
      コミットしてしまうのに 1人,

      <p>FreeBSD に薄暗い電球を付けるくらいなら真っ暗のほうがましだ,
      という, コミットメッセージへの凄まじい非難の嵐によって, それを
      元に戻すのに 2人,

      <p>薄暗い電球が帳消しにされたことに対してどなり声で口論し,
      -core の声明を要求するのに 46人,

      <p>もし FreeBSD をたまごっちに移植することになったときに
      都合がいいように, もっと小さな電球を要求するのに 11人,

      <p>-hackers と -chat の S/N比に文句を言い, 抗議のため講読を
      取りやめるのに 73人,

      <p>「unsubscribe」 「どうやったら講読をやめられるんですか?」
      「このメーリングリストからわたしを外してください」といった
      メッセージを, 例のフッタをくっつけて投稿するのに 13人,

      <p>みんなが激論を戦わせるのに忙がしくて気付かない間に, 作業中の
      電球をコミットするのに 1人,

      <p>新しい電球は TenDRA を使ってコンパイルされた場合に 0.364% も
      明るくなる (ただし電球を立方体にしなければならないが), だから
      FreeBSD は EGCS から TenDRA に変えるべきだと指摘するのに 31人,

      <p>新しい電球は美しさに欠けていると文句を言うのに 1人,

      <p>「MFC って何ですか?」と聞くのに 9人 (send-pr した人も含む),

      <p>電球が取り替えられてから 2週間も消えっぱなしだと文句を
      言うのに 57人.

      <p><em>以下は <url url="mailto:nik@freebsd.org"
      name="Nik Clayton"> による追記:</em>

      <p><em/これには爆笑しました./

      <p><em/それからわたしは考えました. 「ちょっと待てよ, この
      リストのどこかに『これを文書にまとめるのに 1人』というのが
      あってもいいんじゃないか?」/

      <p><em/それからわたしは悟りを開いたのです :-)/

      
  </sect>