Update member list

jcontrib.sgml
    jmembers.sgml

Merge from English version:
    admin.sgml          1.11 -> 1.12
    misc.sgml           1.10 -> 1.16
    preface.sgml        1.20 -> 1.35
    network.sgml        1.22 -> 1.24
    x.sgml              1.6  -> 1.8

Submitted by: FreeBSD Japanese Documentation Project
                Ichimiya Ryo <ryo@phys.sci.kobe-u.ac.jp>
                Mitsuru IWASAKI <iwasaki@jp.freebsd.org>
                Motoyuki Konno <motoyuki@freebsd.org>
                Nishika <nishika@cheerful.com>
                Yasuhiro Fukuma <yasuf@big.or.jp>
                Yoshiaki Uchikawa <yoshiaki@kt.rim.or.jp>
This commit is contained in:
Motoyuki Konno 1999-05-12 04:46:27 +00:00
parent f3af8f2c5e
commit 6b12c8ddf3
Notes: svn2git 2020-12-08 03:00:23 +00:00
svn path=/head/; revision=4872
14 changed files with 848 additions and 308 deletions

View file

@ -1,6 +1,6 @@
<!-- $Id: admin.sgml,v 1.12 1998-08-27 06:10:02 motoyuki Exp $ -->
<!-- $Id: admin.sgml,v 1.13 1999-05-12 04:46:23 motoyuki Exp $ -->
<!-- The FreeBSD Japanese Documentation Project -->
<!-- Original revision: 1.11 -->
<!-- Original revision: 1.22 -->
<sect>
<heading>システム管理<label id="admin"></heading>
@ -198,6 +198,12 @@
マニュアルの <htmlurl
url="http://www.freebsd.org/cgi/man.cgi?mount_ext2fs"
name="mount_ext2fs"> を見てください. より多くの情報があります.
<p><bf/ NT/: FreeBSD 用の読みだしのみ可能な NTFS ドライバがあります.
より詳しくは, Mark Ovens 氏によって書かれたチュートリアル
<htmlurl url="http://www.users.globalnet.co.uk/~markov/ntfs_install.html"
name="http://www.users.globalnet.co.uk/~markov/ntfs_install.html"> を
見てください.
<p>この問題について他の情報があれば, 他の人から感謝されるでしょう.
@ -334,23 +340,11 @@
自身のパーティションを使用する FreeBSD のスライスを, 同じマシン
の他のオペレーティングシステムと互換性のある形にします.
それに付随して, ブートセレクタをインストールすれば, ディスク上の
使用可能なオペレーションシステムを切り替えることができます.
使用可能なオペレーティングシステムを切り替えることができます.
もう一つの方法はディスク全てを FreeBSD で使うというもので, この
場合ほかのオペレーティングシステムとの互換性を考慮しないことに
なります.
<p>さて, これは確かに PC の世界からやって来た人々にとっては
一般的なお話でしょうが, ここで Unix の世界の方からやって来た,
FreeBSD が動作する, しかも FreeBSD だけが動作するマシンをセットアップ
しようとしている人の場合を考えてみましょう. 彼らは
オペレーティングシステムがディスク全体を, その始めのセクタから
終りの 1 つに至るまで使い切る, 古典的な Unix の流儀に慣れ親しんで
います. このような, FreeBSD が 1 日 24 時間, 1 週間に 7 日走り続け,
他のオペレーティングシステムがブートされることなど有り得ないマシン
では, 正しい fdisk のテーブルは何の役にも立ちません. 結果, もし
sysinstall の fdisk エディタで ``A)ll FreeBSD'' を選択し, 続く質問に
``No'' と答えれば, こちらのモードを選択したことになります.
この場合, BSD のブートストラップがこのドライブの MBR になるので,
ブートマネージャ等にスペースが残されていないことに注意してください.
何かを MBR にインストールすれば, BSD のブートストラップに
ダメージを与えることになるでしょう.
<p>では, なぜこれが 「危険覚悟の」と言われるのでしょう?
このモードのディスクが, 通常の PC のユーティリティが有効な fdisk
@ -358,35 +352,61 @@
如何によりますが, そのようなディスクを発見したとき, 警告を
出すものもあります. また, もっと悪い場合, 確認も通告もなしに
BSD のブートストラップにダメージを与えるものもあるでしょう.
PC ではより広範囲で使われているあるオペレーティングシステムは,
そういう非ユーザフレンドリーな行為をすることでよく知られています
(もちろん, その行為は「ユーザフレンドリ」の名の元で
行われるわけですが). 少なくとも 1 種の, 例えば HP Netserver
で使用されていた (もちろん, そこだけではありませんが) Award の
BIOS は, 有効な fdisk テーブルを持っていないと認識した全ての
ハードディスクを無視することで知られています.
ブート時にこの現象が起こると, BIOS はそのようなディスクをさっさと
無視してフロッピードライブを読みに行き, しかも ``Read error''
というあっさりしたメッセージしか吐きません. 感動ものでしょ?
多分彼らにとってはこれが「ユーザフレンドリ」なんでしょうね.
よくわかりませんけど.
さらには, 「危険覚悟の」ディスクレイアウトは多数の BIOS,
AWARD (例えば HP Netserver や Micronics システム, 他多数で
使用されていた) や Symbios/NCR (人気のあるSCSI コントローラ
53C8xx 用) などを混乱させることが分かっています. これは完全な
リストではありません. 他にもまだまだあります. この混乱の兆候は,
起動時にシステムがロックするというだけでなく, FreeBSD のブート
ストラップが自分自身を見つけられないために表示する "read error"
というメッセージなどにも現れることでしょう.
<p>このモードの利点はいくつかあります. FreeBSD がディスク全体を所有でき,
1980 年代の素朴なパーティショニングモデルのためだけに, いくつもの
本来不要な「トラック」を無駄使いする必要がなくなります.
このモデルは, パーティショニングをどのようにすべきかという点に関して,
いくらか不自然で, 今では無意味でさえある制限を課します.
この制限は, しばしば PC に OS をインストールする際の最大の頭痛の種と
なります. パーティショニングの情報を fdisk のテーブルに保存する際に
2 つの異なる, 冗長な方法が用意されているがゆえに, 結果として
ジオメトリの不整合を引き起こすのです. <ref id="missing_os"
name="Missing Operating System"> の章をご覧下さい.
「危険覚悟の専用」モードでは, BSD のブートストラップはセクタ 0
から始まりますが, BIOS のディスクジオメトリ「変換」の方式とは
無関係に, 常に等しい C/H/S の値に変換される唯一のセクタ
なのです. したがって, ブートしなくなる危険を犯すことなしに,
異なる変換方式を採用しているシステム / コントローラ間で,
ディスクを交換することができるのです.
<p>そもそもいったいなぜこのモードがあるのでしょうか? これは
わずかに数キロバイトのディスク容量を節約するのみであり, 新規
インストールで実際に問題を生ずるのです. 「危険覚悟の」モードの
起源は新しい FreeBSD インストーラでの, BIOS から見えるディスクの
「ジオメトリ」の値とディスク自身との整合性という, もっとも一般的な
問題のひとつを回避したいという要求が背景にあります.
<p>「ジオメトリ」は時代遅れの概念ですが, 未だに PC BIOS と
ディスクへの相互作用の中核をなしています. FreeBSD のインストーラが
スライスを作る時, ディスク上のスライスを BIOS が見つけられる
ようにスライス位置をディスク上に記録します. それが誤っていれば,
起動できなくなってしまうでしょう.
<p>「危険覚悟の」モードはこれを, 問題を単純にすることで
回避しようとします. 状況によってはこれでうまくいきます.
しかし次善の策として使われているに過ぎません. この問題を
解決するもっと良い方法はいくらでもあるのです.
<p>では, インストール時に「危険覚悟の専用」モードが必要になる
状況を回避するにはどうすればよいのでしょうか?
まず BIOS が報告するディスクのジオメトリの値を覚えておくことから
はじめましょう. ``boot:'' プロンプトで ``-v'' を指定するか
ローダで ``boot -v'' と指定して, ブート時にカーネルにこの値を
表示させることができます. インストーラが起動する直前に,
カーネルがジオメトリ値のリストを表示するでしょう.
パニックを起こさないでください. インストーラが起動するのを待ち,
逆スクロールでさかのぼって値を確認してください. 普通は BIOS
ディスクユニット番号は, FreeBSD がディスクを検出する順序と同様であり,
最初に IDE, 次に SCSI となります.
<p>ディスクをスライシングする際に, FDISK の画面で表示される
ディスクのジオメトリが正しいことを確認してください (BIOS の
返す値と一致しいるか). 万一ちがっていたら ``g'' を押して
修正してください. ディスクにまったくなにもない場合や他の
システムから持ってきたディスクの場合は, これをおこなう必要が
あるかもしれません. これはそのディスクから起動させようと
している場合にのみ問題になることに注意してください.
FreeBSD はそのディスクをうまい具合いに他のディスクと区別して
くれます.
<p>ディスクのジオメトリについて BIOS と FreeBSD 間で一致させる
ことができたら, この問題はほぼ解決したと思ってよいでしょう.
そしてもはや「危険覚悟の専用」モードは必要ありません.
しかし, まだブート時に恐怖の ``read error'' メッセージが出るようで
あれば, お祈りを捧げて新しいディスクを買いましょう.
もう失うものは何もありません.
<p>「危険覚悟の専用ディスク」を通常の PC での使用法に
戻すには, 原則として 2 つ方法があります. 1 つは十分な NULL
@ -411,6 +431,11 @@
<p>スワップパーティションのサイズを増やすのが最良の方法ですが,
別のディスクを追加しなくて済むという利点のある方法があります.
経験から得た一般的な方法はメインメモリの 2倍程度のスワップ領域を
とるというものです. しかしごく小さなメインメモリしかない場合は,
それ以上のスワップを構成したいと思うでしょう. また, 将来のメモリの
アップグレードに備え, 後でスワップの構成を変更する必要がないように
十分なスワップを構成しておくことは良い考えです.
<p>スワップを別のディスク上に追加することは, 単純に同じディスク上
にスワップを追加する場合よりも高速に動作するようになります.
@ -418,6 +443,18 @@
スワップが別のディスク上に作られていれば, これらが同じディスク上
にある場合よりも断然速いです. SCSI ディスクの場合は特にそうだと言えます.
<p>ディスクが複数ある場合, スワップパーティションを各ディスクに
作るように構成すると, 使用中のディスク上にスワップを置いたとしても,
通常の場合は有益です. 一般的に, システムにある高速なディスクには
スワップを作るようにすべきでしょう.
FreeBSD はデフォルトでインターリーブなスワップデバイスを 4つまで
サポートします. 複数のスワップパーティションを構成する際に,
普通はそれらを大体同じくらいの大きさにして作りたいところですが,
カーネルのコアダンプを取るのに都合が良いようにメインの
スワップパーティションを大きめにとる人もいます.
メインのスワップパーティションはカーネルのコアがとれるように
最低でも実メモリと同じ大きさにすべきでしょう.
<p> IDE ドライブは同時に同じチャネル上の複数のドライブには
アクセスできません (FreeBSD は mode 4 をサポートしていないので,
すべての IDE ディスク I/O は ``programmed'' です).
@ -425,8 +462,12 @@
作成することをおすすめします.
ドライブは実に安いものです, 心配するだけ無駄です.
<p>よいサーバと非常に高速なネットワーク環境でないのであれば,
スワップを NFS 上に置こうというのは本当にばかげた考えです.
<p>NFS 越しにスワッピングさせる方法は, スワップ用の
ローカルディスクが無い場合にのみ推奨されます.
NFS 越しのスワッピングは遅く, FreeBSD 4.x より前のリリースでは
効率が悪いのですが, 4.0 以降ではそれなりに高速になります.
そうはいっても, 利用できるネットワークの太さに制限されますし,
NFS サーバに余計な負荷がかかります.
<p>これは 64MBの vn-swap を作る例です (ここでは <tt>/usr/swap0</tt>
としますが, もちろん好きな名前を使うことができます).
@ -779,6 +820,16 @@
!bg su user -c fetchmail
</verb>
<p><tt>non-local なアカウントにメールを配送するのに
sendmail</tt> を使用している場合 (後述), 上に示したエントリの後に
<verb>
!bg su user -c "sendmail -q"
</verb>
を記述します. これはネットワーク接続が確立したらすぐに
sendmail に溜っている mailqueue を強制的に処理させるようにします.
<p>この例では, <tt/user/ が <tt/bsd.home/ にアカウントを持ち,
<tt/bsd.home/ 上の <tt/user/ のホームディレクトリに, 以下のような
<tt/.fetchmailrc/ ファイルがつくられていることを想定しています.
@ -850,17 +901,28 @@
<p>単に次の perl コマンドを実行してください:
<verb>
perl -i.bak -pe 's/\r\n/\n/g' file ...
perl -i.bak -npe 's/\r\n/\n/g' file ...
</verb>
<p>file の部分には処理するファイルを指定して下さい. 整形後のファイルは
元のファイル名で作成され, 整形前のファイルはバックアップとして元の
ファイル名の末尾に拡張子 .bak のつけられた名前で作成されます.
<p>あるいは <url url="/cgi/man.cgi?tr"
name="tr(1)"> コマンドを使うこともできます:
<verb>
tr -d '\r' &lt; dos-text-file &gt; unix-file
</verb>
<p>dos-text-file は DOS 形式のテストファイル,
unix-file には変換された出力が格納されます.
perl を使うよりほんのちょっぴり速くなります.
<sect1>
<heading>名前で指定してプロセスにシグナルを送るにはどうすればいい?</heading>
<p><url url="/cgi/cvsweb.cgi/man.cgi?killall" name="killall(1)"> を
<p><url url="/cgi/man.cgi?killall" name="killall(1)"> を
使って下さい.
<sect1>
@ -884,5 +946,56 @@ cd /cdrom/bin
./install.sh
</verb>
<sect1>
<heading>疑似ターミナルを追加するには?</heading>
<p>telnet, ssh, X, screen をたくさん利用されている場合,
疑似ターミナルが足りなくなっている可能性があります.
これを増やすには次のようにします:
<enum>
<item>次の行をカーネルコンフィグレーションファイルに追加して
<verb>
pseudo-device pty 256
</verb>
<p>新たにカーネルを作りインストールします.
<item>次のコマンドを実行して
<verb>
# cd /dev
# ./MAKEDEV pty{1,2,3,4,5,6,7}
</verb>
<p>新たなターミナル用の 256 個のデバイスノードを作ります.
<item><tt>/etc/ttys</tt> を編集し 256 個のターミナルごとの定義を追加します.
既存のエントリーの形式にあわせる必要があるでしょう. 例えばこんな感じです.
<verb>
ttyqc none network
</verb>
<p>正規表現を使った指定は <tt>tty[pqrsPQRS][0-9a-v]</tt> となります.
<item>新しいカーネルでシステムをリブートすると完了です.
</enum>
<sect1>
<heading>リブートせずにもう一度 /etc/rc.conf を読み込んで /etc/rc を開始させるには?</heading>
<p>シングルユーザモードに移行して、マルチユーザモードに戻ってください.
コンソールで次のように実行します:
<verb>
# shutdown now
(注: -r や -h は付けません)
# return
# exit
</verb>
</sect>

