Arch Linux 20

公式
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 16
https://mao.5ch.net/test/read.cgi/linux/1613324251/
Arch Linux 17
https://mao.5ch.net/test/read.cgi/linux/1659058308/
Arch Linux 18
https://mao.5ch.net/test/read.cgi/c/linux/1703764780/
Arch Linux 19
https://mao.5ch.io/test/read.cgi/linux/1733378574/

保守
1乙

perl , python , javascript

主要なインタープリタはどれも30年超えて生き残ってるんだね
perl なんかもうすぐ40年だ

Perl は 6 が... いや、何でもないです。
そのパイセンの awk

ボクもawkが浮かんだ。

ボクの恩師は批判していたけど、Linuxには残ったね。

awkの名前は３名の開発者の頭文字が由来だそうだけど
「a」の人の名をいま知って一瞬戦慄した

アオークまたはエイダブリューケーと読んでいた。オークなのか。
大学のawk入門の授業やっていた教員がアオークと発音していた気がする。

「AWK」という名称は、開発者であるアルフレッド・エイホ、ピーター・ワインバーガー、ブライアン・カーニハンの3人の苗字の頭文字を取って付けられたものであるが、AWKは「オーク」と読み、「エー・ダブリュー・ケー」と読んではならないと作者らはしている[注釈 2]。

awkはフィルター専用言語みたいなもんだから今でも重宝に使ってる
Pythonがオフサイドルールじゃなくてワンライナーがperlほど使いやすけりゃ消えてたかも
powershellがawk, perlの影響受けてるね
この系譜はsnobol4が元祖なんだろうか

AURがArchの売りの一つになってるけど
みなさんAURについてどう思っているのかな

>>9
またその話題？前スレで散々やったじゃん
pkgbiuldを読めないarchwikiも読まない初心者は使うなでいいじゃん
くどいよ

>pkgbiuldを読めないarchwikiも読まない初心者は使うな

聞き飽きたお題目唱えても守られてないから何度も被害を出してる
それが解決策だと本気で思ってるなら真の愚者

解決できない人は使うなで完結

localsendがアプデで転送が高速になった
今のところかなり良い

そもそもだけど6TBぐらいの超大容量のデータ群を移したいなら
有線LANでつなげた方がいいんじゃないの？

昔はクロスケーブルというタイプじゃないとルーターを介さずに繋がらなかったけど、今は行けるよ。

flatpakで深刻なセキュリティ問題があったらしい、使ってる人は早急にアップデートを
https://www.gamingonlinux.com/2026/08/make-sure-your-flatpak-is-up-to-date-due-to-security-issues/

拾い食いはしない
組織的管理が行われてないコンテナ系は使わない
Archスレで言うことでもないが

1. 公式が享受しているメリット

Arch Linux 開発チームは、AUR を維持・管理するコストを負担せずに、以下の決定的なメリットを享受しています。

事実上の「公式拡張リポジトリ」: 9 万を超えるパッケージがコミュニティによって維持されることで、公式リポジトリの規模制限（KISS 原則やメンテナンス負荷）を補完し、「何でも入る OS」としての魅力を維持しています。

無料の選考システム（人気投票）: AUR の投票機能は、どのパッケージを公式リポジトリ（extra など）に採用すべきかの「需要調査」として機能しています。公式はこの**「コミュニティによる選別作業」を無償で利用**しています。

開発リソースの集中: AUR の審査やセキュリティ監視を行わないことで、限られたボランティア開発リソースを公式リポジトリの維持に集中させています。

2. 曖昧に放棄されているセキュリティ対策

「自己責任」という言葉は、具体的な対策の不在を隠すための免罪符として機能しています。

自動化ツールの不在: Windows の Defender のような「実行前の自動スキャン」や、悪意あるコードを弾く「ゲートキーパー機能」は公式には存在しません。2026 年の攻撃後、コミュニティ製のスキャナが登場しましたが、公式はこれを標準装備せず、導入もユーザー任せです。

