Debian GNU/Linux スレッド Ver.93

extend:checked:vvvvv:1000:512
extend:checked:vvvvv:1000:512
次スレを立てる方は↑を二行重ねて書いてください

公式
https://www.debian.org/index.ja.html

過去ログは各自検索して見つけること
大体参考にならないので過度な期待は禁物

前スレ
Debian GNU/Linux スレッド Ver.92
https://mao.5ch.net/test/read.cgi/linux/1565609547/

知らない
数百MiBあるようなパッケージ複数ならバラけて見える
小さいパッケージならそんなもんじゃない？
丁度WineのアプデがあったからSS撮ろうとしたが
それなりにデカイはずなのに一瞬で終わって撮れん

じゃあ合成ってことだねｗ

なにいってんだこいつ

見えてる地雷をわざわざ踏みに行くのは感心しないなあ

>>392
すまん、おかしさを感じつつ油断してた

https://i.imgur.com/yFHGrrM.png

煽って説明させて楽に知識を得ようとする手なのかな、これは。

スレ違いでもなんでも無理やりレス引き出そうとするアレか

ああ、ア○ィね

Debianで自動アップグレードする簡単な方法って何かな？
再起動が必要なときは自動的に（できれば時間指定で）再起動してほしい

https://wiki.debian.org/UnattendedUpgrades

検索すれば沢山ヒットするんだから
詰まった箇所で質問しないあたり、試してないどころか
検索すらしてないんだろうな

たくさんある中から、一番簡単な方法を聞いてます。
それに再起動が必要な時に、自動的に再起動の方法は見つかりません
>>398が証拠です。面倒かつ必要な機能を満たせていない。
ちゃんと検索してますか？

なんで上から目線でお前ら教えろなんだろう

毛が三本足りないんだろ

斉天大聖乙

初心者を上から目線で馬鹿にする人は随分減った気がする。
良いことだと思う。

でも相変わらず、自分で何も調べずに、何も努力せずに、
上から目線で「私に教えなさい！」って人がいるんだな。
ここはホントに、大変なスレだよ。

再起動が必要な時ってどういう時かな
カーネル更新しても再起動せずにそのまま使っていられるし
もちろん新しいカーネル使いたかったら再起動しないとだけど

実際、上手に煽ってやると
せっせと知りたい答えを集めてくれる奴らが一定数いるからね。

俺はそんな身につかない、かけた時間が後で全くの
無駄になっちゃうような調べ方はしたくないけど。

>>405
カーネル更新したけど、新しいカーネルは使わないって
なんのためにカーネル更新したの？

よりにもよってDebianという素材ディストリ使っておいて、
最初の単語1個検索にかける時間も惜しむほどシステムに興味がなくて、
それでもIDと口調を偽装してまでしがみつかなきゃいけない
理由ってなんなんだろ？

学校の課題とか？

>>407
upgradeでカーネル新しくなったけど
いま仕事広げちゃってるし再起動めんどいなあ
fsckかかったらやだし、とか
カーネルのアップデートはたいていセキュリティ関係だし
暇になったら再起動しとくか、くらい

>>409
それカーネルを更新してないって意味だよね？

>>409
で、再起動すると起動しないっとwww

そう言えば最近お高くとまった奴見かけなくなったな
あいつも度々IDコロコロしてたのバレバレだったけど

Linuxだって更新にはお祈りが必要なんだから過信は禁物だぞ
最新版しか使えないローリングリリースは怖くてやってられん

リソース不足でローリングリリースしかできない distro じゃあるまいに

そんな貴方にはzfs rollback

物理なら諦めるしかないが、仮想ホストならボリュームイメージをコピーしてからUpdateしたらいい

LVM snapshotとかでもいいんじゃない?

確かに

AndroidみたいにA/Bパーティションできるようになればいいのにな
そうすればアップデートに失敗しても問題ないのに

Debianのカーネル入れ替えに相当する
Android上の操作はメジャーアップデートだろ。
リスクは同等か、低レイヤを直接触って
技術でカバーして直せないことを考えたら
Androidの方がリスク高いくらいだ。

Debianで同等にしたいのなら
Dockerコンテナ以外は一切入れない運用にすれば
リスク的にも技術的にも同等になるが？

ってもはやDebian関係ねぇ

あぁ、ABパーティションってパーティション２つ切って切り替えるあれか。
420の回答は的外れだ。すまない。

DebianでやるならLVM？

aptリポジトリからインストールしたパッケージはaptだけでアップデートできるんだな
って当たり前か

某OSと比べるとそこが利点に感じる

んなことはない
無理矢理他のパッケージマネージャ入れたり自分でmake installしたりすれば簡単にぶっ壊せるよ

またスレ水増しのネタ投下か

「包丁で心臓を刺せば人を殺せるよ」程度の情報