View file

@ -1,4 +1,4 @@
<!-- $Id: jcontrib.sgml,v 1.2 1998-08-30 05:58:47 motoyuki Exp $ -->
<!-- $Id: jcontrib.sgml,v 1.3 1999-05-12 04:46:24 motoyuki Exp $ -->
<!-- The FreeBSD Japanese Documentation Project -->
<sect>
@ -38,6 +38,7 @@
<item>&a.hanai
<item>&a.kiroh
<item>&a.shou
<item>&a.fukuma
<item>&a.murata
<item>&a.junkun
</itemize>

View file

@ -1,4 +1,4 @@
<!-- $Id: jmembers.sgml,v 1.3 1998-08-30 05:58:47 motoyuki Exp $ -->
<!-- $Id: jmembers.sgml,v 1.4 1999-05-12 04:46:24 motoyuki Exp $ -->
<!-- The FreeBSD Japanese Documentation Project -->
<!--
@ -77,6 +77,10 @@
<tt><htmlurl url='mailto:shou@kt.rim.or.jp'
name='&lt;shou@kt.rim.or.jp&gt;'></tt>">
<!ENTITY a.fukuma "Ê¡´Ö ¹¯¹°
<tt><htmlurl url='mailto:yasuf@big.or.jp'
name='&lt;yasuf@big.or.jp&gt;'></tt>">
<!ENTITY a.kuriyama "くりやま
<tt><htmlurl url='mailto:kuriyama@opt.phys.waseda.ac.jp'
name='&lt;kuriyama@opt.phys.waseda.ac.jp&gt;'></tt>">
@ -102,5 +106,5 @@
name='&lt;hideyuki@jp.FreeBSD.org&gt;'></tt>">
<!ENTITY a.sugimura "杉村 貴士
<tt><htmlurl url='mailto:takas-su@is.aist-nara.ac.jp'
name='&lt;takas-su@is.aist-nara.ac.jp&gt;'></tt>">
<tt><htmlurl url='mailto:sugimura@jp.FreeBSD.org'
name='&lt;sugimura@jp.FreeBSD.org&gt;'></tt>">

View file

@ -1,25 +1,31 @@
<!-- $Id: misc.sgml,v 1.10 1999-02-04 17:17:16 motoyuki Exp $ -->
<!-- $Id: misc.sgml,v 1.11 1999-05-12 04:46:25 motoyuki Exp $ -->
<!-- The FreeBSD Japanese Documentation Project -->
<!-- Original revision: 1.10 -->
<!-- Original revision: 1.16 -->
<sect>
<heading>その他の質問<label id="misc"></heading>
<p><em>訳: &a.yoshiaki;.<newline>10 November 1997.</em>
<p><em>訳: &a.yoshiaki;, &a.sugimura;, &a.fukuma;.
<newline>10 November 1997 - 8 May 1999.</em>
<sect1>
<heading>
FreeBSD は Linux より多くのスワップ領域を消費するのはなぜですか?
</heading>
<p>そうではありません. 本当は「なぜスワップが全部使われてる
ように見えるのか」と聞きたいのでしょう. そういうことであれば,
その理由は, 実行プログラムのクリーンな (無変更の) ブロックを,
終了後すぐに捨ててしまわずにスワップ領域に残しておけば,
そのプログラムが再実行される際にファイルシステムから読み直すよりも
迅速に実行することができるからです.
<p>FreeBSD は Linux よりもスワップを多く使っているように見えるだけです.
実際にはそうではありません. この点における FreeBSD と
Linux の主な違いは, FreeBSD はより多くのメインメモリを有効利用できるように
するため, 完全にアイドルになったものやメインメモリ上の使われなくなった
ページをスワップにあらかじめ積極的に移動しているということです.
Linux では最後の手段としてページをスワップに移動させるだけという
傾向があります. このスワップの使い方は, メインメモリをより効果的に
使用することによってバランスが保たれています.
<p>メモリ中に同時に保持する事のできるダーティページの実際の量は
減少しません. クリーンなページが必要に応じて置き換えられます.
<p>FreeBSD はこのような状況では先手策を取りますが, システムが
本当に空き状態の時に, 理由も無くページをスワップしようと決めることはない
ということに注意してください.
したがって, 夜中に使わずにおいたシステムが
朝起きたときにすべてページアウトされているということはないのです.
<sect1>
<heading>
@ -262,7 +268,7 @@
<p>SUP はバンド幅を浪費しますので, 今は使っていません. ソースコードの
アップデートの現在のおすすめの方法は <url
url="../handbook/cvsup.html" name="ハンドブックの CVSup の項">
url="../handbook/synching.html#CVSUP" name="ハンドブックの CVSup の項">
にあります.
<sect1>
@ -286,7 +292,7 @@
「引っかいて匂いをかぐ」 GUI を使っているのではないかと
考えています. 私たちは奇妙な古い仕事をしているのでしょう!
<p>真面目に言うと, FreeBSD も Linux も ``<tt/HLT/'' (停止)
<p>真面目に言うと, FreeBSD や Linux は共に ``<tt/HLT/'' (停止)
命令をシステムのアイドル時に使い, エネルギーの消費を押えて
いますので熱の発生も少なくなります. また, APM (automatic power
management) を設定してあるなら FreeBSD は CPU をローパワーモード
@ -328,5 +334,114 @@
頭文字をとったものです. 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>

