「FAQ」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
imported>Kuroyagi
(New page: Category:About Arch (日本語) Category:FAQs (日本語) {{FAQ i18n Links}} ここで解決されない疑問等については、The Arch Way (日本語)、[[Arch Linux (日...)
 
(→‎アップグレードの前にやっておいたほうがいい事はありますか?: 言語間リンクのプレフィックスを en2: から :en: に修正)
 
(15人の利用者による、間の93版が非表示)
1行目: 1行目:
[[Category:About Arch (日本語)]]
+
[[Category:Arch について]]
  +
[[ar:Frequently asked questions]]
[[Category:FAQs (日本語)]]
 
  +
[[bg:Frequently asked questions]]
{{FAQ i18n Links}}
 
  +
[[bs:Frequently asked questions]]
  +
[[cs:Frequently asked questions]]
  +
[[da:Frequently asked questions]]
  +
[[de:FAQ]]
  +
[[el:Frequently asked questions]]
  +
[[en:Frequently asked questions]]
  +
[[es:Frequently asked questions]]
  +
[[fa:سؤالات متداول]]
  +
[[fi:Frequently asked questions]]
  +
[[fr:FAQ]]
  +
[[hr:Frequently asked questions]]
  +
[[hu:Frequently asked questions]]
  +
[[id:Frequently asked questions]]
  +
[[it:Frequently asked questions]]
  +
[[ko:Frequently asked questions]]
  +
[[lt:Frequently asked questions]]
  +
[[nl:Frequently asked questions]]
  +
[[pl:Frequently asked questions]]
  +
[[pt:Frequently asked questions]]
  +
[[ru:Frequently asked questions]]
  +
[[sk:Frequently asked questions]]
  +
[[sv:FAQ]]
  +
[[th:Frequently asked questions]]
  +
[[tr:Frequently asked questions]]
  +
[[zh-hans:Frequently asked questions]]
  +
[[zh-hant:Frequently asked questions]]
  +
{{Related articles start}}
  +
{{Related|Arch 用語集}}
  +
{{Related|Arch User Repository#FAQ}}
  +
{{Related|一般的なトラブルシューティング}}
  +
{{Related articles end}}
   
  +
==一般==
ここで解決されない疑問等については、[[The Arch Way (日本語)]]、[[Arch Linux (日本語)]]、[[Devland]]が参考になります。そこでは、Arch Linuxに関するより多くの情報が扱われています。
 
   
  +
=== Arch Linux って何ですか? ===
= 一般 =
 
  +
[[Arch Linux]] を参照してください。
   
  +
=== 私は Arch を使うべきではありませんか? ===
==Q) 当方全くのGNU/Linuxビギナーなのですが、Archを使って大丈夫でしょうか? ==
 
  +
以下のような方は Arch を使いたいとは思わないでしょう:
'''A)''' これに関してはかなりの議論があります。Archは、ある程度熟練したGNU/Linuxユーザーを対象にしていますが、「Archこそ入門にもってこいだ」と考えるような人もいます。もしあなたがビギナーで、それでもなおArchを使おうとしているのであれば、あなたは学ぶことに喜びを覚えるようでなければなりません。また、Archが優れて"Do-It-Yourself"なディストリビューションである、ということも肝に命じておくべきでしょう。システムを組み上げ、それがどのようなものにしていくかをコントロールするのは、ユーザー自身なのです。質問をする前に、まず自分で調査するようにしてください。googleや、Wiki、フォーラムの検索を活用しましょう(過去のFAQも参照してください)。以上のことさえ実践していれば、まず困ることはありません。また、多くの人が同じ基本的質問に何度も繰り返して答えさせられることに嫌気がさしているのだ、ということも理解しておいてください。あなたは今、その当事者なのです。伊達や酔狂でこのような文書が作成され、入門者に利用してもらえるよう設置されているわけではありません。途方もない時間が、この貴重な情報を編集するために、無償で費やされているのです。要通読:[[Beginners Guide|Beginners' Guide]].
 
  +
* 'do-it-yourself' な GNU/Linux ディストリビューションを使う能力や時間がない、あるいはそれを求めていない方。
  +
* x86_64 以外のアーキテクチャのサポートが必要な方。
  +
* GNU で定義されたフリーウェアのみを提供するディストリビューションを使うことに強いこだわりのある方。
  +
* オペレーティングシステム自身が構成設定を行うべきであり、"箱から出してすぐ使える" べきであり、インストールメディア上でソフトウェアやデスクトップ環境のデフォルト設定が完全になされているべきであるとお考えの方。
  +
* 最先端で、ローリングリリースな GNU/Linux を求めていない方。
  +
* 今使っている OS に満足している方。
   
  +
=== Arch はどのアーキテクチャをサポートしていますか? ===
==Q) Archはホント好きなんだけどね。開発チームが''X''の機能さえ実装してくれればなぁ。==
 
  +
Arch は x86_64 (別名 amd64) アーキテクチャのみをサポートしています。i686 のサポートは2017年11月に切られました [https://www.archlinux.jp/news/the-end-of-i686-support/]。
'''A)''' ちょっと待った。ちゃんと[[The Arch Way (日本語)]]は、読みましたか?あなたは、その機能/対処方法を提示したのですか?それは、''ミニマリズム''や、''利便性に先んじるコードの整合性''、と言ったArchの哲学と一致するでしょうか?どうぞ積極的に参加してください。あなた自身がコードや解決策を提示することでコミュニティに貢献しましょう。もし、コミュニティや開発チームから認められれば、あなたのコードはマージされるかも知れません。Archコミュニティは、コードやツールの提供、シェアによって活性化していきます。
 
   
  +
''非公式'' の移植プロジェクトとしては、i686 アーキテクチャ向けの [https://archlinux32.org/] や [[Wikipedia:jja:ARMアーキテクチャ|ARM]] CPU 向けの [http://archlinuxarm.org/] などがあり、それぞれ専用のコミュニティを持っています。[http://ix.io/73w/irc]
==Q) いつ新しいメジャー・リリースが出るんでしょうか?==
 
'''A)''' Arch Linuxにおけるメジャー・リリースとは、coreリポジトリの単なるsnapshotを意味するに過ぎません。インストーラ・スクリプトの様々な機能や操作抜きに、これについて語ることはできません。ローリング・リリースモデルは、ひとつのコマンドの実行によって、あらゆるArch Linuxのシステムを、最新かつ最先端に保つものです。
 
   
  +
=== Arch は Linux Foundation の標準ファイルシステム階層 (FHS) に準拠していますか? ===
このことから、Archにおけるメジャー・リリースというのは、さほど重要なものではないと言えます。なぜと言って、ローリング・リリースシステムは、パッケージがアップデートされるや否や、すぐさま最新のメジャー・リリースを旧バージョンにしてしまうわけですから。もし最新のArch Linuxのリリースを手に入れたいのだとしても、再インストールなどする必要はありません。シンプルに"pacman -Syu" のコマンドを実行するだけで、あなたはまっさらなインストールを実行した結果構築されるそれと、同一のシステムを手に入れることになるでしょう。
 
  +
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 を使って大丈夫でしょうか? ===
また同じ理由から、新しいArch Linuxのリリースというのは、一般的に理解されているように、真新しくてエキサイティングな機能を満載したものではありません。そうした真新しくエキサイティングな機能群のリリースは、必要に応じたパッケージのアップデートによってもたらされるものであり、それは"pacman -Syu"のコマンドによって即座に反映されるのです。
 
  +
もしあなたが初心者で、それでもなお Arch を使おうとしているのであれば、あなたは十分な時間を費やして学ぶことに喜びを覚えるようでなければなりません。また Arch が全く "Do-It-Yourself" なディストリビューションとして設計されている、ということも肝に命じておくべきでしょう。システムを組み上げ、それをどのようなものにしていくかをコントロールするのはユーザー自身なのです。
   
  +
質問をする前にまず自分で調査するようにしてください。Google やフォーラム、そして素晴らしいドキュメントが用意されている Arch Wiki の検索を活用しましょう。''そのような情報が使える状態になっているのには理由があります。'' 途方もない時間がこの貴重な情報を編集するために無償で費やされているのです。
==Q) Arch Linuxは堅牢なディストリなのでしょうか?しょっちゅう壊れたりしないのでしょうか?==
 
'''A)''' 答えはyesでもあり、noでもあります。つまり、それは概ね''あなた''がどれだけそれ堅牢にするかに懸かっている、と言えます。
 
   
  +
[[Arch 用語集#RTFM]] や [[インストールガイド]] も見てください。
独自のArchシステムをシンプルな基本環境の上に構築するのは、''あなた''であり、.システムの成長をコントロールしていくのも、''あなた''なのです。当然、多くのパッケージや、複数のツールキット、デスクトップ環境などを統合して、巨大に膨れ上がったシステムは、スリムでよりシンプルなそれに比べて、アップストリームの変更に関わるため、より設定の問題に悩まされる可能性が高くなります。UNIXに関する一般的な素養や、上手なシステム管理、適切なアップグレードの実施といったものは、システムの堅牢にしていく上で、非常に大きな役割を担います。Archのパッケージの大部分がパッチを施されていない、ということにも留意してください。大部分の問題は、おおよそアップストリームに起因するものです。
 
従って、個人のローリング・リリースシステムの堅牢性に関して、最終的な責任を負うのは''ユーザー自身''です。ユーザーが、いつアップグレードするのかを決め、必要な時に必要な変更をマージするのです。もしユーザーがコミュニティに助けを求めれば、救いの手は直ちに差し伸べられることでしょう。これに関して、Archと他のディストリビューションで異なる点は、Archが本当に"Do-it-yourself"なディストロであることでしょう。破損についてクレームをつけるのは、見当違いであり、非生産的です。なぜといって、アップストリーム・チェンジに関して、Arch開発チームは責任を負いかねるからです。
 
   
  +
=== Arch はどの用途向けに設計されていますか?サーバですか?デスクトップですか?ワークステーションですか? ===
==Q) よく耳にする”BSDスタイル”initフレームワークって厳密にはどういうものなの? ==
 
  +
Arch は特定の用途向けに設計されているわけではありません。むしろ、特定の "ユーザ" 向けに設計されています。Arch はなんでも自分でやることを楽しみ、各自のニーズに応じたシステムを構築するためにそれをよりよく活用する、やる気のあるユーザを対象にしています。したがって、その目的はユーザの思いのままであり、Arch は事実上あらゆる用途で使用できます。多くの人々が Arch をデスクトップとワークステーション両方で使用しています。そしてもちろん、archlinux.org は Arch で動いています。
   
  +
=== Arch はホント好きなんだけどね.開発チームがXの機能さえ実装してくれればなぁ ===
30年以上に渡るBSDの財産の一つに、組み込みのシンプルなinitフレームワークがあります。大部分が変更されずに、そのまま受け継がれてきました(GNU/Linuxのシステムに採用されているSysV initが姿を現すのは、ずっと後のことです)。Archが採用するBSDスタイルinitの主な特徴は、あらゆるランレベルにおける、すべてのシステム・サービスのシェルスクリプトを、ひとつのディレクトリ(/etc/rc.d/)に納め、それを一つのファイル(/etc/rc.conf/)で管理している点です。これに対してSysV initでは、各ランレベルごとに"/etc/rc.0,1,2,3,4,5,6"のようなディレクトリが用意され、その中に複雑に入り組んだシンボリックリンクが配置されます。それぞれのサービスとシンボリックリンクは、/etc/init.d/内のシェルスクリプトを参照しています。言うまでもなく、SysV方式の方がより複雑で、各/etc/rcディレクトリ内には往々にして大量のシンボリックリンクが張られることになります。シンプルたらんことを追求する哲学に従って、ArchはBSDスタイルinitを採用しているのです。
 
  +
どうぞ積極的に参加してください.あなた自身がコードや解決策を提示することでコミュニティに貢献しましょう.もし,コミュニティや開発チームから認められれば,あなたのコードはマージされるかも知れません.Archコミュニティはコードやツールの提供,シェアによって活性化していきます.
   
  +
=== いつ新しいリリースが出るんでしょうか? ===
==Q) Archのレビュー記事がもっと必要だ。(宣伝が必要だ)==
 
  +
Arch Linux におけるリリースは単にインストールおよびレスキュー用のライブ環境で、{{Pkg|base}} メタパッケージとその他いくつかの [https://projects.archlinux.org/archiso.git/tree/configs/releng/packages.x86_64 パッケージ]が含まれています。リリースは通常各月の前半頃に公開されます。
'''A)''' 現状でもう十分な量のArchについての記事が書かれています。Archの目標は、巨大になることではありません。シンプルさと、コードの整合性に焦点を絞った、エレガントで、最小かつ最新のディストリビューションを提供することこそが、その目標なのです。Archが対象とするユーザー・ベース自体が自然と発展しています。それを強制したところで、問題の種を蒔くことになるだけでしょう。
 
   
  +
=== Arch Linux は堅牢なディストリなのでしょうか?しょっちゅう壊れたりしませんか? ===
同様に、Archの開発モデルは、自然な発展を制限するものではありません。より多くのユーザーを得ることは、より多くの開発者がArch Linuxに関わることを意味します。これによって上層部における組織的な問題が発生すこともあるかも知れませんが、それはその時に対処すれば良いことです。
 
  +
ローリングリリースで構築された個人のシステムの堅牢性に関して、最終的な責任を負うのは''ユーザー自身''です。ユーザーがいつアップグレードするのかを決め、必要な時に必要な変更をマージするのです。もしユーザーがコミュニティに助けを求めれば、救いの手はすぐに差し伸べられることが多いでしょう。この点に関して、Arch が他のディストリビューションから異なっているのは、Arch が本当に "Do-it-yourself" なディストロであることでしょう。破損についてクレームをつけるのは見当違いであり、非生産的です。アップストリームでの変更に関して Arch 開発チームは責任を負いかねるからです。
   
  +
可能な限り安定する Arch Linux システムを構成するための方法やヒントについては、[[システムメンテナンス]]を参照してください。
   
==Q) Archの開発者がもっと必要だ==
+
=== Archのレビュー記事がもっと必要だ(宣伝が必要だ) ===
  +
現状でもう十分な量のArchについての記事が書かれています.Archの目標は巨大になることではなく、持続的な成長が対象のユーザーベースの間で自然に起きることです。
'''A)''' そうかも知れませんね。もっと柔軟にあなたの時間を使って貢献してください!フォーラムや、IRC、メーリング・リストなどに参加すれば、成すべきことがわかるはずです。
 
ドキュメントの作成者などは、常に必要です。ぜひWikiに寄稿してください。
 
   
  +
=== Archの開発者がもっと必要だ ===
==Q) Why is Arch so slow? I thought it's supposed to be fast!==
 
  +
そうかも知れませんね.もっと柔軟にあなたの時間を使って貢献してください! [https://bbs.archlinux.jp/ フォーラム]や,[[IRC チャンネル]],[https://mailman.archlinux.org/mailman/listinfo/ メーリングリスト]などに参加すれば,成すべきことがわかるはずです.まずは、Community Contributions サブフォーラムに参加してみてください.
'''A)''' Make sure that your hostname is correctly set in /etc/hosts (i.e., that it matches the hostname in /etc/rc.conf. Have a look at "Configure the System" in The [[Beginners_Guide]]). If the hostnames do not match, applications may start up very slowly.
 
   
  +
=== 他のOSに比べてインターネットの速度が遅いんだけど、どうして? ===
==Q) Why is my internet so slow compared to other operating systems?==
 
  +
ネットワークは正しく設定されていますか?[[ネットワーク設定]]のページを参照してください。
'''A)''' Is your network configured correctly? Have you double checked your /etc/rc.conf /etc/hosts and /etc/resolv.conf? Have a look at "Configure the System" in The [[Beginners_Guide]].
 
   
  +
また、Arch ではデフォルトで[[Wikipedia:ja:トラフィックシェーピング|トラフィックシェーピング]]が有効になっていないことも注意してださい。従って、(P2P 上か通常のクライアント-サーバー通信かに関わらず)ネットワーク帯域を使い果たすプログラムは、ローカルの他のソフトの通信を妨げ、ひどいラグやタイムアウトのような結果になる可能性があります。 Shorewall や Vuurmuur などの[[ファイアウォール]]や、 {{Pkg|iproute2}} の静的なスクリプト(例えば ''Wondershaper'' の [http://serendipity.ruwenzori.net/index.php/2008/06/01/modified-wondershaper-for-better-voip-qos 派生]) によってネットワークレイヤーのシェーピングを行うことができます。
=Package Management=
 
   
  +
=== なんで Arch は RAM を全部使っちゃうわけ? ===
==Q) I've found an error with Package X. What should I do?==
 
  +
そもそも、使わない RAM は無駄な RAM です。
'''A)''' First, you need to figure out if this error is something the Arch team can fix. Sometimes it's not (that Firefox crash may be the fault of the Mozilla team) - this is called an ''upstream error''. If it is an Arch problem, there is a series of steps you can take:
 
#Search the forums for information. See if anyone else has noticed it.
 
#Notify the package maintainer. Try a "pacman -Qi <package name>" for this info.
 
#Post a bug report with detailed information at http://bugs.archlinux.org.
 
#If you'd like, write a forum post detailing the problem and the fact that you have reported it already. This will help prevent a lot of people from reporting the same error.
 
   
  +
新米ユーザの方の多くは、Linux カーネルのメモリの扱い方が以前の方法と必ずしも同じにはならないことに気がつきます。RAM 上のデータへのアクセスはディスクに比べ非常に高速なので、カーネルは最近アクセスされたデータをメモリ上にキャッシュします。キャッシュされたデータは、利用可能なメモリを使い果たして、新しいデータがロードされる必要のある時のみクリアされます。
==Q) Will Arch have a database for pacman?==
 
'''A)''' Possibly. There is discussion over the issue. <br>
 
http://bbs.archlinux.org/viewtopic.php?id=11193 <br>
 
http://bbs.archlinux.org/viewtopic.php?id=10898 <br>
 
Look at http://bugs.archlinux.org/task/5328, too.
 
   
  +
{{ic|free}} コマンドによって違いを見分けることができます:
==Q) Arch packages need to use a unique naming convention. .pkg.tar.gz is too long and/or confusing==
 
'''A)''' This has been discussed on the Arch mailing list. Some proposed a .pac file extension. As far as is currently known, there is no plan to change the package extension.
 
As Tobias Kieslich, one of the Arch devs, put it, "A package '''is''' a gzipped tarball! And it can be opened, investigated and manipulated by any tar-capable application. Moreover, the mime-type is automatically detected correctly by most applications."
 
   
  +
{{hc|$ free -h|
==Q) Pacman needs a library so other applications can easily access package information==
 
  +
total used free shared buff/cache available
'''A)''' Since version 3.0.0, pacman has been the front-end to libalpm, the "Arch Linux Package Management" library. This library allows alternative front-ends to be written (for instance, a GUI front-end).
 
  +
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) Why doesn't Pacman have an official GUI front-end?==
 
'''A)''' Please read [[The Arch Way]] and [[Arch Linux]] and [[Devland]]. The answer is basically that the Arch dev team will not be providing one. Feel free to use one of those developed by users. There is a nice list of them on the [[UserContributionsPage]] in the links section, and a selective list on [[Pacman GUI Frontends]].
 
   
  +
もしあなたの好奇心が刺激されたなら、[https://www.linuxjournal.com/article/2770 こちらの素晴らしい記事]も読んでみてください。こちらのウェブサイトでもこの混乱を整理して説明しています: http://www.linuxatemyram.com/
==Q) Pacman needs Feature X!==
 
'''A)''' Please read [[The Arch Way]] and [[Arch Linux]] and [[Devland]]. The Arch philosophy is "Keep It Simple". If you think the idea has merit, and does not violate this simple litany, then by all means, discuss it on the forum [http://bbs.archlinux.org/ here]. You might also like to check [http://bugs.archlinux.org here]; it's a place for feature requests if you find it is important.
 
   
  +
=== わたしのディスクの空き領域はどこへ行ってしまったの? ===
However, the best way to get a feature added to Pacman or Arch Linux is to implement it yourself. There's no telling whether the patch will be officially accepted, but others will appreciate and test your effort.
 
  +
その答えはあなたのシステムによって変わります。[[アプリケーション一覧#ディスク使用量表示プログラム|こちらに優れたユーティリティの一覧があります]]ので試してみてください。
   
  +
==パッケージ管理==
==Q) Arch needs a stable package branch==
 
'''A)'''
 
Never say never.
 
Some of the many discussions on the topic: <br>
 
http://bbs.archlinux.org/viewtopic.php?id=11288
 
   
  +
[[pacman]], [[Pacman ヒント]], [[公式リポジトリ]] により多くの答えがあります。
==Q) What's the difference between all these repositories?==
 
'''A)''' See [[The Arch Linux Repositories]].
 
   
  +
=== Xのパッケージにエラーがあったんだけど,どうしたらいいの? ===
  +
まず,そのエラーはそもそもArch開発チームが修正できるものなのかどうかを見極めなければなりません.そうでない場合が往々にしてあります(例えばFirefoxのクラッシュは大抵の場合Mozillaチームのミスです).これを ''アップストリーム・エラー'' と言います.もしArchの問題であるならば以下の手順を参考に対処してください.:
  +
# フォーラムに情報がないか探してみましょう.誰かが同じ問題について気付いていないかチェックしてください.
  +
# 詳細な情報を書いた[[バグ報告ガイドライン|バグレポート]]を https://bugs.archlinux.org に投稿してください.
  +
# もしお望みならば,フォーラムに質問を投げてみてもよいでしょう.その際,問題の詳細と,あなたが既にバグ・レポートを送った旨を明記してください.それによって同じエラーに関する報告が大量に投稿されるようなケースを回避できます.
   
  +
=== Archのパッケージにはもっと適切な命名規則が必要だ。".pkg.tar.gz" とか ".pkg.tar.xz" なんて長すぎるし、ややこしい ===
  +
これに関しては、Arch のメーリングリスト上で議論されています。{{Ic|.pac}} のような拡張子を提案する人もいますが、現段階では、パッケージの拡張子を変更する具体的な計画はありません。Arch 開発者の一人である Tobias Kieslich の発言は示唆的です。「事実 package は gzip や xz で圧縮された tarball ファイルなわけじゃないか! だいたい tar が扱えるアプリケーションなら何だって開くことができるし、覗いて弄ることだってできるんだしさ。もっと言えば、mime-type なんてたいがいのアプリケーションが問題なく自動判別できるだろ?」
   
  +
=== Pacman には他のアプリケーションがパッケージ情報を簡単に参照するためのライブラリが必要だ ===
==Q) I just installed Package X. How do I start it?==
 
  +
[[pacman]] は [https://www.archlinux.org/pacman/libalpm.3.html libalpm] ("Arch Linux Package Management" library) のフロントエンドになっています。このライブラリは代替のフロントエンドの開発を可能にしています (例えばGUIフロントエンドのような)。
'''A)''' If you're using a desktop environment like KDE or GNOME, the program should automatically show up in your menu. If you're trying to run the program from a terminal and don't know the binary name, try executing "pacman -Ql packagename | grep bin". A common problem for packages like Firefox or OpenOffice is that they are installed to /opt, which is not in your $PATH - you can "source /etc/profile" or logout/login to fix this.
 
   
  +
=== Pacman に X の機能を付けるべきだ! ===
=Installation=
 
  +
そのアイデアにメリットがあると思うのであれば、[https://lists.archlinux.org/listinfo/pacman-dev/ pacman-dev] で議論することができます。既存の機能リクエストがないか https://bugs.archlinux.org/index.php?project=3 も確認してみてください。
   
  +
もっとも,ある機能をPacmanやArch Linuxに追加するために一番良い方法は,あなた自身がそれを実装することです.そのパッチがオフィシャルに取り込まれるかどうかはわかりませんが,いずれにせよあなたの骨折りは他のユーザーによって吟味され,検討されるでしょう.
==Q) Arch needs a better installer. Maybe a GUI installer.==
 
'''A)''' The discussion of a "better" installer is a subjective opinion. The best way to cope with these issues it to fit the installer to "the Arch way". If this opinion on a better installer is backed with more-concrete arguments, it might be taken into account for further development of the installer. Since installation doesn't occur often (see the question above on rolling release), it is not a high priority for developers or users.
 
However, two unofficial methods exist: [http://archie.dotsrc.org/ Archie Live CD] for XFCE (other desktops in development) and [http://user-contributions.org/wikis/userwiki/index.php?title=Arch_Linux_Office_Install_CD Arch Linux Office Install CD] for KDE.
 
   
  +
=== X のパッケージをインストールしたんだけど,どうやって起動するの? ===
==Q) I installed Arch, and now I am at a bash login! What now?==
 
  +
あなたが [[KDE]] や [[GNOME]] のようなデスクトップ環境を導入しているのなら、そのプログラムは自動的にメニューに登録されている筈です。ターミナルから起動しようとしていて、バイナリの名前がわからないというような場合は、次のコマンドで確認してください:
'''A)''' Have a look at the Arch Linux [[Beginners_Guide]]
 
   
  +
$ pacman -Qlq ''パッケージ名'' | grep /usr/bin/
==Q) Arch is touted as a distribution which is built up from a minimal base system, installing only what is required by the user. Isn't this possible with virtually any distribution? What makes Arch unique in this regard?==
 
   
  +
=== 公式リポジトリにある共用ライブラリはそれぞれどうして一つのバージョンしか用意されてないんですか? ===
'''A)''' A few distributions may provide minimal installation methods similar in design to the Arch installation process. However, a few points must be noted:
 
# Arch has been fundamentally designed as a lightweight, minimal environment upon which to build.
 
# Whether the FTP or Core images are used, the only way to install Arch is by building up from this minimal base.
 
# The installation, as well as the entire distribution is inherently a K.I.S.S. design approach, which makes it uniquely suitable for its target base of users.
 
# The simple Arch installer is designed for a high level of transparency and the base system is manually configured by the user to their needed specifications.
 
# Arch provides thoroughly complete documentation to guide one through this process of system assembly.
 
   
  +
Debian などの一部のディストリビューションは、共用ライブラリパッケージにおいて {{ic|libfoo1}}、{{ic|libfoo2}}、{{ic|libfoo3}} といったように複数のバージョンを用意しています。この方法では同一のシステム上で異なるバージョンの libfoo ごとにアプリケーションのコンパイルが可能となります。
=Other=
 
   
  +
Arch のようなディストリビューションの場合、すべてのパッケージで公式にサポートされているのは最新バージョンのみであることを意味します。過去のソフトウェアをサポートしないことで、パッケージメンテナは最新のバージョンが期待通りに動くことの検証に割く時間をより多くとることができます。共有ライブラリの新しいバージョンがアップストリームからリリースされると、それはすぐにリポジトリに追加され、影響を受けるパッケージは新しいライブラリに合わせてリビルドされます。
==Q) I get an error every time I use pacman saying 'warning: current locale is invalid; using default "C" locale'. What do I do?==
 
'''A)''' As the error message says, your locale isn't correctly configured. Have a look at the [[Configuring locales|locale configuration wiki page]].
 
   
  +
=== もし、システム全体のアップグレード({{ic|pacman -Syu}})で共用ライブラリがアップデートされたのにそれに依存するアプリケーションがアップデートされなかったらどうなりますか? ===
==Q) How do I automount/mount something? ==
 
'''A)''' If you use GNOME, install gnome-volume-manager:
 
pacman -Sy gnome-volume-manager
 
   
  +
それは起こってはならないシナリオです。公式リポジトリに {{ic|foobaz}} というアプリケーションがあり、{{ic|libbaz}} という共用ライブラリの新バージョンを使用してビルドされているとして、それは {{ic|libbaz}} のアップデートに合わせてアップデートされます。しかしもし、if it does not build successfully、そのパッケージ {{ic|foobaz}} にはバージョン制限のある依存関係 (例: libbaz=1.5) が指定され、{{ic|libbaz}} のアップグレードの際に pacman によってコンフリクトを理由に削除されます。
Now add yourself to the storage group:
 
gpasswd -a ''your_user'' storage
 
   
  +
もし {{ic|foobaz}} が、あなた自身でビルドした、あるいは AUR からインストールしたパッケージであった場合には、新バージョンの {{ic|libbaz}} で {{ic|foobaz}} をリビルドしてみてください。ビルドが失敗した場合には {{ic|foobaz}} の開発者にそのバグを報告してください。
If you don't want to use gnome-volume-manager, check out [[Ivman]] or [[autofs | AutoFS]].
 
   
  +
=== リポジトリのカーネルにメジャーアップデートがあったのに、ドライバが最新カーネル用にアップデートされないことはあり得ますか? ===
==Q) How do I connect to my wireless network?==
 
