アカウント名:
パスワード:
ローリングリリースをするからRHELが8→9→10・・と進むとCentOS Streamは勝手にそれに追随しちゃうって認識だけど、これがキツイ。アップデートをかけたら従来はマイナーバージョンレベルしか更新されなかったのがその範囲を越えちゃう。
OS準拠のパッケージ以外にアプリを入れた場合に、その動作保証が問題だよなぁ。。。サポートする側の動作保証の範囲が広くなりすぎてサポート外としか言いようがないだろうし。
もともとそもそも、CentOS 8も、7以前とは違い、アプリケーションのアップデートも積極的に行っていくっていう方針だったと思う・・・と思って調べたらAppStreamという概念が加わったのがそういうことみたいだがな。つまりCent 7以前は、そもそも例えば設定ファイルが大きく変更されたり、機能の追加・削除がされるような、パッケージの更新はされることはなかった。RedHatが、パッケージのソフトウェアの変更の中でバグ修正やセキュリティアップデートパッチだけを適用してきていたわけだが、CentOS 8のAppStreamはそうではなく、アプリケーションも時々アップデートされる。
ただ、そのAppStreamってのが実際どういうものかを見る前に、CentOS 8の終了が決まっちゃったからな。実際、AppStreamでのパッケージのアップデートで非互換の変更が入ってから阿鼻叫喚するはずだったところが事前にわかった、ということではないのか?
AppStreamは(初期の)デフォルトより新しいバージョンも(選択的に)インストールできる枠組みであって、無条件で新バージョンに移行する枠組みじゃない。確かに個々のバージョンへのセキュリティパッチ適用はそのアプリの定めるメンテナンス期間しか受けられないが、メンテナンスモード状態の既存バージョンを使う選択肢が残される。また、AppStreamに対応しているモジュールはRHEL8/CentOS8ではまだ50個に満たない。この数ならサポート期間が切れるまでに次期バージョンの検証などもできないことはないし、最悪サポート期間が切れても別バージョンの検証の検証が終わるまでサービスが止まることもない。
でも、ストリームのローリングアップデートはOS全体のバージョンが大きく変わってくるからもっと大変。それにAppStreamの保持期間もRHEL/CentOSのメジャーバージョンのライフサイクルまでなので、それらの強制アップデートも発生する発生しそう。
だから、やっぱりStreamのローリングアップデートとRHEL8/CentOS8のAppStreamを同一視するべきじゃない。
>つまりCent 7以前は、そもそも例えば設定ファイルが大きく変更されたり、>機能の追加・削除がされるような、パッケージの更新はされることはなかった。
7のgnome-shell のベースバージョンが複数回上がっているので、GNOME環境のアップデートに度々失敗するとか、rsyslogやsambaでもベースバージョンが違う物が出てましたね。
どんどん「塩漬け」システムを作る人には使いにくいOSになってきたようですね。
それを許す事で何時までも脆弱性パッチ当てないやつをネット大公開するような輩産むようになったからだね。
RHEL7までは、とっくにコミュニティのサポートが終わってるOSSをRedhatが頑張ってパッチ出し続けてたけど、流石にやってられんってなったんじゃないのかな? > AppStream
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
ローリングリリースがキツイ (スコア:0)
ローリングリリースをするからRHELが8→9→10・・と進むとCentOS Streamは勝手にそれに追随しちゃうって認識だけど、これがキツイ。
アップデートをかけたら従来はマイナーバージョンレベルしか更新されなかったのがその範囲を越えちゃう。
OS準拠のパッケージ以外にアプリを入れた場合に、その動作保証が問題だよなぁ。。。
サポートする側の動作保証の範囲が広くなりすぎてサポート外としか言いようがないだろうし。
Re:ローリングリリースがキツイ (スコア:0)
もともとそもそも、CentOS 8も、7以前とは違い、アプリケーションのアップデートも積極的に行っていくっていう方針だったと
思う・・・と思って調べたらAppStreamという概念が加わったのがそういうことみたいだがな。
つまりCent 7以前は、そもそも例えば設定ファイルが大きく変更されたり、機能の追加・削除がされるような、パッケージの更新はされることはなかった。
RedHatが、パッケージのソフトウェアの変更の中でバグ修正やセキュリティアップデートパッチだけを適用してきていたわけだが、
CentOS 8のAppStreamはそうではなく、アプリケーションも時々アップデートされる。
ただ、そのAppStreamってのが実際どういうものかを見る前に、CentOS 8の終了が決まっちゃったからな。
実際、AppStreamでのパッケージのアップデートで非互換の変更が入ってから阿鼻叫喚するはずだったところが事前にわかった、ということではないのか?
Re:ローリングリリースがキツイ (スコア:1)
AppStreamは(初期の)デフォルトより新しいバージョンも(選択的に)インストールできる枠組みであって、無条件で新バージョンに移行する枠組みじゃない。
確かに個々のバージョンへのセキュリティパッチ適用はそのアプリの定めるメンテナンス期間しか受けられないが、メンテナンスモード状態の既存バージョンを使う選択肢が残される。
また、AppStreamに対応しているモジュールはRHEL8/CentOS8ではまだ50個に満たない。この数ならサポート期間が切れるまでに次期バージョンの検証などもできないことはないし、最悪サポート期間が切れても別バージョンの検証の検証が終わるまでサービスが止まることもない。
でも、ストリームのローリングアップデートはOS全体のバージョンが大きく変わってくるからもっと大変。
それにAppStreamの保持期間もRHEL/CentOSのメジャーバージョンのライフサイクルまでなので、それらの強制アップデートも発生する
発生しそう。
だから、やっぱりStreamのローリングアップデートとRHEL8/CentOS8のAppStreamを同一視するべきじゃない。
Re: (スコア:0)
>つまりCent 7以前は、そもそも例えば設定ファイルが大きく変更されたり、
>機能の追加・削除がされるような、パッケージの更新はされることはなかった。
7のgnome-shell のベースバージョンが複数回上がっているので、
GNOME環境のアップデートに度々失敗するとか、
rsyslogやsambaでもベースバージョンが違う物が出てましたね。
どんどん「塩漬け」システムを作る人には使いにくいOSになってきたようですね。
Re: (スコア:0)
それを許す事で何時までも脆弱性パッチ当てないやつをネット大公開するような輩産むようになったからだね。
Re: (スコア:0)
RHEL7までは、とっくにコミュニティのサポートが終わってるOSSをRedhatが頑張ってパッチ出し続けてたけど、流石にやってられんってなったんじゃないのかな? > AppStream