Arch Linux 17

公式
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/
Arch Linux 16
https://mao.5ch.net/test/read.cgi/linux/1613324251/

>>796
Web サーバーじゃん

debian
>>761
あなたはNixOSを使ったほうがいいのでは…？

> debian
なんか余計なものがレス作成欄にそのまま残ってたわ…すまん

ジェンツーとかな

最近のLinuxはすごい勢いで進歩しているから
Archみたいな最新系のディストリ以外は使う気にならなくなってる
こんな素晴らしいディストリが存在してくれて感謝

archinstall をコンソールで使うと文字が見づらいけど、
EndeavourOS をUSBメモリから起動して、
Konsole で archinstall を実行すると快適になった

Plasmaデスクトップだからフォントを簡単に変更できるし、
archinstall の日本語翻訳も表示できる
わからないことがあれば Firefox で調べられる

それはもうEndeavourOSをインストールしていいんじゃないかな

それはもう別の話だね

最近はgoogle検索自体の精度が落ちてきているせいでLinuxが使いにくくなっている
Arch Wikiも更新されなくなってきているから最新の情報だとどうにも役に立つ率か落ちてるしさ

グーグル検索の精度が落ちたのは昨日今日の話ではないがな

Arch Wikiのラングがガタ落ちした感じがするんだよね
Ask Ubuntuがトップに出るからかなり検索しにくい
比較的正確な回答が多かったredditのランクも落ちた
悪い意味でWindows的な状態に陥りつつある

> Arch Wikiも更新されなくなってきている

今まで更新してくれていた人に感謝しつつ、
自分が担う番が来たということでは

google検索よりAIに質問したほうが早い説あるけど、AIもポンコツだからなぁ

ソース読んだりデバッガ使ってサクッと自分で直せない奴らって何のためにLinux使ってんの？

>>810
Linuxの設定周りは直す箇所を特定するのが難しいんだよ
例えばGDM3のログイン画面から直接ハイバネートする項目を出現させる方法とか分かる？

>>811
んな普段使ってすらねぇようなもんのピンポイントな具体例聞かれたところでエスパーじゃねぇんだから知るわけねぇだろ
そういうのはUIに使われてる文言とかでソース検索してどのへんで処理してんのかとか当たりつけて読んでくんだよ

それを俺にやれってんなら相応の対価を払え
あるいはお前は既に一生懸命ググって答えを知った上でその汎用性のかけらも無い知識をドヤ顔で披露するためにその無意味な質問してんなら大好きなArchWikiにでも書いとけ

ほらね？　分からないでしょ

レスはっや、一日中張り付いてんのかよw

しゃーないからネット上のソースとドキュメントだけちらっと見てやったけどextensionでいくらでも拡張できるようにpanelのアイテム一個一個から全部公開されてるからAPIのドキュメントみて自分で多分精々100行もいかんようなjsのコード書きゃいいだけじゃねーか
なんかGnome周りの前提知識なし&流れ的にググるの禁止縛りでやったけどこの程度ならググれば拡張機能とか普通に公開されてんじゃねーのか
ほんとレベル低すぎて呆れるわ

残念ながら拡張機能はGDMのログイン画面には影響を与えられません
早速直す箇所の特定を間違えてるじゃん

だからエスパーじゃねぇんだから普段使ってねぇ&検証用の環境も用意してねぇもんの正確な中身なんざ知るわけねぇだろっつうのwww
環境用意してしっかり調べてほしいんなら

対
価
を
払
え

知識自慢しようと勝手に調べてそれが的外れだと指摘されたら対価払えば教えるよなどと

>>811
本当に困っているのならともかく、
自分の中で答えを持ってそうな人に答えても、反論されて面倒くさいだけ

> Linuxの設定周りは直す箇所を特定するのが難しいんだよ
> 例えばGDM3のログイン画面から直接ハイバネートする項目を出現させる方法とか分かる？
例えば mousepad のフォントを変更する方法とか簡単
OSの問題ではなく、ユーザーが何をやるか次第だと思う
ユーザーの多くがやるような設定は基本的に簡単だし、調べればすぐ出る

