「FAQ」の版間の差分

2024年7月10日 (水) 20:45時点における最新版

1 一般
2 インストール
3 システムメンテナンス
4 パッケージ管理
5 64ビット
- 5.1 私のプロセッサが x86_64 に対応しているかどうかを知る方法は？
- 5.2 64ビットにする理由は？

一般

Arch Linux って何ですか？

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

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

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

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

なぜ Arch を使いたいですか？

Arch は最高だからです。

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

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

非公式 の移植プロジェクトとしては、i686 アーキテクチャ向けの [2] や ARM CPU 向けの [3] などがあり、それぞれ専用のコミュニティを持っています。

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 チャンネル，メーリングリストなどに参加すれば，成すべきことがわかるはずです．詳細はコミュニティに貢献を参照してください。

インストール

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

Arch には Arch Installation Framework (AIF) と呼ばれる、テキストベースのユーザーインターフェースを持ったインストーラがありました。最後のメンテナが去った後、arch-install-scripts の推奨により廃止されました。 2021年4月1日から、Arch はインストーラを再度含むようになりました。詳細は archinstall を参照してください。

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

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

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

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

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

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

システムメンテナンス

システムメンテナンスも参照してください。

他の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.8Gi       1.1Gi       283Mi       224Mi       1.4Gi       1.2Gi
Swap:         3.0Gi       881Mi       2.1Gi

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

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

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

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

パッケージ管理

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

システムの完全アップグレードを実行すると、共有ライブラリの更新は行われるが、それに依存するアプリケーションの更新は行われない場合はどうなりますか?

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

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

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

いいえ、ありえません。例えば 3.5.x から 3.6.x といったカーネルのメジャーアップデートは常にすべてのサポートカーネルドライバのリビルドを伴います。ただし、非サポートパッケージ (例えば AUR のパッケージ) を使用している場合には、最新のカーネルでそれをリビルドしなければトラブルが発生するかもしれません。サポートされていないドライバパッケージは、インストールしているユーザーがアップデートに全ての責任を負います。

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

システムメンテナンス#システムのアップグレードセクションに従ってください。

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

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

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

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

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

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

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

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

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ビットの方が優れているものは他にもたくさんあり、全てをここに書き出す事はできません。

翻訳ステータス: このページは en:Frequently asked questions の翻訳バージョンです。最後の翻訳日は 2023-02-10 です。もし英語版に変更があれば、翻訳の同期を手伝うことができます。

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