View file

@ -1,6 +1,6 @@
<!-- $Id: network.sgml,v 1.11 1999-05-06 02:11:15 motoyuki Exp $ -->
<!-- $Id: network.sgml,v 1.12 1999-05-12 04:46:26 motoyuki Exp $ -->
<!-- The FreeBSD Japanese Documentation Project -->
<!-- Original revision: 1.22 -->
<!-- Original revision: 1.24 -->
<sect>
<heading>ネットワーキング<label id="networking"></heading>
@ -105,7 +105,7 @@
name="slattach"> は SLIP のクライアント専用です.
<p>これらのプログラムの解説が, <url
url="../handbook/handbook.html" name="ハンドブック">
url="../handbook/index.html" name="ハンドブック">
の以下のセクションにあります.
<itemize>
@ -932,6 +932,24 @@ default 10.0.0.2 UGSc 0 0 tun0
<p><bf>3)</bf>''alias addr''を使ってなんでもかんでも内部の計算機に向けて
流してしまう. これはちょっと無理矢理な解決法です.
<sect3>
<heading>有用な port 番号のリストはありませんか?</heading>
<p>まだ出来ていません. しかし, これは(関心を持って頂けるならば,)
そういったリストにしていく予定です.
<itemize>
<item><bf>Quake</bf>
<p>Quake は UDP ポートの 6112 を使用すると報告されています.
つまり, 次の行により quake が動くようになります.
<tt>alias port udp hostmachine:6112 6112</tt>
ここで, <tt>hostmachine</tt> は quake サーバの IP アドレスです.
<p>このように設定する代わりに,
<htmlurl url="http://www.battle.net/support/proxy/"
name="www.battle.net"> で Quake のプロキシーがサポートされているか
調べてもいいでしょう.
</itemize>
<sect2>
<heading>FCS エラーって何?</heading>

View file