GDM に関して言うと、github.com/GNOME/gdm に行って、
「/hibernat」と入力して Enter
GDM 本体には hibernate に関するメニューがなさそう

Arch Wiki に書いてある方法は、GDM のオプション設定の範囲を超えてると思う
wiki.archlinux.org/title/GDM#Configure_power_button_behavior
たぶん SDDM なら普通にできると思うので、可能ならそれを使えばいい

調べてみて脱力したし、わかっててこういう質問をする人はしんどい

普通なら手を動かして調べる行動力を称賛されるのに…
>>810で徳の低い煽りをしなけりゃよかったのにねぇ！

「ソース読んだりデバッガ使ってサクッと自分で直せる」らしい人なら
Arch Wikiにも存在しない方法で直せるかと思ったけど無理だったか。

>>818
調べてもらったところ申し訳ないけど
それは電源の物理ボタンの設定であって項目を出現させる方法ではないんだよね。
一見簡単そうに見えて超難易度の高い設定というのがLinuxには多々あるからハマると大変という一例。

ハイバネートってなんですか

調べてもキーボードショートカット設定すれば？な代替策しか出てこない……

>>821
さぁ？
でもarch及びその系統のユーザーには何か気色悪いのが多そう
って言うのはわかるマン

ハイバネートなんてやらないほうがいい

アゲアゲでパネェ感じなんですね…

>>820
コードを書いて pull request すればいいよ
他のユーザーも助かるだろう

> 一見簡単そうに見えて超難易度の高い設定というのがLinuxには多々ある
この人には何を言っても無駄そう

GDM に関して言うと、github.com/GNOME/gdm に行って、
「/hibernat」と入力して Enter
GDM 本体には hibernate に関するメニューがなさそう
ないものをやるのは設定の範囲を超えてる

>>824
でも世の中にはログイン画面で保存したい人も居るらしいよ

>>826
>ないものをやるのは設定の範囲を超えてる
Linux初級者はメニュー・コマンド・設定ファイル等で設定できないものはお手上げになるが、
それが、Linux中級以上になるとソースコード等をいじって設定できるようにするんだろうがな
俺もだが、Linux初心者にはソースコード公開してあっても意味なし感じだからな

https://imgur.com/VrvH0CO
しょうがないからテスト用の環境用意して調べてやったけど環境構築の時間含めても2時間もかからず実現できて草

CですらないjsだしGnome周りの知識0からの俺ですらすぐ実現できんのにこんなんが高難易度とかマジで何のためにLinux使ってんの？

まじでサクっと直せる人じゃん！！
なんか感動したから俺も今度からソース読んだりデバッガ使って頑張ることにする

>>829
偉い

>>828
初級なら中級ならという話じゃない
「コードを追加して設定できるようにすればいい」とかもう設定じゃないのよ
Linux に限った話じゃない

>>811 >>830
方言なのかもしれないけど、オプションの追加はそもそも「直す」ではない気が
機能追加を「直す」て言うんか

>>829
スゲーな
Linuxは乞食するのに適しているということで使っている奴が多い
こんな奴(当然俺もだが)は乞食すること以外は碌にできない
当然、Cやらjs等の言語学習はしないから簡単なソースコードすらわからん(高難易度)
(乞食は笑っちゃうレベルのシェルスクリプトできれば俺様超スゲーだろになる)
そして、ソースコードを見てもわからんということで見ることすらしないのが乞食

>>831
>「コードを追加して設定できるようにすればいい」
乞食(永遠の初心者)は、今回はjsでだが、コード追加が(ハイレベルすぎ)できない

まあ言語なんて結局は文法とかはコンパイラなりのツールとかが間違ってるよって教えてくれるし
あとは物事を論理的に考えられるかと実際に挑戦するかどうか程度の問題よ

別に｢俺には出来ない｣って人もそれはそれで全然いいと思うけどそういう手も動かさない頭動かさない対価も払わないくせに自分が乞食だっていう自覚すら無いゴミ共が
>>767みたいに薄っぺらい知識で｢archが抱える原理的問題だよ｣とか手を動かしてくれてる中の人達の成果物ディスるとイラッとするからちょっと>>810で煽ってみたんだわ

