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/

>>287
USBは普通にddrescueで作成したものです
このスレでも悪名高いUNetbootinはさすがに使いませんね。
面白そうなので円盤からのブートで検証してみます
只今久しぶりにDVD作成中

>>287
追記
この現象の原因は特定済み(デフォルトのgfxmode=800x600とブートメニューに
もれなく記載されているvga=788が当方環境に合わない)で、
rufusで作成したUSBでgrub.cfgを修正してインストールしました。
只今インストールしたStretch上で作業しています。

>>287
https://i.imgur.com/QMZD6xc.jpg
やっぱりダメでした(泣)
尚、↓こちらはgrub.cfgを手直し(set gfxmode=1366x768に修正　vga=788をブートメニューから消去)してブートした様子
https://i.imgur.com/Pkowy8L.jpg
282にも書きましたがインストールさえ済めば至って快適そのものですな

最初の画像見えないからわからんけど、今まさに悪評らしきものを体験できてるんじゃないか

君なら良いDebian Desktoperになれそうだ

>>291
https://i.imgur.com/Fn1d0cz.png
最初の画像をeogで閲覧しているStretchの様子です
今のところデスクトップとしての問題は感じられません

>>292
有難うございます
ディストリビューションの名に恥じないDesktoperを目指したいと思います

>>236
systemd排除する方向の投票はどれなんだ…

>>295
しかしsystemdは速いからの・・・
受け入れねば村は滅びるしかないのじゃ

速いとかいう触れ込みの実
速度変わらなかったやつね
systemd滅ぶべし

でも起動時の自動起動処理を書くのが簡単だからな…＞systemd
そこだけ取り出した init があればなぁ

まあ速度より開発リソースの問題だろう
企業主導で開発が進む現代のLinuxにおいて、Debianの烏合の衆が独自路線でついていくのはもはや無理

ユーザーにメリットもないのに沸く謎のsystemd推し
滅べ

systemdの開発ろくにしてねえ一体なにしてるんだ？とニュースになったばかりなのに
開発リソースも糞もないというね

企業の力をもってしても開発が回らないなら乞食衆が独自路線を選ぶなど不可能だと気付け

不自然な成果物に不自然な擁護
マジ滅べ

スポンサーの意向に従ったけど肝心のスポンサーからの実入りが減ったとかそんなとこかね？

最近の情勢知らんけど
sysvinit 系みたいなの残ってんの？

派生鳥で systemd 排除したモノがあるらしいけど
LXQt みたいな感じで合流？するの？？

本気でユーザーにメリットないと思っているんか？
底が浅いのぉ

Debianでいえば、現状はsysvinitもあるしそれ以外の実装openrcとか
runitとかもある

systemd以外もサポートしなければならない、多様性を認める程度、
はてはsystemdのみサポート、というレベル感の違う選択肢が投票の
オプションとして用意されてる

どれがどういうものかをまとめたIanのblog記事が参考になる
https://diziet.dreamwidth.org/3999.html

systemdが使用してるメモリ量ってどこを見ればいいの？
少ないんだとは思うけどユニットファイル追加したらどれくらい増えるんだろうか？

Systemdの使用法書かれた記事はあっても
initと数値を比較して優位性を示した記事は見たことがない
メリットとされていたのは口先だけの誤魔化しで実際はデメリットばかり
ブラックボックス化して悪巧みしたいのだろうとだけ感じる

systemdのメリットは数値じゃなくて便利さでしょ？
initが起動時したときだけの処理をしてるのに対して
systemdはシステムの動的な変化をトリガーに処理を行う

システムが起動した時だけじゃなくて
ディスクがマウントされたとか特定の時間になったとか
ネットワーク構成が変わったとか
数値の前にinitは機能が足りてないんだよ。

あとinit.dのスクリプトが面倒くさい。自分でpidファイルを作ってとか
start/stop時の処理を書いてとかやらないといけない。
自分で新しいアプリを作ったときに必要になるコードの量がぜんぜん違う
あ、コードの量なら数値でわかるかｗ

毎回ゼロからでなし
比較として適切かどうか

「Java はコードが長いからダメ」っていうのとどう違うか説得力もたせないと

- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
7b77e0f2-4ff9-4adb-85e4-af249191f27a
[ ] Choice 1: F: Focus on systemd
[ ] Choice 2: B: Systemd but we support exploring alternatives
[ ] Choice 3: A: Support for multiple init systems is Important
[ ] Choice 4: D: Support non-systemd systems, without blocking progress
[ ] Choice 5: H: Support portability, without blocking progress
[ ] Choice 6: E: Support for multiple init systems is Required
[ ] Choice 7: G: Support portability and multiple implementations
[ ] Choice 8: Further Discussion
- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-


