4 files changed, 154 insertions, 10 deletions

diff --git a/ja/FAQ/misc.sgml b/ja/FAQ/misc.sgml
index 29b649fe3a..182f90b667 100644
--- a/ja/FAQ/misc.sgml
+++ b/ja/FAQ/misc.sgml
@@ -1,6 +1,6 @@
-<!-- $Id: misc.sgml,v 1.5 1998-08-20 04:13:58 hanai Exp $ -->
+<!-- $Id: misc.sgml,v 1.6 1998-10-15 23:35:09 motoyuki Exp $ -->
 <!-- The FreeBSD Japanese Documentation Project -->
-<!-- Original revision: 1.6 --> 
+<!-- Original revision: 1.7 --> 
 
   <sect>
     <heading>その他の質問<label id="misc"></heading>
@@ -86,7 +86,7 @@
       <tt>SunOS</tt>スタイルの共有ライブラリのメカニズムに極めて近い
       ものになっていて非常に使いやすいものになっています.
       しかしながら, FreeBSD では 3.0 から <tt/ELF/ バイナリをデフォルトの
-      フォーマットとしてサポートされるようになることでしょう. <tt/a.out/
+      フォーマットとしてサポートしています. <tt/a.out/
       実行フォーマットはよいものを私達に提供してくれているものの, 私達の
       使っているコンパイラの作者である GNU の人々は <tt/a.out/ フォーマット
       のサポートをやめてしまったのでした. このことは, 私達に別バージョンの
@@ -96,6 +96,78 @@
       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>
 
diff --git a/ja/FAQ/x.sgml b/ja/FAQ/x.sgml
index 93dd373974..9c79696bdb 100644
--- a/ja/FAQ/x.sgml
+++ b/ja/FAQ/x.sgml
@@ -1,4 +1,4 @@
-<!-- $Id: x.sgml,v 1.4 1998-10-15 23:11:54 motoyuki Exp $ -->
+<!-- $Id: x.sgml,v 1.5 1998-10-15 23:35:09 motoyuki Exp $ -->
 <!-- The FreeBSD Japanese Documentation Project -->
 <!-- Original revision: 1.5 --> 
 
@@ -217,7 +217,7 @@
       残せることと, ログアウト時に X サーバを再起動する責任を init に
       押しつけることができることでしょう. 
 
-      <bf以前のバージョンの FAQ では 
+      <p>以前のバージョンの FAQ では 
       <tt>/usr/X11R6/lib/X11/xdm/Xservers</tt> ファイルに X の使う
       <tt/vt/ を加えるように書いてあります. これは必要ありません:
       X は最初に見つけた利用可能な <tt/vt/ を使います. 
diff --git a/ja_JP.eucJP/FAQ/misc.sgml b/ja_JP.eucJP/FAQ/misc.sgml
index 29b649fe3a..182f90b667 100644
--- a/ja_JP.eucJP/FAQ/misc.sgml
+++ b/ja_JP.eucJP/FAQ/misc.sgml
@@ -1,6 +1,6 @@
-<!-- $Id: misc.sgml,v 1.5 1998-08-20 04:13:58 hanai Exp $ -->
+<!-- $Id: misc.sgml,v 1.6 1998-10-15 23:35:09 motoyuki Exp $ -->
 <!-- The FreeBSD Japanese Documentation Project -->
-<!-- Original revision: 1.6 --> 
+<!-- Original revision: 1.7 --> 
 
   <sect>
     <heading>その他の質問<label id="misc"></heading>
@@ -86,7 +86,7 @@
       <tt>SunOS</tt>スタイルの共有ライブラリのメカニズムに極めて近い
       ものになっていて非常に使いやすいものになっています.
       しかしながら, FreeBSD では 3.0 から <tt/ELF/ バイナリをデフォルトの
-      フォーマットとしてサポートされるようになることでしょう. <tt/a.out/
+      フォーマットとしてサポートしています. <tt/a.out/
       実行フォーマットはよいものを私達に提供してくれているものの, 私達の
       使っているコンパイラの作者である GNU の人々は <tt/a.out/ フォーマット
       のサポートをやめてしまったのでした. このことは, 私達に別バージョンの
@@ -96,6 +96,78 @@
       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>
 
diff --git a/ja_JP.eucJP/FAQ/x.sgml b/ja_JP.eucJP/FAQ/x.sgml
index 93dd373974..9c79696bdb 100644
--- a/ja_JP.eucJP/FAQ/x.sgml
+++ b/ja_JP.eucJP/FAQ/x.sgml
@@ -1,4 +1,4 @@
-<!-- $Id: x.sgml,v 1.4 1998-10-15 23:11:54 motoyuki Exp $ -->
+<!-- $Id: x.sgml,v 1.5 1998-10-15 23:35:09 motoyuki Exp $ -->
 <!-- The FreeBSD Japanese Documentation Project -->
 <!-- Original revision: 1.5 --> 
 
@@ -217,7 +217,7 @@
       残せることと, ログアウト時に X サーバを再起動する責任を init に
       押しつけることができることでしょう. 
 
-      <bf以前のバージョンの FAQ では 
+      <p>以前のバージョンの FAQ では 
       <tt>/usr/X11R6/lib/X11/xdm/Xservers</tt> ファイルに X の使う
       <tt/vt/ を加えるように書いてあります. これは必要ありません:
       X は最初に見つけた利用可能な <tt/vt/ を使います.