Arch上級者は実演で黙らせるからカッコいい

Arch Wiki に書かれてない有用なことがあるなら Wiki に書けばいい
オプションを追加するコードを書いたなら pull request すればいい
コードを書けないけどどうしても必要なら、Issues で機能提案すればいい

GDM って歴史の長いソフトだから、いまさらオプションが追加されることはなさそう
Wiki に解決法を書き込むのが現実的かな

自分だけが正しいクイズ大会とかやっても人が離れるだけ

>>836
文句しか言わない連中なんて離れた方が治安良くなるよ
上から目線で他人の貢献を要求する君もそのひとり

>>834
俺は810以降は書き込んでないけどな。
俺ツエー合戦で盛り上がれる程若くないので、生暖かい目で見てた。

何が気に障ったのか知らんが、俺はCもJSも読めるから、
お前が今読めなくて困っているOSSのコードがあれば見てみてもいいけど。
(ただし、俺が何かしら回答出来る確率はかなり低い)

しかし俺も今回のは、831と同様、
> ソース読んだりデバッガ使ってサクッと自分で直 (810)
とは言わないと思うがな。

あと、ノリが学生レベル過ぎる。
ほぼ全員の学生が就職して驚くのはテストの量で、企業では煽り抜きで100万倍テストしてる。
というより、学生は「俺が今使ってる環境で動いたからOK」で、甘すぎなんだが。
今回のハイバネート、設定を追加しただけのようだが、なら、何故それが既に公式に来てないのかを考えた方がいい。
おそらく、何かしら問題があるんだよ。(お前に命中するかはまた別だが)
この点については、
> ハイバネートなんてやらないほうがいい (824)
は当たってる。Linuxは元々節電なんて考えた作りではないので。
それでも試してくれる人柱が居ないと進まないからどうぞ使ってみてくれではあるけど。

それから、俺はarchを使ってなくて、今はZorin、次はMintを使う予定だ。
ローリングアップデートはなかなか面白いアイデアだと思う。
アップデートパッケージは完璧で何ら問題がないという前提なら一つの最適解だろう。
実際はそう上手く行かないにしても、最適解の枠を作っている意味はある。

俺は今お前がやってる、Linux自体を「弄る」事には興味ない。
俺はunixコマンドを「使いたい」のであって、使えれば何だっていい。
こういう連中の現時点での最適解とされてるのはWSLだ。俺はそれ以前のCygwinやUnxutilsで満足してるが。
実際のLinuxユーザーの大半のこの「使う」用途の人には、
Linux本体システムのアップデートなんてクソどうでもいい事でしかない。
昨日と同様に今日も動く事が最重要であって、頻繁なアップデートなんて壊れる機会が増えてるだけだ。
それを理解出来ないのは、お前はあくまで「弄ってる」だけで、「使って」ないからだよ。
(スマホのOSのアップデートが毎日来ても糞ウゼエし困るだけだろ、と言えばZにも通じるか？)

知識ひけらかしたくて話しふって自己レスっていう
ほのかに自演臭漂うやりとりがarchユーザーっぽさ出てて良かった

> アップデートパッケージは完璧で何ら問題がないという前提なら一つの最適解だろう。
これは完全に逆
どうせ完全には出来無いから取りあえず全部最新にしておいてバグ踏んだら次のアプデを祈れ、
フィードバック出来るなら上流にしろ、というのがArch

バージョン固定して必死にバグ取りしてたらリリース遅延しまくりだったDebianが反面教師や

Archから乗り換えるのは分かるけどZorinやMintを選ぶ理由が分からない
FedoraかDebian、100歩譲ってUbuntuまでじゃないか？
特にUbuntuの派生なんてDebianから数えたら派生の派生なんだからどこに不具合が潜んでいるか不明だし
それこそ〝今使ってる環境で動いたからOK〟の典型例が、Ubuntu派生ディストリだから主張と矛盾しているように感じるね

>>842
ぼくはカッコいいからArch使ってるよ。
普段ネットサーフィンかエロ動画視聴にしか使ってないから、別にディストリなんでも良いし、Windowsでも良いんだけど

