DeveloperWiki:ゴール

導入

このページは全般的なゴールの共通点で、特定のタスクのためのものではありません。それらは DeveloperWiki:Objectives に書かれるべきで、ゴールの *後に* 構築されるべきです。このページは en:DeveloperWiki の一部です。

目的は時間とともに変わりますが、ゴールは我々全員が合意した、最も変化のないターゲットです。目的はそれらのターゲット、つまりゴールを全うし確実なものにすることを補助するためのタスクです。

現在の提案

James Rayner

• ある程度のレベルの安定性を実現することを目指しながら、実用的な範囲で最新のソフトウェアを提供する
• どのシステム機能にも特定のグラフィカルインターフェースに依存しない
• シンプルな実装で軽量で汎用のディストリビューションであることを維持する
• 強いコミュニティ指向なディストリビューションであり続ける

Roman Kyrylych

• デスクトップ・サーバー・ポータブル PC 向けの信頼できて新しい Linux 技術のセットを提供する
• 家庭・教育・SOHO・大企業での使用に等しく適切である
• ユーザー固有の目的のためにカスタマイズした Arch (ISO とリポジトリ) の亜種を作ることができる強固な基礎を提供する
• "一度インストールすればずっと動き続ける" ディストリビューションであり続ける
• よい国際化・地域化サポートを提供する

Paul Mattal

少し長いかもしれませんが、当時多くの人が Arch の理念のよい要約と考えていたものを、少し前に書かれたメールからコピーしました。今でも有効だと考えています。

• シンプルなデザイン。理由: “デバッグは始めにコードを書くより2倍難しい。つまり、可能な限りうまく書いたコードをデバッグするには、当然賢さが十分ではない。” – Brian W. Kernighan
• i686 オンリー。1つのアーキテクチャ。理由:開発者にとって物事をシンプルに保ち、我々が薄く広がりすぎることを防ぎます。少なくとも Arch がいつか他のアーキテクチャを選ばなくてはならないのは明確です。i686 は永遠には存在しません。正しく行われるのであれば、もっと多くの開発者を集めて複数のアーキテクチャをサポートする方法を探すことには反対しませんが、それぞれのアーキテクチャは、Arch の成功のためのこの重要な側面を維持するために、個別のメンテナンスチームを持つべきだと強く信じています。
• バニラ。必要な方法で組み合わせて動作するようにするための妥当なパッチと、アップストリームで修正されるまでの一時的な解決策として。これは推測可能性を作り、一般的な GNU/Linux の知識を持った賢い人々に Arch をすぐに選んでもらうことができます。時を追うごとに追加のパッチをメンテナンスする必要もありません。
• pacman による簡単なパッケージ化。恐らく Arch から去らないたった1つの理由は、pacman でパッケージを作ることの簡単さです。鈍い・複雑な・洗練されていない他の RPM spec ファイルや何か別のものを書く必要があることを考えるとうんざりします。私の仕事の助けになる新しいソフトウェアを Web 上で見つけたとき、それをパッケージ化して自分のシステムに組み込むことが普通1時間以内にできます。このシンプルさの結果、何をしようとしているか分かっているコミュニティを持ち、生産的に助けることができ、お互いに助け合えるのです。
• バイナリ配布。Gentoo と違い、十分早いマシンで十分早いリンクがあれば1分以内で Firefox をダウンロードしてインストールできます。さらに、バイナリをテストして認証するため、ユーザーのマシンの気まぐれによってコンパイルプロセスが失敗することはありません。結果は pacman -Syu の後、全てのマシンでほとんどのことが単に機能します。

"i686 オンリー" は古くなっていて、今は公式に x86_64 のサポートがあります。しかし、Arch が Debian のようにたくさんのアーキテクチャをサポートするべきではないのは明らかで、LowArch (i586) や Arch Linux PPC のようなプロジェクトは分割されてうまく管理されているでしょう。 -- Roman Kyrylych

Aaron Griffin

これは正確には我々がどこにいるかではないかもしれませんが、cactus は Arch のことを "メタディストリビューション" と呼びました。Arch は何でもしたいことをすることができるツールととてもいい基礎を提供しています。これは私が考える2つの "ゴール" と一致していると考えています。それは、(a) Andy が言っているように、とてもいい基礎的なシステムを提供して、それを大きく越えないこと、それと (b) "pacman 付きの Slackware" - Slackware に例えると、Slackware が目指しているシンプルさは我々にとっても理想的だと考えています。

eliott

私は基礎となる core パッケージにもっと焦点を当てるべきだと思います。アドオンをスタックの上に置きます。奇妙なことに、私は Arch を BSD 系の1つに例えています。BSD チームはコアの扱いに焦点を当てています。それらはシステムの電源を入れて基本的なネットワーク OS が起動するまでを扱います。その後、ports マネージャーがこのコアシステムの上にあるパッケージを扱います。 ただの考えですが。

Phil

追加することはあまりありませんが、いくつか確認したいことがあります。

• core とそれ以外の大きな違いについて、eliott と同じ意見です。
• Roman が言っているように、追加のアーキテクチャのサポートがディストリビューションに利益をもたらすとは思いません。
• 私は必要としていませんが、i18n のサポートは継続してほしいです。