「FAQ」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
imported>Blowback
(Sync with en 11:03, 8 October 2012)
(9人の利用者による、間の43版が非表示)
1行目: 1行目:
[[Category:About Arch (日本語)]]
+
[[Category:Arch について]]
  +
[[ar:Frequently asked questions]]
[[Category:FAQs (日本語)]]
 
  +
[[bg:Frequently asked questions]]
[[Category:日本語]]
 
  +
[[bs:Frequently asked questions]]
[[bg:FAQ]]
 
[[cs:FAQ]]
+
[[cs:Frequently asked questions]]
[[da:FAQ]]
+
[[da:Frequently asked questions]]
 
[[de:FAQ]]
 
[[de:FAQ]]
  +
[[el:Frequently asked questions]]
[[en:FAQ]]
 
  +
[[en:Frequently asked questions]]
[[es:FAQ]]
 
[[fa:پرسش‌ و پاسخ]]
+
[[es:Frequently asked questions]]
  +
[[fa:سؤالات متداول]]
  +
[[fi:Frequently asked questions]]
 
[[fr:FAQ]]
 
[[fr:FAQ]]
[[hr:FAQ]]
+
[[hr:Frequently asked questions]]
  +
[[hu:Frequently asked questions]]
[[id:FAQ]]
 
  +
[[id:Frequently asked questions]]
[[it:FAQ]]
 
  +
[[it:Frequently asked questions]]
[[ko:FAQ]]
 
  +
[[ko:Frequently asked questions]]
[[lt:FAQ]]
 
  +
[[lt:Frequently asked questions]]
[[nl:FAQ]]
 
  +
[[nl:Frequently asked questions]]
[[pt:FAQ]]
 
  +
[[pl:Frequently asked questions]]
[[ro:Întrebări frecvente]]
 
  +
[[pt:Frequently asked questions]]
[[ru:FAQ]]
 
  +
[[ru:Frequently asked questions]]
[[sk:FAQ]]
 
  +
[[sk:Frequently asked questions]]
[[th:FAQ]]
 
[[tr:Sss]]
+
[[sv:FAQ]]
  +
[[th:Frequently asked questions]]
[[zh-CN:FAQ]]
 
  +
[[tr:Frequently asked questions]]
[[zh-TW:FAQ]]
 
  +
[[zh-hans:Frequently asked questions]]
ここで解決されない問題等については,[[The Arch Way (日本語)]],[[Arch Linux (日本語)]]が参考になります.そこではArch Linuxに関するより多くの情報が扱われています.
 
  +
[[zh-hant:Frequently asked questions]]
  +
{{Related articles start}}
  +
{{Related|Arch 用語集}}
  +
{{Related|Arch User Repository#FAQ}}
  +
{{Related|一般的なトラブルシューティング}}
  +
{{Related articles end}}
   
 
==一般==
 
==一般==
   
===Q) Arch Linux って何ですか?===
+
=== Arch Linux って何ですか===
'''A)''' [[Arch Linux (日本語)]]を参照してください。
+
[[Arch Linux]] を参照してください。
   
===Q) 私は Arch を使うべきで? ===
+
=== 私は Arch を使うべきではありません ===
  +
以下のような方は Arch を使いたいとは思わないでしょう:
'''A)''' あなたが [[The Arch Way (日本語)|The Arch Way]] の理念に賛同し、'do-it-yourself' なアプローチを受け入れることができて、そして、シンプルで、エレガントで、高いカスタマイズ性を持ち、最先端の汎用 GNU/Linux ディストリビューションをお探しなら、Arch が気に入るかもしれません。
 
  +
* 'do-it-yourself' な GNU/Linux ディストリビューションを使う能力や時間がない、あるいはそれを求めていない方。
 
  +
* x86_64 以外のアーキテクチャのサポートが必要な方。
===Q) 私は Arch を使うべきではありませんか?===
 
'''A)''' あなたが [[The Arch Way (日本語)|The Arch Way]] の理念に賛同できず、'do-it-yourself' な GNU/Linux ディストリビューションを使う能力や時間がない、あるいはそれを求めていないなら、Arch はあなた向けではないかもしれません。
 
 
また、以下のような方も Arch を使いたいとは思わないでしょう:
 
* x86_64 および i686 以外のアーキテクチャのサポートが必要な方。
 
 
* GNU で定義されたフリーウェアのみを提供するディストリビューションを使うことに強いこだわりのある方。
 
* GNU で定義されたフリーウェアのみを提供するディストリビューションを使うことに強いこだわりのある方。
 
* オペレーティングシステム自身が構成設定を行うべきであり、"箱から出してすぐ使える" べきであり、インストールメディア上でソフトウェアやデスクトップ環境のデフォルト設定が完全になされているべきであるとお考えの方。
 
* オペレーティングシステム自身が構成設定を行うべきであり、"箱から出してすぐ使える" べきであり、インストールメディア上でソフトウェアやデスクトップ環境のデフォルト設定が完全になされているべきであるとお考えの方。
44行目: 48行目:
 
* 今使っている OS に満足している方。
 
* 今使っている OS に満足している方。
   
===Q) Arch はどのディストリビュションベスなんですか? ===
+
=== Arch はどのキテクチャをサポトしていますか ===
  +
