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

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

>>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年ぐらい前に流行った感じかな

今でもネイティブじゃないとできないことあるけど
VFIOのおかげでほぼデュアルブート不要になった

いまもメインDebian、サブWindows10 x86でデュアルブートしてるけど
古いゲーム用ね

デュアルブートにすると、同居してるWindowsがうっとうしいんだよね。
間違って一端起動すると勝手に半日以上もWindowsアップデートして妨害してくる。
パソコンは安くなったから、各々専用で使ったほうが良いかもね。

>>762
--download-onlyでローカルにdebファイル確保しておけば良い、それだけの話
依存関係にあるもの全て含めて

私が何を言っていることの意味は、分からない所ありませんか
理解できていますか

例えば sudo apt install ffmpeg と実行すると、大抵のdistroでエラい表示になりますが、必要なdebファイル全部確保しておく、それだけのことです

めんどいから酉ごと買い取るわ

>>769-770
nixは色々な使い方ができるが

nix shell、nix developはDockerみたいにシステムを汚さない、インストール先の環境（既に入ってるパッケージ）に依存しない環境構築が
コンテナを使わずに出来るのが良いところだ
だからGUIアプリの開発にも使える

nixならチームでの開発も、nix（テキストファイル）をGitHubに置いて渡すだけで環境構築できる
一人でも、nixだけ保存しとけばいつでも開発環境を復元できるし
システムを汚さない、いつでも消せてディスク領域も圧迫しないのが良い

debを保存じゃDockerみたいな使い心地は無理でしょ

>>768
つい先日その罠にハマった
カウントが100％になったと思ったら「あともう少しです」とかでて殺意が沸いた

>>772
Dockerfileで入れるべきパッケージのdebファイル持っておけば再現性がある
それだけのこと

>>774
既に同じパッケージのバージョン違いがシステムに既にインストールしてあったりしたら
conflict起きたりして無理でしょ

スクリプトで毎回アンインストールとインストールするのか？
チーム開発なら全員にそれを要求？
そしてバイナリをGitHubか何かにアップロード？
一人でも、インストールにも時間掛かるし現実的じゃないと思う

nix developは不変のパッケージをsymlinkで組み合わせるだけだから環境の切り替え早いし
パッケージの追加削除もテキストファイルを変更すれば良いだけ
バイナリを更新してアップロードしなくちゃとか
考えなくて良くなる

OSSのGUIアプリの開発なら
まず必要ツールとかライブラリをaptから探してインストールする作業が必要
そこがまず面倒じゃん
nix develop使ったらその辺も楽になる、アプリが依存してるパッケージを勝手に取ってきて
一時シェル作ってくれるので

いや、aptにもbuild-depで開発用パッケージの検索はあるか
使いたいアプリがパッケージ化されてれば

バージョン違いとかconflictの問題は残るが

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

何の話をしているんだ？
空中戦すぎて異常

空中線とロケーションが全てなんだよ

>>777
archには、devパッケージ無いんですよ
通常のパッケージに内包されています
なので、あれが足りないこれが足りないってなんない
その辺が他と違ってシンプルで扱いやすんですけど
アプデも容量がデカイって不満もたまにききますね

結局gentooにたどり着いたのがGoogleだっけ

Google社内の開発環境：Ubuntuベース → Debianベース
ChromeOS：Ubuntuベース → Gentooベース
ChromeOSのLinux開発環境：Debian
Google Cloud Shell：Debian

KDEのアレヤコレヤを除けば

用がないならdevパッケージ(相当分)は入れたくないな
意図してないのにconfigureで検出されて使われてしまうと困ることもあるし

困るの分かってるなら明示的にconfigureに引数渡すもんじゃね
バグってるconfigureは話が別だが

Gentooもnixも
ソースからビルドする手順が書かれたファイルがパッケージなのは似ていて
よく引き合いに出される

https://www.reddit.com/r/Gentoo/comments/wjn2xq/gentoo_users_what_are_your_thoughts_on_nixos_have/

GentooのPortageの方がUSEフラグのドキュメント充実してて分かりやすいとは聞く
逆にnixの方がビルド済みパッケージの数は多いとか

PortageはGentoo系オンリーだが
nixはNixOS以外でも使える

nixはソースからビルドしたバイナリが100%同じになるように設計されてる
Portageはそこまでは目指してないが
場面次第でメリットにもデメリットにもなりそう
（nixの場合、多くのパッケージから参照されてるパッケージにパッチ当てるのは難しい。ビルドに物凄く時間が掛かるので）

>>785-786
そういう時のためにnix develop --ignore-environmentとかnix buildがあるんだが

Dockerのような一時的なビルド環境の作成と切り替えを
（Dockerのようなコンテナ技術は使わずに）実現してる

バイナリをダウンロードしておいて、必要な時だけ環境を切り替えしたり
nixファイルに書いてないパッケージが勝手にconfigureに渡されないように出来る

nix [bd]
もNGWord追加か

Unix

Unix banzai
Unix daisuki

>>779
>>789
長い文章を連日連投しているけど何のためにやってるんだろうね

布教？

あるいはただのレスバトル

Nix信者
Manjaro KDE信者
Garuda KDE Lite信者
ターボリナックス信者

みんな実質アンチ

>>793
おすすめのディレクトリスレですから
別に良いんじゃないですか?
Nixおしの人の熱弁で、何に惚れたのか
何となく理解できました

さぁあなたもあなたのオススメのディストリについて語りましょう

mint信者「ゆ、許された……」

熱弁だか血便だか知らねーがオマエ以外誰一人関心のない長文を連日連夜撒き散らすなっちゅーの

逆にターボリナックス信者とかは熱い想いとかねえのかよ！
ターボリナックス使ってろやとか意味のない短文だけ投稿しやがって！

ってもう無くなってんじゃんTurboLinux

オススメのディレクトリは/optと/export

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

Mintが最強