diff --git a/ja_JP.eucJP/articles/contributing/article.sgml b/ja_JP.eucJP/articles/contributing/article.sgml index a999cb1fe8..44af8a02fe 100644 --- a/ja_JP.eucJP/articles/contributing/article.sgml +++ b/ja_JP.eucJP/articles/contributing/article.sgml @@ -1,699 +1,698 @@ Jordan Hubbard 寄稿: FreeBSD への貢献 貢献 あなたも何か FreeBSD のために貢献したくなりましたか? 素晴らしい! 私たちは常に支援を受ける用意がありますし, FreeBSD は生き残るためにユーザベースの貢献に頼るようなシステムの一つです. あなたの貢献は感謝されるだけではなく, FreeBSD が成長し続けるために極めて重要なものな のです! 一部の人達が言っているのとは逆に, 貢献を受け付けてもらうために腕利 きのプログラマーになるとか FreeBSD コアチームの人と親友になる必要はありません. FreeBSD プロジェクトの開発は, 多くのそして益々増加する世界中の貢献者達によってなされており, 彼らの年齢, 専門技術分野は多岐に渡ります. そして手の空いている人よりも成されるべき仕事の方が常に多いのです. FreeBSD プロジェクトがカーネルや散在しているユーティリティよりも, オペレーティングシステム環境 (と, そのインストール) に対して責任を持つ ようになったため, 私たちの TODO リストはドキュメンテーション, ベータテスト, 高度に専門化されたタイプのカーネル開発の好例を紹介するなど非常に広い範囲のタスクに渡ります. あなたの技能レベルに関わらず, プロジェクトを支援できることが必ず何かあります! FreeBSD 関連の事業に従事している商業団体が私たちにコンタクトすることも歓迎します. あなたの製品を (FreeBSD 上で) 動作させるには, 特別な拡張が必要ではありませんか? あまりにも風変わりな要求でなければ, それを受け入れる用意が私たちにあるとわかるはずです. 付加価値のある製品ですか? 私たちに知らせてください! 多分私たちは, ある面において共同して作業をすることができるでしょう. フリーソフトウェア界は, ソフトウェアがそのライフサイクルを通してどのように開発され, 売られ, 保守されていくかについて, 既存の仮説に挑戦しています. 少なくとももう一度考慮してみることを私たちは強くお奨めします. 何が必要? 次のタスクとサブプロジェクトのリストは, コアチームの色々な TODO リストと最近2ヶ月で集めたユーザリクエストを合わせたものです. 可能なところでは, 緊急度によってタスクがランクづけされています. もしここにあるタスクの実行に興味があるのでしたら, コーディネータの名前をクリックしてメールを送ってください. もしコーディネータが決まっていなければ, あなたがボランティアしてみませんか? 進行中のタスク 次のタスクはやっておくべきではありますが, 特にさし迫っているわけではありません: 完全な KLD ベースのドライバのサポート / コンフィグレーションマネージャ. 穏やかな方法でハードウェアを検知するコンフィグレーションマネージャの作成 (第3ステージ・ブートの中に?). ハードウェアが必要とする KLD だけを残す等. PCMCIA/PCCARD. コーディネータ: &a.msmith; と &a.imp; ドキュメンテーション! pcic ドライバの信頼性のある操作 (テスト要). sio.c のリコグナイザとハンドラ (ほぼ完了). ed.c のリコグナイザとハンドラ (ほぼ完了). ep.c のリコグナイザとハンドラ (ほぼ完了). User-mode のリコグナイザとハンドラ (部分的に完了). 先進的なパワーマネージメント. コーディネータ: &a.nate; と &a.phk; APM サブドライバ (ほぼ完了). IDE/ATA ディスクサブドライバ (部分的に完了). syscons/pcvt サブドライバ. PCMCIA/PCCARD ドライバ群との統合 (サスペンド / レジューム). 優先度の低いタスク 次のタスクは全くのあら隠し, または誰もすぐにおこないそうもない投資のような仕事を表します: 最初の N 項目は Terry Lambert terry@lambert.org からのものです. ネットワークカードと一緒に提供される ODI カードドライバを使用できるようにする, NetWare サーバ (プロテクトモードの ODI ドライバ) ローダとサブサービス. NDIS ドライバと NetWare の SCSI ドライバについても同様. 前のリビジョンの FreeBSD マシンではなく, Linux マシンで動作する 「アップグレードシステム」オプション. カーネルのマルチスレッド化 (カーネルのプリエンプションが必要). カーネルのプリエンプション付き対称マルチプロセッシング (カーネルのプリエンプションが必要). ポータブルコンピュータのサポートにおける協調の試み. これは PCMCIA ブリッジング規則と電源管理イベント処理の変更により, いくらかは処理できます. しかし, 内蔵ディスプレイと外部ディスプレイの検出, この 2 種類のディスプレイがあるという事実に基づく異なる解像度の選択, マシンがドックにある場合にはディスクのモータ停止を防止すること, マシンのブート能力に影響を与えずにドックベースのカードの消滅を可能にすること (PCMCIA と同じ問題) などの問題があります. もっと簡単なタスク 上のセクションで挙げたタスクは膨大な時間の投資または FreeBSD のカーネルに関する深い知識を必要とします (もしくはそのどちらも). しかしながら, "週末ハッカー"やプログラミングのスキルを持たない人々に適した立派なタスクも数多くあります. FreeBSD-current を運用しており, 状態の良いインターネット接続があるならば, current.FreeBSD.org という一日に一回フルリリースを行っているマシンがあります — 時おり最新のリリースをそこからインストールし, その過程で何か問題があるなら報告して下さい. freebsd-bugs メーリングリストを読んでください. そこではあなたが建設的なコメントを付けたりテストできるパッチが提供されているような問題がある かもしれません. もしくはそれらの問題の一つをあなた自身で修正することさえできるかもしれません. 定期的に FAQ とハンドブックを通して読んでみてください. もしまずい説明や古い事柄や完全に間違っていることなどがあれば我々に知らせて下さい. さらに良いのは我々に修正案を送ることです (SGML は学ぶのにそれほど難しくありませんが, プレインテキストでも問題はありません). (もしまだないならば) FreeBSD のドキュメントを自分の母国語に翻訳するのを手伝ってください — 作業している人がいるかどうか &a.doc; にメールを送って聞くだけです. とはいっても, そうすることによってあなたが全ての FreeBSD ドキュメントの翻訳に携わるようになるというわけではないですからね — 実際, もっとも翻訳が必要とされているドキュメントはインストール方法です. たまに(もしくは定期的に) freebsd-questions メーリングリストや comp.unix.bsd.freebsd.misc を読んでください. これは, あなたの持っている専門知識を共有したり誰かが抱えている問題を解決するのに非常に有効なものになり得ることです. 時にはあなた自身で新しいことを学ぶことさえできるかもしれません. これらのフォーラムはやるべきことのアイディアの源にもなり得るのです. -current に正しく当てられるがしばらく経っても(通常は 2, 3 週間) -stable に取り込まれてないようなバグフィックスがあるならばコミッターに丁寧に思い出させてください. 寄贈ソフトウェアをソースツリーの src/contrib に移動させてください. src/contrib 以下のコードが最新のものであるか確認してください. 警告を詳細に報告するようにして ソースツリー全体(もしくはその一部)を構築してみてください. そして警告が出ないようにしてください. ports で, gets() を使っているとか malloc.h をインクルードしているなどといった警告が出ないようにしてください. もしなんらかの ports に関わっているなら, あなたのパッチを作者にフィードバックしてください (次のバージョンが出た時にあなたが楽になります). このリストに追加するタスクを提案して下さい! 障害報告 (PR; Problem Report) データベースにおける作業 障害報告 (PR) データベース FreeBSD 障害報告リストでは, 現在問題となっている報告と, FreeBSD の利用者によって提出された改良の要望に関する全てのリストを公開しています. open 状態の障害情報を見て, 興味を引く内容かどうか確かめて下さい. 本当に複雑なものも含まれているでしょうし, 例えば, 障害報告に対する修正がちゃんとしたものであるかどうか単にチェックするだけのとても簡単な作業もあるでしょう. まず, まだ誰にも割り当てられていない障害報告から作業を始めて下さい. もし, 誰か他の人に割り当てが決まっているけれども自分が作業可能だ, というものがあれば, 作業ができるかどうか — 既にテスト用パッチが用意されているのかどうか, あるいは その問題についてあなたが考えている, より進んだ考えに関して議論ができるかどうか, 割り当てられている人に電子メールで問い合わせて下さい. 貢献の仕方 一般的に, システムへの貢献は次の 6 つのカテゴリの1つ以上に分類されます: バグ報告と一般的な論評 報告するべきバグがあったり, 提案したいことがあれば: 一般的な 技術的関心事に関するアイデアや提案は &a.hackers; へメールしてください. 同様に, このような事柄に興味のある (そして膨大なメール! に耐えられる) 人は, &a.majordomo; へメールを送って hackers メーリングリストに参加すると良いでしょう. 情報については メーリングリスト を参照してください. バグを発見したり変更を送付しようとしている場合は &man.send-pr.1; プログラムか WEB ベースの + url="../../../../ja/send-pr.html">ウェブベースの send-pr を使用して報告してください. バグレポートの各項目を埋めるようにしてください. 65KB を超えるのでなければ, レポート中に直接パッチを入れてくださって結構です. パッチがソースツリーにすぐ適用できるものならば, 報告の概要に [PATCH] と書いておいてください. その場合, カット＆ペーストはしないでください. カット＆ペーストではタブがスペースに展開されてパッチが使い物にならなくなってしまいます. 20KB を超える場合は, それらを compress して &man.uuencode.1; することも検討してください. とても大きくなる場合は - ftp.FreeBSD.org:/pub/FreeBSD/incoming/ + url="ftp://ftp.FreeBSD.org/pub/FreeBSD/incoming/">ftp://ftp.FreeBSD.org/pub/FreeBSD/incoming/ を利用してください. レポートがファイリングされれば, バグ報告の確認とトラッキング番号をメールで受け取るはずです. このトラッキング番号を覚えておき, 問題に関する詳細情報を bug-followup@FreeBSD.org に メールで送って更新できるようにしてください. 例えば "Re: kern/3377" のように, この番号をサブジェクト行に使用してください. すべてのバグレポートの追加情報は, この方法で送付されなければいけません. もしタイムリに (あなたの電子メール接続形態にもよりますが, 3日から 1週間) 確認を受けとれないとか, 何らかの理由で &man.send-pr.1; コマンドが使用できない場合には, &a.bugs; へメールを送り, 誰か代りにバグ報告を送付してもらうようたずねてください. 文書の変更 文書に関する提案 文書の変更は &a.doc; が監督しています. バグ報告と一般的な論評 に記述されているように send-pr コマンドを使用して, 提案や変更 (どんな些細なものでも歓迎します!) を送ってください. 現存のソースコードの変更 FreeBSD-current 現存のソースコードへの追加または変更は, いくらかトリッキーな仕事で あり, core の FreeBSD 開発の現状にあなたがどれだけ通じているかに大きく依存します. FreeBSD-currentとして知られる FreeBSD の特別な継続的リリースがあります. FreeBSD-current は開発者の積極的な活動の便宜のために, 色々な方法で利用可能になっています. FreeBSD-current の入手と使用方法についての詳しい情報については最新の FreeBSD を追いかける を参照してください. 不幸にして古いソースをもとに仕事をすることは, 時々あなたの変更が時 代遅れ, または FreeBSD への簡単な再統合に合わなくなっていることを意味します. システムの現状に関する議論がおこなわれている &a.announce; と &a.current; へ参加することで, この可能性を最小限にすることができます. 完全な最新のソースを変更のベースにできることが確実になったと仮定して, 次のステップは FreeBSD の保守担当者へ送る差分ファイルの生成です. これは &man.diff.1; コマンドを使用しておこないますが, context diff形式が好まれるようです. 例えば: diff &prompt.user; diff -c oldfile newfile または &prompt.user; diff -c -r olddir newdir これで指定されたソースファイルまたはディレクトリ階層に対するコンテキスト形式の差分が生成されます. 詳しい説明は &man.diff.1; のマ ニュアルページを参照してください. 差分ファイル (&man.patch.1; コマンドでテストできます) を作ったら, それらを FreeBSD に含めてもらうようメールで送ってください. バグ報告と一般的な論評 に記述されているように &man.send-pr.1; コマンドを使用してください. 差分ファイルだけを &a.hackers; へ送ってはいけません. 途方にくれてしまいます! 私たちは多忙なので, あなたの提案に大変感謝します (これはボランティアのプロジェクトです!). すぐに取りかかることはできませんが, 処理されるまではちゃんと PR データベースに残っています. 報告の概要に [PATCH] と書いてあなたの提案を表明してください. uuencode あなたがそうした方がいいと思う場合 (例えば, ファイルの追加, 削除または名称変更など), 変更を tar ファイルにまとめ, &man.uuencode.1; プログラムにかけてください. shar アーカイブも歓迎します. 例えばあなたがそれ自身のさらなる配布を管理するコピーライト問題を良く分かっていないとか, 単に厳しいレビューをおこなっておらず, リリースする準備ができていないなど, あなたの変更が潜在的に不安定な性質をも つものである場合, &man.send-pr.1; で送付するよりむしろ &a.core; へ直接送ってください. コアチームメーリングリスト宛のメールは, 日々の仕事のほとんどを FreeBSD でおこなっている人たちの, より小さなグルー プに届きます. このグループもまたとても忙しいことに注意して, 本当に必要な場合にコアチームの彼らにメールを送るだけにしてください. コーディングスタイルに関する情報は &man.intro.9; および &man.style.9; を参照してください. コードを提出する前には, 少なくともこの情報を意識しておいてくださるようお願いします. 新たなコードやメジャーな付加価値の高いパッケージ 重要な大きい仕事の寄贈や, 重要な新しい機能を FreeBSD に追加する場合には, 変更点を tar/uuencode したファイルにして送るか, それらを web や FTP サイトへアップロードしてアクセスできるようにすることのどちらかが通常必要になります. web や FTP サイトへのアクセスができないときは適切な FreeBSD のメーリングリストで誰かに変更を受け取って貰ってください. 大量のコードを伴った仕事の場合, コピーライトの神経過敏な問題が常に出てきます. FreeBSD に含めるコードのコピーライトとして受け入れることができるのは, 以下の二つです: BSD copyright BSD コピーライト. このコピーライトは権利に縛られない性格と商用企業にとって一般的な魅力をもつために最も好まれます. FreeBSD プロジェクトは商用利用を阻んだりせず, 何かを FreeBSD へ投資する気になった商業関係者による参加を積極的に奨励します. GPLGNU General Public License GNU General Public License GNU一般公有使用許諾, またはGPL. このライセンスはコードを商用目的に使用する場合に余分な努力が求められるため, 私たちにあまり評判が良いというわけではありません. しかし, 私たちは既に GPL 下の高品質なコード (コンパイラ, アセンブラ, テキストフォーマッタ等) の提供を受けており, 私たちは現在それを必要としています. そのため, このライセンスによる新たな貢献を拒絶するというのは愚かなことでしょう. GPL 下のコードはソースツリー の別の部分, 現在のところ /sys/gnu か /usr/src/gnu に入っています. そのため, GPL が問題となるような人は, 誰でも簡単にそれとわかるようになっています. これ以外のタイプのコピーライトによる寄贈は, FreeBSD へ含めることを考慮する前に, 注意深いレビューを受けなければなりません. 作者が独自のチャネルを通して配布しており, そのような変更をおこなうことを常に奨励している場合でも, 特に限定的な商用のコピーライトが適用される寄贈は一般に拒否されます. あなたの作品に BSD- スタイルのコピーライトを付けるには, 保護したいソースコードファイルすべての一番最初に以下のテキストを入れて, %% の間を適切な情報に置き換えください. Copyright (c) %%適切な年%% %%あなたの名前%%, %%あなたの州%% %%郵便番号%%. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer as the first lines of this file unmodified. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. THIS SOFTWARE IS PROVIDED BY %%あなたの名前%% ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL %%あなたの名前%% BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. $Id$ 便宜をはかるため, このテキストのコピーは次の場所に置いてあります. /usr/share/examples/etc/bsd-style-copyright. (訳注: 以下は神田敏広氏より寄贈された bsd-style-copyright の日本語訳です. ソースファイルに含めるものは原文の方であることに注意してご利用ください. また, 原文との間に趣旨の差異が生じた場合, 原文の内容が FreeBSD プロジェクトの意思であるものとします.) Copyright (C) [年] [あなたの名前] All rights reserved. ソースとバイナリ形式の再配布および使用は, 変更の有無にかかわらず以下の 条件を満たす場合に限り許可される: 1. ソースコードの再配布は, 上記の著作権表示・この条件のリスト・下記の 否認声明文を保持しなければならない. 2. バイナリ形式の再配布は, 上記の著作権表示・この条件のリスト・下記の 否認声明文を, 配布物と共に提供される文書および/または他の資料の中に 含めなければならない. (訳注:ここから「否認声明文」です) このソフトウェアは[あなたの名前]および貢献者によって ``あるがままの状態'' で提供され, 商品性と特定の目的に対する適合性についての暗黙の保証に留ま らず, いかなる明示および暗黙の保証を認めない. [あなたの名前]および貢献 者は, あらゆる直接的・間接的・偶発的・特殊的・典型的・必然的な損害 (代 替製品または代替サービスの獲得費; 効用・データ・利益の喪失; または業務 中断を含み, またそれだけに留まらない損害) に対して, たとえどのようにし て生じたとしても, そしてこのソフトウェアの使用によってどのようにであれ 生じる, 契約上であろうと, 厳密な責任内であろうと, あるいは不正行為 (過 失やそうでない場合を含む) における場合であろうとも, いかなる責任論上も, たとえそのような損害の可能性が予見されていたとしても, 一切の責任を持た ない. 翻訳: 神田敏広 御協力 (五十音順・敬称略): 池田研二, 内川 喜章, 藤村 英治, むらたしゅういちろう 杢野 雅一, 横田＠宇都宮 金銭, ハードウェアまたはインターネットアクセス FreeBSD プロジェクトの目的を進めるための寄付や, 私たちと同じような ボランティアの細く長い!努力を, 私たちは常に喜んで受け入れています. また一般的に私たちは自分達で周辺機器を買う資金が不足しているため, 周辺機器のサポートを充実させるのにハードウェアの寄付はとても重要です. 資金の寄付 FreeBSD財団は, FreeBSD プロジェクトの目標を推進するために確立された非営利的で税金を免除された財団です. 501(c)3 の実体として, 財団はコロラド州所得税ならびに, アメリカ連邦主義者所得税を一般に免除されています. 免税実体への寄付は, しばしば有税の連邦政府の所得から差し引くことができます. 寄付は以下に送ってください.
The FreeBSD Foundation 7321 Brockway Dr. Boulder, CO 80303 USA
財団はまだクレジットカード, およびPayPalといった他の形式の支払いを受け入れることができません. FreeBSD 財団に関するこれ以上の情報は The + url="http://people.FreeBSD.org/~jdp/foundation/announcement.html">The FreeBSD Foundation -- an Introduction を見てください. 財団への email での連絡は bod@FreeBSDFoundation.org へどうぞ. ハードウェアの寄贈 寄贈 FreeBSD プロジェクトは, 次の3つのカテゴリのどんなハードウェアの寄贈も, 喜んで受け付けます: ディスクドライブ, メモリまたは完全なシステムといった一般用途のハードウェアは, 資金の寄付の節にある FreeBSD, Inc. の住所まで送っ てください. 進行中の受け入れテストのためのハードウェアが必要とされています. 新たなリリース毎に適切な逆行テストができるように, 私たちは現在, FreeBSD がサポートするすべてのコンポーネントのテストラボを設置しよう としています. 私たちにはまだ, たくさんの重要な部品 (ネットワークカード, マザーボードなど) が不足していますので, このような寄贈をしたいと思っているならば, &a.dg; へコンタクトしてどの部品がまだ必要とされているかの情報を得てください. 現在 FreeBSD にサポートされていないハードウェアで, サポートに追加して欲しいもの. 私たちが新しいハードウェアを受けとる前にそのタスクを引き受けてくれる開発者を探す必要があるため, その部品を送る前に &a.core; にコンタクトを取ってください. インターネットアクセスの寄付 私たちは常に FTP, WWW や cvsup の新しいミラーサイトを募集しています. ミラーサイトになりたい場合には the FreeBSD project administrators hubs@FreeBSD.org にコンタクトを取って, 詳しい情報を手に入れてください. diff --git a/ja_JP.eucJP/books/handbook/bibliography/chapter.sgml b/ja_JP.eucJP/books/handbook/bibliography/chapter.sgml index 0a8957a372..b9b2e8fa2a 100644 --- a/ja_JP.eucJP/books/handbook/bibliography/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/bibliography/chapter.sgml @@ -1,667 +1,666 @@ 参考図書 訳: &a.jp.nakai;, 1996 年 10 月 12 日. FreeBSD オペレーティングシステムの個々の部分については マニュアルページで定義のような説明がなされていますが, それらにはどうやってその部分どうしをつなぎあわせて オペレーティングシステム全体を円滑に動作させるかを 説明していないという欠点がよく指摘されます. それを補うためには Unix システム管理についてのよい本や, すぐれた利用者向けのマニュアルが欠かせません. FreeBSD 専門の書籍および雑誌 非英語文化圏の 書籍 & 雑誌: - + FreeBSD 入門與應用 (中国語). FreeBSD入門キット 98版第二版. 宮嵜忠臣 著. 秀和システム. ISBN 4-87966-535-5 C3055 2900 円. FreeBSD入門キット AT互換機版 第二版. 宮嵜忠臣 著. 秀和システム. ISBN 4-87966-535-5 C3055 2900 円. ここまでできる FreeBSD パワーガイド. 霜山 滋, 仲道 嘉夫, 山中 右次 著. 秀和システム. ISBN 4-87966-637-8 2600円. FreeBSD徹底入門. あさだ たくや / 天川 修平 / 衛藤 敏寿 / 浜田 直樹 / 細川 達己 / 三田 吉郎 著. 翔泳社. ISBN 4-88135-473-6 3600 円. パーソナル UNIX スターターキット FreeBSD. 民田 雅人 / 古場 正行 / 増田 佳泰 / 天池 健 / 宮川 晋 共著. アスキー. ISBN 4-7561-1733-3 3000 円. FreeBSD ハンドブック (日本語版). アスキー. ISBN 4-7561-1580-2 3800 円. FreeBSD mit Methode (ドイツ語版). Computer und Literatur Verlag/Vertrieb Hanser 発行. 1998. ISBN 3-932311-31-0 FreeBSD インストール & 活用マニュアル, 毎日コミュニケーションズ発行. Onno W Purbo, Dodi Maryanto, Syahrial Hubbany, Widjil Widodo 著 FreeBSD を使ったインターネットサーバの構築 (Building Internet Server with FreeBSD) (インドネシア語), Elex Media Komputindo 発行. 英語の書籍 & 雑誌: The Complete FreeBSD, BSDi 発行. - The + The FreeBSD Corporate Networker's Guide, Addison-Wesley 発行. 利用者向けのガイド Computer Systems Research Group, UC Berkeley. 4.4BSD User's Reference Manual. O'Reilly & Associates, Inc., 1994. ISBN 1-56592-075-9 Computer Systems Research Group, UC Berkeley. 4.4BSD User's Supplementary Documents. O'Reilly & Associates, Inc., 1994. ISBN 1-56592-076-7 UNIX in a Nutshell. O'Reilly & Associates, Inc., 1990. ISBN 093717520X Mui, Linda. What You Need To Know When You Can't Find Your UNIX System Administrator. O'Reilly & Associates, Inc., 1995. ISBN 1-56592-104-6 オハイオ州立大学による UNIX Introductory Course. オンラインで HTML 版と PostScript 版が利用可能. FreeBSD 友の会 jpman プロジェクト. FreeBSD User's Reference Manual (日本語訳). 毎日コミュニケーションズ , 1998. ISBN4-8399-0088-4 P3800E. Edinburgh University による UNIX 環境の初心者向け オンラインガイド. 管理者向けのガイド Albitz, Paul and Liu, Cricket. DNS and - BIND, 3rd Ed. - O'Reilly & Associates, Inc., 1998. - ISBN ISBN 1-56592-512-2 + BIND, 4th Ed. + O'Reilly & Associates, Inc., 2001. + ISBN ISBN 1-59600-158-4 (訳注: 邦訳は以下のものが出版されています. 高田 広章 / 小島 育夫 監訳 , 小舘 光正 訳. DNS & BIND 第 3 版. オライリー・ジャパン, 1999. ISBN 4-900900-91-5) Computer Systems Research Group, UC Berkeley. 4.4BSD System Manager's Manual. O'Reilly & Associates, Inc., 1994. ISBN 1-56592-080-5 Costales, Brian, et al. Sendmail, 2nd Ed. O'Reilly & Associates, Inc., 1997. ISBN 1-56592-222-0 (訳注: 邦訳は以下の 2 分冊のものが出版されています. 原著の 3 章までが「システム管理」, 4 章が「リファレンス」 に対応します. 中村 素典 監訳, 鈴木 克彦 訳. sendmail システム管理 (Volume1). オライリー・ジャパン, 1997. ISBN 4-900900-40-0 中村 素典 監訳, 鈴木 克彦 訳. sendmail システム管理 (Volume2). オライリー・ジャパン, 1998. ISBN 4-900900-41-9) Frisch, Æleen. Essential System Administration, 2nd Ed. O'Reilly & Associates, Inc., 1995. ISBN 1-56592-127-5 (訳注: 邦訳は以下のものが出版されています. 谷川 哲司 監訳, 黒岩 真吾 / 株式会社ユニテック 訳. UNIX システム管理入門 改訂版. オライリー・ジャパン, 1998. ISBN 4-900900-14-1) Hunt, Craig. TCP/IP Network Administration, 2nd Ed. O'Reilly & Associates, Inc., 1997. ISBN 1-56592-322-7 (訳注: 邦訳は以下のものが出版されています. 村井 純 監訳. TCP/IP ネットワーク管理 第 2 版. オライリー・ジャパン, 1998. ISBN 4-900900-68-0) Nemeth, Evi. UNIX System Administration Handbook. 3rd Ed. Prentice Hall, 2000. ISBN 0-13-020601-6 (訳注: 邦訳は以下のものが出版されています. 井上 尚司 監訳. UNIX システム管理入門. ソフトバンク, 1992. ISBN 4-89052-362-6 原本は第 3 版だが, 訳出は第 1 版のみ) Stern, Hal Managing NFS and NIS O'Reilly & Associates, Inc., 1991. ISBN 0-937175-75-7 (訳注: 邦訳は以下のものが出版されています. 砂原 秀樹 監訳, 倉骨 彰 訳, NFS & NIS. アスキー, 1992. ISBN 4-7561-0273-5) FreeBSD 友の会 jpman プロジェクト. FreeBSD System Administrator's Manual (日本語訳). 毎日コミュニケーションズ, 1998. ISBN4-8399-0109-0 P3300E. プログラマ向けのガイド - Asente, Paul. X Window System - Toolkit. Digital Press. - ISBN 1-55558-051-3 + Asente, Paul, Converse, Diana, and Swick, Ralph. + X Window System Toolkit. Digital Press, + 1998. ISBN 1-55558-178-1 Computer Systems Research Group, UC Berkeley. 4.4BSD Programmer's Reference Manual. O'Reilly & Associates, Inc., 1994. ISBN 1-56592-078-3 Computer Systems Research Group, UC Berkeley. 4.4BSD Programmer's Supplementary Documents. O'Reilly & Associates, Inc., 1994. ISBN 1-56592-079-1 Harbison, Samuel P. and Steele, Guy L. Jr. C: A Reference Manual. 4rd ed. Prentice Hall, 1995. ISBN 0-13-326224-3 (訳注: 邦訳は以下のものが出版されています. 斎藤 信男監訳. 新・詳説C言語リファレンス [H&Sリファレンス]. ソフトバンク, 1994. ISBN 4-89052-506-8 原本は第4版だが, 訳出は第3版のみ.) Kernighan, Brian and Dennis M. Ritchie. The C Programming Language.. PTR Prentice Hall, 1988. ISBN 0-13-110362-9 (訳注: 邦訳は以下のものが出版されています. 石田 晴久 訳. プログラミング言語 C 第2版(訳書訂正版) 共立出版, 1989. ISBN 4-320-02692-6) Lehey, Greg. Porting UNIX Software. O'Reilly & Associates, Inc., 1995. ISBN 1-56592-126-7 Plauger, P. J. The Standard C Library. Prentice Hall, 1992. ISBN 0-13-131509-9 (訳注: 邦訳は以下のものが出版されています. 福富 寛 / 門倉 明彦 / 清水 恵介 訳. 標準 C ライブラリ ANSI/ISO/JIS C規格. トッパン, 1995. ISBN 4-8101-8541-9) Stevens, W. Richard. Advanced Programming in the UNIX Environment. Reading, Mass. : Addison-Wesley, 1992 ISBN 0-201-56317-7 (訳注: 邦訳は以下のものが出版されています. 大木 敦雄 訳. 詳解 UNIX プログラミング. トッパン, 1994. ISBN 4-89052-524-6) Stevens, W. Richard. UNIX Network Programming. 2nd Ed. PTR Prentice Hall, 1998. ISBN 0-13-949876-1 (訳注: 第 1 版の邦訳は以下のものが出版されています. 篠田 陽一 訳. UNIX ネットワークプログラミング. トッパン, 1992. ISBN 4-8101-8509-5) 第 2 版の邦訳は以下のものが出版されています. 篠田 陽一 訳. UNIX ネットワークプログラミング 第 2 版 Vol.1. トッパン, 1999. ISBN 4-8101-8612-1) Wells, Bill. Writing Serial Drivers for UNIX. Dr. Dobb's Journal. 19(15), December 1994. pp68-71, 97-99. オペレーティングシステム内部 Andleigh, Prabhat K. UNIX System Architecture. Prentice-Hall, Inc., 1990. ISBN 0-13-949843-5 Jolitz, William. Porting UNIX to the 386. Dr. Dobb's Journal. January 1991-July 1992. Leffler, Samuel J., Marshall Kirk McKusick, Michael J Karels and John Quarterman The Design and Implementation of the 4.3BSD UNIX Operating System. Reading, Mass. : Addison-Wesley, 1989. ISBN 0-201-06196-1 (訳注: 邦訳は以下のものが出版されています. 中村 明 / 相田 仁 / 計 宇生 / 小池 汎平 訳. UNIX 4.3BSDの設計と実装. 丸善, 1991. ISBN 4-621-03607-6) Leffler, Samuel J., Marshall Kirk McKusick, The Design and Implementation of the 4.3BSD UNIX Operating System: Answer Book. Reading, Mass. : Addison-Wesley, 1991. ISBN 0-201-54629-9 (訳注: 邦訳は以下のものが出版されています. 相田 仁 / 計 宇生 / 小池 汎平 訳. UNIX 4.3BSDの設計と実装. アンサーブック, トッパン, 1991. ISBN 4-8101-8039-5) McKusick, Marshall Kirk, Keith Bostic, Michael J Karels, and John Quarterman. The Design and Implementation of the 4.4BSD Operating System. Reading, Mass. : Addison-Wesley, 1996. ISBN 0-201-54979-4 Stevens, W. Richard. TCP/IP Illustrated, Volume 1: The Protocols. Reading, Mass. : Addison-Wesley, 1996. ISBN 0-201-63346-9 Schimmel, Curt. Unix Systems for Modern Architectures. Reading, Mass. : Addison-Wesley, 1994. ISBN 0-201-63338-8 Stevens, W. Richard. TCP/IP Illustrated, Volume 3: TCP for Transactions, HTTP, NNTP and the UNIX Domain Protocols. Reading, Mass. : Addison-Wesley, 1996. ISBN 0-201-63495-3 (訳注: 邦訳は以下のものが出版されています. 中本 幸一 / 石川 裕次 / 田中 伸佳 訳. 詳解 TCP/IP Vol.3: トランザクション TCP, HTTP, NNTP, UNIX ドメインプロトコル, アジソンウェスレイパブリッシャーズジャパン, 1998. ISBN 4-8101-8039-5) Vahalia, Uresh. UNIX Internals -- The New Frontiers. Prentice Hall, 1996. ISBN 0-13-101908-2 Wright, Gary R. and W. Richard Stevens. TCP/IP Illustrated, Volume 2: The Implementation. Reading, Mass. : Addison-Wesley, 1995. ISBN 0-201-63354-X セキュリティの参考資料 Cheswick, William R. and Steven M. Bellovin. Firewalls and Internet Security: Repelling the Wily Hacker. Reading, Mass. : Addison-Wesley, 1995. ISBN 0-201-63357-4 (訳注: 邦訳は以下のものが出版されています. 川副 博 監訳. ファイアウォール. ソフトバンク, 1995. ISBN 4-89052-672-2) Garfinkel, Simson and Gene Spafford. - Practical UNIX Security. 2nd Ed. - O'Reilly & Associates, Inc., 1996. - ISBN 1-56592-148-8 + Practical UNIX & Internet Security. + 2nd Ed. O'Reilly & Associates, Inc., 1996. ISBN + 1-56592-148-8 (訳注: 邦訳は以下のものが出版されています. 山口 英 監訳. UNIX セキュリティ. アスキー, 1993. ISBN 4-7561-0274-3 原本は第 2 版だが, 訳出は第 1 版のみ) Garfinkel, Simson. PGP Pretty Good Privacy O'Reilly & Associates, Inc., 1995. ISBN 1-56592-098-8 ハードウェアの参考資料 Anderson, Don and Tom Shanley. Pentium Processor System Architecture. 2nd Ed. Reading, Mass. : Addison-Wesley, 1995. ISBN 0-201-40992-5 Ferraro, Richard F. Programmer's Guide to the EGA, VGA, and Super VGA Cards. 3rd ed. Reading, Mass. : Addison-Wesley, 1995. ISBN 0-201-62490-7 Intel Corporation は, 自社の CPU やチップセットに関する文書を自社の 開発者向け Web サイト で公開しています. 文書のフォーマットは通常 PDF です. Shanley, Tom. 80486 System Architecture. 3rd ed. Reading, Mass. : Addison-Wesley, 1995. ISBN 0-201-40994-1 Shanley, Tom. ISA System Architecture. 3rd ed. Reading, Mass. : Addison-Wesley, 1995. ISBN 0-201-40996-8 - Shanley, Tom. PCI System - Architecture. 3rd ed. Reading, Mass. : - Addison-Wesley, 1995. - ISBN 0-201-40993-3 + Shanley, Tom. PCI System Architecture. + 4th ed. Reading, Mass. : Addison-Wesley, 1999. ISBN + 0-201-30974-2 - Van Gilluwe, Frank. The Undocumented PC. - Reading, Mass: Addison-Wesley Pub. Co., 1994. - ISBN 0-201-62277-7 + Van Gilluwe, Frank. The Undocumented PC, 2nd Ed. + Reading, Mass: Addison-Wesley Pub. Co., 1996. ISBN + 0-201-47950-8 Unix の歴史 Lion, John Lion's Commentary on UNIX, 6th Ed. With Source Code. ITP Media Group, 1996. ISBN 1573980137 Raymond, Eric s. The New Hacker's Dictionary, 3rd edition. MIT Press, 1996. ISBN 0-262-68092-0 Also known as the Jargon File Saulus, Peter H. A quarter century of UNIX. Addison-Wesley Publishing Company, Inc., 1994. ISBN 0-201-54777-5 Simon Garfinkel, Daniel Weise, Steven Strassmann. The UNIX-HATERS Handbook. IDG Books Worldwide, Inc., 1994. ISBN 1-56884-203-1 Don Libes, Sandy Ressler Life with UNIX — special edition. Prentice-Hall, Inc., 1989. ISBN 0-13-536657-7 (訳注: 邦訳は以下のものが出版されています. 坂本 文 監訳. Life with UNIX. アスキー, 1990. ISBN 4-7561-0783-4 邦訳が Special 版の訳出か否かは不明) BSD 系 OS の系譜図. 1997年. ftp://ftp.FreeBSD.org/pub/FreeBSD/FreeBSD-current/src/share/misc/bsd-family-tree または, FreeBSD-current マシンの ローカルファイル. BSD リリース告知コレクション. 1997. http://www.de.FreeBSD.ORG/de/ftp/releases/ Networked Computer Science Technical Reports Library . http://www.ncstrl.org/ Computer Systems Research group (CSRG) からの古い BSD リリース集 http://www.mckusick.com/csrg/: この 4 枚 CD セットには, 1BSD から 4.4BSD までと 4.4BSD-Lite2 が含まれます (残念ながら 2.11BSD は含まれていません). また 4 枚目の CD には, 最終ソースおよび SCCS ファイルが含まれています. 雑誌とジャーナル The C/C++ Users Journal. R&D Publications Inc. ISSN 1075-2838 Sys Admin — The Journal for UNIX System Administrators Miller Freeman, Inc., ISSN 1061-2688 diff --git a/ja_JP.eucJP/books/handbook/contrib/chapter.sgml b/ja_JP.eucJP/books/handbook/contrib/chapter.sgml index a999cb1fe8..44af8a02fe 100644 --- a/ja_JP.eucJP/books/handbook/contrib/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/contrib/chapter.sgml @@ -1,699 +1,698 @@ Jordan Hubbard 寄稿: FreeBSD への貢献 貢献 あなたも何か FreeBSD のために貢献したくなりましたか? 素晴らしい! 私たちは常に支援を受ける用意がありますし, FreeBSD は生き残るためにユーザベースの貢献に頼るようなシステムの一つです. あなたの貢献は感謝されるだけではなく, FreeBSD が成長し続けるために極めて重要なものな のです! 一部の人達が言っているのとは逆に, 貢献を受け付けてもらうために腕利 きのプログラマーになるとか FreeBSD コアチームの人と親友になる必要はありません. FreeBSD プロジェクトの開発は, 多くのそして益々増加する世界中の貢献者達によってなされており, 彼らの年齢, 専門技術分野は多岐に渡ります. そして手の空いている人よりも成されるべき仕事の方が常に多いのです. FreeBSD プロジェクトがカーネルや散在しているユーティリティよりも, オペレーティングシステム環境 (と, そのインストール) に対して責任を持つ ようになったため, 私たちの TODO リストはドキュメンテーション, ベータテスト, 高度に専門化されたタイプのカーネル開発の好例を紹介するなど非常に広い範囲のタスクに渡ります. あなたの技能レベルに関わらず, プロジェクトを支援できることが必ず何かあります! FreeBSD 関連の事業に従事している商業団体が私たちにコンタクトすることも歓迎します. あなたの製品を (FreeBSD 上で) 動作させるには, 特別な拡張が必要ではありませんか? あまりにも風変わりな要求でなければ, それを受け入れる用意が私たちにあるとわかるはずです. 付加価値のある製品ですか? 私たちに知らせてください! 多分私たちは, ある面において共同して作業をすることができるでしょう. フリーソフトウェア界は, ソフトウェアがそのライフサイクルを通してどのように開発され, 売られ, 保守されていくかについて, 既存の仮説に挑戦しています. 少なくとももう一度考慮してみることを私たちは強くお奨めします. 何が必要? 次のタスクとサブプロジェクトのリストは, コアチームの色々な TODO リストと最近2ヶ月で集めたユーザリクエストを合わせたものです. 可能なところでは, 緊急度によってタスクがランクづけされています. もしここにあるタスクの実行に興味があるのでしたら, コーディネータの名前をクリックしてメールを送ってください. もしコーディネータが決まっていなければ, あなたがボランティアしてみませんか? 進行中のタスク 次のタスクはやっておくべきではありますが, 特にさし迫っているわけではありません: 完全な KLD ベースのドライバのサポート / コンフィグレーションマネージャ. 穏やかな方法でハードウェアを検知するコンフィグレーションマネージャの作成 (第3ステージ・ブートの中に?). ハードウェアが必要とする KLD だけを残す等. PCMCIA/PCCARD. コーディネータ: &a.msmith; と &a.imp; ドキュメンテーション! pcic ドライバの信頼性のある操作 (テスト要). sio.c のリコグナイザとハンドラ (ほぼ完了). ed.c のリコグナイザとハンドラ (ほぼ完了). ep.c のリコグナイザとハンドラ (ほぼ完了). User-mode のリコグナイザとハンドラ (部分的に完了). 先進的なパワーマネージメント. コーディネータ: &a.nate; と &a.phk; APM サブドライバ (ほぼ完了). IDE/ATA ディスクサブドライバ (部分的に完了). syscons/pcvt サブドライバ. PCMCIA/PCCARD ドライバ群との統合 (サスペンド / レジューム). 優先度の低いタスク 次のタスクは全くのあら隠し, または誰もすぐにおこないそうもない投資のような仕事を表します: 最初の N 項目は Terry Lambert terry@lambert.org からのものです. ネットワークカードと一緒に提供される ODI カードドライバを使用できるようにする, NetWare サーバ (プロテクトモードの ODI ドライバ) ローダとサブサービス. NDIS ドライバと NetWare の SCSI ドライバについても同様. 前のリビジョンの FreeBSD マシンではなく, Linux マシンで動作する 「アップグレードシステム」オプション. カーネルのマルチスレッド化 (カーネルのプリエンプションが必要). カーネルのプリエンプション付き対称マルチプロセッシング (カーネルのプリエンプションが必要). ポータブルコンピュータのサポートにおける協調の試み. これは PCMCIA ブリッジング規則と電源管理イベント処理の変更により, いくらかは処理できます. しかし, 内蔵ディスプレイと外部ディスプレイの検出, この 2 種類のディスプレイがあるという事実に基づく異なる解像度の選択, マシンがドックにある場合にはディスクのモータ停止を防止すること, マシンのブート能力に影響を与えずにドックベースのカードの消滅を可能にすること (PCMCIA と同じ問題) などの問題があります. もっと簡単なタスク 上のセクションで挙げたタスクは膨大な時間の投資または FreeBSD のカーネルに関する深い知識を必要とします (もしくはそのどちらも). しかしながら, "週末ハッカー"やプログラミングのスキルを持たない人々に適した立派なタスクも数多くあります. FreeBSD-current を運用しており, 状態の良いインターネット接続があるならば, current.FreeBSD.org という一日に一回フルリリースを行っているマシンがあります — 時おり最新のリリースをそこからインストールし, その過程で何か問題があるなら報告して下さい. freebsd-bugs メーリングリストを読んでください. そこではあなたが建設的なコメントを付けたりテストできるパッチが提供されているような問題がある かもしれません. もしくはそれらの問題の一つをあなた自身で修正することさえできるかもしれません. 定期的に FAQ とハンドブックを通して読んでみてください. もしまずい説明や古い事柄や完全に間違っていることなどがあれば我々に知らせて下さい. さらに良いのは我々に修正案を送ることです (SGML は学ぶのにそれほど難しくありませんが, プレインテキストでも問題はありません). (もしまだないならば) FreeBSD のドキュメントを自分の母国語に翻訳するのを手伝ってください — 作業している人がいるかどうか &a.doc; にメールを送って聞くだけです. とはいっても, そうすることによってあなたが全ての FreeBSD ドキュメントの翻訳に携わるようになるというわけではないですからね — 実際, もっとも翻訳が必要とされているドキュメントはインストール方法です. たまに(もしくは定期的に) freebsd-questions メーリングリストや comp.unix.bsd.freebsd.misc を読んでください. これは, あなたの持っている専門知識を共有したり誰かが抱えている問題を解決するのに非常に有効なものになり得ることです. 時にはあなた自身で新しいことを学ぶことさえできるかもしれません. これらのフォーラムはやるべきことのアイディアの源にもなり得るのです. -current に正しく当てられるがしばらく経っても(通常は 2, 3 週間) -stable に取り込まれてないようなバグフィックスがあるならばコミッターに丁寧に思い出させてください. 寄贈ソフトウェアをソースツリーの src/contrib に移動させてください. src/contrib 以下のコードが最新のものであるか確認してください. 警告を詳細に報告するようにして ソースツリー全体(もしくはその一部)を構築してみてください. そして警告が出ないようにしてください. ports で, gets() を使っているとか malloc.h をインクルードしているなどといった警告が出ないようにしてください. もしなんらかの ports に関わっているなら, あなたのパッチを作者にフィードバックしてください (次のバージョンが出た時にあなたが楽になります). このリストに追加するタスクを提案して下さい! 障害報告 (PR; Problem Report) データベースにおける作業 障害報告 (PR) データベース FreeBSD 障害報告リストでは, 現在問題となっている報告と, FreeBSD の利用者によって提出された改良の要望に関する全てのリストを公開しています. open 状態の障害情報を見て, 興味を引く内容かどうか確かめて下さい. 本当に複雑なものも含まれているでしょうし, 例えば, 障害報告に対する修正がちゃんとしたものであるかどうか単にチェックするだけのとても簡単な作業もあるでしょう. まず, まだ誰にも割り当てられていない障害報告から作業を始めて下さい. もし, 誰か他の人に割り当てが決まっているけれども自分が作業可能だ, というものがあれば, 作業ができるかどうか — 既にテスト用パッチが用意されているのかどうか, あるいは その問題についてあなたが考えている, より進んだ考えに関して議論ができるかどうか, 割り当てられている人に電子メールで問い合わせて下さい. 貢献の仕方 一般的に, システムへの貢献は次の 6 つのカテゴリの1つ以上に分類されます: バグ報告と一般的な論評 報告するべきバグがあったり, 提案したいことがあれば: 一般的な 技術的関心事に関するアイデアや提案は &a.hackers; へメールしてください. 同様に, このような事柄に興味のある (そして膨大なメール! に耐えられる) 人は, &a.majordomo; へメールを送って hackers メーリングリストに参加すると良いでしょう. 情報については メーリングリスト を参照してください. バグを発見したり変更を送付しようとしている場合は &man.send-pr.1; プログラムか WEB ベースの + url="../../../../ja/send-pr.html">ウェブベースの send-pr を使用して報告してください. バグレポートの各項目を埋めるようにしてください. 65KB を超えるのでなければ, レポート中に直接パッチを入れてくださって結構です. パッチがソースツリーにすぐ適用できるものならば, 報告の概要に [PATCH] と書いておいてください. その場合, カット＆ペーストはしないでください. カット＆ペーストではタブがスペースに展開されてパッチが使い物にならなくなってしまいます. 20KB を超える場合は, それらを compress して &man.uuencode.1; することも検討してください. とても大きくなる場合は - ftp.FreeBSD.org:/pub/FreeBSD/incoming/ + url="ftp://ftp.FreeBSD.org/pub/FreeBSD/incoming/">ftp://ftp.FreeBSD.org/pub/FreeBSD/incoming/ を利用してください. レポートがファイリングされれば, バグ報告の確認とトラッキング番号をメールで受け取るはずです. このトラッキング番号を覚えておき, 問題に関する詳細情報を bug-followup@FreeBSD.org に メールで送って更新できるようにしてください. 例えば "Re: kern/3377" のように, この番号をサブジェクト行に使用してください. すべてのバグレポートの追加情報は, この方法で送付されなければいけません. もしタイムリに (あなたの電子メール接続形態にもよりますが, 3日から 1週間) 確認を受けとれないとか, 何らかの理由で &man.send-pr.1; コマンドが使用できない場合には, &a.bugs; へメールを送り, 誰か代りにバグ報告を送付してもらうようたずねてください. 文書の変更 文書に関する提案 文書の変更は &a.doc; が監督しています. バグ報告と一般的な論評 に記述されているように send-pr コマンドを使用して, 提案や変更 (どんな些細なものでも歓迎します!) を送ってください. 現存のソースコードの変更 FreeBSD-current 現存のソースコードへの追加または変更は, いくらかトリッキーな仕事で あり, core の FreeBSD 開発の現状にあなたがどれだけ通じているかに大きく依存します. FreeBSD-currentとして知られる FreeBSD の特別な継続的リリースがあります. FreeBSD-current は開発者の積極的な活動の便宜のために, 色々な方法で利用可能になっています. FreeBSD-current の入手と使用方法についての詳しい情報については最新の FreeBSD を追いかける を参照してください. 不幸にして古いソースをもとに仕事をすることは, 時々あなたの変更が時 代遅れ, または FreeBSD への簡単な再統合に合わなくなっていることを意味します. システムの現状に関する議論がおこなわれている &a.announce; と &a.current; へ参加することで, この可能性を最小限にすることができます. 完全な最新のソースを変更のベースにできることが確実になったと仮定して, 次のステップは FreeBSD の保守担当者へ送る差分ファイルの生成です. これは &man.diff.1; コマンドを使用しておこないますが, context diff形式が好まれるようです. 例えば: diff &prompt.user; diff -c oldfile newfile または &prompt.user; diff -c -r olddir newdir これで指定されたソースファイルまたはディレクトリ階層に対するコンテキスト形式の差分が生成されます. 詳しい説明は &man.diff.1; のマ ニュアルページを参照してください. 差分ファイル (&man.patch.1; コマンドでテストできます) を作ったら, それらを FreeBSD に含めてもらうようメールで送ってください. バグ報告と一般的な論評 に記述されているように &man.send-pr.1; コマンドを使用してください. 差分ファイルだけを &a.hackers; へ送ってはいけません. 途方にくれてしまいます! 私たちは多忙なので, あなたの提案に大変感謝します (これはボランティアのプロジェクトです!). すぐに取りかかることはできませんが, 処理されるまではちゃんと PR データベースに残っています. 報告の概要に [PATCH] と書いてあなたの提案を表明してください. uuencode あなたがそうした方がいいと思う場合 (例えば, ファイルの追加, 削除または名称変更など), 変更を tar ファイルにまとめ, &man.uuencode.1; プログラムにかけてください. shar アーカイブも歓迎します. 例えばあなたがそれ自身のさらなる配布を管理するコピーライト問題を良く分かっていないとか, 単に厳しいレビューをおこなっておらず, リリースする準備ができていないなど, あなたの変更が潜在的に不安定な性質をも つものである場合, &man.send-pr.1; で送付するよりむしろ &a.core; へ直接送ってください. コアチームメーリングリスト宛のメールは, 日々の仕事のほとんどを FreeBSD でおこなっている人たちの, より小さなグルー プに届きます. このグループもまたとても忙しいことに注意して, 本当に必要な場合にコアチームの彼らにメールを送るだけにしてください. コーディングスタイルに関する情報は &man.intro.9; および &man.style.9; を参照してください. コードを提出する前には, 少なくともこの情報を意識しておいてくださるようお願いします. 新たなコードやメジャーな付加価値の高いパッケージ 重要な大きい仕事の寄贈や, 重要な新しい機能を FreeBSD に追加する場合には, 変更点を tar/uuencode したファイルにして送るか, それらを web や FTP サイトへアップロードしてアクセスできるようにすることのどちらかが通常必要になります. web や FTP サイトへのアクセスができないときは適切な FreeBSD のメーリングリストで誰かに変更を受け取って貰ってください. 大量のコードを伴った仕事の場合, コピーライトの神経過敏な問題が常に出てきます. FreeBSD に含めるコードのコピーライトとして受け入れることができるのは, 以下の二つです: BSD copyright BSD コピーライト. このコピーライトは権利に縛られない性格と商用企業にとって一般的な魅力をもつために最も好まれます. FreeBSD プロジェクトは商用利用を阻んだりせず, 何かを FreeBSD へ投資する気になった商業関係者による参加を積極的に奨励します. GPLGNU General Public License GNU General Public License GNU一般公有使用許諾, またはGPL. このライセンスはコードを商用目的に使用する場合に余分な努力が求められるため, 私たちにあまり評判が良いというわけではありません. しかし, 私たちは既に GPL 下の高品質なコード (コンパイラ, アセンブラ, テキストフォーマッタ等) の提供を受けており, 私たちは現在それを必要としています. そのため, このライセンスによる新たな貢献を拒絶するというのは愚かなことでしょう. GPL 下のコードはソースツリー の別の部分, 現在のところ /sys/gnu か /usr/src/gnu に入っています. そのため, GPL が問題となるような人は, 誰でも簡単にそれとわかるようになっています. これ以外のタイプのコピーライトによる寄贈は, FreeBSD へ含めることを考慮する前に, 注意深いレビューを受けなければなりません. 作者が独自のチャネルを通して配布しており, そのような変更をおこなうことを常に奨励している場合でも, 特に限定的な商用のコピーライトが適用される寄贈は一般に拒否されます. あなたの作品に BSD- スタイルのコピーライトを付けるには, 保護したいソースコードファイルすべての一番最初に以下のテキストを入れて, %% の間を適切な情報に置き換えください. Copyright (c) %%適切な年%% %%あなたの名前%%, %%あなたの州%% %%郵便番号%%. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer as the first lines of this file unmodified. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. THIS SOFTWARE IS PROVIDED BY %%あなたの名前%% ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL %%あなたの名前%% BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. $Id$ 便宜をはかるため, このテキストのコピーは次の場所に置いてあります. /usr/share/examples/etc/bsd-style-copyright. (訳注: 以下は神田敏広氏より寄贈された bsd-style-copyright の日本語訳です. ソースファイルに含めるものは原文の方であることに注意してご利用ください. また, 原文との間に趣旨の差異が生じた場合, 原文の内容が FreeBSD プロジェクトの意思であるものとします.) Copyright (C) [年] [あなたの名前] All rights reserved. ソースとバイナリ形式の再配布および使用は, 変更の有無にかかわらず以下の 条件を満たす場合に限り許可される: 1. ソースコードの再配布は, 上記の著作権表示・この条件のリスト・下記の 否認声明文を保持しなければならない. 2. バイナリ形式の再配布は, 上記の著作権表示・この条件のリスト・下記の 否認声明文を, 配布物と共に提供される文書および/または他の資料の中に 含めなければならない. (訳注:ここから「否認声明文」です) このソフトウェアは[あなたの名前]および貢献者によって ``あるがままの状態'' で提供され, 商品性と特定の目的に対する適合性についての暗黙の保証に留ま らず, いかなる明示および暗黙の保証を認めない. [あなたの名前]および貢献 者は, あらゆる直接的・間接的・偶発的・特殊的・典型的・必然的な損害 (代 替製品または代替サービスの獲得費; 効用・データ・利益の喪失; または業務 中断を含み, またそれだけに留まらない損害) に対して, たとえどのようにし て生じたとしても, そしてこのソフトウェアの使用によってどのようにであれ 生じる, 契約上であろうと, 厳密な責任内であろうと, あるいは不正行為 (過 失やそうでない場合を含む) における場合であろうとも, いかなる責任論上も, たとえそのような損害の可能性が予見されていたとしても, 一切の責任を持た ない. 翻訳: 神田敏広 御協力 (五十音順・敬称略): 池田研二, 内川 喜章, 藤村 英治, むらたしゅういちろう 杢野 雅一, 横田＠宇都宮 金銭, ハードウェアまたはインターネットアクセス FreeBSD プロジェクトの目的を進めるための寄付や, 私たちと同じような ボランティアの細く長い!努力を, 私たちは常に喜んで受け入れています. また一般的に私たちは自分達で周辺機器を買う資金が不足しているため, 周辺機器のサポートを充実させるのにハードウェアの寄付はとても重要です. 資金の寄付 FreeBSD財団は, FreeBSD プロジェクトの目標を推進するために確立された非営利的で税金を免除された財団です. 501(c)3 の実体として, 財団はコロラド州所得税ならびに, アメリカ連邦主義者所得税を一般に免除されています. 免税実体への寄付は, しばしば有税の連邦政府の所得から差し引くことができます. 寄付は以下に送ってください.
The FreeBSD Foundation 7321 Brockway Dr. Boulder, CO 80303 USA
財団はまだクレジットカード, およびPayPalといった他の形式の支払いを受け入れることができません. FreeBSD 財団に関するこれ以上の情報は The + url="http://people.FreeBSD.org/~jdp/foundation/announcement.html">The FreeBSD Foundation -- an Introduction を見てください. 財団への email での連絡は bod@FreeBSDFoundation.org へどうぞ. ハードウェアの寄贈 寄贈 FreeBSD プロジェクトは, 次の3つのカテゴリのどんなハードウェアの寄贈も, 喜んで受け付けます: ディスクドライブ, メモリまたは完全なシステムといった一般用途のハードウェアは, 資金の寄付の節にある FreeBSD, Inc. の住所まで送っ てください. 進行中の受け入れテストのためのハードウェアが必要とされています. 新たなリリース毎に適切な逆行テストができるように, 私たちは現在, FreeBSD がサポートするすべてのコンポーネントのテストラボを設置しよう としています. 私たちにはまだ, たくさんの重要な部品 (ネットワークカード, マザーボードなど) が不足していますので, このような寄贈をしたいと思っているならば, &a.dg; へコンタクトしてどの部品がまだ必要とされているかの情報を得てください. 現在 FreeBSD にサポートされていないハードウェアで, サポートに追加して欲しいもの. 私たちが新しいハードウェアを受けとる前にそのタスクを引き受けてくれる開発者を探す必要があるため, その部品を送る前に &a.core; にコンタクトを取ってください. インターネットアクセスの寄付 私たちは常に FTP, WWW や cvsup の新しいミラーサイトを募集しています. ミラーサイトになりたい場合には the FreeBSD project administrators hubs@FreeBSD.org にコンタクトを取って, 詳しい情報を手に入れてください. diff --git a/ja_JP.eucJP/books/handbook/cutting-edge/chapter.sgml b/ja_JP.eucJP/books/handbook/cutting-edge/chapter.sgml index ec53e09bb6..54ac85f1f8 100644 --- a/ja_JP.eucJP/books/handbook/cutting-edge/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/cutting-edge/chapter.sgml @@ -1,1789 +1,1789 @@ 開発の最前線 改訂: &a.jim;, 2000 年 3 月. 原作: &a.jkh;, &a.phk;, &a.jdp;, &a.nik;, およびたくさんのフィードバック. この章では あるリリースから次のリリースまでの期間にも, &os; の開発は休みなく続けられています. この開発の最前線に興味を持っている人のために, 手元のシステムを最新の開発ツリーに同期させておくための, とても使いやすい仕掛けが何種類も用意されています. 注意: 開発の最前線は, 誰もが扱えるという性質のものではありません! もしもあなたが, 開発途中のシステムを追いかけようか, それともリリースバージョンのどれかを使い続けようかと迷っているのなら, きっとこの章が参考になるでしょう. &os.current; vs. &os.stable; -CURRENT -STABLE FreeBSD には二つの開発ブランチがあります. それは &os.current; と &os.stable; です. この章ではそれぞれについて簡単に説明し, どのようにしてあなたのシステムを対応するツリーに対して, どうやって常に最新の状態に保つかについて扱います. まずは &os.current;, 次に &os.stable; について説明します. 訳: &a.hanai;, 1996 年 11 月 6 日. 最新の &os; を追いかける これを読む前に, 心にとめておいて欲しいことがあります. &os.current; とは &os; の開発の最前線だということです. もし &os; を使い始めたばかりなら, これを運用することについて十分検討を重ねた方が良いでしょう. &os.current; ってなに? &os.current; とは文字通り, 日々変更されている &os; のソースのスナップショット以外の何ものでもありません. 中には現在開発途上のソフトウェア, 実験的な変更, あるいは過渡的な機能などが含まれています. また, この中に入っている機能がすべて, 次の公式リリースに入るとは限りません. &os.current; をソースからほぼ毎日コンパイルしている人は たくさんいますが, 時期によってはコンパイルさえできない状態になっていることもあります. 一般的に, これらの問題は可能な限り迅速に解決されますが, &os.current; のソースが不幸をもたらすか, それとも非常に素晴らしい機能をもたらすかというのは文字通り, ある与えられた 24 時間の間の, どの部分であなたがソースを手に入れたかによる場合もあるのです. 誰が &os.current; を必要としてるの? &os.current; は, 主に次の三つの重要なグループを対象としています. ソースツリーのある部分に関して活発に作業している &os; グループのメンバ. 彼らにとっては最新のものにしておくのが 絶対に必要なことなのです. 活発にテストしている &os; グループのメンバ. 彼らは, &os.current; が健全であることを可能な限り確認するために, 種々の問題と戦う時間を惜しまない人々です. 彼らはまた, 様々な変更に関する提案や &os; の大まかな方向付けを行ないたいと思っている 人々でもあります. 単に, 様々な事に目を向け, 参考のために (たとえば動かすためではなく読むために) 最新のソースを使いたいと思っている &os; (または他の) グループのまわりにいるメンバ. これらの人々はまた, 時々コメントやコードを寄稿してくれます. &os.current; に期待しては<emphasis>いけない</emphasis>ことは? なにか新しくカッコイイモノがあると聞き, 自分の周囲では一番にそれを持ちたいがために, リリース前のコードの断片を追いかけること. バグを修正するための素早い方法. わたしたちが公式にサポートすること. わたしたちは 3 つの公式な &os.current; のグループの一つに, 実際に属する人々を助けるのにベストを尽くしますが, 技術的なサポートを行なうには, 単に「時間が足りない」のです. これはわたしたちが外の人を助けるの好まない, ケチで意地悪い人間だということではなく (もしそうなら &os; なんかやっていません), 文字通りわたしたちは一日に 400 ものメッセージに答え, かつ &os; の作業をすることなど出来ない! ということなのです. もし, &os; の改良作業を続けるか, それともたくさんの質問に答えるか, という二者択一が与えられたとしたら, - 開発者とユーザのほとんどは後者を支持するでしょう. + 開発者とユーザのほとんどは前者を支持するでしょう. &os.current; を使う &a.current; と &a.cvsall; に加わってください. これは単に良い考えであるというだけでなく, 必須のことなのです. もし &a.current; メーリングリストに入っていなければ, さまざまな人がシステムの現在の状態について 述べているコメントを見ることは決してありませんし, 従って他の人が既に見つけて解決している 多くの問題に戸惑ってあきらめてしまうでしょう. さらに言うと, システムを正常に保つための 重要な情報を見逃してしまう可能性もあります. &a.cvsall; メーリングリストでは, それぞれの変更についての commit ログを見ることができます. また, それに関して起こり得る副作用の情報を得ることができますので, 参加する価値のあるメーリングリストです. これらのメーリングリストに入るには, &a.majordomo; へ subscribe freebsd-current subscribe cvs-all majordomo と書いたメールを送ってください. オプションとして本文に help と書けば, Majordomo からあなたへ, わたしたちがサポートする様々なメーリングリストに参加 /脱退する方法に関する, 詳しいヘルプが送られます. ftp.FreeBSD.org からのソースの入手. 以下の 3 つの方法で行なうことができます. cvsup cron -CURRENT CVSup を使った同期 cvsup を この supfile を用いて使用する. これは 2 番目に推薦される方法です. なぜなら, cvsup によって一度全体を入手し, 後は変更されたところだけを入手することができるからです. たくさんの人が自動的にソースを最新のものに保つために cvsup を cron から起動しています. これを行なうための非常に簡単な方法は, 単に
&prompt.root; pkg_add -f ftp://ftp.FreeBSD.org/pub/FreeBSD/development/CVSup/cvsupit.tgz
とタイプすることです. -CURRENT ftp によるダウンロード ftp を使う. &os.current; のソースツリーは常に ftp://ftp.FreeBSD.org/pub/FreeBSD/FreeBSD-current/ で公開されています. わたしたちはまた, 全体を compress/tar して入手できる wu-ftpd を使っています. たとえば, usr.bin/lex があったとすると, ftp> cd usr.bin ftp> get lex.tar とすることにより, ディレクトリ全体(この場合, usr.bin/lex以下全体) を tar ファイルとして入手することができます. -CURRENT CTM を使った同期 CTMを用いる. (接続料が高額だったり, email でのアクセスしかできないような) あまり良質でない TCP/IP 接続の場合には, CTM を利用すると良いでしょう. ただし, これには多くの手間がかかりますし, 壊れたファイルを受けとってしまう可能性もあります. そのため, 最近ではあまり使われなくなっており, 長い間使用できなくなってしまう事態が発生する可能性があります (訳注: 保守する人が少ないためです). 9600bps 以上の速度で接続しているなら, CVSup を利用されることを推奨します. もし, ソースを眺めるだけでなく, 走らせるために入手しているのであれば, 一部だけ選ぶのではなく, &os.current; の全体を手に入れてください. なぜなら, ソースのさまざまな部分が他の部分の更新に依存しており, 一部のみをコンパイルしようとすると, ほぼ間違いなくトラブルを起こすからです. &os.current; をコンパイルする前に /usr/src にある Makefile を良く読んでください. アップグレードの処理の一部として, 少なくとも一回は最初に make world を行なうべきでしょう. &a.current; を読めば, 次のリリースへ向けて時々必要になる他のブートストラップの方法に関して, 常に最新情報を得ることが出来ます. アクティブになって下さい! もし &os.current; を走らせているなら, わたしたちはそれに関するコメント, 特に拡張やバグ潰しに関する提案, を欲しています. コードを伴う提案はもっとも歓迎されるものです! 安定版の &os; を使う 訳: &a.jp.iwasaki;. &os.stable; ってなに? -STABLE &os.stable; とは定期的に公開されるリリースを作成するための開発ブランチです. このブランチに加えられる変更は原則として, 事前に &os.current; で試験ずみであるという特徴があります. ただそうであっても, これは開発用ブランチの一つであるということに注意してください. つまり, ある時点における &os.stable; のソースが どんな場合にも使えるものであるとは限らないということです. このブランチはもう一つの開発の流れというだけであって, エンドユーザ向けのものではありません. 誰が &os.stable; を必要としているの? もしあなたが FreeBSD の開発過程に興味があるとか, それに対する貢献を考えていて, 特にそれが 次回のポイントリリースに関係するもの であるなら &os.stable; を追うことを考えると良いでしょう. セキュリティ上の修正は &os.stable; ブランチに対して行なわれますが, そのために &os.stable; を追う必要はありません. すべての FreeBSD セキュリティ勧告には 影響のあるリリースで問題点を修正する方法が説明されており, セキュリティ上の理由のみから開発用ブランチ全体を追いかけることは, 同時に望ましくない変更点まで取り込んでしまう可能性があるからです. わたしたちは &os.stable; ブランチがいつも安定に動作するように 努めていますが, それが保証されているというわけではありません. また, コードは &os.stable; に加えられる前に &os.current; で開発されるのですが, &os.stable; のユーザは &os.current; よりも多いため, &os.current; で発見されなかった バグが &os.stable; で発見され, 時々それが問題となることがあるのは 避けることができません. このような理由から, わたしたちは盲目的に &os.stable; を追いかけることを推奨しません. 特に, 最初に開発環境でコードを十分に試験せずに プロダクション品質が要求されるサーバを &os.stable; にアップグレードしてはいけません. もしそうするための資源的な余裕がない場合は, リリース間のバイナリアップデート機能を利用して, 最新の FreeBSD リリースを使うことを推奨します. &os.stable; を使う -STABLE 利用する &a.stable; へ加わってください. このメーリングリストでは, &os.stable; の構築に関連する事柄や, その他の注意すべき点 に関する情報が流れています. また開発者は議論の余地がある修正や変更を考えている場合に, このメーリングリストで公表し, 提案された変更に関して問題が生じるかどうかを返答する機会をユーザに与えます. また, &a.cvsall; メーリングリストでは, それぞれの変更がなされると, 起こりうる副作用に関するすべての適切な情報と一緒に commit log を読むことができます. subscribe しておきたいもう一つのメーリングリストです. メーリングリストに参加するには, &a.majordomo; へメッセージの本文に次のように書いたメールを送ってください: subscribe freebsd-stable subscribe cvs-all majordomo オプションとして本文に `help' と書けば, Majordomo はわたしたちがサポートするさまざまなメーリングリストに参加 / 脱退する方法に関する詳しいヘルプを送付します. もし, あなたが新しいシステムをインストールしようとしていて それを可能な限り安定なものにしておきたいなら, 最新のブランチの snapshot を ftp://releng4.freebsd.org/pub/FreeBSD から取得し, これを一般のリリースのものと同様にインストールしてください. もし, 既に &os; の以前のリリースが動いている場合で, これをソースからアップグレードしようとするならば, ftp.FreeBSD.org より簡単に これを行う事が出来ます. これには次の 3 つの方法があります. CTM -STABLE CTM を使った同期 CTM 機能を使用する. 転送レートが安定している TCP/IP 接続でない場合は, この方法が適しています. -STABLE CVSup を使った同期 cvsup を この supfile を用いて使用する. 一度コレクション全体を入手してしまえば, 前回からの変更部分だけですむので, 2 番目に推奨される方法です. 多くの人が cron から cvsup を実行し, 自動的にソースコードを最新の状態に保っています. これを簡単に扱うには次のようにタイプしてください.
&prompt.root; pkg_add -f ftp://ftp.FreeBSD.org/pub/FreeBSD/development/CVSup/cvsupit.tgz
 -STABLE FTP を使ったダウンロード ftp を使用する. &os.stable; 用のソースツリーは 常に次のところで公開されています: ftp://ftp.FreeBSD.org/pub/FreeBSD/FreeBSD-stable/ 私たちはまた, tar/compress でツリー全体を入手できる wu-ftpd を使用しています. 例えば : usr.bin/lex に対して: ftp> cd usr.bin ftp> get lex.tar とすることにより, ディレクトリ全体を tar ファイルとして入手することができます. 基本的には, ソースに迅速でオンデマンドなアクセスが必要で, 接続のバンド幅が問題でなければ, cvsup か ftp を使いましょう. そうで ない場合は CTM を使いましょう. -STABLE 構築, コンパイル &os.stable; をコンパイルする前に, /usr/src にある Makefile をよ く読んでください. 少なくとも一回はアップグレードの処理の一部として最初に make world を実行するべきでしょう. &a.stable; を読めば, 次のリリースに移行する に当たって時々必要となる既存システムからの 新システムの構築手順に ついての最新情報が得られるでしょう. ソースの同期 訳: &a.jp.iwasaki;. 13 September 1997. インターネット接続 (または電子メール) を使用して, あなたの興味の対象によって &os; プロジェクトのソースのある一部分または全体の最新を 追いかける方法は色々あります. 私たちが提供している基本的なサービスは Anonymous CVS, CVSup と CTM です: ソースツリーの一部を最新のものに更新することは可能です. ただし, サポートされているアップデート手順は, ソースツリー全体を最新のものに更新して, ユーザランド (/bin や /sbin にあるような, ユーザが実行するプログラム全体のこと) およびカーネルのソースから再構築することのみであることに注意してください. カーネルだけ, あるいはユーザランドだけというように, ソースツリーの一部を更新した場合は, 問題が生じることがよくあります. この時に発生する問題はコンパイル時のエラーからカーネルパニック, データの破壊とさまざまです. anonymous CVS Anonymous CVS と CVSup は pull 同期モデルを採用しています. CVSup の場合, ユーザ (または cron スクリプト) が cvsup 起動し, どこかにある cvsupd サーバとやりとりしてファイルを 最新状態にします. 届けられる更新情報はその時点の最新のものであり, また必要な時にだけ取り寄せられます. 興味のある特定のファイルやディレクトリに 限定して更新することも簡単にできます. クライアント側のソースツリーの状態・ 設定ファイルの指定に従い, サーバによって更新情報が 素早く生成されます. Anonymous CVS は, このプログラムがリモートの CVS リポジトリから直接変更点を pull できるようにした &man.cvs.1; への拡張であるという点で, CVSup よりもずっと単純です. CVSup は効率の点ではるかにまさっていますが, Anonymous CVS の方が簡単に利用できます. CTM 一方, CTM はあなたが持っているソースとマスタアーカイブ上に あるそれとの対話的な比較をおこないませんし, あるいは向こう側から変更点を pull したりもしません. そのかわりに, 前回の実行時からの変更を認識するスクリプトが マスタ CTM マシン上で一日に数回実行され, すべての変更を compress して通し番号を振り, さらに電子メールで転送できるようにエンコードします (印字可能な ASCII キャラクタのみです). 受信した後は, これらの CTM のデルタ は自動 的にデコード, 検査してユーザのソースのコピーに変更を適用する &man.ctm.rmail.1; によって処理可能となります. この処理は CVSup や Anonymous CVS よりずっと効率 的であり, pull モデルというよりむしろ push モデルで あるため, 私たちのサーバ資源の負荷は軽くなります. もちろん他のトレードオフもあります. うっかりアーカイブ の一部を消してしまっても, CVSup は壊れた部分を検出して再構築してくれます. CTM はこれをやってくれませんし, Anonymous CVS はおそらく他の何よりも深く混乱してしまうことが多いでしょう. もしソースツリーの一部を消してしまったら, (最新の CVS ベースデルタから) 一からやり直し, CTM か anoncvs を使って悪い部分を消去し, 再同期させることによって すべてを再構築しなければなりません. Anonymous CVS, CTM, CVSup についての 詳しい情報については, 以下の節を参照してください. <command>make world</command> の利用 make world FreeBSD のどれか特定のバージョン &os; (&os.stable;, &os.current; など) について, ローカルのソースツリーを同期させたら, そのソースツリーを使ってシステムを 再構築しなければなりません. バックアップを作成する システムを再構築する前にバックアップを 作成することの重要性は, いくら強調してもし過ぎると言うことはありません. システム全体の再構築とは (以降に書かれた手順に従っている限り)難しい作業ではありませんが, どんなに注意していたとしても, あなた自身, あるいはソースツリーで作業している他の人達に手違いがあった時には, システムが起動しなくなってしまう状態になることがあるのです. まず, バックアップがきちんと作成されていることを確認して, fix-it フロッピーを用意してください. 多分, それを使うことはないと思いますが, あとで後悔することのないよう, 念のため用意しておきましょう. メーリングリストに参加する メーリングリスト もともと, &os.stable; と &os.current; のコードブランチは, 開発中のものです. &os; の作業に貢献してくださっている人達も人間ですから, 時にはミスをすることだってあるでしょう. そのような間違いは, 単に警告を示す見慣れない 診断メッセージをシステムが,表示するような, 全く害のないものであることもあれば, システムを起動できなくしたり, ファイルシステムを破壊してしまうような, 恐ろしい結果を招くものかも知れません. 万が一, このような問題が生じた場合, 問題の詳細と, どのようなシステムが影響を受けるかについて書かれた 注意(heads up)の記事が 適切なメーリングリストに投稿され, そして, その問題が解決されると, 問題解決(all clear)のアナウンス記事が同様に 投稿されます. &os.stable; や &os.current; ブランチを試したり, それらに 追随していくときに FreeBSD-stable@FreeBSD.ORG や FreeBSD-current@FreeBSD.ORG を読まないというのは, 自ら災難を招くことになるでしょう. 訳注: これらのメーリングリストは英語でやりとりされているため, 日本語での投稿は歓迎されません. 英語でのやりとりができない人は, FreeBSD 友の会 の運営しているメーリングリストをあたってみるのがいいでしょう. <filename>/usr/src/UPDATING</filename> を読む 何を始めるにしろ, まず最初に /usr/src/UPDATING (もしくはあなたがソースコードを どこにコピーしたにせよそれに相当するファイル) を読みましょう. このファイルにはあなたが遭遇するかも知れない問題に対する重要な情報を 含んでいたり, あなたが特定のコマンドを実行しなければならなくなった時 その順序を指示したりするはずです. UPDATING があなたが読んだ事柄と矛盾している時は UPDATING が優先します. UPDATING を読むということは, 前述の 適切なメーリングリストを購読する代わりにはなりません. 二つの要求は相補的なもので排他的なものではないのです. <filename>/etc/make.conf</filename> の確認 make.conf まず, /etc/defaults/make.conf と /etc/make.conf を調べてください. そこには 最初から標準的なものが (多くのものはコメントアウトされていますが) 含まれています. ソースからシステムを再構築するときに make が /etc/make.conf に付け加えられた設定を使用します. /etc/make.conf に追加された設定は make を実行したときに常に使われることを覚えておいてください. そのため, システムに必要な設定を書いておくと良いでしょう. 標準的なユーザならおそらく, /etc/defaults/make.conf の CFLAGS と NOPROFILE のコメントをはずすことを考えると思います. 他の定義 (COPTFLAGS, NOPORTDOCS など) の定義行についても, コメントを外す必要があるかどうか調べておきましょう. <filename>/etc/group</filename> の更新 /etc ディレクトリには, システム起動時に実行されるスクリプトだけでなく, あなたのシステムの設定に関連する情報の大部分が 含まれています. そのディレクトリに含まれる スクリプトは, FreeBSD のバージョンによって多少異なります. また, 設定ファイルのなかには, 稼働中のシステムが日々利用している ものもあります. 実際には, /etc/group などがそれに該当します. make world のインストールの段階では, 特定のユーザ名, あるいはグループが存在していることを 要求する場面があります. システムのアップグレードを行なう際には, それらのグループが削除, あるいは変更されて存在していない可能性が 考えられますが, そういった場合, システムのアップグレードを 行なっている間に, 問題が発生する原因になります. この種の例でもっとも記憶に新しいのは, ppp サブシステムがインストールされる時, そのサブシステムが利用する 解決方法は, /usr/src/etc/group を調べ, 自分のシステムのグループ名リストと比較することです. 最新のファイルに含まれていて, あなたのファイルに含まれていない グループ名があれば, あなたのファイルにそのグループ名をコピーして下さい. 同様に, 名前が異なるにも関わらず, /etc/group と /usr/src/etc/group で同じ GID を持っているグループ名があれば, /etc/group に含まれる, 該当するすべてのグループ名を変更しておかなければなりません. もし, あなたがもっと神経質な人なら, あなたが名前を変更したり, 削除してしまったグループが所有しているファイルを, 次のようにして調べることもできます. &prompt.root; find / -group GID -print これは GID(グループ名もしくは数字で示されたグループ ID)で 指定されたグループが所有するすべてのファイルを表示します. シングルユーザモードへの移行 シングルユーザモード コンパイルは, シングルユーザモードで行なった方が良いでしょう. そうすることで多少速度が向上する, というちょっとした利点が あるだけでなく, システムの再インストールは重要なシステムファイル, 標準コマンド, ライブラリ, インクルードファイルなどを操作します. 稼働中のシステムに (特に他のユーザがそのシステムにログインしている時に) そのような変更を加えることは, トラブルを引き起こす原因となります. マルチユーザモード もう一つの方法として, マルチユーザモードでシステムを再構築して, シングルユーザモードに移行してからそれをインストールする, というのがあります. もしこのような方法で行ないたい場合は, 以下の手順を構築が完了するところまで飛ばしてください. 稼働中のシステムでシングルユーザモードに移行するには, スーパユーザ(root)権限で次のコマンドを実行します. &prompt.root; あるいはシステムを再起動し, ブートプロンプトから フラグを設定することで, シングルユーザモードで システムを起動させることができます. 起動後, シェルプロンプトから 次のように実行して下さい. &prompt.root; fsck -p &prompt.root; mount -u / &prompt.root; mount -a -t ufs &prompt.root; swapon -a これはファイルシステムをチェックした後, / を読み書き可能にして再マウント, /etc/fstab に指定されている, それ以外の UFS ファイルシステムをすべてマウントしてから スワップを有効にします. <filename>/usr/obj</filename> の削除 システムが再構築される時, 構築されたものは(デフォルトで) /usr/obj 以下のディレクトリに格納され, そのディレクトリの下は /usr/src と同じ構造となります. このディレクトリをあらかじめ削除しておくことにより, make world の行程にかかる時間を短縮させ, 依存問題に悩まされるようなトラブルを回避することができます. /usr/obj 以下のファイルには, 変更不可(immutable)フラグ(詳細は &man.chflags.1; 参照)がセットされているものがある可能性があります. そのため, まず最初にそのフラグを変更しなければなりません. &prompt.root; cd /usr/obj &prompt.root; chflags -R noschg * &prompt.root; rm -rf * ソースの再構築 出力メッセージの保存 実行される &man.make.1; からの出力は, ファイルに保存すると良いでしょう. もし, 何か障害が発生した場合, エラーメッセージのコピーを手元に残すことができます. 何が悪かったのか, あなた自身がそれから理解することはできないかも 知れませんが, &os; メーリングリストに投稿して, 誰か他の人からの助言を得るために利用することができます. ファイルに保存する最も簡単な方法は, &man.script.1; コマンドを 使い, 引数に出力を保存したいファイル名を指定することです. これを make world の直前に行ない, 再構築が終了してから exit と入力すると, 出力を保存することができます. &prompt.root; script /var/tmp/mw.out Script started, output file is /var/tmp/mw.out &prompt.root; make TARGET … compile, compile, compile … &prompt.root; exit Script done, … 出力を保存する場合, /tmp ディレクトリの中に 保存してはいけません. このディレクトリは, 次の再起動で削除されてしまう可能性があります. 出力の保存には, (上の例のように)/var/tmpや root のホームディレクトリが適しています. ベースシステムの構築とインストール まず, カレントディレクトリを /usr/src に 変更しなければなりません. 次のように実行して下さい. &prompt.root; cd /usr/src (もちろん, ソースコードが他のディレクトリにある場合には, /usr/src ではなく, ソースコードのあるディレクトリに移動して下さい). make make world を行なうには, &man.make.1; コマンドを使用します. このコマンドは, Makefile というファイルから, FreeBSD を構成するプログラムの再構築方法や, どういう順番でそれらを構築すべきかといったような 指示を読み込みます. コマンドラインの一般的な書式は, 次のとおりです. &prompt.root; make この例では, が &man.make.1; に渡されるオプションになります. どのようなオプションが利用できるかについては, マニュアルページを 参照して下さい. は, Makefile に渡される変数であり, この変数は Makefile の動作をコントロールします. また, /etc/make.conf で設定される変数も 同様です. これは変数を設定するもう一つの方法として用意されています. &prompt.root; make -DNOPROFILE=true target は, プロファイル版のライブラリを構築しないことを指定する もう一つの記法で, /etc/make.conf 中の NOPROFILE= true # Avoid compiling profiled libraries の行に対応します. target は, &man.make.1; に どのように動作するのかを指示するためのものです. 各々の Makefile には, 数多くの異なる ターゲット(target) が定義されていて, 指定されたターゲットによって, 動作が決まります. Makefile に書かれているターゲットには, あなたが指定しても意味を持たないものも含まれます. これらは, システムの再構築に必要な段階を, 多くの さらに細かい段階に分割するため, 構築の過程で利用されるものです. 大抵の場合, &man.make.1; にパラメータを指定する必要はないでしょうから, コマンドラインは次のようなものになるでしょう. &prompt.root; make target &os; の 2.2.5 から(実際には, &os.current; ブランチで最初に作成され, 2.2.2 と 2.2.5 の間の時点で &os.stable; に導入されたのですが), world ターゲットは buildworld と installworld の二つに分割されました. その名前が示すように, buildworld は /usr/obj 以下に新しい完全な ディレクトリツリーを構築し, installworld は, そのツリーを 現在のマシンにインストールします. これは, 二つの理由から非常に有用です. まず第一に, 稼働中のシステムに全く影響を与えることなく, 安全にシステムの構築作業を行えることです. 構築作業は何にも依存せず独立して行なわれるため, マルチユーザモードで稼働中のシステムでも, 何一つ 悪影響を与えずに buildworld を 実行することができます. ただし, installworld は シングルユーザモードで行なうことをおすすめします. 第二に, NFS マウントを利用することで, ネットワーク上の複数のマシンをアップグレードすることが 可能な点があげられます. 例えば三台のマシン, マシン A, マシン B, マシン C をアップグレードしたい場合には, まず マシン A で make buildworld と make installworld を実行します. それから, マシン B とマシン C で /usr/src を NFS マウントし, make installworld とすることで 構築済みのシステムを各マシンにインストールすることができるのです. world ターゲットも利用可能ですが, このターゲットの利用は推奨されていません. 次のコマンド &prompt.root; make buildworld を実行してください. ここで make に -j オプションをつけると, 同時にいくつかのプロセスを生成させることが できます. この機能はマルチ CPU マシンで特に効果を発揮します. 構築過程の大部分では CPU 性能の限界より I/O 性能の限界の方が問題となるため, シングル CPU マシンにも効果があります. 普通のシングル CPU マシンで以下のコマンド &prompt.root; make -j4 buildworld を実行すると, &man.make.1; は最大 4 個までのプロセスを同時に実行します. メーリングリストに投稿された経験的な報告によると, 4 個という指定が最も良いパフォーマンスを示すようです. もし, 複数の CPU を備えたマシンで SMP 設定が行なわれたカーネルを 利用しているなら, 6 から 10 の間の値を設定し, 速度がどれくらい 向上するか確認してみて下さい. ただし, この機能はまだ実験段階であるということに注意してください. そのため, ソースツリーへ変更が加えられたときに これが正常に機能しなくなる可能性があります. もし, このオプションを用いてシステムの構築に失敗した場合には, 障害を報告する前に, もう一度オプションを付けずに試してみて下さい. システムの構築にかかる時間 make world 時間 構築時間を決める要素はさまざまありますが, 現時点では Pentium 3 の 500MHz, 128MB の RAM という構成で トリックや近道を使わずに普通に構築した場合, &os.current; の構築に約 3 時間半かかります. &os.stable; の構築は, もう少し早く終わります. 新しいカーネルの構築とインストール カーネル(kernel) 構築, コンパイル 新しいシステムの全機能を完全に利用できるようにするには, カーネルの再構築をする必要があります. 再構築は, ある種のメモリ構造体が変更された時には特に必須であり, &man.ps.1; や &man.top.1; のようなプログラムは, カーネルとソースコードのバージョンが一致しないと正常に動作しないでしょう. 最も簡単で安全にカーネルの再構築を行なう方法は, GENERIC を使ったカーネルを構築・インストールすることです. GENERIC にはあなたが必要とするデバイスがすべて含まれていない かも知れませんが, あなたのシステムをシングルユーザモードで 起動させるのに必要なものはすべて入っています. これは新しいバージョンのシステムがきちんと動作するかどうか 調べる良い方法の一つです. GENERIC で起動してから, あなたがいつも使っているカーネルコンフィグレーションファイルを 使って新しいカーネルを構築することで, システムが正常に動作しているかどうか確かめることができます. もし &os; 4.0 以降のシステムにアップグレードする場合, ( に記載されている) 標準的なカーネル構築手順は使えません. 代わりに, 以下のコマンドを実行する必要があります. &prompt.root; cd /usr/src &prompt.root; make buildkernel &prompt.root; make installkernel &os; の 4.0 以前にアップグレードする場合は, 標準的なカーネル構築手順に従う必要があります. ただし, 以下のコマンドを使って新しいバージョンの &man.config.8; を利用することが推奨されています. &prompt.root; /usr/obj/usr/src/usr.sbin/config/config KERNELNAME シングルユーザモードで再起動する single-user mode 新しいカーネルが動作するかどうかテストするために, シングルユーザモードで再起動するべきです. シングルユーザモードでの起動は, に書かれている手順に従ってください. 新しいシステムバイナリのインストール 十分最近のバージョンの &os; を make buildworld で構築しているなら, 次にここで installworld を 使うことで新しいシステムバイナリのインストールを行ないます. それには, 以下のコマンドを実行してください. &prompt.root; make installworld make buildworld でコマンドラインから 変数を指定した場合は, 同じ指定を make installworld のコマンドラインにも 指定しなければなりません. ただし, オプションについてはその限りではありません. たとえば は installworld で絶対に使ってはいけません. たとえば以下のように実行したなら, &prompt.root; make -DNOPROFILE=true buildworld 以下のようにしてインストールしなければなりません. &prompt.root; make -DNOPROFILE=true installworld もしそうしなかった場合, make buildworld の段階で構築されていない プロファイル版ライブラリをインストールしようとしてしまうでしょう. <command>make world</command> で更新されないファイルの更新 システムの再構築は, いくつかのディレクトリ ( 特に, /etc, や /var や /usr) において, 新規に導入されたり, 変更された設定ファイルによる ファイルの更新は行なわれません. mergemaster これらのファイルを更新するもっとも簡単な方法は, &man.mergemaster.8; を使うことです. これは自分でやることも可能なので, そうしても かまいません. &man.mergemaster.8; は簡単に使えるので, こちらを使うことを お勧めします. その場合には 次のセクション に進んでください. まず最初にマニュアルページを読んで, /etc のバックアップを取って不測の事態に備えてください. 手動で更新することを選んだ場合, 単にファイルを /usr/src/etc から /etc に コピーしただけでは正常に動作させることはできません. これらのファイルには, インストールという 手順を踏まなければならないものが含まれています. /usr/src/etc ディレクトリは /etc ディレクトリにそのまま置き換えられるような コピーではないからです. また, /etc にあるべきファイルのうちで /usr/src/etc にないものもあります. 手動で行う際の 一番簡単な方法は, ファイルを新しいディレクトリにインストールしてから, 以前のものと異なっている部分を調べて更新作業を行なうことです. 既存の <filename>/etc</filename> をバックアップする 理論的に考えて, このディレクトリが自動的に 処理されることはありませんが, 念には念を入れておいて 損はありません. たとえば以下のようにして, 既存の /etc ディレクトリを どこか安全な場所にコピーしておきましょう. &prompt.root; cp -Rp /etc /etc.old は再帰的なコピーを行ない, はファイルの更新時間や所有者などを保存します. また, 新しい /etc やその他のファイルを インストールするための, 仮のディレクトリを作っておく必要があります. 仮ディレクトリは /var/tmp/root に置くのが良いでしょう. 同様に, 必要なサブディレクトリもこの下に置きます. &prompt.root; mkdir /var/tmp/root &prompt.root; cd /usr/src/etc &prompt.root; make DESTDIR=/var/tmp/root distrib-dirs distribution 上の例は, 必要なディレクトリ構造をつくり, ファイルをインストールします. /var/tmp/root 以下に作られる, たくさんの空のディレクトリは削除する必要があります. 一番簡単なやり方は, 次のとおりです. &prompt.root; cd /var/tmp/root &prompt.root; find -d . -type d | xargs rmdir 2>/dev/null これは空ディレクトリをすべて削除します. (空でないディレクトリに関する警告を避けるために, 標準エラー出力は /dev/null に リダイレクトされます) この段階の /var/tmp/root には, 本来 / 以下にあるべきファイルが すべて含まれています. 各ファイルを順に見て, 既存のファイルと異なる部分を 調べて下さい. /var/tmp/root 以下に インストールされているファイルの中には, /var/tmp/root/ と /var/tmp/root/root/ の中にある シェルスタートアップ ファイルだけですが, 他のものがあるかも知れません. (これは, あなたがこれをどの時点で読んでいるかに依存するので, もっとも簡単な方法は, 二つのファイルを比較するコマンド &man.diff.1; を使うことです. &prompt.root; diff /etc/shells /var/tmp/root/etc/shells これは, あなたの /etc/shells ファイルと 新しい /etc/shells ファイルの 異なる部分を表示します. これらを, あなたが書き換えたものに変更点をマージするか, それとも既存のファイルを新しいもので上書きするかを 判断する材料にして下さい. 新しい root ディレクトリ (<filename>/var/tmp/root</filename>) の名前に タイムスタンプを付けておくと, 異なるバージョン間の比較を楽に行なうことができます. 頻繁にシステムの再構築を行なうということは, /etc の更新もまた, 頻繁に行う必要がある ということです. これはちょっと手間のかかる作業です. この作業は, あなたが /etc にマージした, 新しく変更されたファイルの最新のセットのコピーを保存しておくことで 素早く行なうことができます. 下の手順は, それを実現するための一つの方法です. 普通に make world します. /etc や 他のディレクトリを更新したくなったときは, ターゲット ディレクトリに, そのときの日付に基づく名前をつけてください. たとえば 1998 年 2 月 14 日 だとすれば, 以下のようにします. &prompt.root; mkdir /var/tmp/root-19980214 &prompt.root; cd /usr/src/etc &prompt.root; make DESTDIR=/var/tmp/root-19980214 \ distrib-dirs distribution 上に説明されているように, このディレクトリから変更点をマージします. その作業が終了しても, /var/tmp/root-19980214 を 削除してはいけません. 最新版のソースをダウンロードして再構築したら, ステップ 1 にしたがって下さい. 今度は, /var/tmp/root-19980221 (更新作業が一週間おきだった場合) のような名前の, 新しいディレクトリをつくることになるでしょう. この段階で &man.diff.1; を使用し, 二つのディレクトリを比較する再帰的 diff を作成することで, 一週間の間に行なわれたソースへの変更による相違点を調べます. &prompt.root; cd /var/tmp &prompt.root; diff -r root-19980214 root-19980221 これによって報告される相違点は, 大抵の場合, /var/tmp/root-19980221/etc と /etc との場合に比べて 非常に少ないものになります. 相違点が少ないため, 変更点を既存の /etc ディレクトリにマージすることは, 比較的容易になります. ここまで終了したら, /var/tmp/root-* の 二つのうち, 古い方のディレクトリは削除して構いません. &prompt.root; rm -rf /var/tmp/root-19980214 この工程を, /etc へ変更点をマージする 必要があるたび, 毎回繰り返します. ディレクトリ名の生成を自動化するには, &man.date.1; を利用することができます. &prompt.root; mkdir /var/tmp/root-`date "+%Y%m%d"` <filename>/dev</filename> の更新 DEVFS DEVFS もし DEVFS を利用しているなら, この作業は必要ありません. ほとんどの場合, &man.mergemaster.8; は デバイスの再構築が必要であることを検出して自動的にそれを実行するのですが, ここではデバイスの再構築を手動で行なう方法について説明します. 安全のため, これはいくつかの段階に分けて行ないます. /var/tmp/root/dev/MAKEDEV を /dev にコピーします. &prompt.root; cp /var/tmp/root/dev/MAKEDEV /dev MAKEDEV /etc を更新するのに &man.mergemaster.8; を使った場合, MAKEDEV スクリプトは既に更新 されているでしょうが, (&man.diff.1; を使って) チェックすることは無駄ではありませんし, 必要なら自分でコピーしてください. ここで, /dev のファイル一覧を記録しておきます. この一覧は, 各ファイルの許可属性, 所有者, メジャー番号, マイナー番号が 含まれている必要がありますが, タイムスタンプは含まれていてはいけません. これを行なう簡単な方法は, &man.awk.1; を使って, いくつかの情報を取り除くことです. &prompt.root; cd /dev &prompt.root; ls -l | awk '{print $1, $2, $3, $4, $5, $6, $NF}' > /var/tmp/dev.out デバイスファイルをつくり直します. &prompt.root; もう一度, ディレクトリのファイル一覧を記録します. 今回は /var/tmp/dev2.out です. この段階で, この二つのファイル一覧を調べて 作成に失敗したデバイスを探して下さい. 違いは一つもないはずなのですが, 安全のために一応チェックして下さい. &prompt.root; diff /var/tmp/dev.out /var/tmp/dev2.out 次のようなコマンドを使用し, ディスクスライスエントリを 再作成することで, ディスクスライスの矛盾を検出することができます. &prompt.root; sh MAKEDEV sd0s1 適当な組み合わせは, 環境によって異なります. <filename>/stand</filename> の更新 この段階は, 完全な更新を行なう場合にだけ必要な内容を含んでいます. 悪影響はありませんので, 省略しても構いません. 完全な更新を行なうために, /stand にあるファイルも同じように 更新したいと考えるかも知れません. これらのファイルは, /stand/sysinstall という バイナリファイルへのハードリンクです. このバイナリファイルは, 他のファイルシステム(特に /usr)が マウントされていない場合にも動作できるよう, 静的にリンクされていなければなりません. &prompt.root; cd /usr/src/release/sysinstall &prompt.root; make all install 再起動 これで, 作業はおしまいです. すべてがあるべき正しい場所に存在することをチェックしたら, システムを再起動します. これは, 単に &man.fastboot.8; を実行するだけです. &prompt.root; fastboot 作業の完了 ここまで来れば, &os; システムのアップグレードは成功です. おめでとうございます. もしちょっとした問題があった場合でも, システムの一部を再構築するのは簡単です. たとえば, アップグレードの途中で誤って /etc/magic を削除して /etc にマージしてしまい, その結果 file コマンドが動作しなくなってしまったような場合を考えてみてください. これを修復するには, 次のコマンドを実行すれば修復することができます. &prompt.root; cd /usr/src/usr.bin/file &prompt.root; 質問ですか? 変更が行なわれたら, その度にシステムの再構築が必要になるのでしょうか? それは変更の性質によるので, なんとも言えません. 例えば, CVSup を実行したとき, 最後に実行したときから比べて 次にあげるようなファイルが更新されていたとします. src/games/cribbage/instr.c src/games/sail/pl_main.c src/release/sysinstall/config.c src/release/sysinstall/media.c src/share/mk/bsd.port.mk このときには, 改めてシステム全体を再構築する必要はないでしょう. 適切なサブディレクトリに移って make all install を行うだけで更新することができます. しかし, もし何らかの大きな変更が行なわれているとき, 例えば src/lib/libc/stdlib が変更されている場合には, システム全体を再構築するか, もしくはそのうち, 少なくとも静的にリンクされているもの(と, あなたが追加した 静的にリンクされたプログラム)を作り直す必要があります. 結局のところ, どの時点で現在のシステムをアップグレードするかは あなたが決めることです. 2 週間ごとにシステムを再構築し, その 2 週間の変更を取り込めば 幸せかもしれませんし, 変更のあった部分だけ再構築し, 依存関係を確かめたいと考えるかも知れません. もちろん, それらはどのくらいの頻度でアップグレードしたいか, そして &os.stable; か &os.current; のどちらを追いかけているのかによります. signal 11(もしくは他のシグナル番号)のエラーがたくさん出て コンパイルが失敗します. 何が起こっているんでしょうか? signal 11 これは通常, ハードウェアに問題があることを示しています. システムの再構築は, ハードウェアに対する負荷耐久試験を行なうための 有効な手段の一つで, メモリに関係する問題がよく報告されます. その大部分は, コンパイラが奇妙なシグナルを受け取り, 不可解な異常終了となることで発見されます. 本当にこの問題によるものかどうかは, 再構築をもう一度実行し, 異なる段階で異常終了が発生するか, ということから確認できます. この場合には, マシンの部品を交換して, どの部分が悪いのかを 調べてみることくらいしかできることはありません. 終了したら /usr/obj を削除しても かまいませんか? 一言で答えるなら「削除しても構わない」です. /usr/obj には, コンパイルの段階で生成された すべてのオブジェクトファイルが含まれています. 通常 /usr/obj を保存しておいても, あまり意味はありません. 削除すれば, 大きなディスクスペースを (現在はだいたい 340MB あります) 解放することができます. しかし, もしあなたが何を行なおうとしているのか理解しているなら, この段階を省略して もし, このような危険を承知した上でシステムの再構築を行なう場合には, 次のように変数 NOCLEAN を定義して構築します. &prompt.root; make -DNOCLEAN world 構築を中断した場合, その構築を途中から再開することはできますか? それは, あなたが問題に気付く前に, どれだけの作業を終えているかによって変わります. 一般的に (そしてこれは確実でしっかりした 規則ではありませんが), make world の過程では, 基本的なツール ( &man.gcc.1;, や &man.make.1; のようなもの) や, システムライブラリの新しいコピーが作成されます. その後まず, これらのツールやライブラリはインストールされてから 自分自身の再構築に使われ, もう一度, インストールされます. 全体のシステム (ここでは &man.ls.1; や &man.grep.1; といった 標準的なユーザプログラムを含みます) は, その新しいシステムファイルを用いて作り直されることになります. もし, 再構築が最終段階に入っていること が(記録しておいた出力を見たりすることで)わかっていたら, (全く悪影響を与えることなく)次のようにすることができます. … fix the problem … &prompt.root; cd /usr/src &prompt.root; make -DNOCLEAN all これは, 前回の make world の作業をやり直しません. 次のメッセージ -------------------------------------------------------------- Building everything.. -------------------------------------------------------------- が make world の出力にある場合には, 上のようにしてもほとんど悪影響が現れることはありません. もしこのメッセージがないとか, よく分からないという場合には, 安全を確保し, 後悔するようなことがないよう, システムの再構築を最初からやり直しましょう. NFS あるマシンを この作業を行なうのは簡単で, たくさんのマシンをアップグレードする場合に時間を節約することができます. これには, 中心となるマシンで buildworld を実行し, 終了後にリモートマシンで /usr/src と /usr/obj を NFS マウントしてから, そこで installworld します. どのようにすれば make world を高速化できますか? シングルユーザモードで動かしてください. /usr/src と /usr/obj ディレクトリを, 異なるディスク上の別のファイルシステムに置いてください. また可能ならば, 異なるディスクコントローラに接続された ディスクを使って下さい. さらに高速化するには, これらのファイルシステムを &man.ccd.4; (連結ディスクドライバ) デバイスを 使って, 複数のディスク上に置いてください. プロファイル版の作成を無効化して下さい. (/etc/make.conf で NOPROFILE=true をセットします) 普通, それが必要になることはありません. また, /etc/make.conf の中の CFLAGS を, -O -pipe のように指定しましょう. -O2 の最適化はさらに多くの時間を必要とし, しかも -O と -O2 の 最適化には, ほとんど差はありません. -pipe を指定することで, コンパイラはテンポラリファイルの代わりにパイプを利用します. その結果, (メモリの利用は増えますが)ディスクアクセスが減ります. make に オプションを指定して, 複数のプロセスを並列に実行させてください. これはプロセッサが単一か複数かによらず, どちらも同様に恩恵を得ることができます. /usr/src のある ファイルシステムを, オプションを付けてマウント(もしくは再マウント)してください. これは, そのファイルシステムにおいて, 最後にアクセスされた時刻の書き込みを抑制します. おそらく, この情報が必要になることはないでしょう. &prompt.root; mount -u -o noatime /usr/src 上の例は, /usr/src 自身が独立したファイルシステムで あることを想定しています. もしそうでないときには (例えば /usr の 一部である場合には), /usr/src ではなく 適切なマウントポイントを指定する必要があります. /usr/obj のあるファイルシステムを, async オプションをつけてマウント (もしくは 再マウント) してください. これによって, ディスクへの書き込みが非同期になります. つまり, 書き込み命令はすぐに完了するのに対し, 実際にデータがディスクに書き込まれるのは, その数秒後になります. これによって, 書き込み処理の一括化が可能になるため, 劇的なパフォーマンスの向上が期待できます. このオプションを指定すると, ファイルシステムは 壊れやすくなってしまうことに注意してください. このオプションを付けていて, 突然電源が落ちた場合には, 再起動後にファイルシステムが復旧不能になる可能性が 非常に高くなります. もし, /usr/obj 自身が独立した ファイルシステムであるならば, これは問題になりません. しかし, 同じファイルシステムに, 他の貴重なデータを置いているときには, このオプションを有効にする前に, バックアップをきちんと取っておきましょう. &prompt.root; mount -u -o async /usr/obj もし /usr/obj 自身が ファイルシステムでない場合には, 適切なマウントポイントを指すように, 上の例の名前を置き換えて下さい.