訳: &a.yoshiaki;, &a.sugimura;, &a.fukuma;.
FreeBSD は Linux よりもスワップを多く使っているように見えるだけです.
実際にはそうではありません. この点における FreeBSD と
Linux の主な違いは, FreeBSD はより多くのメインメモリを有効利用できるように
するため, 完全にアイドルになったものやメインメモリ上の使われなくなった
ページをスワップにあらかじめ積極的に移動しているということです.
Linux では最後の手段としてページをスワップに移動させるだけという
傾向があります. このスワップの使い方は, メインメモリをより効果的に
使用することによってバランスが保たれています.
FreeBSD はこのような状況では先手策を取りますが, システムが
本当に空き状態の時に, 理由も無くページをスワップしようと決めることはない
ということに注意してください.
したがって, 夜中に使わずにおいたシステムが
朝起きたときにすべてページアウトされているということはないのです.
FreeBSD の a.outフォーマットを理解するためには,
まず UNIXにおいて現在 「優勢」な 3種類の実行フォーマットについて
いくらか知っておく必要があります:
最も古く 「由緒正しい」 unix オブジェクトフォーマットです.
マジックナンバを含む短くてコンパクトなヘッダが先頭にあり,
これがフォーマットの特徴とされています (参照
SVR3 のオブジェクトフォーマットです. ヘッダは単一の
セクションテーブルから成り, .text, .data, .bss セクション以外
の部分を持つことができます. FreeBSD はこの問題を解決するための試みとして, 既知の 書き加える
ユーティリティを提供しています.
FreeBSD は伝統的な立場をとり, 数多くの世代の BSD のリリース
で試され, 実証されてきた
もうおぼろげになってしまった暗い過去に, 単純なハードウェアが
ありました. この単純なハードウェアは, 単純で小さなシステムを
サポートしていました. a.out はこの単純なシステム (PDP-11) での
作業を行なうバイナリとして完全に適したものだったのです.
人々はこの単純なシステムから UNIX を移植する際に, a.out
フォーマットをそのまま使いました. というのは Motorola 68k, VAXen,
といったアーキテクチャへの UNIX の初期の移植ではこれで十分だったからです.
やがてある聡明なエンジニアがソフトウェアでちょっとした
トリックを使うことを決めました. 彼はいくつかのゲートを削り取って
CPU のコアをより速く走らせることができたのです. これは
新しい種類のハードウェア (今日では RISC として知られています) で
動いたのです. さらに, プログラムサイズは巨大になり, ディスク (および物理メモリ)
は依然として相対的に小さかったため, 共用ライブラリのコンセプトが
誕生しました.
また, VM システムはより複雑なものになりました.
これらの個々の進歩は しかし時が経つにつれ, FreeBSD のビルドツールの元となったツー
ル群(特にアセンブラとローダ)と FreeBSD のビルドツール群は異なっ
た進化の経路をたどりました. FreeBSD のツリーでは, 共有ライブラ
リが追加され, バグフィックスも行われました. もともとのツール群
を作成した GNU の人たちは, プログラムを書き直し, クロスコンパ
イラのサポート, 異なるフォーマットを任意に取り込む機能などを追
加していきました. 多くの人々が FreeBSD をターゲットとしたクロ
スコンパイラの構築を試みましたが, FreeBSD の使っている as と
ld の古いプログラムコードはクロスコンパイルをサポートしておら
ず, うまくいきませんでした. 新しい GNU のツール群 (binutils)
は, クロスコンパイル, 共有ライブラリ, C++ 拡張などの機能をサポー
トしています. さらに数多くのベンダが
この場合, `` と
後ろにスラッシュをつけると,
それ以前のバージョンでは, これらの問題が起こった場合に, 問題
を自分自身で発見し, 解決できることに絶対的な自信がある場合は
/usr/include/utmp.h を編集し, UT_NAMESIZE の変更にしたがって,
長いユーザ名を使うことができます.
また, UT_NAMESIZE の変更と一致するように
/usr/include/sys/param.h の MAXLOGNAME 更新しなくてはなりません.
最後に, ソースからビルドする場合は /usr/include を毎回
アップデートする必要があることを忘れないように!
/usr/src/.. 上のファイルを変更しておいて置き換えましょう. はい, 3.0 からは, 統合と改良が重ねられた BSDI の
へメールを送ってください.
3.0 以前のシステムでは,
SUP はバンド幅を浪費しますので, 今は使っていません. ソースコードの
アップデートの現在のおすすめの方法は Q. FreeBSD を動かす時に温度測定をおこなった人はいますか? Linux
は dos よりも温度が下がるということは知っていますが, FreeBSD
についてはこのようなことに触れたものを見たことはありません.
実際熱くなっているように見えます.
A. いいえ. 私たちは 250 マイクログラムの LSD-25 をあらかじめ
与えておいたボランティアに対する目隠し味覚テストを大量に
おこなっています.
35% のボランティアは FreeBSD はオレンジのような味
がすると言っているのに対し Linux は紫煙のような味わいがある
と言っている人もいます. 私の知る限り両方のグループとも温度の
不一致については触れていません. この調査で, 非常に多くの
ボランティアがテストをおこなった部屋から不思議そうに出てきて,
このようなおかしな結果を示したことに私たちは当惑させられました.
私は, ほとんどのボランティアは Apple にいて彼らの最新の
「引っかいて匂いをかぐ」 GUI を使っているのではないかと
考えています. 私たちは奇妙な古い仕事をしているのでしょう!
真面目に言うと, FreeBSD や Linux は共に ``
Q. FreeBSDでカーネルのコンパイルをしている時にメモリから
引っかいているような奇妙な音が聞こえるようなことはあるのでしょうか?
コンパイルをしている時 (あるいは起動時にフロッピドライブを
認識した後の短い間など), 奇妙な引っかくような音がメモリカードの
あたりから聞こえてきます.
A. その通りです. BSDのドキュメントでしばしば「デーモン」に
ついて述べられている理由がわかるでしょう. しかし多くの人は本当の
事については触れていません. 非物質的な存在があなたのコンピュータ
にあるのです. メモリからの引っかいたような音は, 実際に色々な
システム管理タスクの扱いをいかに最善なものにするかという内容を交わす,
デーモンたちのかん高いささやきなのです.
「雑音」があなたに DOS プログラムの ``fdisk /mbr''
を使ってうまくささやきを取り除かせようとしているように聞こえても,
彼らは逆にそうすることをやめさせようとしているのかもしれません.
本当は内蔵スピーカからのビル ゲイツの悪魔的な声が
あなたに影響を与えているのかもしれません.
実行するのは止めましょう, そして振り返ってはいけません!
BSD の守護神 (daemon) の力により,
繰り返しあなたのマシンを支配下に置こうとし, あなたの魂を
無限地獄に突き落そうとする DOSと Windows の双子の悪鬼 (demon) の
影響から自由になりましょう.
選択の機会は与えられました. 私自身はこの引っかくような音が
聞こえていたことを嬉しく思っています.
MFC とは 'CURRENT との合流(Merged From -CURRENT.)'の
頭文字をとったものです. CVS ログで CURRENT から STABLE ブランチ
への合流を示します.
この言葉は, 仲間うちだけに分かる隠語で何とかという意味です.
文字どおりに訳すことはできませんが, BSD の訳は「F1 のレーシング
チーム」か「ペンギンはおいしいスナック」, あるいは「俺たちゃ
Linux より洒落は利いてるぜ」とかそのへんだと言っておけばおっけー
でしょう. :-)
閑話休題. BSD とは, Berkeley CSRG (コンピュータシステム
評議会) が彼らの UNIX の配布形態の名前として当時選んだ
'Berkeley Software Distribution' の略です.
1,172人です.
電球が消えていると -current で文句を言うのに 23人,
設定上の問題で -questions で話をすべきことについて騒ぐのに
4人,
それを send-pr (訳注: 障害報告) するのに 3人 (そのうちの
ひとつは間違って doc カテゴリに送りつけられたうえに, 内容が「暗くなった」
というだけのもの),
buildworld を失敗させ, 5分後には元に戻されるような電球を
テストもせずにコミットするのに 1人,
send-pr した人に, パッチが含まれていないといちゃもんを
付けるのに 8人,
buildworld が失敗すると文句を言うのに 5人,
自分のところではちゃんと動く, cvsup したタイミングが
悪かったんだろうと答えるのに 31人,
新しい電球のためのパッチを -hackers に投げるのに 1人,
自分は 3年も前にパッチを作ったが, それを -current に投げた
ときには無視されただけだった, 自分は send-pr のシステムには嫌な経験が
あると (おまけに, 提案された新しい電球には柔軟性が無いとまで)
文句を言うのに 1人,
電球が基本システムに組み込まれていない, committer は
コミュニティの意見を聞くこと無しにこんなことをする権利は無いと
叫び, 「こんなときに -core は何をやってるんだ!?」とわめき
ちらすのに 37人,
自転車置き場の色に文句を言うのに 200人,
パッチが style(9) 違反だと指摘するのに 3人,
提案された新しい電球は GPL の下にあると文句を言うのに 70人,
GPL と BSD ライセンスと MIT ライセンスと NPL と, 某 FSF
創立者らの個人的な健康法の優位性についての論争を戦わすのに
586人,
スレッドのあちこちの枝を -chat や -advocacy に移動するのに
7人,
提案された電球を, 古いのよりずっと薄暗いのに
コミットしてしまうのに 1人,
FreeBSD に薄暗い電球を付けるくらいなら真っ暗のほうがましだ,
という, コミットメッセージへの凄まじい非難の嵐によって, それを
元に戻すのに 2人,
薄暗い電球が帳消しにされたことに対してどなり声で口論し,
-core の声明を要求するのに 46人,
もし FreeBSD をたまごっちに移植することになったときに
都合がいいように, もっと小さな電球を要求するのに 11人,
-hackers と -chat の S/N比に文句を言い, 抗議のため講読を
取りやめるのに 73人,
「unsubscribe」 「どうやったら講読をやめられるんですか?」
「このメーリングリストからわたしを外してください」といった
メッセージを, 例のフッタをくっつけて投稿するのに 13人,
みんなが激論を戦わせるのに忙がしくて気付かない間に, 作業中の
電球をコミットするのに 1人,
新しい電球は TenDRA を使ってコンパイルされた場合に 0.364% も
明るくなる (ただし電球を立方体にしなければならないが), だから
FreeBSD は EGCS から TenDRA に変えるべきだと指摘するのに 31人,
新しい電球は美しさに欠けていると文句を言うのに 1人,
「MFC って何ですか?」と聞くのに 9人 (send-pr した人も含む),
電球が取り替えられてから 2週間も消えっぱなしだと文句を
言うのに 57人.
以下は