オススメLinuxディストリビューションは？ Part88

前スレ
オススメLinuxディストリビューションは？ Part87
https://mao.5ch.net/test/read.cgi/linux/1675795293/

ではここでリンカさんが一言

>>638
RHEL互換ならMiracle Linuxがよろし

>>665
のーみそこねこねと言ってほしかった

Centos7が来年終了するので後継OSを探しているんですが、Rocky linuxあたりはどうですか？

生理的に無理な人にすすめる気はないけど

https://yum.oracle.com/oracle-linux-isos.html

>>669
RHEL本家がよろしい

ターボリナックスつかってろや

>>669
条件を満たせば無料のRHEL

RPMとかねーかな流石に

Mageia
PCLinuxOS
OpenMandriva
ROSA Linux

Mandrake四天王最弱なのは…

RPMとか極々少数の信者だけが使ってるらしい格別面倒ばかりかかる特殊なものです

無知は罪だぜ

>>668
なんか、すいません

>>677
ほんとこれ
今は情報源なんていくらでもあるし

ムチはご褒美ムチムチもご褒美

>>680
だらしな系おなか

仕事やんないならyumは今後も知識ゼロで多分良いかな？？？
来年6月まで、安心できない人は居るかも知れんけど

>>674
個人的な感想ですけど
debと比べると、rpmの方が簡単だし良くできてますよ
まぁ、後発の、archのPKGBUILDが一番分かりやすいと感じますが…

あ
パッケージを作る場合の話ですので
使うだけの方には、あんま関係ありません
誤解なきように…

Debian系ディストロは無線LANとかのプロプラドライバ含まれて無い事多くて積むケースが地味に多い
Ubuntu系ならドライバに関してはマシだけど個性が無い

ターボリナックスつかってろや

オマエガナー

この辺とか
そんなに認知度が低いのかな
https://cdimage.debian.org/cdimage/unofficial/non-free/images-including-firmware/11.7.0-live+nonfree/amd64/iso-hybrid/
https://cdimage.debian.org/cdimage/unofficial/non-free/images-including-firmware/current-live/amd64/iso-hybrid/

その人が知らないだけかと

結局今デスクトップ用途で主流なのって圧倒的にarch系なんだろ？

>>691
割合は知らんけどウブンツがunityとキャノニカルのせいで個人ユーザーから見限られつつあるのは確か

「かんたんなDebian」を求めてた層が「かんたんなarch」に流れてる

なおMXは健在なもよう

逆にウブンツは企業ユーザが昔より増えた気がする
気がするだけ

だってdebianのほうが簡単なんだもん

Google も Ubuntu 止めて Debian を元にした自前のディストリビューションにしちゃったしな。
Ubuntu が進めたい新機能、途中で止めちゃっう事も多いイメージだし、5年間同じマシンでOSをアップデートしながら使う用途にはUbuntuは向いてないイメージ。
LST は準備してくれているけど。

ローリンアップデートの楽さに気づいてしまったのだな

パッケージ自作はNixOSが楽
OSをカスタムして使いたい人ほどNixOSがおすすめ

ArchってAURに大きく依存してるっぽいけど
AURのPKGBUILDって再現性ないでしょ？しらんけど
ビルド環境の違いでトラブル起きたらデバッグ大変じゃない？

NixOSのnixはビルド環境から完全再現する仕組みになってるからな
debもrpmも依存パッケージは緩いバージョン指定がされてるだけだから
作者のビルド環境を再現するの難しいよね

ターボリナックスつかってろや

>>692
かんたんなarchといえばgaruda kde liteだね

>>697
NixOSは使ってないから知らないけどマイナーのOSはトラブったときにもう詰むやん
やっぱりDebian最強

mintと和解せよ

>>697
NixOSよく知りませんけど
ArchのPKGBUILDは、AURだけじゃなくて
Arch全体のパッケージを作る為のものですよ

で
自分でビルドするにしても、PKGBUIDのテキストファイル1個に、レシピ書いたら
すぐパッケージにできます
当然、依存関係の注入もできますし
Archはローリングですので、バージョンは最新の物を使うが推奨されています
なので、AURのパッケージでメンテされてないものは、人目でわかるようになっています
そして、Manjaroは、archのリポジトリを再テストしてる都合上、本家Archに比べると1ヶ月ぐらい更新が遅れてきますので
それを、よく問題にされますが
それは、Arch本家の問題ではありません

ロボットで無意味なレスしてるやつどこに通報すればいいの？

時代はopenSUSEである

>>703
同じフレーズのヤツなら、NGワードにしちゃえばOkです

同じレスばっかしてたら、そのうち規制されるでしょ

で
この板の自治は無理ゲーですので、諦めてください