@ -1,6 +1,6 @@
<!-- $Id: preface.sgml,v 1.12 1998-11-11 17:49:20 motoyuki Exp $ -->
<!-- $Id: preface.sgml,v 1.13 1999-05-12 04:46:26 motoyuki Exp $ -->
<!-- The FreeBSD Japanese Documentation Project -->
<!-- Original revision: 1.20 -->
<!-- Original revision: 1.35 -->
<sect>
<heading>まえがき<label id="preface"></heading>
@ -44,7 +44,7 @@
を参照してください.
<p>FreeBSD に関するより詳しい情報は
<url url="../handbook/handbook.html" name="FreeBSD ハンドブック">
<url url="../handbook/index.html" name="FreeBSD ハンドブック">
を参照してください.
<sect1>
@ -102,37 +102,26 @@
<sect1>
<heading>FreeBSD の最新バージョンは?</heading>
<p><url url="ftp://ftp.freebsd.org/pub/FreeBSD/2.2.7-RELEASE"
name="2.2.7"> が最新の <em>stable</em> バージョンで,
1998 年 7 月にリリースされました. また, これは最新の <em>release</em>
<p><url url="ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/3.1-RELEASE"
name="3.1"> が最新の <em>stable</em> バージョンで,
1999 年 2 月にリリースされました. また, これは最新の <em>release</em>
バージョンでもあります.
<p>簡単に言ってしまうと, <bf>-stable</bf> は
最新のリリースのすばらしい新機能の数々よりも, 安定性と変更回数の
<p>簡単に言ってしまうと, <em/-stable/ は最新の <em/-current/
のスナップショットのすばらしい新機能の数々よりも, 安定性と変更回数の
少なさを好む ISP や他の企業のユーザをターゲットにしています.
今のところ, これらのバージョンは同一のものですが, この状況も
<bf>-current</bf>ブランチが一般のリリースとして十分に洗練されるまでの
ことでしょう.
<p>これは 3.0-current snapshot がビジネスサービス向けとしては不安定である,
と言っているわけではなく, 3.0 特有の機能 (新しいコンパイラ技術や
高速なネットワークコードなど) を必要とする多くの人たちは, これを
使う決定をし, 良い成果を収めています.
私たちとしては, このブランチでさらに実績を積むまでは,
3.0 が自信を持っておすすめめできるものあるということを
「保証」したくないだけなのです.
<sect1>
<heading>FreeBSD-currentって何?<label id="current"></heading>
<p><url url="../handbook/current.html" name="FreeBSD-current"> は
オペレーティングシステムのの開発バージョンで, やがて 3.0-RELEASE
<p><url url="../handbook/cutting-edge.html#CURRENT" name="FreeBSD-current"> は
オペレーティングシステムのの開発バージョンで, やがて 4.0-RELEASE
となります. よってこれは, そこに携わっている開発者や,
どんな障害をも乗り越えていけるタフな愛好家たちにとってのみ
興味深いものです.
-current の使用に際しての詳細は <url
url="../handbook/handbook.html" name="ハンドブック"> の
<url url="../handbook/current.html" name="関連するセクション">
url="../handbook/index.html" name="ハンドブック"> の
<url url="../handbook/cutting-edge.html#CURRENT" name="関連するセクション">
を参照してください.
<p>オペレーティングシステムに馴染みがない場合や一時的な問題か
@ -171,7 +160,7 @@
基づく要求は行わないでください. 安定性やテスト十分性にこだわる人は
完全なリリースから離れてはいけません.
<p>3.0-current および 2.2-stable ブランチ両方の snapshot は,
<p>4.0-current および 3.0-stable ブランチ両方の snapshot は,
平均的に一日に一度生成されており, <url
url="ftp://current.freebsd.org/pub/FreeBSD/"> から直接入手することが
できます.
@ -184,42 +173,45 @@
name="-stable"> というブランチで, バグの修正はしっかりテストされ,
機能の強化は少しずつしか行われません (急な変更や実験的機能を望まない,
インターネットサービスプロバイダや営利企業向け). もう一方のブランチは
<url url="../handbook/current.html" name="-current"> で,
2.0 がリリースされて以来 3.0-RELEASE (そしてその後も) へ向けて脈々と
<url url="../handbook/cutting-edge.html#CURRENT" name="-current"> で,
2.0 がリリースされて以来 4.0-RELEASE (そしてその後も) へ向けて脈々と
続いているものです.
ASCII で描いた簡単な図がわかりやすいかは自信がありませんが,
こんな感じになります:
<verb>
2.0
|
|
| [2.1-stable]
*BRANCH* 2.0.5 -> 2.1 -> 2.1.5 -> 2.1.6 -> 2.1.7.1 [2.1-stable 終了]
| (1997年3月)
|
|
| [2.2-stable]
*BRANCH* 2.2.1 -> 2.2.2-RELEASE -> 2.2.5 -> 2.2.6 -> 2.2.7
| (1997年3月) (97年10月) (98年4月) (98年7月)
|
|
3.0-SNAPs (1997年第一四半期開始)
|
|
3.0.0-RELEASE (1998年10月)
|
\|/
+
[今後の 3.x リリース群]
2.0
|
|
| [2.1-stable]
*BRANCH* 2.0.5 -> 2.1 -> 2.1.5 -> 2.1.6 -> 2.1.7.1 [2.1-stable 終了]
| (1997年3月)
|
|
| [2.2-stable]
*BRANCH* 2.2.1 -> 2.2.2-RELEASE -> 2.2.5 -> 2.2.6 -> 2.2.7 -> 2.2.8 [終了]
| (1997年3月) (97年10月) (98年4月)(98年7月)(98年12月)
|
|
3.0-SNAPs (1997年第一四半期開始)
|
|
3.0.0-RELEASE (1998年10月)
|
| [3.0-stable]
*BRANCH* 3.1 (Feb 1999) -> ... 今後の 3.x リリース群 ...
|
|
\|/
+
[4.0-current として継続中]
</verb>
<p>以前の 2.1-stable ブランチが 2.2.0 がリリースされたことによって
終了し, 「安定版ブランチ」がいわゆる 2.2-stable として新しくなったのに対して,
-current ブランチは 3.0 とその先へ向けてゆっくりと進化を続けています.
3.0-current は, 実際に 3.0 がリリースされるまで, 活発な開発の
舞台として続いていくでしょう. その時点で 3.0 は別のブランチとなり,
3.1-current が次の「最新ブランチ」となる予定です.
<p>-current ブランチは 4.0 とその先へ向けてゆっくりと進化を続けており,
以前の 2.2-stable ブランチが 2.2.8 のリリースをもって終了しました.
3.0-stable がそれに替り, 次のリリース 3.1 が 1999年初頭に予定されています.
4.0-current が現在の "current branch" であり, 最初の 4.0 系列の
リリースは 2000年第一四半期の予定です.
<sect1>
<heading>2.1-stable ブランチが 2.1.7.1 で終わったのはなぜですか?</heading>
@ -252,7 +244,7 @@
待ち望んでいるユーザを欲求不満にさせるとしても, 多くのユーザは
このことを FreeBSD の最も良い所の一つだと考えています.
<p>平均的には, だいたい 6 ヶ月ごとにリリースが作成されます.
<p>平均的には, だいたい 4 ヶ月ごとにリリースが作成されます.
<p>もう少し刺激が欲しい (あるいは待ち遠しい) 方々向けに SNAP
というものが存在し, これは特にリリースに近付いてきた数ヶ月
@ -261,11 +253,12 @@
<sect1>
<heading>FreeBSD は PC 用だけしかないの?</heading>
<p>現時点ではそうですが, <url
url="../alpha/alpha.html" name="DEC Alpha">
と <url url="http://www.freebsd.org/~jseger/freebsd-sparc/"
name="UltraSPARC"> アーキテクチャへの移植
が計画されています. 異なるアーキテクチャのマシンを
<p>現在 FreeBSD 3.x は x86 アーキテクチャと同様, <url
url="../alpha/alpha.html" name="DEC Alpha"> でも動作します.
また, SPARC への移植という興味深い話もありますが,
このプロジェクトの詳細については未だ不透明です.
異なるアーキテクチャのマシンを
持っていて, ゆっくり待てないという場合には次の URL を
参照してください.
@ -278,10 +271,10 @@
<p>プロジェクトの全体的な方向性や, 誰にソースツリーにコードの
書き込み権限を与えるか, などといった FreeBSD プロジェクトに関する
重要な意思決定は 17 名からなる
<url url="../handbook/staff:core.html" name="コアチーム">
重要な意思決定は 15 名からなる
<url url="../handbook/staff.html#STAFF-CORE" name="コアチーム">
によってなされます.
ソースツリーを直接変更できる人はもっと多く, 80 名以上の
ソースツリーを直接変更できる人はもっと多く, 150 名以上の
<url url="../handbook/staff:committers.html"
name="ソースツリー管理者 (committer)"> がいます.
@ -297,24 +290,28 @@
name="FreeBSD FTP サイト"> から入手できます:
<itemize>
<item>現在の 2.2-stable リリース, 2.2.7R は
<url url="ftp://ftp.FreeBSD.ORG/pub/FreeBSD/2.2.7-RELEASE/"
name="FreeBSD 2.2.7-RELEASE"> にあります.
<item>現在の 2.2-stable リリース, 2.2.8R は
<url url="ftp://ftp.FreeBSD.ORG/pub/FreeBSD/2.2.8-RELEASE/"
name="FreeBSD 2.2.8-RELEASE"> にあります.
<item>現在の 3.0-current, 3.0-SNAP
<url url="ftp://current.freebsd.org/pub/FreeBSD/" name="3.0">
<item>現在の 3.0-stable, 3.0-RELEASE
<url url="ftp://current.freebsd.org/pub/FreeBSD/releases/3.0-RELEASE/" name="3.0-RELEASE">
にあります.
<item>次の 2.2 ブランチのリリースへと向かっている
RELENG_2_2 ブランチ (2.2.7 -> 2.2.x) に基づき一日に一回,
<item>メンテナンスモードに入っている
RELENG_2_2 ブランチ (2.2.8 以降) に基づき一日に一回,
<url url="ftp://releng22.freebsd.org/pub/FreeBSD/" name="2.2 Snapshot">
リリースが作成されます.
不慮の手違いによるまれな例外もありますが, RELENG_2_2 ブランチは
注意深く保守されています (実験的な変更はなく, -current でテスト済みの
変更だけが入ります).
RELENG_2_2 ブランチは現在, 保守要員によって注意深く保守されており,
セキュリティや信頼性面での強い必要性がなければ, 変更が加えられる
ことはありません.
<item><url url="ftp://current.freebsd.org/pub/FreeBSD/" name="3.0 Snapshot">
リリースも <ref id="current" name="-current"> ブランチ用に一日に一回
<item>3.1-RELEASE へ向けた <url url="ftp://releng30.freebsd.org/pub/FreeBSD/"
name="3.0 Snapshot"> リリースも一日に一回,
RELENG_3 ブランチ (3.0-release 以降) に基づいて作成されます.
<item><url url="ftp://current.freebsd.org/pub/FreeBSD/" name="4.0 Snapshot">
リリースは <ref id="current" name="-current"> ブランチ用に一日に一回
作成されており, これらは純粋に最先端の開発者およびテスターのために
提供されています.
</itemize>
@ -362,14 +359,14 @@
</heading>
<p>完全な情報が
<url url="../handbook/eresources:mail.html"
<url url="../handbook/eresources.html#ERESOURCES-MAIL"
name="ハンドブックのメーリングリストの節">にあります.
<sect1>
<heading>FreeBSD のニュースグループは何がありますか?</heading>
<p>完全な情報が
<url url="../handbook/eresources:news.html"
<url url="../handbook/eresources-news.html"
name="ハンドブックのニュースグループの節">にあります.
<sect1>
@ -381,8 +378,14 @@
ネットワークホストは以下の通りです:
<itemize>
<item>EFNET の Channel <tt>&num;FreeBSD</tt> が恐らく最も
人気があります. <tt>irc.chat.org</tt> のサーバー上にあります.
<item>EFNet の Channel <tt>&num;FreeBSD</tt> は FreeBSD 関係の
フォーラムですが, そこでは技術的サポートを期待しては
いけません. そこにいる人たちはあなたをマニュアルページを
読むとか研究をするとかといった苦労から遠ざけようとします.
まず第一に, これはチャットチャンネルであり, そこにある
トピックスは恋人募集, スポーツ, 核兵器といったようなものであり,
FreeBSD も同列に扱われています. 一応注意しましたからね!
<tt>irc.chat.org</tt> のサーバー上にあります.
<item>DALNET の Channel <tt>&num;FreeBSD</tt> はアメリカでは
<tt>irc.dal.net</tt>, ヨーロッパでは <tt>irc.eu.dal.net</tt>
@ -391,16 +394,25 @@
<item>UNDERNET の Channel <tt>&num;FreeBSD</tt> はアメリカでは
<tt>us.undernet.org</tt>, ヨーロッパでは <tt>eu.undernet.org</tt>
にあります.
ここも EFNet と同様のことがいえます. 助けてもらいたくて質問したり
かしこまって教えを乞うことはしてはいけません. ここは
チャットチャンネルでありヘルプチャンネルではありません.
<item>最後に, BSDNET の <tt>&num;FreeBSD</tt> に入ることもできます.
BSD 専用の小さなチャットネットワークで <tt>irc.FreeBSD.org</tt>
にあります.
このネットワークは EFNET, UNDERNET, DALNET のような無法地帯ではなく,
より技術的なサポートをおこなおうとしていますが, 閑古鳥が鳴いている
状態です. なぜ BSDNET で FreeBSD 関係の質問に答えてくれる
ボランティアがいないのでしょう?
</itemize>
<p>それぞれのチャンネルは別個のもので互いに接続されていません.
チャットのスタイルも違っているので自分のチャットのスタイルにあった
ものを見つけるために一つ一つ試すのもいいでしょう.
あらゆる種類の IRC トラフィックのため, 失礼なことをいう若い人たち
(年輩の方は少数です) に機嫌を損ねたり手に負えなくなっても
気にしてはいけません.
<sect1>
<heading>FreeBSD の本</heading>
@ -416,7 +428,7 @@
name="&lt;freebsd-questions@FreeBSD.ORG&gt;">.
<p>FreeBSD の「ハンドブック」もあり,
<url url="../handbook/handbook.html" name="FreeBSD ハンドブック">
<url url="../handbook/index.html" name="FreeBSD ハンドブック">
から読むことができます.
現在作業中ですので不完全な部分もあることに注意してください.

View file

@ -1,6 +1,6 @@
<!-- $Id: x.sgml,v 1.6 1999-02-04 17:17:17 motoyuki Exp $ -->
<!-- $Id: x.sgml,v 1.7 1999-05-12 04:46:27 motoyuki Exp $ -->
<!-- The FreeBSD Japanese Documentation Project -->
<!-- Original revision: 1.6 -->
<!-- Original revision: 1.8 -->
<sect>
<heading>X Window System と仮想コンソール<label id="x"></heading>
@ -20,8 +20,8 @@
XFree86(tm) の設定を行うのを助けてくれます.
<p>Xaccel サーバーについて調べてみるのもいいでしょう.
これはとても納得のいく価格で販売されています. 詳しくは
<ref id="xig" name="Xi Graphics について"> をご覧ください.
詳しくは <ref id="xig" name="Xi Graphics について"> か
<ref id="metrox" name="Metro Link"> をご覧ください.
<sect1>
<heading>私のマウスはなぜ X で動かないのでしょうか?<label id="x-and-moused"></heading>
@ -217,6 +217,13 @@
残せることと, ログアウト時に X サーバを再起動する責任を init に
押しつけることができることでしょう.
<p>rc.local からロードされる場合, <tt/xdm/ は引数を持たずに起動します.
(すなわち, デーモンとして起動します.) <tt/xdm/ は getty が起動した後に
ロードされなければなりません. そうでないと, <tt/xdm/ は getty と衝突し,
コンソールをロックアウトしてしまいます. この問題に対処する最善の方法は
起動スクリプト(訳注: rc.local のこと)で 10秒ほどの sleepを実行させ,
その後に xdm をロードすることです.
<p>以前のバージョンの FAQ では
<tt>/usr/X11R6/lib/X11/xdm/Xservers</tt> ファイルに X の使う
<tt/vt/ を加えるように書いてあります. これは必要ありません:

View file

@ -1,6 +1,6 @@
<!-- $Id: admin.sgml,v 1.12 1998-08-27 06:10:02 motoyuki Exp $ -->
<!-- $Id: admin.sgml,v 1.13 1999-05-12 04:46:23 motoyuki Exp $ -->
<!-- The FreeBSD Japanese Documentation Project -->
<!-- Original revision: 1.11 -->
<!-- Original revision: 1.22 -->
<sect>
<heading>システム管理<label id="admin"></heading>
@ -198,6 +198,12 @@
マニュアルの <htmlurl
url="http://www.freebsd.org/cgi/man.cgi?mount_ext2fs"
name="mount_ext2fs"> を見てください. より多くの情報があります.
<p><bf/ NT/: FreeBSD 用の読みだしのみ可能な NTFS ドライバがあります.
より詳しくは, Mark Ovens 氏によって書かれたチュートリアル
<htmlurl url="http://www.users.globalnet.co.uk/~markov/ntfs_install.html"
name="http://www.users.globalnet.co.uk/~markov/ntfs_install.html"> を
見てください.
<p>この問題について他の情報があれば, 他の人から感謝されるでしょう.
@ -334,23 +340,11 @@
自身のパーティションを使用する FreeBSD のスライスを, 同じマシン
の他のオペレーティングシステムと互換性のある形にします.
それに付随して, ブートセレクタをインストールすれば, ディスク上の
使用可能なオペレーションシステムを切り替えることができます.
使用可能なオペレーティングシステムを切り替えることができます.
もう一つの方法はディスク全てを FreeBSD で使うというもので, この
場合ほかのオペレーティングシステムとの互換性を考慮しないことに
なります.
<p>さて, これは確かに PC の世界からやって来た人々にとっては
一般的なお話でしょうが, ここで Unix の世界の方からやって来た,
FreeBSD が動作する, しかも FreeBSD だけが動作するマシンをセットアップ
しようとしている人の場合を考えてみましょう. 彼らは
オペレーティングシステムがディスク全体を, その始めのセクタから
終りの 1 つに至るまで使い切る, 古典的な Unix の流儀に慣れ親しんで
います. このような, FreeBSD が 1 日 24 時間, 1 週間に 7 日走り続け,
他のオペレーティングシステムがブートされることなど有り得ないマシン
では, 正しい fdisk のテーブルは何の役にも立ちません. 結果, もし
sysinstall の fdisk エディタで ``A)ll FreeBSD'' を選択し, 続く質問に
``No'' と答えれば, こちらのモードを選択したことになります.
この場合, BSD のブートストラップがこのドライブの MBR になるので,
ブートマネージャ等にスペースが残されていないことに注意してください.
何かを MBR にインストールすれば, BSD のブートストラップに
ダメージを与えることになるでしょう.
<p>では, なぜこれが 「危険覚悟の」と言われるのでしょう?
このモードのディスクが, 通常の PC のユーティリティが有効な fdisk
@ -358,35 +352,61 @@
如何によりますが, そのようなディスクを発見したとき, 警告を
出すものもあります. また, もっと悪い場合, 確認も通告もなしに
BSD のブートストラップにダメージを与えるものもあるでしょう.
PC ではより広範囲で使われているあるオペレーティングシステムは,
そういう非ユーザフレンドリーな行為をすることでよく知られています
(もちろん, その行為は「ユーザフレンドリ」の名の元で
行われるわけですが). 少なくとも 1 種の, 例えば HP Netserver
で使用されていた (もちろん, そこだけではありませんが) Award の
BIOS は, 有効な fdisk テーブルを持っていないと認識した全ての
ハードディスクを無視することで知られています.
ブート時にこの現象が起こると, BIOS はそのようなディスクをさっさと
無視してフロッピードライブを読みに行き, しかも ``Read error''
というあっさりしたメッセージしか吐きません. 感動ものでしょ?
多分彼らにとってはこれが「ユーザフレンドリ」なんでしょうね.
よくわかりませんけど.
さらには, 「危険覚悟の」ディスクレイアウトは多数の BIOS,
AWARD (例えば HP Netserver や Micronics システム, 他多数で
使用されていた) や Symbios/NCR (人気のあるSCSI コントローラ
53C8xx 用) などを混乱させることが分かっています. これは完全な
リストではありません. 他にもまだまだあります. この混乱の兆候は,
起動時にシステムがロックするというだけでなく, FreeBSD のブート
ストラップが自分自身を見つけられないために表示する "read error"
というメッセージなどにも現れることでしょう.
<p>このモードの利点はいくつかあります. FreeBSD がディスク全体を所有でき,
1980 年代の素朴なパーティショニングモデルのためだけに, いくつもの
本来不要な「トラック」を無駄使いする必要がなくなります.
このモデルは, パーティショニングをどのようにすべきかという点に関して,
いくらか不自然で, 今では無意味でさえある制限を課します.
この制限は, しばしば PC に OS をインストールする際の最大の頭痛の種と
なります. パーティショニングの情報を fdisk のテーブルに保存する際に
2 つの異なる, 冗長な方法が用意されているがゆえに, 結果として
ジオメトリの不整合を引き起こすのです. <ref id="missing_os"
name="Missing Operating System"> の章をご覧下さい.
「危険覚悟の専用」モードでは, BSD のブートストラップはセクタ 0
から始まりますが, BIOS のディスクジオメトリ「変換」の方式とは
無関係に, 常に等しい C/H/S の値に変換される唯一のセクタ
なのです. したがって, ブートしなくなる危険を犯すことなしに,
異なる変換方式を採用しているシステム / コントローラ間で,
ディスクを交換することができるのです.
<p>そもそもいったいなぜこのモードがあるのでしょうか? これは
わずかに数キロバイトのディスク容量を節約するのみであり, 新規
インストールで実際に問題を生ずるのです. 「危険覚悟の」モードの
起源は新しい FreeBSD インストーラでの, BIOS から見えるディスクの
「ジオメトリ」の値とディスク自身との整合性という, もっとも一般的な
問題のひとつを回避したいという要求が背景にあります.
<p>「ジオメトリ」は時代遅れの概念ですが, 未だに PC BIOS と
ディスクへの相互作用の中核をなしています. FreeBSD のインストーラが
スライスを作る時, ディスク上のスライスを BIOS が見つけられる
ようにスライス位置をディスク上に記録します. それが誤っていれば,
起動できなくなってしまうでしょう.
<p>「危険覚悟の」モードはこれを, 問題を単純にすることで
回避しようとします. 状況によってはこれでうまくいきます.
しかし次善の策として使われているに過ぎません. この問題を
解決するもっと良い方法はいくらでもあるのです.
<p>では, インストール時に「危険覚悟の専用」モードが必要になる
状況を回避するにはどうすればよいのでしょうか?
まず BIOS が報告するディスクのジオメトリの値を覚えておくことから
はじめましょう. ``boot:'' プロンプトで ``-v'' を指定するか
ローダで ``boot -v'' と指定して, ブート時にカーネルにこの値を
表示させることができます. インストーラが起動する直前に,
カーネルがジオメトリ値のリストを表示するでしょう.
パニックを起こさないでください. インストーラが起動するのを待ち,
逆スクロールでさかのぼって値を確認してください. 普通は BIOS
ディスクユニット番号は, FreeBSD がディスクを検出する順序と同様であり,
最初に IDE, 次に SCSI となります.
<p>ディスクをスライシングする際に, FDISK の画面で表示される
ディスクのジオメトリが正しいことを確認してください (BIOS の
返す値と一致しいるか). 万一ちがっていたら ``g'' を押して
修正してください. ディスクにまったくなにもない場合や他の
システムから持ってきたディスクの場合は, これをおこなう必要が
あるかもしれません. これはそのディスクから起動させようと
している場合にのみ問題になることに注意してください.
FreeBSD はそのディスクをうまい具合いに他のディスクと区別して
くれます.
<p>ディスクのジオメトリについて BIOS と FreeBSD 間で一致させる
ことができたら, この問題はほぼ解決したと思ってよいでしょう.
そしてもはや「危険覚悟の専用」モードは必要ありません.
しかし, まだブート時に恐怖の ``read error'' メッセージが出るようで
あれば, お祈りを捧げて新しいディスクを買いましょう.
もう失うものは何もありません.
<p>「危険覚悟の専用ディスク」を通常の PC での使用法に
戻すには, 原則として 2 つ方法があります. 1 つは十分な NULL
@ -411,6 +431,11 @@
<p>スワップパーティションのサイズを増やすのが最良の方法ですが,
別のディスクを追加しなくて済むという利点のある方法があります.
経験から得た一般的な方法はメインメモリの 2倍程度のスワップ領域を
とるというものです. しかしごく小さなメインメモリしかない場合は,
それ以上のスワップを構成したいと思うでしょう. また, 将来のメモリの
アップグレードに備え, 後でスワップの構成を変更する必要がないように
十分なスワップを構成しておくことは良い考えです.
<p>スワップを別のディスク上に追加することは, 単純に同じディスク上
にスワップを追加する場合よりも高速に動作するようになります.
@ -418,6 +443,18 @@
スワップが別のディスク上に作られていれば, これらが同じディスク上
にある場合よりも断然速いです. SCSI ディスクの場合は特にそうだと言えます.
<p>ディスクが複数ある場合, スワップパーティションを各ディスクに
作るように構成すると, 使用中のディスク上にスワップを置いたとしても,
通常の場合は有益です. 一般的に, システムにある高速なディスクには
スワップを作るようにすべきでしょう.
FreeBSD はデフォルトでインターリーブなスワップデバイスを 4つまで
サポートします. 複数のスワップパーティションを構成する際に,
普通はそれらを大体同じくらいの大きさにして作りたいところですが,
カーネルのコアダンプを取るのに都合が良いようにメインの
スワップパーティションを大きめにとる人もいます.
メインのスワップパーティションはカーネルのコアがとれるように
最低でも実メモリと同じ大きさにすべきでしょう.
<p> IDE ドライブは同時に同じチャネル上の複数のドライブには
アクセスできません (FreeBSD は mode 4 をサポートしていないので,
すべての IDE ディスク I/O は ``programmed'' です).
@ -425,8 +462,12 @@
作成することをおすすめします.
ドライブは実に安いものです, 心配するだけ無駄です.
<p>よいサーバと非常に高速なネットワーク環境でないのであれば,
スワップを NFS 上に置こうというのは本当にばかげた考えです.
<p>NFS 越しにスワッピングさせる方法は, スワップ用の
ローカルディスクが無い場合にのみ推奨されます.
NFS 越しのスワッピングは遅く, FreeBSD 4.x より前のリリースでは
効率が悪いのですが, 4.0 以降ではそれなりに高速になります.
そうはいっても, 利用できるネットワークの太さに制限されますし,
NFS サーバに余計な負荷がかかります.
<p>これは 64MBの vn-swap を作る例です (ここでは <tt>/usr/swap0</tt>
としますが, もちろん好きな名前を使うことができます).
@ -779,6 +820,16 @@
!bg su user -c fetchmail
</verb>
<p><tt>non-local なアカウントにメールを配送するのに
sendmail</tt> を使用している場合 (後述), 上に示したエントリの後に
<verb>
!bg su user -c "sendmail -q"
</verb>
を記述します. これはネットワーク接続が確立したらすぐに
sendmail に溜っている mailqueue を強制的に処理させるようにします.
<p>この例では, <tt/user/ が <tt/bsd.home/ にアカウントを持ち,
<tt/bsd.home/ 上の <tt/user/ のホームディレクトリに, 以下のような
<tt/.fetchmailrc/ ファイルがつくられていることを想定しています.
@ -850,17 +901,28 @@
<p>単に次の perl コマンドを実行してください:
<verb>
perl -i.bak -pe 's/\r\n/\n/g' file ...
perl -i.bak -npe 's/\r\n/\n/g' file ...
</verb>
<p>file の部分には処理するファイルを指定して下さい. 整形後のファイルは
元のファイル名で作成され, 整形前のファイルはバックアップとして元の
ファイル名の末尾に拡張子 .bak のつけられた名前で作成されます.
<p>あるいは <url url="/cgi/man.cgi?tr"
name="tr(1)"> コマンドを使うこともできます:
<verb>
tr -d '\r' &lt; dos-text-file &gt; unix-file
</verb>
<p>dos-text-file は DOS 形式のテストファイル,
unix-file には変換された出力が格納されます.
perl を使うよりほんのちょっぴり速くなります.
<sect1>
<heading>名前で指定してプロセスにシグナルを送るにはどうすればいい?</heading>
<p><url url="/cgi/cvsweb.cgi/man.cgi?killall" name="killall(1)"> を
<p><url url="/cgi/man.cgi?killall" name="killall(1)"> を
使って下さい.
<sect1>
@ -884,5 +946,56 @@ cd /cdrom/bin
./install.sh
</verb>
<sect1>
<heading>疑似ターミナルを追加するには?</heading>
<p>telnet, ssh, X, screen をたくさん利用されている場合,
疑似ターミナルが足りなくなっている可能性があります.
これを増やすには次のようにします:
<enum>
<item>次の行をカーネルコンフィグレーションファイルに追加して
<verb>
pseudo-device pty 256
</verb>
<p>新たにカーネルを作りインストールします.
<item>次のコマンドを実行して
<verb>
# cd /dev
# ./MAKEDEV pty{1,2,3,4,5,6,7}
</verb>
<p>新たなターミナル用の 256 個のデバイスノードを作ります.
<item><tt>/etc/ttys</tt> を編集し 256 個のターミナルごとの定義を追加します.
既存のエントリーの形式にあわせる必要があるでしょう. 例えばこんな感じです.
<verb>
ttyqc none network
</verb>
<p>正規表現を使った指定は <tt>tty[pqrsPQRS][0-9a-v]</tt> となります.
<item>新しいカーネルでシステムをリブートすると完了です.
</enum>
<sect1>
<heading>リブートせずにもう一度 /etc/rc.conf を読み込んで /etc/rc を開始させるには?</heading>
<p>シングルユーザモードに移行して、マルチユーザモードに戻ってください.
コンソールで次のように実行します:
<verb>
# shutdown now
(注: -r や -h は付けません)
# return
# exit
</verb>
</sect>

