「DeveloperWiki:ゴール」の版間の差分
ナビゲーションに移動
検索に移動
(→James Rayner: 訳出) |
(→Phil: 訳出) |
||
| (同じ利用者による、間の5版が非表示) | |||
| 15行目: | 15行目: | ||
== Roman Kyrylych == |
== Roman Kyrylych == |
||
| + | * デスクトップ・サーバー・ポータブル PC 向けの信頼できて新しい Linux 技術のセットを提供する |
||
| − | * Provide a good set of reliable and modern Linux technologies for desktop, server and portable PCs |
||
| + | * 家庭・教育・SOHO・大企業での使用に等しく適切である |
||
| − | * Be equally suitable for home, educational, small business and corporate use |
||
| + | * ユーザー固有の目的のためにカスタマイズした Arch (ISO とリポジトリ) の亜種を作ることができる強固な基礎を提供する |
||
| − | * Provide a solid base for creating custom Arch (ISOs and repos) variants for users specific purposes |
||
| + | * "一度インストールすればずっと動き続ける" ディストリビューションであり続ける |
||
| − | * Remain a "install once, run forever" distribution |
||
| + | * よい国際化・地域化サポートを提供する |
||
| − | * Provide good i18n and l10n support |
||
== Paul Mattal == |
== Paul Mattal == |
||
| + | 少し長いかもしれませんが、当時多くの人が Arch の理念のよい要約と考えていたものを、少し前に書かれたメールからコピーしました。今でも有効だと考えています。 |
||
| − | These may be a bit long, but I've copied them in from an email written some time ago and at the time many thought they were a good summary of Arch cornerstones. I think they're still useful today. |
||
| + | * シンプルなデザイン。理由: “デバッグは始めにコードを書くより2倍難しい。つまり、可能な限りうまく書いたコードをデバッグするには、当然賢さが十分ではない。” – Brian W. Kernighan |
||
| − | * Simple design. Reasoning: “Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” – Brian W. Kernighan |
||
| + | * i686 オンリー。1つのアーキテクチャ。理由:開発者にとって物事をシンプルに保ち、我々が薄く広がりすぎることを防ぎます。少なくとも Arch がいつか他のアーキテクチャを選ばなくてはならないのは明確です。i686 は永遠には存在しません。正しく行われるのであれば、もっと多くの開発者を集めて複数のアーキテクチャをサポートする方法を探すことには反対しませんが、それぞれのアーキテクチャは、Arch の成功のためのこの重要な側面を維持するために、個別のメンテナンスチームを持つべきだと強く信じています。 |
||
| − | * i686 only. One architecture. Reasoning: It keeps things simple for the developers, and keeps us from spreading ourselves too thin. Clearly, Arch will eventually have to at least choose another architecture.. i686 won't be around forever. I'm not opposed to bringing on more developers and finding ways for us to support multiple architectures, if done correctly, but I believe strongly that each architecture should have a separate maintenance team in order for this critical aspect of Arch's success to be preserved. |
||
| + | * バニラ。必要な方法で組み合わせて動作するようにするための妥当なパッチと、アップストリームで修正されるまでの一時的な解決策として。これは推測可能性を作り、一般的な GNU/Linux の知識を持った賢い人々に Arch をすぐに選んでもらうことができます。時を追うごとに追加のパッチをメンテナンスする必要もありません。 |
||
| − | * Vanilla. As few patches as is reasonable to make things play together in the ways necessary, and then primarily as stopgap solutions until things get fixed upstream. This creates predictability and allows smart people with general GNU/Linux knowledge to pick up Arch instantly. It also keeps us from maintaining more and more custom patches over time. |
||
| + | * pacman による簡単なパッケージ化。恐らく Arch から去らないたった1つの理由は、pacman でパッケージを作ることの簡単さです。鈍い・複雑な・洗練されていない他の RPM spec ファイルや何か別のものを書く必要があることを考えるとうんざりします。私の仕事の助けになる新しいソフトウェアを Web 上で見つけたとき、それをパッケージ化して自分のシステムに組み込むことが普通1時間以内にできます。このシンプルさの結果、何をしようとしているか分かっているコミュニティを持ち、生産的に助けることができ、お互いに助け合えるのです。 |
||
| − | * Easy packaging with pacman. The SINGLE thing that will probably keep me from ever leaving Arch is how simple it is to create packages with Pacman. The thought of ever having to write another RPM spec file or something else as obtuse or complicated or ill-conceived as that makes me want to toss my lunch. When I find new software on the Web to help me do my work, I can have it packaged and integrated into my bag of tricks usually in less than an hour. As a result of this simplicity, we have a Community who understands what's going on and can be productively helpful and supportive of each other. |
||
| + | * バイナリ配布。Gentoo と違い、十分早いマシンで十分早いリンクがあれば1分以内で Firefox をダウンロードしてインストールできます。さらに、バイナリをテストして認証するため、ユーザーのマシンの気まぐれによってコンパイルプロセスが失敗することはありません。結果は pacman -Syu の後、全てのマシンでほとんどのことが単に機能します。 |
||
| − | * Binary distribution. Unlike Gentoo, we can download and install Firefox on a reasonably fast machine with a reasonably fast link in less than a minute. Also, we test and certify binaries, so quirks of people's machines don't bugger up their compile processes. The result is that after a pacman -Syu, on any machine, most things just work. |
||
| − | |||
| − | : "i686 only" is a outdated now as we have official x86_64 too. However, it's obvious that Arch shouldn't support as many archs as Debian, and projects like LowArch (i586) and probably Arch Linux PPC will be better managed separately. -- Roman Kyrylych |
||
| + | : "i686 オンリー" は古くなっていて、今は公式に x86_64 のサポートがあります。しかし、Arch が Debian のようにたくさんのアーキテクチャをサポートするべきではないのは明らかで、LowArch (i586) や Arch Linux PPC のようなプロジェクトは分割されてうまく管理されているでしょう。 -- Roman Kyrylych |
||
== Aaron Griffin == |
== Aaron Griffin == |
||
| + | これは正確には我々がどこにいるかではないかもしれませんが、cactus は Arch のことを "メタディストリビューション" と呼びました。Arch は何でもしたいことをすることができるツールととてもいい基礎を提供しています。これは私が考える2つの "ゴール" と一致していると考えています。それは、(a) Andy が言っているように、とてもいい基礎的なシステムを提供して、それを大きく越えないこと、それと (b) "pacman 付きの Slackware" - Slackware に例えると、Slackware が目指しているシンプルさは我々にとっても理想的だと考えています。 |
||
| − | This might not be exactly where or what we are, but cactus once called Arch a "meta distribution". That is, it gives you tools and a very nice base with which you can do whatever you want. I think this also coincides with 2 of the "goals" I would like to see - that is, (a) like Andy said, we provide a very nice base system and not much more, and (b) "Slackware with pacman" - we get likened to Slackware enough, and I think the simplicity that Slackware strives for is ideal for us as well. |
||
== eliott == |
== eliott == |
||
| + | 私は基礎となる core パッケージにもっと焦点を当てるべきだと思います。アドオンをスタックの上に置きます。奇妙なことに、私は Arch を BSD 系の1つに例えています。BSD チームはコアの扱いに焦点を当てています。それらはシステムの電源を入れて基本的なネットワーク OS が起動するまでを扱います。その後、ports マネージャーがこのコアシステムの上にあるパッケージを扱います。 |
||
| − | I say focus more on the core packages, the underlying fundamentals. Push the addons higher into the stack. I liken Arch to one of the BSD's, oddly enough. The BSD team focuses on handling the core. They deal with things that come about when the system goes from poweroff to running a base network OS. Then ports managers handle the packages that lay on top of this core system. |
||
| + | ただの考えですが。 |
||
| − | Just a thought. |
||
== Phil == |
== Phil == |
||
| + | 追加することはあまりありませんが、いくつか確認したいことがあります。 |
||
| − | Not got much to add but some point I'd like to ack: |
||
| + | * core とそれ以外の大きな違いについて、eliott と同じ意見です。 |
||
| − | * I'm with eliott regarding a bigger differentiation between core and everything else. |
||
| + | * Roman が言っているように、追加のアーキテクチャのサポートがディストリビューションに利益をもたらすとは思いません。 |
||
| − | * I also don't think commitments to further architectures will benefit the distro, as Roman said |
||
| + | * 私は必要としていませんが、i18n のサポートは継続してほしいです。 |
||
| − | * I'd also like to see continued support for i18n, even though i don't need it. |
||
2020年7月11日 (土) 12:31時点における最新版
目次
導入
このページは全般的なゴールの共通点で、特定のタスクのためのものではありません。それらは 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 のサポートは継続してほしいです。