例えがよくない!

Windowsの場合も一応パッケージマネージャは
あるのだけど、

- リポジトリがない（ストアアプリにはあるけど全てを管理できない）
- お作法というか縛りが緩くてメーカーのやりたい放題
- 連結サブパッケージシステムとも呼べる物が複数乱立してる

辺りがカオスの原因じゃないかなと。

そういう意味では423はWindowsの現状を
Debianで無理やり再現してると言えなくもなく
意外と合ってる気がしなくもなくもない。
（無理やりだけど。）

Windowsでもaptやらrpmやらを導入する事はできるだろう
けど現状そうなっていないという事はMSや周囲がパッケージマネージャを導入する利点を見いだせていないという事だ

最近ではクラウドやコンテナの普及によってサーバーのLinux環境は使い捨てるスタイルが主流になってきて、
パッケージマネージャは単なるインストールツールに成り下がりつつあるね
そしてデスクトップだとアプリのフィーチャーアップデートを積極的に入れるから、
aptのような保守的でコンポーネントを極力共有するスタイルのパッケージマネージャはあまり適さないんだよね

まじでこいつらどこかいってくれ

ああ、もう・・・なんで debian スレはこんなに荒れるんだ。
ひょっとして、こいつ、自作自演か？？
まともな状態は三日と続かないｗ

>>427
それいったらmacOSにもパッケージマネージャーもリポジトリもないよ。
サードパーティのHomebewにお世話になるしか無い

で、CLIで動くWindows標準の公式パッケージマネージャーといったら
PackageManagementだけど裏ではNuGetやChocolateyが動いていて
これらのサードパーティのパッケージマネージャー＆リポジトリを
（パッケージプロバイダとして）共通インターフェースで扱えるもの

NuGetはほぼ.NETライブラリ用なので、アプリとしてはChocolateyがリポジトリとして使われてるね
サードパーティだから、リポジトリがないと言いたいんだろうけど、でもWindowsで
パッケージマネージャーを使ってCLIでいろんなアプリをインストールすることはできる。

現時点で全部で7,387パッケージあるらしい（細かい派生パッケージ？を入れると82,802らしいけど）
Debianも6万ぐらいパッケージあるけど、ライブラリとか細かく分かれてるから
アプリとしての数は同じぐらいでは？

CIサービスではソースコードpushしたら自動的に環境が構築されてテストが実行される、
つまりCLIと同じようにコマンドで自動化されてるけど、そういうのでもChocolateyなどが使われてる。

ともかく、知らない人が多いだけでパッケージマネージャー対応としては
十分だと思うけどなにか不満ある？

chocoは管理がメチャクチャな印象しかない

鮭が正月の定番？
聞いたことない

吉池の回し者だろ

雑談は余所でやれ

>>433
お前の印象じゃなくて事実を語れ

>>437
板違いだからその必要は無い

じゃあ嘘も語るな

IDコロコロしてるくせに威張る男の人って‥

Debian壊すな、という話はDebian Wikiにも書いてある
https://wiki.debian.org/DontBreakDebian
非公式なリポジトリを混ぜた状態をFrankenDebianと呼んでる

>>441
なんかツッコミどころ満載のページやなｗ

そりゃアプリの開発者は（一部例外はあるだろうが）
Debianで動作保証なんてしてないんだから動くかどうかわからない。
それを保証してるのがDebianってことだろう？

そこはWindowsと大きな違いなんだわ。
Windowsはアプリの開発者が、Windowsで動くことを検証してる。
多くはバーション指定して動くと保証してるね。

それとそのページ、ソースからビルドしろって言ってるけど
要するに、他人がビルドしたものを使うなってことじゃないのか？
そのことには同意するけどさ、これもWindowsに当てはまらないよね
公式がビルドしてるんだから

そのページは結局、Linuxの世界は特定のディストリで正しくアプリを
インストールして動かすことの難しさを語ってるだけじゃないのか？
それは俺もそのとおりだと思うよｗ

>>441
そこのリンク先にもFlatpaksとかSnappyを使えって書いてあるけど、
FlatpaksやSnappyで提供できるようなものは
Debianパッケージとして提供するのをやめたほうが良いと思うんだよね

アプリ開発者にはaptやyum経由の利用者を嫌ってる人が多いよね
「ユーザーは開発者である」の思想を追求したことが、結果として本来の開発者とユーザーの間の溝を広げてしまっているというのは皮肉な話だな

upstream と連携とってない部分はフォークに見えて
不快感を隠しがたいんじゃね

嫌ってるというか対応できないからな
バグ修正しても対応できません。本家では直ってます。後は知りません。
旧バージョンのサポートは終了しました。
枯れてるコマンドは良いけど、開発速度に追いつけないんだよね