View file

@ -1,4 +1,4 @@
<!-- $Id: jcontrib.sgml,v 1.2 1998-08-30 05:58:47 motoyuki Exp $ -->
<!-- $Id: jcontrib.sgml,v 1.3 1999-05-12 04:46:24 motoyuki Exp $ -->
<!-- The FreeBSD Japanese Documentation Project -->
<sect>
@ -38,6 +38,7 @@
<item>&a.hanai
<item>&a.kiroh
<item>&a.shou
<item>&a.fukuma
<item>&a.murata
<item>&a.junkun
</itemize>

View file

@ -1,4 +1,4 @@
<!-- $Id: jmembers.sgml,v 1.3 1998-08-30 05:58:47 motoyuki Exp $ -->
<!-- $Id: jmembers.sgml,v 1.4 1999-05-12 04:46:24 motoyuki Exp $ -->
<!-- The FreeBSD Japanese Documentation Project -->
<!--
@ -77,6 +77,10 @@
<tt><htmlurl url='mailto:shou@kt.rim.or.jp'
name='&lt;shou@kt.rim.or.jp&gt;'></tt>">
<!ENTITY a.fukuma "Ê¡´Ö ¹¯¹°
<tt><htmlurl url='mailto:yasuf@big.or.jp'
name='&lt;yasuf@big.or.jp&gt;'></tt>">
<!ENTITY a.kuriyama "くりやま
<tt><htmlurl url='mailto:kuriyama@opt.phys.waseda.ac.jp'
name='&lt;kuriyama@opt.phys.waseda.ac.jp&gt;'></tt>">
@ -102,5 +106,5 @@
name='&lt;hideyuki@jp.FreeBSD.org&gt;'></tt>">
<!ENTITY a.sugimura "杉村 貴士
<tt><htmlurl url='mailto:takas-su@is.aist-nara.ac.jp'
name='&lt;takas-su@is.aist-nara.ac.jp&gt;'></tt>">
<tt><htmlurl url='mailto:sugimura@jp.FreeBSD.org'
name='&lt;sugimura@jp.FreeBSD.org&gt;'></tt>">

View file

@ -1,25 +1,31 @@
<!-- $Id: misc.sgml,v 1.10 1999-02-04 17:17:16 motoyuki Exp $ -->
<!-- $Id: misc.sgml,v 1.11 1999-05-12 04:46:25 motoyuki Exp $ -->
<!-- The FreeBSD Japanese Documentation Project -->
<!-- Original revision: 1.10 -->
<!-- Original revision: 1.16 -->
<sect>
<heading>その他の質問<label id="misc"></heading>
<p><em>訳: &a.yoshiaki;.<newline>10 November 1997.</em>
<p><em>訳: &a.yoshiaki;, &a.sugimura;, &a.fukuma;.
<newline>10 November 1997 - 8 May 1999.</em>
<sect1>
<heading>
FreeBSD は Linux より多くのスワップ領域を消費するのはなぜですか?
</heading>
<p>そうではありません. 本当は「なぜスワップが全部使われてる
ように見えるのか」と聞きたいのでしょう. そういうことであれば,
その理由は, 実行プログラムのクリーンな (無変更の) ブロックを,
終了後すぐに捨ててしまわずにスワップ領域に残しておけば,
そのプログラムが再実行される際にファイルシステムから読み直すよりも
迅速に実行することができるからです.
<p>FreeBSD は Linux よりもスワップを多く使っているように見えるだけです.
実際にはそうではありません. この点における FreeBSD と
Linux の主な違いは, FreeBSD はより多くのメインメモリを有効利用できるように
するため, 完全にアイドルになったものやメインメモリ上の使われなくなった
ページをスワップにあらかじめ積極的に移動しているということです.
Linux では最後の手段としてページをスワップに移動させるだけという
傾向があります. このスワップの使い方は, メインメモリをより効果的に
使用することによってバランスが保たれています.
<p>メモリ中に同時に保持する事のできるダーティページの実際の量は
減少しません. クリーンなページが必要に応じて置き換えられます.
<p>FreeBSD はこのような状況では先手策を取りますが, システムが
本当に空き状態の時に, 理由も無くページをスワップしようと決めることはない
ということに注意してください.
したがって, 夜中に使わずにおいたシステムが
朝起きたときにすべてページアウトされているということはないのです.
<sect1>
<heading>
@ -262,7 +268,7 @@
<p>SUP はバンド幅を浪費しますので, 今は使っていません. ソースコードの
アップデートの現在のおすすめの方法は <url
url="../handbook/cvsup.html" name="ハンドブックの CVSup の項">
url="../handbook/synching.html#CVSUP" name="ハンドブックの CVSup の項">
にあります.
<sect1>
@ -286,7 +292,7 @@
「引っかいて匂いをかぐ」 GUI を使っているのではないかと
考えています. 私たちは奇妙な古い仕事をしているのでしょう!
<p>真面目に言うと, FreeBSD も Linux も ``<tt/HLT/'' (停止)
<p>真面目に言うと, FreeBSD や Linux は共に ``<tt/HLT/'' (停止)
命令をシステムのアイドル時に使い, エネルギーの消費を押えて
いますので熱の発生も少なくなります. また, APM (automatic power
management) を設定してあるなら FreeBSD は CPU をローパワーモード
@ -328,5 +334,114 @@
頭文字をとったものです. 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>

