[過去ﾛｸﾞ] Arch Linux 17 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
853: 2023/11/29(水)17:25 ID:mpJZ3k90(1) AAS
Archスレは初心者が紛れていると見せかけて蓋を開けたら大抵初心者じゃないから好き
854: 2023/11/29(水)18:32 ID:RoPZG394(1) AAS
>>848
そうかな？
linuxでも ffmpeg のハードウェアアクセラレーション出来るし言うほど駄目ではないと思うけど
動画再生ソフトは大体内部でffmpegのライブラリ叩いてるしイケるでしょ
855: 2023/11/29(水)18:35 ID:ZK/p0W9o(3/3) AAS
>>851
そうかな？
以下はものすごく偏見にまみれた俺個人の意見
gentoo → ひきこもり
arch → 猥褻物陳列罪
その他 → どうでもよー
異論は認めるけどレスは返さない
856(1): 2023/11/29(水)20:34 ID:vGxGe3iZ(2/6) AAS
>>846
固い文章の割に知識ではなく想像で物言ってるように見える
現実はスペクトラム的に書けば以下のような感じですよ
パッチ多 <-> パッチ小
バージョン古 <-> バージョン新
バグ少 <-> バグ多
Debian - Ubuntu - Manjaro - Arch
RHEL Fedora
バグを取るのがおかしいとか言ってるけど、管理されたディストリ程パッケージのソースは
上流のソース＋大量のパッチ、となってます。パッケージのソースを取得して見た事のある人なら誰でも知ってる事
857: 2023/11/29(水)20:35 ID:vGxGe3iZ(3/6) AAS
RHELとFedora の位置がおかしくなってしまった。
RHELはDebianとUbuntuの間、Fedora は Manjaro と同じあたり。
858: 2023/11/29(水)20:40 ID:hg4ximew(4/8) AAS
>>850
俺の場合はCM再生中にニュース等を読んでるのでCPU使用率が高いとカクついてウザイ。
(元より参戦してないが)アドブロックのいたちごっこからはもう降りた。
デスクトップでオフィス作業の一般的な使い方なら、GPUが問題になる事は多分ない。
モバイルの場合はバッテリーを無駄に消費する問題はある。
>>849
まあ俺みたいに単に使いたいだけなら5〜10年毎にPC買い換えるのが結局一番楽そうではある。
来年出るらしいWindows12に乗り換えるのが一番妥当な気はしてる。
859: 2023/11/29(水)21:03 ID:hg4ximew(5/8) AAS
>>856
まあ実際知らんしね。
ただそれだとやはりdebianは戦略を間違ってるよ。
そして肥大化しすぎたダウンストリームパッチへのアンチテーゼとしてのarchか。
> Arch Linux はシンプリシティを、「不必要な追加や修正を行わない」ことと定義しています。
> Arch Linux はオリジナルの開発者(アップストリーム)のリリースしたままのソフトウェアを、
> 最小限のディストリビューション固有(ダウンストリーム)の変更を加えて提供しています。(from Arch wiki)
とはいえそもそも個別のunixコマンド群やデーモンにディストリビューション固有の変更が必要とは思えないから、
大方C自体のパッチファイルではなく、デフォでssh起動するかとかの設定ファイル等じゃないかと思ってるが違うか？
そうではなく、本当にCを弄ってるのなら、それは枯れたとは言わんし、戦略として矛盾してるという話。
860: 2023/11/29(水)21:26 ID:mpUvEI+O(1) AAS
せんとくんショックから、ウブンツサーバーの評価上がったよね。実際使いやすいし。
861(2): 2023/11/29(水)21:34 ID:vGxGe3iZ(4/6) AAS
> ディストリビューション固有の変更が必要とは思えない
整合性取るためにはメチャクチャ必要ですよ。あとセキュリティパッチも。
例えば RHEL7 の apache httpd には 157個のパッチファイル(勿論Cメイン) が含まれています。
862: 2023/11/29(水)22:06 ID:AJ604FjC(1) AAS
Emacs Lisp のパッケージを /usr/share/emacs/site-lisp 下にインストールするとき
・Aはデフォルトで、サブディレクトリを作ってそこにAの設定ファイルをまとめてインストールしてくれる。
・アプリBはデフォルトでは /usr/share/emacs/site-lisp 直下に大量のファイルをバラ撒いてしまう。
ただし configure でちょいとオプションを付けてビルドすれば、BもAと同じようにインストールしてくれる。
という状況で「BもAのようにしてくれ」とArchに要望を出したら「シンプリシティに反する」と却下された。
configure にちょいとオプションを付けることさえ拒否されるんだなあ。
863: 2023/11/29(水)22:12 ID:hg4ximew(6/8) AAS
>>861
だからバックポート自体が間違いなんだよ。
生産性のある作業ではないので、出来るだけ無くそうというarchの戦略は妥当だし、
そもそもセキュリティ周りの最新パッチが欲しければ最新版使え、が一番シンプルな解だ。
とはいえRHELの場合はそうも行かないからバックポートするのだろうけど、
それより古いバージョンをdebianが保持する理由はさっぱり分からんね。
まさかRHELですらバージョンアップが早すぎて、一度動いたら永久にそのまま動かしたい勢がdebianなのか？
864(1): 2023/11/29(水)22:18 ID:vGxGe3iZ(5/6) AAS
別に代弁するつもりも無いので、Debian stable too old とかでググって好きなだけ議論を漁って下さい
archの人達も最新を維持するのが正解、と思ってるわけで貴方に合うならそれでいいんじゃない？
arch ではサイクルが早すぎると思ってる人達が定期サイクルで安定化を図っているのがManjaro
debian では遅すぎるので testing をベースに半年サイクルで更新頻度を上げたのがUbuntu
鏡像のような関係ですね
リリースサイクルの管理には色々な思想宗派があるってだけの事です
865: 2023/11/29(水)22:21 ID:hg4ximew(7/8) AAS
>>861
つうて確認してみようと思ったが、RHELってソースコードの公開停止してんだな。
まあ確かにバックポートの手間を考えれば金払えではある。
866(1): 2023/11/29(水)22:38 ID:vGxGe3iZ(6/6) AAS
RHEL7までは最後にCentがミラーしてた SRPM を拾えば確認出来るよ
867: 2023/11/29(水)23:19 ID:hg4ximew(8/8) AAS
>>864
まあ確かにdebianについてはここでこれ以上は必要ないね。
ちなwikiがあるので確認してみたが、のっけから
哲学が最も重要だ、FreeBSDのカースト制が糞だったからdebian作った、とか、政治的すぎてビビる。
割とFreeBSDの連中も政治的な気はするが、なんだかねー。
> 外部ﾘﾝｸ:wiki.debian.org
>>866
GitHubでさらっと見えるのなら、程度で居たのでまあいいや、という感じ。
とはいえ、ありがとう。気が向いたら確認するかも。
868(1): 2023/11/30(木)03:41 ID:62/AR/We(1/2) AAS
バックポートが間違いも何も依存関係で上げられないケースがあるんだから多かれ少なかれバックポートは必要だぞ
非OSSのソフトが古い依存関係を要求してたらこちらはバージョンを上げない以外に手の打ちようがない
869: 2023/11/30(木)09:41 ID:Fiz23/sm(1/2) AAS
>>868
その意味でプロプライエタリのプラットフォームなRHELはバックポートもしないと駄目だろうさ。
しかしapacheではないだろ。PHP5やPython2とかなら分かるけども。
調べてみたところRHEL7(2014.06-2032)はapache2.4(2012.02-現行)なのでバックポートは必要ない。
それでダウンストリームパッチが大量に必要なら、何か戦略に問題があるんだよ。
(申し訳ないが)今のところ861の言う「157個のパッチファイル(勿論Cメイン)」の大半が実はアップストリームパッチなんじゃないかと勘ぐってる。
870: 2023/11/30(木)12:00 ID:62/AR/We(2/2) AAS
apache2は知らないが、パッケージ管理ソフト外のアプリから依存されるようなパッケージはバックポート必須
Debianなら5年、RHELなら10年は動くってこと
そういったアプリを使うななら自動更新のArchは用途外
871(1): 2023/11/30(木)13:05 ID:y3Pnrhnn(1) AAS
アップストリームパッチ、というかセキュリティパッチだよ
表向き固定したバージョンを保ちつつ後のセキュリティフィックスを入れるだめのパッチ
872: 2023/11/30(木)14:17 ID:Fiz23/sm(2/2) AAS
>>871
多分その可能性が一番高いとは思う。
つまり、RHELがパッチのつまみ食い(セキュリティパッチのみ適用)をしようとして、
完全上位互換を保ってリリースしてるapache側は「その必要はない」として無視、
結果的にRHELのapacheがfork(branch)してしまってる形かと。
どっちが悪いって事ではなく、ポリシーの違いではあるが、
現実的に各アプリのメンテを各ディストリが完璧にこなせるはずもなく、どこかでボロが出るから、
「完全上位互換だ」というapache側を信じて走るarchの方が戦略としては妥当。
841の通り、問題があればapache側から緊急リリースが出てくるはずだし。
全アプリの全パッチを精査して必要な物だけ適用、というのは相当に工数がかかる。
省1
上下前次1-新書関写板覧索設栞歴
あと 130 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.013s