「Debian Project、次期リリース「Bullseye」で使用するアートワークの人気調査を実施」記事へのコメント

そんなことより

[Anonymous Coward]

強制仕様変更をstableに導入する是非を
投票で決めて欲しいと思われ

udev、systemd、nftable、etcc...
どんだけえらい目にあってきたか。。。

dist-upgrade時に選択枝出れば阿鼻叫喚も減るのに

# source.listでstableにしてると泣きを見るDebian

Re:そんなことより

[Anonymous Coward]

devfs → udev
一回設定すれば終わる話。言うほど影響ない。
こんな程度で困っていたらglibcのアップデートひとつままならない。

 

iptables → nftables
ip(6)tablesバイナリがxtables-nft-multiへのsymlinkになるだけ。
これまで通りiptables使っていても裏でkernelがコンバートしてユーザーランドでnftが処理してるだけの話。
そもそもnftスクリプトをまともに書ける奴自体が少なく、またfirewalldからsanewall、shorewallまで、
結局裏でiptables-nftでコンバートしてるだけなので、素人が心配するようなことは何も起きない。
自らnftスクリプトを書く段階になってようやく、それまでのiptalbesとの作法の違いに戸惑うだけ。

 

init → systemd
systemd自体が複数機能の集合的存在なので、これはかなりヤバイ。
素人はinit用のシェルスクリプトとsystemd.serviceの制御構文や挙動の違いだけを問題にしたがる。

が、systemdは泥んこ玉なので、先週のsystemd 247のRCリリースからもわかるように、
systemdにsystemd-homedとsystemd-oomdが増えたよ。やったねたえちゃん。
みたいなことが頻繁に起きる。
今使ってるsystemdとアップデートするsystemdで、一体なにがどう変わったのかを事前に把握せずアップデートしたりすると死ねる。

またsystemd-journaldは機能不足にもほどがあるからrsyslogに転送させてElasticsearchできるようにしとこうとか、
systemd-timesyncdはPTPやPPSも満足に捌けないから代わりにchronyd使ってましたとか、
そういった自分勝手な真似をしてるとアップデート後にsystemdの残党どもが余計なこと始めてて死ねる。

Debはsystemdでなくcron使う派なのであまり問題にならないが、Archとかだとcron使わずsystemd.Timer使う派なので、
アップデートと共に裏で勝手に*.timerが登録されてたりして、それに気づかないと余計こと始められてこれまた死ねる。

等々。
systemdは基本的に、出来合いのものを出来合いのまま単純に利用してる時は問題ないが、そういった枠からはみ出ると途端に牙を剥く。
アップデートではなくクリーンインストールを念頭に、余計なカスタマイズを施さず、
ディストリ出来合いのものを、出来合いのまま単純に使うだけの素人だけが何の問題も起こさず使用することができる。
それを素人がdist-upgradeして使い続けようなんて考えたら苦労するのは必然。