View file

@ -1,6 +1,6 @@
<!-- $Id: network.sgml,v 1.11 1999-05-06 02:11:15 motoyuki Exp $ -->
<!-- $Id: network.sgml,v 1.12 1999-05-12 04:46:26 motoyuki Exp $ -->
<!-- The FreeBSD Japanese Documentation Project -->
<!-- Original revision: 1.22 -->
<!-- Original revision: 1.24 -->
<sect>
<heading>ネットワーキング<label id="networking"></heading>
@ -105,7 +105,7 @@
name="slattach"> は SLIP のクライアント専用です.
<p>これらのプログラムの解説が, <url
url="../handbook/handbook.html" name="ハンドブック">
url="../handbook/index.html" name="ハンドブック">
の以下のセクションにあります.
<itemize>
@ -932,6 +932,24 @@ default 10.0.0.2 UGSc 0 0 tun0
<p><bf>3)</bf>''alias addr''を使ってなんでもかんでも内部の計算機に向けて
流してしまう. これはちょっと無理矢理な解決法です.
<sect3>
<heading>有用な port 番号のリストはありませんか?</heading>
<p>まだ出来ていません. しかし, これは(関心を持って頂けるならば,)
そういったリストにしていく予定です.
<itemize>
<item><bf>Quake</bf>
<p>Quake は UDP ポートの 6112 を使用すると報告されています.
つまり, 次の行により quake が動くようになります.
<tt>alias port udp hostmachine:6112 6112</tt>
ここで, <tt>hostmachine</tt> は quake サーバの IP アドレスです.
<p>このように設定する代わりに,
<htmlurl url="http://www.battle.net/support/proxy/"
name="www.battle.net"> で Quake のプロキシーがサポートされているか
調べてもいいでしょう.
</itemize>
<sect2>
<heading>FCS エラーって何?</heading>

View file