>>442
そりゃWindowsでも開発元が自分のソフトだけインストールして検証するなら動くだろ
むしろ動くか検証しないでリリースする会社いるのかよ

sonameとかの根本的なことが分かってないからこういう馬鹿な発言になるんだろうな

サポートの問題と soname の話は別なんじゃないかなあ

そもそも開発元公式のOSのパッチやアップデートで
ぶっ壊れる事件も多々起きてるのは…

"Advice For New Users On Not Breaking Their Debian System"
という親切なページがいつの間にかできたんですね。>>441

初心者向けに、きちんとまとめてあって良いね。
Debian 公式レポジトリーを使うのは昔から基本。そのための　APT。
基本を守っていれば、滅多に不具合は起きないから。アップデートもあるし。

サードパーティのパッケージは十分な検証が行われていないからね。
サードパーティでも、FlatpakやSnap を使ったほうがいくらかマシなだけで、
それらも、""some ways to reduce the risks""と警告されている。

Windows であっても、匿名のサードパーティはインストールしないよね。
Windows Updatesに相当するのが、Advanced Package System。

訂正→　Advanced Package Tool　

荒らしの連投いつ終わるんだ？

>>453
午前中にはすでも終わってるよ

反応するやつも荒らしいうしな
わしもか

最近のreportbug-ngコマンドはバグ報告テンプレートにaptリポジトリの
一覧を入れてくれる。サードパーティリポジトリが問題の原因の可能性も
あるからね

うぶんつさんが「サードパーティーリポジトリを使うのが当たり前」という悪弊を拡散させてしまったから…

なんでサードパーティリポジトリを使おうとするのか？
その要望を理解してないんだよね。

サードパーティのソフトを入れても壊れない仕組みを作ったほうが良い

ディスクとメモリのフットプリントを減らすことに命懸けてきた時代の遺物だからねえ
公式リポジトリのパッケージは検証済みというのも眉唾だな。
せいぜい公式リポジトリの共有ライブラリとリンクされたものが最低限動くという程度のテストだけで限界で、
マイナーなパッケージでは機能的な検証がロクにされてなくて使い物にならないものも珍しくない。

デスクトップアプリのようなセキュリティ懸念の少ないものについては、
可能な限り共有ライブラリを使わずに静的リンクせよとガイドラインを出すだけでも、
遥かにロバストになるし検証の手間も減ると思うね。

https://www.leviathansecurity.com/blog/aslr-protection-for-statically-linked-executables
まずこのへんでも読んで理解しろ
これすら理解できねぇんなら3才児が｢げんぱつはんたーい｣って叫んでるようなもんだからママのおっぱいでもしゃぶって黙ってろ

>>461
ところが、最近流行りのGo言語は全てスタティックリンクするのが基本なんだ
そして、もはや常識となったコンテナ技術はある意味究極のスタティックリンク技術とも言えるもので、
アプリケーションに対してLinuxシステムを丸ごと実質的にスタティックリンクする
残念ながら、時代はスタティックリンクなんだ
セキュリティはクラウドプラットフォームのレイヤで確保するものなんだ

連投してるのは全部NGにすればいいのか？

ノートPCにDebian10.2をnon-free版isoでインストールしましたが、数回何かキータイプしないとNICが有効になりません。
ところがデスクトップPCにストレージを繋いでブートするとこのような事は起こりません。
しかもノートPCのままでもSSDからHDDに丸ごと書き換えてブートしてみてもこのような事は起こりません。
ノートPCで使用しているNICドライバはfirmware-iwlwifiで、OSインストール後にaptで入れたものです。
NIC自体は以下のものです。
https://ark.intel.com/content/www/jp/ja/ark/products/75439/intel-dual-band-wireless-ac-7260.html

システムログ関係も見直しましたが、いまいちよく分かりません。
原因としてどのような事が考えられるでしょうか？宜しければご回答頂けると嬉しく思います。

>>462
てめえのそのクソ箱んなかのgoやdockerのバイナリがどうなってるか確認してみやがれクソニワカ
コンテナとstaticlinkを同列扱いしてる時点でガイジ以下なんだよクソ虫が

>>463
NGID に都度でぶっこんだとしてもコロコロ変えてくる奴が出て来るだけなので
私は諦めてる
※感じ方には個人差があります

ID:P1yzkYK9 は口はわるいけど適切に役に立つ助言をしているので
逆に ID:WxPywLO6 や ID:rfzCB+FT をNGIDにすべきだと思います。

おま環の私もNGですか？

自己解決しました
スペースキー連打したりするとコンソールに「crng init done」と表示されるので、/var/log/messagesからコピペして
検索してみたらエントロピーの枯渇との事
何でも4.16カーネルからのバグらしいですね
aptでhavegedというパッケージをインストールしたら何の問題も無くなりました
どうも失礼致しました

