「FAQ」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
(Pkg/AUR テンプレートの更新)
(英語版から同期)
2行目: 2行目:
 
[[ar:Frequently asked questions]]
 
[[ar:Frequently asked questions]]
 
[[bg:Frequently asked questions]]
 
[[bg:Frequently asked questions]]
  +
[[bs:Frequently asked questions]]
 
[[cs:Frequently asked questions]]
 
[[cs:Frequently asked questions]]
 
[[da:Frequently asked questions]]
 
[[da:Frequently asked questions]]
9行目: 10行目:
 
[[es:Frequently asked questions]]
 
[[es:Frequently asked questions]]
 
[[fa:سؤالات متداول]]
 
[[fa:سؤالات متداول]]
[[fi:FAQ]]
+
[[fi:Frequently asked questions]]
 
[[fr:FAQ]]
 
[[fr:FAQ]]
 
[[hr:Frequently asked questions]]
 
[[hr:Frequently asked questions]]
  +
[[hu:Frequently asked questions]]
 
[[id:Frequently asked questions]]
 
[[id:Frequently asked questions]]
 
[[it:Frequently asked questions]]
 
[[it:Frequently asked questions]]
17行目: 19行目:
 
[[lt:Frequently asked questions]]
 
[[lt:Frequently asked questions]]
 
[[nl:Frequently asked questions]]
 
[[nl:Frequently asked questions]]
  +
[[pl:Frequently asked questions]]
 
[[pt:Frequently asked questions]]
 
[[pt:Frequently asked questions]]
[[ro:Întrebări frecvente]]
 
 
[[ru:Frequently asked questions]]
 
[[ru:Frequently asked questions]]
 
[[sk:Frequently asked questions]]
 
[[sk:Frequently asked questions]]
 
[[sv:FAQ]]
 
[[sv:FAQ]]
 
[[th:Frequently asked questions]]
 
[[th:Frequently asked questions]]
[[tr:Sss]]
+
[[tr:Frequently asked questions]]
 
[[zh-hans:Frequently asked questions]]
 
[[zh-hans:Frequently asked questions]]
 
[[zh-hant:Frequently asked questions]]
 
[[zh-hant:Frequently asked questions]]
31行目: 33行目:
 
{{Related|一般的なトラブルシューティング}}
 
{{Related|一般的なトラブルシューティング}}
 
{{Related articles end}}
 
{{Related articles end}}
ここで解決されない問題等については,[[The Arch Way]],[[Arch Linux]] が参考になります.そこでは Arch Linux に関するより多くの情報が扱われています.
 
   
 
==一般==
 
==一般==
37行目: 38行目:
 
=== Arch Linux って何ですか? ===
 
=== Arch Linux って何ですか? ===
 
[[Arch Linux]] を参照してください。
 
[[Arch Linux]] を参照してください。
 
=== 私は Arch を使うべきですか? ===
 
あなたが [[The Arch Way]] の理念に賛同し、'do-it-yourself' なアプローチを受け入れることができて、そして、シンプルで、エレガントで、高いカスタマイズ性を持ち、最先端の汎用 GNU/Linux ディストリビューションをお探しなら、Arch が気に入るかもしれません。
 
   
 
=== 私は Arch を使うべきではありませんか? ===
 
=== 私は Arch を使うべきではありませんか? ===
  +
以下のような方は Arch を使いたいとは思わないでしょう:
あなたが [[The Arch Way]] の理念に賛同できず、'do-it-yourself' な GNU/Linux ディストリビューションを使う能力や時間がない、あるいはそれを求めていないなら、Arch はあなた向けではないかもしれません。
 
  +
* 'do-it-yourself' な GNU/Linux ディストリビューションを使う能力や時間がない、あるいはそれを求めていない方。
 
また、以下のような方も Arch を使いたいとは思わないでしょう:
 
 
* x86_64 以外のアーキテクチャのサポートが必要な方。
 
* x86_64 以外のアーキテクチャのサポートが必要な方。
 
* GNU で定義されたフリーウェアのみを提供するディストリビューションを使うことに強いこだわりのある方。
 
* GNU で定義されたフリーウェアのみを提供するディストリビューションを使うことに強いこだわりのある方。
50行目: 47行目:
 
* 最先端で、ローリングリリースな GNU/Linux を求めていない方。
 
* 最先端で、ローリングリリースな GNU/Linux を求めていない方。
 
* 今使っている OS に満足している方。
 
* 今使っている OS に満足している方。
 
=== Arch はどのディストリビューションベースなんですか? ===
 
Arch は独自に開発され、他のいかなる GNU/Linux ディストリビューションもベースとしていません。Arch を製作する以前、Judd Vinet は Per Lidén による優れた最小主義ディストリビューションである CRUX を賞賛し使用していました。当初は CRUX と同様のアイデアに触発された Arch ですが、スクラッチビルドされており、[[pacman]] は C 言語で開発されました。
 
   
 
=== Arch はどのアーキテクチャをサポートしていますか? ===
 
