Arch Linux 16

公式
https://www.archlinux.org/

ArchWiki
https://wiki.archlinux.org/

フォーラム
https://bbs.archlinux.org/

インストールガイド (英語, 日本語)
01. https://wiki.archlinux.org/index.php/Installation_guide
02. https://wiki.archlinux.jp/index.php/%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB%E3%82%AC%E3%82%A4%E3%83%89

※ 質問はインストールガイドを熟読し、ArchWiki、フォーラムを検索してから。
※ 次スレは>>980が建てること。

前スレ
Arch Linux 15
https://mao.5ch.net/test/read.cgi/linux/1568434521/

fcitx5に乗り換えてみたけどスゲー良い

>>549
kwsk

>>550
まずシンプルに見やすい。
https://i.imgur.com/P4srW1F.png

それと入力欄にフォーカスした時点で
現在の入力形式をポップアップしてくれるオプションがあって超便利。(「ja」とか出てくる)
いちいちローマ字側だっけ？とか一切悩まなくて済む。

フォーカス時にどっちの入力なのか分からなくてミスった経験は1回や2回じゃなかったから最高。

>>551
ポップアップ機能それいいな

>>551
これフォント何？

>>553
notoかな？
Debian11の/usr/share/fonts/を
全部ぶっこ抜いてコピーしたらこうなった。
この手法だとブラウザ含めて全てのフォントがいい感じになるからオススメ。

グラフィックをBIOSで設定できるのはまだましでhpでは一切触れなかった
nvidiaGPU強制有効でVRAM6GBあるのにIGPUも強制有効で強制的に2GB取られる
全く訳がわからない仕様だった

書き換えりゃええやん

fcitx5あったのか　いいこと聞いた
5ってpacmanに明示しなきゃ入らないよね　まあいつかはいらんくなりそうだけど

Debian向けのAURが登場したらしい
https://dur.hunterwittenborn.com/

pkgbuidで使えるの？
Linux版のbrewもあるけど、アーチのパッケージシステム使えたらいいよね。

pacmanクソ有能だからね

てかaurに統一するんじゃなくて、サンドボックス機能があるflatpakしかりsnap然りに統一してほしい感ある
最近pipewireなりwaylandが使えるまでに進歩したし

Gnomeにしてみたけど言われているほど悪くない
設定でアニメーション切って
なるべくショートカットキーを活用するとサクサク動かせる

初心者向けのDEだと思って使うと面食らうけど
キーボード操作前提の中上級者用のDEだと頭を切り替えて使うとかなり良いね
i3やXmonadの超リッチ版だと思って扱うとめっちゃ快適で
カーネルメンテナ達が愛用するのも納得

i3も悪くないけど、快適かと言われるとね。

i3然りwmで快適じゃ無い点ってなんや？
ノーパソ利用ならwmってクソ神だと思うんだけど…

特に自分的にいい点は、マウス操作するのブラウザくらいでほぼキーボードから手を離さなくて済んだのとtmuxを使わなくなった

キーボードに慣れるとマウス前提のDEに戻れないのは分かる
Gnomeがキーボードで行けるなら乗り換えもありかな
リーナスやGKHがマウスを頻繁にカチカチしてる姿は想像しにくいし
実際キーボードで完結するんだろうね

>>554
Noto fontは中・日・韓の言語を包括サポートするnoto-fonts-cjkが多くのdistroの公式
リポジトリにあり、Archにもある[*]。他のdistroから持ってくるとfontがupdateしても使用
distroが知る術がないので、その手法はdistroに含まれないもの以外は、お勧めできない。
公式リポジトリからインストールするには、以下で。
----
sudo pacman -S noto-fonts-cjk noto-fonts-emoji

[*] フォント - ArchWiki
https://wiki.archlinux.jp/index.php/%E3%83%95%E3%82%A9%E3%83%B3%E3%83%88

フォントは抜けがあるだけで一気に汚くなるから
大手のdistroから引っ張ってくるのは効率的ではある

抜けを気にするならそれこそNotoでいいだろ

snapにサンドボックス機能があってもあんまり必要なシーンが思いつかない。開発者はDockerで検証すればいいだろうし、性能に響くだけじゃん。

Dockerとsnapでは抽象化してる層が全然違うやん

フォントは余計なの入れると古いの使われて汚くなることあるわ
JAVAとか汚くなると厄介