arch wikiの原則に書いてあるけど

> Arch はできるだけ多くの人にアピールするよりも、貢献している人のニーズを満たすことを目指しています。熟練の GNU/Linux ユーザーや、積極的にドキュメントを読んだり自分の問題を解決する“do-it-yourself”の姿勢を持った人をターゲットにしています。

お客様はそもそもターゲットではない

>>843
arch使う事がかっこ良いという考えは改めた方が良いと思うよ
ttps://qph.cf2.quoracdn.net/main-qimg-0f9a31ff44d1b2a2b89adb78c31a5a87-pjlq
ttps://www.facebook.com/TecMint/photos/a.274403725911428/1322651147753342/?type=3

>>841
そういう解釈もありだ。
まあ意味付けはともかく、現実的なアップデート戦略は、両端がarchとRHELなのだと思う。

> バージョン固定して必死にバグ取りしてたらリリース遅延しまくりだったDebianが反面教師や
これは知らんが、枯れたバージョンを使う連中がバグ取り(＝新規コード挿入)をしてる事自体が戦略ミスだね。
arch等の先端で問題なかった物の集合体を枯れたパッケージにすべきで、駄目ならさっさとスキップすべきだ。
まあ何かしら旧バージョンにこだわる(＝新バージョンでは駄目な)理由があったんだろうけど。


>>842
動作報告があったからだね。
俺は「自分で使う用」だから自分が使えれば何でもいいんだよ。

ちな、俺はarchから乗り換えたのではなく、windowsからLinuxへの乗り換えを検討していて、
archだと再インストール作業を一生せずに済むのか？と考え、候補として見てる。
が、まあ、ここ見てる限り、現実的には厳しいかな、という感じね。
本当にメインマシンをLinuxにして良いのかをZorinで味見中。
(主に日本語環境とかその辺。
今のところ見えてる不満はGPUの動画再生支援がまるでない事だが、
これはディストリではなくLinuxの問題なのでどうにもならない)

アムド製のGPUならそうなるかもな

なおnVidia製だ。(勿論プロプライエタリドライバは入れてる)
ただ、正直LinuxのGPU活用はWindowsと比べて20年遅れてる。
クライアントマシンとして使うならWindowsの方が断然優れてると思う。
(Linuxのシェアが上がらないのも分かる。Windowsなら何の問題も無く出来てる事が、出来ない)

>>846
PCを乗り換える5年から10年くらいならOS問わず再インストールが必要になるとは思わない
ただ、もし必要になった時archならpacstrapで必要なものを再インストールするだけとやりやすくはある

事務員がGPUが遅くて困るとかあるか？
オフィースワークなら、LinuxとLibreOfficeで解決するのが現状

>>845
ギークって感じでかっけぇじゃん

>>837
> 上から目線で他人の貢献を要求する君もそのひとり
目線低過ぎでは

> > 自分だけが正しいクイズ大会とかやっても人が離れるだけ
> 文句しか言わない連中なんて離れた方が治安良くなるよ
調べてみたら設定項目自体がないし、答えても文句しか言わないし、
そもそもオープンソースの世界で「俺が正解のクイズ大会（答えは内緒）」とかされてもさ
「ここで詰まった、こうしたら解決した、Linux難しい」でいいのに

とあるソフトのリリースノートに貢献者として載った
Arch LinuxのISOファイルにも入る（来月分には間に合わないかも）
自分のためにやったことだけど、何人かの役にも立てば

Archスレは初心者が紛れていると見せかけて蓋を開けたら大抵初心者じゃないから好き

>>848
そうかな？
linuxでも ffmpeg のハードウェアアクセラレーション出来るし言うほど駄目ではないと思うけど
動画再生ソフトは大体内部でffmpegのライブラリ叩いてるしイケるでしょ

>>851
そうかな？
以下はものすごく偏見にまみれた俺個人の意見
gentoo → ひきこもり
arch → 猥褻物陳列罪
その他 → どうでもよー
異論は認めるけどレスは返さない

>>846
固い文章の割に知識ではなく想像で物言ってるように見える