'''A)''' See [[Wireless Setup]].
 
   
  +
いいえ、ありえません。例えば {{ic|3.5.x}} から {{ic|3.6.x}} といったカーネルのメジャーアップデートは常にすべてのサポートカーネルドライバのリビルドを伴います。ただし、{{AUR|catalyst}} などの非サポートパッケージを使用している場合には、最新のカーネルでそれをリビルドしなければトラブルが発生するかもしれません。サポートされていないドライバパッケージは、インストールしているユーザーがアップデートに全ての責任を負います。
==Q) How do I connect to my wired network?==
 
'''A)''' See [[Configuring network]].
 
   
  +
=== アップグレードの前にやっておいたほうがいい事はありますか? ===
==Q) What is this AUR thing I keep hearing about?==
 
  +
[[:en:System maintenance#Upgrading the system]] セクションに従ってください。
'''A)''' See [[AUR Q & A]].
 
   
  +
=== パッケージのアップデートがリリースされているのに、pacman はシステムは最新だと出力する ===
==Q) Why do I get a green screen whenever I try to watch a video?==
 
'''A)''' Your colour depth is set wrong. It may need to be 24 instead of 16, for example.
 
   
  +
''pacman'' のミラーはすぐに同期されるわけではありません。アップデートが利用できるようになるまで24時間以上かかることもあります。取り得る選択肢は辛抱強く待つか、別のミラーを使うことだけです。[https://www.archlinux.org/mirrors/status/ MirrorStatus] で最新のミラーを確認できます。
==Q) Spellcheck is marking all of my text as incorrect!==
 
  +
'''A)''' Have you installed an aspell dictionary? Use <tt>pacman -Ss aspell</tt> to see the available dictionaries.
 
  +
=== 上流のプロジェクト ''X'' が新しいバージョンをリリースしています。Arch パッケージとして新しいバージョンにアップデートできるようになるまでにかかる時間は? ===
  +
  +
パッケージアップデートは準備ができ次第リリースされます。上流リリースがマイナーなバグ修正のみであれば数時間でパッケージがアップデートされることもありますし、メジャーアップデートであれば数週間後となることもあります。上流の新しいバージョンが Arch にリリースされるまでの時間はそのパッケージとパッケージメンテナによって変わります。一部のパッケージは [[testing]] リポジトリでしばらくテストされるため、パッケージが更新されるまでの時間が長い傾向にあります。[[Arch 用語集#パッケージメンテナ|パッケージメンテナ]]は安定版のアップデートをリポジトリで素早く提供できるように尽力しています。公式リポジトリのパッケージが古くなっていることに気づいたら、[https://www.archlinux.org/packages/ パッケージウェブサイト] から out-of-date フラグを立てて報告してください。
  +
  +
=== インストールしているライブラリの古いバージョンが必要なときは、新しいバージョンにシンボリックリンクを貼るだけでいいですか? ===
  +
幸運であれば少しの間それで動くかもしれません。動いたとしても、以下の理由でそれは正しい解決法ではありません:
  +
  +
* ライブラリは意味もなくバージョンを変えません。API/ABI が変更されたり(いくつか削除されたり)することがあり、それが使用に影響するかは単に運次第です。
  +
* シンボリックリンクはパッケージマネージャによって管理されません。すぐにシステムライブラリのファイルをハックしようとする初心者は、診断・修正が不可能な意図していない変更を加える大きなリスクを持っています。パッケージマネージャはこのような問題から守る手助けをしています。
  +
* 古いライブラリファイルをファイルシステムにコピーする代替手段もありますが、追跡されない上に忘れられやすく、潜在的なセキュリティのバグが気付かれず、また修正されません。
  +
  +
代わりに、例えば必要なライブラリのバージョンを提供する[https://aur.archlinux.org/packages/?SeB=n&K=compat 互換パッケージ]を使うか、もしくは作ってください。
  +
  +
==インストール==
  +
  +
=== Arch はもっと良いインストーラーを付けるべきだ。たとえば GUI インストーラーとか ===
  +
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 ではインストールそのものを滅多に行わないため(この記事の残りを読んで、''ローリングリリース'' の意味することをより理解してください)、その優先度は開発者やユーザにとって高くありません。[[インストールガイド]]はコマンドラインから行う方式に全面的に改められました。
  +
  +
=== 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
  +
  +
Windows 上では、 フリーウェアである [http://www.cpuid.com/cpuz.php CPU-Z] を使って、64ビット互換があるかどうか確認できます。AMD の命令セットである AMD64 または Intel の命令セット EM64T は x86_64 のバイナリと互換性があります。
  +
  +
=== 64ビットにする理由は? ===
  +
多くの状況下で (32ビットに比べて) 高速であり、通常の i686 カーネルでは PAE が無効化されているために利用できない[[wikipedia:ja:アドレス空間配置のランダム化|アドレス空間配置のランダム化 (ASLR)]] や [[wikipedia:ja:位置独立コード|位置独立コード (PIC)]]、[[wikipedia:ja:NXビット|NX ビット]]を使用することによりセキュリティが向上することが挙げられます。もしコンピューターに 4GB 以上のメモリが載っている場合、64ビットの OS のみが全てを活用することができます。
  +
  +
更に、64ビットの拡張をサポートしている新しい x86 CPU に対して、レガシーな32ビットの CPU をプログラマーがサポートしなくなってきているというのもあります。
  +
  +
以上の理由が32ビット環境を避けるべきという我々のアドバイスですが、カーネルやユーザースペース、個々のプログラムなど、64ビットの方が優れているものは他にもたくさんあり、全てをここに書き出す事は出来ません。

2020年3月22日 (日) 14:04時点における最新版

関連記事

目次

一般

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

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