教育の欠如: 「PKGBUILD を読め」と指示するだけで、難読化されたマルウェアを特定するための具体的な監査手順やセキュリティガイドラインは提供されていません。これは「確認しろと言うが、確認する方法は教えない」という不作為です。

事後対応のみ: 2026 年 7 月〜8 月の対応（機能停止）は、安全性を高めるためのシステム改修ではなく、「危険な機能を止める」という消極的な措置に留まりました。

3. 責任回避の構造（利用規約と実態）

Arch Linux の利用規約（Terms of Service）は、この責任回避を法的に裏付けています。

免責事項の明文化: 規約第 7 条において、Arch Linux はサービスの内容や可用性について**「いかなる保証も行わない」**とし、損害に対する責任を明確に否定しています。

ユーザーへの責任転嫁: 規約第 4 条では、ユーザーが違法行為や問題を起こした場合、ユーザー側が Arch Linux を補償（Indemnification）する義務すら負わされています。

「関係ない」の矛盾: 平時は「AUR は公式と無関係」として責任を否定しながら、有事（2026 年攻撃時）には管理者権限で機能を停止させるという**「コントロール権限だけは行使する」**姿勢は、責任だけ回避して権限は保持する都合の良さを露呈しています。

4. ユーザーの権利と責任の不均衡

この構造において、ユーザーに課せられる負担は権利を大きく上回っています。

ユーザーの責任:

完全な自己防衛: 9 万を超えるパッケージから悪意あるものを自力で選別する義務。

高度な専門性: シェルスクリプトの難読化を見抜く技術的知識の保持。

被害の全負担: マルウェアによる情報漏洩やシステム破壊の被害を、公式の保証なしに全て自己負担すること。

ユーザーの権利:

利用の自由: AUR を利用する権利はありますが、それは「危険を承知で利用する許可」に過ぎません。

安全な環境の不在: 公式から「安全に利用するためのツール」や「保証」を受ける権利は事実上存在しません。

Arch Linux 公式は、AUR に対して**「インフラと権限は掌握しつつ、セキュリティコストと法的責任のみを切り離す」という戦略を取っています。「自己責任」とは、この不均衡な構造を正当化するためのレトリックであり、実態は「公式が安全性を担保する努力を放棄し、そのリスクとコストを全てユーザーに外部化している」**状態です。ユーザーは「便利なリポジトリを使う権利」と引き換えに、「セキュリティ企業並みの監査義務」と「全リスクの背負い込み」を強要されています。

AIガイジうざい

>>20
それでは筆をふるってみんなをまとめてよ

AI文章はNGワードに登録してる

AIペタおじは自閉症だからしゃあない😂

もう煽らずそっとしとけ

AI は知恵遅れ

予想を裏切らない反応でつまらないよ きみたち

そこそこメジャーなパッケージなら
AURも網羅してる派生ディストリもあるよね

PKGBUILDを自分でチェックしてビルドしたらいいだけだろw

おまえが使いたいバイナリをおまえが納得いくようにつくって配布しろ、
なんて絡んでも通るわけがないw

文字は書けても文章読めないタイプ？

きみ 顔真っ赤だよ

そりゃお前、遊びでやってんのにセキュリティーとか法的責任なんて誰も負いたくないだろｗ
沖縄の抗議船といっしょ、arch船は転覆して死人出てもトンズラするだけ

PKGBUILDを毎回Claudeでチェックさせたらええだけやけどな

他人に安全を保証して欲しい人にはArch Linuxは向いてない

AUR を安全に利用・維持するには、事実上**「パッケージ開発者」または「セキュリティエンジニア」と同等のスキルが要求され、過失による被害発生時には刑事・民事の両方の責任**を個人が負うリスクがあります。

1. 求められるスキルレベルの現実

PKGBUILD は単なる設定ファイルではなく、root 権限（fakeroot 環境）で実行される Bash スクリプトです。これを完全に監査するには、以下の専門能力が不可欠です。