コピペで持ってくるのはWindows専用のやつだけ

>570
何が言いたいかさっぱりわからん。Dockerで安全ならsnapでも安全だと思うけど。
そもそも、パッケージマネージャーがないとサンドボックス運用ができないのが問題じゃなくて?

確かにメリットはよく分からん。
だから全然普及してないんだろうけど。

>>567
ArchもArch系と言われるdistro群の上流に位置する、大手の一つだが。

>>574
Snapは開発しているCanonicalのやり方に一部メンテナが異議を唱えている。LinuxMintの
創設者、Clement Lefebreは上流のUbuntuがChromiumのサポートをSnapに限定した手法の
内容が、ユーザーを欺く行為[*]だとして、Mint20以降、Mintリポジトリからsnapdを削除した。

[*] Linux Mint dumps Ubuntu Snap
By Steven J. Vaughan-Nichols June 5, 2020 18:52
https://www.zdnet.com/article/linux-mint-dumps-ubuntu-snap/

Ubuntuは一部のシステムすらsnap化してるという記事を読んだことがある
将来のアップグレードでsnap廃止とかになったら作業が面倒くさそうだけどいいのだろうか

MintはとにかくUbuntuに逆らいたいだけって印象
親に養ってもらいながら親に反発する子供みたいな

リソース足りてないのに上流とコンフリクトする方向に乖離したプロジェクトは消える運命よ
Mintがリソース足りてるのかどうかは知らん

mintはシェア落としてるでしょ
ユーザーフレンドリーなディストロが増えてきたから

さっさとcleartype対応してくれよいつ特許切れるんだよ

GNOME 40への対応を見るにUbuntuも色々と弄りすぎて
パッケージ側の大きな更新に追従する余裕がなくなってきてるね
Unityとか自前で作ってた頃と比べると相当開発規模が縮小してそう

snap嫌いなんだよなあ
fdisk -lがひどいことになる

ループバックのマウントポイントが大量に出てくるってことかちょっと分かる

大量のハッシュ名ファイルを作るflatpakも嫌い

バイナリ1つにまとめてくれたら管理が楽なんだけどね
パフォーマンスも考えると難しいか

snap てdockerで動いたっけ？
前にインストールしてダメだった気が。

>>585
appimage

AppImageは1ファイルで良い感じだけど普及率の低さとアップデートの面倒さが欠点

GNOME40試してみたけど
アニメーション無効化したら確かにi3感覚で使えるね
初期設定はtrackerの無効化と端末エミュ起動のショートカット設定くらいで十分
メモリ使用量はそれなりだけど動作速度はラップトップで使っても相当速い

使わないメモリは無駄なメモリ
余ってるメモリは積極的にキャッシュとして活用したほうがいい

誰もそんな話してないが

ケンカ腰の書き込みはNG

最近思うんだけどArchが壊れる原因って
pacmanのパッケージでの依存関係の定義の甘さもあるよね
アップストリーム追従だから仕方ないけど
公式リポジトリでも依存関係の不足が発生する場合がある

いや、yayなりのparuなりの非承認pacmanパッカー使ってるのが原因や‼︎aurutilsを布教したい‼︎

>>593
主要なライブラリのアップデートがあると依存するアプリ全てビルドしなおす必要あるから大変やね
https://archlinux.org/todo/
最近はsonameを公式で追えるようになったから楽になったとはいえ

pacmanで壊れるとか言ってる奴でちゃんと再現性のある実例出てきた例がまったくねーよな
いっつも｢〇〇入れたら依存関係がぶっ壊れてぐちゃぐちゃ｣みたいな何の再現性もない曖昧な日記ばっか

使い方も理解しない原因も特定しないでてめぇでぶっ壊して｢ふぇぇ何もしてないのに壊れたよぉぉ｣とか騒ぐんならWindowsでも使ってろやwww

>>596
何もしなくても強制アップデートで壊れるwindows勧めるとか鬼かよｗ

再現性のある実例ったってArchで再現可能な説明をしようにも
インストール手順から何から全部説明する事になるから困難でしょう
仮に全部説明されたところで常に最新になるからこっち側での再現も無理だし

>>598
それな〜各々の環境全然違うから、飽くまで解決の一例又は依存関係のエラー吐かれるって情報が沢山あるだけ有益だと思うけどな〜

寧ろなんも凝って無いインストールガイドこそ要らへんわ

>>598
> 再現性のある実例ったってArchで再現可能な説明をしようにも
> インストール手順から何から全部説明する事になるから困難でしょう

アホ？
なんですべてのレイヤをごっちゃにして考えるのだ

最近遭遇した例だと、lua52とlua両方のパッケージが入った状態で
vlcをビルドすると失敗するという依存関係での不具合があった。
解決方法はlua52を削除。

依存関係は不足ならまだ分かりやすいけど
上記のような組み合わせて初めて発生するタイプのエラーもあるから厄介。
個々のパッケージの依存関係だけ見ると完全に満たされてるからね。

ビルドはまた別の話だろ
Arch (pacman) は別に手元でビルドするための依存関係を解決してるわけじゃない

やり直し

本人は具体的に指摘してるつもりなんだろうけど相変わらず｢依存関係での不具合｣とかいうぼんやりした物言いに終始してて草

vlcのビルドで誤ったライブラリを参照されるということであればvlcのバグなのでは

頻繁に依存関係が壊れるパッケージといえばhaskell関連だな。
archのたまに出てくる依存関係壊すやつは公式の手順どおりに使ってないだけって奴は単純に使ってるパッケージが少ないだけ。
普通に更新切れたパッケージが削除されずに残って依存関係を壊す（パッケージが腐る）こともあるし、経験足りないんじゃないの？
ただそのぐらいの不具合は他のディストリにもあるし、そのぐらいはアーチユーザーが空気吸うみたいに修正して使うから問題にならないだけだ。

昔からフルビルドして使ってる人からしたらパッケージマネージャーは依存関係の補助でしかなくて、Linuxにインストールするソフトやファイルの位置は自分でコントロールするのが普通でpacmanはそれがやりやすいだけで、依存関係をわざと壊そうとしたら普通に壊せるからな。
Luaのパッケージにしたって危惧すべきことが起きたなあって感じだ。

error while loading shared libraries: libfoo.so.1: cannot open shared object file: No such file or directory
とか言われたら
1. libfoo.so.2とかの似た奴がないか探してもしあったら｢$ ln -s libfoo.so.2 libfoo.so.1｣とかやって自分でシンボリックリンク作ってやる
2. 1がなかったらUbuntuとか別ディストロからlibfoo.so.1.1.1とかをコピーして持ってきて｢$ ln -s libfoo.so.1.1.1 libfoo.so.1｣とかやって自分でシンボリックリンク作ってやる
ってやってやれば良いんやで




ってのはウソやで、どっちもよく見かける間違った対処法だから真似したらアカンで

>>605
cabal使ってて壊れてるならインストールしたいものに依ってはちょっと面倒かもだけどstackage使った方がいい
haskellライブラリ専用のディストリビューションみたいになってて依存関係で壊れる心配がなくなる

>>608
おっしゃる通り、もうパッケージマネージャーに依存してなくて、stackコマンドで管理してる。
依存関係壊れなくても頻繁にpacmanのビルドが更新されるからアップデート時の負担になるので切り離したほうが圧倒的に楽だった。

stackがない頃 (有名じゃない頃？) に構築した環境そのまま使ってるから pacman まかせだわ
haskel 関係のアプデ多いからウザいっちゃウザいんだよな
今のところ不具合というのはないが

カーネル5.13はどう?

>>605
本当それですわ
開発とかで大量のパッケージ入れ始めると
pacmanへの信用がなくなる

自分の開発環境とディストリの配布物は混ぜないようにするのが良いとxmonadで学んだ
ちょっと想像すると分かるが、自分のPCで今動いている自作のソフトウェアが本当は何に依存しているのか、把握するのって結構大変よ

xmonad何かあったんか?

そりゃ会話の流れ的に、開発用途で入れたライブラリで
Xmonadの方のHaskellの依存が壊れたんでしょ

開発でHaskellライブラリ使うことあるのか
猛者かね

もう4〜5年近くarch使ってるけど、公式アナウンスされるのとほんの少し程度しか依存関係然りbootしなくなったことねーけどな〜

皆猛者で弄りまくってるからなのか、皆が何も考えず弄ってるのか、はたまた俺が優秀なのか、はたまた俺がなんも弄らんで使ってるから壊れないのか

どれなんだ一体？！

Archでマイナーな構成にすると
自分しか遭遇しないであろうトラブルにも結構見舞われるから
もう諦めてGNOMEにしてるわ

実際ソフトウェア開発にはあまり向いてないね
公式の開発環境の導入手順がDebianやfedora用しか紹介されてない事が多いし

開発とかいう言葉に逃げてるフシがあるが、本当に開発のために夥しい数のかつdevelopingなパッケージをインストールする必要があるなら今はdocker等を検討するべきでしょう
それに、DebianやFedoraは平気なのにpacmanでは解決できてない依存関係というのが本当に存在するなら、抽象的な物言いでなく具体的にいつのどれと言えば良い


>>613とは別人だと思うが、
> 自分の開発環境とディストリの配布物は混ぜない
って何を今更ってくらい当たり前のことですよ
アマチュア開発者さんたちの率先してわけわからんことして喜ぶくせ、本当に良くないよ

ArchはAURで勝手に開発用の依存関係入れてくるから
AURが必要ないようなミニマルな用途じゃない限りは避けられないでしょう
逆に619さんがどういう用途でArchを使っているのか気になるよ

一言に開発と言っても言語やフレームワークによって前提条件異なるからそこの認識合わせないと議論はすれ違い続けるのでは

それ 情報系言葉の定義が広かったり、多様な意味あったりとで明確な名称で定着してほしいもんだ

>>620
それが、Archが公式にAURパッケージのインストール補助をしない理由なんですよ


> ArchはAURで勝手に開発用の依存関係入れてくるから
これは言っちゃ悪いが糖質並みの妄言だ
いつどのように「ArchがAURで勝手に開発用の依存関係入れ」たのか説明しろ
逃げんなよ絶対しろ

node.jsだったらnvm使うしrubyだったらrvm使う
それがhaskellだったらstackだったってだけでは

全部過去の話よ
https://wiki.archlinux.org/index.php?title=Haskell&;oldid=294693 あたりの
日々使うソフトはpacmanで管理したいけど、ちょっと興味が湧くから開発環境も入れるじゃん？
cabal-installとかもとりあえず使ってみるじゃん？

で、しばらくするとcabal-installで入れたもの、それを元にmakepkgしたhaskellのパッケージ、pacmanが管理しているもの
全部が混在することになってpacman -Syuするとghc-pkgが怒る

もちろん、これは「何もしていないのに壊れた」なんて当時も思っちゃいなかったが、「何が悪いのか分からない」状態にはなった。

言語やフレームワークごとにパッケージマネージャがある場合はどう考えてもディストリのパッケージマネージャとは使い分けるべきだ
pip しかり cabal しかり
使い分けると言っても、単にユーザー環境下 ($HOME 以下) にインストールすることにすれば足る話
これは開発とはまたレイヤの違う、常識やモラルの話だろう


>>625さんは分かっておいでのことだと思うが、他の多くの方はどうもこの点を理解されていない

やっぱ結局なーんも理解しないで｢何もしてないのにぶっ壊れた｣って騒いでるだけっていうね

"ぎじゅつりょく"至上主義は頂けないな。
発展性の無い事に頭や時間を使うのは趣味でしか無い事くらい自覚しときなよ。

ライブラリを共有するのが悪いってことでそれがsnap？

話のきっかけの<<605たけど、
俺は一言も開発環境と言ってなくて、haskellの公式パッケージはたびたび依存関係が壊れるって話。
Rubyもnodejsもシステムのパッケージ壊れないだろ。

ちなみにたまーにglibが壊れるのと同じ理由、原理的に壊れないということはないのよ。

バイナリ配布は難しいのよ。

いつんなったら自分がサポート外のことしてぶっ壊してるだけなんだって気づくんだろ

相変わらず｢壊れた｣が何を意味してんのかすらはっきり言わねぇからあれだけど
仕組み的にはサポート外のことしなきゃ壊れなくなってるしサポート外のことしてないのに壊れてるならバグレポすればいいだけ
ちゃんと理解してるなら対応も簡単だし今ここでバージョンとかの具体例を上げればいいだけ

理解して無くて｢なんもしてないのに壊れたよふぇぇぇ｣とかしか出来ないから具体例が上げられないんだよな

ちょっとまって、依存関係が壊れた で何を意味してるかわからないユーザーがいるの？
シングルバイナリじゃないとモジュールに依存して動くんだけど、それが壊れるってだけなんだけど、それがわからないの？？

>>633
どんだけレベル低いんだよ
ただ｢壊れる｣としか言わねぇんじゃ動的リンク時の話なのかもロード時の話なのか単純にライブラリが見つからないのかとかsonameの付け間違いなのかそれらが上流のバグなのかArchのバグなのかアホユーザーが自分で壊したせいなのかとか腐るほど可能性があって話にならねぇんだよ
だからバージョンなりエラーなり具体的に言えっつってんの

>>634
なんていうか、おつかれ。俺そんなのはコミュニティに直接報告するからここでは書いても意味ないし、知りたいことは自分で調べるから十分だわ。
説明してマンに説明するぐらいなら開発者に言うわ。
あと大抵、pkgbuildのミスかパッケージ更新のタイミングが殆どの原因だよ。
Haskellはバージョンが変わると基本全部ビルドし直しだから更新のタイミングがずれただけで壊れる。
これ以上は説明する気さえ起きない。調べろ。

あと普通はリンクできなくてエラーになるのを依存関係が壊れると言うと思う。
言葉ミスってる奴はいるし、俺はスルーしてる。
他の原因まで考えないそれが普通。
間違ってたら間違ってるよといえばいいだけ。

ロードできないとかは依存関係は壊れてないだろ。

勝手に可能性を広げて拡大解釈して意味わからんとか何がしたいか全然わからん。

な、結局なーんも理解しないで自分でぶっ壊して｢なんにもしてないのに壊れた！｣とか言ってるだけだろ？

>>638
ちゃんと読めよ。遠回しに否定されてんだろ

>>638

<<606

> あと普通はリンクできなくてエラーになるのを依存関係が壊れると言うと思う。
な、やっぱなーんも理解してない

リンク時にエラーになるっつーのはつまり自分でビルドしてるときの話なわけだがそれはつまり公式の立場から見りゃAURと同じで"サポート外"なわけ
公式のパッケージは依存するライブラリの非互換な変更によるリビルドやパッチの必要性をTODOでリスト化して対応してから一斉にアプデって形がとれるけど
無限にあるユーザーのオレオレビルドオレオレパッチのために公式の側のアプデを遅らせるなんて不可能だからな

んでそれは固定リリースのUbuntuだろうがDebianだろうがリリースが変われば非互換な変更が起きるんで同様の問題が起きる事に変わりはない

>>630
golangやrustといった最近の言語が静的リンクデフォルトにしてるのはバイナリ配布難しい問題に対する一つの回答なのかね
言語のランタイムも静的リンクするからコンパイラのバージョンアップでABI/APIが変わっても影響されない
その分ディスク容量は食うわけで富豪的な解決策ではあるが

>>642
*nixのモジュール主義は初期のディスク容量の制限からきてるし、当初はみんなビルドしてたから問題なかったし、動的リンクの方が良かった。
今は静的リンクの方がめんどくさくないから当然考えられるオプションだと思うよ。
なるべく依存したくないのはみんな同じだと思う。

>>420>>980
次スレは
--------
システムメンテナンス (英語, 日本語)
https://wiki.archlinux.org/title/System_maintenance
https://wiki.archlinux.jp/index.php/%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%83%A1%E3%83%B3%E3%83%86%E3%83%8A%E3%83%B3%E3%82%B9
--------

も追加してくれ
AURやローカルでのビルドはアプデ時に自分で対応が必要とかの基本的な事もちゃんと書いてある

>>641
当然、自分でビルドしてないのに見つからないことがあります。
他人には詳細に前後の関係を求めるくせに、自分は偏見で判断するの良くないよ。

あと依存が壊れたのをアーチの所為には誰もしてない。壊れたと事実を言ってるだけ。

Ubuntuなら壊れないとかDebianならこんな事にはならないなんて誰も言ってないのにそういう声が聞こえるみたいだし、なんかの病気だろうね

まあでもHaskellの依存関係が壊れるのは頻繁にHaskellのバージョンを上げてるのが一番の原因だけどな。
関連パッケージが同時に更新されないのも痛い。
Haskellに関してはアーチとの相性が圧倒的に悪い。
あと単純にHaskellが時代遅れ。

xmonad使う層が自分たちで解決しちゃうのもあって初見殺し感もある

haskellはビルドした時点で依存関係がガチガチに固まるってことを分かってない人がいるな

今は1000近いhaskellのパッケージをほぼ1人で作成しているんで壊れにくくなってる
が、これってあんま健全じゃない