=== Arch はどのアーキテクチャをサポートしていますか? ===
Arch は x86_64 (別名 amd64) アーキテクチャのみをサポートしています。i686 のサポートは2017年11月に切られました [https://www.archlinux.jp/news/the-end-of-i686-support/]。x86_64 の CPU を搭載しているコンピュータで i686 版の Arch を使用している場合は[[#再インストールせずに i686 環境から x86_64 環境にアップグレード出来ますか?]]を見てください。32ビットマシンの場合は [https://archlinux32.org/ Arch Linux 32] に切り替えるという方法があります
+
Arch は x86_64 (別名 amd64) アーキテクチャのみをサポートしています。i686 のサポートは2017年11月に切られました [https://www.archlinux.jp/news/the-end-of-i686-support/]。
   
  +
There are ''unofficial'' ports for the i686 architecture [https://archlinux32.org/] and [[Wikipedia:ARM architecture|ARM]] CPUs [http://archlinuxarm.org/], each with their own community channels. [http://ix.io/73w/irc]
=== Arch は ARM CPU をサポートしていますか? ===
 
いいえ、ただし [https://archlinuxarm.org/ Arch Linux ARM] プロジェクトによって Arch Linux が ARM プラットフォームに移植されています。
 
   
=== Arch は [http://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html FHS] に準拠していますか? ===
+
=== Arch は Linux Foundation の標準ファイルシステム階層 (FHS) に準拠していますか? ===
Arch Linux は [[systemd]] サービスマネージャを使用するオペレーティングシステムの''ファイルシステム階層''を遵守しています。ディレクトリの説明については {{man|7|file-hierarchy}} を見てください。特に Arch では {{ic|/bin}}, {{ic|/sbin}}, {{ic|/usr/sbin}} は {{ic|/usr/bin}} のシンボリックリンクに、{{ic|/lib}} と {{ic|/lib64}} は {{ic|/usr/lib}} のシンボリックリンクになっています。[[Arch ファイルシステム階層]]も参照してください
+
Arch Linux は [[systemd]] サービスマネージャを使用するオペレーティングシステムの''ファイルシステム階層''を遵守しています。ディレクトリの説明については {{man|7|file-hierarchy}} を見てください。特に Arch では {{ic|/bin}}, {{ic|/sbin}}, {{ic|/usr/sbin}} は {{ic|/usr/bin}} のシンボリックリンクに、{{ic|/lib}} と {{ic|/lib64}} は {{ic|/usr/lib}} のシンボリックリンクになっています。
   
 
=== 当方全くの GNU/Linux ビギナーなのですが、Arch を使って大丈夫でしょうか? ===
 
=== 当方全くの GNU/Linux ビギナーなのですが、Arch を使って大丈夫でしょうか? ===
これに関してはかなりの議論があります。Arch はある程度熟練した GNU/Linux ユーザーを対象にしていますが、やる気のある初心者には Arch こそもってこいだ、と考えるような人もいます。もしあなたが初心者で、それでもなお Arch を使おうとしているのであれば、あなたは十分な時間を費やして学ぶことに喜びを覚えるようでなければなりません。また Arch が全く "Do-It-Yourself" なディストリビューションとして設計されている、ということも肝に命じておくべきでしょう。システムを組み上げ、それをどのようなものにしていくかをコントロールするのはユーザー自身なのです。質問をする前にまず自分で調査するようにしてください。Google やフォーラム、そして素晴らしいドキュメントが用意されている Arch Wiki の検索を活用しましょう (以下のFAQも参照してください)。以上のことさえ実践していれば、それほど困難なことはありません。また、多くの人が同じ基本的質問に何度も繰り返して答えさせられることに嫌気がさしているのだ、ということも理解しておいてください。あなたは今まさにその当事者なのです。伊達や酔狂でこのような文書が作成され、入門者に利用してもらえるよう設置されているわけではありません。途方もない時間がこの貴重な情報を編集するために無償で費やされているのです。[[Arch 用語集#RTFM]] も見てください
+
もしあなたが初心者で、それでもなお Arch を使おうとしているのであれば、あなたは十分な時間を費やして学ぶことに喜びを覚えるようでなければなりません。また Arch が全く "Do-It-Yourself" なディストリビューションとして設計されている、ということも肝に命じておくべきでしょう。システムを組み上げ、それをどのようなものにしていくかをコントロールするのはユーザー自身なのです。
   
  +
質問をする前にまず自分で調査するようにしてください。Google やフォーラム、そして素晴らしいドキュメントが用意されている Arch Wiki の検索を活用しましょう。''There is a reason these resources were made available to you in the first place.'' 途方もない時間がこの貴重な情報を編集するために無償で費やされているのです。
=== Arch を使うにはとても手間暇がかかるし、コミュニティはといえば、なにかと言うと RTFM って言うし ===
 
  +
Arch は特定のユーザベースを対象にして設計され、利用されています。おそらくそれがあなたには合っていないのでしょう。[[#当方全くの GNU/Linux ビギナーなのですが、Arch を使って大丈夫でしょうか?|上のセクション]]も参照してください。
 
  +
[[Arch 用語集#RTFM]] や [[インストールガイド]] も見てください。
   
 
=== Arch はどの用途向けに設計されていますか?サーバですか?デスクトップですか?ワークステーションですか? ===
 
=== Arch はどの用途向けに設計されていますか?サーバですか?デスクトップですか?ワークステーションですか? ===
73行目: 67行目:
   
 
=== Arch はホント好きなんだけどね.開発チームがXの機能さえ実装してくれればなぁ ===
 
=== Arch はホント好きなんだけどね.開発チームがXの機能さえ実装してくれればなぁ ===
ちょっと待った.ちゃんと [[The Arch Way]] は,読みましたか? あなたはその機能/対処方法を提示してみたのですか? それは''ミニマリズム''や,''利便性に先んじるコードの整合性''と言ったArchの哲学と一致するでしょうか? どうぞ積極的に参加してください.あなた自身がコードや解決策を提示することでコミュニティに貢献しましょう.もし,コミュニティや開発チームから認められれば,あなたのコードはマージされるかも知れません.Archコミュニティはコードやツールの提供,シェアによって活性化していきます.
+
どうぞ積極的に参加してください.あなた自身がコードや解決策を提示することでコミュニティに貢献しましょう.もし,コミュニティや開発チームから認められれば,あなたのコードはマージされるかも知れません.Archコミュニティはコードやツールの提供,シェアによって活性化していきます.
   
=== いつ新しいメジャー・リリースが出るんでしょうか? ===
+
=== いつ新しいリリースが出るんでしょうか? ===
Arch Linux におけるメジャーリリースは各月の前半頃公開されますが、これはインストールおよびレスキュー用のライブ環境で、{{Pkg|base}} グルとその他いくつかの [https://projects.archlinux.org/archiso.git/tree/configs/releng/packages.both パッケージ]が含まれています。
+
Arch Linux におけるリリースはにインストールおよびレスキュー用のライブ環境で、{{Pkg|base}} メタパッケとその他いくつかの [https://projects.archlinux.org/archiso.git/tree/configs/releng/packages.x86_64 パッケージ]が含まれています。リリースは通常各月の前半頃に公開されます。
 
ローリングリリースモデルは、ひとつのコマンド操作によってあらゆる Arch Linux のシステムを最新かつ最先端に保つものです。このことから、Arch におけるメジャーリリースというのはさほど重要な意味を持つものではないと言えます、なぜと言ってローリングリリースシステムは、パッケージがアップデートされるや否や、すぐさま最新のメジャーリリースを旧バージョンにしてしまうわけですから。最新の Arch Linux のメジャーリリースを手に入れたいと思っても、再インストールなどする必要はありません。単にコマンド {{ic|pacman -Syu}} を実行するだけで、あなたのシステムは新規インストールしたのと同様に最新になります。また同じ理由から、新しい Arch Linux のリリースというのは、一般的に理解されているような、真新しくてエキサイティングな機能を満載したものにはなりません。そうした真新しくエキサイティングな機能群のリリースは、必要に応じたパッケージのアップデートによってもたらされるものであり、それは {{ic|pacman -Syu}} のコマンドによって即座に反映されるのです。
 
   
 
=== Arch Linux は堅牢なディストリなのでしょうか?しょっちゅう壊れたりしませんか? ===
 
=== Arch Linux は堅牢なディストリなのでしょうか?しょっちゅう壊れたりしませんか? ===
  +
ローリングリリースで構築された個人のシステムの堅牢性に関して、最終的な責任を負うのは''ユーザー自身''です。ユーザーがいつアップグレードするのかを決め、必要な時に必要な変更をマージするのです。もしユーザーがコミュニティに助けを求めれば、救いの手はすぐに差し伸べられることが多いでしょう。この点に関して、Arch が他のディストリビューションから異なっているのは、Arch が本当に "Do-it-yourself" なディストロであることでしょう。破損についてクレームをつけるのは見当違いであり、非生産的です。アップストリームでの変更に関して Arch 開発チームは責任を負いかねるからです。
一言で言うと、それは概ね「''あなた''次第」だということです。
 
  +
See the [[en2:System maintenance]] article for tips on how to make an Arch Linux system as stable as possible.
 
自分の Arch システムをシンプルな基本環境の上に構築するのは''あなた''であり,システムの成長をコントロールしていくのも''あなた''なのです。当然、多くのカスタマイズパッケージや、色とりどりのツールキット、デスクトップ環境などを統合して巨大に膨れ上がったシステムでは、スリムでよりシンプルなそれに比べてアップストリームの変更による影響を受けやすく、より多くの設定の問題に悩まされることになります。UNIX に関する一般的な知識や、上手なシステム管理、適切なアップグレードの実施といったものは、システムを堅牢にしていく上で非常に大きな役割を担います。Arch のパッケージの大部分はパッチを施されていないのだ、ということにも留意してください。大部分の問題はおおよそアップストリームに起因するものです。
 
 
従って、ローリングリリースで構築された個人のシステムの堅牢性に関して、最終的な責任を負うのは''ユーザー自身''です。ユーザーがいつアップグレードするのかを決め、必要な時に必要な変更をマージするのです。もしユーザーがコミュニティに助けを求めれば、救いの手は直ちに差し伸べられることでしょう。この点に関して、Arch が他のディストリビューションから異なっているのは、Arch が本当に "Do-it-yourself" なディストロであることでしょう。破損についてクレームをつけるのは見当違いであり、非生産的です。なぜといって、アップストリームでの変更に関して Arch 開発チームは責任を負いかねるからです。
 
   
 
=== Archのレビュー記事がもっと必要だ(宣伝が必要だ) ===
 
=== Archのレビュー記事がもっと必要だ(宣伝が必要だ) ===
現状でもう十分な量のArchについての記事が書かれています.Archの目標は巨大になることではなく、シンプルさと,コードの整合性に焦点を絞った,エレガントで,最小かつ最新のディストリビューションを提供することなのです.Archが対象とするユーザー・ベース自体が自然と発展しています.
+
現状でもう十分な量のArchについての記事が書かれています.Archの目標は巨大になることではなく; rather, organic, sustainable growth occurs naturally amongst the target user base.
   
 
=== Archの開発者がもっと必要だ ===
 
=== Archの開発者がもっと必要だ ===
そうかも知れませんね.もっと柔軟にあなたの時間を使って貢献してください! [https://bbs.archlinux.jp/ フォーラム]や,[[IRC チャンネル|IRC]],[https://lists.archlinux.org/listinfo/ メーリングリスト]などに参加すれば,成すべきことがわかるはずです.まずは、Community Contributions サブフォーラムに参加してみてください.
+
そうかも知れませんね.もっと柔軟にあなたの時間を使って貢献してください! [https://bbs.archlinux.jp/ フォーラム]や,[[IRC チャンネル]],[https://mailman.archlinux.org/mailman/listinfo/ メーリングリスト]などに参加すれば,成すべきことがわかるはずです.まずは、Community Contributions サブフォーラムに参加してみてください.
   
 
=== 他のOSに比べてインターネットの速度が遅いんだけど、どうして? ===
 
=== 他のOSに比べてインターネットの速度が遅いんだけど、どうして? ===
 
ネットワークは正しく設定されていますか?[[ネットワーク設定]]のページを参照してください。
 
ネットワークは正しく設定されていますか?[[ネットワーク設定]]のページを参照してください。
   
また、Arch ではデフォルトで[[Wikipedia:ja:トラフィックシェーピング|トラフィックシェーピング]]が有効になっていないことも注意してださい。従って、ネットワーク帯域を活用するプログラムによって改善する可能性があります。Shorewall や Vuurmuur などの[[ファイアウォール]] (これらは {{Pkg|iproute2}} のスクリプトでもあります) によってネットワークレイヤーのシェーピングを行うことができます。
+
また、Arch ではデフォルトで[[Wikipedia:ja:トラフィックシェーピング|トラフィックシェーピング]]が有効になっていないことも注意してださい。従って、it is possible that if a program on it somehow utilizes your internet connection to the full – regardless if it is over P2P or classic client-server connections – other local ones will find it clogged, resulting in severe lags and timeouts. Shorewall や Vuurmuur などの[[ファイアウォール]]; there are also static scripts for {{Pkg|iproute2}} (such as [http://serendipity.ruwenzori.net/index.php/2008/06/01/modified-wondershaper-for-better-voip-qos this derivative] of ''Wondershaper'') によってネットワークレイヤーのシェーピングを行うことができます。
   
 
=== なんで Arch は RAM を全部使っちゃうわけ? ===
 
=== なんで Arch は RAM を全部使っちゃうわけ? ===
 
そもそも、使わない RAM は無駄な RAM です。
 
そもそも、使わない RAM は無駄な RAM です。
   
新米ユーザの方の多くは、Linux カーネルのメモリの扱い方がそれ使われ方と必ずしも同じにはならないことに気がつきます。RAM 上のデータへのアクセスはディスクに比べ非常に高速なので、カーネルは最近アクセスされたデータをメモリ上にキャッシュします。キャッシュされたデータは利用可能なメモリを使い果たした時のみクリアされ、新しいデータは必要に応じてロードされます。
+
新米ユーザの方の多くは、Linux カーネルのメモリの扱い方が以前の方と必ずしも同じにはならないことに気がつきます。RAM 上のデータへのアクセスはディスクに比べ非常に高速なので、カーネルは最近アクセスされたデータをメモリ上にキャッシュします。キャッシュされたデータは利用可能なメモリを使い果たし、新しいデータロードされる必要のある時のみクリアされます。
   
  +
We could distinguish the difference from {{ic|free}} command:
この混乱のもっとも一般的な原因は、おそらく {{ic|free}} コマンドにあるでしょう:
 
   
{{hc|$ free -m|
+
{{hc|$ free -h|
total used free shared buffers cached
+
total used free shared buff/cache available
Mem: 1009 741 267 0 104 359
+
Mem: 2.8G 1.1G 283M 224M 1.4G 1.2G
-/+ buffers/cache: 278 731
+
Swap: 3.0G 881M 2.1G
  +
}}
Swap: 1537 0 1537}}
 
   
  +
It is important to note the difference between "free" and "available" memory. In the above example, a laptop with 2.8G of total RAM appears to be using most of it, with only 283M as free memory. However, 1.4G of it is "buff/cache". There is still 1.2G available for starting new applications, without swapping. See {{ic|man free(1)}} for detail. The result of all this? Performance!
{{ic|-/+ buffers/cache:}} の行に注目してください —— メモリ量の表現は、実際には「現在使用中」と「利用可能」なメモリ量であり、「未使用」なのではありません。
 
   
  +
もしあなたの好奇心が刺激されたなら、[https://www.linuxjournal.com/article/2770 こちらの素晴らしい記事]も読んでみてください。こちらのウェブサイトでもこの混乱を整理して説明しています: http://www.linuxatemyram.com/
上記の例では、1GB の RAM を積んだラップトップで、アイドル状態のターミナルとウェブブラウザを開いただけでその 741MB を使用しています! しかし、上記の "-/+ buffers/cache:" で始まる行を見てください。「現在使用中」なのは 278MB に過ぎません。実際には 731MB は新しいデータのために「利用可能」なのです。一見すると、「使用中」メモリの内の 104MB がバッファデータであり、359MB がキャッシュデータであるかのように見えてしまいますが、それぞれは必要なときにクリアされます。全メモリ中の 267MB のみが真の意味で「free」なのです。
 
 
もしあなたの好奇心が刺激されたなら、[https://www.linuxjournal.com/article/2770 こちらの素晴らしい記事]も読んでみてください。
 
 
こちらのウェブサイトでもこの混乱を整理して説明しています: http://www.linuxatemyram.com/
 
   
 
=== わたしのディスクの空き領域はどこへ行ってしまったの? ===
 
=== わたしのディスクの空き領域はどこへ行ってしまったの? ===
124行目: 109行目:
 
==パッケージ管理==
 
==パッケージ管理==
   
  +
See the [[pacman]], [[en2:pacman/Tips and tricks]] and [[en2:Official repositories]] pages for more answers.
=== ファイル〇〇はどのパッケージに含まれていますか? ===
 
{{Pkg|pkgfile}} コマンドで確認できます。
 
 
例:
 
{{hc|$ pkgfile glxinfo|extra/mesa-demos}}
 
   
 
=== Xのパッケージにエラーがあったんだけど,どうしたらいいの? ===
 
=== Xのパッケージにエラーがあったんだけど,どうしたらいいの? ===
まず,そのエラーはそもそもArch開発チームが修正できるものなのかどうかを見極めなければなりません.そうでない場合が往々にしてあります(例えばFirefoxのクラッシュは大抵の場合Mozillaチームのミスです).これをアップストリーム・エラーと言います.もしArchの問題であるならば以下の手順を参考に対処してください.:
+
まず,そのエラーはそもそもArch開発チームが修正できるものなのかどうかを見極めなければなりません.そうでない場合が往々にしてあります(例えばFirefoxのクラッシュは大抵の場合Mozillaチームのミスです).これを ''アップストリーム・エラー'' と言います.もしArchの問題であるならば以下の手順を参考に対処してください.:
#フォーラムに情報がないか探してみましょう.誰かが同じ問題について発言していないかチェックしてください.
+
# フォーラムに情報がないか探してみましょう.誰かが同じ問題について気付いていないかチェックしてください.
#詳細な情報を書いたバグレポートを[https://bugs.archlinux.org 投函]してください.
+
# 詳細な情報を書いた[[バグ報告ガイドライン|バグレポート]] https://bugs.archlinux.org 稿してください.
#もしお望みならば,フォーラムに質問を投げてみてもよいでしょう.その際,問題の詳細と,あなたが既にバグ・レポートを送った旨を明記してください.それによって同じエラーに関する報告が大量に投されるようなケースを回避できます.
+
# もしお望みならば,フォーラムに質問を投げてみてもよいでしょう.その際,問題の詳細と,あなたが既にバグ・レポートを送った旨を明記してください.それによって同じエラーに関する報告が大量に投稿されるようなケースを回避できます.
   
 
=== Archのパッケージにはもっと適切な命名規則が必要だ。".pkg.tar.gz" とか ".pkg.tar.xz" なんて長すぎるし、ややこしい ===
 
=== Archのパッケージにはもっと適切な命名規則が必要だ。".pkg.tar.gz" とか ".pkg.tar.xz" なんて長すぎるし、ややこしい ===
140行目: 121行目:
   
 
=== Pacman には他のアプリケーションがパッケージ情報を簡単に参照するためのライブラリが必要だ ===
 
=== Pacman には他のアプリケーションがパッケージ情報を簡単に参照するためのライブラリが必要だ ===
バージョン3.0.0以降、[[pacman]] は libalpm ("Arch Linux Package Management" library) のフロントエンドになっています。このライブラリは代替のフロントエンドの開発を可能にしています (例えばGUIフロントエンドのような)。
+
[[pacman]] は [https://www.archlinux.org/pacman/libalpm.3.html libalpm] ("Arch Linux Package Management" library) のフロントエンドになっています。このライブラリは代替のフロントエンドの開発を可能にしています (例えばGUIフロントエンドのような)。
 
=== どうして Pacman にはオフィシャルの GUI フロントエンドがないの? ===
 
[[The Arch Way]],[[Arch Linux]] を読んでください.強いて言うならArch開発者チームが提供しようと思わないからです.ユーザー達が開発したものの中からご自由に選択して使ってください.[[Pacman GUI フロントエンド]]には選りすぐりがリストアップされています.
 
   
 
=== Pacman に X の機能を付けるべきだ! ===
 
=== Pacman に X の機能を付けるべきだ! ===
  +
If you think an idea has merit, you may choose to discuss it on [https://lists.archlinux.org/listinfo/pacman-dev/ pacman-dev]. Also check https://bugs.archlinux.org/index.php?project=3 for existing feature requests.
[[The Arch Way]],[[Arch Linux]]を読んでください.Archの哲学は「シンプルたれ」です.もしあなたがご自身のアイデアにメリットがあると考え,それがくだんのシンプルのお題目を毀損しないものなら,是非フォーラムに投げて議論してください.また,フォーラムをちゃんとチェックしてしかるべきです.ここは重要だと思われる機能について要望を出す,まさにそのための場所なのです.
 
   
 
もっとも,ある機能をPacmanやArch Linuxに追加するために一番良い方法は,あなた自身がそれを実装することです.そのパッチがオフィシャルに取り込まれるかどうかはわかりませんが,いずれにせよあなたの骨折りは他のユーザーによって吟味され,検討されるでしょう.
 
もっとも,ある機能をPacmanやArch Linuxに追加するために一番良い方法は,あなた自身がそれを実装することです.そのパッチがオフィシャルに取り込まれるかどうかはわかりませんが,いずれにせよあなたの骨折りは他のユーザーによって吟味され,検討されるでしょう.
 
=== Arch には,安定版パッケージの branch が必要だ ===
 
何事にも絶対はありません。これに関してはいくつかの議論があります:<br>
 
https://bbs.archlinux.org/viewtopic.php?id=11288
 
 
また、より安定したサーバ運用のためのコミュニティプロジェクト [http://www.archserver.org/ ArchServer]{{dead link|2014|04|04}} もあります。
 
 
=== 数種のリポジトリがありますが,どんな違いがあるんでしょうか? ===
 
[[公式リポジトリ]] を参照してください.
 
   
 
=== X のパッケージをインストールしたんだけど,どうやって起動するの? ===
 
=== X のパッケージをインストールしたんだけど,どうやって起動するの? ===
あなたが KDE や GNOME のようなデスクトップ環境を導入しているのなら、そのプログラムは自動的にメニューに登録されている筈です。ターミナルから起動しようとしていて、バイナリの名前がわからないというような場合は、次のコマンドで確認してください:
+
あなたが [[KDE]][[GNOME]] のようなデスクトップ環境を導入しているのなら、そのプログラムは自動的にメニューに登録されている筈です。ターミナルから起動しようとしていて、バイナリの名前がわからないというような場合は、次のコマンドで確認してください:
   
 
$ pacman -Qlq ''パッケージ名'' | grep /usr/bin/
 
$ pacman -Qlq ''パッケージ名'' | grep /usr/bin/
168行目: 137行目:
 
Debian などの一部のディストリビューションは、共用ライブラリパッケージにおいて {{ic|libfoo1}}、{{ic|libfoo2}}、{{ic|libfoo3}} といったように複数のバージョンを用意しています。この方法では同一のシステム上で異なるバージョンの libfoo ごとにアプリケーションのコンパイルが可能となります。
 
Debian などの一部のディストリビューションは、共用ライブラリパッケージにおいて {{ic|libfoo1}}、{{ic|libfoo2}}、{{ic|libfoo3}} といったように複数のバージョンを用意しています。この方法では同一のシステム上で異なるバージョンの libfoo ごとにアプリケーションのコンパイルが可能となります。
   
Debian と異なり、Arch はローリングリリースで最先端のディストリビューションです。最先端のディストリビューションの最大の特徴はそのリポジトリから最新バージョンのソフトウェアが入手可能であることです。Arch のようなディストリビューションの場合、すべてのパッケージで公式にサポートされているのは最新バージョンのみであることを意味します。過去のソフトウェアをサポートしないことで、パッケージメンテナは新しいバージョンの作業に割く時間をより多くとることができます。共有ライブラリの新しいバージョンがアップストリームからリリースされると、それはすぐにリポジトリに追加され、影響を受けるパッケージは新しいライブラリに合わせてリビルドされます。
+
Arch のようなディストリビューションの場合、すべてのパッケージで公式にサポートされているのは最新バージョンのみであることを意味します。過去のソフトウェアをサポートしないことで、パッケージメンテナはensuring that the newest versions work as expectedに割く時間をより多くとることができます。共有ライブラリの新しいバージョンがアップストリームからリリースされると、それはすぐにリポジトリに追加され、影響を受けるパッケージは新しいライブラリに合わせてリビルドされます。
   
 
=== もし、システム全体のアップグレード({{ic|pacman -Syu}})で共用ライブラリがアップデートされたのにそれに依存するアプリケーションがアップデートされなかったらどうなりますか? ===
 
=== もし、システム全体のアップグレード({{ic|pacman -Syu}})で共用ライブラリがアップデートされたのにそれに依存するアプリケーションがアップデートされなかったらどうなりますか? ===
   
それは起こってはならないシナリオです。公式リポジトリに {{ic|foobaz}} というアプリケーションがあり、{{ic|libbaz}} という共用ライブラリの新バージョンを使用してビルドされているとして、それは {{ic|libbaz}} のアップデートに合わせてアップデートされます。しかしもし、それがうまくいかない場合、そのパッケージ {{ic|foobaz}} にはバージョン制限のある依存関係 (例: libbaz=1.5) が指定され、{{ic|libbaz}} のアップグレードの際に pacman によってコンフリクトを理由に削除されます。
+
それは起こってはならないシナリオです。公式リポジトリに {{ic|foobaz}} というアプリケーションがあり、{{ic|libbaz}} という共用ライブラリの新バージョンを使用してビルドされているとして、それは {{ic|libbaz}} のアップデートに合わせてアップデートされます。しかしもし、if it does not build successfully、そのパッケージ {{ic|foobaz}} にはバージョン制限のある依存関係 (例: libbaz=1.5) が指定され、{{ic|libbaz}} のアップグレードの際に pacman によってコンフリクトを理由に削除されます。
   
 
もし {{ic|foobaz}} が、あなた自身でビルドした、あるいは AUR からインストールしたパッケージであった場合には、新バージョンの {{ic|libbaz}} で {{ic|foobaz}} をリビルドしてみてください。ビルドが失敗した場合には {{ic|foobaz}} の開発者にそのバグを報告してください。
 
もし {{ic|foobaz}} が、あなた自身でビルドした、あるいは AUR からインストールしたパッケージであった場合には、新バージョンの {{ic|libbaz}} で {{ic|foobaz}} をリビルドしてみてください。ビルドが失敗した場合には {{ic|foobaz}} の開発者にそのバグを報告してください。
178行目: 147行目:
 
=== リポジトリのカーネルにメジャーアップデートがあったのに、ドライバが最新カーネル用にアップデートされないことはあり得ますか? ===
 
=== リポジトリのカーネルにメジャーアップデートがあったのに、ドライバが最新カーネル用にアップデートされないことはあり得ますか? ===
   
いいえ、ありえません。例えば {{ic|3.5.x}} から {{ic|3.6.x}} といったカーネルのメジャーアップデートは常にすべてのサポートカーネルドライバのリビルドを伴います。ただし、{{AUR|catalyst}} などの非サポートパッケージを使用している場合には、最新のカーネルでそれをリビルドしなければトラブルが発生するかもしれません。非サポートパッケージは自身の責任において使用してください。
+
いいえ、ありえません。例えば {{ic|3.5.x}} から {{ic|3.6.x}} といったカーネルのメジャーアップデートは常にすべてのサポートカーネルドライバのリビルドを伴います。ただし、{{AUR|catalyst}} などの非サポートパッケージを使用している場合には、最新のカーネルでそれをリビルドしなければトラブルが発生するかもしれません。Users are responsible for updating any unsupported driver packages that they have installed.
 
=== Arch はパッケージに署名を採用していますか? ===
 
はい、パッケージ署名は pacman バージョン 4 から実装されました。詳しい情報は [[pacman-key]] をご覧ください。
 
   
 
=== アップグレードの前にやっておいたほうがいい事はありますか? ===
 
=== アップグレードの前にやっておいたほうがいい事はありますか? ===
  +
Follow the [[en2:System maintenance#Upgrading the system]] section.
それは Arch Linux にとってとても大事なことです。アップグレード時、Enter を叩く前に、公式サイトの [https://www.archlinux.jp/ Arch news] (RSS で購読できます) と [https://lists.archlinux.org/listinfo/arch-announce/ アナウンスメントメーリングリスト]を、あとできれば [https://bbs.archlinux.org/ フォーラム]や[https://lists.archlinux.org/listinfo/ その他のメーリングリスト]もチェックしてください。なにがしかの特殊な作業が必要な場合にはそれについて説明されています。
 
   
 
=== パッケージのアップデートがリリースされているのに、pacman はシステムは最新だと出力する ===
 
=== パッケージのアップデートがリリースされているのに、pacman はシステムは最新だと出力する ===
   
''pacman'' のミラーはすぐに同期されるわけではありません。アップデートが利用できるようになるまで24時間以上かかることもあります。アップデートが下りてくるのを待つか、別のミラーを使ってみて下さい。[https://www.archlinux.org/mirrors/status/ MirrorStatus] で最新のミラーを確認できます。
+
''pacman'' のミラーはすぐに同期されるわけではありません。アップデートが利用できるようになるまで24時間以上かかることもあります。The only options are be patient or 別のミラーを使ってみて下さい。[https://www.archlinux.org/mirrors/status/ MirrorStatus] で最新のミラーを確認できます。
   
 
=== 上流のプロジェクト ''X'' が新しいバージョンをリリースしています。Arch パッケージとして新しいバージョンにアップデートできるようになるまでにかかる時間は? ===
 
=== 上流のプロジェクト ''X'' が新しいバージョンをリリースしています。Arch パッケージとして新しいバージョンにアップデートできるようになるまでにかかる時間は? ===
   
 
パッケージアップデートは準備ができ次第リリースされます。上流リリースがマイナーなバグ修正のみであれば数時間でパッケージがアップデートされることもありますし、メジャーアップデートであれば数週間後となることもあります。上流の新しいバージョンが Arch にリリースされるまでの時間はそのパッケージとパッケージメンテナによって変わります。一部のパッケージは [[testing]] リポジトリでしばらくテストされるため、パッケージが更新されるまでの時間が長い傾向にあります。[[Arch 用語集#パッケージメンテナ|パッケージメンテナ]]は安定版のアップデートをリポジトリで素早く提供できるように尽力しています。公式リポジトリのパッケージが古くなっていることに気づいたら、[https://www.archlinux.org/packages/ パッケージウェブサイト] から out-of-date フラグを立てて報告してください。
 
パッケージアップデートは準備ができ次第リリースされます。上流リリースがマイナーなバグ修正のみであれば数時間でパッケージがアップデートされることもありますし、メジャーアップデートであれば数週間後となることもあります。上流の新しいバージョンが Arch にリリースされるまでの時間はそのパッケージとパッケージメンテナによって変わります。一部のパッケージは [[testing]] リポジトリでしばらくテストされるため、パッケージが更新されるまでの時間が長い傾向にあります。[[Arch 用語集#パッケージメンテナ|パッケージメンテナ]]は安定版のアップデートをリポジトリで素早く提供できるように尽力しています。公式リポジトリのパッケージが古くなっていることに気づいたら、[https://www.archlinux.org/packages/ パッケージウェブサイト] から out-of-date フラグを立てて報告してください。
  +
  +
=== If I need an older version of an installed library, can I just symlink to the newer version? ===
  +
  +
If you are lucky, it might work, for a time. Regardless, it is not a proper solution, because:
  +
  +
* Libraries do not change versions randomly - the API/ABI will have likely changed (possibly with bits removed), and whether those changes affect the usage is just a matter of luck.
  +
* The symlink would be untracked by a package manager. Newbies who immediately try to hack on system library files are in the greatest risk of making an unwanted change that they cannot diagnose/fix, which a package manager helps to guard against.
  +
* A slight alternative of dumping the old library file into the filesystem, untracked, would be forgotten about, and not have potential security bugs noticed/patched.
  +
  +
Instead, e.g. use/write a [https://aur.archlinux.org/packages/?SeB=n&K=compat compat package], which provides the required library version.
   
 
==インストール==
 
==インストール==
   
 
=== Arch はもっと良いインストーラーを付けるべきだ。たとえば GUI インストーラーとか ===
 
=== Arch はもっと良いインストーラーを付けるべきだ。たとえば GUI インストーラーとか ===
  +
Arch used to have an installer with a text-based user interface called the Arch Installation Framework (AIF). After its [https://lists.archlinux.org/pipermail/arch-releng/2012-July/002628.html last maintainer left], it was [[Arch Linux#Arch Install Scripts|deprecated in favor of Arch Install Scripts]].
ローリングリリースモデルを採用している Arch ではインストールそのものを滅多に行わないため、その優先度は開発者やユーザにとって高くありません。[[インストールガイド]]はコマンドラインから行う方式に全面的に改められました。それでもインストーラに興味のある方は [[Archboot]] の利用も検討してみてください。
 
  +
Arch ではインストールそのものを滅多に行わないため(read the rest of this article to know more about what ''rolling release'' means)、その優先度は開発者やユーザにとって高くありません。[[インストールガイド]]はコマンドラインから行う方式に全面的に改められました。
   
 
=== Arch をインストールしたんですが、シェルのログイン画面が表示されてます! どうすれば良いのでしょう? ===
 
=== Arch をインストールしたんですが、シェルのログイン画面が表示されてます! どうすれば良いのでしょう? ===
203行目: 180行目:
   
 
=== デスクトップ環境やウィンドウマネージャはどれを使えばいいですか? ===
 
=== デスクトップ環境やウィンドウマネージャはどれを使えばいいですか? ===
たくさんありますので、あなたに一番あったものを使えばいいのです。どのようなデスクトップ環境やウィンドウマネージャがあるかは、[[デスクトップ環境]]や[[ウィンドウマネージャ]]で説明されています
+
たくさんありますので、あなたに一番あったものを使えばいいのです。[[デスクトップ環境]]や[[ウィンドウマネージャ]]も参照しください。
   
=== Arch は「ミニマルな基本システムから構築していくディストリビューションで、ユーザが本当に望むものだけをインストールできる」いうことをうたい文句にしていますが、これって他のディストリビューションでもできますよね?この点に関し一体 Arch のどこがユニークなんですか? ===
+
=== 他の「ミニマルなディストリビューションと比べて Arch のどこがユニークなんですか? ===
  +
See [[en2:Arch compared to other distributions]].
 
確かに一部のディストリビューションは Arch と近い設計理念を持っており、同じようにミニマルなインストール・メソッドを提供してるかも知れませんが、いくつかの相違は指摘しておかねばなりません:
 
#Arch は骨の髄まで軽量でミニマルな環境を構築することを想定してデザインされています。
 
#Arch はこのミニマルな基本システムから構築する以外に方法を提供していません。
 
#ディストリビューション全体と同様、インストレーションに関しても原則的に K.I.S.S.("Keep It Simple and Stupid") の設計理念に基づいています。これによって Arch のベースシステムは、対象となるユーザーベースとの間に、これ以上はないというくらいの親和性を獲得しています。
 
# サービス及びパッケージのインストールでは、手動あるいは対話式に構成設定を行わなければなりません。他のディストリビューションと異なり、サービスの構成や起動設定を自動で行ったりはしません。Arch の哲学は、そのような責任を扱う権利をユーザーから奪わず、ユーザの力量に任せることに重きをおいています。
 
#Arch のパッケージングはミニマルであるよう設計されており、利用状況によっては必要となる“任意の”依存パッケージは自動インストールされません。それらはパッケージのインストール時に通知されるだけなので、結果的によりスリムなシステムになるのです。
 
#Arch は完全なドキュメント群を提供しており、これによって各ユーザーのシステム構築のプロセスを一通り補助しています。
 
   
 
== 64ビット ==
 
== 64ビット ==
   
 
=== 私のプロセッサが x86_64 に対応しているかどうかを知る方法は? ===
 
=== 私のプロセッサが x86_64 に対応しているかどうかを知る方法は? ===
  +
If your processor is [[wikipedia:X86-64|x86_64]] compatible, you will have the {{ic|lm}} ([[Wikipedia:Long mode|long mode]]) flag in {{ic|/proc/cpuinfo}}. For example,
==== Linux ユーザー ====
 
以下のコマンドを実行してください:
 
$ less /proc/cpuinfo
 
   
  +
$ grep -w lm /proc/cpuinfo
{{ic|flags}} エントリーを探してください。 {{ic|lm}} フラグがあったら、あなたのプロセッサーは x86_64 対応です。
 
   
  +
Under Windows, フリーウェアである [http://www.cpuid.com/cpuz.php CPU-Z] を使って、64ビット互換があるかどうか確認できます。AMD の命令セットである AMD64 または Intel の命令セット EM64T は x86_64 のバイナリと互換性があります。
もしくは以下のコマンドを実行してみることも出来ます:
 
$ grep -q "^flags.*\blm\b" /proc/cpuinfo && echo "x86_64" || echo "not x86_64"
 
 
==== Windows ユーザー ====
 
フリーウェアである [http://www.cpuid.com/cpuz.php CPU-Z] を使って、64ビット互換があるかどうか確認できます。AMD の命令セットである AMD64 または Intel の命令セット EM64T は x86_64 のバイナリと互換性があります。
 
   
 
=== 64ビットにする理由は? ===
 
=== 64ビットにする理由は? ===
多くの状況下で (32ビットに比べて) 高速であり、通常の i686 カーネルでは PAE が無効化されているために利用できない[[wikipedia:ja:アドレス空間配置のランダム化|アドレス空間配置のランダム化 (ASLR)]] や [[wikipedia:ja:位置独立コード|位置独立コード (PIC)]]、[[wikipedia:ja:NXビット|NX ビット]]を使用することによりセキュリティが向上することが挙げられます。もしコンピューターに 4GB 以上のメモリが載っている場合、32ビット OS では利用できない分のメモリも使用することができるので、ぜひ64ビットを使用するべきでしょう。
+
多くの状況下で (32ビットに比べて) 高速であり、通常の i686 カーネルでは PAE が無効化されているために利用できない[[wikipedia:ja:アドレス空間配置のランダム化|アドレス空間配置のランダム化 (ASLR)]] や [[wikipedia:ja:位置独立コード|位置独立コード (PIC)]]、[[wikipedia:ja:NXビット|NX ビット]]を使用することによりセキュリティが向上することが挙げられます。もしコンピューターに 4GB 以上のメモリが載っている場合、only a 64-bit OS will be able to fully utilize it.
   
 
更に、64ビットの拡張をサポートしている新しい x86 CPU に対して、レガシーな32ビットの CPU をプログラマーがサポートしなくなってきているというのもあります。
 
更に、64ビットの拡張をサポートしている新しい x86 CPU に対して、レガシーな32ビットの CPU をプログラマーがサポートしなくなってきているというのもあります。
   
 
以上の理由が32ビット環境を避けるべきという我々のアドバイスですが、カーネルやユーザースペース、個々のプログラムなど、64ビットの方が優れているものは他にもたくさんあり、全てをここに書き出す事は出来ません。
 
以上の理由が32ビット環境を避けるべきという我々のアドバイスですが、カーネルやユーザースペース、個々のプログラムなど、64ビットの方が優れているものは他にもたくさんあり、全てをここに書き出す事は出来ません。
 
[https://www.archlinux.org/packages/differences/ 差異のレポート]も見てください。32/64ビットのパッケージバージョンの比較を行うことが出来ます。
 
 
=== 再インストールせずに i686 環境から x86_64 環境にアップグレード出来ますか? ===
 
できません。厳格に言えば、環境の移行とは、全てのパッケージを新しいアーキテクチャ向けに再インストールするということを意味します。ただし、新規インストールをすることなく、現在インストールされているシステムから、環境を移行することは可能です。[https://bbs.archlinux.org/viewtopic.php?id=64485 この]フォーラムスレッドの手順に従えば、設定やデータを失うことなく、32ビットから64ビットに移行できます。移行には外付けのハードドライブを使用するので注意してください。
 
 
もしくは、Arch64 インストール CD でシステムを起動し、ディスクをマウントして、32ビットバイナリ以外の、残しておきたいデータ (例えば {{ic|/home}} や {{ic|/etc}} など) をバックアップして、インストールします。
 
 
詳しくは[[再インストールせずにアーキテクチャを移行]]を読んでください。
 

2020年3月16日 (月) 12:03時点における版

関連記事

目次

一般

Arch Linux って何ですか?

Arch Linux を参照してください。

私は Arch を使うべきではありませんか?

以下のような方は Arch を使いたいとは思わないでしょう:

  • 'do-it-yourself' な GNU/Linux ディストリビューションを使う能力や時間がない、あるいはそれを求めていない方。
  • x86_64 以外のアーキテクチャのサポートが必要な方。
  • GNU で定義されたフリーウェアのみを提供するディストリビューションを使うことに強いこだわりのある方。
  • オペレーティングシステム自身が構成設定を行うべきであり、"箱から出してすぐ使える" べきであり、インストールメディア上でソフトウェアやデスクトップ環境のデフォルト設定が完全になされているべきであるとお考えの方。
  • 最先端で、ローリングリリースな GNU/Linux を求めていない方。
  • 今使っている OS に満足している方。

Arch はどのアーキテクチャをサポートしていますか?

Arch は x86_64 (別名 amd64) アーキテクチャのみをサポートしています。i686 のサポートは2017年11月に切られました [1]

There are unofficial ports for the i686 architecture [2] and ARM CPUs [3], each with their own community channels. [4]

Arch は Linux Foundation の標準ファイルシステム階層 (FHS) に準拠していますか?

Arch Linux は systemd サービスマネージャを使用するオペレーティングシステムのファイルシステム階層を遵守しています。ディレクトリの説明については file-hierarchy(7) を見てください。特に Arch では /bin, /sbin, /usr/sbin/usr/bin のシンボリックリンクに、/lib/lib64/usr/lib のシンボリックリンクになっています。

当方全くの GNU/Linux ビギナーなのですが、Arch を使って大丈夫でしょうか?

もしあなたが初心者で、それでもなお Arch を使おうとしているのであれば、あなたは十分な時間を費やして学ぶことに喜びを覚えるようでなければなりません。また Arch が全く "Do-It-Yourself" なディストリビューションとして設計されている、ということも肝に命じておくべきでしょう。システムを組み上げ、それをどのようなものにしていくかをコントロールするのはユーザー自身なのです。

質問をする前にまず自分で調査するようにしてください。Google やフォーラム、そして素晴らしいドキュメントが用意されている Arch Wiki の検索を活用しましょう。There is a reason these resources were made available to you in the first place. 途方もない時間がこの貴重な情報を編集するために無償で費やされているのです。

Arch 用語集#RTFMインストールガイド も見てください。

Arch はどの用途向けに設計されていますか?サーバですか?デスクトップですか?ワークステーションですか?

Arch は特定の用途向けに設計されているわけではありません。むしろ、特定の "ユーザ" 向けに設計されています。Arch はなんでも自分でやることを楽しみ、各自のニーズに応じたシステムを構築するためにそれをよりよく活用する、やる気のあるユーザを対象にしています。したがって、その目的はユーザの思いのままであり、Arch は事実上あらゆる用途で使用できます。多くの人々が Arch をデスクトップとワークステーション両方で使用しています。そしてもちろん、archlinux.org は Arch で動いています。

Arch はホント好きなんだけどね.開発チームがXの機能さえ実装してくれればなぁ

どうぞ積極的に参加してください.あなた自身がコードや解決策を提示することでコミュニティに貢献しましょう.もし,コミュニティや開発チームから認められれば,あなたのコードはマージされるかも知れません.Archコミュニティはコードやツールの提供,シェアによって活性化していきます.

いつ新しいリリースが出るんでしょうか?

Arch Linux におけるリリースは単にインストールおよびレスキュー用のライブ環境で、base メタパッケージとその他いくつかの パッケージが含まれています。リリースは通常各月の前半頃に公開されます。

Arch Linux は堅牢なディストリなのでしょうか?しょっちゅう壊れたりしませんか?

ローリングリリースで構築された個人のシステムの堅牢性に関して、最終的な責任を負うのはユーザー自身です。ユーザーがいつアップグレードするのかを決め、必要な時に必要な変更をマージするのです。もしユーザーがコミュニティに助けを求めれば、救いの手はすぐに差し伸べられることが多いでしょう。この点に関して、Arch が他のディストリビューションから異なっているのは、Arch が本当に "Do-it-yourself" なディストロであることでしょう。破損についてクレームをつけるのは見当違いであり、非生産的です。アップストリームでの変更に関して Arch 開発チームは責任を負いかねるからです。 See the en2:System maintenance article for tips on how to make an Arch Linux system as stable as possible.

Archのレビュー記事がもっと必要だ(宣伝が必要だ)

現状でもう十分な量のArchについての記事が書かれています.Archの目標は巨大になることではなく; rather, organic, sustainable growth occurs naturally amongst the target user base.

Archの開発者がもっと必要だ

そうかも知れませんね.もっと柔軟にあなたの時間を使って貢献してください! フォーラムや,IRC チャンネルメーリングリストなどに参加すれば,成すべきことがわかるはずです.まずは、Community Contributions サブフォーラムに参加してみてください.

他のOSに比べてインターネットの速度が遅いんだけど、どうして?

ネットワークは正しく設定されていますか?ネットワーク設定のページを参照してください。

また、Arch ではデフォルトでトラフィックシェーピングが有効になっていないことも注意してださい。従って、it is possible that if a program on it somehow utilizes your internet connection to the full – regardless if it is over P2P or classic client-server connections – other local ones will find it clogged, resulting in severe lags and timeouts. Shorewall や Vuurmuur などのファイアウォール; there are also static scripts for iproute2 (such as this derivative of Wondershaper) によってネットワークレイヤーのシェーピングを行うことができます。

なんで Arch は RAM を全部使っちゃうわけ?

そもそも、使わない RAM は無駄な RAM です。

新米ユーザの方の多くは、Linux カーネルのメモリの扱い方が以前の方法と必ずしも同じにはならないことに気がつきます。RAM 上のデータへのアクセスはディスクに比べ非常に高速なので、カーネルは最近アクセスされたデータをメモリ上にキャッシュします。キャッシュされたデータは、利用可能なメモリを使い果たして、新しいデータがロードされる必要のある時のみクリアされます。

We could distinguish the difference from free command:

$ free -h
              total        used        free      shared  buff/cache   available
Mem:           2.8G        1.1G        283M        224M        1.4G        1.2G
Swap:          3.0G        881M        2.1G

It is important to note the difference between "free" and "available" memory. In the above example, a laptop with 2.8G of total RAM appears to be using most of it, with only 283M as free memory. However, 1.4G of it is "buff/cache". There is still 1.2G available for starting new applications, without swapping. See man free(1) for detail. The result of all this? Performance!

もしあなたの好奇心が刺激されたなら、こちらの素晴らしい記事も読んでみてください。こちらのウェブサイトでもこの混乱を整理して説明しています: http://www.linuxatemyram.com/

わたしのディスクの空き領域はどこへ行ってしまったの?

その答えはあなたのシステムによって変わります。こちらに優れたユーティリティの一覧がありますので試してみてください。

パッケージ管理

See the pacman, en2:pacman/Tips and tricks and en2:Official repositories pages for more answers.

Xのパッケージにエラーがあったんだけど,どうしたらいいの?

まず,そのエラーはそもそもArch開発チームが修正できるものなのかどうかを見極めなければなりません.そうでない場合が往々にしてあります(例えばFirefoxのクラッシュは大抵の場合Mozillaチームのミスです).これを アップストリーム・エラー と言います.もしArchの問題であるならば以下の手順を参考に対処してください.:

  1. フォーラムに情報がないか探してみましょう.誰かが同じ問題について気付いていないかチェックしてください.
  2. 詳細な情報を書いたバグレポートhttps://bugs.archlinux.org に投稿してください.
  3. もしお望みならば,フォーラムに質問を投げてみてもよいでしょう.その際,問題の詳細と,あなたが既にバグ・レポートを送った旨を明記してください.それによって同じエラーに関する報告が大量に投稿されるようなケースを回避できます.

Archのパッケージにはもっと適切な命名規則が必要だ。".pkg.tar.gz" とか ".pkg.tar.xz" なんて長すぎるし、ややこしい

これに関しては、Arch のメーリングリスト上で議論されています。.pac のような拡張子を提案する人もいますが、現段階では、パッケージの拡張子を変更する具体的な計画はありません。Arch 開発者の一人である Tobias Kieslich の発言は示唆的です。「事実 package は gzip や xz で圧縮された tarball ファイルなわけじゃないか! だいたい tar が扱えるアプリケーションなら何だって開くことができるし、覗いて弄ることだってできるんだしさ。もっと言えば、mime-type なんてたいがいのアプリケーションが問題なく自動判別できるだろ?」

Pacman には他のアプリケーションがパッケージ情報を簡単に参照するためのライブラリが必要だ

pacmanlibalpm ("Arch Linux Package Management" library) のフロントエンドになっています。このライブラリは代替のフロントエンドの開発を可能にしています (例えばGUIフロントエンドのような)。

Pacman に X の機能を付けるべきだ!

If you think an idea has merit, you may choose to discuss it on pacman-dev. Also check https://bugs.archlinux.org/index.php?project=3 for existing feature requests.

もっとも,ある機能をPacmanやArch Linuxに追加するために一番良い方法は,あなた自身がそれを実装することです.そのパッチがオフィシャルに取り込まれるかどうかはわかりませんが,いずれにせよあなたの骨折りは他のユーザーによって吟味され,検討されるでしょう.

X のパッケージをインストールしたんだけど,どうやって起動するの?

あなたが KDEGNOME のようなデスクトップ環境を導入しているのなら、そのプログラムは自動的にメニューに登録されている筈です。ターミナルから起動しようとしていて、バイナリの名前がわからないというような場合は、次のコマンドで確認してください:

$ pacman -Qlq パッケージ名 | grep /usr/bin/

公式リポジトリにある共用ライブラリはそれぞれどうして一つのバージョンしか用意されてないんですか?

Debian などの一部のディストリビューションは、共用ライブラリパッケージにおいて libfoo1libfoo2libfoo3 といったように複数のバージョンを用意しています。この方法では同一のシステム上で異なるバージョンの libfoo ごとにアプリケーションのコンパイルが可能となります。

Arch のようなディストリビューションの場合、すべてのパッケージで公式にサポートされているのは最新バージョンのみであることを意味します。過去のソフトウェアをサポートしないことで、パッケージメンテナはensuring that the newest versions work as expectedに割く時間をより多くとることができます。共有ライブラリの新しいバージョンがアップストリームからリリースされると、それはすぐにリポジトリに追加され、影響を受けるパッケージは新しいライブラリに合わせてリビルドされます。

もし、システム全体のアップグレード(pacman -Syu)で共用ライブラリがアップデートされたのにそれに依存するアプリケーションがアップデートされなかったらどうなりますか?

それは起こってはならないシナリオです。公式リポジトリに foobaz というアプリケーションがあり、libbaz という共用ライブラリの新バージョンを使用してビルドされているとして、それは libbaz のアップデートに合わせてアップデートされます。しかしもし、if it does not build successfully、そのパッケージ foobaz にはバージョン制限のある依存関係 (例: libbaz=1.5) が指定され、libbaz のアップグレードの際に pacman によってコンフリクトを理由に削除されます。

もし foobaz が、あなた自身でビルドした、あるいは AUR からインストールしたパッケージであった場合には、新バージョンの libbazfoobaz をリビルドしてみてください。ビルドが失敗した場合には foobaz の開発者にそのバグを報告してください。

リポジトリのカーネルにメジャーアップデートがあったのに、ドライバが最新カーネル用にアップデートされないことはあり得ますか?

いいえ、ありえません。例えば 3.5.x から 3.6.x といったカーネルのメジャーアップデートは常にすべてのサポートカーネルドライバのリビルドを伴います。ただし、catalystAUR などの非サポートパッケージを使用している場合には、最新のカーネルでそれをリビルドしなければトラブルが発生するかもしれません。Users are responsible for updating any unsupported driver packages that they have installed.

アップグレードの前にやっておいたほうがいい事はありますか?

Follow the en2:System maintenance#Upgrading the system section.

パッケージのアップデートがリリースされているのに、pacman はシステムは最新だと出力する

pacman のミラーはすぐに同期されるわけではありません。アップデートが利用できるようになるまで24時間以上かかることもあります。The only options are be patient or 別のミラーを使ってみて下さい。MirrorStatus で最新のミラーを確認できます。

上流のプロジェクト X が新しいバージョンをリリースしています。Arch パッケージとして新しいバージョンにアップデートできるようになるまでにかかる時間は?

パッケージアップデートは準備ができ次第リリースされます。上流リリースがマイナーなバグ修正のみであれば数時間でパッケージがアップデートされることもありますし、メジャーアップデートであれば数週間後となることもあります。上流の新しいバージョンが Arch にリリースされるまでの時間はそのパッケージとパッケージメンテナによって変わります。一部のパッケージは testing リポジトリでしばらくテストされるため、パッケージが更新されるまでの時間が長い傾向にあります。パッケージメンテナは安定版のアップデートをリポジトリで素早く提供できるように尽力しています。公式リポジトリのパッケージが古くなっていることに気づいたら、パッケージウェブサイト から out-of-date フラグを立てて報告してください。

If I need an older version of an installed library, can I just symlink to the newer version?

If you are lucky, it might work, for a time. Regardless, it is not a proper solution, because:

  • Libraries do not change versions randomly - the API/ABI will have likely changed (possibly with bits removed), and whether those changes affect the usage is just a matter of luck.
  • The symlink would be untracked by a package manager. Newbies who immediately try to hack on system library files are in the greatest risk of making an unwanted change that they cannot diagnose/fix, which a package manager helps to guard against.
  • A slight alternative of dumping the old library file into the filesystem, untracked, would be forgotten about, and not have potential security bugs noticed/patched.

Instead, e.g. use/write a compat package, which provides the required library version.

インストール

Arch はもっと良いインストーラーを付けるべきだ。たとえば GUI インストーラーとか

Arch used to have an installer with a text-based user interface called the Arch Installation Framework (AIF). After its last maintainer left, it was deprecated in favor of Arch Install Scripts. Arch ではインストールそのものを滅多に行わないため(read the rest of this article to know more about what rolling release means)、その優先度は開発者やユーザにとって高くありません。インストールガイドはコマンドラインから行う方式に全面的に改められました。

Arch をインストールしたんですが、シェルのログイン画面が表示されてます! どうすれば良いのでしょう?

一般的な推奨事項を参照してください。

デスクトップ環境やウィンドウマネージャはどれを使えばいいですか?

たくさんありますので、あなたに一番あったものを使えばいいのです。デスクトップ環境ウィンドウマネージャも参照してください。

他の「ミニマル」なディストリビューションと比べて Arch のどこがユニークなんですか?

See en2:Arch compared to other distributions.

64ビット

私のプロセッサが x86_64 に対応しているかどうかを知る方法は?

If your processor is x86_64 compatible, you will have the lm (long mode) flag in /proc/cpuinfo. For example,

$ grep -w lm /proc/cpuinfo

Under Windows, フリーウェアである CPU-Z を使って、64ビット互換があるかどうか確認できます。AMD の命令セットである AMD64 または Intel の命令セット EM64T は x86_64 のバイナリと互換性があります。

64ビットにする理由は?

多くの状況下で (32ビットに比べて) 高速であり、通常の i686 カーネルでは PAE が無効化されているために利用できないアドレス空間配置のランダム化 (ASLR)位置独立コード (PIC)NX ビットを使用することによりセキュリティが向上することが挙げられます。もしコンピューターに 4GB 以上のメモリが載っている場合、only a 64-bit OS will be able to fully utilize it.

更に、64ビットの拡張をサポートしている新しい x86 CPU に対して、レガシーな32ビットの CPU をプログラマーがサポートしなくなってきているというのもあります。

以上の理由が32ビット環境を避けるべきという我々のアドバイスですが、カーネルやユーザースペース、個々のプログラムなど、64ビットの方が優れているものは他にもたくさんあり、全てをここに書き出す事は出来ません。