現実はスペクトラム的に書けば以下のような感じですよ

パッチ多 <-> パッチ小
バージョン古 <-> バージョン新
バグ少 <-> バグ多

Debian - Ubuntu - Manjaro - Arch
RHEL Fedora

バグを取るのがおかしいとか言ってるけど、管理されたディストリ程パッケージのソースは
上流のソース＋大量のパッチ、となってます。パッケージのソースを取得して見た事のある人なら誰でも知ってる事

RHELとFedora の位置がおかしくなってしまった。
RHELはDebianとUbuntuの間、Fedora は Manjaro と同じあたり。

>>850
俺の場合はCM再生中にニュース等を読んでるのでCPU使用率が高いとカクついてウザイ。
(元より参戦してないが)アドブロックのいたちごっこからはもう降りた。

デスクトップでオフィス作業の一般的な使い方なら、GPUが問題になる事は多分ない。
モバイルの場合はバッテリーを無駄に消費する問題はある。


>>849
まあ俺みたいに単に使いたいだけなら5〜10年毎にPC買い換えるのが結局一番楽そうではある。
来年出るらしいWindows12に乗り換えるのが一番妥当な気はしてる。

>>856
まあ実際知らんしね。
ただそれだとやはりdebianは戦略を間違ってるよ。
そして肥大化しすぎたダウンストリームパッチへのアンチテーゼとしてのarchか。
> Arch Linux はシンプリシティを、「不必要な追加や修正を行わない」ことと定義しています。
> Arch Linux はオリジナルの開発者(アップストリーム)のリリースしたままのソフトウェアを、
> 最小限のディストリビューション固有(ダウンストリーム)の変更を加えて提供しています。(from Arch wiki)

とはいえそもそも個別のunixコマンド群やデーモンにディストリビューション固有の変更が必要とは思えないから、
大方C自体のパッチファイルではなく、デフォでssh起動するかとかの設定ファイル等じゃないかと思ってるが違うか？
そうではなく、本当にCを弄ってるのなら、それは枯れたとは言わんし、戦略として矛盾してるという話。

せんとくんショックから、ウブンツサーバーの評価上がったよね。実際使いやすいし。

> ディストリビューション固有の変更が必要とは思えない
整合性取るためにはメチャクチャ必要ですよ。あとセキュリティパッチも。
例えば RHEL7 の apache httpd には 157個のパッチファイル(勿論Cメイン) が含まれています。

Emacs Lisp のパッケージを /usr/share/emacs/site-lisp 下にインストールするとき
・Aはデフォルトで、サブディレクトリを作ってそこにAの設定ファイルをまとめてインストールしてくれる。
・アプリBはデフォルトでは /usr/share/emacs/site-lisp 直下に大量のファイルをバラ撒いてしまう。
ただし configure でちょいとオプションを付けてビルドすれば、BもAと同じようにインストールしてくれる。

という状況で「BもAのようにしてくれ」とArchに要望を出したら「シンプリシティに反する」と却下された。
configure にちょいとオプションを付けることさえ拒否されるんだなあ。

>>861
だからバックポート自体が間違いなんだよ。
生産性のある作業ではないので、出来るだけ無くそうというarchの戦略は妥当だし、
そもそもセキュリティ周りの最新パッチが欲しければ最新版使え、が一番シンプルな解だ。
とはいえRHELの場合はそうも行かないからバックポートするのだろうけど、
それより古いバージョンをdebianが保持する理由はさっぱり分からんね。
まさかRHELですらバージョンアップが早すぎて、一度動いたら永久にそのまま動かしたい勢がdebianなのか？

別に代弁するつもりも無いので、Debian stable too old とかでググって好きなだけ議論を漁って下さい
archの人達も最新を維持するのが正解、と思ってるわけで貴方に合うならそれでいいんじゃない？

arch ではサイクルが早すぎると思ってる人達が定期サイクルで安定化を図っているのがManjaro
debian では遅すぎるので testing をベースに半年サイクルで更新頻度を上げたのがUbuntu
鏡像のような関係ですね

リリースサイクルの管理には色々な思想宗派があるってだけの事です

