Index: head/release/doc/ja_JP.eucJP/early-adopter/article.sgml =================================================================== --- head/release/doc/ja_JP.eucJP/early-adopter/article.sgml (revision 120973) +++ head/release/doc/ja_JP.eucJP/early-adopter/article.sgml (revision 120974) @@ -1,503 +1,514 @@ %man; %freebsd; %authors; %ja-teams; %teams; %ja-mailing-lists; + +%trademarks; + %release; X"> X"> ]>
&os; &release.current; 初期利用者のための手引き &os; リリースエンジニアリングチーム $FreeBSD$ 2002 2003 &os; リリースエンジニアリングチーム + + &tm-attrib.freebsd; + &tm-attrib.intel; + &tm-attrib.microsoft; + &tm-attrib.sparc; + &tm-attrib.general; + + この記事では、&os; &release.current; の現状を &release.5x; 系列のリリースまたは &os; 一般に不慣れな 利用者の立場から詳細に述べています。 リリースエンジニアリングの背景となる事情、 新機能のハイライト、初期利用者が直面する可能性のある障害を記載しています。 また、4-STABLE 開発ブランチの将来のリリース計画と 既存のシステムをアップグレードするためのヒントをいくつか紹介しています。 はじめに &os; &release.5x; は、2 年ぶりに公開される新しいメジャーバージョンです。 さまざまな新機能に加えて、システムアーキテクチャレベルでの開発も 数多く反映されています。ただしこの進歩は、まだ広く試験されていない 新しいコードが非常に多く導入された結果でもあります。 そのため、現在の &release.4x; リリースと比較すると、 初期の &release.5x; リリースは安定性や性能、 場合によっては機能性などの点で劣っているかも知れません。 &a.re; はこのような理由から、新しいリリースにおいて発生しうる問題を ユーザが自覚して (そして対処する準備ができて) いない限り、 古い &os; リリースを &release.current; にアップグレードするのを 明確に非推奨としています。 特に、今までどおりの動作を期待する慎重なユーザには、しばらくの間は (4.8-RELEASE のような) &release.4x; リリースで運用することをおすすめします。 &release.5x; へのアップグレードを考える時期としては、 おそらく 5-STABLE 開発ブランチが作成された後が適当でしょう。 これは 5.2-RELEASE の公開あたりになる見込みです。 (&os; &release.5x; はいわゆる卵鶏問題を抱えています。 プロジェクトでは皆が可能な限りリリースを 安定で信頼性の高いものにしようと考えているのですが、 その安定性と信頼性を得るには、広い範囲での試験、 特にシステムの新しい機能に対する試験が必要です。 しかし、たくさんのユーザにシステムを試験してもらうためには、 実際のところ最初のリリースを作成し、 配布しなければならないのです!) この文書では、&os; &release.current; のインストールと運用における いくつかの問題点について説明しています。 まず、&os; のリリース工程の概要について解説し、 次に &os; &release.current; の特筆すべき新機能のいくつかと、 不注意からユーザが陥りやすいと思われる問題について紹介します。 また、4-STABLE ベースのリリースを使い続けようと考えているユーザ向けに、 今後の 4-STABLE 開発ブランチにおける短期・中期的なプランについても触れます。 最後に、&release.4x; システムを &release.current; にアップグレードする際の注意点を示します。 &os; リリース工程の概要 &os; では、ソースコードリポジトリに複数の開発ブランチを置く という開発モデルを採用しています。中心となるブランチは CURRENT と呼ばれ、 CVS リポジトリでは HEAD というタグが付けられています。 新機能はまず、このブランチにコミットされます。 つまり CURRENT には新機能が一番最初に追加されますが、 その新機能の追加やデバッグが原因でシステムが壊れてしまうこともある、 ということです。 &os; リリースの大部分は、いくつかある STABLE ブランチから作成されます。これらのブランチには、CURRENT である程度試験された機能だけが追加されます。 現時点で活発に開発されている STABLE ブランチは 1 つだけです。 そのブランチは 4-STABLE と呼ばれており、 &os; &release.4x; リリースはすべてこのブランチから作成されました。 このブランチは CVS リポジトリで RELENG_4 というタグが付けられています。 &os; 5.0 と 5.1 は CURRENT ブランチをベースにしています。 CURRENT ブランチからのリリースは 2 年ぶりです (前回の &os; 4.0 は 2000 年 3 月でした)。 &os; 5.0 のリリース後、少し経過した時点で &os; CVS リポジトリに RELENG_5 というタグが打たれ、 5-STABLE というブランチが作成される予定です。 以前の 2 つの stable ブランチ (3-STABLE および 4-STABLE) は、 それぞれの x.0 リリースの直後 (それぞれ 3.0 と 4.0) に 作成されていました。しかしこの方法では、 新しい STABLE ブランチが作成される前に、 CURRENT ブランチが安定する 十分な時間が確保できないという問題があります。 そのためリリースエンジニアリングチームは、 各ブランチがそのブランチの持つ性格に対して 比較的安定した状態になったことを確認してから、 CVS リポジトリに 5-STABLE ブランチを作成することを予定しています。 おそらくブランチが作成されるまでに、&release.5x; 系列からリリース版がいくつか公開されるでしょう。 5-STABLE ブランチの登場は、5.2-RELEASE の後あたりになると見込んでいます。 &os; リリースエンジニアリング工程に関する詳細は、 リリースエンジニアリングのウェブページ および、&os; リリースエンジニアリング という記事をご覧ください。 きたる 5-STABLE 開発ブランチについての特記事項は 5-STABL 開発ブランチのロードマップ という記事をご覧ください。 新機能 &os; &release.5x; の大きな魅力の 1 つは、数多くの新機能です。 これらの新しい機能は、&os; 4-STABLE 開発ブランチには統合できなかった 大きなアーキテクチャレベルの変更も当然ながら含まれています (一方で新しいデバイスドライバやユーザランドユーティリティなど、 それ自身で完結している改良点は、4-STABLE ブランチに移植されています)。 すべてを網羅したものではありませんが、簡単にまとめてみましょう。 SMPng: 次世代に向けた SMP マシン対応です (開発中)。 現在は、カーネルにおけるマルチプロセッサの同時実行に部分的に対応しています。 この作業は現在進行中です。 KSE: カーネルスケジュールエンティティ (Kernel Scheduled Entities; KSE) は、スケジューラアクティベーション (Scheduler Activations) の手法と同様の、 1 個のプロセスが複数のカーネルレベルスレッドを 持てるようにするための機構です。この機構を利用して マルチスレッドのユーザランドプログラムを実現するために、 (実験的な) libkse ライブラリと libthr ライブラリが提供されています。 - 新しいアーキテクチャ: i386, pc98, alpha アーキテクチャに加え、 - 新たに sparc64 と ia64 アーキテクチャに対応しました。 + 新しいアーキテクチャ: &i386;, pc98, alpha アーキテクチャに加え、 + 新たに &sparc64; と ia64 アーキテクチャに対応しました。 GCC: コンパイラツールチェインが GCC 2.95.X ベースのものから、 GCC 3.2.2 に更新されました。 MAC: 高い拡張性を持ち動的にロード可能な、 強制アクセス制御 (Mandatory Access Control; MAC) ポリシに対応しました。 GEOM: ディスク I/O 要求を変換する拡張性の高いフレームワークです。 GEOM をベースにしたディスク暗号化機能が実験的に開発されています。 FFS: FFS ファイルシステムが (クラッシュから高速に復帰する) バックグラウンド &man.fsck.8; 処理 と ファイルシステムスナップショットに対応しました。 UFS2: UFS2 オンディスクフォーマットが新たに追加されました。 これは、ファイル単位での拡張属性と巨大なファイルに対応しています。 また、UFS2 は &man.newfs.8; のデフォルトのフォーマットになりました。 pc98 を除くすべてのプラットフォームにおいて、 &man.sysinstall.8; はデフォルトで UFS2 のファイルシステムを作成します。 Cardbus: Cardbus デバイスに対応しました。 さらに詳しい新機能のリストは、&os; &release.prev; と &os; &release.current; のリリースノートに書かれています。 初期リリースを使う上での欠点 &os; &release.5x; には説明したような新機能が追加されているのですが、 問題があったり、意図どおりに動かないという部分もいくつか存在します。 これはほとんどの場合、多くの機能がまだ開発中であることに起因したものです。 次に、問題のある部分のいくつかをまとめたリストを示します。 たとえば、上の新機能リストにある SMPng や KSE など、 開発がまだ終わっていない機能が多くあります。 これらの機能はテストと実験用途には向いているものの、 製品品質には達していないかもしれません。 カーネルのデータ構造体や ABI, API が変更されたため、 サードパーティ製のデバイスドライバは、 &os; 5.0 に対応させるための作業が必要です。 また、5-STABLE ブランチが作成される前に若干の ABI, API の変更が加えられる可能性があります。 &os; ベースシステムに含まれていた機能のいくつかが、 Ports Collection に移動しました。 大きなものとしては、Perl、 UUCP、ゲームの大部分 (すべてではありません) が該当します。 プログラムはサポート対象になっていますが、 ベースシステムからなくなったことは混乱を招くかも知れません。 利用者と保守担当者が不足しているため、 &os; ベースシステムの一部が破綻状態に陥りました。 これら (の使われないことの多い機能) は現在削除されています。 特筆すべき事例に、a.out 形式の実行ファイルの生成、 XNS ネットワーキング対応、X-10 コントローラドライバが挙げられます。 &os; 4.0 で正しく動作していた多くの ports/packages が、 &os; 5.0 では構築できなくなったり、 正しく動作しなくなったりしています。 これは大抵の場合、コンパイラツールチェインの変更と、 ヘッダファイルの整頓が原因です。 &os; &release.5x; の多くの新機能が、 一般向けに広く公開される初めての機会になります。 カーネルは、(SMPng などの) このような新機能によって、 大きく変更されています。 &os; 5.0 の新機能に含まれる問題点を追跡するため、 デバッグや診断用のコードがある程度残されています。 これにより &os; 5.0 は、4-STABLE より動作が遅くなっているでしょう。 4-STABLE 開発ブランチへの機能統合は、 -CURRENT で安定した後にのみ、行なわれます。 &os; 5.0 は、このような -STABLE ブランチの持つ安定性を持っていません (訳注: &os; 5.0 への新機能追加は、「安定した後に統合」という -STABLE ブランチの慣習に則っていないという意味です)。 (5-STABLE 開発ブランチは、5.2-RELEASE の後あたりに作成される予定です)。 &os; ハンドブック と FAQ のような文書は &os; &release.5x; までに加えられた最近の変更を反映していないかもしれません。 このようにシステムの安定性に影響する欠点が多くあることから、 &release.5x; 系列が十分に安定するまでの間、 リリースエンジニアリングチームは、 現在の機能性・安定性を重要視するサイトやユーザに対して 4-STABLE ブランチから公開されるリリース版を利用することを推奨しています。 4-STABLE ブランチに対する今後の予定 &os; 5.0 が公開されても、4-STABLE ブランチの開発が終了するわけではありません。 実際に、&os; 4.8-RELEASE は 5.0-RELEASE の 2 ヵ月後の 2003 年 4 月に公開されました。 このブランチからは、最低でももう 1 回のリリース、 すなわち 4.9-RELEASE が公開されるでしょう (現在は 2003 年の夏を予定しています)。 4.10-RELEASE が公開される可能性についても同様です。 4-STABLE ブランチからの将来のリリースは、いくつかの要素が絡んできます。 最も重要なのは、5-STABLE ブランチの作成と、その安定性です。 CURRENT が 5-STABLE ブランチを作成できるほどに安定していなかった場合、 リリースは 4-STABLE ブランチから作成することになるでしょう。 また 4-STABLE には、4-STABLE ブランチからの最終リリースが 告知されるまで、開発者の判断とリリースエンジニアリングの ポリシに基づいて HEAD から新機能が統合されます。 ある程度ですが、リリースエンジニアリングチームは 開発者コミュニティと同様にプロジェクト全体として、 将来の 4-STABLE リリースに対するユーザのニーズを考慮するつもりです。 ただしそのニーズは、リリースエンジニアリング作業に必要な労力・資源 (特に開発者の時間、計算機資源、ミラーアーカイブ容量) に見合ったものである必要があるでしょう。 &a.security-officer; は &os; ウェブサイトの セキュリティのページ で公開されているポリシに基づき、 4-STABLE ブランチから作成されるリリースのサポートを継続します。 セキュリティ勧告とセキュリティ上の修正がサポートするのは、 通常、各ブランチ毎に最も新しい 2 つのリリースです。 セキュリティオフィサチームは、 他のリリース版もこのルールに則ったサポートを行ないます。 &os; &release.4x; からアップグレードする際の注意点 この節では現在 &os; システムを利用している方向けに、 &os; &release.4x; システムを &release.5x; システムにアップグレードする際の 注意点について説明します。 &os; をアップグレードする場合は、アップグレードしたいバージョンの リリースノートと errata 文書を読むこと、また、 ソースからアップグレードする場合には src/UPDATING を読むことが重要です。 バイナリアップグレード おそらく最も単純な方法は、 すべてをバックアップして、再フォーマット、再インストールし、 最後にバックアップを展開することでしょう。 この方法は、互換性がなかったり、古くて使えない実行ファイルや 設定ファイルによって、新しいシステムが汚染される問題を回避することができます。 また、新規にファイルシステムを作成することによって、 デフォルトフォーマットである UFS2 の新機能の恩恵を受けることができます。 現時点の &man.sysinstall.8; のバイナリアップグレード機能は、 メジャーバージョンをまたぐアップグレードに対して 十分に試験されていません。 そのため、この機能を使うことはおすすめできません。 特に、バイナリアップグレードは &os; &release.4x; に存在して &os; &release.5x; に存在しないファイルをシステムに数多く残します。 これらの古いファイルは何らかの問題を引き起こす可能性があります。 - i386 および pc98 プラットフォームの 4-STABLE では、 + &i386; および pc98 プラットフォームの 4-STABLE では、 インストールメディアからの起動の際、 ISA デバイスの設定を起動時に変更できる UserConfig ユーティリティが利用できるようになっています。 &os; 5.0 では、この機能の一部が &man.device.hints.5; 機構に 置き換えられました(同じパラメータを指定できますが、 対話的なものではなくなっています)。 フロッピを使ったバイナリインストールには、 デバイスドライバのカーネルモジュールを含んだ 新しい 3 枚目のフロッピイメージが必要です。 この drivers.flp フロッピイメージは通常、 従来からある kern.flp や mfsroot.flp のフロッピイメージが置かれている場所と同じところに置かれています。 - i386 アーキテクチャにおける CDROM を使ったインストールでは、 + &i386; アーキテクチャにおける CDROM を使ったインストールでは、 非エミュレーション型の起動ローダを使用するようになっています。 この利点はいろいろとありますが、フロッピイメージ用に切り詰めた カーネルではなく、通常の GENERIC カーネルが 使用できるという点があげられるでしょう。 - 理論的には、Microsoft Windows NT 4 インストール CDROM + 理論的には、µsoft; &windowsnt; 4 インストール CDROM が起動できるシステムなら、&os; &release.5x; CDROM も動作するはずです。 ソースを使ったアップグレード 何はともあれ、src/UPDATING を読むことが非常に大切です。 To upgrade from 4.x-stable to current という節には、アップグレード手順がステップバイステップで書かれています。 説明されているとおり、正確に従ってください。 たまにやる人がいるのですが、 手順を飛ばしたりしてはいけません。 共通の注意点 Perl がベースシステムから削除されています。 すでに作成ずみの package から、もしくは Ports Collection から Perl をインストールしなければなりません。 以前は Perl をベースシステムの一部として構築していたため、 Perl のアップグレードが難しく、多くの問題を引き起こしていました。 ベースシステムのユーティリティで Perl を使うものは、 まだ使われているものは Perl を使わないものに書き換えられ、 使わなくなったものは削除されています。 &man.sysinstall.8; は、大部分の配布物のインストール時に、 その配布物の一部として Perl の package もインストールするようになっていますので、 この変更に気づくユーザはごく一部でしょう。 基本的に、従来の &release.4x; で使っていた実行ファイルは &release.5x; でも動作します。 ただし、これには compat4x 配布物がインストールされていることが必要です。 つまり、古い ports を使うことはおそらく可能です。 既存の 4-STABLE ベースのシステムに上書きする形でインストールや アップグレードを行なった場合は、 /usr/include にある古いヘッダファイルを削除することが非常に重要です。 バイナリインストールや installworld の前に、 このディレクトリをリネームしておくと良いでしょう。 こうしないと、(特に C++ プログラムで) コンパイラが古いヘッダと 新しいヘッダを混ぜて使用してしまい、おかしな結果になる可能性があります。 MAKEDEV がもはや提供されなくなり、 また必要なくなりました。 FreeBSD &release.5x; は、必要に応じてデバイスノードを自動的に作成する デバイスファイルシステムを利用しています。 詳細は &man.devfs.5; をご覧ください。 UFS2 が &man.newfs.8; を利用して作成するファイルシステムの デフォルトのディスクフォーマットになりました。 また、pc98 を除くすべてのプラットフォームにおいて、 &man.sysinstall.8; がディスクラベル作成画面で作成する デフォルトのファイルシステムになりました。 &os; &release.4x; は UFS1 のみを認識する (UFS2 は認識しません) ので、 &release.5x; と &release.4x; の両方がアクセスする必要のあるディスクパーティションは UFS1 で作成しなければならないことに注意してください。 これは &man.newfs.8; の オプションを利用するか &man.sysinstall.8; のディスクラベル作成画面で指示することで 指定することができます。 このような状況は、単一のマシンで &os; &release.5x; と &os; &release.4x; の双方を起動するシステムでしばしば発生します。 ディスクフォーマット間のファイルシステムを変換する方法は (バックアップして、ファイルシステムを再度作成し、 バックアップを展開する以外に) 存在しないことに注意してください。 まとめ &os; &release.current; には魅力的な機能がたくさん含まれています。 しかし現時点では、それがすべての皆さんの期待に応えられるものではないかも知れません。 この文書では、リリースエンジニアリングの背景と &release.5x; 系列の特筆すべき新機能の一部について、 初期リリースを使う上でのいくつかの欠点についてとりあげました。 また、将来の 4-STABLE 開発ブランチの計画と、 初期リリースを利用する人向けのアップグレードのヒントも説明しています。