そんなことより、オススメのディストリについて語ろう！

貴方のオススメのディストリはなんですか?

>>700
どんなトラブルかによる
nixのDSLでシステム設定を宣言的に記述しておけば
起動しなくなってもブートメニューで
前のシステム構成から起動すればおk

仮にブートローダーを破壊してしまっても
Gitにnixで記述した構成を保存しとけば全く同じシステム構成でインストールできる
スナップショット要らずだし、何を変えたか分かりやすいし、
複数のマシンで設定を一部変えて
同じようなシステム構成にするのも簡単

前のシステムに戻せない事によるトラブルはないが
使いたいパッケージがなかったり、古かったりした時が面倒かな
そういうときに、英語でググれたり質問できるハードコアなLinuxユーザー向けとは思うが
システム構成をすべて宣言的に書けるのは
学習何度に勝るメリットだと思う

>>704
suseもローリングのだしてるし
なんつたってKDEのパトロンですからね
suseに足向けて眠れません
suseの方角分かんないけど…

>>702
今までのパッケージマネージャーは
依存関係にあるパッケージのバージョンを固定出来ないのが問題
nixは全て固定できる

nixはビルド自動化ツールに分散キャッシュ機能を付けて
パッケージマネージャーのように使えるようにしたツールとも言える

ソースコードのtarアーカイブのハッシュや依存パッケージ、configureスクリプトに渡す引数なんかをハッシュ化して
そのハッシュで既にビルドした物がキャッシュに無いか検索
ローカルに有ればそのまま使うし、公式リポジトリのキャッシュにあればダウンロードする
キャッシュされてないパッケージだけをビルドする

ビルド時は上記の入力にない物がビルドに使われないように
サンドボックス内でビルドして
環境依存のビルド不具合を防いでいる
だから「git cloneで取ってきたnixがビルド出来ない！！なんで！？」みたいな問題が起きない

実行時も入力に書かれているパッケージしか基本的に使わないので、
実行時のライブラリバージョンの違いによるエラーも回避できる

公式リポジトリにあるパッケージは既に同じ設定でビルドしてキャッシュしたのがあるので、
大半はビルドせずダウンロードするだけで済む
マシン固有の設定も「キャッシュされてないパッケージ」として扱ってビルドする

NixOSは一部のパッケージだけバージョンアップしたりパッチ当てたりして
使うのが非常にやりやすい

公式リポジトリはGitHubにPR出してマージされれば
そのうちCIでビルドされ、ビルド済みのパッケージがキャッシュされる
GitHubだけで完結するのが今風で良い
（すぐレビューしてくれるかは別にして・・・）

自分のパッケージリポジトリもGitHubでリポジトリ作るだけで良い
ビルドとパッケージのキャッシュもCIで自動化しようとするともう少し大変だが、
カスタムの部分をソースからビルド出来さえすれば良いなら
GitHubで公開するだけで良い

Archは公式パッケージは何か使って再現性は確保してるらしいけど
AURは特にそういう仕組みなかったと思う
Archよくしらんけど

>>708
なんか理解しきれてないけど
debでもrpmでも依存パッケージの
バージョンの措定できますよ
なんとか以上とかって…

Archに関しては、繰り返しになりますけど、最新版使うのが常識なので、あえて言及する必要ありませんが
それでも依存関係でバージョンが古いって怒られたりもしちゃいます

鉄オタみたい

>>711
Linuxオタって言ってあげてください
鉄オタは、ほぼほぼ自分で鉄道作っている訳じゃないけど
Linuxオタは、そのオタク達が、Linuxオタクのために仕事してんですよ

鉄オタ見たことないけど…

>>711
早口で喋ってそうだよね

>>713
よく、おっとりしてるって言われますけど
やさしいとも必ず言われます
そんなに、やさしくは無いんですけど…

そして、せっかくこのスレに登場したんですから
貴方のオススメのディストリについて語っていってください

やっぱ、archなんですか?

>>712
鉄オタなんてYouTube行けばすぐにお目にかかれるよ
スーツ氏は一目置いてるが変わり者だね

>>715
興味ないので、視界に入ってくるまで
ディレイさせてください
その、なんとかって人がLinuxオタなら
ちょびっと興味わくかもしれませんが…

そんで、あなたのオススメのディレクトリはなんですか?

ぜひ語っていってください

>>716
あーー

まちがっちゃったよ
ごめんなさい

ディレクトリじゃなくて
ディストリですね

大変申し訳ございませんでした

>>710
でも、バージョン細かく指定しすぎると更新の度に依存関係満たせなくなってエラーなるから
以上～以下みたいな緩めのバージョン指定しか実質出来ないよね？