>>861
つうて確認してみようと思ったが、RHELってソースコードの公開停止してんだな。
まあ確かにバックポートの手間を考えれば金払えではある。

RHEL7までは最後にCentがミラーしてた SRPM を拾えば確認出来るよ

>>864
まあ確かにdebianについてはここでこれ以上は必要ないね。

ちなwikiがあるので確認してみたが、のっけから
哲学が最も重要だ、FreeBSDのカースト制が糞だったからdebian作った、とか、政治的すぎてビビる。
割とFreeBSDの連中も政治的な気はするが、なんだかねー。
> https://wiki.debian.org/WhyDebian


>>866
GitHubでさらっと見えるのなら、程度で居たのでまあいいや、という感じ。
とはいえ、ありがとう。気が向いたら確認するかも。

バックポートが間違いも何も依存関係で上げられないケースがあるんだから多かれ少なかれバックポートは必要だぞ
非OSSのソフトが古い依存関係を要求してたらこちらはバージョンを上げない以外に手の打ちようがない

>>868
その意味でプロプライエタリのプラットフォームなRHELはバックポートもしないと駄目だろうさ。
しかしapacheではないだろ。PHP5やPython2とかなら分かるけども。

調べてみたところRHEL7(2014.06-2032)はapache2.4(2012.02-現行)なのでバックポートは必要ない。
それでダウンストリームパッチが大量に必要なら、何か戦略に問題があるんだよ。
(申し訳ないが)今のところ861の言う「157個のパッチファイル(勿論Cメイン)」の大半が実はアップストリームパッチなんじゃないかと勘ぐってる。

apache2は知らないが、パッケージ管理ソフト外のアプリから依存されるようなパッケージはバックポート必須
Debianなら5年、RHELなら10年は動くってこと
そういったアプリを使うななら自動更新のArchは用途外

アップストリームパッチ、というかセキュリティパッチだよ
表向き固定したバージョンを保ちつつ後のセキュリティフィックスを入れるだめのパッチ

>>871
多分その可能性が一番高いとは思う。
つまり、RHELがパッチのつまみ食い(セキュリティパッチのみ適用)をしようとして、
完全上位互換を保ってリリースしてるapache側は「その必要はない」として無視、
結果的にRHELのapacheがfork(branch)してしまってる形かと。
どっちが悪いって事ではなく、ポリシーの違いではあるが、
現実的に各アプリのメンテを各ディストリが完璧にこなせるはずもなく、どこかでボロが出るから、
「完全上位互換だ」というapache側を信じて走るarchの方が戦略としては妥当。
841の通り、問題があればapache側から緊急リリースが出てくるはずだし。
全アプリの全パッチを精査して必要な物だけ適用、というのは相当に工数がかかる。
それをタダでパクってんじゃねえよ！というRHELの言い分はごもっとも。

>>847
Linusのマシンもそうなるんだな

>それをタダでパクってんじゃねえよ！というRHELの言い分はごもっとも
gcc、emacs 、glibc、apacheやpostfixだって、相当の工数がかかってる
誰も「タダでパクってんじゃねえ」なんて品の無いことは言わない
それをいうのは赤帽だけ
人のものはタダでパクるが自分のものはパクらせないのが赤帽

RHELはライセンス上タダパクされても文句言えないのでそれが嫌ならLinuxなど使わず0から完全オリジナルOSを作って自由にライセンス設定すればよかっただけの話

またどうでもいいことでマウントの取り合いしてるの?

>>874
RedHatが気に入らないからRHELは使わない←分かる
RHELの意義は認めるがRedHatが気に入らない、またはサポート不要なのでCent使う←分かる
RHELを全パクる＝Miracle←頭おかしい

使う以上使う価値があると自ら認めているのだから、それが持続しないように仕向けるのはパヨク過ぎる。
それでは最終的な着地点を自ら破壊してるだろ。
日本に文句があるのなら、日本から出ていくか、日本を改善する努力をするべきで、
日本を破壊する工作をしてるようでは話にならんだろ。だから彼等は馬鹿にされるのであってね。
まあMiracleとかはRedHatに金払ってパッチを買うか、自前で工数かけるかを選択すればいいだけの話だし、
そもそもarchユーザーには関係ない話ではある。
RHELに無駄に工数かかるのは無理に長期サポートするからであって、
そうならないように出来るだけアップストリームに寄り添うarchの方針はまあ妥当だよ。

