訳: 内川 喜章 <yoshiaki@kt.rim.or.jp>、 杉村 貴士
<sugimura@jp.FreeBSD.org>、 福間 康弘
<yasuf@big.or.jp>、 1997 年 11 月 10 日 -
1999 年 5 月 8 日
実際にはそうではありません。 FreeBSD は Linux よりもスワップを多く使っているように見えるだけです。 この点における FreeBSD と Linux の主な違いは、 FreeBSD はより多くのメインメモリを有効利用できるようにするため、 完全にアイドルになったものやメインメモリ上の使われなくなったページを、 スワップにあらかじめ積極的に移動しているということです。 Linux では、 最後の手段としてページをスワップに移動させるだけという傾向があります。 このスワップの使い方は、 メインメモリをより効果的に使用することによってバランスが保たれています。
FreeBSD はこのような状況では先手策を取りますが、 システムが本当に空き状態の時に、 理由も無くページをスワップしようと決めることはないということに注意してください。 したがって、 夜中に使わずにおいたシステムが朝起きたとき、 すべてページアウトされているということはないのです。
12.2. ほとんどプログラムは実行されていないのに、 どうして top(1) は非常に少ない free memory を報告するのでしょうか?
簡単に言えば、free memory とは無駄になっているメモリのことだからです。 プログラムが確保しているメモリ以外のすべてのメモリは、 FreeBSD カーネル内でディスクキャッシュとして利用されます。 この値は top(1) において Inact、 Cache Buf として表示され、 それぞれは異なるエージングレベル (訳注: データがどれだけ古いかを示す評価値) でキャッシュされた全データを表します。 データがキャッシュされると言うのは、 最近アクセスされたデータであれば、 再度そのデータをアクセスするためにシステムが遅いディスクにアクセスする必要がない、 ということを意味します。 そのため、全体のパフォーマンスが向上します。 一般的に、top(1) で表示される Free メモリが小さい値を示すことは良いことで、 自由に使えるメモリの残量が本当に少ない、 ということを表しているわけではありません。
FreeBSD が何故 ELF フォーマットを利用しているのかを理解するためには、 まず UNIXにおいて現在「優勢」な 3 種類の実行フォーマットについて いくらか知っておく必要があります。
注意: FreeBSD 3.x より前の FreeBSD では a.out フォーマットが使われていました。
最も古く 「由緒正しい」 unix オブジェクトフォーマットです。 マジックナンバを含む短くてコンパクトなヘッダが先頭にあり、 これがフォーマットの特徴とされています (a.out(5) に詳細な内容があります)。 ロードされる 3種類のセグメント、 .text、 .data、 .bss と加えてシンボルテーブルと文字列テーブルを含みます。
COFF
SVR3 のオブジェクトフォーマットです。 ヘッダは単一のセクションテーブルから成り、 .text、 .data、 .bss セクション以外の部分を持つことができます。
ELF
COFFの後継です。複数のセクションをサポートし、32-bit と 64-bitのいずれの値も可能です。大きな欠点の一つは、ELF はそれぞれのシステムアーキテクチャ毎に単一の ABI のみが存在するという仮定で設計されていることです。 この仮定はまったく正しくありません。 商用の SYSV の世界でさえそうです (少なくとも SVR4、 Solaris、SCO の 3種類の ABI があります)。
FreeBSD はこの問題を解決するための試みとして、 既知の ELF 実行ファイルに ABI に応じた情報を 書き加えるユーティリティを提供しています。 詳しくは brandelf(1) のマニュアルページを参照してください。
FreeBSD は伝統的な立場をとり、数多くの世代の BSD のリリースで試され、実証されてきた a.out(5) フォーマットを伝統的に使用しています。 いつかは FreeBSD システムでネイティブ ELF バイナリを作り、 実行することができるようになるかもしれませんが、 初期の頃 FreeBSD では ELF をデフォルトのフォーマットに変更するという動きは ありませんでした。なぜでしょうか? ところで Linux においては、 ELF への苦痛をともなった変更は、 その時に a.out 実行フォーマットから逃れたというよりは、 ジャンプテーブルベースの共有ライブラリのメカニズムの柔軟性の低さからの脱却でした。 これはベンダや開発者全体にとって、 共有ライブラリの作成が非常に難しかった原因でした。 ELF のツールには共有ライブラリの問題を解決することができるものが提供されており、 またいずれにせよ一般的に「進歩」していると考えられます。 このため移行のコストは必要なものとして容認され、 移行は行なわれました。
FreeBSD の場合は、共有ライブラリのメカニズムは Sun の SunOS 形式の共有ライブラリの メカニズムに極めて近いものになっていて、 非常に使いやすいものになっています。 しかしながら、FreeBSD では 3.0 から ELF バイナリをデフォルトのフォーマットとして公式にサポートしています。 a.out 実行フォーマットはよいものを私達に提供してくれているものの、 私たちの使っているコンパイラの作者である GNU の人々は a.out フォーマットのサポートをやめてしまったのでした。 このことは、 私たちに別バージョンのコンパイラとリンカを保守することを余儀なくされることとなり、 最新の GNU 開発の努力による恩恵から遠ざかることになります。 その上、ISO C++ の、 とくにコンストラクタやデストラクタがらみの要求もあって、今後の FreeBSD のリリースでネイティブの ELF のサポートされる方向へと話が進んでいます。
もうおぼろげになってしまった暗い過去に、単純なハードウェアがありました。 この単純なハードウェアは、単純で小さなシステムをサポートしていました。 a.out はこの単純なシステム (PDP-11) での作業を行なうバイナリとして完全に適したものだったのです。 人々はこの単純なシステムから UNIX を移植する際に、a.out フォーマットをそのまま使いました。というのは Motorola 68k、VAXen、 といったアーキテクチャへの UNIX の初期の移植ではこれで十分だったからです。
やがてある聡明なエンジニアが、 ソフトウェアでちょっとしたトリックを使うことを決めました。 彼はいくつかのゲートを削り取って CPU のコアをより速く走らせることができたのです。 これは新しい種類のハードウェア (今日では RISC として知られています) で動いたのです。 a.out はこのハードウェアには適していなかったので、 このハードウェア上で多くのフォーマットが、 限定された単純な a.out フォーマットでのものよりもより良いパフォーマンスを出すことを目指して開発されたのです。 COFF、ECOFF、 そしていくつかの有名でないフォーマットが ELF が標準になる前に開発され、 それらの限界が探求されたのです。
さらに、プログラムサイズは巨大になり、 ディスク (および物理メモリ) は依然として相対的に小さかったため、 共用ライブラリのコンセプトが誕生しました。 また、VM システムはより複雑なものになりました。 これらの個々の進歩は a.out フォーマットを使用して遂げられましたが、 その有用性は新しい機能とともにどんどん広がってきました。 これらに加え、実行時に必要なものを動的にロードする、 または初期化コードの実行後にプログラムの一部を破棄し、 コアメモリおよびスワップ空間を節約するという要望が高まりました。 プログラミング言語はさらに複雑になり、main 関数の前に自動的にコールされるコードの要望が高まりました。 多くの機能拡張が行なわれ、a.out フォーマットがこれらすべてを実現できるようになり、 それらはしばらくは基本的に動作していました。 やがて、a.out はコードでのオーバヘッドと複雑さを増大させずに、 これらの問題すべてを処理することに無理がでてきました。 一方、ELF はこれらの問題の多くを解決しますが、 現状稼働しているシステムからの切替えは厄介なものになるでしょう。 そのため ELF は、a.out のままでいることが ELF への移行よりももっと厄介なものになるまで待つ必要がありました。
しかし時が経つにつれ、FreeBSD のビルドツールの元となったツール群 (特にアセンブラとローダ) と FreeBSD のビルドツール群は異なった進化の経路をたどりました。 FreeBSD のツリーでは、共有ライブラリが追加され、 バグフィックスも行われました。 もともとのツール群を作成した GNU の人たちは、プログラムを書き直し、 クロスコンパイラのサポート、 異なるフォーマットを任意に取り込む機能などを追加していきました。 多くの人々が FreeBSD をターゲットとしたクロスコンパイラの構築を試みましたが、 FreeBSD の使っている as と ld の古いプログラムコードはクロスコンパイルをサポートしておらず、 うまくいきませんでした。 新しい GNU のツール群 (binutils) は、 クロスコンパイル、共有ライブラリ、C++ 拡張などの機能をサポートしています。 さらに数多くのベンダが ELF バイナリをリリースしています。 FreeBSD にとって ELF バイナリが実行できることは、 非常にメリットがあります。ELF バイナリが FreeBSD で動くのなら、a.out を動かすのに手間をかける必要はありませんね。 長い間忠実によく働いた老いた馬は、 そろそろ牧草地で休ませてあげましょう。
ELF は a.out に比べてより表現力があり、 ベースのシステムに対してより幅広い拡張性を提供できます。 ELF 用のツールはよりよく保守されています。 また多くの人にとって重要なクロスコンパイルもサポートしています。 ELF の実行速度は、ほんの少し a.out より遅いかもしれませんが、 実際に速度の差をはかるのは困難でしょう。 ELF と a.out の間には、ページマッピング、 初期化コードの処理など多くの違いがありますが、 とりたてて重要なものはありません。しかし違いがあるのは確かです。ほどなく、 GENERIC カーネルから a.out のサポートが外されます。 a.out のプログラムを実行する必要性がなくなれば、 最終的に a.out のサポートはカーネルから削除されます。
シンボリックリンクは許可属性を持ちません。 また chmod(1) のデフォルト動作は、 シンボリックリンクをたどってリンク先のファイルの許可属性を変更するようになっていません。 そのため、 foo というファイルがあり、 このファイルへのシンボリックリンク bar があったとすると、 以下のコマンドは常に成功します。
% chmod g-w bar
しかしこの場合、foo の許可属性は変更されません。
この場合、“-H” か “-L” のどちらかのオプションを “-R” と同時に使う必要があります。 chmod(1) と symlink(7)
のマニュアルページにはもっと詳しい情報があります。
警告 “
-R” オプションは再帰的に chmod(1) を実行します。ディレクトリやディレクトリへのシンボリックリンクを chmod する場合は気をつけてください。 シンボリックリンクで参照されている単一のディレクトリのパーミッションを変更したい場合は、 chmod(1) をオプションをつけずに、 シンボリックリンクの名前の後ろにスラッシュ (“/”) をつけて使います。たとえば、“foo” がディレクトリ “bar” へのシンボリックリンクである場合、 “foo” (実際には “bar”) のパーミッションを変更したい場合には、このようにします。% chmod 555 foo/後ろにスラッシュをつけると、 chmod(1) はシンボリックリンク “foo” を追いかけてディレクトリ “bar” のパーミッションを変更します。
UT_NAMESIZE を変更してシステム全体を作り直せば十分で、 それだけでうまくいくだろうとあなたは考えるかもしれません。 残念ながら多くのアプリケーションやユーティリティ (システムツールも含めて) は、 小さな数値を構造体やバッファなどに使っています (必ずしも “8” や “9” ではなく、 “15” や “20” などの変った値を使うものもあります)。 (固定長のレコードを期待するところで可変長レコードになるため、 ) 台無しになったログファイルを得ることになるということだけでなく、 Sun の NIS のクライアントの場合は問題が起きますし、他の UNIX システムとの関連においてこれら以外の問題も起きる可能性があります。
しかし、FreeBSD 3.0 以降では 16 文字となり、 多くのユーティリティのハードコードされた名前の長さの問題も解決されます。 実際にはシステムのあまりに多くの部分を修正するために、 3.0 になるまでは変更が行われませんでした。
それ以前のバージョンでは、これらの問題が起こった場合に、 問題を自分自身で発見し、解決できることに絶対的な自信がある場合は /usr/include/utmp.h を編集し、 UT_NAMESIZE の変更にしたがって、 長いユーザ名を使うことができます。 また、 UT_NAMESIZE の変更と一致するように /usr/include/sys/param.h の MAXLOGNAME 更新しなくてはなりません。 最後に、ソースからビルドする場合は /usr/include を毎回アップデートする必要があることを忘れないように! /usr/src/.. 上のファイルを変更しておいて置き換えましょう。
はい、FreeBSD 3.0 からは、 統合と改良が重ねられた BSDI の doscmd DOS エミュレーションサブシステムを使ってできるようになりました。 今なお続けられているこの努力に興味を持って参加していただけるなら、 FreeBSD-emulation メーリングリスト へメールを送ってください。
FreeBSD 3.0 以前のシステムでは、 pcemu という巧妙なユーティリティが FreeBSD Ports Collection にあり、 8088 のエミュレーションと DOS のテキストモードアプリケーションを動かすに十分な BIOS サービスを行ないます。これは X ウィンドウシステムが必要です (XFree86 として提供されています)。
FreeBSD はいずれのサーバーにもアクセスを開放していませんが、 Unix システムへの自由なアクセスを提供しているところがあります。 費用はまちまちで、限定されたサービスが利用できます。
M-Net としても知られる Arbornet, Inc は 1983 年から Unix システムへのアクセスを提供しています。 System III が動作する Altos に始まり、1991 年には BSD/OS に移行しました。2000 年 6 月には、再び FreeBSD に 移行しています。M-Net には SSH または telnet 経由で アクセスすることができ、FreeBSD ソフトウェア一式が 利用できるようになっています。ただし、ネットワーク接続は 会員と、非営利組織として運営されているシステムに寄付をする 後援者に制限されています。また、M-Net は掲示板システムと 双方向チャットも提供しています。
Grex は、 掲示板システムと双方向チャットソフトウェアが同じであることも含め、 M-Net とよく似たサイトを提供しています。しかし、 マシンは Sun 4M で、SunOS が動作しています。
SUP とは、ソフトウェアアップデートプロトコル (Software Update Protocol) で カーネギーメロン大学 (CMU) で開発ツリーの同期のために開発されました。 私たちの中心開発ツリーをリモートサイトで同期させるために使っていました。
SUP はバンド幅を浪費しますので、今は使っていません。 ソースコードのアップデートの現在のおすすめの方法は FreeBSD ハンドブックの「CVSup」にあります。
FreeBSD を動かす時に温度測定を行なった人はいますか? Linux は dos よりも温度が下がるということは知っていますが、FreeBSD についてはこのようなことに触れたものを見たことはありません。 実際熱くなっているように見えます。
いいえ。 私たちは 250 マイクログラムの LSD-25 をあらかじめ与えておいたボランティアに対する、 目隠し味覚テストを大量に行なっています。 35% のボランティアは FreeBSD はオレンジのような味がすると言っているのに対し、 Linux は紫煙のような味わいがあると言っている人もいます。 両方のグループとも温度の不一致については何も触れていません。 この調査で、非常に多くのボランティアがテストを行なった部屋から不思議そうに出てきて、 このようなおかしな結果を示したことに私たちは当惑させられました。 私たちは、ほとんどのボランティアは Apple にいて彼らの最新の「引っかいて匂いをかぐ」GUI を使っているのではないかと考えています。 私たちは奇妙な古い仕事をしているのでしょう!
真面目に言うと、FreeBSD や Linux は共に “HLT” (停止) 命令をシステムのアイドル (idle) 時に使い、 エネルギーの消費を押えていますので熱の発生も少なくなります。 また、APM (advanced power management) を設定してあるなら FreeBSD は CPU をローパワーモードにすることができます。
12.11. 誰かが私のメモリカードをひっかいているのですか??
FreeBSDでカーネルのコンパイルをしている時、 メモリから引っかいているような奇妙な音が聞こえるようなことはあるのでしょうか? コンパイルをしている時 (あるいは起動時にフロッピドライブを認識した後の短い間など)、 奇妙な引っかくような音がメモリカードのあたりから聞こえてきます。
その通り! BSD の文書には良く、デーモン (daemon) という言葉が出てきます。 ほとんどの人は知らないのですが、 デーモンとは、あなたのコンピュータを依り代とする、 純粋で非物質的な存在のことです。 メモリから聞こえるひっかくような音は、 さまざまあるシステム管理タスクの扱いをいかに最善なものにするか、 といったことを決めるときにデーモンたちが交わす、 かん高いささやき声なのです。
この雑音が聞こえたとき、DOS から “fdisk /mbr” というプログラムを実行すれば、 うまくデーモンを追い出すことができるでしょう。 でも、デーモンはそれに歯向かって fdisk の実行をやめさせようとするかも知れません。 もし、それを実行しているときにスピーカならビル ゲイツ (Bill Gates) の悪魔のささやきが聞こえてきたら、 すぐに立ち上がって逃げてください。決して振り返ってはいけません! BSD のデーモンたちが押え込んでいた双子のデーモン、DOS と Windows が解放され、 あなたの魂を永遠の破滅へ導こうとマシンを再び支配してしまうことでしょう。 それを知った今や、選べと言われたら、 むしろひっかき音に慣れる方を選ぶのではありませんか?
MFC とは、 「CURRENT との合流 (Merged From -CURRENT)」の頭文字をとったものです。 CVS ログで -CURRENT から -STABLE ブランチへの合流を示します。
この言葉は、仲間うちだけに分かる隠語で何とかという意味です。 文字どおりに訳すことはできませんが、 BSD の訳は「F1 のレーシングチーム」か「ペンギンはおいしいスナック」、 あるいは「俺たちゃ Linux より洒落は利いてるぜ」とかそのへんだと言っておけばおっけーでしょう。 :-)
冗談はさておき、BSD とは、Berkeley CSRG (コンピュータシステム評議会) が彼らの UNIX の配布形態の名前として当時選んだ "Berkeley Software Distribution" の略です。
repo-copy (“repository copy” の略) とは、 CVS リポジトリの中で直接ファイルをコピーすることを示す用語です。
repo-copy を行なわない場合を考えます。 リポジトリの中の異なる場所にファイルをコピーしたり、 移動したりする必要性が生じると、コミッターは ファイルを新しい場所に置くために cvs add を、 そして古いファイルが削除される場合は、古いファイルに対して cvs rm を実行するでしょう。
この方法の欠点は、ファイルの変更履歴 (たとえば CVS ログのエントリ) が新しい場所にコピーされないことです。 FreeBSD プロジェクトではこの変更履歴をとても有用なものだと考えているため、 前述の方法の代わりにリポジトリコピーが良く用いられます。 この操作は cvs プログラムを利用するのではなく、 リポジトリの管理担当者がリポジトリの中でファイルを直接コピーすることによって行なわれます。
一言で言ってしまえば、そうすべきではありません。 もう少し詳しく説明しましょう。 たとえば、あなたがバイク小屋を建てる技術を持っていたとします。 しかしそれは、塗ろうとしている色が気に入らないからと言って、 他人がバイク小屋を建てようとしているのを止めて良い理由にはなりませんよね。 これは、自分の行動について十分な理解を持っているなら、 あなたは細かな機能すべてにわたって議論する必要はないことを示す比喩です。 ある変更によって産み出されるノイズの総量は、 その変更の複雑さに反比例するのだと言っている人達もいます。
さらに詳しく、完全な回答を紹介しましょう。 Poul-Henning Kamp は、 「sleep(1) は分数の秒数を引数として取るべきか」という 非常に長い議論の後で、 “A bike shed (any colour will do) on greener grass...” というタイトルの長文を投稿しました。 関係のある部分だけを以下に掲載します。
|
“このバイク小屋、どうだろう?” 誰かがたずねました。 長い…というか、むしろ古い話になりますが、 中身はわりと簡単な話です。パーキンソン (C. Northcote Parkinson) は 1960 年代初頭に “パーキンソンの法則” と呼ばれる本を書きました。 この中にはさまざまな経営の力学に関する洞察が含まれています。 [ この本に関する解説があったが省略 ] バイク小屋に関連する例として、 もう一つの重要な構成要素となっているのは原子力発電所です。 この本の年代がわかりますね。 パーキンソンは、あなたが重役会に出席して 数百万から数10億ドル規模の原子力発電所の建設の承認を得る ことはできるでしょうが、あなたが建てたいのがバイク小屋ならば、 終わりなき議論に巻き込まれるだろうと言っています。 パーキンソンはこのように説明しています。 これは原発が余りに巨大で高価で複雑なので誰もこれを一手に握ることができず、 それを試みるくらいならむしろ、手が出せなくなる前に 他の誰かがすべてを詳細にチェックすることを 引き受けることに頼るのです。 リチャード・ファインマン (Richard P. Feynmann) は、 ロスアラモスでこの手の重要な経験を何度も見てきたと本に書いています。 一方でバイク小屋の場合は、誰でも週末にこれを作り上げることができ、 しかも TV の試合を見る時間があまるほどです。 なので、どんなに準備が整えてあって、どんなに計画が順当であったとしても、 わたしは仕事をやっているよ、 わたしは注意を払っているよ、そして わたしはここにいるよ、 ということを示そうとする人が必ず現れます。 デンマークではこれを「指紋をつける」と呼んでいます。 これは個人的なプライドや名声を求め、 ある場所を指し示して「ここ! ここは俺が やったんだぜ〜」というようなものです。 これは政治家に見られる強い特徴ですが、 その他のほとんどの人もこういう風に振舞う可能性はあるのです。 生乾きのセメントにつけられた足跡のことを考えればお分かりでしょう。 |
||
| --1999 年 10 月 2 日 freebsd-hackers にて Poul-Henning Kamp | ||
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 人。
Nik Clayton
<nik@FreeBSD.org>による追記: これには爆笑しました。それからわたしは考えました。 「ちょっと待てよ? このリストのどこかに、 『これを文書にまとめるのに 1人』というのがあってもいいんじゃないか?」
それからわたしは悟りを開いたのです :-)
この項目の著作権は Copyright (c) 1999
Dag-Erling C. Sm�rgrav <des@FreeBSD.org> にあります。
無断で使用しないでください。
本文書、および他の文書は ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/ からダウンロードできます。
FreeBSD に関する質問がある場合には、ドキュメント を読んだ上で <questions@FreeBSD.org> まで (英語で)
連絡してください。
本文書に関する質問については、<doc@FreeBSD.org> まで電子メールを (英語で)
送ってください。