(日本語)、Devlandが参考になります。Linuxに関するより多くの情報が扱われています。Archはホント好きなんだけどね。開発チームがXの機能さえ実装してくれればなぁ。Archのレビュー記事がもっと必要だ(宣伝が必要だ)。Archの開発者がもっと必要だ。Archのパッケージにはもっと適切な命名規則が必要だ。長すぎるし、ややこしい。Pacmanには他のアプリケーションがパッケージ情報を簡単に参照するためのライブラリが必要だ。Archには、安定版パッケージのbranchが必要だ。Archはもっと良いインストーラーを付けるべきだ。GUIインストーラーとか。Spellcheckを実行するとテキストが全部ミス判定されてしまうんですが。これに関してはかなりの議論があります。Archはある程度熟練したGNU/Linuxユーザーを対象にしていますが、「Archこそ入門にもってこいだ」と考えるような人もいます。あなたがビギナーでそれでもなおArchを使おうとしているのであれば、あなたは学ぶことに喜びを覚えるようでなければなりません。Archが優れて"Do-It-Yourself"なディストリビューションである、ということも肝に命じておくべきでしょう。システムを組み上げ、それをどのようなものにしていくかをコントロールするのはユーザー自身なのです。質問をする前にまず自分で調査するようにしてください。googleや、Wiki、フォーラムの検索を活用しましょう(過去のFAQも参照してください)。以上のことさえ実践していれば、それほど困難なことはありません。多くの人が同じ基本的質問に何度も繰り返して答えさせられることに嫌気がさしているのだ、ということも理解しておいてください。あなたは今その当事者なのです。伊達や酔狂でこのような文書が作成され、入門者に利用してもらえるよう設置されているわけではありません。途方もない時間がこの貴重な情報を編集するために無償で費やされているのです。Archはホント好きなんだけどね。開発チームがXの機能さえ実装してくれればなぁ。(日本語)は、読みましたか?あなたは、その機能/対処方法を提示したのですか?それは、ミニマリズムや、利便性に先んじるコードの整合性、と言ったArchの哲学と一致するでしょうか?どうぞ積極的に参加してください。あなた自身がコードや解決策を提示することでコミュニティに貢献しましょう。コミュニティや開発チームから認められれば、あなたのコードはマージされるかも知れません。Archコミュニティは、コードやツールの提供、シェアによって活性化していきます。Linuxにおけるメジャー・リリースとは、coreリポジトリの単なるスナップショットを意味するに過ぎません。これについては、インストーラ・スクリプトの様々な機能や操作抜きに語ることはできません。Linuxのシステムを、最新かつ最先端に保つものです。このことから、Archにおけるメジャー・リリースというのは、さほど重要なものではないと言えます。言って、ローリング・リリースシステムは、パッケージがアップデートされるや否や、すぐさま最新のメジャー・リリースを旧バージョンにしてしまうわけですから。Linuxのメジャー・リリースを手に入れたいと思っても、再インストールなどする必要はありません。コマンドを実行するだけで、あなたはまっさらなインストールを実行した結果構築されるそれと、同一のシステムを手に入れることになるでしょう。Linuxのリリースというのは一般的に理解されているように、真新しくてエキサイティングな機能を満載したものではありません。-Syu"のコマンドによって即座に反映されるのです。答えはYesでもあり、Noでもあります。「それは概ねあなたがどれだけそれ堅牢にするかに懸かっている」ということです。自分のArchシステムをシンプルな基本環境の上に構築するのはあなたであり、システムの成長をコントロールしていくのもあなたなのです。多くのパッケージや、色とりどりのツールキット、デスクトップ環境などを統合して、巨大に膨れ上がったシステムでは、スリムでよりシンプルなそれに比べて、アップストリーム・チェンジの影響を受けやすく、より多くの設定の問題に悩まされることになります。UNIXに関する一般的な知識や、上手なシステム管理、適切なアップグレードの実施といったものは、システムの堅牢にしていく上で、非常に大きな役割を担います。Archのパッケージの大部分はパッチを施されていないのだ、ということにも留意してください。大部分の問題は、おおよそアップストリームに起因するものです。従って、ローリング・リリースで構築された個人のシステムの堅牢性に関して、最終的な責任を負うのはユーザー自身です。ユーザーが、いつアップグレードするのかを決め、必要な時に必要な変更をマージするのです。ユーザーがコミュニティに助けを求めれば、救いの手は直ちに差し伸べられることでしょう。この点に関して、Archと他のディストリビューションで異なるのは、Archが本当に"Do-it-yourself"なディストロであることでしょう。破損についてクレームをつけるのは、見当違いであり、非生産的です。いって、アップストリーム・チェンジに関して、Arch開発チームは責任を負いかねるからです。耳にする”BSDスタイルの”initフレームワークって厳密にはどういうものなの?30年以上の歴史を持つBSDの財産の一つに、組み込みのシンプルなinitフレームワークがあります。initが姿を現すのはずっと後のことです)。initの主な特徴は、あらゆるランレベルにおける、すべてのシステム・サービスのシェルスクリプトを、ひとつのディレクトリ(/etc/rc.d/)に納め、それを一つのファイル(/etc/rc.conf/)で管理している点です。initでは、各ランレベルごとに"/etc/rc.0,1,2,3,4,5,6"のようなディレクトリが用意され、その中に複雑に入り組んだシンボリックリンクが配置されます。それぞれのサービスとシンボリックリンクは、/etc/init.d/内のシェルスクリプトを参照しています。言うまでもなく、SysV方式の方がより複雑で、各/etc/rcディレクトリ内には往々にして大量のシンボリックリンクが張られることになります。initを採用しているのです。Archのレビュー記事がもっと必要だ(宣伝が必要だ)。現状でもう十分な量のArchについての記事が書かれています。Archの目標は巨大になることではありません。シンプルさと、コードの整合性に焦点を絞った、エレガントで、最小かつ最新のディストリビューションを提供することこそが、その目標なのです。Archが対象とするユーザー・ベース自体が自然と発展しています。それを強制したところで、問題の種を蒔くことになるだけでしょう。同様に、Archの開発モデルは、自然な発展を制限するものではありません。Linuxに関わることを意味します。これによって上層部における組織的な問題が発生すこともあるかも知れませんが、それはその時に対処すれば良いことです。Archの開発者がもっと必要だ。柔軟にあなたの時間を使って貢献してください!フォーラムや、IRC、メーリング・リストなどに参加すれば、成すべきことがわかるはずです。ドキュメントの作成者などは常に需要があります。Wikiに寄稿してください。してArchは重いの?もっと軽いと思ってたのに!A)/etc/hostsが正しく設定されているか確認してください(/etc/rc.confに書かれたhostnameと一致していなければなりません。Systemの項を参照してください)。hostnameが一致していないとアプリケーションの起動が非常に遅くなる場合があります。Systemの項を参照してください。そのエラーはそもそもArch開発チームが修正できるものなのかどうかを見極めなければなりません。ない場合が往々にしてあります(Firefoxのクラッシュは大抵の場合Mozillaチームのミスです)。これをアップストリーム・エラーと言います。Archの問題であるならば以下の手順を参考に対処してください。:フォーラムに情報がないか探してみましょう。誰かが同じ問題について発言していないかチェックしてください。パッケージのメンテナに報告しましょう。name>"でメンテナに関する情報が得られます。詳細な情報を書いたバグレポートを投函してください。お望みならば、フォーラムに質問を投げてみてもよいでしょう。その際、問題の詳細と、あなたが既にバグ・レポートを送った旨を明記してください。それによって同じエラーに関する報告が大量に投函されるようなケースを回避できます。この件について議論が行われています。http://bbs.archlinux.org/viewtopic.php?id=11193http://bbs.archlinux.org/viewtopic.php?id=10898以下も参照してください。Archのパッケージにはもっと適切な命名規則が必要だ。長すぎるし、ややこしい。これに関しては、Archのメーリング・リスト上で議論されています。".pac"のような拡張子を提案する人もいますが、現段階では、パッケージの拡張子を変更する具体的な計画はありません。Kieslichの発言は示唆的です。「事実packageはgzipで圧縮されたtarballファイルなわけじゃないか!だいたいtarが扱えるアプリケーションなら何だって開くことができるし、覗いて弄ることだってできるんだしさ。Pacmanには他のアプリケーションがパッケージ情報を簡単に参照するためのライブラリが必要だ。library)のフロントエンドになっています。このライブラリは、代替のフロントエンドの開発を可能にしています(例えばGUIフロントエンドのような)。(日本語)、Devlandを読んでください。言うならArch開発者チームが提供しようと思わないからです。ユーザー達が開発したものの中からご自由に選択して使ってください。linksのセクションから辿れるUserContributionsPageでは、ユーザーが開発したGUIフロントエンドが沢山見つかります。Frontendsには選りすぐりがリストアップされています。(日本語)、Devlandを読んでください。Archの哲学は「シンプルたれ」です。あなたがご自身のアイデアにメリットがあると考え、それがくだんのシンプルのお題目を毀損しないものなら、是非フォーラムに投げて議論してください。フォーラムをちゃんとチェックしてしかるべきです。ここは重要だと思われる機能について要望を出す、まさにそのための場所なのです。Linuxに追加するために一番良い方法は、あなた自身がそれを実装することです。そのパッチがオフィシャルに取り込まれるかどうかはわかりませんが、いずれにせよあなたの骨折りは他のユーザーによって吟味され、検討されるでしょう。Archには、安定版パッケージのbranchが必要だ。A)とんでもない、二度と口に出さないことです。Repositoriesを参照してください。あなたがKDEやGNOMEのようなデスクトップ環境を導入しているのなら、そのプログラムは自動的にメニューに登録されている筈です。bin"のコマンドを実行してください。FirefoxやOpenOfficeのようなパッケージでよくこの問題にぶつかるのは、これが$PATHの通っていない/opt以下にインストールされるためです。/etc/profile"を実行するか、再ログインすることで解決するでしょう。Archはもっと良いインストーラーを付けるべきだ。GUIインストーラーとか。「良い」インストーラー云々の議論は主観の問題です。した論争に決着をつける最良の方法は、インストーラーを「Archの流儀」に合わせることでしょう。この「良いインストーラ」に関する議論がより具体的な論拠を伴うようになれば、新たなインストーラの開発が顧慮されるようなこともあるかも知れません。インストールを実行する機会自体がそもそも稀なので(メジャー・リリースに関する質問を参照)、開発者、ユーザー双方にとって優先度の高い課題ではないのです。Beginners_Guideを参照してください。確かに2、3のディストリビューションはArchと近い設計理念を持っており、同じようにミニマルなインストール・メソッドを提供してるかも知れませんが、2、3の相違は指摘しておかねばなりません:Archは骨の髄まで軽量でミニマルな環境を構築することを想定してデザインされています。imageを使うにしろ、Archはこのミニマルな基本システムから構築する以外に方法を提供していません。Stupid")の設計理念に基づいています。これによってArchのインストールシステムは対象となるユーザー・ベースとの間に、これ以上はないというくらいの親和性を獲得しています。シンプルなArchのインストーラは高度な透明性を保ったデザインとなっており、基本システムでも細かい設定が必要な部分は、ユーザー自身がマニュアル操作しなければなりません。Archは徹底的かつ完全なドキュメント群を提供しており、これによって各ユーザーのシステム構築のプロセスを一通り補助しています。エラーメッセージが言っているように、localeが正しく設定されていません。localesを参照してください。storagegnome-volume-managerが気に入らない場合は、IvmanやAutoFSを試してみましょう。Setupを参照してください。networkを参照してください。Aを参照してください。depthの設定が正しくありません。Spellcheckを実行するとテキストが全部ミス判定されてしまうんですが。aspell"を実行して、入手可能な辞書を確認しましょう。ArchWikiDisclaimers。