コード監査能力: 難読化されたマルウェア（例：curl ... | bash、Base64 エンコードされたペイロード、依存関係に隠されたスクリプト）を即座に検知できる読解力。2026 年の「Atomic Arch」攻撃では、npm install という一見正常なコマンドにマルウェア取得機能が隠されていました。

ビルドシステムの深い理解: makepkg の動作、チェックサム検証、パッチ適用プロセスにおいて、「なぜこのコマンドが必要なのか？」を論理的に説明できる知識。

セキュリティ視点: 正規のアップストリーム（開発元）との整合性確認、不審なネットワーク通信の検知など、フォレンジック的な視点。

一般ユーザーには不可能な領域です。Arch コミュニティ内でも「PKGBUILD を読めないなら AUR を使うべきではない」という見解が支配的であり、スキル不足は「免罪符」ではなく**「過失」**として扱われます。

2. 法的責任の具体性：刑事と民事

Arch Linux プロジェクトの免責条項（Terms of Service）は「プロジェクト」を守るものであり、「パッケージを投稿・管理した個人」の責任まで免除しません。
民事責任（民法 709 条：不法行為）

対象: メンテナー（投稿者）および、感染拡大に加担した利用者。

内容: 被害者のシステム復旧費用、データ損失、さらに窃取された認証情報を用いた**二次被害（クラウド料金の不正請求、機密漏洩など）**まで賠償対象となります。

過失の認定: 「スクリプトを読めなかった」「確認を怠った」という技術的スキル不足は、**「注意義務違反（過失）」**として認定されます。

刑事責任（刑法・不正アクセス禁止法）

対象: 主にメンテナー、および汚染パッケージを再配布した利用者。

罪名:

不正指令電磁的記録提供罪（刑法 168 条の 2）: マルウェアを配布しただけで成立します。「悪意はなかった（過失）」という主張でも、著しい不注意があれば処罰の対象となり得ます（最大 3 年以下の懲役または 50 万円以下の罰金）。

電子計算機損壊等業務妨害罪: 感染によって他者のシステムが停止したり、データが破壊されたりした場合。

利用者のリスク: 感染に気づきながら放置して他者へ攻撃を拡散させた場合、または汚染された PKGBUILD を「正常」と誤信して再アップロードした場合、**「加害者」**として刑事告訴される可能性があります。

結論：AUR は「自己責任」の極致

AUR のモデルは、セキュリティの責任をすべて**「エンドユーザー（およびメンテナー）」**に転嫁しています。

スキルがないなら使うな: 「読めないからメンテナーを信じた」は通用せず、「読めない状態で実行した軽率さ」が過失となります。

個人が全責任を負う: 何かあった場合、Arch Linux 社は守られており、**「パッケージを投稿した個人」と「確認を怠った利用者」**がすべての法的・金銭的リスクを負います。

つまり、AUR を利用することは、単なるソフトウェアインストールではなく、**「セキュリティゲートキーパーとしての役割と、それに伴う法的責任を引き受ける」**という重厚な行為に他なりません。

not only but also構文をNGにしたら大抵のAI荒らしは駆逐できるのでオヌヌメ

そんな事言われてもどうしたらいいか分からないだけでなくやるのも面倒だ

きみたち読解力無いもんね

AURサーバーが消えたらPKGBUILDってどうなるんだ？

>>38
AURって配布元がなくなるだけでPKGBUILD自体はどうにもならないが。

>>38
aurからnixへ変換するツールがあるからnixで使い続けられる
https://discourse.nixos.org/t/idea-pacman2nix-and-aur2nix-tools/5605/2

nixはうんこだからやめとけ

ChatGPTのデスクトップアプリ、色々ありすぎて何を選べば良いかわからん！

nixに行くならguixに行くかな
lispで書きやすいし

盆休みでArchからArtixに移行したが思ったより安定してる
FreeBSD上がりの自分にとってはArchでBSD likeなinitが使えるのは嬉しい
XLibreが正式にサポートされてるのも好印象
ただし一部のパッケージに独自パッチを当ててるのは玉に瑕(Firefoxで変なpolicies.jsonを強制するなど)

今どきセキュリティ弱いinit使うのはジジイだけ