initの投票は現状維持で終了
https://vote.debian.org/~secretary/gr_initsystems/index.html

結局何がしたかったのか…

>>464
以前も書いたが、non-free版isoでもnon-freeファームウェアがインストールされてなかった
dpkg -l firmware-linux-nonfree でインストール済みの有無を確認して無ければインストール

>>471
お考え頂いた通りにfirmware-iwlwifiもfirmware-linux-nonfreeも後からインストールしたんですけど
問題は解決しませんでした。その後一応何度もupdate-initramfs等も試してみました。
乱数生成等はあまり知らなかったのですが、>469に書いた通りに乱数生成デーモン？を追加したら問題は解決しました。
でもレスを下さりありがとうございます。

Debian Developers Decide On Init System Diversity: "Proposal B" Wins
https://www.phoronix.com/scan.php?page=news_item&;px=Debian-Devs-Vote-For-Prop-B

ソースコードからビルドするときは
/usr/local/src以下にソースコードを配置して
/usr/binとか汚したくないから、/opt以下にインストールして.bashrcでパス通してる
update-alternativeは使ってない

>>474
> /opt以下にインストール

基本だよな
昔は /opt./kde/bin とか良く使われたもんだ

基本じゃねーよｗ

>>474
ソースコードはユーザーのホームディレクトリ以下に入れる
ビルドの段階で/usr/localとか/optとかに置くな
ビルドをユーザー権限で行えないだろ

ビルドした後は/usr/local/binとか、パスにlocalって入ってるものを使う
大抵自分でビルドしたものはそこに入るようになってる

/optはユーザーがビルドしたものではない
他のパッケージシステムなどがインストールするパス

/usr/local/srcは/usr/srcと同じで、ソースコードから
ソースコードパッケージをビルドした後、そのソースコードパッケージから
ソースコードをインストールするときのパス
ビルドするためのソースコードを置く場所ではない

> update-alternativeは使ってない
/usr/local/binなどのlocalが含まれてるパスは
システム標準パスよりも優先されるように最初から設定されてる
.bashrcでパスを通す必要もない

また自分しか使わないなら、ユーザーホームディレクトリ以下の~/binや
~/.local/binを使う。（最新ディストリなら）標準の.profileで
それらのパスが存在した場合はそれを使うようになってる。

>>476
https://ja.wikipedia.org/wiki/Filesystem_Hierarchy_Standard


すまないがどういう意味で「標準じゃねえ」のか分からんかった

>>476
> ビルドをユーザー権限で行えない

コンパイル作業自体は /var/tmp/hoge-0.1 とかで行うもんじゃないのかい
貴殿が言う「ビルド作業」というのが何を指すのか全く分からんので何ともいえないが

大昔にどっかに distro でパッケージをメンテしてた頃は専らユーザ権限でパッケージ作ってたけど
たしか kernel 以外は全部ユーザ権限で全く問題なかった気がする

kernel がどうだったかは、さすがに大昔すぎて忘れた
ユーザ権限で出来たかもしんない
K6 系プロセッサで寝る前にコンパイル作業を始めてたことだけは覚えてる

うわっｗ　プログラマじゃないのかｗ

ソースコードのビルドをユーザー権限で行うなんて常識やろ
ソースコードを修正してGitHubにpushとかしたことないんだろうな。

GitHubにpushするならユーザーの鍵を使うに決まってるし
ユーザーの鍵を使ってpushするならソースコードはユーザー権限で
触れる所にあったほうが良いだろ。

ビルドの段階でシステムに影響を与えるようなことなんてしたくないだろ
ユーザー権限で行っていればそういう自体は避けられる。
システム権限が必要なのは最後だけ使うもんだ

>>481
君のいう「ビルド」の定義が分からんのよ

>>482
ビルドの定義にこだわってるからわからんのよｗ

できる限りユーザー権限を使え
それだけだ

>>483
>>479 は読めないのかい

>>478
それのどこに「ビルドする場所」なんて書いてあるんだ？ｗ

>>484
意味不明。/var/tmpはソースコードをビルドする場所なんて書いてないだろ
だいたい/var/tmpはファイルがいつの間にか消える場所だぞ

>>486
> だいたい/var/tmpはファイルがいつの間にか消える場所だぞ

/tmp と混同してないかい

ほら、/var/tmp以下が消えるってことも知らない（笑）

だいたい一般的に使われる./configure & makeで/var/tmp以下が使われるようになんてなってないし
そもそも他のユーザーと共有される場所を使うとかありえんよな
他のユーザーだが同時にビルドししようとしたどうするんだｗ

標準のやり方で楽にできるようになってるのに
オレオレルール導入で面倒くさくしてるだけ

ソースコードはユーザーのディレクトリ以下にgit cloneして
そこでビルドして、最後の最後の段階でsudo make installとかして
システムに入れるんだよ