aboutsummaryrefslogtreecommitdiff
path: root/ja_JP.eucJP/FAQ/misc.sgml
diff options
context:
space:
mode:
Diffstat (limited to 'ja_JP.eucJP/FAQ/misc.sgml')
-rw-r--r--ja_JP.eucJP/FAQ/misc.sgml143
1 files changed, 129 insertions, 14 deletions
diff --git a/ja_JP.eucJP/FAQ/misc.sgml b/ja_JP.eucJP/FAQ/misc.sgml
index d3d9c33401..c7aaa869f6 100644
--- a/ja_JP.eucJP/FAQ/misc.sgml
+++ b/ja_JP.eucJP/FAQ/misc.sgml
@@ -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>メモリ中に同時に保持する事のできるダーティページの実際の量は
- 減少しません. クリーンなページが必要に応じて置き換えられます.
+ <p>FreeBSD は Linux よりもスワップを多く使っているように見えるだけです.
+ 実際にはそうではありません. この点における FreeBSD と
+ Linux の主な違いは, FreeBSD はより多くのメインメモリを有効利用できるように
+ するため, 完全にアイドルになったものやメインメモリ上の使われなくなった
+ ページをスワップにあらかじめ積極的に移動しているということです.
+ Linux では最後の手段としてページをスワップに移動させるだけという
+ 傾向があります. このスワップの使い方は, メインメモリをより効果的に
+ 使用することによってバランスが保たれています.
+
+ <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>