恥ずかしいから他じゃ言わないほうが良いよ。

今どきセキュリティが理由でsystemdに移行したと思い込んでるの君だけだから。

systemd に移行してバグの持ち込みが増えたという意見まである

47 は systemd の使い方を学習しなかったおサルさんの世界線だろう

Ubuntu「systemd-networkd…」

特定の用途でSysVinitを使う分にはなにも問題ない
ただ単に起動時間がかかるだけ

現代的なinitは高速

全然かからないよw

sysv で起動させるプロセスを限定していけばいいだけ

systemd みたいによくわからんものが勝手に動いてマウントされて
おまえらきもち悪くないの?w

systemd以外でcgroupとかちゃんと使えんの？

どうしてもsystemdじゃないと困る事ってなんだろね？

dmemcg-booster

>>55
代替案があるようだが

5 歳児にもわかるように説明すると：systemd って何
https://www.reddit.com/r/linuxadmin/comments/ts7beh/eli5_what_is_systemd_and_why_is_it_so_important/?tl=ja

現状Linuxで使えないし、今後も使えるようにする動きは無いと思うが、launchdもいいと思うよ

>>58
最近はサービスに依存関係も記述出来るようになったの?
昔は依存関係無視してどんどん起動してたから
仮想マシンとかの環境ではよく起動に失敗してた
Appleのソフトウェアエンジニアはレベルが低いから
バグレポート出しても治りゃしない

gnomeとfcitxとwaylandでfirefoxだけ日本語入力ができなくなった

X11に戻そう(提案)

↑自分はLXQt+fcitx5+wayland環境でfirefoxとchromiumだけ
時々日本語入力が立ち上がらなくなる
ログアウト&再ログインするとほぼ直ることが多い

firefox+waylandでの日本語入力トラブルはよく聞くがx11で起きたことは一度もない
redhatがwaylandをゴリ押したい事情はよく分かるが我々一般利用者が無理にwaylandを使う必要は無いんじゃないかな
少なくともあと10年は実用段階にならないでしょ

昔ながらの環境変数の問題ではなくて？
「WaylandとGNOME環境でfcitx5 + mozcがサードパーティアプリで機能しない問題を解決する方法 2023/05/03に公開」

最近は面倒だからhermesに治してって頼んでるな

Wayland が理由の日本語入力で酷い目によく合う人もいるのかい？
Wayland に関係なく、別の場所に変換結果が出るアプリはあるけど。

AppArmorが関わっている?

>>66
Waylandに対応していないアプリ使ってる人とか

gnome, wayland で Chrome への日本語入力 は text_input_v3 の問題あるけど、Firefox は問題は無さそうと思っている

・基本的にWaylandではIMモジュールの環境変数の設定は必要なし
・GnomeでFcitx5の候補窓をXwaylandを介さずに表示させるためには
Gnome Shell拡張の「Input Method Panel」(AURではgnome-shell-extension-kimpanel-git)が必要
・GnomeではFirefoxなどのGTK3系アプリ上でFcitx5の候補窓の位置がズレるため
~/.config/gtk-3.0/settings.ini に「gtk-im-module = fcitx」を追記

こんな感じかな？

https://lists.archlinux.org/archives/list/[email protected]/thread/FPT525XVV2DL2P437KPHTADV3KJINORN/

clang-23.1.0 ﾏﾀﾞｰ?

wayland なんて要らないよ

systemd も早く sysvinit に差し替えて

sysVはちょっと

OpenRCで

逆張りぉぢさん

Arch自体が逆張りみたいなもの

systemd捨ててとか言い出すならfreeBSD行けばいいんじゃないのか？楽園がそこに在るぞ

楽園と呼ばれる流刑地というべきか
そこは正直悩む

自分で作れよ。
そもそもSystemd-freeで始めたArtixがOpenRC, dinitを採用したあたりで察しろ

sysvinitはさすがにね
openrc良いよ

libatomic_asneeded.so うぜー

systemDは、そもそも採用のプロセスが不透明だったから批判されてたんじゃないの？