Voting period starts 2019-12-07 00:00:00 UTC
Votes must be received by 2019-12-27 23:59:59 UTC

systemctl statusは便利

あと/etc/systemd以下にファイルを配置することで
簡単にデフォルト設定を変更できるのもいいな
以前はインストールすると勝手に起動するサービスを
停止させるのは面倒だった

>>311
Javaのコードの長さは型情報の追加という意味があるから全然話が違うよ。

init.dの場合、initが面倒を見てくれれば書かなくて済むものを
自分で書かなければいけない。しかもそのやり方はディストリごとに
パスが違ったりと微妙に異なる可能性がある。

なにより量が違いすぎる。/etc/init.d/cronは少ないほうだと思うが92行もある
それに対して/lib/systemd/system/cron.serviceは12行

>>312
今のままのinitの使い方はやめるべきだと思うな
init自体はそのままでも良いと思うんだけど、
init.dのスクリプト群にフレームワーク的な構造をを取り入れて
処理を共通化するべきだろう。そしておそらくそれはできる。
start/stop/status的なものはデフォルトで共通処理
そしてオーバーライド可能とかね
そうしないとメンテナンスが大変すぎる。

Debianをsystemdに売り渡した連中がデカイ面してるので
出ていった半数のメンテナは戻ってこない
つまりDebianが暗黒面に落ちたから*BSDへ移る用意をしておけということだ

要するに、sysvinit かなにかをデフォルトにして
「選びたければ systemd にしな」というかんじにしたい人が結構多いのかな

>>317
そんな事言っちゃっていいの？
間違いなくドライバ云々で苦労する人続出だよ

systemdってexponential backoffないのか？つらいな
デフォルトは10秒間で5回まで再起動が行うっていうけど
起動に3秒ぐらいかかってるから、10秒で5回の閾値超えないんだよな
つまり永遠に再起動を繰り返す。
ちゃんとそこまで確認して設定すりゃいいんだろうが
簡単にミスしてログでディスク枯渇してしまう

>>318
blogでどう投票したかを表明している人の内容を見てる感じ
systemd推進派とinit多様性維持派で半々ぐらいの印象
まあN=1桁だけど

systemdオンリーにする方針は
何年かしたら再考しようと誰か言い出すし
蒸し返すの禁止にも出来ないし

エラーの原因が一時的な要因（ネットワークエラー）によるものと
恒久的なもの（設定ファイル記述ミス）とで分ける仕組み無いかな
一時的なものならsystemdでリトライしてもらいたいが、
設定ミスとかリトライしたってしょうがないだろうと

つーかリトライ上限すら無いんだな

変数展開にExecStart=/bin/sh -cが広く使われてるワークアラウンドってのがダサいな
これのせいで絶対パス限定にした意味がなくなってるし

まぁ、簡単にサービスを定義できるようになったから、逆にテキトウな設定で済ませてしまう（いわゆるコピペ）開発者やメンテナが増えてしまうっていうパターンだな。
RestartPreventExitStatus とか StartLimitBurst とかいろいろ仕組みはあるから…。

どこもかしこもsystemdってことは迎合してでも採用する利点があったってことじゃないの？
古来からの文法が刷新されて一から覚え直すハメになったのは分かるけど、
だからって開発者にまで批判ってどんだけ嫌われてるのコレ
Linux版のsvchost.exeってことで色々察したけどさ
swapも最近になって専用領域からファイルに変わったけどそこまでwindowsの後追いしなくてもなぁ

不便にはなった
無理やりねじ込んできた様にしか感じない

別に不便とは思わないんだが、ユニットファイルの形式がなー

hogehoge.service.sh みたいな名前で、こんな形式の
シェルスクリプトだったら良かったのにな


description="説明"
before=
after=

exec_start() {
　起動コマンドを書く
}

exec_reload() {
　再起動コマンドを書く
}

宣言的に書くのがミソなのに
そんな書き方許したら駄目だな

>>322
まあそういうのはどういう方向に行ったとしても禁止はできない
それでも本格的にどうするのかを決めるまでにいくのはそんなに簡単でもない
今回でもMLで議論 -> Technical commiitee内で議論 -> GR という
過程を経ているし蒸し返す際にも同じ過程を踏む必要がある

で、蒸し返しの場合だったら一回GRで決まったんだからTCが否決する
可能性が高いんじゃないかな

なんでfetchmailは、ベータ版をstableに採用したんだろう
旧版はセキュリティ的に問題あったのかな

>>330
実行順がないところは宣言的でいいが
起動順が重要なところは宣言的じゃないほうが良いよ

例えばEnvironmentとExecStartPreはどちらが先に実行されるか？
こういう処理は本質的に宣言的ではない

すべてを宣言的にやろうとしすぎて逆に複雑になってる気がする

>>332
fetchmail 使えない？ うちではこんなエラーが出ている。

$ fetchmail
fetchmail: OpenSSL からの報告: error:1414D172:SSL
routines:tls12_check_peer_sigalg:wrong signature type
fetchmail: SSL による接続に失敗しました。

strech で不自由していないから、そのうち直るだろうとほっぽってあるんだが。

debian10.2のnetインストのハッシュを確認したいのですが、
相変わらずサイト構成が解りにくく、たどり着くことが出来ません。
チェックサムはどこに記載されていますか？

>>335
まずネットインストの場所を教えて下さい

isoの同じディレクトリにSHA256SUMSがあるじゃろ

>>335
そんな調子では署名の確認とかもやっていなさそうですね
改ざんされていても知りませんよ
とりあえず公式文書をお読み下さい
https://www.debian.org/CD/verify.ja.html

>>335
こことか
https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/

>>335
公認ミラー一覧
https://www.debian.org/CD/http-ftp/#mirrors

>>334
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912759
OpenSSLのsecurity levelを1に下げたら解決しそうな気がする
fetchmailrcのどこにどう書けばいいかはちょっとぐぐった限りでは
わからんかった

>>335
https://www.debian.org/　を開く
Debian を入手する　リンクを押す
インストールイメージのダウンロード　項の配下にある　64 ビット PC netinst iso　又は　32 ビット PC netinst iso　を右クリックなどしてリンク URLを取得
アドレスバーに貼り付けて isoファイル名を除いて確定
SHA256SUMS　などを押して確認するだけ
サイトは綺麗にまとまっていると思うんだけど　解釈する人によるんかな

Windows でも 7zip とかで sha256 計算できるよな

Windows のコマンドなら、7z(7-zip), certutil, PowerShell のGet-FileHash などがある

Win10ならbash動くだろ、コマンドないのか？

マウスで出来ることをいちいちコマンド打つ必要がない

「コマンド打てば出来ることをいちいちマウスいじる必要がない」という話にもなりかねず
結局やりたいようにやりゃええ

なんでWindowsの話が出てくるのかわからん

GUIの話にLinuxがでるとは誰も思わないから

Windows 環境でダウンロードファイルを検証することが
この文脈で（以下省略

署名の検証については誰も書いてくれないのですね
諸先輩方これでよろしいのでしょうか？　Debian 9上でチェック
$ gpg --verify SHA512SUMS.sign SHA512SUMS
gpg: 2019年11月17日 11時48分09秒 JSTに施された署名
gpg: RSA鍵DF9B9C49EAA9298432589D76DA87E80D6294BE9Bを使用
gpg: "Debian CD signing key <[email protected]>"からの正しい署名 [不明の]
gpg: *警告*: この鍵は信用できる署名で証明されていません!
gpg: この署名が所有者のものかどうかの検証手段がありません。
主鍵フィンガープリント: DF9B 9C49 EAA9 2984 3258 9D76 DA87 E80D 6294 BE9B

ハッシュの置き場がわかんねえとかって応用が効かねえんだよ
その数値でググれば出てきたりするもんだ

>>346
キーボードショートカットで操作しようとしたら隣から二十歳の子が手を出してきて
マウスで目にも止まらぬカーソルコントロールを見せてパパッと済ませてしまった

>>351
man 1 gpg
https://ぐぐる/search?q=gpg+公開鍵+承認
https://ぐぐる/search?=debian+iso+署名+検証
https://mevius.5ch.net/test/read.cgi/unix/1007324740

何でも人に聞く前にせめてこの位のリサーチはしておきましょう

>>354
訂正
https://ぐぐる/search?=debian+iso+署名+検証
↓
https://ぐぐる/search?q=debian+iso+署名+検証

なんでキーパンチの早い女子って
威嚇するようにでっかい打鍵音を立てるんだろう

昔は、商業高校とかで、本物のタイプライターとか和文タイプ教えてたから、
あれで覚えるとそうなっちゃうんだよね
あくまでも昔の女子の話で、今は知らない

>>357
20世紀末、パソコン教育黎明期にタイプ練習ソフトが流行したな。ソフトの名前も忘れてしまったけど

商業高校は速さを求めてローマ字入力でなくてかな入力してた。
ローマ字入力派の俺は、そいつと同じマシンを使うと、切替ないといけなくて、微妙なストレスあった。

そういや、その「女子」もカナ入力だった
商業高校でマウンティング大会でも経験したのかなあ

>>351
どこに記載されているかもわからない程度で作業状況を示していないのでは書きようがない
キーサーバーを指定しているのは自分なんだからそれを信じるしかないだろう

>>357
中大卒で電気関係行った60の母はタイプライター資格取ってたから今も英字タイプでやってるようだ
ローマ字打ちはなんか慣れないって言ってるがどう違うのか俺にはようわからん。俺よりタイピング上なのに

>>358
あったなあ(遠い目)
PC98に移植されたやつを万札出して購入して、毎日一時間練習した
元が英語用だから
the quick brown fox jumps over the lazy dog
を何度も練習した

Windows3.1が普及して特打などのローマ字入力を主流にするやつが出て
日本国からキーボードアレルギーが払拭された

apt-getって並列でインストールできるようにならないかな？

>>364
依存関係の意味わかってる？

>>364
こういう事？
https://github.com/ilikenwf/apt-fast

>>365
パッケージは全てにおいて依存関係があるわけではない
同時にインストールできる場合は多い

>>366
それはダウンロードが並列なだけ

同時インストールはdpkgが想定してないから無理
アトミックにしか動かない

並列に出来たとして早くなるかな？

シーケンシャルに実行するのに何の不満があるのだろう
debファイル手動で落として dpkg コマンドでインストールという手、とか…？


$ apt install foo bar
とか出来た気もするが…？

厨房ほどむだな速さにこだわる

dpkgのインストールで時間がかかっている部分ってほとんどがストレージのI/Oじゃない？
だから並列にしてもそんなに早くなるとは思えない
逆に遅くなるケースが多そう

並列に動かしたいと言うのが速さのためではなく単に処理中でも他から同時に実行できるようにしたいってことかも知れないが

速度も速くなるだろうけど、それはどうでもいいよ
本来個々のパッケージのインストールは独立しているわけだから
並列してインストール可能なはずだろ？

例えばセキュリティアップデートが自動更新されてるときに
別のパッケージを手動でインストールするとかあるわけじゃん？

今は別のプロセスが処理してるからとか言ってエラーが出るけど
全体にロックを掛けるんじゃなくて、必要な部分だけ排他制御を
きちんとやっていれば、エラーなくインストールできるはず

少なくとも他のOSだとエラーになることはないよね

連携性・構成力・統一性の無さはOSSならではｗ 受け入れるしかない

>>373
パッケージのインストールはファイルの
コピーするだけではないので
並列動作の安全性の保証は簡単じゃない

Windowsのアップデートなんかほとんど再起動要請されて
その中途で置き換えてんじゃねえの

>>373
なんなら自分でこさえなよ
dpkgでの動作検証出来てるんでしょ？

>>377
設計レベルで見直さないといけないから大変だよ
一番厄介なのはパッケージインストールやアンインストール時に実行されるフック
何が行われるのかわからないからパッケージマネージャーだけの頑張りだけでは実現不可能
そういうのをきっちり何に依存するのかしないのかをメタデータで定めて
パッケージ間の独立性を明確にし、どうしても依存する部分は部分的にロックを掛ける仕組みが必要
たいていは独立してインストール可能だと思うけどね。特にサービスではないものは。
一部の例外が大変なんだよ。一筋縄ではいかないから、ここでできないなーってぼやいてる

>>373
エラーが出ない他のOSってなに？
俺の知る限りではWindowsもMacOSではインストール中のインストールは出来ないと思うが。

>>379
こんな感じで同時にインストールできるようになってるよ

https://snow-white.cocolog-nifty.com/first/2018/07/office-3432.html
https://snow-white.cocolog-nifty.com/first/Open-Live-Writer/810c34d5b394_12BBF/image_c413fc2d-074e-4edd-8e77-1b54fee0d470.png

ストアアプリはパッケージマネージャ以前にベースの仕組みが全く違う。

どこまで理解してから話してるのか分からないから
釈迦に説法だったらごめんだけど、
それが唯一の根拠だとしたら
ストアアプリがどういうものか、なんで並列インストールができるのか、
ちょっとググってきたほうがいい。

ぶっちゃけ、ちょっと恥ずかしい主張になっちゃってる。

>>381
そいで、何が言いたいのさ？ｗ

>>382
>>381はいい人だから遠まわしにお前に馬鹿引っ込めと言ってくれてるんだよ
わからないやつは親切に言われてもわからないということが証明されたね

>>383
いや、それ単なる嫌がらせじゃんｗ

恥ずかしいと、お前は恥ずかしいんだ！っていうだけで
その根拠を何も示せない。

説得力って言葉知ってる？

でも、もしそんな常識を覆す実装が実用に耐えうる形で実現したら素敵だね
俺の様なパーには無理な話だが

>>380
https://quickfix.es/wp-content/uploads/2018/03/updatediscover.png
KDEのDiscoverシステム眺めてれば？

https://i.imgur.com/S0lL5VU.png
JDで読めるように再

なんで全部5,1MBなんですか？