Arch は x86_64 (別名 amd64) アーキテクチャのみをサポートしています。i686 のサポートは2017年11月に切られました [https://www.archlinux.jp/news/the-end-of-i686-support/]。
'''A)''' Arch は独自に開発され、他のいかなる GNU/Linux ディストリビューションもベースとしていません。Arch を製作する以前、Judd Vinet は Per Lidén による優れた最小主義ディストリビューションである CRUX を賞賛し使用していました。当初は CRUX と同様のアイデアに触発された Arch ですが、スクラッチビルドされており、[[pacman]] は C 言語で開発されました。
 
   
  +
''非公式'' の移植プロジェクトとしては、i686 アーキテクチャ向けの [https://archlinux32.org/] や [[Wikipedia:jja:ARMアーキテクチャ|ARM]] CPU 向けの [http://archlinuxarm.org/] などがあり、それぞれ専用のコミュニティを持っています。[http://ix.io/73w/irc]
===Q) 当方全くの GNU/Linux ビギナーなのですが、Arch を使って大丈夫でしょうか? ===
 
'''A)''' これに関してはかなりの議論があります。Arch はある程度熟練した GNU/Linux ユーザーを対象にしていますが、やる気のある初心者には Arch こそもってこいだ、と考えるような人もいます。もしあなたが初心者で、それでもなお Arch を使おうとしているのであれば、あなたは十分な時間を費やして学ぶことに喜びを覚えるようでなければなりません。また Arch が全く "Do-It-Yourself" なディストリビューションとして設計されている、ということも肝に命じておくべきでしょう。システムを組み上げ、それをどのようなものにしていくかをコントロールするのはユーザー自身なのです。質問をする前にまず自分で調査するようにしてください。Google やフォーラム、そして素晴らしいドキュメントが用意されている Arch Wiki の検索を活用しましょう (以下のFAQも参照してください)。以上のことさえ実践していれば、それほど困難なことはありません。また、多くの人が同じ基本的質問に何度も繰り返して答えさせられることに嫌気がさしているのだ、ということも理解しておいてください。あなたは今まさにその当事者なのです。伊達や酔狂でこのような文書が作成され、入門者に利用してもらえるよう設置されているわけではありません。途方もない時間がこの貴重な情報を編集するために無償で費やされているのです。
 
   
  +
=== Arch は Linux Foundation の標準ファイルシステム階層 (FHS) に準拠していますか? ===
要通読:[[Beginners Guide|Beginners' Guide]]
 
  +
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 を使って大丈夫でしょうか? ===
===Q) Arch を使うにはとても手間暇がかかるし、コミュニティはといえば、なにかと言うと RTFM って言うし。===
 
  +
もしあなたが初心者で、それでもなお Arch を使おうとしているのであれば、あなたは十分な時間を費やして学ぶことに喜びを覚えるようでなければなりません。また Arch が全く "Do-It-Yourself" なディストリビューションとして設計されている、ということも肝に命じておくべきでしょう。システムを組み上げ、それをどのようなものにしていくかをコントロールするのはユーザー自身なのです。
'''A)''' Arch は特定のユーザベースを対象にして設計され、利用されています。おそらくそれがあなたには合っていないのでしょう。[[#Q) 当方全くの GNU/Linux ビギナーなのですが、Arch を使って大丈夫でしょうか?|上のセクション]]も参照してください。
 
   
  +
質問をする前にまず自分で調査するようにしてください。Google やフォーラム、そして素晴らしいドキュメントが用意されている Arch Wiki の検索を活用しましょう。''そのような情報が使える状態になっているのには理由があります。'' 途方もない時間がこの貴重な情報を編集するために無償で費やされているのです。
===Q) Arch はどの用途向けに設計されていますか? サーバですか? デスクトップですか? ワークステーションですか?===
 
'''A)''' Arch は特定の用途向けに設計されているわけではありません。むしろ、特定の "ユーザ" 向けに設計されています。Arch はなんでも自分でやることを楽しみ、各自のニーズに応じたシステムを構築するためにそれをよりよく活用する、やる気のあるユーザを対象にしています。したがって、その目的はユーザの思いのままであり、Arch は事実上あらゆる用途で使用できます。多くの人々が Arch をデスクトップとワークステーション両方で使用しています。そしてもちろん、archlinux.org は Arch で動いています。
 
   
  +
[[Arch 用語集#RTFM]] や [[インストールガイド]] も見てください。
===Q) Archはホント好きなんだけどね.開発チームがXの機能さえ実装してくれればなぁ.===
 
'''A)''' ちょっと待った.ちゃんと[[The Arch Way (日本語)]]は,読みましたか? あなたはその機能/対処方法を提示したみたのですか? それは''ミニマリズム''や,''利便性に先んじるコードの整合性''と言ったArchの哲学と一致するでしょうか? どうぞ積極的に参加してください.あなた自身がコードや解決策を提示することでコミュニティに貢献しましょう.もし,コミュニティや開発チームから認められれば,あなたのコードはマージされるかも知れません.Archコミュニティはコードやツールの提供,シェアによって活性化していきます.
 
   
  +
=== Arch はどの用途向けに設計されていますか?サーバですか?デスクトップですか?ワークステーションですか? ===
===Q) いつ新しいメジャー・リリースが出るんでしょうか? ===
 
  +
Arch は特定の用途向けに設計されているわけではありません。むしろ、特定の "ユーザ" 向けに設計されています。Arch はなんでも自分でやることを楽しみ、各自のニーズに応じたシステムを構築するためにそれをよりよく活用する、やる気のあるユーザを対象にしています。したがって、その目的はユーザの思いのままであり、Arch は事実上あらゆる用途で使用できます。多くの人々が Arch をデスクトップとワークステーション両方で使用しています。そしてもちろん、archlinux.org・aur.archlinux.org とほとんど全ての Arch の [https://gitlab.archlinux.org/archlinux/infrastructure インフラストラクチャ] は Arch で動いています。
'''A)''' Arch Linuxにおけるメジャーリリースは各月の前半頃に公開されますが、これは [core] リポジトリの単なるスナップショットを意味するに過ぎません。
 
   
  +
=== Arch はホント好きなんだけどね.開発チームがXの機能さえ実装してくれればなぁ ===
ローリングリリースモデルは、ひとつのコマンド操作によってあらゆる Arch Linux のシステムを最新かつ最先端に保つものです。このことから、Arch におけるメジャーリリースというのはさほど重要な意味を持つものではないと言えます、なぜと言ってローリングリリースシステムは、パッケージがアップデートされるや否や、すぐさま最新のメジャーリリースを旧バージョンにしてしまうわけですから。最新の Arch Linux のメジャーリリースを手に入れたいと思っても、再インストールなどする必要はありません。単にコマンド {{ic|pacman -Syu}} を実行するだけで、あなたのシステムは新規インストールしたのと同様に最新になります。また同じ理由から、新しい Arch Linux のリリースというのは、一般的に理解されているような、真新しくてエキサイティングな機能を満載したものにはなりません。そうした真新しくエキサイティングな機能群のリリースは、必要に応じたパッケージのアップデートによってもたらされるものであり、それは {{ic|pacman -Syu}} のコマンドによって即座に反映されるのです。
 
  +
どうぞ積極的に参加してください.あなた自身がコードや解決策を提示することでコミュニティに貢献しましょう.もし,コミュニティや開発チームから認められれば,あなたのコードはマージされるかも知れません.Archコミュニティはコードやツールの提供,シェアによって活性化していきます.
   
===Q) Arch Linux は堅牢なディトリなのでしょうか? しょっちゅう壊れたりしませんか? ===
+
=== いつ新しいリリーが出るんでしょうか ===
  +
Arch Linux におけるリリースは単にインストールおよびレスキュー用のライブ環境で、{{Pkg|base}} メタパッケージとその他いくつかの [https://projects.archlinux.org/archiso.git/tree/configs/releng/packages.x86_64 パッケージ]が含まれています。リリースは通常各月の前半頃に公開されます。
'''A)''' 一言で言うと、それは概ね「''あなた''次第」だということです。
 
   
  +
=== Arch Linux は堅牢なディストリなのでしょうか?しょっちゅう壊れたりしませんか? ===
自分の Arch システムをシンプルな基本環境の上に構築するのは''あなた''であり,システムの成長をコントロールしていくのも''あなた''なのです。当然、多くのカスタマイズパッケージや、色とりどりのツールキット、デスクトップ環境などを統合して巨大に膨れ上がったシステムでは、スリムでよりシンプルなそれに比べてアップストリームの変更による影響を受けやすく、より多くの設定の問題に悩まされることになります。UNIX に関する一般的な知識や、上手なシステム管理、適切なアップグレードの実施といったものは、システムを堅牢にしていく上で非常に大きな役割を担います。Arch のパッケージの大部分はパッチを施されていないのだ、ということにも留意してください。大部分の問題はおおよそアップストリームに起因するものです。
 
  +
ローリングリリースで構築された個人のシステムの堅牢性に関して、最終的な責任を負うのは''ユーザー自身''です。ユーザーがいつアップグレードするのかを決め、必要な時に必要な変更をマージするのです。もしユーザーがコミュニティに助けを求めれば、救いの手はすぐに差し伸べられることが多いでしょう。この点に関して、Arch が他のディストリビューションから異なっているのは、Arch が本当に "Do-it-yourself" なディストロであることでしょう。破損についてクレームをつけるのは見当違いであり、非生産的です。アップストリームでの変更に関して Arch 開発チームは責任を負いかねるからです。
   
  +
可能な限り安定する Arch Linux システムを構成するための方法やヒントについては、[[システムメンテナンス]]を参照してください。
従って、ローリングリリースで構築された個人のシステムの堅牢性に関して、最終的な責任を負うのは''ユーザー自身''です。ユーザーがいつアップグレードするのかを決め、必要な時に必要な変更をマージするのです。もしユーザーがコミュニティに助けを求めれば、救いの手は直ちに差し伸べられることでしょう。この点に関して、Arch が他のディストリビューションから異なっているのは、Arch が本当に "Do-it-yourself" なディストロであることでしょう。破損についてクレームをつけるのは見当違いであり、非生産的です。なぜといって、アップストリームでの変更に関して Arch 開発チームは責任を負いかねるからです。
 
   
  +
=== Archのレビュー記事がもっと必要だ(宣伝が必要だ) ===
===Q) よく耳にする"BSDスタイルの"initフレームワークって厳密にはどういうものなの? ===
 
  +
現状でもう十分な量のArchについての記事が書かれています.Archの目標は巨大になることではなく、持続的な成長が対象のユーザーベースの間で自然に起きることです。
   
  +
=== Archの開発者がもっと必要だ ===
'''A)''' 30年以上の歴史を持つ BSD の財産の一つに、組み込みのシンプルな init フレームワークがあります。大部分が変更されずにそのまま受け継がれてきました (GNU/Linux のシステムに採用されている SysV init が姿を現すのはずっと後のことです)。Arch が採用する BSD init の主な特徴は、あらゆるランレベルにおけるすべてのシステム・サービスを制御するシェルスクリプトを、ひとつのディレクトリ ({{ic|/etc/rc.d/}}) に納め、それを一つのテキストファイル ({{ic|/etc/rc.conf}}) で管理している点です。
 
  +
そうかも知れませんね.もっと柔軟にあなたの時間を使って貢献してください! [https://bbs.archlinux.jp/ フォーラム]や,[[IRC チャンネル]],[https://mailman.archlinux.org/mailman/listinfo/ メーリングリスト]などに参加すれば,成すべきことがわかるはずです.まずは、Community Contributions サブフォーラムに参加してみてください.
   
  +
=== 他のOSに比べてインターネットの速度が遅いんだけど、どうして? ===
これに対して SysV init では、各ランレベルごとに {{ic|/etc/rc.0,1,2,3,4,5,6}} のようなディレクトリが用意され、その中に複雑に入り組んだシンボリックリンクが配置されます。それぞれのサービスとシンボリックリンクは、{{ic|/etc/init.d/}} 内のシェルスクリプトを参照しています。言うまでもなく SysV 方式の方がより複雑で、各 /etc/rc ディレクトリ内には往々にして大量のシンボリックリンクが張られることになります。シンプルたらんことを追求する哲学に従って、Arch は BSD init を採用しているのです。
 
  +
ネットワークは正しく設定されていますか?[[ネットワーク設定]]のページを参照してください。
   
  +
また、Arch ではデフォルトで[[Wikipedia:ja:トラフィックシェーピング|トラフィックシェーピング]]が有効になっていないことも注意してださい。従って、(P2P 上か通常のクライアント-サーバー通信かに関わらず)ネットワーク帯域を使い果たすプログラムは、ローカルの他のソフトの通信を妨げ、ひどいラグやタイムアウトのような結果になる可能性があります。 Shorewall や Vuurmuur などの[[ファイアウォール]]や、 {{Pkg|iproute2}} の静的なスクリプト(例えば ''Wondershaper'' の [http://serendipity.ruwenzori.net/index.php/2008/06/01/modified-wondershaper-for-better-voip-qos 派生]) によってネットワークレイヤーのシェーピングを行うことができます。
===Q) Archのレビュー記事がもっと必要だ(宣伝が必要だ).===
 
'''A)''' 現状でもう十分な量のArchについての記事が書かれています.Archの目標は巨大になることではなく、シンプルさと,コードの整合性に焦点を絞った,エレガントで,最小かつ最新のディストリビューションを提供することなのです.Archが対象とするユーザー・ベース自体が自然と発展しています.
 
   
===Q) Archの開発者がもと必要だ.===
+
=== なんで Arch は RAM を全部使ちゃうわけ? ===
  +
そもそも、使わない RAM は無駄な RAM です。
'''A)''' そうかも知れませんね.もっと柔軟にあなたの時間を使って貢献してください! [https://bbs.archlinux.org フォーラム]や,[[IRC Channel|IRC]],[https://mailman.archlinux.org/mailman/listinfo/ メーリングリスト]などに参加すれば,成すべきことがわかるはずです.まずは、Community Contributions サブフォーラムに参加してみてください.
 
   
  +
新米ユーザの方の多くは、Linux カーネルのメモリの扱い方が以前の方法と必ずしも同じにはならないことに気がつきます。RAM 上のデータへのアクセスはディスクに比べ非常に高速なので、カーネルは最近アクセスされたデータをメモリ上にキャッシュします。キャッシュされたデータは、利用可能なメモリを使い果たして、新しいデータがロードされる必要のある時のみクリアされます。
===Q) どうしてArchは重いの? もっと軽いと思ってたのに! ===
 
'''A)''' {{ic|/etc/hosts}} が正しく設定されているか確認してください。{{ic|/etc/hostname}} (または {{ic|/etc/rc.conf}}) に書かれた hostname と一致していなければなりません。[[Beginners'_Guide#Configure_the_system|Beginners' Guide のConfigure the System]] の項を参照してください)。hostname が一致していないとアプリケーションの起動が非常に遅くなる場合があります。
 
   
  +
{{ic|free}} コマンドによって違いを見分けることができます:
===Q) 他のOSに比べてインターネットの速度が遅いんだけど、どうして? ===
 
'''A)''' ネットワークは正しく設定されていますか? {{ic|/etc/rc.conf}}、{{ic|/etc/hostname}}、{{ic|/etc/hosts}}、{{ic|/etc/resolv.conf}} をよく確認してみましたか? [[Beginners'_Guide#Configure_the_system|Beginners' Guide のConfigure the System]] の項を参照してください。
 
   
  +
{{hc|$ free -h|
また、Arch ではデフォルトで[http://ja.wikipedia.org/wiki/トラフィックシェーピング トラフィックシェーピング]が有効になっていないことも注意してださい。従って、ネットワーク帯域を活用するプログラムによって改善する可能性があります。Shorewall や Vuurmuur などのファイアウォール (これらは {{Pkg|iproute2}} のスクリプトでもあります) によってネットワークレイヤーのシェーピングを行うことができます。
 
  +
total used free shared buff/cache available
  +
Mem: 2.8G 1.1G 283M 224M 1.4G 1.2G
  +
Swap: 3.0G 881M 2.1G
  +
}}
   
  +
"free" と "available" メモリの違いは重要です。上の例において、ラップトップは 2.8G の RAM をほとんど使っていて、free なメモリはたった 283M しかありません。しかし、そのうち 1.4G は "buff/cache" です。スワップなしで 1.2G の available なメモリが新しいアプリケーションの起動に利用可能です。詳しくは {{ic|man free(1)}} を参照してください。これらは結果としてパフォーマンスを向上させます!
===Q) なんで Arch は RAM を全部使っちゃうわけ? ===
 
'''A)''' そもそも、使わない RAM は無駄な RAM です。
 
   
  +
もしあなたの好奇心が刺激されたなら、[https://www.linuxjournal.com/article/2770 こちらの素晴らしい記事]も読んでみてください。こちらのウェブサイトでもこの混乱を整理して説明しています: http://www.linuxatemyram.com/
新米ユーザの方の多くは、Linux カーネルのメモリの扱い方がそれの使われ方と必ずしも同じにはならないことに気がつきます。RAM 上のデータへのアクセスはディスクに比べ非常に高速なので、カーネルは最近アクセスされたデータをメモリ上にキャッシュします。キャッシュされたデータは利用可能なメモリを使い果たした時のみクリアされ、新しいデータは必要に応じてロードされます。
 
   
  +
=== わたしのディスクの空き領域はどこへ行ってしまったの? ===
この混乱のもっとも一般的な原因は、おそらく {{ic|free}} コマンドにあるでしょう:
 
  +
その答えはあなたのシステムによって変わります。[[アプリケーション一覧#ディスク使用量表示プログラム|こちらに優れたユーティリティの一覧があります]]ので試してみてください。
   
  +
==パッケージ管理==
{{hc|$ free -m|
 
total used free shared buffers cached
 
Mem: 1009 741 267 0 104 359
 
-/+ buffers/cache: 278 731
 
Swap: 1537 0 1537}}
 
   
  +
[[pacman]], [[Pacman ヒント]], [[公式リポジトリ]] により多くの答えがあります。
{{ic|-/+ buffers/cache:}} の行に注目してください —— メモリ量の表現は、実際には「現在使用中」と「利用可能」なメモリ量であり、「未使用」なのではありません。
 
   
  +
=== Xのパッケージにエラーがあったんだけど,どうしたらいいの? ===
上記の例では、1GB の RAM を積んだラップトップで、アイドル状態のターミナルとウェブブラウザを開いただけでその 741MB を使用しています! しかし、上記の "-/+ buffers/cache:" で始まる行を見てください。「現在使用中」なのは 278MB に過ぎません。実際には 731MB は新しいデータのために「利用可能」なのです。一見すると、「使用中」メモリの内の 104MB がバッファデータであり、359MB がキャッシュデータであるかのように見えてしまいますが、それぞれは必要なときにクリアできます。全メモリ中の 267MB のみが真の意味で「free」なのです。
 
  +
まず,そのエラーはそもそもArch開発チームが修正できるものなのかどうかを見極めなければなりません.そうでない場合が往々にしてあります(例えばFirefoxのクラッシュは大抵の場合Mozillaチームのミスです).これを ''アップストリーム・エラー'' と言います.もしArchの問題であるならば以下の手順を参考に対処してください.:
  +
# フォーラムに情報がないか探してみましょう.誰かが同じ問題について気付いていないかチェックしてください.
  +
# 詳細な情報を書いた[[バグ報告ガイドライン|バグレポート]]を https://bugs.archlinux.org に投稿してください.
  +
# もしお望みならば,フォーラムに質問を投げてみてもよいでしょう.その際,問題の詳細と,あなたが既にバグ・レポートを送った旨を明記してください.それによって同じエラーに関する報告が大量に投稿されるようなケースを回避できます.
   
  +
=== Archのパッケージにはもっと適切な命名規則が必要だ。".pkg.tar.gz" とか ".pkg.tar.xz" なんて長すぎるし、ややこしい ===
もしあなたの好奇心が刺激されたなら、[http://www.linuxjournal.com/article/2770 こちらの素晴らしい記事]も読んでみてください。
 
  +
これに関しては、Arch のメーリングリスト上で議論されています。{{Ic|.pac}} のような拡張子を提案する人もいますが、現段階では、パッケージの拡張子を変更する具体的な計画はありません。Arch 開発者の一人である Tobias Kieslich の発言は示唆的です。「事実 package は gzip や xz で圧縮された tarball ファイルなわけじゃないか! だいたい tar が扱えるアプリケーションなら何だって開くことができるし、覗いて弄ることだってできるんだしさ。もっと言えば、mime-type なんてたいがいのアプリケーションが問題なく自動判別できるだろ?」
   
  +
=== Pacman には他のアプリケーションがパッケージ情報を簡単に参照するためのライブラリが必要だ ===
===Q) わたしのディスクの空き領域はどこへ行ってしまったの?===
 
  +
[[pacman]] は [https://www.archlinux.org/pacman/libalpm.3.html libalpm] ("Arch Linux Package Management" library) のフロントエンドになっています。このライブラリは代替のフロントエンドの開発を可能にしています (例えばGUIフロントエンドのような)。
'''A)''' その答えはあなたのシステムによって変わります。[[List of Applications#Disk usage display programs|こちらに優れたユーティリティの一覧があります]]ので試してみてください。
 
   
  +
=== Pacman に X の機能を付けるべきだ! ===
==パッケージ管理==
 
  +
そのアイデアにメリットがあると思うのであれば、[https://lists.archlinux.org/listinfo/pacman-dev/ pacman-dev] で議論することができます。既存の機能リクエストがないか https://bugs.archlinux.org/index.php?project=3 も確認してみてください。
   
  +
もっとも,ある機能をPacmanやArch Linuxに追加するために一番良い方法は,あなた自身がそれを実装することです.そのパッチがオフィシャルに取り込まれるかどうかはわかりませんが,いずれにせよあなたの骨折りは他のユーザーによって吟味され,検討されるでしょう.
===Q) ファイル〇〇はどのパッケージに含まれていますか?===
 
'''A)''' {{Pkg|pkgfile}} コマンドで確認できます。
 
   
  +
=== X のパッケージをインストールしたんだけど,どうやって起動するの? ===
例:
 
  +
あなたが [[KDE]] や [[GNOME]] のようなデスクトップ環境を導入しているのなら、そのプログラムは自動的にメニューに登録されている筈です。ターミナルから起動しようとしていて、バイナリの名前がわからないというような場合は、次のコマンドで確認してください:
{{hc|$ pkgfile glxinfo|extra/mesa-demos}}
 
   
  +
$ pacman -Qlq ''パッケージ名'' | grep /usr/bin/
===Q) Xのパッケージにエラーがあったんだけど,どうしたらいいの? ===
 
'''A)''' まず,そのエラーはそもそもArch開発チームが修正できるものなのかどうかを見極めなければなりません.そうでない場合が往々にしてあります(例えばFirefoxのクラッシュは大抵の場合Mozillaチームのミスです).これをアップストリーム・エラーと言います.もしArchの問題であるならば以下の手順を参考に対処してください.:
 
#フォーラムに情報がないか探してみましょう.誰かが同じ問題について発言していないかチェックしてください.
 
#詳細な情報を書いたバグレポートを[https://bugs.archlinux.org 投函]してください.
 
#もしお望みならば,フォーラムに質問を投げてみてもよいでしょう.その際,問題の詳細と,あなたが既にバグ・レポートを送った旨を明記してください.それによって同じエラーに関する報告が大量に投函されるようなケースを回避できます.
 
   
  +
=== 公式リポジトリにある共用ライブラリはそれぞれどうして一つのバージョンしか用意されてないんですか? ===
===Q) Archのパッケージにはもっと適切な命名規則が必要だ。".pkg.tar.gz" とか ".pkg.tar.xz" なんて長すぎるし、ややこしい。===
 
'''A)''' これに関しては、Arch のメーリングリスト上で議論されています。{{Ic|.pac}} のような拡張子を提案する人もいますが、現段階では、パッケージの拡張子を変更する具体的な計画はありません。Arch 開発者の一人である Tobias Kieslich の発言は示唆的です。''「事実 package は gzip や xz で圧縮された tarball ファイルなわけじゃないか! だいたい tar が扱えるアプリケーションなら何だって開くことができるし、覗いて弄ることだってできるんだしさ。もっと言えば、mime-type なんてたいがいのアプリケーションが問題なく自動判別できるだろ?」''
 
   
  +
Debian などの一部のディストリビューションは、共用ライブラリパッケージにおいて {{ic|libfoo1}}、{{ic|libfoo2}}、{{ic|libfoo3}} といったように複数のバージョンを用意しています。この方法では同一のシステム上で異なるバージョンの libfoo ごとにアプリケーションのコンパイルが可能となります。
===Q) Pacman には他のアプリケーションがパッケージ情報を簡単に参照するためのライブラリが必要だ.===
 
'''A)''' バージョン3.0.0以降、[[pacman]] は libalpm ("Arch Linux Package Management" library) のフロントエンドになっています。このライブラリは代替のフロントエンドの開発を可能にしています (例えばGUIフロントエンドのような)。
 
   
  +
Arch のようなディストリビューションの場合、すべてのパッケージで公式にサポートされているのは最新バージョンのみであることを意味します。過去のソフトウェアをサポートしないことで、パッケージメンテナは最新のバージョンが期待通りに動くことの検証に割く時間をより多くとることができます。共有ライブラリの新しいバージョンがアップストリームからリリースされると、それはすぐにリポジトリに追加され、影響を受けるパッケージは新しいライブラリに合わせてリビルドされます。
===Q) どうしてPacmanにはオフィシャルのGUIフロントエンドがないの? ===
 
'''A)''' [[The Arch Way (日本語)]],[[Arch Linux (日本語)]],[[Devland]]を読んでください.強いて言うならArch開発者チームが提供しようと思わないからです.ユーザー達が開発したものの中からご自由に選択して使ってください.[[Pacman GUI Frontends]]には選りすぐりがリストアップされています.
 
   
  +
=== もし、システム全体のアップグレード({{ic|pacman -Syu}})で共用ライブラリがアップデートされたのにそれに依存するアプリケーションがアップデートされなかったらどうなりますか? ===
===Q) PacmanにXの機能を付けるべきだ! ===
 
'''A)''' [[The Arch Way (日本語)]],[[Arch Linux (日本語)]],[[Devland]]を読んでください.Archの哲学は「シンプルたれ」です.もしあなたがご自身のアイデアにメリットがあると考え,それがくだんのシンプルのお題目を毀損しないものなら,是非フォーラムに投げて議論してください.また,フォーラムをちゃんとチェックしてしかるべきです.ここは重要だと思われる機能について要望を出す,まさにそのための場所なのです.
 
   
  +
それは起こってはならないシナリオです。公式リポジトリに {{ic|foobaz}} というアプリケーションがあり、{{ic|libbaz}} という共用ライブラリの新バージョンを使用してビルドされているとして、それは {{ic|libbaz}} のアップデートに合わせてアップデートされます。しかしもし、if it does not build successfully、そのパッケージ {{ic|foobaz}} にはバージョン制限のある依存関係 (例: libbaz=1.5) が指定され、{{ic|libbaz}} のアップグレードの際に pacman によってコンフリクトを理由に削除されます。
もっとも,ある機能をPacmanやArch Linuxに追加するために一番良い方法は,あなた自身がそれを実装することです.そのパッチがオフィシャルに取り込まれるかどうかはわかりませんが,いずれにせよあなたの骨折りは他のユーザーによって吟味され,検討されるでしょう.
 
   
  +
もし {{ic|foobaz}} が、あなた自身でビルドした、あるいは AUR からインストールしたパッケージであった場合には、新バージョンの {{ic|libbaz}} で {{ic|foobaz}} をリビルドしてみてください。ビルドが失敗した場合には {{ic|foobaz}} の開発者にそのバグを報告してください。
===Q) Archには,安定版パッケージのbranchが必要だ。===
 
'''A)''' 何事にも絶対はありません。これに関してはいくつかの議論があります:<br>
 
https://bbs.archlinux.org/viewtopic.php?id=11288
 
   
  +
=== リポジトリのカーネルにメジャーアップデートがあったのに、ドライバが最新カーネル用にアップデートされないことはあり得ますか? ===
また、より安定したサーバ運用のためのコミュニティプロジェクト [http://www.archserver.org/ ArchServer] もあります。
 
   
  +
いいえ、ありえません。例えば {{ic|3.5.x}} から {{ic|3.6.x}} といったカーネルのメジャーアップデートは常にすべてのサポートカーネルドライバのリビルドを伴います。ただし、{{AUR|catalyst}} などの非サポートパッケージを使用している場合には、最新のカーネルでそれをリビルドしなければトラブルが発生するかもしれません。サポートされていないドライバパッケージは、インストールしているユーザーがアップデートに全ての責任を負います。
===Q) 数種のリポジトリがありますが,どんな違いがあるんでしょうか? ===
 
'''A)''' [[Official Repositories]]を参照してください.
 
   
  +
=== アップグレードの前にやっておいたほうがいい事はありますか? ===
===Q) Xのパッケージをインストールしたんだけど,どうやって起動するの? ===
 
  +
[[:en:System maintenance#Upgrading the system]] セクションに従ってください。
'''A)''' あなたが KDE や GNOME のようなデスクトップ環境を導入しているのなら、そのプログラムは自動的にメニューに登録されている筈です。ターミナルから起動しようとしていて、バイナリの名前がわからないというような場合は、次のコマンドで確認してください:
 
   
  +
=== パッケージのアップデートがリリースされているのに、pacman はシステムは最新だと出力する ===
$ pacman -Qlq ''パッケージ名'' | grep bin
 
   
  +
''pacman'' のミラーはすぐに同期されるわけではありません。アップデートが利用できるようになるまで24時間以上かかることもあります。取り得る選択肢は辛抱強く待つか、別のミラーを使うことだけです。[https://www.archlinux.org/mirrors/status/ MirrorStatus] で最新のミラーを確認できます。
===Q) 公式リポジトリにある共用ライブラリはそれぞれどうして一つのバージョンしか用意されてないんですか?===
 
   
  +
=== 上流のプロジェクト ''X'' が新しいバージョンをリリースしています。Arch パッケージとして新しいバージョンにアップデートできるようになるまでにかかる時間は? ===
'''A)''' Debian などの一部のディストリビューションは、共用ライブラリパッケージにおいて {{ic|libfoo1}}、{{ic|libfoo2}}、{{ic|libfoo3}} といったように複数のバージョンを用意しています。この方法では同一のシステム上で異なるバージョンの libfoo ごとにアプリケーションのコンパイルが可能となります。
 
   
  +
パッケージアップデートは準備ができ次第リリースされます。上流リリースがマイナーなバグ修正のみであれば数時間でパッケージがアップデートされることもありますし、メジャーアップデートであれば数週間後となることもあります。上流の新しいバージョンが Arch にリリースされるまでの時間はそのパッケージとパッケージメンテナによって変わります。一部のパッケージは [[testing]] リポジトリでしばらくテストされるため、パッケージが更新されるまでの時間が長い傾向にあります。[[Arch 用語集#パッケージメンテナ|パッケージメンテナ]]は安定版のアップデートをリポジトリで素早く提供できるように尽力しています。公式リポジトリのパッケージが古くなっていることに気づいたら、[https://www.archlinux.org/packages/ パッケージウェブサイト] から out-of-date フラグを立てて報告してください。
Debian と異なり、Arch はローリングリリースで最先端のディストリビューションです。最先端のディストリビューションの最大の特徴はそのリポジトリから最新バージョンのソフトウェアが入手可能であることです。Arch のようなディストリビューションの場合、すべてのパッケージで公式にサポートされているのは最新バージョンのみであることを意味します。過去のソフトウェアをサポートしないことで、パッケージメンテナは新しいバージョンの作業に割く時間をより多くとることができます。共有ライブラリの新しいバージョンがアップストリームからリリースされると、それはすぐにリポジトリに追加され、影響を受けるパッケージは新しいライブラリに合わせてリビルドされます。
 
   
  +
=== インストールしているライブラリの古いバージョンが必要なときは、新しいバージョンにシンボリックリンクを貼るだけでいいですか? ===
===Q) もし、{{ic|pacman -Syu}} で共用ライブラリがアップデートされたのにそれに依存するアプリケーションがアップデートされなかったらどうなりますか?===
 
  +
幸運であれば少しの間それで動くかもしれません。動いたとしても、以下の理由でそれは正しい解決法ではありません:
   
  +
* ライブラリは意味もなくバージョンを変えません。API/ABI が変更されたり(いくつか削除されたり)することがあり、それが使用に影響するかは単に運次第です。
'''A)''' それは起こってはならないシナリオです。公式リポジトリに {{ic|foobaz}} というアプリケーションがあり、{{ic|libbaz}} という共用ライブラリの新バージョンを使用してビルドされているとして、それは {{ic|libbaz}} のアップデートに合わせてアップデートされます。しかしもし、それがうまくいかない場合、そのパッケージ {{ic|foobaz}} にはバージョン制限のある依存関係 (例: libbaz=1.5) が指定され、{{ic|libbaz}} のアップグレードの際に pacman によってコンフリクトを理由に削除されます。
 
  +
* シンボリックリンクはパッケージマネージャによって管理されません。すぐにシステムライブラリのファイルをハックしようとする初心者は、診断・修正が不可能な意図していない変更を加える大きなリスクを持っています。パッケージマネージャはこのような問題から守る手助けをしています。
  +
* 古いライブラリファイルをファイルシステムにコピーする代替手段もありますが、追跡されない上に忘れられやすく、潜在的なセキュリティのバグが気付かれず、また修正されません。
   
  +
代わりに、例えば必要なライブラリのバージョンを提供する[https://aur.archlinux.org/packages/?SeB=n&K=compat 互換パッケージ]を使うか、もしくは作ってください。
もし {{ic|foobaz}} が、あなた自身でビルドした、あるいは AUR からインストールしたパッケージであった場合には、新バージョンの {{ic|libbaz}} で {{ic|foobaz}} をリビルドしてみてください。ビルドが失敗した場合には {{ic|foobaz}} の開発者にそのバグを報告してください。
 
   
  +
==インストール==
===Q) リポジトリのカーネルにメジャーアップデートがあったのに、ドライバが最新カーネル用にアップデートされないことはあり得ますか?===
 
   
  +
=== Arch はもっと良いインストーラーを付けるべきだ。たとえば GUI インストーラーとか ===
'''A)''' いいえ、ありえません。例えば {{ic|3.5.x}} から {{ic|3.6.x}} といったカーネルのメジャーアップデートは常にすべてのサポートカーネルドライバのリビルドを伴います。ただし、{{AUR|catalyst}} などの非サポートパッケージを使用している場合には、最新のカーネルでそれをリビルドしなければトラブルが発生するかもしれません。非サポートパッケージは自身の責任において使用してください。
 
  +
Arch には Arch Installation Framework (AIF) と呼ばれる、テキストベースのユーザーインターフェースを持ったインストーラがありました。[https://lists.archlinux.org/pipermail/arch-releng/2012-July/002628.html 最後のメンテナが去った]後、{{Pkg|arch-install-scripts}} の推奨により [[Arch_Linux#Arch_Install_Scripts|廃止]] されました。
 
  +
Arch ではインストールそのものを滅多に行わないため(この記事の残りを読んで、''ローリングリリース'' の意味することをより理解してください)、その優先度は開発者やユーザにとって高くありません。[[インストールガイド]]はコマンドラインから行う方式に全面的に改められました。
===Q) Arch はパッケージに署名を採用していますか?===
 
'''A)''' はい、パッケージ署名は pacman バージョン 4 から実装されました。詳しい情報は [[package signing]] をご覧ください。
 
 
==インストール==
 
   
  +
=== Arch をインストールしたんですが、シェルのログイン画面が表示されてます! どうすれば良いのでしょう? ===
===Q) Archはもっと良いインストーラーを付けるべきだ。たとえばGUIインストーラーとか。===
 
  +
[[一般的な推奨事項]]を参照してください。
'''A)''' ローリングリリースモデルを採用している Arch ではインストールそのものを滅多に行わないため、その優先度は開発者やユーザにとって高くありません。[[Installation Guide]] および [[Beginners' Guide]] はコマンドラインから行う方式に全面的に改められました。それでもインストーラに興味のある方は [[Archboot]] の利用も検討してみてください。
 
   
  +
=== デスクトップ環境やウィンドウマネージャはどれを使えばいいですか? ===
===Q) Archをインストールしたんですが,bashのログイン画面が表示されてます! どうすれば良いのでしょう? ===
 
  +
たくさんありますので、あなたに一番あったものを使えばいいのです。[[デスクトップ環境]]や[[ウィンドウマネージャ]]も参照してください。
'''A)''' [[Beginners_Guide]]を参照してください.
 
   
  +
=== 他の「ミニマル」なディストリビューションと比べて Arch のどこがユニークなんですか? ===
===Q) デスクトップ環境やウィンドウマネージャはどれを使えばいいですか?===
 
  +
[[Arch と他のディストリビューションの比較]] を参照してください。
'''A)''' たくさんありますので、あなたに一番あったものを使えばいいのです。どのようなデスクトップ環境やウィンドウマネージャがあるかは、[[Desktop_Environment|Desktop Environments]] や [[Window Manager]] で説明されています。
 
   
  +
== 64ビット ==
===Q) Arch は「ミニマルな基本システムから構築していくディストリビューションで、ユーザが本当に望むものだけをインストールできる」ということをうたい文句にしていますが、これって他のディストリビューションでもできますよね? この点に関して一体 Arch のどこがユニークなんですか? ===
 
   
  +
=== 私のプロセッサが x86_64 に対応しているかどうかを知る方法は? ===
'''A)''' 確かに一部のディストリビューションは Arch と近い設計理念を持っており、同じようにミニマルなインストール・メソッドを提供してるかも知れませんが、いくつかの相違は指摘しておかねばなりません:
 
  +
使っているプロセッサが [[Wikipedia:ja:X64|x86_64]] に対応している場合、{{ic|/proc/cpuinfo}} の中に{{ic|lm}} ([[Wikipedia:ja:X64#Longモード|Longモード]]) フラグがあります。例えば以下のコマンドを実行してください:
#Arch は骨の髄まで軽量でミニマルな環境を構築することを想定してデザインされています。
 
#Arch はこのミニマルな基本システムから構築する以外に方法を提供していません。
 
#ディストリビューション全体と同様、インストレーションに関しても原則的に K.I.S.S.("Keep It Simple and Stupid") の設計理念に基づいています。これによって Arch のベースシステムは、対象となるユーザーベースとの間に、これ以上はないというくらいの親和性を獲得しています。
 
# サービス及びパッケージのインストールでは、手動あるいは対話式に構成設定を行わなければなりません。他のディストリビューションと異なり、サービスの構成や起動設定を自動で行ったりはしません。Arch の哲学は、そのような責任を扱う権利をユーザーから奪わず、ユーザの力量に任せることに重きをおいています。
 
#Arch のパッケージングはミニマルであるよう設計されており、利用状況によっては必要となる“任意の”依存パッケージは自動インストールされません。それらはパッケージのインストール時に通知されるだけなので、結果的によりスリムなシステムになるのです。
 
#Arch は完全なドキュメント群を提供しており、これによって各ユーザーのシステム構築のプロセスを一通り補助しています。
 
   
  +
$ grep -w lm /proc/cpuinfo
==その他==
 
   
  +
Windows 上では、 フリーウェアである [http://www.cpuid.com/cpuz.php CPU-Z] を使って、64ビット互換があるかどうか確認できます。AMD の命令セットである AMD64 または Intel の命令セット EM64T は x86_64 のバイナリと互換性があります。
===Q) "AUR"ってよく聞くんだけど一体何? ===
 
'''A)''' [[AUR Q & A]]を参照してください.
 
   
  +
=== 64ビットにする理由は? ===
===Q) ビデオを見ようとすると画面が緑色になっちゃうんだけど,どうして? ===
 
  +
多くの状況下で (32ビットに比べて) 高速であり、通常の i686 カーネルでは PAE が無効化されているために利用できない[[wikipedia:ja:アドレス空間配置のランダム化|アドレス空間配置のランダム化 (ASLR)]] や [[wikipedia:ja:位置独立コード|位置独立コード (PIC)]]、[[wikipedia:ja:NXビット|NX ビット]]を使用することによりセキュリティが向上することが挙げられます。もしコンピューターに 4GB 以上のメモリが載っている場合、64ビットの OS のみが全てを活用することができます。
'''A)''' colour depthの設定が正しくありません.例えば"24"であるべきところが"16"になっていたりしませんか?
 
   
  +
更に、64ビットの拡張をサポートしている新しい x86 CPU に対して、レガシーな32ビットの CPU をプログラマーがサポートしなくなってきているというのもあります。
===Q) Spellcheckを実行するとテキストが全部ミス判定されてしまうんですが.===
 
'''A)''' {{Pkg|aspell}} 辞書はインストールされていますか? {{ic|pacman -Ss aspell}} を実行して、入手可能な辞書を確認してください。インストールされている辞書は {{ic|aspell dicts}} で確認できます。
 
{{hc|$ aspell dicts|
 
en
 
en_GB
 
...etc}}
 
   
  +
以上の理由が32ビット環境を避けるべきという我々のアドバイスですが、カーネルやユーザースペース、個々のプログラムなど、64ビットの方が優れているものは他にもたくさんあり、全てをここに書き出す事は出来ません。
aspell および辞書がインストールされていても問題が解決しない場合、{{ic|enchant}} が原因かもしれません。{{ic|/usr/share/enchant/enchant.ordering}} を確認し、目的の言語が期待した設定になっているか確認してください。
 

2020年5月24日 (日) 12:34時点における版

関連記事

目次

一般

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]

非公式 の移植プロジェクトとしては、i686 アーキテクチャ向けの [2]ARM CPU 向けの [3] などがあり、それぞれ専用のコミュニティを持っています。[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 の検索を活用しましょう。そのような情報が使える状態になっているのには理由があります。 途方もない時間がこの貴重な情報を編集するために無償で費やされているのです。

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

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

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

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

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

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

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

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

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

可能な限り安定する Arch Linux システムを構成するための方法やヒントについては、システムメンテナンスを参照してください。

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

現状でもう十分な量のArchについての記事が書かれています.Archの目標は巨大になることではなく、持続的な成長が対象のユーザーベースの間で自然に起きることです。

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

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

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

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

また、Arch ではデフォルトでトラフィックシェーピングが有効になっていないことも注意してださい。従って、(P2P 上か通常のクライアント-サーバー通信かに関わらず)ネットワーク帯域を使い果たすプログラムは、ローカルの他のソフトの通信を妨げ、ひどいラグやタイムアウトのような結果になる可能性があります。 Shorewall や Vuurmuur などのファイアウォールや、 iproute2 の静的なスクリプト(例えば Wondershaper派生) によってネットワークレイヤーのシェーピングを行うことができます。

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

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

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

free コマンドによって違いを見分けることができます:

$ 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

"free" と "available" メモリの違いは重要です。上の例において、ラップトップは 2.8G の RAM をほとんど使っていて、free なメモリはたった 283M しかありません。しかし、そのうち 1.4G は "buff/cache" です。スワップなしで 1.2G の available なメモリが新しいアプリケーションの起動に利用可能です。詳しくは man free(1) を参照してください。これらは結果としてパフォーマンスを向上させます!

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

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

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

パッケージ管理

pacman, Pacman ヒント, 公式リポジトリ により多くの答えがあります。

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 の機能を付けるべきだ!

そのアイデアにメリットがあると思うのであれば、pacman-dev で議論することができます。既存の機能リクエストがないか https://bugs.archlinux.org/index.php?project=3 も確認してみてください。

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

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

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

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

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

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

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

もし、システム全体のアップグレード(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 などの非サポートパッケージを使用している場合には、最新のカーネルでそれをリビルドしなければトラブルが発生するかもしれません。サポートされていないドライバパッケージは、インストールしているユーザーがアップデートに全ての責任を負います。

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

en:System maintenance#Upgrading the system セクションに従ってください。

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

pacman のミラーはすぐに同期されるわけではありません。アップデートが利用できるようになるまで24時間以上かかることもあります。取り得る選択肢は辛抱強く待つか、別のミラーを使うことだけです。MirrorStatus で最新のミラーを確認できます。

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

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

インストールしているライブラリの古いバージョンが必要なときは、新しいバージョンにシンボリックリンクを貼るだけでいいですか?

幸運であれば少しの間それで動くかもしれません。動いたとしても、以下の理由でそれは正しい解決法ではありません:

  • ライブラリは意味もなくバージョンを変えません。API/ABI が変更されたり(いくつか削除されたり)することがあり、それが使用に影響するかは単に運次第です。
  • シンボリックリンクはパッケージマネージャによって管理されません。すぐにシステムライブラリのファイルをハックしようとする初心者は、診断・修正が不可能な意図していない変更を加える大きなリスクを持っています。パッケージマネージャはこのような問題から守る手助けをしています。
  • 古いライブラリファイルをファイルシステムにコピーする代替手段もありますが、追跡されない上に忘れられやすく、潜在的なセキュリティのバグが気付かれず、また修正されません。

代わりに、例えば必要なライブラリのバージョンを提供する互換パッケージを使うか、もしくは作ってください。

インストール

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

Arch には Arch Installation Framework (AIF) と呼ばれる、テキストベースのユーザーインターフェースを持ったインストーラがありました。最後のメンテナが去った後、arch-install-scripts の推奨により 廃止 されました。 Arch ではインストールそのものを滅多に行わないため(この記事の残りを読んで、ローリングリリース の意味することをより理解してください)、その優先度は開発者やユーザにとって高くありません。インストールガイドはコマンドラインから行う方式に全面的に改められました。

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

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

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

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

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

Arch と他のディストリビューションの比較 を参照してください。

64ビット

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

使っているプロセッサが x86_64 に対応している場合、/proc/cpuinfo の中にlm (Longモード) フラグがあります。例えば以下のコマンドを実行してください:

$ grep -w lm /proc/cpuinfo

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

64ビットにする理由は?

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

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

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