理想的にはapacheその他全部がLTS版を提供すれば済む事で、
全ソフトウェアがLTS版を提供すればRHELは自然と消滅していく。
RedHatを殺したければこの方向に努力すべきで、パクっても構わないと考えるのはクレイジーだよ。
膨大な手間はかかってるし、実際それをMiracleその他がやるのは無理だろうし。


>>875
それはRedHatへの文句であって、RHELではないね。
RHELはLinuxのおま環問題を解決する為に出てきたので、Linuxでないといけなかったんだよ。

そもそもアップストリームのパッチですらRedHatがプルリク出してるんだから
間接的にArch Linuxも恩恵を受けていると言える

GNU GPLを全否定してるガイジおるやん

ライセンス的にはタダパクし放題のはずだけど俺達のソフトだけは課金組限定公開にするね！
だって俺達めちゃくちゃ頑張ったんだから特別扱いされて当然だよね！

別にCentOS Streamを通して公開してるぞ
完全丸パクリディストリを作れなくなっただけ

アップストリームとダウンストリームじゃ全然別物なんですが

>>879-880
> 正確にGPLを理解できている訳ではないですが、バイナリを利用するユーザがソースコードを入手できれば問題無いので、GPL的には、今回のRed Hatの一般公開停止と限定公開自体は問題無いようです(※)。
> happy-nap.はてなblog.com/entry/2023/06/28/232517
実際の所は俺も知らんが。

>>882
ならお前が用意して配れば良いだけでは。
RHEL使う気ない奴はRedHat絶対殺すマンでも何の問題もないが、
RHEL使いたい奴がRedHatの足を引っ張っても何の生産性もないだろ。

Red Hatはソースを外部に漏らしたらサポート切るって言ってるぞ

>>884
クラウドで使ってソース貰うのがオススメらしい

IBMはRHELをどうするつもりなのか
いっそMSがウブンツを巻き取ってRHELを殺して欲しい

カノニカルもRedHatもビジネスモデルは同様だし、
ubuntuで済むのならみんなRHEL使うの止めて自然と死ぬ。
そうならない理由があるのだから、俺が気に入らないから殺すと考えるのは幼稚なパヨクだよ。
RHELよりもよい代替品を提供出来れば順当に死ぬ、この殺し方が正道。パクったりリークではなくてね。
むしろモロパクしてた連中が困ってるだけだから勝手に死んどけでしかない。

ああちなみに言っておくと、apacheその他のアプリ陣営からすると全ディストリがモロパクであって、
ディストリごときがデカい顔してんじゃねえ、つべこべ言わず最新版使えでしかない。
この意味ではarchは正道だよ。

RHELと比べたらUbuntuなんて全パッケージAURで動かしてるようなものだぞ
堅い業務で使えるような代物じゃない

重いけどGNOMEはなんだかんだ便利で使ってるが日本語環境に難があるよね
iBusがデフォでfcitxと相性が悪い
何とかならないのか…

今年は暖冬のせいか秋ジャガイモがまだ青々としてるわ

堅い業務って何のことを指すのか知らんがUbuntuサーバーで動いているwebサービスなんて山程あるぞ

Webシステムですら、普通に官公庁とか、大企業だと赤帽が多い

スマホにarch入れたけど結構いいね
初arch

>>887
ネトウヨ臭え

>>894
パヨク死ね

つか多分、ネットが順調に発展してきてるのはフォーク主義で、代案がないと俎上にも載らない事が大きい。
代案もなく文句しか言わないパヨクなんて全員死ねでしかないし、これを実現出来てるのがネットだ。

RHEL殺したいのなら、お前がRHELに代わる何かを提供すればいいだけの話。
誰もそれが出来ない限りRHELは生き残るという、至極単純な世界だ。

パヨクってなに？
カルト壺用語わかんない。