「FAQ」の版間の差分
imported>Kynikos.bot (Template:i18n is deprecated, use intelanguage links, see Help talk:I18n#"Dummy" interlanguage links and deprecation of Template:i18n) |
Kusakata.bot (トーク | 投稿記録) 細 (文字列「http://archlinuxarm.org」を「https://archlinuxarm.org」に置換) |
||
(8人の利用者による、間の44版が非表示) | |||
1行目: | 1行目: | ||
− | [[Category: |
+ | [[Category:Arch について]] |
+ | [[ar:Frequently asked questions]] |
||
− | [[Category:FAQs (日本語)]] |
||
+ | [[bg:Frequently asked questions]] |
||
− | [[Category:日本語]] |
||
+ | [[cs:Frequently asked questions]] |
||
− | [[bg:FAQ]] |
||
+ | [[da:Frequently asked questions]] |
||
− | [[cs:FAQ]] |
||
− | [[da:FAQ]] |
||
[[de:FAQ]] |
[[de:FAQ]] |
||
+ | [[el:Frequently asked questions]] |
||
− | [[en:FAQ]] |
||
+ | [[en:Frequently asked questions]] |
||
− | [[es:FAQ]] |
||
− | [[ |
+ | [[es:Frequently asked questions]] |
+ | [[fa:سؤالات متداول]] |
||
+ | [[fi:FAQ]] |
||
[[fr:FAQ]] |
[[fr:FAQ]] |
||
− | [[hr: |
+ | [[hr:Frequently asked questions]] |
− | [[id: |
+ | [[id:Frequently asked questions]] |
− | [[it: |
+ | [[it:Frequently asked questions]] |
− | [[ko: |
+ | [[ko:Frequently asked questions]] |
− | [[lt: |
+ | [[lt:Frequently asked questions]] |
− | [[nl: |
+ | [[nl:Frequently asked questions]] |
− | [[pt: |
+ | [[pt:Frequently asked questions]] |
[[ro:Întrebări frecvente]] |
[[ro:Întrebări frecvente]] |
||
− | [[ru: |
+ | [[ru:Frequently asked questions]] |
− | [[sk: |
+ | [[sk:Frequently asked questions]] |
− | [[ |
+ | [[sv:FAQ]] |
+ | [[th:Frequently asked questions]] |
||
[[tr:Sss]] |
[[tr:Sss]] |
||
− | [[zh- |
+ | [[zh-hans:Frequently asked questions]] |
− | [[zh- |
+ | [[zh-hant:Frequently asked questions]] |
+ | {{Related articles start}} |
||
− | {{Temporary i18n}} |
||
+ | {{Related|Arch 用語集}} |
||
− | ここで解決されない問題等については,[[The Arch Way (日本語)]],[[Arch Linux (日本語)]]が参考になります.そこではArch Linuxに関するより多くの情報が扱われています. |
||
+ | {{Related|Arch User Repository#FAQ}} |
||
+ | {{Related|一般的なトラブルシューティング}} |
||
+ | {{Related articles end}} |
||
+ | ここで解決されない問題等については,[[The Arch Way]],[[Arch Linux]] が参考になります.そこでは Arch Linux に関するより多くの情報が扱われています. |
||
==一般== |
==一般== |
||
− | === |
+ | === Arch Linux って何ですか? === |
− | + | [[Arch Linux]] を参照してください。 |
|
− | === |
+ | === 私は Arch を使うべきですか? === |
− | + | あなたが [[The Arch Way]] の理念に賛同し、'do-it-yourself' なアプローチを受け入れることができて、そして、シンプルで、エレガントで、高いカスタマイズ性を持ち、最先端の汎用 GNU/Linux ディストリビューションをお探しなら、Arch が気に入るかもしれません。 |
|
− | === |
+ | === 私は Arch を使うべきではありませんか? === |
− | + | あなたが [[The Arch Way]] の理念に賛同できず、'do-it-yourself' な GNU/Linux ディストリビューションを使う能力や時間がない、あるいはそれを求めていないなら、Arch はあなた向けではないかもしれません。 |
|
また、以下のような方も Arch を使いたいとは思わないでしょう: |
また、以下のような方も Arch を使いたいとは思わないでしょう: |
||
− | * x86_64 |
+ | * x86_64 以外のアーキテクチャのサポートが必要な方。 |
* GNU で定義されたフリーウェアのみを提供するディストリビューションを使うことに強いこだわりのある方。 |
* GNU で定義されたフリーウェアのみを提供するディストリビューションを使うことに強いこだわりのある方。 |
||
* オペレーティングシステム自身が構成設定を行うべきであり、"箱から出してすぐ使える" べきであり、インストールメディア上でソフトウェアやデスクトップ環境のデフォルト設定が完全になされているべきであるとお考えの方。 |
* オペレーティングシステム自身が構成設定を行うべきであり、"箱から出してすぐ使える" べきであり、インストールメディア上でソフトウェアやデスクトップ環境のデフォルト設定が完全になされているべきであるとお考えの方。 |
||
45行目: | 51行目: | ||
* 今使っている OS に満足している方。 |
* 今使っている OS に満足している方。 |
||
− | === |
+ | === Arch はどのディストリビューションベースなんですか? === |
− | + | Arch は独自に開発され、他のいかなる GNU/Linux ディストリビューションもベースとしていません。Arch を製作する以前、Judd Vinet は Per Lidén による優れた最小主義ディストリビューションである CRUX を賞賛し使用していました。当初は CRUX と同様のアイデアに触発された Arch ですが、スクラッチビルドされており、[[pacman]] は C 言語で開発されました。 |
|
+ | === Arch はどのアーキテクチャをサポートしていますか? === |
||
− | ===Q) 当方全くの GNU/Linux ビギナーなのですが、Arch を使って大丈夫でしょうか? === |
||
+ | Arch は x86_64 (別名 amd64) アーキテクチャのみをサポートしています。i686 のサポートは2017年11月に切られました [https://www.archlinux.jp/news/the-end-of-i686-support/]。x86_64 の CPU を搭載しているコンピュータで i686 版の Arch を使用している場合は[[#再インストールせずに i686 環境から x86_64 環境にアップグレード出来ますか?]]を見てください。32ビットマシンの場合は [https://archlinux32.org/ Arch Linux 32] に切り替えるという方法があります。 |
||
− | '''A)''' これに関してはかなりの議論があります。Arch はある程度熟練した GNU/Linux ユーザーを対象にしていますが、やる気のある初心者には Arch こそもってこいだ、と考えるような人もいます。もしあなたが初心者で、それでもなお Arch を使おうとしているのであれば、あなたは十分な時間を費やして学ぶことに喜びを覚えるようでなければなりません。また Arch が全く "Do-It-Yourself" なディストリビューションとして設計されている、ということも肝に命じておくべきでしょう。システムを組み上げ、それをどのようなものにしていくかをコントロールするのはユーザー自身なのです。質問をする前にまず自分で調査するようにしてください。Google やフォーラム、そして素晴らしいドキュメントが用意されている Arch Wiki の検索を活用しましょう (過去のFAQも参照してください)。以上のことさえ実践していれば、それほど困難なことはありません。また、多くの人が同じ基本的質問に何度も繰り返して答えさせられることに嫌気がさしているのだ、ということも理解しておいてください。あなたは今まさにその当事者なのです。伊達や酔狂でこのような文書が作成され、入門者に利用してもらえるよう設置されているわけではありません。途方もない時間がこの貴重な情報を編集するために無償で費やされているのです。 |
||
+ | === Arch は ARM CPU をサポートしていますか? === |
||
− | 要通読:[[Beginners Guide|Beginners' Guide]] |
||
+ | いいえ、ただし [https://archlinuxarm.org/ Arch Linux ARM] プロジェクトによって Arch Linux が ARM プラットフォームに移植されています。 |
||
+ | === Arch は [http://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html FHS] に準拠していますか? === |
||
− | ===Q) Arch を使うにはとても手間暇がかかるし、コミュニティはといえば、なにかと言うと RTFM って言うし。=== |
||
+ | Arch Linux は [[systemd]] サービスマネージャを使用するオペレーティングシステムの''ファイルシステム階層''を遵守しています。ディレクトリの説明については {{man|7|file-hierarchy}} を見てください。特に Arch では {{ic|/bin}}, {{ic|/sbin}}, {{ic|/usr/sbin}} は {{ic|/usr/bin}} のシンボリックリンクに、{{ic|/lib}} と {{ic|/lib64}} は {{ic|/usr/lib}} のシンボリックリンクになっています。[[Arch ファイルシステム階層]]も参照してください。 |
||
− | '''A)''' Arch は特定のユーザベースを対象にして設計され、利用されています。おそらくそれがあなたには合っていないのでしょう。 |
||
+ | === 当方全くの GNU/Linux ビギナーなのですが、Arch を使って大丈夫でしょうか? === |
||
− | ===Q) Arch はどの用途向けに設計されていますか? サーバですか? デスクトップですか? ワークステーションですか?=== |
||
+ | これに関してはかなりの議論があります。Arch はある程度熟練した GNU/Linux ユーザーを対象にしていますが、やる気のある初心者には Arch こそもってこいだ、と考えるような人もいます。もしあなたが初心者で、それでもなお Arch を使おうとしているのであれば、あなたは十分な時間を費やして学ぶことに喜びを覚えるようでなければなりません。また Arch が全く "Do-It-Yourself" なディストリビューションとして設計されている、ということも肝に命じておくべきでしょう。システムを組み上げ、それをどのようなものにしていくかをコントロールするのはユーザー自身なのです。質問をする前にまず自分で調査するようにしてください。Google やフォーラム、そして素晴らしいドキュメントが用意されている Arch Wiki の検索を活用しましょう (以下のFAQも参照してください)。以上のことさえ実践していれば、それほど困難なことはありません。また、多くの人が同じ基本的質問に何度も繰り返して答えさせられることに嫌気がさしているのだ、ということも理解しておいてください。あなたは今まさにその当事者なのです。伊達や酔狂でこのような文書が作成され、入門者に利用してもらえるよう設置されているわけではありません。途方もない時間がこの貴重な情報を編集するために無償で費やされているのです。[[Arch 用語集#RTFM]] も見てください。 |
||
− | '''A)''' Arch は特定の用途向けに設計されているわけではありません。むしろ、特定の "ユーザ" 向けに設計されています。Arch はなんでも自分でやることを楽しみ、各自のニーズに応じたシステムを構築するためにそれをよりよく活用する、やる気のあるユーザを対象にしています。したがって、その目的はユーザの思いのままであり、Arch は事実上あらゆる用途で使用できます。多くの人々が Arch をデスクトップとワークステーション両方で使用しています。そしてもちろん、archlinux.org は Arch で動いています。 |
||
+ | === Arch を使うにはとても手間暇がかかるし、コミュニティはといえば、なにかと言うと RTFM って言うし === |
||
− | ===Q) Archはホント好きなんだけどね.開発チームがXの機能さえ実装してくれればなぁ.=== |
||
+ | Arch は特定のユーザベースを対象にして設計され、利用されています。おそらくそれがあなたには合っていないのでしょう。[[#当方全くの GNU/Linux ビギナーなのですが、Arch を使って大丈夫でしょうか?|上のセクション]]も参照してください。 |
||
− | '''A)''' ちょっと待った.ちゃんと[[The Arch Way (日本語)]]は,読みましたか? あなたはその機能/対処方法を提示したみたのですか? それは''ミニマリズム''や,''利便性に先んじるコードの整合性''と言ったArchの哲学と一致するでしょうか? どうぞ積極的に参加してください.あなた自身がコードや解決策を提示することでコミュニティに貢献しましょう.もし,コミュニティや開発チームから認められれば,あなたのコードはマージされるかも知れません.Archコミュニティはコードやツールの提供,シェアによって活性化していきます. |
||
+ | === Arch はどの用途向けに設計されていますか?サーバですか?デスクトップですか?ワークステーションですか? === |
||
− | ===Q) いつ新しいメジャー・リリースが出るんでしょうか? === |
||
+ | Arch は特定の用途向けに設計されているわけではありません。むしろ、特定の "ユーザ" 向けに設計されています。Arch はなんでも自分でやることを楽しみ、各自のニーズに応じたシステムを構築するためにそれをよりよく活用する、やる気のあるユーザを対象にしています。したがって、その目的はユーザの思いのままであり、Arch は事実上あらゆる用途で使用できます。多くの人々が Arch をデスクトップとワークステーション両方で使用しています。そしてもちろん、archlinux.org は Arch で動いています。 |
||
− | '''A)''' Arch Linuxにおけるメジャー・リリースとは,coreリポジトリの単なるスナップショットを意味するに過ぎません.これについては,インストーラ・スクリプトの様々な機能や操作抜きに語ることはできません.ローリング・リリースモデルは,ひとつのコマンド操作によってあらゆるArch Linuxのシステムを最新かつ最先端に保つものです. |
||
+ | === Arch はホント好きなんだけどね.開発チームがXの機能さえ実装してくれればなぁ === |
||
− | このことから,Archにおけるメジャー・リリースというのは,さほど重要な意味を持つものではないと言えます.なぜと言ってローリング・リリースシステムは,パッケージがアップデートされるや否や,すぐさま最新のメジャー・リリースを旧バージョンにしてしまうわけですから.最新のArch Linuxのメジャー・リリースを手に入れたいと思っても,再インストールなどする必要はありません.シンプルに {{ic|pacman -Syu}} のコマンドを実行するだけで,あなたはまっさらなインストールを実行した結果構築されるそれと,同一のシステムを手に入れることになるでしょう. |
||
+ | ちょっと待った.ちゃんと [[The Arch Way]] は,読みましたか? あなたはその機能/対処方法を提示してみたのですか? それは''ミニマリズム''や,''利便性に先んじるコードの整合性''と言ったArchの哲学と一致するでしょうか? どうぞ積極的に参加してください.あなた自身がコードや解決策を提示することでコミュニティに貢献しましょう.もし,コミュニティや開発チームから認められれば,あなたのコードはマージされるかも知れません.Archコミュニティはコードやツールの提供,シェアによって活性化していきます. |
||
+ | === いつ新しいメジャー・リリースが出るんでしょうか? === |
||
− | また同じ理由から,新しいArch Linuxのリリースというのは,一般的に理解されているように真新しくてエキサイティングな機能を満載したものではありません.そうした真新しくエキサイティングな機能群のリリースは,必要に応じたパッケージのアップデートによってもたらされるものであり,それは {{ic|pacman -Syu}} のコマンドによって即座に反映されるのです. |
||
+ | Arch Linux におけるメジャーリリースは各月の前半頃に公開されますが、これはインストールおよびレスキュー用のライブ環境で、{{grp|base}} グループとその他いくつかの [https://projects.archlinux.org/archiso.git/tree/configs/releng/packages.both パッケージ]が含まれています。 |
||
+ | ローリングリリースモデルは、ひとつのコマンド操作によってあらゆる Arch Linux のシステムを最新かつ最先端に保つものです。このことから、Arch におけるメジャーリリースというのはさほど重要な意味を持つものではないと言えます、なぜと言ってローリングリリースシステムは、パッケージがアップデートされるや否や、すぐさま最新のメジャーリリースを旧バージョンにしてしまうわけですから。最新の Arch Linux のメジャーリリースを手に入れたいと思っても、再インストールなどする必要はありません。単にコマンド {{ic|pacman -Syu}} を実行するだけで、あなたのシステムは新規インストールしたのと同様に最新になります。また同じ理由から、新しい Arch Linux のリリースというのは、一般的に理解されているような、真新しくてエキサイティングな機能を満載したものにはなりません。そうした真新しくエキサイティングな機能群のリリースは、必要に応じたパッケージのアップデートによってもたらされるものであり、それは {{ic|pacman -Syu}} のコマンドによって即座に反映されるのです。 |
||
− | ===Q) Arch Linux は堅牢なディストリなのでしょうか? しょっちゅう壊れたりしませんか? === |
||
+ | |||
− | '''A)''' 一言で言うと、それは概ね「''あなた''次第」だということです。 |
||
+ | === Arch Linux は堅牢なディストリなのでしょうか?しょっちゅう壊れたりしませんか? === |
||
+ | 一言で言うと、それは概ね「''あなた''次第」だということです。 |
||
自分の Arch システムをシンプルな基本環境の上に構築するのは''あなた''であり,システムの成長をコントロールしていくのも''あなた''なのです。当然、多くのカスタマイズパッケージや、色とりどりのツールキット、デスクトップ環境などを統合して巨大に膨れ上がったシステムでは、スリムでよりシンプルなそれに比べてアップストリームの変更による影響を受けやすく、より多くの設定の問題に悩まされることになります。UNIX に関する一般的な知識や、上手なシステム管理、適切なアップグレードの実施といったものは、システムを堅牢にしていく上で非常に大きな役割を担います。Arch のパッケージの大部分はパッチを施されていないのだ、ということにも留意してください。大部分の問題はおおよそアップストリームに起因するものです。 |
自分の Arch システムをシンプルな基本環境の上に構築するのは''あなた''であり,システムの成長をコントロールしていくのも''あなた''なのです。当然、多くのカスタマイズパッケージや、色とりどりのツールキット、デスクトップ環境などを統合して巨大に膨れ上がったシステムでは、スリムでよりシンプルなそれに比べてアップストリームの変更による影響を受けやすく、より多くの設定の問題に悩まされることになります。UNIX に関する一般的な知識や、上手なシステム管理、適切なアップグレードの実施といったものは、システムを堅牢にしていく上で非常に大きな役割を担います。Arch のパッケージの大部分はパッチを施されていないのだ、ということにも留意してください。大部分の問題はおおよそアップストリームに起因するものです。 |
||
76行目: | 87行目: | ||
従って、ローリングリリースで構築された個人のシステムの堅牢性に関して、最終的な責任を負うのは''ユーザー自身''です。ユーザーがいつアップグレードするのかを決め、必要な時に必要な変更をマージするのです。もしユーザーがコミュニティに助けを求めれば、救いの手は直ちに差し伸べられることでしょう。この点に関して、Arch が他のディストリビューションから異なっているのは、Arch が本当に "Do-it-yourself" なディストロであることでしょう。破損についてクレームをつけるのは見当違いであり、非生産的です。なぜといって、アップストリームでの変更に関して Arch 開発チームは責任を負いかねるからです。 |
従って、ローリングリリースで構築された個人のシステムの堅牢性に関して、最終的な責任を負うのは''ユーザー自身''です。ユーザーがいつアップグレードするのかを決め、必要な時に必要な変更をマージするのです。もしユーザーがコミュニティに助けを求めれば、救いの手は直ちに差し伸べられることでしょう。この点に関して、Arch が他のディストリビューションから異なっているのは、Arch が本当に "Do-it-yourself" なディストロであることでしょう。破損についてクレームをつけるのは見当違いであり、非生産的です。なぜといって、アップストリームでの変更に関して Arch 開発チームは責任を負いかねるからです。 |
||
+ | === Archのレビュー記事がもっと必要だ(宣伝が必要だ) === |
||
− | ===Q) よく耳にする"BSDスタイルの"initフレームワークって厳密にはどういうものなの? === |
||
+ | 現状でもう十分な量のArchについての記事が書かれています.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 チャンネル|IRC]],[https://lists.archlinux.org/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:トラフィックシェーピング|トラフィックシェーピング]]が有効になっていないことも注意してださい。従って、ネットワーク帯域を活用するプログラムによって改善する可能性があります。Shorewall や Vuurmuur などの[[ファイアウォール]] (これらは {{Pkg|iproute2}} のスクリプトでもあります) によってネットワークレイヤーのシェーピングを行うことができます。 |
||
− | ===Q) Archのレビュー記事がもっと必要だ(宣伝が必要だ).=== |
||
− | '''A)''' 現状でもう十分な量のArchについての記事が書かれています.Archの目標は巨大になることではなく、シンプルさと,コードの整合性に焦点を絞った,エレガントで,最小かつ最新のディストリビューションを提供することなのです.Archが対象とするユーザー・ベース自体が自然と発展しています. |
||
− | === |
+ | === なんで Arch は RAM を全部使っちゃうわけ? === |
+ | そもそも、使わない RAM は無駄な RAM です。 |
||
− | '''A)''' そうかも知れませんね.もっと柔軟にあなたの時間を使って貢献してください! [http://bbs.archlinux.org フォーラム]や,[[IRC Channel|IRC]],[http://mailman.archlinux.org/mailman/listinfo/ メーリングリスト]などに参加すれば,成すべきことがわかるはずです.まずは、Community Contributions サブフォーラムに参加してみてください. |
||
+ | 新米ユーザの方の多くは、Linux カーネルのメモリの扱い方がそれの使われ方と必ずしも同じにはならないことに気がつきます。RAM 上のデータへのアクセスはディスクに比べ非常に高速なので、カーネルは最近アクセスされたデータをメモリ上にキャッシュします。キャッシュされたデータは利用可能なメモリを使い果たした時のみクリアされ、新しいデータは必要に応じてロードされます。 |
||
− | ===Q) どうしてArchは重いの? もっと軽いと思ってたのに! === |
||
− | '''A)''' {{ic|/etc/hosts}} が正しく設定されているか確認してください ({{ic|/etc/rc.conf}} に書かれた hostname と一致していなければなりません。[[Beginners_Guide#Configure_the_system|Beginners_Guide のConfigure the System]] の項を参照してください)。hostname が一致していないとアプリケーションの起動が非常に遅くなる場合があります。 |
||
− | |||
− | ===Q) 他のOSに比べてインターネットの速度が遅いんだけど,どうして? === |
||
− | '''A)''' ネットワークは正しく設定されていますか? {{ic|/etc/rc.conf}},{{ic|/etc/hosts}},{{ic|/etc/resolv.conf}} をよく確認してみましたか? [[Beginners_Guide]]のConfigure the Systemの項を参照してください. |
||
− | |||
− | ===Q) なんで Arch は RAM を全部使っちゃうわけ? === |
||
− | '''A)''' そもそも、使わない RAM は無駄な RAM です。 |
||
− | |||
− | 新米ユーザの方の多くは、Linux カーネルのメモリの扱い方がそれの使われ方と必ずしも同じにはならないことに気がつきます。RAM 上のデータへのアクセスはディスクに比べ非常に高速なので、カーネルは最近アクセスされたデータをメモリ上にキャッシュします。キャッシュされたデータは空きメモリを使い果たした時のみクリアされ、新しいデータは必要に応じてロードされます。 |
||
この混乱のもっとも一般的な原因は、おそらく {{ic|free}} コマンドにあるでしょう: |
この混乱のもっとも一般的な原因は、おそらく {{ic|free}} コマンドにあるでしょう: |
||
− | {{hc|$ free -m| |
+ | {{hc|$ free -m| |
total used free shared buffers cached |
total used free shared buffers cached |
||
Mem: 1009 741 267 0 104 359 |
Mem: 1009 741 267 0 104 359 |
||
-/+ buffers/cache: 278 731 |
-/+ buffers/cache: 278 731 |
||
− | Swap: 1537 0 1537 |
+ | Swap: 1537 0 1537}} |
{{ic|-/+ buffers/cache:}} の行に注目してください —— メモリ量の表現は、実際には「現在使用中」と「利用可能」なメモリ量であり、「未使用」なのではありません。 |
{{ic|-/+ buffers/cache:}} の行に注目してください —— メモリ量の表現は、実際には「現在使用中」と「利用可能」なメモリ量であり、「未使用」なのではありません。 |
||
− | 上記の例では、1GB の RAM を積んだラップトップで、アイドル状態のターミナルとウェブブラウザを開いただけでその 741MB を使用しています! しかし、上記の "-/+ buffers/cache:" で始まる行を見てください。「現在使用中」なのは 278MB に過ぎません。実際には 731MB は新しいデータのために「利用可能」なのです。一見すると、「使用中」メモリの内の 104MB がバッファデータであり、359MB がキャッシュデータであるかのように見えてしまいますが、それぞれは必要なときにクリア |
+ | 上記の例では、1GB の RAM を積んだラップトップで、アイドル状態のターミナルとウェブブラウザを開いただけでその 741MB を使用しています! しかし、上記の "-/+ buffers/cache:" で始まる行を見てください。「現在使用中」なのは 278MB に過ぎません。実際には 731MB は新しいデータのために「利用可能」なのです。一見すると、「使用中」メモリの内の 104MB がバッファデータであり、359MB がキャッシュデータであるかのように見えてしまいますが、それぞれは必要なときにクリアされます。全メモリ中の 267MB のみが真の意味で「free」なのです。 |
− | もしあなたの好奇心が刺激されたなら、[ |
+ | もしあなたの好奇心が刺激されたなら、[https://www.linuxjournal.com/article/2770 こちらの素晴らしい記事]も読んでみてください。 |
+ | こちらのウェブサイトでもこの混乱を整理して説明しています: http://www.linuxatemyram.com/ |
||
− | ===Q) わたしのディスクの空き領域はどこへ行ってしまったの?=== |
||
− | '''A)''' その答えはあなたのシステムによって変わります。[[Common Applications#Disk Usage Display Programs|こちらに優れたユーティリティの一覧があります]]ので試してみてください。 |
||
+ | === わたしのディスクの空き領域はどこへ行ってしまったの? === |
||
− | ==パッケージ管理== |
||
+ | その答えはあなたのシステムによって変わります。[[アプリケーション一覧#ディスク使用量表示プログラム|こちらに優れたユーティリティの一覧があります]]ので試してみてください。 |
||
− | == |
+ | ==パッケージ管理== |
− | + | === ファイル〇〇はどのパッケージに含まれていますか? === |
|
+ | {{Pkg|pkgfile}} コマンドで確認できます。 |
||
例: |
例: |
||
{{hc|$ pkgfile glxinfo|extra/mesa-demos}} |
{{hc|$ pkgfile glxinfo|extra/mesa-demos}} |
||
− | === |
+ | === 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 なんてたいがいのアプリケーションが問題なく自動判別できるだろ?」'' |
|
− | Arch開発者の一人であるTobias Kieslichの発言は示唆的です.''「事実packageはgzipやxzで圧縮されたtarballファイルなわけじゃないか! だいたいtarが扱えるアプリケーションなら何だって開くことができるし,覗いて弄ることだってできるんだしさ.もっと言えば,mime-typeなんてたいがいのアプリケーションが問題なく自動判別できるだろ? 」'' |
||
− | === |
+ | === Pacman には他のアプリケーションがパッケージ情報を簡単に参照するためのライブラリが必要だ === |
− | + | バージョン3.0.0以降、[[pacman]] は libalpm ("Arch Linux Package Management" library) のフロントエンドになっています。このライブラリは代替のフロントエンドの開発を可能にしています (例えばGUIフロントエンドのような)。 |
|
− | === |
+ | === どうして Pacman にはオフィシャルの GUI フロントエンドがないの? === |
− | + | [[The Arch Way]],[[Arch Linux]] を読んでください.強いて言うならArch開発者チームが提供しようと思わないからです.ユーザー達が開発したものの中からご自由に選択して使ってください.[[Pacman GUI フロントエンド]]には選りすぐりがリストアップされています. |
|
− | === |
+ | === Pacman に X の機能を付けるべきだ! === |
− | + | [[The Arch Way]],[[Arch Linux]]を読んでください.Archの哲学は「シンプルたれ」です.もしあなたがご自身のアイデアにメリットがあると考え,それがくだんのシンプルのお題目を毀損しないものなら,是非フォーラムに投げて議論してください.また,フォーラムをちゃんとチェックしてしかるべきです.ここは重要だと思われる機能について要望を出す,まさにそのための場所なのです. |
|
もっとも,ある機能をPacmanやArch Linuxに追加するために一番良い方法は,あなた自身がそれを実装することです.そのパッチがオフィシャルに取り込まれるかどうかはわかりませんが,いずれにせよあなたの骨折りは他のユーザーによって吟味され,検討されるでしょう. |
もっとも,ある機能をPacmanやArch Linuxに追加するために一番良い方法は,あなた自身がそれを実装することです.そのパッチがオフィシャルに取り込まれるかどうかはわかりませんが,いずれにせよあなたの骨折りは他のユーザーによって吟味され,検討されるでしょう. |
||
− | === |
+ | === Arch には,安定版パッケージの branch が必要だ === |
− | + | 何事にも絶対はありません。これに関してはいくつかの議論があります:<br> |
|
− | + | https://bbs.archlinux.org/viewtopic.php?id=11288 |
|
− | また、より安定したサーバ運用のためのコミュニティプロジェクト [http://www.archserver.org/ ArchServer] もあります。 |
+ | また、より安定したサーバ運用のためのコミュニティプロジェクト [http://www.archserver.org/ ArchServer]{{dead link|2014|04|04}} もあります。 |
− | === |
+ | === 数種のリポジトリがありますが,どんな違いがあるんでしょうか? === |
− | + | [[公式リポジトリ]] を参照してください. |
|
− | === |
+ | === X のパッケージをインストールしたんだけど,どうやって起動するの? === |
− | + | あなたが KDE や GNOME のようなデスクトップ環境を導入しているのなら、そのプログラムは自動的にメニューに登録されている筈です。ターミナルから起動しようとしていて、バイナリの名前がわからないというような場合は、次のコマンドで確認してください: |
|
+ | $ pacman -Qlq ''パッケージ名'' | grep /usr/bin/ |
||
− | ===Q) 公式リポジトリにある共用ライブラリはそれぞれどうして一つのバージョンしか用意されてないんですか?=== |
||
+ | === 公式リポジトリにある共用ライブラリはそれぞれどうして一つのバージョンしか用意されてないんですか? === |
||
− | '''A)''' Debian などの一部のディストリビューションは、共用ライブラリパッケージにおいて {{ic|libfoo1}}、{{ic|libfoo2}}、{{ic|libfoo3}} といったように複数のバージョンを用意しています。この方法では同一のシステム上で異なるバージョンの libfoo ごとにアプリケーションのコンパイルが可能となります。 |
||
+ | Debian などの一部のディストリビューションは、共用ライブラリパッケージにおいて {{ic|libfoo1}}、{{ic|libfoo2}}、{{ic|libfoo3}} といったように複数のバージョンを用意しています。この方法では同一のシステム上で異なるバージョンの libfoo ごとにアプリケーションのコンパイルが可能となります。 |
||
− | Debian と異なり、Arch はローリングリリースで最先端のディストリビューションです。最先端のディストリビューションの最大の特徴はそのリポジトリから最新バージョンのソフトウェアが入手可能であることです。Arch の場合も、すべてのパッケージで公式にサポートされているのは最新バージョンのみであることを意味します。過去のソフトウェアをサポートしないことで、パッケージメンテナは新しいバージョンの作業に割く時間をより多くとることができます。共有ライブラリの新しいバージョンがアップストリームからリリースされると、それはすぐにリポジトリに追加され、影響を受けるパッケージは新しいライブラリに合わせてリビルドされます。 |
||
+ | Debian と異なり、Arch はローリングリリースで最先端のディストリビューションです。最先端のディストリビューションの最大の特徴はそのリポジトリから最新バージョンのソフトウェアが入手可能であることです。Arch のようなディストリビューションの場合、すべてのパッケージで公式にサポートされているのは最新バージョンのみであることを意味します。過去のソフトウェアをサポートしないことで、パッケージメンテナは新しいバージョンの作業に割く時間をより多くとることができます。共有ライブラリの新しいバージョンがアップストリームからリリースされると、それはすぐにリポジトリに追加され、影響を受けるパッケージは新しいライブラリに合わせてリビルドされます。 |
||
− | ===Q) もし、{{ic|pacman -Syu}} で共用ライブラリがアップデートされたのにそれに依存するアプリケーションがアップデートされなかったらどうなりますか?=== |
||
+ | === もし、システム全体のアップグレード({{ic|pacman -Syu}})で共用ライブラリがアップデートされたのにそれに依存するアプリケーションがアップデートされなかったらどうなりますか? === |
||
− | '''A)''' それは起こってはならないシナリオです。公式リポジトリに {{ic|foobaz}} というアプリケーションがあり、{{ic|libbaz}} という共用ライブラリの新バージョンを使用してビルドされているとして、それは {{ic|libbaz}} のアップデートに合わせてアップデートされます。しかしもし、それがうまくいかない場合は、パッケージ {{ic|foobaz}} は以下のようなバージョン制限のある依存関係が指定されます。 |
||
+ | |||
− | libbaz=1.5 |
||
− | そして {{ic|foobaz}} は、{{ic|libbaz}} のアップグレードの際に pacman によってコンフリクトを理由に削除されます。 |
+ | それは起こってはならないシナリオです。公式リポジトリに {{ic|foobaz}} というアプリケーションがあり、{{ic|libbaz}} という共用ライブラリの新バージョンを使用してビルドされているとして、それは {{ic|libbaz}} のアップデートに合わせてアップデートされます。しかしもし、それがうまくいかない場合、そのパッケージ {{ic|foobaz}} にはバージョン制限のある依存関係 (例: libbaz=1.5) が指定され、{{ic|libbaz}} のアップグレードの際に pacman によってコンフリクトを理由に削除されます。 |
もし {{ic|foobaz}} が、あなた自身でビルドした、あるいは AUR からインストールしたパッケージであった場合には、新バージョンの {{ic|libbaz}} で {{ic|foobaz}} をリビルドしてみてください。ビルドが失敗した場合には {{ic|foobaz}} の開発者にそのバグを報告してください。 |
もし {{ic|foobaz}} が、あなた自身でビルドした、あるいは AUR からインストールしたパッケージであった場合には、新バージョンの {{ic|libbaz}} で {{ic|foobaz}} をリビルドしてみてください。ビルドが失敗した場合には {{ic|foobaz}} の開発者にそのバグを報告してください。 |
||
− | === |
+ | === リポジトリのカーネルにメジャーアップデートがあったのに、ドライバが最新カーネル用にアップデートされないことはあり得ますか? === |
+ | |||
+ | いいえ、ありえません。例えば {{ic|3.5.x}} から {{ic|3.6.x}} といったカーネルのメジャーアップデートは常にすべてのサポートカーネルドライバのリビルドを伴います。ただし、{{AUR|catalyst}} などの非サポートパッケージを使用している場合には、最新のカーネルでそれをリビルドしなければトラブルが発生するかもしれません。非サポートパッケージは自身の責任において使用してください。 |
||
+ | |||
+ | === Arch はパッケージに署名を採用していますか? === |
||
+ | はい、パッケージ署名は pacman バージョン 4 から実装されました。詳しい情報は [[pacman-key]] をご覧ください。 |
||
+ | |||
+ | === アップグレードの前にやっておいたほうがいい事はありますか? === |
||
+ | それは Arch Linux にとってとても大事なことです。アップグレード時、Enter を叩く前に、公式サイトの [https://www.archlinux.jp/ Arch news] (RSS で購読できます) と [https://lists.archlinux.org/listinfo/arch-announce/ アナウンスメントメーリングリスト]を、あとできれば [https://bbs.archlinux.org/ フォーラム]や[https://lists.archlinux.org/listinfo/ その他のメーリングリスト]もチェックしてください。なにがしかの特殊な作業が必要な場合にはそれについて説明されています。 |
||
+ | |||
+ | === パッケージのアップデートがリリースされているのに、pacman はシステムは最新だと出力する === |
||
+ | |||
+ | ''pacman'' のミラーはすぐに同期されるわけではありません。アップデートが利用できるようになるまで24時間以上かかることもあります。アップデートが下りてくるのを待つか、別のミラーを使ってみて下さい。[https://www.archlinux.org/mirrors/status/ MirrorStatus] で最新のミラーを確認できます。 |
||
+ | === 上流のプロジェクト ''X'' が新しいバージョンをリリースしています。Arch パッケージとして新しいバージョンにアップデートできるようになるまでにかかる時間は? === |
||
− | '''A)''' いいえ、ありえません。{{ic|2.6.x}} から {{ic|2.6.x+1}} といったカーネルのメジャーアップデートは常にすべてのサポートカーネルドライバのリビルドを伴います。ただし、{{AUR|catalyst}} などの非サポートパッケージを使用している場合には、最新のカーネルでそれをリビルドしなければトラブルが発生するかもしれません。非サポートパッケージは自身の責任において使用してください。 |
||
+ | パッケージアップデートは準備ができ次第リリースされます。上流リリースがマイナーなバグ修正のみであれば数時間でパッケージがアップデートされることもありますし、メジャーアップデートであれば数週間後となることもあります。上流の新しいバージョンが Arch にリリースされるまでの時間はそのパッケージとパッケージメンテナによって変わります。一部のパッケージは [[testing]] リポジトリでしばらくテストされるため、パッケージが更新されるまでの時間が長い傾向にあります。[[Arch 用語集#パッケージメンテナ|パッケージメンテナ]]は安定版のアップデートをリポジトリで素早く提供できるように尽力しています。公式リポジトリのパッケージが古くなっていることに気づいたら、[https://www.archlinux.org/packages/ パッケージウェブサイト] から out-of-date フラグを立てて報告してください。 |
||
− | ===Q) Arch はパッケージに署名を採用していますか?=== |
||
− | '''A)''' はい、パッケージ署名は pacman バージョン 4 から実装されました。詳しい情報は [[package signing]] をご覧ください。 |
||
==インストール== |
==インストール== |
||
− | === |
+ | === Arch はもっと良いインストーラーを付けるべきだ。たとえば GUI インストーラーとか === |
+ | ローリングリリースモデルを採用している Arch ではインストールそのものを滅多に行わないため、その優先度は開発者やユーザにとって高くありません。[[インストールガイド]]はコマンドラインから行う方式に全面的に改められました。それでもインストーラに興味のある方は [[Archboot]] の利用も検討してみてください。 |
||
− | '''A)''' 「良い」インストーラー云々の議論は主観の問題です。こうした論争に決着をつける最良の方法は、インストーラを「Archの流儀」に合わせることでしょう。もし、この「良いインストーラ」に関する議論がより具体的な論拠を伴うようになれば、新たなインストーラの開発が顧慮されるようなこともあるかも知れません。しかし、インストールを実行する機会自体がそもそも稀なので (メジャー・リリースに関する質問を参照)、開発者、ユーザー双方にとって優先度の高い課題ではないのです。 |
||
− | 非公式でもよいならば、[http://chakra-project.org/ Chakra]などのArch派生プロジェクトがあります。詳しくは[[Arch Based Distributions]]を参照してください。 |
||
− | === |
+ | === Arch をインストールしたんですが、シェルのログイン画面が表示されてます! どうすれば良いのでしょう? === |
− | + | [[一般的な推奨事項]]を参照してください。 |
|
− | === |
+ | === デスクトップ環境やウィンドウマネージャはどれを使えばいいですか? === |
− | + | たくさんありますので、あなたに一番あったものを使えばいいのです。どのようなデスクトップ環境やウィンドウマネージャがあるかは、[[デスクトップ環境]]や[[ウィンドウマネージャ]]で説明されています。 |
|
− | === |
+ | === Arch は「ミニマルな基本システムから構築していくディストリビューションで、ユーザが本当に望むものだけをインストールできる」ということをうたい文句にしていますが、これって他のディストリビューションでもできますよね?この点に関して一体 Arch のどこがユニークなんですか? === |
− | + | 確かに一部のディストリビューションは Arch と近い設計理念を持っており、同じようにミニマルなインストール・メソッドを提供してるかも知れませんが、いくつかの相違は指摘しておかねばなりません: |
|
#Arch は骨の髄まで軽量でミニマルな環境を構築することを想定してデザインされています。 |
#Arch は骨の髄まで軽量でミニマルな環境を構築することを想定してデザインされています。 |
||
− | # |
+ | #Arch はこのミニマルな基本システムから構築する以外に方法を提供していません。 |
− | #ディストリビューション全体と同様、インストレーションに関しても原則的に K.I.S.S.("Keep It Simple and Stupid") の設計理念に基づいています。これによって Arch の |
+ | #ディストリビューション全体と同様、インストレーションに関しても原則的に K.I.S.S.("Keep It Simple and Stupid") の設計理念に基づいています。これによって Arch のベースシステムは、対象となるユーザーベースとの間に、これ以上はないというくらいの親和性を獲得しています。 |
# サービス及びパッケージのインストールでは、手動あるいは対話式に構成設定を行わなければなりません。他のディストリビューションと異なり、サービスの構成や起動設定を自動で行ったりはしません。Arch の哲学は、そのような責任を扱う権利をユーザーから奪わず、ユーザの力量に任せることに重きをおいています。 |
# サービス及びパッケージのインストールでは、手動あるいは対話式に構成設定を行わなければなりません。他のディストリビューションと異なり、サービスの構成や起動設定を自動で行ったりはしません。Arch の哲学は、そのような責任を扱う権利をユーザーから奪わず、ユーザの力量に任せることに重きをおいています。 |
||
#Arch のパッケージングはミニマルであるよう設計されており、利用状況によっては必要となる“任意の”依存パッケージは自動インストールされません。それらはパッケージのインストール時に通知されるだけなので、結果的によりスリムなシステムになるのです。 |
#Arch のパッケージングはミニマルであるよう設計されており、利用状況によっては必要となる“任意の”依存パッケージは自動インストールされません。それらはパッケージのインストール時に通知されるだけなので、結果的によりスリムなシステムになるのです。 |
||
+ | #Arch は完全なドキュメント群を提供しており、これによって各ユーザーのシステム構築のプロセスを一通り補助しています。 |
||
− | #シンプルな Arch のインストーラ AIF は高度な透明性を保ったデザインとなっており、基本システムでも細かい設定が必要な部分は、ユーザー自身がマニュアル操作しなければなりません。 |
||
+ | |||
− | #Arch は徹底的かつ完全なドキュメント群を提供しており、これによって各ユーザーのシステム構築のプロセスを一通り補助しています。 |
||
+ | == 64ビット == |
||
+ | |||
+ | === 私のプロセッサが x86_64 に対応しているかどうかを知る方法は? === |
||
+ | ==== Linux ユーザー ==== |
||
+ | 以下のコマンドを実行してください: |
||
+ | $ less /proc/cpuinfo |
||
+ | |||
+ | {{ic|flags}} エントリーを探してください。 {{ic|lm}} フラグがあったら、あなたのプロセッサーは x86_64 対応です。 |
||
+ | |||
+ | もしくは以下のコマンドを実行してみることも出来ます: |
||
+ | $ grep -q "^flags.*\blm\b" /proc/cpuinfo && echo "x86_64" || echo "not x86_64" |
||
+ | ==== Windows ユーザー ==== |
||
− | ==その他== |
||
+ | フリーウェアである [http://www.cpuid.com/cpuz.php CPU-Z] を使って、64ビット互換があるかどうか確認できます。AMD の命令セットである AMD64 または Intel の命令セット EM64T は x86_64 のバイナリと互換性があります。 |
||
+ | === 64ビットにする理由は? === |
||
− | ===Q) Pacmanを実行する度に,'warning: current locale is invalid; using default "C" locale'というエラーが出るんですが,どうしたらいいでしょう? === |
||
+ | 多くの状況下で (32ビットに比べて) 高速であり、通常の i686 カーネルでは PAE が無効化されているために利用できない[[wikipedia:ja:アドレス空間配置のランダム化|アドレス空間配置のランダム化 (ASLR)]] や [[wikipedia:ja:位置独立コード|位置独立コード (PIC)]]、[[wikipedia:ja:NXビット|NX ビット]]を使用することによりセキュリティが向上することが挙げられます。もしコンピューターに 4GB 以上のメモリが載っている場合、32ビット OS では利用できない分のメモリも使用することができるので、ぜひ64ビットを使用するべきでしょう。 |
||
− | '''A)''' エラーメッセージが言っているように,localeが正しく設定されていません.Wikiの[[Configuring locales]]を参照してください. |
||
+ | 更に、64ビットの拡張をサポートしている新しい x86 CPU に対して、レガシーな32ビットの CPU をプログラマーがサポートしなくなってきているというのもあります。 |
||
− | ===Q) 無線ネットワークに接続するにはどうすればいいですか? === |
||
− | '''A)''' [[Wireless Setup]]を参照してください. |
||
+ | 以上の理由が32ビット環境を避けるべきという我々のアドバイスですが、カーネルやユーザースペース、個々のプログラムなど、64ビットの方が優れているものは他にもたくさんあり、全てをここに書き出す事は出来ません。 |
||
− | ===Q) 有線ネットワークに接続するにはどうすればいいですか? === |
||
− | '''A)''' [[Configuring network]]を参照してください. |
||
+ | [https://www.archlinux.org/packages/differences/ 差異のレポート]も見てください。32/64ビットのパッケージバージョンの比較を行うことが出来ます。 |
||
− | ===Q) "AUR"ってよく聞くんだけど一体何? === |
||
− | '''A)''' [[AUR Q & A]]を参照してください. |
||
+ | === 再インストールせずに i686 環境から x86_64 環境にアップグレード出来ますか? === |
||
− | ===Q) ビデオを見ようとすると画面が緑色になっちゃうんだけど,どうして? === |
||
+ | できません。厳格に言えば、環境の移行とは、全てのパッケージを新しいアーキテクチャ向けに再インストールするということを意味します。ただし、新規インストールをすることなく、現在インストールされているシステムから、環境を移行することは可能です。[https://bbs.archlinux.org/viewtopic.php?id=64485 この]フォーラムスレッドの手順に従えば、設定やデータを失うことなく、32ビットから64ビットに移行できます。移行には外付けのハードドライブを使用するので注意してください。 |
||
− | '''A)''' colour depthの設定が正しくありません.例えば"24"であるべきところが"16"になっていたりしませんか? |
||
+ | もしくは、Arch64 インストール CD でシステムを起動し、ディスクをマウントして、32ビットバイナリ以外の、残しておきたいデータ (例えば {{ic|/home}} や {{ic|/etc}} など) をバックアップして、インストールします。 |
||
− | ===Q) Spellcheckを実行するとテキストが全部ミス判定されてしまうんですが.=== |
||
− | '''A)''' aspell dictionaryはインストールされていますか? {{ic|pacman -Ss aspell}} を実行して、入手可能な辞書を確認してください。インストールされている辞書は {{ic|aspell dicts}} で確認できます。 |
||
− | {{hc|$ aspell dicts|<nowiki> |
||
− | Prints out: |
||
− | en |
||
− | en_GB |
||
− | ...etc</nowiki>}} |
||
+ | 詳しくは[[再インストールせずにアーキテクチャを移行]]を読んでください。 |
||
− | aspell および辞書がインストールされていても問題が解決しない場合、{{ic|enchant}} が原因かもしれません。{{ic|/usr/share/enchant/enchant.ordering}} を確認し、目的の言語が期待した設定になっているか確認してください。 |
2018年2月6日 (火) 23:43時点における版
ここで解決されない問題等については,The Arch Way,Arch Linux が参考になります.そこでは Arch Linux に関するより多くの情報が扱われています.
目次
- 1 一般
- 1.1 Arch Linux って何ですか?
- 1.2 私は Arch を使うべきですか?
- 1.3 私は Arch を使うべきではありませんか?
- 1.4 Arch はどのディストリビューションベースなんですか?
- 1.5 Arch はどのアーキテクチャをサポートしていますか?
- 1.6 Arch は ARM CPU をサポートしていますか?
- 1.7 Arch は FHS に準拠していますか?
- 1.8 当方全くの GNU/Linux ビギナーなのですが、Arch を使って大丈夫でしょうか?
- 1.9 Arch を使うにはとても手間暇がかかるし、コミュニティはといえば、なにかと言うと RTFM って言うし
- 1.10 Arch はどの用途向けに設計されていますか?サーバですか?デスクトップですか?ワークステーションですか?
- 1.11 Arch はホント好きなんだけどね.開発チームがXの機能さえ実装してくれればなぁ
- 1.12 いつ新しいメジャー・リリースが出るんでしょうか?
- 1.13 Arch Linux は堅牢なディストリなのでしょうか?しょっちゅう壊れたりしませんか?
- 1.14 Archのレビュー記事がもっと必要だ(宣伝が必要だ)
- 1.15 Archの開発者がもっと必要だ
- 1.16 他のOSに比べてインターネットの速度が遅いんだけど、どうして?
- 1.17 なんで Arch は RAM を全部使っちゃうわけ?
- 1.18 わたしのディスクの空き領域はどこへ行ってしまったの?
- 2 パッケージ管理
- 2.1 ファイル〇〇はどのパッケージに含まれていますか?
- 2.2 Xのパッケージにエラーがあったんだけど,どうしたらいいの?
- 2.3 Archのパッケージにはもっと適切な命名規則が必要だ。".pkg.tar.gz" とか ".pkg.tar.xz" なんて長すぎるし、ややこしい
- 2.4 Pacman には他のアプリケーションがパッケージ情報を簡単に参照するためのライブラリが必要だ
- 2.5 どうして Pacman にはオフィシャルの GUI フロントエンドがないの?
- 2.6 Pacman に X の機能を付けるべきだ!
- 2.7 Arch には,安定版パッケージの branch が必要だ
- 2.8 数種のリポジトリがありますが,どんな違いがあるんでしょうか?
- 2.9 X のパッケージをインストールしたんだけど,どうやって起動するの?
- 2.10 公式リポジトリにある共用ライブラリはそれぞれどうして一つのバージョンしか用意されてないんですか?
- 2.11 もし、システム全体のアップグレード(pacman -Syu)で共用ライブラリがアップデートされたのにそれに依存するアプリケーションがアップデートされなかったらどうなりますか?
- 2.12 リポジトリのカーネルにメジャーアップデートがあったのに、ドライバが最新カーネル用にアップデートされないことはあり得ますか?
- 2.13 Arch はパッケージに署名を採用していますか?
- 2.14 アップグレードの前にやっておいたほうがいい事はありますか?
- 2.15 パッケージのアップデートがリリースされているのに、pacman はシステムは最新だと出力する
- 2.16 上流のプロジェクト X が新しいバージョンをリリースしています。Arch パッケージとして新しいバージョンにアップデートできるようになるまでにかかる時間は?
- 3 インストール
- 4 64ビット
一般
Arch Linux って何ですか?
Arch Linux を参照してください。
私は Arch を使うべきですか?
あなたが The Arch Way の理念に賛同し、'do-it-yourself' なアプローチを受け入れることができて、そして、シンプルで、エレガントで、高いカスタマイズ性を持ち、最先端の汎用 GNU/Linux ディストリビューションをお探しなら、Arch が気に入るかもしれません。
私は Arch を使うべきではありませんか?
あなたが The Arch Way の理念に賛同できず、'do-it-yourself' な GNU/Linux ディストリビューションを使う能力や時間がない、あるいはそれを求めていないなら、Arch はあなた向けではないかもしれません。
また、以下のような方も Arch を使いたいとは思わないでしょう:
- x86_64 以外のアーキテクチャのサポートが必要な方。
- GNU で定義されたフリーウェアのみを提供するディストリビューションを使うことに強いこだわりのある方。
- オペレーティングシステム自身が構成設定を行うべきであり、"箱から出してすぐ使える" べきであり、インストールメディア上でソフトウェアやデスクトップ環境のデフォルト設定が完全になされているべきであるとお考えの方。
- 最先端で、ローリングリリースな GNU/Linux を求めていない方。
- 今使っている OS に満足している方。
Arch はどのディストリビューションベースなんですか?
Arch は独自に開発され、他のいかなる GNU/Linux ディストリビューションもベースとしていません。Arch を製作する以前、Judd Vinet は Per Lidén による優れた最小主義ディストリビューションである CRUX を賞賛し使用していました。当初は CRUX と同様のアイデアに触発された Arch ですが、スクラッチビルドされており、pacman は C 言語で開発されました。
Arch はどのアーキテクチャをサポートしていますか?
Arch は x86_64 (別名 amd64) アーキテクチャのみをサポートしています。i686 のサポートは2017年11月に切られました [1]。x86_64 の CPU を搭載しているコンピュータで i686 版の Arch を使用している場合は#再インストールせずに i686 環境から x86_64 環境にアップグレード出来ますか?を見てください。32ビットマシンの場合は Arch Linux 32 に切り替えるという方法があります。
Arch は ARM CPU をサポートしていますか?
いいえ、ただし Arch Linux ARM プロジェクトによって Arch Linux が ARM プラットフォームに移植されています。
Arch は FHS に準拠していますか?
Arch Linux は systemd サービスマネージャを使用するオペレーティングシステムのファイルシステム階層を遵守しています。ディレクトリの説明については file-hierarchy(7) を見てください。特に Arch では /bin
, /sbin
, /usr/sbin
は /usr/bin
のシンボリックリンクに、/lib
と /lib64
は /usr/lib
のシンボリックリンクになっています。Arch ファイルシステム階層も参照してください。
当方全くの GNU/Linux ビギナーなのですが、Arch を使って大丈夫でしょうか?
これに関してはかなりの議論があります。Arch はある程度熟練した GNU/Linux ユーザーを対象にしていますが、やる気のある初心者には Arch こそもってこいだ、と考えるような人もいます。もしあなたが初心者で、それでもなお Arch を使おうとしているのであれば、あなたは十分な時間を費やして学ぶことに喜びを覚えるようでなければなりません。また Arch が全く "Do-It-Yourself" なディストリビューションとして設計されている、ということも肝に命じておくべきでしょう。システムを組み上げ、それをどのようなものにしていくかをコントロールするのはユーザー自身なのです。質問をする前にまず自分で調査するようにしてください。Google やフォーラム、そして素晴らしいドキュメントが用意されている Arch Wiki の検索を活用しましょう (以下のFAQも参照してください)。以上のことさえ実践していれば、それほど困難なことはありません。また、多くの人が同じ基本的質問に何度も繰り返して答えさせられることに嫌気がさしているのだ、ということも理解しておいてください。あなたは今まさにその当事者なのです。伊達や酔狂でこのような文書が作成され、入門者に利用してもらえるよう設置されているわけではありません。途方もない時間がこの貴重な情報を編集するために無償で費やされているのです。Arch 用語集#RTFM も見てください。
Arch を使うにはとても手間暇がかかるし、コミュニティはといえば、なにかと言うと RTFM って言うし
Arch は特定のユーザベースを対象にして設計され、利用されています。おそらくそれがあなたには合っていないのでしょう。上のセクションも参照してください。
Arch はどの用途向けに設計されていますか?サーバですか?デスクトップですか?ワークステーションですか?
Arch は特定の用途向けに設計されているわけではありません。むしろ、特定の "ユーザ" 向けに設計されています。Arch はなんでも自分でやることを楽しみ、各自のニーズに応じたシステムを構築するためにそれをよりよく活用する、やる気のあるユーザを対象にしています。したがって、その目的はユーザの思いのままであり、Arch は事実上あらゆる用途で使用できます。多くの人々が Arch をデスクトップとワークステーション両方で使用しています。そしてもちろん、archlinux.org は Arch で動いています。
Arch はホント好きなんだけどね.開発チームがXの機能さえ実装してくれればなぁ
ちょっと待った.ちゃんと The Arch Way は,読みましたか? あなたはその機能/対処方法を提示してみたのですか? それはミニマリズムや,利便性に先んじるコードの整合性と言ったArchの哲学と一致するでしょうか? どうぞ積極的に参加してください.あなた自身がコードや解決策を提示することでコミュニティに貢献しましょう.もし,コミュニティや開発チームから認められれば,あなたのコードはマージされるかも知れません.Archコミュニティはコードやツールの提供,シェアによって活性化していきます.
いつ新しいメジャー・リリースが出るんでしょうか?
Arch Linux におけるメジャーリリースは各月の前半頃に公開されますが、これはインストールおよびレスキュー用のライブ環境で、base グループとその他いくつかの パッケージが含まれています。
ローリングリリースモデルは、ひとつのコマンド操作によってあらゆる Arch Linux のシステムを最新かつ最先端に保つものです。このことから、Arch におけるメジャーリリースというのはさほど重要な意味を持つものではないと言えます、なぜと言ってローリングリリースシステムは、パッケージがアップデートされるや否や、すぐさま最新のメジャーリリースを旧バージョンにしてしまうわけですから。最新の Arch Linux のメジャーリリースを手に入れたいと思っても、再インストールなどする必要はありません。単にコマンド pacman -Syu
を実行するだけで、あなたのシステムは新規インストールしたのと同様に最新になります。また同じ理由から、新しい Arch Linux のリリースというのは、一般的に理解されているような、真新しくてエキサイティングな機能を満載したものにはなりません。そうした真新しくエキサイティングな機能群のリリースは、必要に応じたパッケージのアップデートによってもたらされるものであり、それは pacman -Syu
のコマンドによって即座に反映されるのです。
Arch Linux は堅牢なディストリなのでしょうか?しょっちゅう壊れたりしませんか?
一言で言うと、それは概ね「あなた次第」だということです。
自分の Arch システムをシンプルな基本環境の上に構築するのはあなたであり,システムの成長をコントロールしていくのもあなたなのです。当然、多くのカスタマイズパッケージや、色とりどりのツールキット、デスクトップ環境などを統合して巨大に膨れ上がったシステムでは、スリムでよりシンプルなそれに比べてアップストリームの変更による影響を受けやすく、より多くの設定の問題に悩まされることになります。UNIX に関する一般的な知識や、上手なシステム管理、適切なアップグレードの実施といったものは、システムを堅牢にしていく上で非常に大きな役割を担います。Arch のパッケージの大部分はパッチを施されていないのだ、ということにも留意してください。大部分の問題はおおよそアップストリームに起因するものです。
従って、ローリングリリースで構築された個人のシステムの堅牢性に関して、最終的な責任を負うのはユーザー自身です。ユーザーがいつアップグレードするのかを決め、必要な時に必要な変更をマージするのです。もしユーザーがコミュニティに助けを求めれば、救いの手は直ちに差し伸べられることでしょう。この点に関して、Arch が他のディストリビューションから異なっているのは、Arch が本当に "Do-it-yourself" なディストロであることでしょう。破損についてクレームをつけるのは見当違いであり、非生産的です。なぜといって、アップストリームでの変更に関して Arch 開発チームは責任を負いかねるからです。
Archのレビュー記事がもっと必要だ(宣伝が必要だ)
現状でもう十分な量のArchについての記事が書かれています.Archの目標は巨大になることではなく、シンプルさと,コードの整合性に焦点を絞った,エレガントで,最小かつ最新のディストリビューションを提供することなのです.Archが対象とするユーザー・ベース自体が自然と発展しています.
Archの開発者がもっと必要だ
そうかも知れませんね.もっと柔軟にあなたの時間を使って貢献してください! フォーラムや,IRC,メーリングリストなどに参加すれば,成すべきことがわかるはずです.まずは、Community Contributions サブフォーラムに参加してみてください.
他のOSに比べてインターネットの速度が遅いんだけど、どうして?
ネットワークは正しく設定されていますか?ネットワーク設定のページを参照してください。
また、Arch ではデフォルトでトラフィックシェーピングが有効になっていないことも注意してださい。従って、ネットワーク帯域を活用するプログラムによって改善する可能性があります。Shorewall や Vuurmuur などのファイアウォール (これらは iproute2 のスクリプトでもあります) によってネットワークレイヤーのシェーピングを行うことができます。
なんで Arch は RAM を全部使っちゃうわけ?
そもそも、使わない RAM は無駄な RAM です。
新米ユーザの方の多くは、Linux カーネルのメモリの扱い方がそれの使われ方と必ずしも同じにはならないことに気がつきます。RAM 上のデータへのアクセスはディスクに比べ非常に高速なので、カーネルは最近アクセスされたデータをメモリ上にキャッシュします。キャッシュされたデータは利用可能なメモリを使い果たした時のみクリアされ、新しいデータは必要に応じてロードされます。
この混乱のもっとも一般的な原因は、おそらく free
コマンドにあるでしょう:
$ free -m
total used free shared buffers cached Mem: 1009 741 267 0 104 359 -/+ buffers/cache: 278 731 Swap: 1537 0 1537
-/+ buffers/cache:
の行に注目してください —— メモリ量の表現は、実際には「現在使用中」と「利用可能」なメモリ量であり、「未使用」なのではありません。
上記の例では、1GB の RAM を積んだラップトップで、アイドル状態のターミナルとウェブブラウザを開いただけでその 741MB を使用しています! しかし、上記の "-/+ buffers/cache:" で始まる行を見てください。「現在使用中」なのは 278MB に過ぎません。実際には 731MB は新しいデータのために「利用可能」なのです。一見すると、「使用中」メモリの内の 104MB がバッファデータであり、359MB がキャッシュデータであるかのように見えてしまいますが、それぞれは必要なときにクリアされます。全メモリ中の 267MB のみが真の意味で「free」なのです。
もしあなたの好奇心が刺激されたなら、こちらの素晴らしい記事も読んでみてください。
こちらのウェブサイトでもこの混乱を整理して説明しています: http://www.linuxatemyram.com/
わたしのディスクの空き領域はどこへ行ってしまったの?
その答えはあなたのシステムによって変わります。こちらに優れたユーティリティの一覧がありますので試してみてください。
パッケージ管理
ファイル〇〇はどのパッケージに含まれていますか?
pkgfile コマンドで確認できます。
例:
$ pkgfile glxinfo
extra/mesa-demos
Xのパッケージにエラーがあったんだけど,どうしたらいいの?
まず,そのエラーはそもそもArch開発チームが修正できるものなのかどうかを見極めなければなりません.そうでない場合が往々にしてあります(例えばFirefoxのクラッシュは大抵の場合Mozillaチームのミスです).これをアップストリーム・エラーと言います.もしArchの問題であるならば以下の手順を参考に対処してください.:
- フォーラムに情報がないか探してみましょう.誰かが同じ問題について発言していないかチェックしてください.
- 詳細な情報を書いたバグレポートを投函してください.
- もしお望みならば,フォーラムに質問を投げてみてもよいでしょう.その際,問題の詳細と,あなたが既にバグ・レポートを送った旨を明記してください.それによって同じエラーに関する報告が大量に投函されるようなケースを回避できます.
Archのパッケージにはもっと適切な命名規則が必要だ。".pkg.tar.gz" とか ".pkg.tar.xz" なんて長すぎるし、ややこしい
これに関しては、Arch のメーリングリスト上で議論されています。.pac
のような拡張子を提案する人もいますが、現段階では、パッケージの拡張子を変更する具体的な計画はありません。Arch 開発者の一人である Tobias Kieslich の発言は示唆的です。「事実 package は gzip や xz で圧縮された tarball ファイルなわけじゃないか! だいたい tar が扱えるアプリケーションなら何だって開くことができるし、覗いて弄ることだってできるんだしさ。もっと言えば、mime-type なんてたいがいのアプリケーションが問題なく自動判別できるだろ?」
Pacman には他のアプリケーションがパッケージ情報を簡単に参照するためのライブラリが必要だ
バージョン3.0.0以降、pacman は libalpm ("Arch Linux Package Management" library) のフロントエンドになっています。このライブラリは代替のフロントエンドの開発を可能にしています (例えばGUIフロントエンドのような)。
どうして Pacman にはオフィシャルの GUI フロントエンドがないの?
The Arch Way,Arch Linux を読んでください.強いて言うならArch開発者チームが提供しようと思わないからです.ユーザー達が開発したものの中からご自由に選択して使ってください.Pacman GUI フロントエンドには選りすぐりがリストアップされています.
Pacman に X の機能を付けるべきだ!
The Arch Way,Arch Linuxを読んでください.Archの哲学は「シンプルたれ」です.もしあなたがご自身のアイデアにメリットがあると考え,それがくだんのシンプルのお題目を毀損しないものなら,是非フォーラムに投げて議論してください.また,フォーラムをちゃんとチェックしてしかるべきです.ここは重要だと思われる機能について要望を出す,まさにそのための場所なのです.
もっとも,ある機能をPacmanやArch Linuxに追加するために一番良い方法は,あなた自身がそれを実装することです.そのパッチがオフィシャルに取り込まれるかどうかはわかりませんが,いずれにせよあなたの骨折りは他のユーザーによって吟味され,検討されるでしょう.
Arch には,安定版パッケージの branch が必要だ
何事にも絶対はありません。これに関してはいくつかの議論があります:
https://bbs.archlinux.org/viewtopic.php?id=11288
また、より安定したサーバ運用のためのコミュニティプロジェクト ArchServer[リンク切れ 2014-04-04] もあります。
数種のリポジトリがありますが,どんな違いがあるんでしょうか?
公式リポジトリ を参照してください.
X のパッケージをインストールしたんだけど,どうやって起動するの?
あなたが KDE や GNOME のようなデスクトップ環境を導入しているのなら、そのプログラムは自動的にメニューに登録されている筈です。ターミナルから起動しようとしていて、バイナリの名前がわからないというような場合は、次のコマンドで確認してください:
$ pacman -Qlq パッケージ名 | grep /usr/bin/
公式リポジトリにある共用ライブラリはそれぞれどうして一つのバージョンしか用意されてないんですか?
Debian などの一部のディストリビューションは、共用ライブラリパッケージにおいて libfoo1
、libfoo2
、libfoo3
といったように複数のバージョンを用意しています。この方法では同一のシステム上で異なるバージョンの libfoo ごとにアプリケーションのコンパイルが可能となります。
Debian と異なり、Arch はローリングリリースで最先端のディストリビューションです。最先端のディストリビューションの最大の特徴はそのリポジトリから最新バージョンのソフトウェアが入手可能であることです。Arch のようなディストリビューションの場合、すべてのパッケージで公式にサポートされているのは最新バージョンのみであることを意味します。過去のソフトウェアをサポートしないことで、パッケージメンテナは新しいバージョンの作業に割く時間をより多くとることができます。共有ライブラリの新しいバージョンがアップストリームからリリースされると、それはすぐにリポジトリに追加され、影響を受けるパッケージは新しいライブラリに合わせてリビルドされます。
もし、システム全体のアップグレード(pacman -Syu
)で共用ライブラリがアップデートされたのにそれに依存するアプリケーションがアップデートされなかったらどうなりますか?
それは起こってはならないシナリオです。公式リポジトリに foobaz
というアプリケーションがあり、libbaz
という共用ライブラリの新バージョンを使用してビルドされているとして、それは libbaz
のアップデートに合わせてアップデートされます。しかしもし、それがうまくいかない場合、そのパッケージ foobaz
にはバージョン制限のある依存関係 (例: libbaz=1.5) が指定され、libbaz
のアップグレードの際に pacman によってコンフリクトを理由に削除されます。
もし foobaz
が、あなた自身でビルドした、あるいは AUR からインストールしたパッケージであった場合には、新バージョンの libbaz
で foobaz
をリビルドしてみてください。ビルドが失敗した場合には foobaz
の開発者にそのバグを報告してください。
リポジトリのカーネルにメジャーアップデートがあったのに、ドライバが最新カーネル用にアップデートされないことはあり得ますか?
いいえ、ありえません。例えば 3.5.x
から 3.6.x
といったカーネルのメジャーアップデートは常にすべてのサポートカーネルドライバのリビルドを伴います。ただし、catalystAUR などの非サポートパッケージを使用している場合には、最新のカーネルでそれをリビルドしなければトラブルが発生するかもしれません。非サポートパッケージは自身の責任において使用してください。
Arch はパッケージに署名を採用していますか?
はい、パッケージ署名は pacman バージョン 4 から実装されました。詳しい情報は pacman-key をご覧ください。
アップグレードの前にやっておいたほうがいい事はありますか?
それは Arch Linux にとってとても大事なことです。アップグレード時、Enter を叩く前に、公式サイトの Arch news (RSS で購読できます) と アナウンスメントメーリングリストを、あとできれば フォーラムやその他のメーリングリストもチェックしてください。なにがしかの特殊な作業が必要な場合にはそれについて説明されています。
パッケージのアップデートがリリースされているのに、pacman はシステムは最新だと出力する
pacman のミラーはすぐに同期されるわけではありません。アップデートが利用できるようになるまで24時間以上かかることもあります。アップデートが下りてくるのを待つか、別のミラーを使ってみて下さい。MirrorStatus で最新のミラーを確認できます。
上流のプロジェクト X が新しいバージョンをリリースしています。Arch パッケージとして新しいバージョンにアップデートできるようになるまでにかかる時間は?
パッケージアップデートは準備ができ次第リリースされます。上流リリースがマイナーなバグ修正のみであれば数時間でパッケージがアップデートされることもありますし、メジャーアップデートであれば数週間後となることもあります。上流の新しいバージョンが Arch にリリースされるまでの時間はそのパッケージとパッケージメンテナによって変わります。一部のパッケージは testing リポジトリでしばらくテストされるため、パッケージが更新されるまでの時間が長い傾向にあります。パッケージメンテナは安定版のアップデートをリポジトリで素早く提供できるように尽力しています。公式リポジトリのパッケージが古くなっていることに気づいたら、パッケージウェブサイト から out-of-date フラグを立てて報告してください。
インストール
Arch はもっと良いインストーラーを付けるべきだ。たとえば GUI インストーラーとか
ローリングリリースモデルを採用している Arch ではインストールそのものを滅多に行わないため、その優先度は開発者やユーザにとって高くありません。インストールガイドはコマンドラインから行う方式に全面的に改められました。それでもインストーラに興味のある方は Archboot の利用も検討してみてください。
Arch をインストールしたんですが、シェルのログイン画面が表示されてます! どうすれば良いのでしょう?
一般的な推奨事項を参照してください。
デスクトップ環境やウィンドウマネージャはどれを使えばいいですか?
たくさんありますので、あなたに一番あったものを使えばいいのです。どのようなデスクトップ環境やウィンドウマネージャがあるかは、デスクトップ環境やウィンドウマネージャで説明されています。
Arch は「ミニマルな基本システムから構築していくディストリビューションで、ユーザが本当に望むものだけをインストールできる」ということをうたい文句にしていますが、これって他のディストリビューションでもできますよね?この点に関して一体 Arch のどこがユニークなんですか?
確かに一部のディストリビューションは Arch と近い設計理念を持っており、同じようにミニマルなインストール・メソッドを提供してるかも知れませんが、いくつかの相違は指摘しておかねばなりません:
- Arch は骨の髄まで軽量でミニマルな環境を構築することを想定してデザインされています。
- Arch はこのミニマルな基本システムから構築する以外に方法を提供していません。
- ディストリビューション全体と同様、インストレーションに関しても原則的に K.I.S.S.("Keep It Simple and Stupid") の設計理念に基づいています。これによって Arch のベースシステムは、対象となるユーザーベースとの間に、これ以上はないというくらいの親和性を獲得しています。
- サービス及びパッケージのインストールでは、手動あるいは対話式に構成設定を行わなければなりません。他のディストリビューションと異なり、サービスの構成や起動設定を自動で行ったりはしません。Arch の哲学は、そのような責任を扱う権利をユーザーから奪わず、ユーザの力量に任せることに重きをおいています。
- Arch のパッケージングはミニマルであるよう設計されており、利用状況によっては必要となる“任意の”依存パッケージは自動インストールされません。それらはパッケージのインストール時に通知されるだけなので、結果的によりスリムなシステムになるのです。
- Arch は完全なドキュメント群を提供しており、これによって各ユーザーのシステム構築のプロセスを一通り補助しています。
64ビット
私のプロセッサが x86_64 に対応しているかどうかを知る方法は?
Linux ユーザー
以下のコマンドを実行してください:
$ less /proc/cpuinfo
flags
エントリーを探してください。 lm
フラグがあったら、あなたのプロセッサーは x86_64 対応です。
もしくは以下のコマンドを実行してみることも出来ます:
$ grep -q "^flags.*\blm\b" /proc/cpuinfo && echo "x86_64" || echo "not x86_64"
Windows ユーザー
フリーウェアである CPU-Z を使って、64ビット互換があるかどうか確認できます。AMD の命令セットである AMD64 または Intel の命令セット EM64T は x86_64 のバイナリと互換性があります。
64ビットにする理由は?
多くの状況下で (32ビットに比べて) 高速であり、通常の i686 カーネルでは PAE が無効化されているために利用できないアドレス空間配置のランダム化 (ASLR) や 位置独立コード (PIC)、NX ビットを使用することによりセキュリティが向上することが挙げられます。もしコンピューターに 4GB 以上のメモリが載っている場合、32ビット OS では利用できない分のメモリも使用することができるので、ぜひ64ビットを使用するべきでしょう。
更に、64ビットの拡張をサポートしている新しい x86 CPU に対して、レガシーな32ビットの CPU をプログラマーがサポートしなくなってきているというのもあります。
以上の理由が32ビット環境を避けるべきという我々のアドバイスですが、カーネルやユーザースペース、個々のプログラムなど、64ビットの方が優れているものは他にもたくさんあり、全てをここに書き出す事は出来ません。
差異のレポートも見てください。32/64ビットのパッケージバージョンの比較を行うことが出来ます。
再インストールせずに i686 環境から x86_64 環境にアップグレード出来ますか?
できません。厳格に言えば、環境の移行とは、全てのパッケージを新しいアーキテクチャ向けに再インストールするということを意味します。ただし、新規インストールをすることなく、現在インストールされているシステムから、環境を移行することは可能です。このフォーラムスレッドの手順に従えば、設定やデータを失うことなく、32ビットから64ビットに移行できます。移行には外付けのハードドライブを使用するので注意してください。
もしくは、Arch64 インストール CD でシステムを起動し、ディスクをマウントして、32ビットバイナリ以外の、残しておきたいデータ (例えば /home
や /etc
など) をバックアップして、インストールします。
詳しくは再インストールせずにアーキテクチャを移行を読んでください。