web-dev-qa-db-ja.com

Ubuntu LTSの安定性

tl; dr：Ubuntu LTSはライブラリをAPI要素を変更/削除できるバージョンに更新しますか？

Debian安定版は新しいハードウェアをサポートするためにカーネルにパッチを適用していないため、組織の新しいラップトップがDebian安定版を実行するにはあまりにも新しいという問題に遭遇しました。 Debianの請負業者を雇って、バックポートされたカーネルでインストールCDを作成しましたが、1週間後、彼はそれを作成することができませんでした。

今、会社をUbuntu LTSに移行することを検討せざるを得ません。しかし、私は次の悪夢で睡眠を失います：

  • 顧客向けの大きなデモの数日前の早朝に仕事に着きます。
  • 時間があるのでapt upgrade。
  • 後Yを押すqt5-defaultが5.9.5から5.10.0に増加したことに気付きました。
  • APIが変更されたことを確認するためだけにプロジェクトをコンパイルします。
  • 私たちのチームは、適応するためにコードを書き直すのに約2週間必要です。
  • デモを見逃し、入札を失います。
  • 会社は破産し、私たち全員が職を失います。

Debianでは、単に更新されないため、この心配はありません。セキュリティパッチのみを取得します。悲痛なトレードオフは、新しいハードウェアがサポートされていないことです。 Debian安定版のリリース前に製造されたラップトップのみを注文するOEMのような手段がないため、別のソリューションが必要です。

buntu LTSクレーム 「ポイントリリース」のみを実行します。 カーネル履歴16.04 を見て、その意味を理解すると、カーネルが4.4から4.15に更新されたことがわかります。これは、Ubuntuがメジャーリビジョンを増やしたくない場合があることを示していますが、areマイナーリビジョンを増やしたいと考えています。

libboostから1.67.0から1.67.1への更新に問題はありませんが、1.68.0への更新が怖いです。

Ubuntu LTSが逆互換性のないパッケージをアップグレードしないと確信できますか？

Ubuntuの安定性に自信がない場合は、次の回避策が考えられますが、提案は歓迎します。

  1. apt-mark hold <package>は特定のパッケージのアップグレードを防ぎますが、
    1. 依存関係の手動管理には時間がかかります
    2. これを全社的に管理する必要があります。
  2. 開発は、debian安定版を実行しているchroot環境で実行でき、デスクトップ環境から開発環境を分離できます。
package-managementupgradelts
3
Stewart

Ubuntu LTSを更新しても、カーネルバージョンはアップグレードされません。セキュリティパッチのみが適用されています。
現在のLTSリリースは bionic です。
Ubuntu 18.4.1（26.4.2018）

LTSリリースの自動カーネル更新は、ハードウェア有効化スタックのみで有効になります。


Ubuntu Kernel Release Shedule
ここでは、HWEが有効になっていない限り、LTSでカーネルのアップグレードが行われていないことがわかります。

Ubuntu Kernel Release Shedule

Ubuntu LTS Kernel Support Shedule
セキュリティパッチのみが実装されていることがわかります。

Ubuntu Kernel Support Shedule

Ubuntu LTSは、ライブラリのAPI要素を変更/削除できるバージョンに更新しますか？
答えはノーです。

Ubuntu LTSは、逆互換性のないパッケージをアップグレードしないと確信できますか？
答えはイエスです、できます。


Debian安定版にも同じことが当てはまります。
現在の安定版リリースは stretch です。
Debian 9.5（2018年14.7.19リリース、2022年までサポート）

Linuxでの開発
企業環境でのソフトウェア開発のベストプラクティスは、仮想マシンを実行することです。そのため、snapshotsで作業を簡単に保護できます。

例
Qubes OS はセキュリティ指向のオペレーティングシステムであり、仮想マシン（および templates 、を含むdebian）XENハイパーバイザーを使用（ 代わりに of KVM仮想化）

Qtを使用していて、更新を防ぐ必要がある場合は、setUpdatesEnabled(false);を試して、更新を有効にするsetUpdatesEnabled(true);