nixの各パッケージにはそもそもバージョン指定が全くないことが多い
メジャーバージョン指定しないと、互換性が無くて動かないって時だけ
メジャーバージョンの数字が後ろについたパッケージのバリアントを指定する事はあるけど、基本は指定しない

こんな感じで、依存パッケージのバージョンの指定はない
https://github.com/NixOS/nixpkgs/blob/cc45a3f8c98e1c33ca996e3504adefbf660a72d1/pkgs/tools/nix/nixpkgs-fmt/default.nix

NixOSの公式リポジトリ（nixpkgs）はいわゆるmonorepo的なGitリポジトリとして作られてる
皆で1つの巨大リポジトリを育てる仕組み

リポジトリの特定のコミットをチェックアウトすれば、おのずと全パッケージバージョンが決まるので
いちいち全パッケージでバージョン指定なんてする必要が無いからだ
パッケージがアップデートされたら、ABIに互換性あるかとか関係なく、
依存してるパッケージは全て再ビルドしてバイナリキャッシュにアップロードする

かなり贅沢にマシンパワーを使う仕組みではあるが
ユーザーがソースコードにパッチを当ててパッケージをビルドする時も、
ビルド出来る事が既にテストされているパッケージの組み合わせでビルド出来る訳で
ビルド失敗するって問題が起きにくい

その一方、NixOSでアップデートする時は全パッケージが更新される
従来のパッケージマネージャーでは一部だけ更新する事は出来たが、NixOSは出来ない
その代わり、チャンネルを組み合わせる事で
同じパッケージの異なるバージョンが幾つも存在出来るようになっている

OSやデスクトップ環境は安定版チャンネルのパッケージを使うが、
Rustは最新版パッケージを不安定版チャンネルから取ってくる、みたいに幾つでもnixpkgsのチャンネルを組み合わせ可能になってる

ユーザーリポジトリにあるカスタムのパッケージをnixpkgsと組み合わせて使う時は
既に使ってるnixpkgsのチャンネルがあれば、そのリビジョンをユーザーリポジトリから参照させる事で
最新版nixpkgsと組み合わせてビルド可能だし、
最新版使ったらビルドがエラーになった、って時は
そのリポジトリが参照してるnixpkgsのリビジョンを使えば
ユーザーリポジトリの作者と全く同じ環境でカスタムのパッケージをビルド出来る

aptってバージョンをhold出来なかったっけか
>>708 さんの発言よく分かりません

ニッチというか滅多に見ない部品使ってる中華PCに入れるにはどの酉がいいですかね？
ドライバー揃えるのが大変
ノートのキーボードバックライトとかDebianではnonfree contribでも結局操作できなかったので点きっぱなしに

GarudaかEndeavourOS
気合いあるならarch
arcoってどんなんだっけ。。

大事な説明が抜けてるんだな
Nixは「バージョン違いのパッケージを共存できるから」全体をアップデートしつつ特定のビルド環境を完全再現もできる
らしいよ

>>721
Deepinじゃないの
あらゆる穴から情報を抜かれそうw

apt-rdepends foo
apt-rdepends -r foo
してごっそりhold
パッケージファイルは--download-onlyで確保、とか

acpiを通して/sys/class/ledsとか/sys/class/backlightに列挙されてくるならlinuxでも直接叩けますけれど
win/mac専用ドライバ/アプリ経由で動作するタイプだときつそうですね

>>723
Dockerか仮想環境でええのと違うか
Gentooか派生でemerge --search

>>724
オープンソースでどうやって仕込むんですかねえクソウヨ君

deepin入れたことあるけど噂通りの重量級、デザインがとてもmacライク

https://q4os.org/downloads1.html

Debian系でKDE Plasma desktopを安定的に使うための選択肢、かも
詳しく確認してないけど。。

Bookwormは9月リリースだろうか
https://endoflife.date/debian

キーボードバックライトは電源管理power-managerのお仕事。Gnome系、KDE、XFCEで点き方変わってきま。

>>728
仕込んでもバレないか試して、結果バレなかったという話があるけどね
今時膨大なソースを追える人は少ないと思うよ

うちのMacBookairの場合Gnome系(マテシナモン含む)は再起動のたびキーボード最大輝度に、KDEはライト点かず、XFCEがいい感じだったので一時MATEに xfce4-power-manager入れたりも

>>731
というネトウヨ特有の願望

>>722
calam-arch-installer使えばバニラarchも気合い要らずよ

>>697
そんなにマイナーバージョンの差によるエンバグデグレって頻発するっけ
KDEしらんけど

... fedoraでもええんやで
動画見て貰えそうにないけど

32bit uefi atom機にGarudaでも入れてみやがれ。。

