「FAQ」の版間の差分
imported>Kuroyagi (New page: Category:About Arch (日本語) Category:FAQs (日本語) {{FAQ i18n Links}} ここで解決されない疑問等については、The Arch Way (日本語)、[[Arch Linux (日...) |
Kusanaginoturugi (トーク | 投稿記録) (校正(でき・出来)) |
||
(17人の利用者による、間の136版が非表示) | |||
1行目: | 1行目: | ||
− | [[Category: |
+ | [[Category:Arch について]] |
+ | [[ar:Frequently asked questions]] |
||
− | [[Category:FAQs (日本語)]] |
||
+ | [[cs:Frequently asked questions]] |
||
− | {{FAQ i18n Links}} |
||
+ | [[de:FAQ]] |
||
+ | [[en:Frequently asked questions]] |
||
+ | [[es:Frequently asked questions]] |
||
+ | [[fa:سؤالات متداول]] |
||
+ | [[fi:Frequently asked questions]] |
||
+ | [[fr:Frequently asked questions]] |
||
+ | [[it:Frequently asked questions]] |
||
+ | [[pl:Frequently asked questions]] |
||
+ | [[pt:Frequently asked questions]] |
||
+ | [[ru:Frequently asked questions]] |
||
+ | [[tr:Frequently asked questions]] |
||
+ | [[uk:Frequently asked questions]] |
||
+ | [[zh-hans:Frequently asked questions]] |
||
+ | {{Related articles start}} |
||
+ | {{Related|Arch 用語集}} |
||
+ | {{Related|Arch User Repository#FAQ}} |
||
+ | {{Related|一般的なトラブルシューティング}} |
||
+ | {{Related articles end}} |
||
+ | ==一般== |
||
+ | === Arch Linux って何ですか? === |
||
− | ここで解決されない疑問等については、[[The Arch Way (日本語)]]、[[Arch Linux (日本語)]]、[[Devland]]が参考になります。そこでは、Arch Linuxに関するより多くの情報が扱われています。 |
||
+ | [[Arch Linux]] を参照してください。 |
||
+ | === 私は Arch を使うべきではありませんか? === |
||
− | = 一般 = |
||
+ | 以下のような方は Arch を使いたいとは思わないでしょう: |
||
+ | * 'do-it-yourself' な GNU/Linux ディストリビューションを使う能力や時間がない、あるいはそれを求めていない方。 |
||
+ | * x86_64 以外のアーキテクチャのサポートが必要な方。 |
||
+ | * GNU で定義されたフリーウェアのみを提供するディストリビューションを使うことに強いこだわりのある方。 |
||
+ | * オペレーティングシステム自身が構成設定を行うべきであり、"箱から出してすぐ使える" べきであり、インストールメディア上でソフトウェアやデスクトップ環境のデフォルト設定が完全になされているべきであるとお考えの方。 |
||
+ | * 最先端で、ローリングリリースな GNU/Linux を求めていない方。 |
||
+ | * 今使っている OS に満足している方。 |
||
− | == |
+ | === なぜ Arch を使いたいですか? === |
− | '''A)''' これに関してはかなりの議論があります。Archは、ある程度熟練したGNU/Linuxユーザーを対象にしていますが、「Archこそ入門にもってこいだ」と考えるような人もいます。もしあなたがビギナーで、それでもなおArchを使おうとしているのであれば、あなたは学ぶことに喜びを覚えるようでなければなりません。また、Archが優れて"Do-It-Yourself"なディストリビューションである、ということも肝に命じておくべきでしょう。システムを組み上げ、それがどのようなものにしていくかをコントロールするのは、ユーザー自身なのです。質問をする前に、まず自分で調査するようにしてください。googleや、Wiki、フォーラムの検索を活用しましょう(過去のFAQも参照してください)。以上のことさえ実践していれば、まず困ることはありません。また、多くの人が同じ基本的質問に何度も繰り返して答えさせられることに嫌気がさしているのだ、ということも理解しておいてください。あなたは今、その当事者なのです。伊達や酔狂でこのような文書が作成され、入門者に利用してもらえるよう設置されているわけではありません。途方もない時間が、この貴重な情報を編集するために、無償で費やされているのです。要通読:[[Beginners Guide|Beginners' Guide]]. |
||
+ | [[Arch は最高]] だからです。 |
||
− | ==Q) Archはホント好きなんだけどね。開発チームが''X''の機能さえ実装してくれればなぁ。== |
||
− | '''A)''' ちょっと待った。ちゃんと[[The Arch Way (日本語)]]は、読みましたか?あなたは、その機能/対処方法を提示したのですか?それは、''ミニマリズム''や、''利便性に先んじるコードの整合性''、と言ったArchの哲学と一致するでしょうか?どうぞ積極的に参加してください。あなた自身がコードや解決策を提示することでコミュニティに貢献しましょう。もし、コミュニティや開発チームから認められれば、あなたのコードはマージされるかも知れません。Archコミュニティは、コードやツールの提供、シェアによって活性化していきます。 |
||
+ | === Arch はどのアーキテクチャをサポートしていますか? === |
||
− | ==Q) いつ新しいメジャー・リリースが出るんでしょうか?== |
||
+ | Arch は [[Wikipedia:ja:X64|x86_64]] (別名 amd64) アーキテクチャのみをサポートしています。i686 のサポートは2017年11月に切られました [https://www.archlinux.jp/news/the-end-of-i686-support/]。 |
||
− | '''A)''' Arch Linuxにおけるメジャー・リリースとは、coreリポジトリの単なるsnapshotを意味するに過ぎません。インストーラ・スクリプトの様々な機能や操作抜きに、これについて語ることはできません。ローリング・リリースモデルは、ひとつのコマンドの実行によって、あらゆるArch Linuxのシステムを、最新かつ最先端に保つものです。 |
||
+ | ''非公式'' の移植プロジェクトとしては、i686 アーキテクチャ向けの [https://archlinux32.org/] や [[Wikipedia:jja:ARMアーキテクチャ|ARM]] CPU 向けの [https://archlinuxarm.org/] などがあり、それぞれ専用のコミュニティを持っています。 |
||
− | このことから、Archにおけるメジャー・リリースというのは、さほど重要なものではないと言えます。なぜと言って、ローリング・リリースシステムは、パッケージがアップデートされるや否や、すぐさま最新のメジャー・リリースを旧バージョンにしてしまうわけですから。もし最新のArch Linuxのリリースを手に入れたいのだとしても、再インストールなどする必要はありません。シンプルに"pacman -Syu" のコマンドを実行するだけで、あなたはまっさらなインストールを実行した結果構築されるそれと、同一のシステムを手に入れることになるでしょう。 |
||
+ | === Arch は Linux Foundation の標準ファイルシステム階層 (FHS) に準拠していますか? === |
||
− | また同じ理由から、新しい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 を使おうとしているのであれば、あなたは十分な時間を費やして学ぶことに喜びを覚えるようでなければなりません。また Arch が全く "Do-It-Yourself" なディストリビューションとして設計されている、ということも肝に命じておくべきでしょう。システムを組み上げ、それをどのようなものにしていくかをコントロールするのはユーザー自身なのです。 |
||
− | '''A)''' 答えはyesでもあり、noでもあります。つまり、それは概ね''あなた''がどれだけそれ堅牢にするかに懸かっている、と言えます。 |
||
+ | 質問をする前にまず自分で調査するようにしてください。Google やフォーラム、そして素晴らしいドキュメントが用意されている Arch Wiki の検索を活用しましょう。''そのような情報が使える状態になっているのには理由があります。'' 途方もない時間がこの貴重な情報を編集するために無償で費やされているのです。 |
||
− | 独自のArchシステムをシンプルな基本環境の上に構築するのは、''あなた''であり、.システムの成長をコントロールしていくのも、''あなた''なのです。当然、多くのパッケージや、複数のツールキット、デスクトップ環境などを統合して、巨大に膨れ上がったシステムは、スリムでよりシンプルなそれに比べて、アップストリームの変更に関わるため、より設定の問題に悩まされる可能性が高くなります。UNIXに関する一般的な素養や、上手なシステム管理、適切なアップグレードの実施といったものは、システムの堅牢にしていく上で、非常に大きな役割を担います。Archのパッケージの大部分がパッチを施されていない、ということにも留意してください。大部分の問題は、おおよそアップストリームに起因するものです。 |
||
− | 従って、個人のローリング・リリースシステムの堅牢性に関して、最終的な責任を負うのは''ユーザー自身''です。ユーザーが、いつアップグレードするのかを決め、必要な時に必要な変更をマージするのです。もしユーザーがコミュニティに助けを求めれば、救いの手は直ちに差し伸べられることでしょう。これに関して、Archと他のディストリビューションで異なる点は、Archが本当に"Do-it-yourself"なディストロであることでしょう。破損についてクレームをつけるのは、見当違いであり、非生産的です。なぜといって、アップストリーム・チェンジに関して、Arch開発チームは責任を負いかねるからです。 |
||
+ | [[Arch 用語集#RTFM]] や [[インストールガイド]] も見てください。 |
||
− | ==Q) よく耳にする”BSDスタイル”initフレームワークって厳密にはどういうものなの? == |
||
+ | === Arch はどの用途向けに設計されていますか?サーバですか?デスクトップですか?ワークステーションですか? === |
||
− | 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 は特定の用途向けに設計されているわけではありません。むしろ、特定の "ユーザ" 向けに設計されています。Arch はなんでも自分でやることを楽しみ、各自のニーズに応じたシステムを構築するためにそれをよりよく活用する、やる気のあるユーザを対象にしています。したがって、その目的はユーザの思いのままであり、Arch は事実上あらゆる用途で使用できます。多くの人々が Arch をデスクトップとワークステーション両方で使用しています。そしてもちろん、archlinux.org・aur.archlinux.org とほとんど全ての Arch の [https://gitlab.archlinux.org/archlinux/infrastructure インフラストラクチャ] は Arch で動いています。 |
||
+ | === Arch はホント好きなんだけどね.開発チームがXの機能さえ実装してくれればなぁ === |
||
− | ==Q) Archのレビュー記事がもっと必要だ。(宣伝が必要だ)== |
||
+ | どうぞ積極的に参加してください.あなた自身がコードや解決策を提示することで [[コミュニティに貢献]] しましょう.もし,コミュニティや開発チームから認められれば,あなたのコードはマージされるかも知れません.Archコミュニティはコードやツールの提供,シェアによって活性化していきます. |
||
− | '''A)''' 現状でもう十分な量のArchについての記事が書かれています。Archの目標は、巨大になることではありません。シンプルさと、コードの整合性に焦点を絞った、エレガントで、最小かつ最新のディストリビューションを提供することこそが、その目標なのです。Archが対象とするユーザー・ベース自体が自然と発展しています。それを強制したところで、問題の種を蒔くことになるだけでしょう。 |
||
+ | === いつ新しいリリースが出るんでしょうか? === |
||
− | 同様に、Archの開発モデルは、自然な発展を制限するものではありません。より多くのユーザーを得ることは、より多くの開発者がArch Linuxに関わることを意味します。これによって上層部における組織的な問題が発生すこともあるかも知れませんが、それはその時に対処すれば良いことです。 |
||
+ | Arch Linux におけるリリースは単にインストールおよびレスキュー用のライブ環境で、{{Pkg|base}} メタパッケージとその他いくつかの [https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/packages.x86_64 パッケージ]が含まれています。リリースは通常各月の前半頃に公開されます。 |
||
+ | === Arch Linux は堅牢なディストリなのでしょうか?しょっちゅう壊れたりしませんか? === |
||
+ | ローリングリリースで構築された個人のシステムの堅牢性に関して、最終的な責任を負うのは''ユーザー自身''です。ユーザーがいつアップグレードするのかを決め、必要な時に必要な変更をマージするのです。もしユーザーがコミュニティに助けを求めれば、救いの手はすぐに差し伸べられることが多いでしょう。この点に関して、Arch が他のディストリビューションから異なっているのは、Arch が本当に "Do-it-yourself" なディストロであることでしょう。破損についてクレームをつけるのは見当違いであり、非生産的です。アップストリームでの変更に関して Arch 開発チームは責任を負いかねるからです。 |
||
+ | 可能な限り安定する Arch Linux システムを構成するための方法やヒントについては、[[システムメンテナンス]]を参照してください。 |
||
− | ==Q) Archの開発者がもっと必要だ。== |
||
− | '''A)''' そうかも知れませんね。もっと柔軟にあなたの時間を使って貢献してください!フォーラムや、IRC、メーリング・リストなどに参加すれば、成すべきことがわかるはずです。 |
||
− | ドキュメントの作成者などは、常に必要です。ぜひWikiに寄稿してください。 |
||
+ | === Archのレビュー記事がもっと必要だ(宣伝が必要だ) === |
||
− | ==Q) Why is Arch so slow? I thought it's supposed to be fast!== |
||
+ | 現状でもう十分な量のArchについての記事が書かれています.Archの目標は巨大になることではなく、持続的な成長が対象のユーザーベースの間で自然に起きることです。 |
||
− | '''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. |
||
+ | === Archの開発者がもっと必要だ === |
||
− | ==Q) Why is my internet so slow compared to other operating systems?== |
||
+ | そうかも知れませんね.もっと柔軟にあなたの時間を使って貢献してください! [https://bbs.archlinux.jp/ フォーラム]や,[[IRC チャンネル]],[https://lists.archlinux.org/mailman3/lists/ メーリングリスト]などに参加すれば,成すべきことがわかるはずです.詳細は [[コミュニティに貢献]] を参照してください。 |
||
− | '''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]]. |
||
+ | ==インストール== |
||
− | =Package Management= |
||
+ | === Arch はもっと良いインストーラーを付けるべきだ。たとえば GUI インストーラーとか === |
||
− | ==Q) I've found an error with Package X. What should I do?== |
||
+ | Arch には Arch Installation Framework (AIF) と呼ばれる、テキストベースのユーザーインターフェースを持ったインストーラがありました。[https://lists.archlinux.org/archives/list/arch-releng@lists.archlinux.org/thread/4BW5FZZFIOMD3RFMOM4XVHKKEDMLXWPQ/ 最後のメンテナが去った]後、{{Pkg|arch-install-scripts}} の推奨により [[Arch_Linux#Arch_Install_Scripts|廃止]] されました。 |
||
− | '''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: |
||
+ | [https://www.archlinux.jp/news/installation-medium-with-installer/ 2021年4月1日 から]、Arch はインストーラを再度含むようになりました。詳細は [[archinstall]] を参照してください。 |
||
− | #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. |
||
+ | === Arch をインストールしたんですが、シェルのログイン画面が表示されてます! どうすれば良いのでしょう? === |
||
− | ==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. |
||
+ | === デスクトップ環境やウィンドウマネージャはどれを使えばいいですか? === |
||
− | ==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." |
||
+ | === 他の「ミニマル」なディストリビューションと比べて Arch のどこがユニークなんですか? === |
||
− | ==Q) Pacman needs a library so other applications can easily access package information== |
||
+ | [[Arch と他のディストリビューションの比較]] を参照してください。 |
||
− | '''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). |
||
+ | == システムメンテナンス == |
||
− | ==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]]. |
||
+ | [[システムメンテナンス]] も参照してください。 |
||
− | ==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. |
||
+ | === 他のOSに比べてインターネットの速度が遅いんだけど、どうして? === |
||
− | 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. |
||
+ | ネットワークは正しく設定されていますか?[[ネットワーク設定]]のページを参照してください。 |
||
+ | また、Arch ではデフォルトで[[Wikipedia:ja:トラフィックシェーピング|トラフィックシェーピング]]が有効になっていないことも注意してださい。従って、(P2P 上か通常のクライアント-サーバー通信かに関わらず)ネットワーク帯域を使い果たすプログラムは、ローカルの他のソフトの通信を妨げ、ひどいラグやタイムアウトのような結果になる可能性があります。 Shorewall や Vuurmuur などの[[ファイアウォール]]や、 {{Pkg|iproute2}} の静的なスクリプト(例えば ''Wondershaper'' の [http://serendipity.ruwenzori.net/index.php/2008/06/01/modified-wondershaper-for-better-voip-qos 派生]) によってネットワークレイヤーのシェーピングを行うことができます。 |
||
− | ==Q) Arch 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 |
||
+ | === なんで Arch は RAM を全部使っちゃうわけ? === |
||
− | ==Q) What's the difference between all these repositories?== |
||
+ | そもそも、使わない RAM は無駄な RAM です。 |
||
− | '''A)''' See [[The Arch Linux Repositories]]. |
||
+ | 新米ユーザの方の多くは、Linux カーネルのメモリの扱い方が以前の方法と必ずしも同じにはならないことに気がつきます。RAM 上のデータへのアクセスはディスクに比べ非常に高速なので、カーネルは最近アクセスされたデータをメモリ上にキャッシュします。キャッシュされたデータは、利用可能なメモリを使い果たして、新しいデータがロードされる必要のある時のみクリアされます。 |
||
+ | {{ic|free}} コマンドによって違いを見分けることができます: |
||
+ | {{hc|$ free -h| |
||
− | ==Q) I just installed Package X. How do I start it?== |
||
+ | total used free shared buff/cache available |
||
− | '''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. |
||
+ | Mem: 2.8Gi 1.1Gi 283Mi 224Mi 1.4Gi 1.2Gi |
||
+ | Swap: 3.0Gi 881Mi 2.1Gi |
||
+ | }} |
||
+ | "free" と "available" メモリの違いは重要です。上の例において、ラップトップは 2.8GiB の RAM をほとんど使っていて、free なメモリはたった 283MiB しかありません。しかし、そのうち 1.4GiB は "buff/cache" です。スワップなしで 1.2GiB の available なメモリが新しいアプリケーションの起動に利用可能です。詳しくは {{man|1|free}} を参照してください。これらは結果としてパフォーマンスを向上させます! |
||
− | =Installation= |
||
+ | もしあなたの好奇心が刺激されたなら、[https://www.linuxjournal.com/article/2770 こちらの素晴らしい記事]も読んでみてください。こちらのウェブサイトでもこの混乱を整理して説明しています: https://www.linuxatemyram.com/ 。 |
||
− | ==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. |
||
+ | === わたしのディスクの空き領域はどこへ行ってしまったの? === |
||
− | ==Q) I installed Arch, and now I am at a bash login! What now?== |
||
+ | その答えはあなたのシステムによって変わります。[[アプリケーション一覧#ディスク使用量表示プログラム|こちらに優れたユーティリティの一覧があります]]ので試してみてください。 |
||
− | '''A)''' Have a look at the Arch Linux [[Beginners_Guide]] |
||
+ | ==パッケージ管理== |
||
− | ==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?== |
||
+ | [[pacman]], [[Pacman ヒント]], [[公式リポジトリ]] により多くの答えがあります。 |
||
− | '''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. |
||
+ | === Xのパッケージにエラーがあったんだけど,どうしたらいいの? === |
||
− | =Other= |
||
+ | まず,そのエラーはそもそもArch開発チームが修正できるものなのかどうかを見極めなければなりません.そうでない場合が往々にしてあります(例えばFirefoxのクラッシュは大抵の場合Mozillaチームのミスです).これを ''アップストリーム・エラー'' と言います.もしArchの問題であるならば以下の手順を参考に対処してください.: |
||
+ | # フォーラムに情報がないか探してみましょう.誰かが同じ問題について気付いていないかチェックしてください. |
||
+ | # 詳細な情報を書いた[[バグ報告ガイドライン|バグレポート]]を https://bugs.archlinux.org に投稿してください. |
||
+ | # もしお望みならば,フォーラムに質問を投げてみてもよいでしょう.その際,問題の詳細と,あなたが既にバグ・レポートを送った旨を明記してください.それによって同じエラーに関する報告が大量に投稿されるようなケースを回避できます. |
||
+ | === Archのパッケージにはもっと適切な命名規則が必要だ。".pkg.tar.zst" なんて長すぎるし、ややこしい === |
||
− | ==Q) I get an error every time I use pacman saying 'warning: current locale is invalid; using default "C" locale'. What do I do?== |
||
+ | これに関しては、Arch のメーリングリスト上で議論されています。{{Ic|.pac}} のような拡張子を提案する人もいますが、現段階では、パッケージの拡張子を変更する具体的な計画はありません。Arch 開発者の一人である Tobias Kieslich の発言は示唆的です。「事実 package は ''[圧縮された]'' tarball ファイルなわけじゃないか! だいたい tar が扱えるアプリケーションなら何だって開くことができるし、覗いて弄ることだってできるんだしさ。もっと言えば、mime-type なんてたいがいのアプリケーションが問題なく自動判別できるだろ?」 |
||
− | '''A)''' As the error message says, your locale isn't correctly configured. Have a look at the [[Configuring locales|locale configuration wiki page]]. |
||
+ | === Pacman には他のアプリケーションがパッケージ情報を簡単に参照するためのライブラリが必要だ === |
||
− | ==Q) How do I automount/mount something? == |
||
+ | [[pacman]] は {{man|3|libalpm}} ("Arch Linux Package Management" library) のフロントエンドになっています。このライブラリは代替のフロントエンドの開発を可能にしています (例えばGUIフロントエンドのような)。 |
||
− | '''A)''' If you use GNOME, install gnome-volume-manager: |
||
− | pacman -Sy gnome-volume-manager |
||
+ | === Pacman に X の機能を付けるべきだ! === |
||
− | Now add yourself to the storage group: |
||
+ | そのアイデアにメリットがあると思うのであれば、[https://lists.archlinux.org/mailman3/lists/pacman-dev.lists.archlinux.org/ pacman-dev] で議論することができます。既存の機能リクエストがないか https://gitlab.archlinux.org/pacman/pacman/-/issues や https://bugs.archlinux.org/index.php?project=3 も確認してみてください。 |
||
− | gpasswd -a ''your_user'' storage |
||
+ | もっとも,ある機能をPacmanやArch Linuxに追加するために一番良い方法は,あなた自身がそれを実装することです.そのパッチがオフィシャルに取り込まれるかどうかはわかりませんが,いずれにせよあなたの骨折りは他のユーザーによって吟味され,検討されるでしょう. |
||
− | If you don't want to use gnome-volume-manager, check out [[Ivman]] or [[autofs | AutoFS]]. |
||
+ | === X のパッケージをインストールしたんだけど,どうやって起動するの? === |
||
− | ==Q) How do I connect to my wireless network?== |
||
+ | あなたが [[KDE]] や [[GNOME]] のようなデスクトップ環境を導入しているのなら、そのプログラムは自動的にメニューに登録されている筈です。ターミナルから起動しようとしていて、バイナリの名前がわからないというような場合は、次のコマンドで確認してください: |
||
− | '''A)''' See [[Wireless Setup]]. |
||
+ | $ pacman -Qlq ''パッケージ名'' | grep /usr/bin/ |
||
− | ==Q) How do I connect to my wired network?== |
||
− | '''A)''' See [[Configuring network]]. |
||
+ | === 公式リポジトリにある共用ライブラリはそれぞれどうして一つのバージョンしか用意されてないんですか? === |
||
− | ==Q) What is this AUR thing I keep hearing about?== |
||
− | '''A)''' See [[AUR Q & A]]. |
||
+ | Debian などの一部のディストリビューションは、共用ライブラリパッケージにおいて {{ic|libfoo1}}、{{ic|libfoo2}}、{{ic|libfoo3}} といったように複数のバージョンを用意しています。この方法では同一のシステム上で異なるバージョンの libfoo ごとにアプリケーションのコンパイルが可能となります。 |
||
− | ==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. |
||
+ | Arch のようなディストリビューションの場合、最新のパッケージされたバージョンのみが公式にサポートされています。過去のソフトウェアをサポートしないことで、パッケージメンテナは最新のバージョンが期待通りに動くことの検証に割く時間をより多くとることができます。共有ライブラリの新しいバージョンがアップストリームからリリースされると、それはすぐにリポジトリに追加され、影響を受けるパッケージは新しいライブラリに合わせてリビルドされます。 |
||
− | ==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. |
||
+ | === システムの完全アップグレードを実行すると、共有ライブラリの更新は行われるが、それに依存するアプリケーションの更新は行われない場合はどうなりますか? === |
||
+ | |||
+ | それは起こってはならないシナリオです。公式リポジトリに {{ic|foobaz}} というアプリケーションがあり、{{ic|libbaz}} という共用ライブラリの新バージョンを使用してビルドされているとして、それは {{ic|libbaz}} のアップデートに合わせてアップデートされます。しかしもし、ビルドに失敗した場合は、そのパッケージ {{ic|foobaz}} にはバージョン制限のある依存関係 (例: libbaz=1.5) が指定され、{{ic|libbaz}} のアップグレードの際に pacman によってコンフリクトを理由に削除されます。 |
||
+ | |||
+ | もし {{ic|foobaz}} が、あなた自身でビルドした、あるいは AUR からインストールしたパッケージであった場合には、新バージョンの {{ic|libbaz}} で {{ic|foobaz}} をリビルドしてみてください。ビルドが失敗した場合には {{ic|foobaz}} の開発者にそのバグを報告してください。 |
||
+ | |||
+ | === リポジトリのカーネルにメジャーアップデートがあったのに、ドライバが最新カーネル用にアップデートされないことはあり得ますか? === |
||
+ | |||
+ | いいえ、ありえません。例えば {{ic|3.5.x}} から {{ic|3.6.x}} といったカーネルのメジャーアップデートは常にすべてのサポートカーネルドライバのリビルドを伴います。ただし、非サポートパッケージ (例えば [[AUR]] のパッケージ) を使用している場合には、最新のカーネルでそれをリビルドしなければトラブルが発生するかもしれません。サポートされていないドライバパッケージは、インストールしているユーザーがアップデートに全ての責任を負います。 |
||
+ | |||
+ | === アップグレードの前にやっておいたほうがいい事はありますか? === |
||
+ | [[システムメンテナンス#システムのアップグレード]] セクションに従ってください。 |
||
+ | |||
+ | === パッケージのアップデートがリリースされているのに、pacman はシステムは最新だと出力する === |
||
+ | |||
+ | ''pacman'' のミラーはすぐに同期されるわけではありません。アップデートが利用できるようになるまで24時間以上かかることもあります。取り得る選択肢は辛抱強く待つか、別のミラーを使うことだけです。[https://archlinux.org/mirrors/status/ MirrorStatus] で最新のミラーを確認できます。 |
||
+ | |||
+ | === 上流のプロジェクト X が新しいバージョンをリリースしています。Arch パッケージとして新しいバージョンにアップデートできるようになるまでにかかる時間は? === |
||
+ | |||
+ | パッケージアップデートは準備ができ次第リリースされます。上流リリースがマイナーなバグ修正のみであれば数時間でパッケージがアップデートされることもありますし、メジャーアップデートであれば数週間後となることもあります。上流の新しいバージョンが Arch にリリースされるまでの時間はそのパッケージとパッケージメンテナによって変わります。一部のパッケージは [[testing]] リポジトリでしばらくテストされるため、パッケージが更新されるまでの時間が長い傾向にあります。[[Arch 用語集#パッケージメンテナ|パッケージメンテナ]]は安定版のアップデートをリポジトリで素早く提供できるように尽力しています。公式リポジトリのパッケージが古くなっていることに気づいたら、[https://archlinux.org/packages/ パッケージウェブサイト] から out-of-date フラグを立てて報告してください。 |
||
+ | |||
+ | === インストールしているライブラリの古いバージョンが必要なときは、新しいバージョンにシンボリックリンクを貼るだけでいいですか? === |
||
+ | 幸運であれば少しの間それで動くかもしれません。動いたとしても、以下の理由でそれは正しい解決法ではありません: |
||
+ | |||
+ | * ライブラリは意味もなくバージョンを変えません。API/ABI が変更されたり(いくつか削除されたり)することがあり、それが使用に影響するかは単に運次第です。 |
||
+ | * シンボリックリンクはパッケージマネージャによって管理されません。すぐにシステムライブラリのファイルをハックしようとする初心者は、診断・修正が不可能な意図していない変更を加える大きなリスクを持っています。パッケージマネージャはこのような問題から守る手助けをしています。 |
||
+ | * 古いライブラリファイルをファイルシステムにコピーする代替手段もありますが、追跡されない上に忘れられやすく、潜在的なセキュリティのバグが気付かれず、また修正されません。 |
||
+ | |||
+ | 代わりに、例えば必要なライブラリのバージョンを提供する[https://aur.archlinux.org/packages/?SeB=n&K=compat 互換パッケージ]を使うか、もしくは作ってください。 |
||
+ | |||
+ | == 64ビット == |
||
+ | |||
+ | === 私のプロセッサが x86_64 に対応しているかどうかを知る方法は? === |
||
+ | 使っているプロセッサが [[Wikipedia:ja:X64|x86_64]] に対応している場合、{{ic|/proc/cpuinfo}} の中に{{ic|lm}} ([[Wikipedia:ja:X64#Longモード|Longモード]]) フラグがあります。例えば以下のコマンドを実行してください: |
||
+ | |||
+ | $ grep -w lm /proc/cpuinfo |
||
+ | |||
+ | Windows 上では、 フリーウェアである [https://www.cpuid.com/cpuz.php CPU-Z] を使って、64ビット互換があるかどうか確認できます。AMD の命令セットである AMD64 または Intel の命令セット EM64T は x86_64 のバイナリと互換性があります。 |
||
+ | |||
+ | === 64ビットにする理由は? === |
||
+ | 多くの状況下で (32ビットに比べて) 高速であり、通常の i686 カーネルでは [[wikipedia:ja:物理アドレス拡張|物理アドレス拡張 (PAE)]] が無効化されているために利用できない[[wikipedia:ja:アドレス空間配置のランダム化|アドレス空間配置のランダム化 (ASLR)]] や [[wikipedia:ja:位置独立コード|位置独立コード (PIC)]]、[[wikipedia:ja:NXビット|NX ビット]]を使用することによりセキュリティが向上することが挙げられます。もしコンピューターに 4GB 以上のメモリが載っている場合、64ビットの OS のみが全てを活用することができます。 |
||
+ | |||
+ | 更に、64ビットの拡張をサポートしている新しい x86 CPU に対して、レガシーな32ビットの CPU をプログラマーがサポートしなくなってきているというのもあります。 |
||
+ | |||
+ | 以上の理由が32ビット環境を避けるべきという我々のアドバイスですが、カーネルやユーザースペース、個々のプログラムなど、64ビットの方が優れているものは他にもたくさんあり、全てをここに書き出す事はできません。 |
||
+ | |||
+ | {{TranslationStatus|Frequently asked questions|2023-02-10|767066}} |
2024年7月10日 (水) 20:45時点における最新版
目次
- 1 一般
- 1.1 Arch Linux って何ですか?
- 1.2 私は Arch を使うべきではありませんか?
- 1.3 なぜ Arch を使いたいですか?
- 1.4 Arch はどのアーキテクチャをサポートしていますか?
- 1.5 Arch は Linux Foundation の標準ファイルシステム階層 (FHS) に準拠していますか?
- 1.6 当方全くの GNU/Linux ビギナーなのですが、Arch を使って大丈夫でしょうか?
- 1.7 Arch はどの用途向けに設計されていますか?サーバですか?デスクトップですか?ワークステーションですか?
- 1.8 Arch はホント好きなんだけどね.開発チームがXの機能さえ実装してくれればなぁ
- 1.9 いつ新しいリリースが出るんでしょうか?
- 1.10 Arch Linux は堅牢なディストリなのでしょうか?しょっちゅう壊れたりしませんか?
- 1.11 Archのレビュー記事がもっと必要だ(宣伝が必要だ)
- 1.12 Archの開発者がもっと必要だ
- 2 インストール
- 3 システムメンテナンス
- 4 パッケージ管理
- 4.1 Xのパッケージにエラーがあったんだけど,どうしたらいいの?
- 4.2 Archのパッケージにはもっと適切な命名規則が必要だ。".pkg.tar.zst" なんて長すぎるし、ややこしい
- 4.3 Pacman には他のアプリケーションがパッケージ情報を簡単に参照するためのライブラリが必要だ
- 4.4 Pacman に X の機能を付けるべきだ!
- 4.5 X のパッケージをインストールしたんだけど,どうやって起動するの?
- 4.6 公式リポジトリにある共用ライブラリはそれぞれどうして一つのバージョンしか用意されてないんですか?
- 4.7 システムの完全アップグレードを実行すると、共有ライブラリの更新は行われるが、それに依存するアプリケーションの更新は行われない場合はどうなりますか?
- 4.8 リポジトリのカーネルにメジャーアップデートがあったのに、ドライバが最新カーネル用にアップデートされないことはあり得ますか?
- 4.9 アップグレードの前にやっておいたほうがいい事はありますか?
- 4.10 パッケージのアップデートがリリースされているのに、pacman はシステムは最新だと出力する
- 4.11 上流のプロジェクト X が新しいバージョンをリリースしています。Arch パッケージとして新しいバージョンにアップデートできるようになるまでにかかる時間は?
- 4.12 インストールしているライブラリの古いバージョンが必要なときは、新しいバージョンにシンボリックリンクを貼るだけでいいですか?
- 5 64ビット
一般
Arch Linux って何ですか?
Arch Linux を参照してください。
私は Arch を使うべきではありませんか?
以下のような方は Arch を使いたいとは思わないでしょう:
- 'do-it-yourself' な GNU/Linux ディストリビューションを使う能力や時間がない、あるいはそれを求めていない方。
- x86_64 以外のアーキテクチャのサポートが必要な方。
- GNU で定義されたフリーウェアのみを提供するディストリビューションを使うことに強いこだわりのある方。
- オペレーティングシステム自身が構成設定を行うべきであり、"箱から出してすぐ使える" べきであり、インストールメディア上でソフトウェアやデスクトップ環境のデフォルト設定が完全になされているべきであるとお考えの方。
- 最先端で、ローリングリリースな GNU/Linux を求めていない方。
- 今使っている OS に満足している方。
なぜ Arch を使いたいですか?
Arch は最高 だからです。
Arch はどのアーキテクチャをサポートしていますか?
Arch は x86_64 (別名 amd64) アーキテクチャのみをサポートしています。i686 のサポートは2017年11月に切られました [1]。
非公式 の移植プロジェクトとしては、i686 アーキテクチャ向けの [2] や ARM CPU 向けの [3] などがあり、それぞれ専用のコミュニティを持っています。
Arch は Linux Foundation の標準ファイルシステム階層 (FHS) に準拠していますか?
Arch Linux は systemd サービスマネージャを使用するオペレーティングシステムのファイルシステム階層を遵守しています。ディレクトリの説明については file-hierarchy(7) を見てください。特に Arch では /bin
, /sbin
, /usr/sbin
は /usr/bin
のシンボリックリンクに、/lib
と /lib64
は /usr/lib
のシンボリックリンクになっています。
当方全くの GNU/Linux ビギナーなのですが、Arch を使って大丈夫でしょうか?
もしあなたが初心者で、それでもなお Arch を使おうとしているのであれば、あなたは十分な時間を費やして学ぶことに喜びを覚えるようでなければなりません。また Arch が全く "Do-It-Yourself" なディストリビューションとして設計されている、ということも肝に命じておくべきでしょう。システムを組み上げ、それをどのようなものにしていくかをコントロールするのはユーザー自身なのです。
質問をする前にまず自分で調査するようにしてください。Google やフォーラム、そして素晴らしいドキュメントが用意されている Arch Wiki の検索を活用しましょう。そのような情報が使える状態になっているのには理由があります。 途方もない時間がこの貴重な情報を編集するために無償で費やされているのです。
Arch 用語集#RTFM や インストールガイド も見てください。
Arch はどの用途向けに設計されていますか?サーバですか?デスクトップですか?ワークステーションですか?
Arch は特定の用途向けに設計されているわけではありません。むしろ、特定の "ユーザ" 向けに設計されています。Arch はなんでも自分でやることを楽しみ、各自のニーズに応じたシステムを構築するためにそれをよりよく活用する、やる気のあるユーザを対象にしています。したがって、その目的はユーザの思いのままであり、Arch は事実上あらゆる用途で使用できます。多くの人々が Arch をデスクトップとワークステーション両方で使用しています。そしてもちろん、archlinux.org・aur.archlinux.org とほとんど全ての Arch の インフラストラクチャ は Arch で動いています。
Arch はホント好きなんだけどね.開発チームがXの機能さえ実装してくれればなぁ
どうぞ積極的に参加してください.あなた自身がコードや解決策を提示することで コミュニティに貢献 しましょう.もし,コミュニティや開発チームから認められれば,あなたのコードはマージされるかも知れません.Archコミュニティはコードやツールの提供,シェアによって活性化していきます.
いつ新しいリリースが出るんでしょうか?
Arch Linux におけるリリースは単にインストールおよびレスキュー用のライブ環境で、base メタパッケージとその他いくつかの パッケージが含まれています。リリースは通常各月の前半頃に公開されます。
Arch Linux は堅牢なディストリなのでしょうか?しょっちゅう壊れたりしませんか?
ローリングリリースで構築された個人のシステムの堅牢性に関して、最終的な責任を負うのはユーザー自身です。ユーザーがいつアップグレードするのかを決め、必要な時に必要な変更をマージするのです。もしユーザーがコミュニティに助けを求めれば、救いの手はすぐに差し伸べられることが多いでしょう。この点に関して、Arch が他のディストリビューションから異なっているのは、Arch が本当に "Do-it-yourself" なディストロであることでしょう。破損についてクレームをつけるのは見当違いであり、非生産的です。アップストリームでの変更に関して Arch 開発チームは責任を負いかねるからです。
可能な限り安定する Arch Linux システムを構成するための方法やヒントについては、システムメンテナンスを参照してください。
Archのレビュー記事がもっと必要だ(宣伝が必要だ)
現状でもう十分な量のArchについての記事が書かれています.Archの目標は巨大になることではなく、持続的な成長が対象のユーザーベースの間で自然に起きることです。
Archの開発者がもっと必要だ
そうかも知れませんね.もっと柔軟にあなたの時間を使って貢献してください! フォーラムや,IRC チャンネル,メーリングリストなどに参加すれば,成すべきことがわかるはずです.詳細は コミュニティに貢献 を参照してください。
インストール
Arch はもっと良いインストーラーを付けるべきだ。たとえば GUI インストーラーとか
Arch には Arch Installation Framework (AIF) と呼ばれる、テキストベースのユーザーインターフェースを持ったインストーラがありました。最後のメンテナが去った後、arch-install-scripts の推奨により 廃止 されました。 2021年4月1日 から、Arch はインストーラを再度含むようになりました。詳細は archinstall を参照してください。
Arch をインストールしたんですが、シェルのログイン画面が表示されてます! どうすれば良いのでしょう?
一般的な推奨事項を参照してください。
デスクトップ環境やウィンドウマネージャはどれを使えばいいですか?
たくさんありますので、あなたに一番あったものを使えばいいのです。デスクトップ環境やウィンドウマネージャも参照してください。
他の「ミニマル」なディストリビューションと比べて Arch のどこがユニークなんですか?
Arch と他のディストリビューションの比較 を参照してください。
システムメンテナンス
システムメンテナンス も参照してください。
他のOSに比べてインターネットの速度が遅いんだけど、どうして?
ネットワークは正しく設定されていますか?ネットワーク設定のページを参照してください。
また、Arch ではデフォルトでトラフィックシェーピングが有効になっていないことも注意してださい。従って、(P2P 上か通常のクライアント-サーバー通信かに関わらず)ネットワーク帯域を使い果たすプログラムは、ローカルの他のソフトの通信を妨げ、ひどいラグやタイムアウトのような結果になる可能性があります。 Shorewall や Vuurmuur などのファイアウォールや、 iproute2 の静的なスクリプト(例えば Wondershaper の 派生) によってネットワークレイヤーのシェーピングを行うことができます。
なんで Arch は RAM を全部使っちゃうわけ?
そもそも、使わない RAM は無駄な RAM です。
新米ユーザの方の多くは、Linux カーネルのメモリの扱い方が以前の方法と必ずしも同じにはならないことに気がつきます。RAM 上のデータへのアクセスはディスクに比べ非常に高速なので、カーネルは最近アクセスされたデータをメモリ上にキャッシュします。キャッシュされたデータは、利用可能なメモリを使い果たして、新しいデータがロードされる必要のある時のみクリアされます。
free
コマンドによって違いを見分けることができます:
$ free -h
total used free shared buff/cache available Mem: 2.8Gi 1.1Gi 283Mi 224Mi 1.4Gi 1.2Gi Swap: 3.0Gi 881Mi 2.1Gi
"free" と "available" メモリの違いは重要です。上の例において、ラップトップは 2.8GiB の RAM をほとんど使っていて、free なメモリはたった 283MiB しかありません。しかし、そのうち 1.4GiB は "buff/cache" です。スワップなしで 1.2GiB の available なメモリが新しいアプリケーションの起動に利用可能です。詳しくは free(1) を参照してください。これらは結果としてパフォーマンスを向上させます!
もしあなたの好奇心が刺激されたなら、こちらの素晴らしい記事も読んでみてください。こちらのウェブサイトでもこの混乱を整理して説明しています: https://www.linuxatemyram.com/ 。
わたしのディスクの空き領域はどこへ行ってしまったの?
その答えはあなたのシステムによって変わります。こちらに優れたユーティリティの一覧がありますので試してみてください。
パッケージ管理
pacman, Pacman ヒント, 公式リポジトリ により多くの答えがあります。
Xのパッケージにエラーがあったんだけど,どうしたらいいの?
まず,そのエラーはそもそもArch開発チームが修正できるものなのかどうかを見極めなければなりません.そうでない場合が往々にしてあります(例えばFirefoxのクラッシュは大抵の場合Mozillaチームのミスです).これを アップストリーム・エラー と言います.もしArchの問題であるならば以下の手順を参考に対処してください.:
- フォーラムに情報がないか探してみましょう.誰かが同じ問題について気付いていないかチェックしてください.
- 詳細な情報を書いたバグレポートを https://bugs.archlinux.org に投稿してください.
- もしお望みならば,フォーラムに質問を投げてみてもよいでしょう.その際,問題の詳細と,あなたが既にバグ・レポートを送った旨を明記してください.それによって同じエラーに関する報告が大量に投稿されるようなケースを回避できます.
Archのパッケージにはもっと適切な命名規則が必要だ。".pkg.tar.zst" なんて長すぎるし、ややこしい
これに関しては、Arch のメーリングリスト上で議論されています。.pac
のような拡張子を提案する人もいますが、現段階では、パッケージの拡張子を変更する具体的な計画はありません。Arch 開発者の一人である Tobias Kieslich の発言は示唆的です。「事実 package は [圧縮された] tarball ファイルなわけじゃないか! だいたい tar が扱えるアプリケーションなら何だって開くことができるし、覗いて弄ることだってできるんだしさ。もっと言えば、mime-type なんてたいがいのアプリケーションが問題なく自動判別できるだろ?」
Pacman には他のアプリケーションがパッケージ情報を簡単に参照するためのライブラリが必要だ
pacman は libalpm(3) ("Arch Linux Package Management" library) のフロントエンドになっています。このライブラリは代替のフロントエンドの開発を可能にしています (例えばGUIフロントエンドのような)。
Pacman に X の機能を付けるべきだ!
そのアイデアにメリットがあると思うのであれば、pacman-dev で議論することができます。既存の機能リクエストがないか https://gitlab.archlinux.org/pacman/pacman/-/issues や https://bugs.archlinux.org/index.php?project=3 も確認してみてください。
もっとも,ある機能をPacmanやArch Linuxに追加するために一番良い方法は,あなた自身がそれを実装することです.そのパッチがオフィシャルに取り込まれるかどうかはわかりませんが,いずれにせよあなたの骨折りは他のユーザーによって吟味され,検討されるでしょう.
X のパッケージをインストールしたんだけど,どうやって起動するの?
あなたが KDE や GNOME のようなデスクトップ環境を導入しているのなら、そのプログラムは自動的にメニューに登録されている筈です。ターミナルから起動しようとしていて、バイナリの名前がわからないというような場合は、次のコマンドで確認してください:
$ pacman -Qlq パッケージ名 | grep /usr/bin/
公式リポジトリにある共用ライブラリはそれぞれどうして一つのバージョンしか用意されてないんですか?
Debian などの一部のディストリビューションは、共用ライブラリパッケージにおいて libfoo1
、libfoo2
、libfoo3
といったように複数のバージョンを用意しています。この方法では同一のシステム上で異なるバージョンの libfoo ごとにアプリケーションのコンパイルが可能となります。
Arch のようなディストリビューションの場合、最新のパッケージされたバージョンのみが公式にサポートされています。過去のソフトウェアをサポートしないことで、パッケージメンテナは最新のバージョンが期待通りに動くことの検証に割く時間をより多くとることができます。共有ライブラリの新しいバージョンがアップストリームからリリースされると、それはすぐにリポジトリに追加され、影響を受けるパッケージは新しいライブラリに合わせてリビルドされます。
システムの完全アップグレードを実行すると、共有ライブラリの更新は行われるが、それに依存するアプリケーションの更新は行われない場合はどうなりますか?
それは起こってはならないシナリオです。公式リポジトリに foobaz
というアプリケーションがあり、libbaz
という共用ライブラリの新バージョンを使用してビルドされているとして、それは libbaz
のアップデートに合わせてアップデートされます。しかしもし、ビルドに失敗した場合は、そのパッケージ foobaz
にはバージョン制限のある依存関係 (例: libbaz=1.5) が指定され、libbaz
のアップグレードの際に pacman によってコンフリクトを理由に削除されます。
もし foobaz
が、あなた自身でビルドした、あるいは AUR からインストールしたパッケージであった場合には、新バージョンの libbaz
で foobaz
をリビルドしてみてください。ビルドが失敗した場合には foobaz
の開発者にそのバグを報告してください。
リポジトリのカーネルにメジャーアップデートがあったのに、ドライバが最新カーネル用にアップデートされないことはあり得ますか?
いいえ、ありえません。例えば 3.5.x
から 3.6.x
といったカーネルのメジャーアップデートは常にすべてのサポートカーネルドライバのリビルドを伴います。ただし、非サポートパッケージ (例えば AUR のパッケージ) を使用している場合には、最新のカーネルでそれをリビルドしなければトラブルが発生するかもしれません。サポートされていないドライバパッケージは、インストールしているユーザーがアップデートに全ての責任を負います。
アップグレードの前にやっておいたほうがいい事はありますか?
システムメンテナンス#システムのアップグレード セクションに従ってください。
パッケージのアップデートがリリースされているのに、pacman はシステムは最新だと出力する
pacman のミラーはすぐに同期されるわけではありません。アップデートが利用できるようになるまで24時間以上かかることもあります。取り得る選択肢は辛抱強く待つか、別のミラーを使うことだけです。MirrorStatus で最新のミラーを確認できます。
上流のプロジェクト X が新しいバージョンをリリースしています。Arch パッケージとして新しいバージョンにアップデートできるようになるまでにかかる時間は?
パッケージアップデートは準備ができ次第リリースされます。上流リリースがマイナーなバグ修正のみであれば数時間でパッケージがアップデートされることもありますし、メジャーアップデートであれば数週間後となることもあります。上流の新しいバージョンが Arch にリリースされるまでの時間はそのパッケージとパッケージメンテナによって変わります。一部のパッケージは testing リポジトリでしばらくテストされるため、パッケージが更新されるまでの時間が長い傾向にあります。パッケージメンテナは安定版のアップデートをリポジトリで素早く提供できるように尽力しています。公式リポジトリのパッケージが古くなっていることに気づいたら、パッケージウェブサイト から out-of-date フラグを立てて報告してください。
インストールしているライブラリの古いバージョンが必要なときは、新しいバージョンにシンボリックリンクを貼るだけでいいですか?
幸運であれば少しの間それで動くかもしれません。動いたとしても、以下の理由でそれは正しい解決法ではありません:
- ライブラリは意味もなくバージョンを変えません。API/ABI が変更されたり(いくつか削除されたり)することがあり、それが使用に影響するかは単に運次第です。
- シンボリックリンクはパッケージマネージャによって管理されません。すぐにシステムライブラリのファイルをハックしようとする初心者は、診断・修正が不可能な意図していない変更を加える大きなリスクを持っています。パッケージマネージャはこのような問題から守る手助けをしています。
- 古いライブラリファイルをファイルシステムにコピーする代替手段もありますが、追跡されない上に忘れられやすく、潜在的なセキュリティのバグが気付かれず、また修正されません。
代わりに、例えば必要なライブラリのバージョンを提供する互換パッケージを使うか、もしくは作ってください。
64ビット
私のプロセッサが x86_64 に対応しているかどうかを知る方法は?
使っているプロセッサが x86_64 に対応している場合、/proc/cpuinfo
の中にlm
(Longモード) フラグがあります。例えば以下のコマンドを実行してください:
$ grep -w lm /proc/cpuinfo
Windows 上では、 フリーウェアである CPU-Z を使って、64ビット互換があるかどうか確認できます。AMD の命令セットである AMD64 または Intel の命令セット EM64T は x86_64 のバイナリと互換性があります。
64ビットにする理由は?
多くの状況下で (32ビットに比べて) 高速であり、通常の i686 カーネルでは 物理アドレス拡張 (PAE) が無効化されているために利用できないアドレス空間配置のランダム化 (ASLR) や 位置独立コード (PIC)、NX ビットを使用することによりセキュリティが向上することが挙げられます。もしコンピューターに 4GB 以上のメモリが載っている場合、64ビットの OS のみが全てを活用することができます。
更に、64ビットの拡張をサポートしている新しい x86 CPU に対して、レガシーな32ビットの CPU をプログラマーがサポートしなくなってきているというのもあります。
以上の理由が32ビット環境を避けるべきという我々のアドバイスですが、カーネルやユーザースペース、個々のプログラムなど、64ビットの方が優れているものは他にもたくさんあり、全てをここに書き出す事はできません。