3
Tomáš Pánik

Ubuntuカーネルの番号付けはLinuxとは異なります

で検索4.13.0-26を使用してUbuntuに問い合わせると、2018年1月から101の質問と回答が見つかります。その時点でリリースされているLinuxカーネルバージョンはLTSカーネル4.14チェーン用。

buntu Mainline Kernel downloads を見ると、2018年1月にLinux Kernel Teamによって4.14.11から4.14.17（7つのカーネル更新）がリリースされました。また、2018年1月のリリース候補カーネルは4.15.rc6から4.15.rc9（4つのカーネル更新）でした。

2018年1月、Linux Kernel Teamによって、SpectreおよびMeltdown Predictive Branchingの理論上のメモリリークについて、カーネルの主要な改訂が行われました。次に、Ubuntu KernelチームはコードをUbuntu Kernel 4.13.0-xxチェーンにすばやく移植しました。

ABI/APIの変更の追跡

ABI Labratory から、最後の変更が2018年6月4、5、6日にあったことがわかります。

Linux ABI changes.png

2018年6月に改訂されたLinux Kernelの数値は次のとおりです。

  • 4.14.48、4.9.107および4.4.136すべての6年LTSカーネル

対応するUbuntu Kernelバージョン番号はおそらく：

新しいハードウェアのサポートまたは既存のハードウェアのバグ修正がリリースされたら、Linuxカーネルをアップグレードする必要があります。 ABI/APIの変更が関係する場合、Ubuntuカーネルが機能する場合と機能しない場合があります。 ABI/APIの変更が行われなかったとしても、Ubuntuカーネルは他の理由で一部の人にとっては壊れる可能性があります。

新しいLinuxカーネルのバージョン番号とUbuntuカーネルのバージョン番号の相関関係を見つけることは、部外者にとって非常に困難です。 Ubuntu Kernel Teamから最新のニュースレターを取得 2017年6月6日のニュースレター ABI/APIの1年前上記の変更：

Kernel Versions
====================================================================
         precise  3.2.0-126.169
          trusty  3.13.0-119.166
           vivid  3.19.0-84.92
          xenial  4.4.0-78.99
         yakkety  4.8.0-53.56

linux-lts-trusty  3.13.0-117.164~precise1
 linux-lts-vivid  3.19.0-80.88~14.04.1
linux-lts-xenial  4.4.0-78.99~14.04.1

その期間（2017年6月7日）の 対応するLinuxカーネルのバージョン番号 は、3.2.89、3.10.105、3.16.44、3.18.56でした。 、4.1.40、4.4.71、4.9.31、4.11.4、および4.12-rc4。

クローニングと機能テスト

眠い月曜日の朝にアドホックSudo apt upgradeではなく、自動化されたクローン作成、アップグレード、機能テストを検討できます。

  1. 午前0時にジョブを実行して、16.04または18.04をテストに複製しますパーティション： 18.04 LTSアップグレードをテストするためにUbuntuを新しいパーティションにクローンするためのBashスクリプト
  2. クローンを作成したら、cron再起動スクリプトが作成され、Sudo apt upgradeを実行してテスト機能を実行します。
  3. クローン作成後、grubの再起動がクローンバージョンに対して呼び出されます。 Grub：特定のカーネルへの再起動
  4. クローンが再起動されると、cron再起動スクリプトが無人アップグレードとユニットテストのために実行されます。
  5. ユニットテストでは、すべてのライブラリバージョン番号を既知の番号と比較し、バージョン番号が未テストの番号に更新された場合はメールで通知する必要があります。
  6. 単体テストでは、既知のすべての関数を呼び出して、テストパラメーターを渡し、戻り値と期待される結果を比較します。不一致があればメールでお知らせします。
  7. ユニットテストスクリプトが完了すると、最終結果をメールで送信し、grubを設定してライブ環境に再起動してからシャットダウンします。
1
WinEunuuchs2Unix