アプリによっては文字化けや日本語入力さえままならんものも今だにあるんやな
こんな使い勝手の悪いOS使う意味あるかな
やっぱり第8世代のPCを中古で用意してwindowsかな

ターボリナックスつかってろや

>32bit uefi atom機

酉以前にブラウザが対応してない

自分に自信がないやつはMint

mintと和解せよ
日本の夏mintの夏
流れよ我が涙とmintは言った

結局mintが良いの？

>>742
良いよ、問題ない

気がつけばMint

Ubuntuだとパッケージの不具合で動かなくなる事があるだけでなく
atomicなアップデート&ロールバックが出来ないのがアレ
アプデ中に電源供給が無くなるとシステムが壊れる
Windowsですらアプデ中に電源切っても壊れなくなったのに

NixOSはシステムパーティションの殆どのファイルが
/nix/storeの読み取り専用ファイル・ディレクトリへのsymlinkでしかない
アップデートはnixで書かれた設定をもとに/nix/store内にビルドして
完成したシンボリックリンクを切り替えるだけって形なので
（ブートローダーの更新以外は）壊れる心配がない
ゆえにUbuntuのリカバリーモードみたいのも無い

実際にnixで書いた設定ファイルはこういう感じ
nix flakesも一緒に使えば、npmで言う
package-lock.jsonのようなロックファイルで
nixpkgsのリビジョンを固定可能

NixOS と Nix Flakes の紹介
https://zenn.dev/kino_ma/articles/f2a4df384b91a4

DockerもDockerfileからビルドする場合は再現性無いから
アップデートのために再度ビルドすると失敗する事はあった

Dockerイメージにビルド結果を保存出来るようになったのと単機能のコンテナを組み合わせできるようになって
問題は少なくなったけど
上記の再現性の問題はパッケージマネージャーの設計から来てる問題なので未解決

Docker使っても出来るのは開発環境の管理まで
/etc、カーネル周り、DE周りなど、OS直接触るしか無い部分は
再現性のある管理ができない

PopOS!どうよ

常用してる人見ないディストリ筆頭

常用に適した鳥はgaruda kde lite

ubutuってログ見たら、エラー多くないですか？22.0.4使ってるんですけど7つくらいエラーになってます　たまにアプリがクラッシュするし

>>747
rustでDE書き直すって言ってたけどどうなったんだろう？

オススメ
open suse tumbleweed か gentoo

皆さまは基本Linuxは仮想マシンで動かしてますか？
あと、仮想マシンの個人ユースでのシャアはVirtualBox、VMware、Hyper-Vでそれぞれどのくらいの割合なんでしょう

というかnixっていう長文連投マジ勘弁

linux上でwindows10動かして喜んでるアホやったらおる

>>739
uefiが32bitなだけで64bit OSは稼働出来る
ASUS E203MA等のノートPC板で既出

>>746
> DockerもDockerfileからビルドする場合は再現性無い
つ > --download-only

>>747
Stable DiffusionによるAIイラスト生成で、外国人が使っていたケースは伝聞
日本人だと、まざ使うメリットが見い出せない

>>753
WSL2でUbuntu使っている人は相応に多いかも

Git for WindowsのmingwとかQt for Windowsとかと比べると分からんが、実質としてディスクアクセスのパフォーマンスがmingwより高速っぽくはある
仮想命令を介しているからCPU律速の処理はmingwに分がある

ターボリナックスつかってろや

>>759
逆じゃね？
基本的に仮想で足を引っ張るのはIOの方だろ。

>>757
何の事を言ってるのか分からんが
Dockerfile内でapt使う時も
普通にホストでapt使う時と同様に
インストールされるバージョンに再現性ないよね
インストール時の最新が入る

OSSのコードを弄る時はDockerイメージとかDockerfileが既にあるとも限らん
だがnixならパッケージ化されてる場合もある
そういう時、nix developを使えば
依存パッケージがインストールされたシェルに一時的に入れる

nix developのシェル環境は、Dockerのように
ホストと分離されたサンドボックス内での実行ではない
DockerではやりにくいGUIアプリの開発環境構築もしやすく便利だ

一時的な物なので、開発しなくなったら削除するのも簡単なのはDockerとnix developは似てる

>>753
デスクトップPCは
ブラウジングとか趣味の開発はLinuxでやって
ゲームとかだけWindows10の仮想マシンでやってる
VM使用中はホストからWindows用のパーティション読めないけど、自分の用途ではそんな困らない
性能的にも十分
アンチチートがVM検出して動かないゲームあるのだけ難点だが、問題ないゲームも多いし

ノートPCはWindowsだけ

windowsとmintのデュアルブート

デュアルブートとかUbuntuとかって10年ぐらい前に流行った感じかな