「FAQ」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
(英語版から同期)
(英文の翻訳)
51行目: 51行目:
 
Arch は x86_64 (別名 amd64) アーキテクチャのみをサポートしています。i686 のサポートは2017年11月に切られました [https://www.archlinux.jp/news/the-end-of-i686-support/]。
  
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]
 +
''非公式'' の移植プロジェクトとしては、i686 アーキテクチャ向けの [https://archlinux32.org/] や [[Wikipedia:jja:ARMアーキテクチャ|ARM]] CPU 向けの [http://archlinuxarm.org/] などがあり、それぞれ専用のコミュニティを持っています。[http://ix.io/73w/irc]
   
 
=== Arch は Linux Foundation の標準ファイルシステム階層 (FHS) に準拠していますか？ ===
  
=== Arch は Linux Foundation の標準ファイルシステム階層 (FHS) に準拠していますか？ ===
59行目: 59行目:
 
もしあなたが初心者で、それでもなお Arch を使おうとしているのであれば、あなたは十分な時間を費やして学ぶことに喜びを覚えるようでなければなりません。また Arch が全く "Do-It-Yourself" なディストリビューションとして設計されている、ということも肝に命じておくべきでしょう。システムを組み上げ、それをどのようなものにしていくかをコントロールするのはユーザー自身なのです。
  
もしあなたが初心者で、それでもなお Arch を使おうとしているのであれば、あなたは十分な時間を費やして学ぶことに喜びを覚えるようでなければなりません。また Arch が全く "Do-It-Yourself" なディストリビューションとして設計されている、ということも肝に命じておくべきでしょう。システムを組み上げ、それをどのようなものにしていくかをコントロールするのはユーザー自身なのです。
   
−
質問をする前にまず自分で調査するようにしてください。Google やフォーラム、そして素晴らしいドキュメントが用意されている Arch Wiki の検索を活用しましょう。''There is a reason these resources were made available to you in the first place.'' 途方もない時間がこの貴重な情報を編集するために無償で費やされているのです。
 +
質問をする前にまず自分で調査するようにしてください。Google やフォーラム、そして素晴らしいドキュメントが用意されている Arch Wiki の検索を活用しましょう。''そのような情報が使える状態になっているのには理由があります。'' 途方もない時間がこの貴重な情報を編集するために無償で費やされているのです。
   
 
[[Arch 用語集#RTFM]] や [[インストールガイド]] も見てください。
  
[[Arch 用語集#RTFM]] や [[インストールガイド]] も見てください。
74行目: 74行目:
 
=== Arch Linux は堅牢なディストリなのでしょうか？しょっちゅう壊れたりしませんか？ ===
  
=== Arch Linux は堅牢なディストリなのでしょうか？しょっちゅう壊れたりしませんか？ ===
 
ローリングリリースで構築された個人のシステムの堅牢性に関して、最終的な責任を負うのは''ユーザー自身''です。ユーザーがいつアップグレードするのかを決め、必要な時に必要な変更をマージするのです。もしユーザーがコミュニティに助けを求めれば、救いの手はすぐに差し伸べられることが多いでしょう。この点に関して、Arch が他のディストリビューションから異なっているのは、Arch が本当に "Do-it-yourself" なディストロであることでしょう。破損についてクレームをつけるのは見当違いであり、非生産的です。アップストリームでの変更に関して Arch 開発チームは責任を負いかねるからです。
  
ローリングリリースで構築された個人のシステムの堅牢性に関して、最終的な責任を負うのは''ユーザー自身''です。ユーザーがいつアップグレードするのかを決め、必要な時に必要な変更をマージするのです。もしユーザーがコミュニティに助けを求めれば、救いの手はすぐに差し伸べられることが多いでしょう。この点に関して、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 Linux システムを構成するための方法やヒントについては、[[システムメンテナンス]]を参照してください。
   
 
=== Archのレビュー記事がもっと必要だ(宣伝が必要だ) ===
  
=== Archのレビュー記事がもっと必要だ(宣伝が必要だ) ===
−
現状でもう十分な量のArchについての記事が書かれています．Archの目標は巨大になることではなく; rather, organic, sustainable growth occurs naturally amongst the target user base.
 +
現状でもう十分な量のArchについての記事が書かれています．Archの目標は巨大になることではなく、持続的な成長が対象のユーザーベースの間で自然に起きることです。
   
 
=== Archの開発者がもっと必要だ ===
  
=== Archの開発者がもっと必要だ ===
85行目: 86行目:
 
ネットワークは正しく設定されていますか？[[ネットワーク設定]]のページを参照してください。
  
ネットワークは正しく設定されていますか？[[ネットワーク設定]]のページを参照してください。
   
−
また、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 ではデフォルトで[[Wikipedia:ja:トラフィックシェーピング|トラフィックシェーピング]]が有効になっていないことも注意してださい。従って、(P2P 上か通常のクライアント-サーバー通信かに関わらず)ネットワーク帯域を使い果たすプログラムは、ローカルの他のソフトの通信を妨げ、ひどいラグやタイムアウトのような結果になる可能性があります。 Shorewall や Vuurmuur などの[[ファイアウォール]]や、 {{Pkg|iproute2}} の静的なスクリプト(例えば ''Wondershaper'' の [http://serendipity.ruwenzori.net/index.php/2008/06/01/modified-wondershaper-for-better-voip-qos 派生]) によってネットワークレイヤーのシェーピングを行うことができます。
   
 
=== なんで Arch は RAM を全部使っちゃうわけ？ ===
  
=== なんで Arch は RAM を全部使っちゃうわけ？ ===
92行目: 93行目:
 
新米ユーザの方の多くは、Linux カーネルのメモリの扱い方が以前の方法と必ずしも同じにはならないことに気がつきます。RAM 上のデータへのアクセスはディスクに比べ非常に高速なので、カーネルは最近アクセスされたデータをメモリ上にキャッシュします。キャッシュされたデータは、利用可能なメモリを使い果たして、新しいデータがロードされる必要のある時のみクリアされます。
  
新米ユーザの方の多くは、Linux カーネルのメモリの扱い方が以前の方法と必ずしも同じにはならないことに気がつきます。RAM 上のデータへのアクセスはディスクに比べ非常に高速なので、カーネルは最近アクセスされたデータをメモリ上にキャッシュします。キャッシュされたデータは、利用可能なメモリを使い果たして、新しいデータがロードされる必要のある時のみクリアされます。
   
  +
{{ic|free}} コマンドによって違いを見分けることができます:
−
We could distinguish the difference from {{ic|free}} command:
  
   
 
{{hc|$ free -h|
  
{{hc|$ free -h|
100行目: 101行目:
 
}}
  
}}
   
  +
"free" と "available" メモリの違いは重要です。上の例において、ラップトップは 2.8G の RAM をほとんど使っていて、free なメモリはたった 283M しかありません。しかし、そのうち 1.4G は "buff/cache" です。スワップなしで 1.2G の available なメモリが新しいアプリケーションの起動に利用可能です。詳しくは {{ic|man free(1)}} を参照してください。これらは結果としてパフォーマンスを向上させます！
−
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!
  
   
 
もしあなたの好奇心が刺激されたなら、[https://www.linuxjournal.com/article/2770 こちらの素晴らしい記事]も読んでみてください。こちらのウェブサイトでもこの混乱を整理して説明しています: http://www.linuxatemyram.com/
  
もしあなたの好奇心が刺激されたなら、[https://www.linuxjournal.com/article/2770 こちらの素晴らしい記事]も読んでみてください。こちらのウェブサイトでもこの混乱を整理して説明しています: http://www.linuxatemyram.com/
109行目: 110行目:
 
==パッケージ管理==
  
==パッケージ管理==
   
  +
[[pacman]], [[Pacman ヒント]], [[公式リポジトリ]] により多くの答えがあります。
−
See the [[pacman]], [[en2:pacman/Tips and tricks]] and [[en2:Official repositories]] pages for more answers.
  
   
 
=== Xのパッケージにエラーがあったんだけど，どうしたらいいの？ ===
  
=== Xのパッケージにエラーがあったんだけど，どうしたらいいの？ ===
118行目: 119行目:
   
 
=== Archのパッケージにはもっと適切な命名規則が必要だ。".pkg.tar.gz" とか ".pkg.tar.xz" なんて長すぎるし、ややこしい ===
  
=== Archのパッケージにはもっと適切な命名規則が必要だ。".pkg.tar.gz" とか ".pkg.tar.xz" なんて長すぎるし、ややこしい ===
−
これに関しては、Arch のメーリングリスト上で議論されています。{{Ic|.pac}} のような拡張子を提案する人もいますが、現段階では、パッケージの拡張子を変更する具体的な計画はありません。Arch 開発者の一人である Tobias Kieslich の発言は示唆的です。''「事実 package は gzip や xz で圧縮された tarball ファイルなわけじゃないか! だいたい tar が扱えるアプリケーションなら何だって開くことができるし、覗いて弄ることだってできるんだしさ。もっと言えば、mime-type なんてたいがいのアプリケーションが問題なく自動判別できるだろ？」''
 +
これに関しては、Arch のメーリングリスト上で議論されています。{{Ic|.pac}} のような拡張子を提案する人もいますが、現段階では、パッケージの拡張子を変更する具体的な計画はありません。Arch 開発者の一人である Tobias Kieslich の発言は示唆的です。「事実 package は gzip や xz で圧縮された tarball ファイルなわけじゃないか! だいたい tar が扱えるアプリケーションなら何だって開くことができるし、覗いて弄ることだってできるんだしさ。もっと言えば、mime-type なんてたいがいのアプリケーションが問題なく自動判別できるだろ？」
   
 
=== Pacman には他のアプリケーションがパッケージ情報を簡単に参照するためのライブラリが必要だ ===
  
=== Pacman には他のアプリケーションがパッケージ情報を簡単に参照するためのライブラリが必要だ ===
124行目: 125行目:
   
 
=== 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.
 +
そのアイデアにメリットがあると思うのであれば、[https://lists.archlinux.org/listinfo/pacman-dev/ pacman-dev] で議論することができます。既存の機能リクエストがないか https://bugs.archlinux.org/index.php?project=3 も確認してみてください。
   
 
もっとも，ある機能をPacmanやArch Linuxに追加するために一番良い方法は，あなた自身がそれを実装することです．そのパッチがオフィシャルに取り込まれるかどうかはわかりませんが，いずれにせよあなたの骨折りは他のユーザーによって吟味され，検討されるでしょう．
  
もっとも，ある機能をPacmanやArch Linuxに追加するために一番良い方法は，あなた自身がそれを実装することです．そのパッチがオフィシャルに取り込まれるかどうかはわかりませんが，いずれにせよあなたの骨折りは他のユーザーによって吟味され，検討されるでしょう．
137行目: 138行目:
 
Debian などの一部のディストリビューションは、共用ライブラリパッケージにおいて {{ic|libfoo1}}、{{ic|libfoo2}}、{{ic|libfoo3}} といったように複数のバージョンを用意しています。この方法では同一のシステム上で異なるバージョンの libfoo ごとにアプリケーションのコンパイルが可能となります。
  
Debian などの一部のディストリビューションは、共用ライブラリパッケージにおいて {{ic|libfoo1}}、{{ic|libfoo2}}、{{ic|libfoo3}} といったように複数のバージョンを用意しています。この方法では同一のシステム上で異なるバージョンの libfoo ごとにアプリケーションのコンパイルが可能となります。
   
−
Arch のようなディストリビューションの場合、すべてのパッケージで公式にサポートされているのは最新バージョンのみであることを意味します。過去のソフトウェアをサポートしないことで、パッケージメンテナはensuring that the newest versions work as expectedに割く時間をより多くとることができます。共有ライブラリの新しいバージョンがアップストリームからリリースされると、それはすぐにリポジトリに追加され、影響を受けるパッケージは新しいライブラリに合わせてリビルドされます。
 +
Arch のようなディストリビューションの場合、すべてのパッケージで公式にサポートされているのは最新バージョンのみであることを意味します。過去のソフトウェアをサポートしないことで、パッケージメンテナは最新のバージョンが期待通りに動くことの検証に割く時間をより多くとることができます。共有ライブラリの新しいバージョンがアップストリームからリリースされると、それはすぐにリポジトリに追加され、影響を受けるパッケージは新しいライブラリに合わせてリビルドされます。
   
 
=== もし、システム全体のアップグレード（{{ic|pacman -Syu}}）で共用ライブラリがアップデートされたのにそれに依存するアプリケーションがアップデートされなかったらどうなりますか？ ===
  
=== もし、システム全体のアップグレード（{{ic|pacman -Syu}}）で共用ライブラリがアップデートされたのにそれに依存するアプリケーションがアップデートされなかったらどうなりますか？ ===
147行目: 148行目:
 
=== リポジトリのカーネルにメジャーアップデートがあったのに、ドライバが最新カーネル用にアップデートされないことはあり得ますか？ ===
  
=== リポジトリのカーネルにメジャーアップデートがあったのに、ドライバが最新カーネル用にアップデートされないことはあり得ますか？ ===
   
−
いいえ、ありえません。例えば {{ic|3.5.x}} から {{ic|3.6.x}} といったカーネルのメジャーアップデートは常にすべてのサポートカーネルドライバのリビルドを伴います。ただし、{{AUR|catalyst}} などの非サポートパッケージを使用している場合には、最新のカーネルでそれをリビルドしなければトラブルが発生するかもしれません。Users are responsible for updating any unsupported driver packages that they have installed.
 +
いいえ、ありえません。例えば {{ic|3.5.x}} から {{ic|3.6.x}} といったカーネルのメジャーアップデートは常にすべてのサポートカーネルドライバのリビルドを伴います。ただし、{{AUR|catalyst}} などの非サポートパッケージを使用している場合には、最新のカーネルでそれをリビルドしなければトラブルが発生するかもしれません。サポートされていないドライバパッケージは、インストールしているユーザーがアップデートに全ての責任を負います。
   
 
=== アップグレードの前にやっておいたほうがいい事はありますか？ ===
  
=== アップグレードの前にやっておいたほうがいい事はありますか？ ===
−
Follow the [[en2:System maintenance#Upgrading the system]] section.
 +
[[en2:System maintenance#Upgrading the system]] セクションに従ってください。
   
 
=== パッケージのアップデートがリリースされているのに、pacman はシステムは最新だと出力する ===
  
=== パッケージのアップデートがリリースされているのに、pacman はシステムは最新だと出力する ===
   
−
''pacman'' のミラーはすぐに同期されるわけではありません。アップデートが利用できるようになるまで24時間以上かかることもあります。The only options are be patient or 別のミラーを使ってみて下さい。[https://www.archlinux.org/mirrors/status/ MirrorStatus] で最新のミラーを確認できます。
 +
''pacman'' のミラーはすぐに同期されるわけではありません。アップデートが利用できるようになるまで24時間以上かかることもあります。取り得る選択肢は辛抱強く待つか、別のミラーを使うことだけです。[https://www.archlinux.org/mirrors/status/ MirrorStatus] で最新のミラーを確認できます。
   
 
=== 上流のプロジェクト ''X'' が新しいバージョンをリリースしています。Arch パッケージとして新しいバージョンにアップデートできるようになるまでにかかる時間は？ ===
  
=== 上流のプロジェクト ''X'' が新しいバージョンをリリースしています。Arch パッケージとして新しいバージョンにアップデートできるようになるまでにかかる時間は？ ===
160行目: 161行目:
 
パッケージアップデートは準備ができ次第リリースされます。上流リリースがマイナーなバグ修正のみであれば数時間でパッケージがアップデートされることもありますし、メジャーアップデートであれば数週間後となることもあります。上流の新しいバージョンが 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:
  
   
  +
* ライブラリは意味もなくバージョンを変えません。API/ABI が変更されたり(いくつか削除されたり)することがあり、それが使用に影響するかは単に運次第です。
−
* 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.
 +
代わりに、例えば必要なライブラリのバージョンを提供する[https://aur.archlinux.org/packages/?SeB=n&K=compat 互換パッケージ]を使うか、もしくは作ってください。
   
 
==インストール==
  
==インストール==
   
 
=== 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 には Arch Installation Framework (AIF) と呼ばれる、テキストベースのユーザーインターフェースを持ったインストーラがありました。[https://lists.archlinux.org/pipermail/arch-releng/2012-July/002628.html 最後のメンテナが去った]後、[[Arch_Linux#Arch_Install_Scripts|Arch Install Script の推奨により廃止]]されました。
−
Arch ではインストールそのものを滅多に行わないため(read the rest of this article to know more about what ''rolling release'' means)、その優先度は開発者やユーザにとって高くありません。[[インストールガイド]]はコマンドラインから行う方式に全面的に改められました。
 +
Arch ではインストールそのものを滅多に行わないため(この記事の残りを読んで、''ローリングリリース'' の意味することをより理解してください)、その優先度は開発者やユーザにとって高くありません。[[インストールガイド]]はコマンドラインから行う方式に全面的に改められました。
   
 
=== Arch をインストールしたんですが、シェルのログイン画面が表示されてます! どうすれば良いのでしょう？ ===
  
=== Arch をインストールしたんですが、シェルのログイン画面が表示されてます! どうすれば良いのでしょう？ ===
183行目: 183行目:
   
 
=== 他の「ミニマル」なディストリビューションと比べて Arch のどこがユニークなんですか？ ===
  
=== 他の「ミニマル」なディストリビューションと比べて Arch のどこがユニークなんですか？ ===
  +
[[Arch と他のディストリビューションの比較]] を参照してください。
−
See [[en2:Arch compared to other distributions]].
  
   
 
== 64ビット ==
  
== 64ビット ==
   
 
=== 私のプロセッサが x86_64 に対応しているかどうかを知る方法は？ ===
  
=== 私のプロセッサが x86_64 に対応しているかどうかを知る方法は？ ===
  +
使っているプロセッサが [[Wikipedia:ja:X64|x86_64]] に対応している場合、{{ic|/proc/cpuinfo}} の中に{{ic|lm}} ([[Wikipedia:ja:X64#Longモード|Longモード]]) フラグがあります。例えば以下のコマンドを実行してください:
−
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,
  
   
 
$ grep -w lm /proc/cpuinfo
  
$ grep -w lm /proc/cpuinfo
   
−
Under Windows, フリーウェアである [http://www.cpuid.com/cpuz.php CPU-Z] を使って、64ビット互換があるかどうか確認できます。AMD の命令セットである AMD64 または Intel の命令セット EM64T は 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 以上のメモリが載っている場合、only a 64-bit OS will be able to fully utilize it.
 +
多くの状況下で (32ビットに比べて) 高速であり、通常の i686 カーネルでは PAE が無効化されているために利用できない[[wikipedia:ja:アドレス空間配置のランダム化|アドレス空間配置のランダム化 (ASLR)]] や [[wikipedia:ja:位置独立コード|位置独立コード (PIC)]]、[[wikipedia:ja:NXビット|NX ビット]]を使用することによりセキュリティが向上することが挙げられます。もしコンピューターに 4GB 以上のメモリが載っている場合、64ビットの OS のみが全てを活用することができます。
   
 
更に、64ビットの拡張をサポートしている新しい x86 CPU に対して、レガシーな32ビットの CPU をプログラマーがサポートしなくなってきているというのもあります。
  
更に、64ビットの拡張をサポートしている新しい x86 CPU に対して、レガシーな32ビットの CPU をプログラマーがサポートしなくなってきているというのもあります。

2020年3月16日 (月) 13: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 は 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 には他のアプリケーションがパッケージ情報を簡単に参照するためのライブラリが必要だ

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

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

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

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

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

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

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

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

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

en2: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 Script の推奨により廃止されました。 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ビットの方が優れているものは他にもたくさんあり、全てをここに書き出す事は出来ません。

「https://wiki.archlinux.jp/index.php?title=FAQ&oldid=15718」から取得