@ -1,6 +1,6 @@
<!-- $Id: preface.sgml,v 1.12 1998-11-11 17:49:20 motoyuki Exp $ -->
<!-- $Id: preface.sgml,v 1.13 1999-05-12 04:46:26 motoyuki Exp $ -->
<!-- The FreeBSD Japanese Documentation Project -->
<!-- Original revision: 1.20 -->
<!-- Original revision: 1.35 -->
<sect>
<heading>まえがき<label id="preface"></heading>
@ -44,7 +44,7 @@
を参照してください.
<p>FreeBSD に関するより詳しい情報は
<url url="../handbook/handbook.html" name="FreeBSD ハンドブック">
<url url="../handbook/index.html" name="FreeBSD ハンドブック">
を参照してください.
<sect1>
@ -102,37 +102,26 @@
<sect1>
<heading>FreeBSD の最新バージョンは?</heading>
<p><url url="ftp://ftp.freebsd.org/pub/FreeBSD/2.2.7-RELEASE"
name="2.2.7"> が最新の <em>stable</em> バージョンで,
1998 年 7 月にリリースされました. また, これは最新の <em>release</em>
<p><url url="ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/3.1-RELEASE"
name="3.1"> が最新の <em>stable</em> バージョンで,
1999 年 2 月にリリースされました. また, これは最新の <em>release</em>
バージョンでもあります.
<p>簡単に言ってしまうと, <bf>-stable</bf> は
最新のリリースのすばらしい新機能の数々よりも, 安定性と変更回数の
<p>簡単に言ってしまうと, <em/-stable/ は最新の <em/-current/
のスナップショットのすばらしい新機能の数々よりも, 安定性と変更回数の
少なさを好む ISP や他の企業のユーザをターゲットにしています.
今のところ, これらのバージョンは同一のものですが, この状況も
<bf>-current</bf>ブランチが一般のリリースとして十分に洗練されるまでの
ことでしょう.
<p>これは 3.0-current snapshot がビジネスサービス向けとしては不安定である,
と言っているわけではなく, 3.0 特有の機能 (新しいコンパイラ技術や
高速なネットワークコードなど) を必要とする多くの人たちは, これを
使う決定をし, 良い成果を収めています.
私たちとしては, このブランチでさらに実績を積むまでは,
3.0 が自信を持っておすすめめできるものあるということを
「保証」したくないだけなのです.
<sect1>
<heading>FreeBSD-currentって何?<label id="current"></heading>
<p><url url="../handbook/current.html" name="FreeBSD-current"> は
オペレーティングシステムのの開発バージョンで, やがて 3.0-RELEASE
<p><url url="../handbook/cutting-edge.html#CURRENT" name="FreeBSD-current"> は
オペレーティングシステムのの開発バージョンで, やがて 4.0-RELEASE
となります. よってこれは, そこに携わっている開発者や,
どんな障害をも乗り越えていけるタフな愛好家たちにとってのみ
興味深いものです.
-current の使用に際しての詳細は <url
url="../handbook/handbook.html" name="ハンドブック"> の
<url url="../handbook/current.html" name="関連するセクション">
url="../handbook/index.html" name="ハンドブック"> の
<url url="../handbook/cutting-edge.html#CURRENT" name="関連するセクション">
を参照してください.
<p>オペレーティングシステムに馴染みがない場合や一時的な問題か
@ -171,7 +160,7 @@
基づく要求は行わないでください. 安定性やテスト十分性にこだわる人は
完全なリリースから離れてはいけません.
<p>3.0-current および 2.2-stable ブランチ両方の snapshot は,
<p>4.0-current および 3.0-stable ブランチ両方の snapshot は,
平均的に一日に一度生成されており, <url
url="ftp://current.freebsd.org/pub/FreeBSD/"> から直接入手することが
できます.
@ -184,42 +173,45 @@
name="-stable"> というブランチで, バグの修正はしっかりテストされ,
機能の強化は少しずつしか行われません (急な変更や実験的機能を望まない,
インターネットサービスプロバイダや営利企業向け). もう一方のブランチは
<url url="../handbook/current.html" name="-current"> で,
2.0 がリリースされて以来 3.0-RELEASE (そしてその後も) へ向けて脈々と
<url url="../handbook/cutting-edge.html#CURRENT" name="-current"> で,
2.0 がリリースされて以来 4.0-RELEASE (そしてその後も) へ向けて脈々と
続いているものです.
ASCII で描いた簡単な図がわかりやすいかは自信がありませんが,
こんな感じになります:
<verb>
2.0
|
|
| [2.1-stable]
*BRANCH* 2.0.5 -> 2.1 -> 2.1.5 -> 2.1.6 -> 2.1.7.1 [2.1-stable 終了]
| (1997年3月)
|
|
| [2.2-stable]
*BRANCH* 2.2.1 -> 2.2.2-RELEASE -> 2.2.5 -> 2.2.6 -> 2.2.7
| (1997年3月) (97年10月) (98年4月) (98年7月)
|
|
3.0-SNAPs (1997年第一四半期開始)
|
|
3.0.0-RELEASE (1998年10月)
|
\|/
+
[今後の 3.x リリース群]
2.0
|
|
| [2.1-stable]
*BRANCH* 2.0.5 -> 2.1 -> 2.1.5 -> 2.1.6 -> 2.1.7.1 [2.1-stable 終了]
| (1997年3月)
|
|
| [2.2-stable]
*BRANCH* 2.2.1 -> 2.2.2-RELEASE -> 2.2.5 -> 2.2.6 -> 2.2.7 -> 2.2.8 [終了]
| (1997年3月) (97年10月) (98年4月)(98年7月)(98年12月)
|
|
3.0-SNAPs (1997年第一四半期開始)
|
|
3.0.0-RELEASE (1998年10月)
|
| [3.0-stable]
*BRANCH* 3.1 (Feb 1999) -> ... 今後の 3.x リリース群 ...
|
|
\|/
+
[4.0-current として継続中]
</verb>
<p>以前の 2.1-stable ブランチが 2.2.0 がリリースされたことによって
終了し, 「安定版ブランチ」がいわゆる 2.2-stable として新しくなったのに対して,
-current ブランチは 3.0 とその先へ向けてゆっくりと進化を続けています.
3.0-current は, 実際に 3.0 がリリースされるまで, 活発な開発の
舞台として続いていくでしょう. その時点で 3.0 は別のブランチとなり,
3.1-current が次の「最新ブランチ」となる予定です.
<p>-current ブランチは 4.0 とその先へ向けてゆっくりと進化を続けており,
以前の 2.2-stable ブランチが 2.2.8 のリリースをもって終了しました.
3.0-stable がそれに替り, 次のリリース 3.1 が 1999年初頭に予定されています.
4.0-current が現在の "current branch" であり, 最初の 4.0 系列の
リリースは 2000年第一四半期の予定です.
<sect1>
<heading>2.1-stable ブランチが 2.1.7.1 で終わったのはなぜですか?</heading>
@ -252,7 +244,7 @@
待ち望んでいるユーザを欲求不満にさせるとしても, 多くのユーザは
このことを FreeBSD の最も良い所の一つだと考えています.
<p>平均的には, だいたい 6 ヶ月ごとにリリースが作成されます.
<p>平均的には, だいたい 4 ヶ月ごとにリリースが作成されます.
<p>もう少し刺激が欲しい (あるいは待ち遠しい) 方々向けに SNAP
というものが存在し, これは特にリリースに近付いてきた数ヶ月
@ -261,11 +253,12 @@
<sect1>
<heading>FreeBSD は PC 用だけしかないの?</heading>
<p>現時点ではそうですが, <url
url="../alpha/alpha.html" name="DEC Alpha">
と <url url="http://www.freebsd.org/~jseger/freebsd-sparc/"
name="UltraSPARC"> アーキテクチャへの移植
が計画されています. 異なるアーキテクチャのマシンを
<p>現在 FreeBSD 3.x は x86 アーキテクチャと同様, <url
url="../alpha/alpha.html" name="DEC Alpha"> でも動作します.
また, SPARC への移植という興味深い話もありますが,
このプロジェクトの詳細については未だ不透明です.
異なるアーキテクチャのマシンを
持っていて, ゆっくり待てないという場合には次の URL を
参照してください.
@ -278,10 +271,10 @@
<p>プロジェクトの全体的な方向性や, 誰にソースツリーにコードの
書き込み権限を与えるか, などといった FreeBSD プロジェクトに関する
重要な意思決定は 17 名からなる
<url url="../handbook/staff:core.html" name="コアチーム">
重要な意思決定は 15 名からなる
<url url="../handbook/staff.html#STAFF-CORE" name="コアチーム">
によってなされます.
ソースツリーを直接変更できる人はもっと多く, 80 名以上の
ソースツリーを直接変更できる人はもっと多く, 150 名以上の
<url url="../handbook/staff:committers.html"
name="ソースツリー管理者 (committer)"> がいます.
@ -297,24 +290,28 @@
name="FreeBSD FTP サイト"> から入手できます:
<itemize>
<item>現在の 2.2-stable リリース, 2.2.7R は
<url url="ftp://ftp.FreeBSD.ORG/pub/FreeBSD/2.2.7-RELEASE/"
name="FreeBSD 2.2.7-RELEASE"> にあります.
<item>現在の 2.2-stable リリース, 2.2.8R は
<url url="ftp://ftp.FreeBSD.ORG/pub/FreeBSD/2.2.8-RELEASE/"
name="FreeBSD 2.2.8-RELEASE"> にあります.
<item>現在の 3.0-current, 3.0-SNAP
<url url="ftp://current.freebsd.org/pub/FreeBSD/" name="3.0">
<item>現在の 3.0-stable, 3.0-RELEASE
<url url="ftp://current.freebsd.org/pub/FreeBSD/releases/3.0-RELEASE/" name="3.0-RELEASE">
にあります.
<item>次の 2.2 ブランチのリリースへと向かっている
RELENG_2_2 ブランチ (2.2.7 -> 2.2.x) に基づき一日に一回,
<item>メンテナンスモードに入っている
RELENG_2_2 ブランチ (2.2.8 以降) に基づき一日に一回,
<url url="ftp://releng22.freebsd.org/pub/FreeBSD/" name="2.2 Snapshot">
リリースが作成されます.
不慮の手違いによるまれな例外もありますが, RELENG_2_2 ブランチは
注意深く保守されています (実験的な変更はなく, -current でテスト済みの
変更だけが入ります).
RELENG_2_2 ブランチは現在, 保守要員によって注意深く保守されており,
セキュリティや信頼性面での強い必要性がなければ, 変更が加えられる
ことはありません.
<item><url url="ftp://current.freebsd.org/pub/FreeBSD/" name="3.0 Snapshot">
リリースも <ref id="current" name="-current"> ブランチ用に一日に一回
<item>3.1-RELEASE へ向けた <url url="ftp://releng30.freebsd.org/pub/FreeBSD/"
name="3.0 Snapshot"> リリースも一日に一回,
RELENG_3 ブランチ (3.0-release 以降) に基づいて作成されます.
<item><url url="ftp://current.freebsd.org/pub/FreeBSD/" name="4.0 Snapshot">
リリースは <ref id="current" name="-current"> ブランチ用に一日に一回
作成されており, これらは純粋に最先端の開発者およびテスターのために
提供されています.
</itemize>
@ -362,14 +359,14 @@
</heading>
<p>完全な情報が
<url url="../handbook/eresources:mail.html"
<url url="../handbook/eresources.html#ERESOURCES-MAIL"
name="ハンドブックのメーリングリストの節">にあります.
<sect1>
<heading>FreeBSD のニュースグループは何がありますか?</heading>
<p>完全な情報が
<url url="../handbook/eresources:news.html"
<url url="../handbook/eresources-news.html"
name="ハンドブックのニュースグループの節">にあります.
<sect1>
@ -381,8 +378,14 @@
ネットワークホストは以下の通りです:
<itemize>
<item>EFNET の Channel <tt>&num;FreeBSD</tt> が恐らく最も
人気があります. <tt>irc.chat.org</tt> のサーバー上にあります.
<item>EFNet の Channel <tt>&num;FreeBSD</tt> は FreeBSD 関係の
フォーラムですが, そこでは技術的サポートを期待しては
いけません. そこにいる人たちはあなたをマニュアルページを
読むとか研究をするとかといった苦労から遠ざけようとします.
まず第一に, これはチャットチャンネルであり, そこにある
トピックスは恋人募集, スポーツ, 核兵器といったようなものであり,
FreeBSD も同列に扱われています. 一応注意しましたからね!
<tt>irc.chat.org</tt> のサーバー上にあります.
<item>DALNET の Channel <tt>&num;FreeBSD</tt> はアメリカでは
<tt>irc.dal.net</tt>, ヨーロッパでは <tt>irc.eu.dal.net</tt>
@ -391,16 +394,25 @@
<item>UNDERNET の Channel <tt>&num;FreeBSD</tt> はアメリカでは
<tt>us.undernet.org</tt>, ヨーロッパでは <tt>eu.undernet.org</tt>
にあります.
ここも EFNet と同様のことがいえます. 助けてもらいたくて質問したり
かしこまって教えを乞うことはしてはいけません. ここは
チャットチャンネルでありヘルプチャンネルではありません.
<item>最後に, BSDNET の <tt>&num;FreeBSD</tt> に入ることもできます.
BSD 専用の小さなチャットネットワークで <tt>irc.FreeBSD.org</tt>
にあります.
このネットワークは EFNET, UNDERNET, DALNET のような無法地帯ではなく,
より技術的なサポートをおこなおうとしていますが, 閑古鳥が鳴いている
状態です. なぜ BSDNET で FreeBSD 関係の質問に答えてくれる
ボランティアがいないのでしょう?
</itemize>
<p>それぞれのチャンネルは別個のもので互いに接続されていません.
チャットのスタイルも違っているので自分のチャットのスタイルにあった
ものを見つけるために一つ一つ試すのもいいでしょう.
あらゆる種類の IRC トラフィックのため, 失礼なことをいう若い人たち
(年輩の方は少数です) に機嫌を損ねたり手に負えなくなっても
気にしてはいけません.
<sect1>
<heading>FreeBSD の本</heading>
@ -416,7 +428,7 @@
name="&lt;freebsd-questions@FreeBSD.ORG&gt;">.
<p>FreeBSD の「ハンドブック」もあり,
<url url="../handbook/handbook.html" name="FreeBSD ハンドブック">
<url url="../handbook/index.html" name="FreeBSD ハンドブック">
から読むことができます.
現在作業中ですので不完全な部分もあることに注意してください.

View file

@ -1,6 +1,6 @@
<!-- $Id: x.sgml,v 1.6 1999-02-04 17:17:17 motoyuki Exp $ -->
<!-- $Id: x.sgml,v 1.7 1999-05-12 04:46:27 motoyuki Exp $ -->
<!-- The FreeBSD Japanese Documentation Project -->
<!-- Original revision: 1.6 -->
<!-- Original revision: 1.8 -->
<sect>
<heading>X Window System と仮想コンソール<label id="x"></heading>
@ -20,8 +20,8 @@
XFree86(tm) の設定を行うのを助けてくれます.
<p>Xaccel サーバーについて調べてみるのもいいでしょう.
これはとても納得のいく価格で販売されています. 詳しくは
<ref id="xig" name="Xi Graphics について"> をご覧ください.
詳しくは <ref id="xig" name="Xi Graphics について"> か
<ref id="metrox" name="Metro Link"> をご覧ください.
<sect1>
<heading>私のマウスはなぜ X で動かないのでしょうか?<label id="x-and-moused"></heading>
@ -217,6 +217,13 @@
残せることと, ログアウト時に X サーバを再起動する責任を init に
押しつけることができることでしょう.
<p>rc.local からロードされる場合, <tt/xdm/ は引数を持たずに起動します.
(すなわち, デーモンとして起動します.) <tt/xdm/ は getty が起動した後に
ロードされなければなりません. そうでないと, <tt/xdm/ は getty と衝突し,
コンソールをロックアウトしてしまいます. この問題に対処する最善の方法は
起動スクリプト(訳注: rc.local のこと)で 10秒ほどの sleepを実行させ,
その後に xdm をロードすることです.
<p>以前のバージョンの FAQ では
<tt>/usr/X11R6/lib/X11/xdm/Xservers</tt> ファイルに X の使う
<tt/vt/ を加えるように書いてあります. これは必要ありません: