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/

>>355
ありがとう、無事に動きました
gitバージョンが無くなってたのね・・・

リポジトリから落ちたパッケージとかアプデで必要なくなった依存パッケージがそのままになるのは割とよくある罠だね(罠ってほどの問題ではないけど)
pacmanのhookで毎回アプデ後に-Qmqと-Qdtqして一覧表示するようにしてるわ

ってそういう話じゃないか、スマン

いや普通によくあるよ！壊れたうちに入らないと思って対処してるけど初見殺しだと思う

manjaroスレに書いたらスレチと言われちゃった
Archスレ有ったんだ

インストールマニア
mint, manjaro, sparky, MX, Endeavour,
と来てとうとう Arch「Calam-Arch-installer.ISO」迄入れちゃった。
正味10分程で終了再起動後は何時ものデスクトップだ。
凄く軽いが、なんでだ？　ゲームがいっぱい入ってる。いらないのはどんどん削除。

inxi
CPU: 6-Core AMD Ryzen 5 PRO 4650G with Radeon Graphics (-MT MCP-)
speed/min/max: 4096/1400/3700 MHz Kernel: 5.12.6-arch1-1 x86_64 Up: 5h 53m
Mem: 5431.8/15358.1 MiB (35.4%) Storage: 4.8 TiB (19.0% used) Procs: 333
Shell: Bash inxi: 3.3.04

uname -r
5.12.6-arch1-1

lsb_release -a
LSB Version: 1.4
Distributor ID: Arch
Description: Arch Linux
Release: rolling
Codename: n/a

Twitterでやれ

今は他にArch Linux GUI Installerってのがある>>360
こちらはデスクトップ環境など構成毎にイメージが分かれているのでより簡単　

「ArchをGUIでインストールとはけしからん！」って言う人が出てきそうな…

だろうね
だけど時代がそれを求めて今存在するのは
Manjaro等派生鳥ばかり持て囃される流れへの危惧からかも
インスコさえ乗り切れば派生使う利点ほとんど無いしね

25、6年前Linux 出始めからやってるんだな。
何も参考になるものがなくて、すべて英語、command。「startx」で何もないデスクトップ、１から作っていくんだよ。
今は楽だー、初めから日本語、「root,home,swap,boot」パーティションを作っておいてインストール。
再起動すればもうすぐ使えるデスクトップ。「ArchWiki」初め参考サイトがいっぱい。今はほんと楽。

https://imgur.com/a/8fXIW9y.png

>>366
メニューバーのフォントがイラついた

https://imgur.com/8fXIW9y.png

なぜ無能は自己紹介がうまいのか

>>369
自己紹介だと気付いてないから

1992年秋頃からの情報しか知らないけど当時からネットニュースで日本語のLinux情報あったし
X11はLinux専用というわけでもないからunixの日本語情報は更にいろいろあった
sunosとかで使ってる設定持ってくるだけで1からやらなくてもそこそこ動いた

まあ当時はドライバもモジュール化されてないからハードに合わせてカーネルビルド必須とか
グラフィックドライバ設定は確かに苦労したし、ライブラリ無いとか怒られてソース探してきてmakeからとかも多かったけど
「英語しかない状況」は25,6年前には払拭されてるはずだが

ネット環境がおそまつだったのかな、ニフティのパソコン通信位で。
日本語情報はそのころあふれるように出てきた雑誌、「UNIX USER」の
おまけ「CD」から色んなのをインストールしまくった。
「debian,vine,思兼,kondara,Storm.....」記憶の中で「難しい」「英語」と置き換えられたかな？
「Enlightenment」のド派手なデスクトップにのけぞったり。
フロッピーでブート、「lilo」は簡単なテキストで、順番も自由に変え、背景画像も、起動時サウンドを鳴らす設定も楽だった。
Windows3.0から3.1になった頃、一太郎のインストールもフロッピーで何枚あった？

>>372
>>1

なんかここ数日アプデが0であれ？と思ってたらmirrorlistの一番上のmirrors.cat.netがしばらくエラーで更新されてないね

まーた依存関係ぶっ壊れたぁ
容量も圧迫してたし入れ直すかな
スクリプトの使い心地を試すチャンスと前向きに捉えよう

どうぶっ壊れたの？

大してスキル無いから解決できないのは（libglewとか）消しては入れ直してるけど
今回は依存関係がこんがらがって消したらあかんて怒られるし
そんなこんなしてたらGwenviewが窓枠表示だけになる不具合出て
面倒くさくてもういいやって感じ
調べるよりクリーンインスコする方が手間も時間も掛からないので
そんなだから一向に向上しないのだけどまあ

どういう意味？
公式リポジトリにもAURにもないものを自分でビルド・インストールして依存関係が壊れたってこと？

いずれにせよアプリケーションごとの設定とパッケージ同士の依存関係を切り離せてないし、そんななのにやけに達観したような語り口なの笑えるな
依存関係じゃなくて己の認知がぶっ壊れてるんだよ

それで良いよ
自分はそれで間に合ってるから

>>377
> 大してスキル無いから解決できないのは
いや、どんな問題を解決しようとしてそれをしてるの？？
あ、非難とかじゃなくて単純に技術的な興味の質問です

ド安定のDebianにおいでよ

ぶっ壊れた ←まちがい
ぶっ壊した ←せいかい！

>>382
しかしArchWikiの充実っぷりは異常
Debian系の人もみんな見てる

>>384
Debianも使ってるけどArchWikiは本当に有り難い
ディストリなんか好きなの使えばいいじゃんね

いつか戻ろと眺めながら Ubuntu

全部パッケージ入れ直せ

https://ascii.jp/elem/000/000/475/475007/2/
10年以上前だしディストロも違うけどUbuntuJPの中の人が悲哀を語ってますなぁ

>>388
今ならもうほとんどUTF-8じゃない？

pacman6ついにきたね
paralleldownloads試したけどめちゃくちゃ速い

新しいpacmanはyay-binと衝突するのか

paru-binが一時動かなかったのはcat.netのせいかい
jaistを先頭にしたわ

>>391
yay、git clone, makepkgした。こんでいいのか自信ないけど。

>>393
yay-binでなくyayならいいのか、ありがとう

カーネル5.13からzstdが超絶進化するみたいだな。
楽しみだ。

zstdはまだ新しい規格だからまだ高速化の余地があるんだよな

Archの更新ってフリーフォールなみにこわいの？

https://twitter.com/chor0sK/status/1400099977112608774
NixOSを使ってても結局OS更新は清水の舞台から飛び降りる気分ではあるんだけど、Arch linuxはフリーフォールな気分なところ、NixOSだとバンジージャンプみたいな気持ちで飛び降りれる。rollbackできるから死にはしない。
https://twitter.com/5chan_nel (5ch newer account)

意味がわからんバックアップ作るなりetckeeperで管理するなりすればいいだけだろ
自分の技術力不足を他に押し付けるな

使おうsnap-pac
https://github.com/wesbarnett/snap-pac

システムなんてぶっ壊れようがいくらでも簡単に直せるしどうでも良いよな
エロ動画が消えるのだけは絶対許されないからデータ用のパーティションだけは多重バックアップ必須だけど

起動しなくなるなんてレベルで壊れたことはない

8年くらい使ってるが、アプリケーション毎のトラブルしか踏んだことないね (wine等)
アプデが契機でシステムごと、しかも復元不能なまでにおかしくなるなんて想像もつかない

おそらく、DEとかWMのトラブルで画面がつかなくなったりしたのも「システムが壊れた」と見なして叫んてるんだと思うが、そういうのは利用者のモラルの問題だね
軽々しく「Arch のアプデには勇気がいる」みたいなこと言わないでほしいなあ
発言者がどういう方かは知らないが、転載されてここまで来るということは影響力のある人なんだろうし

AURと混ぜると危険
標準リポジトリのみなら特に問題はない。
良くも悪くも壊れるようならArchのようなミニマルなディストリ向きのユースケースじゃないと思う

A(nixOS)をアゲるためにB(arch)を下げる、的な論法を真に受けなさんな。

# python上がってpython製のwmがちょっとおかしくなったり、pipewireの
# 設定に互換性が無くなって .pacnew で上書きが必要になったり、lvmeatd
# がxx で起動が遅くなったり、とか systemd-resolvd がー、とかちょいちょい
# あるのでリスクを感じないとは言わない。

arch固有の話というかローリングリリース一般に通用する話が多い印象

安定板でローリングリリースは事実上Arch系固有だからね
対抗馬はWindows10くらい

>>404
空行以下って全く致命的なトラブルじゃないでしょ

ところでPython製のwmってどれ？

更新が怖いというか
AUR経由での直接インストールが多いのが設計上の弱点だよね。
野良製アプリ前提だからある意味Windowsに似ているといえる。

公式リポジトリしか使ってない限りは依存関係が崩壊しないっていうのは強みでもあるんじゃないか
問題の切り分けもしやすい
野良パッケージもpacman経由でインストールするわけだからリムーブも簡単だし、公式パッケージとの依存関係も基本的には取り持ってくれるので、configure; make; make install とはわけが違う

Archは月1回リリースだから新しさと安定性のバランスが取れてるかと思うけど
どうなん？

上で出てるNixOSは最近使ってみたが
年2回リリースなので、安定版は段々ソフトウェアが古くなる
依存関係が厳密で、依存関係崩壊によるエラーは無いが、
使いたいソフトウェアがパッケージ化されてないと自分でパッケージ化必要でつらい
これはNixOSがと言うよりマイナーなディストロの弱みかもしれんけど

パッケージは基本的に上流で既に｢安定版｣とされたものだし
数少ないArch由来の変更や設定もcoreとかに入る前にtestingに入ってテストされてるわけだし

不安定って言ってるやつは何を論理的な根拠に不安定だって言ってんのかね
ただ｢ぼくが不安定だと思うから不安定なんだ！｣ってだけ？
それともtestingでのテスト期間が短いとかかな

他のディストリからしたら安定版はArchやらで試されてるから安定なんだろうけど
ArchやFedoraの場合は最初にその安定版とやらが降ってくるポジションだから
安定版といっても少数のテスターの環境での安定してる程度の意味しかないよ。

そもそもアプリ自体が最新版入るんだから安定とか安定してないとかそういう問題でもない気がする
どんな OS でも最新版のアプリにすると今までできたことができなかったりできるようになったりするのは当たり前だし

安定版がちゃんと安定しているかどうかは上流のリリース基準によるからなんともいえんね
バージョン自体は古くてもメンテナンスが行きどといてなくてそもそもバグが放置されてるソフトウェアとかもある

Arch自体は最新の安定版ってちゃんとした基準があるんだから、古いのや新しいが使いたいならユーザー側で変えればいい
Debian Testing、SUSE Tumbleweedなんかは同じローリングリリースでもベータ版が普通に落ちてくるし
GentooやNixは逆にローリングうたってるわりにバージョンが安定版から数年遅れの場合も少なくない
Ubuntuみたいな固定リリースの場合は上流がサポートしてないメンテナンス終了してふソフトウェアも含むから話が全然違う

ソフトウェアのバージョンアップしたくないならpacmanのignorepkgで設定しておけば、
依存しているライブラリがABIに破壊的な変更加えない限りしばらくの間は使えるし
そもそも設定ファイルの構文がバージョンによってしょっちゅう変わるような開発途上のアプリは安定を優先させたいなら避けるべき
どのディストリ使ってようがいつかはその変更の影響受けるんだしそれがまとめてくるか細かくくるかの違いだけ

ローリングリリース故に別パッケージのアップデートに追従するまで間が空くことがあるくらいだな

特定バージョンのアプリケーション使い続けたいならdockerなどに頼る方が良いんじゃないかな
デーモン系だと難しいけど

>>407
> ところでPython製のwmってどれ？
qtile 当時ローカル改造しながら使ってた。

致命的、じゃなくてもなんかあったらリカバリ出来る時間が取れるときじゃないとね、って事。
プライベートな作業やってる時とか仕事の前にアプデかけるリスクは取れないよ。

言ってるそばから早速pacman6.0でyayが破壊される不具合が発生したみたいだな。

もう次スレから
｢Partial Upgradeはサポート外｣
｢公式リポのパッケージに非互換な変更があったらそれに依存するAURのパッケージはリビルドが必要｣
みたいな基本的な注意点だけでも入れね？

基本的なこと理解しないでサポ外のことして自分でぶっ壊しといてArchが悪いと騒ぐバカが多すぎる

Arch試してみようかと思ってたんだけど
AURって無くても困らないの？

>>421
コマンド1発でパッケージマネージャ外のソフトをビルドインストールできるだけだから困らないよ

今朝アップデートしたらtimeshiftが機能しなくてちょっとビビったが
リビルドして日常を取り戻した

>>420
このスレの住人に喚起すべき注意点ってよりは、社会の問題な気もするが
データサイエンティスト笑志望のアホが環境作ろうと思って変なことしてるみたいな背景があるのかな


>>421
AURは便利である
し、野良パッケージをインストールするときもAURの作法でやるのが良い
>>420に書いてあるようなことは守る必要がある

パッケージマネージャ外のはAURでソースからビルドしろって文化？
ビルド済みバイナリないの？

パッケージマネージャ外だから
非互換の変更あっても自動でリビルドしてくんないの？

>>425
バイナリもあるよ
なんとか-bin
って名前だとバイナリ

なんとか-git
だと、gitからソース拾ってきてビルドしてくれる

他には、appimegeとかもたまに転がってる

ビルドするヤツでも、pkgbuidファイル更新してくれないと
自動更新で再ビルドとかできないから
最終更新日とか
ユーザーからの評価とか、利用者どんだけいるかとか
もう、メンテされてないのとか
自分で選んで使わないといけない

メジャーなヤツだったら、そんな酷い目に会わないと思うけど…

>>425
arch wiki くらい読めよ……と思ったが、思想・方針的な話はあんまり書いてないな。

「AUR は……人気のあるパッケージが [community] リポジトリに取り込まれるように、コミュニティの手で新しいパッケージを共有することを目的に AUR は作られました。」

AURはもともとパッケージ開発を目的としているので、パッケージビルドスクリプト（PKGBUILD）を共有／パッケージそのものは自分で作れ、という文化。PKGBUILDの中身はbashスクリプトなので、ソースコードからフルビルドするものもあるし、ビルド済みプログラムをダウンロードするものもある。そこはPKGBUILDの作者次第。

何で人気のあるパッケージyayをcommunityに取り込まないのかは謎だな

yayはほとんど開発止まってる状態だからなぁ

>>428
yayに限らず、AURヘルパーは公式でサポートしない方針。

昔フォーラムでQAが存在しないユーザーリポジトリからのインストールを自動化するようなアプリは公式リポジトリには入れたくないって偉い人が言ってたけど、
じゃあmakepkgするときいちいちスクリプトや参照先のソースを監査してるのかいって言う話になるし、実際大多数の人間は細かいこと気にしないでyayとか使ってるわけだが

え？流石にスクリプト眺めるよね

AURは自分で判断ができる程度の数のパッケージしか入れないわ
それこそ公式に合わせてリビルドが必要なこととか忘れて後からどうしてなのか悩みたくないし

ぼーっと眺めてても単純な記述ミスにすら気づかない自信があるし真面目に1行ずつ読んだところで悪意を持って巧妙に隠されたら気づかないだろうから気にしてない
そもそもまじめにソース確認する人ばっかりだったらbinパッケージなんてものはAURに存在しないだろう

メンテ放棄されてたacroreadに悪意のあるスクリプト注入されてたのもう忘れたか

>>431
> 実際大多数の人間は細かいこと気にしないでyayとか使ってるわけだが

だーかーら、そういうスタンスの人はあえてArch使う必要なんかないんだって
AURは素晴らしい
が、それはAURを公式リポジトリさながらに使いましょうということを全く意味しない
Archのミニマルな思想と利便性の間を取り持つためにAURは存在するんだってなぜ分からない
思想なんか関係ないよと思うなら正にArchなんて使う必要はない

>>434
> そもそもまじめにソース確認する人ばっかりだったらbinパッケージなんてものはAURに存在しないだろう

……バカ？

>>434
多分スクリプトはaurのパッケージを作るスクリプトを指してると思う。
binを使うのはわざわざ自分のマシンでコンパイルしても大して最適化されないものだよ

まあ好ましくはなくても自己責任で｢見てもわかんねーしまぁいっか｣って判断してもそれはそれで別に悪くないっしょ
悪いのはわざわざ｢AURは誰でもアップできるから自己責任で使えよ！｣って太字で書いてあるのに何も理解しないで使って問題が起きたら騒ぐガイジ

それはそうと、AURで多くの人にインストールされててかつ公式のアプデに取り残されてシステムに深刻な影響を及ぼしうるパッケージって何かね

自分の環境眺めてみたら有名どころは nkf と displaylink と slack と zoom くらいしかなかったし平和なもんだ

>>439
両者、層が被ってそう

>>438
ソースURLに適当にでっち上げたサイトのURL書いとくだけで何だってできるのにPKGBUILDだけちらっと眺めてどれほどの意味があるのか

>>435の言ってる奴とかはcurlでダウンロードしてbashに渡すみたいな隠そうともしない露骨に不審な奴だったから眺めるだけでも割と気づけそうだし全く意味無くはないだろうとも思うけどね

ただ俺は全部チェックしてるって言うやつはじゃあ
Nodeに依存するパッケージがnpmでインストールするパッケージの中身まで全部把握してんのか？
Rustに依存するパッケージがcargoでインストールするクレートの中身まで全部把握してんのか？
みたいな話になるし現実的に個人が100%もれなくチェックするなんて無理だしな

結局｢意味ないからお前らも見なくていいーよ☆｣っておおっぴらに開き直って良いもんでもないし逆に｢隅から隅までチェックしろ！！！｣って強制するもんでもないし
リスクを承知した上でそれぞれが自己責任で利便性との間で適当にバランス取るしか無いわな

上流でウイルス混入してるのと
AUR自体のスクリプトにウイルス入ってるのは別問題じゃね？

そういうの嫌だったら普通にUbuntuとか使えば良いんじゃね？
なぜArch？
パッケージ新しいから？

アップストリームに問題なくてもAURのパッケージメンテナに悪意があったら何だってできるわけ
PKGBUILDのソースURLがmozila.orgかもしれないしkernel.netかもしれないしパッケージ名っぽい独自ドメインかもしれないしgithabかもしれないし
実はユーザー名が一文字足りないかもしれないし一見普通のユーザーかもしれない
あるいはソースは本物でもパッチの一つに何か仕込まれているかもしれない
ソースパッケージだったらダウンロードして確認ということも原理的には可能だがバイナリパッケージだともうどうにもならない
まぁarch wayの伝道者ともなるとバイナリパッケージからでも余裕でソースコード復元できるみたいだが一般人には普通のソースコード監査すら厳しいからね

どんだけ馬鹿なのコイツ

・ユーザーリポジトリからのダウンロード、インストールを公式ではサポートしたくない話
・ユーザーリポジトリには悪意のあるパッケージが含まれうる話
・バイナリ配布には危険が伴う話
全部全くレイヤが違う話なんだが
問題の切り分けがなってないって指摘されてんのに何もわかってねえな

AURは公式リポジトリではないし誰でも自由にUPできるから信用できないってのは共通認識があるわけだけどこの人は何を言ってるんだろう
齟齬があるのはmakepkg前にPKGBUILDファイルを眺める作業をする事の意義なわけだが
いきなり問題の切り分けとか言い出すし、もしかして日本語不自由かな

AURがどう作られてるかしらんけど
GitHubで開発してるなら
複数人で開発しててレビューが行き届いてんのもあるんじゃね？
それとも大体個人開発でレビュー無しなの？

>>445
PKGBUILDがー
って
いくらでも参照できるのに
コソコソ悪さできるとでも?

現に、公式のChromiumが、vaapiパッチ採用する
ちょっと前に、Chromium-vaapi-binで
ﾊﾞｲﾅﾘ配布してたのが、シナ製に切り替わった事あんだけど
みんな警戒して使わなかったよ

ソースコード読めない情弱で
こまけー事、ワケわからんユーザーにでも
コメントくらいは、よめますからね

GitHubでPKGBUILDを管理している人はいるけど全員ではないな
公式リポジトリはSVN使っているし

yayなどのAURヘルパーはAURのパッケージインストール前にPKGBUILDの中身表示するようになってるし
AURのパッケージ使う前にPKGBUILDを確認すべきでその作業には意味があるというのはコミュニティーの共通認識とされているのでは

AURはただのインストールスクリプト集だからそこが心配なら自分でビルドすればいい

>>447
ド低脳キッツ

makepkgはアーチのコマンド、自動化は自分たちでやってねって事
これ以上でも以下でもないから。

>>451
yayはデフォルトの選択肢が非表示なんだよなぁ