Ubuntu 22.10はGNOME 43ベースで構築されている
日本時間の10月21日午前4時に、Ubuntuの最新版である 「Ubuntu 22.10(Kinetic Kudu)」 がリリースされた。今回はこの22.10の概要と、アップグレードすべきかどうかの判断、そしてUbuntuのリリースプロセスについて解説しよう。
細かな機能修正にとどまったUbuntu 22.10
Ubuntuは半年ごとに最新版を出す「タイムベースリリース」を採用している。そのためリリースによっては大きな機能追加は行なわれず、小幅なアップデートにとどまることもある。どちらかと言うと、Ubuntuそのものの新機能よりも、各種ソフトウェアのバージョンが最新版に更新されることのほうが重要だったりするのだ。
今回のUbuntu 22.10も細かいところでいろいろ機能が追加されてはいるものの、「ビッグジャンプ」と言えるものはほぼ存在しない。その代わり、将来のリリースに向けて少しずつ準備を始めているものが多い状態だ。簡単にいくつかの新機能を紹介しよう。
Ubuntuのデスクトップ版はデスクトップ環境である「GNOME」をベースに構築されている。よってデスクトップ関連の新機能となると、そのUbuntuのリリースで採用されたGNOMEのバージョンの新機能でもあることが多い。Ubuntu 22.10では、おおよそGNOME 43ベースの環境となっている。「おおよそ」と言うのは完全にGNOMEと同じではなくUbuntuの都合に合わせていくつかのバージョンや機能を調整しているためだ。
さて、GNOME 43での変更点での大きなところは「クイック設定メニュー」と「Adaptiveデザイン」だろう。 クイック設定メニュー は、画面右上のボタンを押したときに表示されるメニューの改善だ。これまではドロップダウン的に各種メニュー項目が統合されていたが、新しいGNOMEではよりタッチパネルでも操作しやすいようにボタンライクな設定になっている。
さらにこれまで、サウンドデバイスの切り替えには設定アプリを立ち上げる必要があったが、これもクイック設定メニューに統合された。複数のマイク/ヘッドセット/スピーカーを切り替えて使いたいユーザーにとってはうれしい機能だろう。
ウィンドウサイズに応じた適切なレイアウトに対応した
Adaptiveデザイン は、いくつかのウィンドウサイズに合わせてレイアウトを調整する仕組みだ。レスポンシブデザインほど柔軟性は高くないが、その分シンプルでかつ使いやすくレイアウトできる利点がある。またGNOMEは現在、UIツールキットであるGTK4へのバージョンアップを行なっている。これによりいくつかのソフトウェアは内部的にいろいろな作りが変わっている。
Ubuntu固有の話としては、標準のGUIテキストエディタが高機能な「Gedit」からGNOME標準の 「テキストエディター」 へと置き換わっている。Geditは最初からインストールされなくなっただけで、あとからパッケージ管理システムでインストール可能だ。ちなみにGNOMEはプロジェクトの方針として、各種アプリケーションの名前は一般名詞化している。ファイルブラウザ(Windowsで言うエクスプローラー)は「ファイル」だし、ストレージ管理ツールは「ディスク」、ターミナルアプリは「端末」と言った具合だ。これは初心者向けの対応ということになっているが、実際に説明する側からするとわかりにくいことこの上ない。
GNOMEの新しいテキストエディター
他にもサウンドバックエンドがPulseAudioから PipeWire に変わっている。普通に使う分には気にしなくて良い変更ではあるが、サウンド関係で細かな設定を行っている人は注意しよう。
サーバー向けだとインストーラの機能が大きく追加され、SSHサーバーがsystemdのソケットアクティベーション機能を使うようになった、Raspberry PiやRISC-Vサポートの拡充などなど、ほかにもいろいろな更新がある。また、Linuxカーネルが5.19に更新されたことで、Intel CPUを採用したラップトップの電力消費や、描画周り改善、LenoveのThinkPadトラックポイントキーボードのカスタマイズ性の向上、ワコム製デバイスのサポート拡充などなど、さまざまなデバイス向けの改善が行なわれた。カーネルに関しては将来的にUbuntu 22.04 LTSでもHWEカーネルとして5.19に更新予定なので、LTSのユーザーもそのうちこれらの恩恵に預かれることだろう。
22.04からアップグレードすべきか？
現在、Ubuntu 22.04 LTSを使っているユーザーは、即座にUbuntu 22.10にアップグレードすべきかと問われると、 「よっぽどの理由がない限り、アップグレードしないことを推奨する」 となる。
これは主にサポート期間が理由になる。Ubuntu 22.04 LTSは「長期サポート版」だ。つまり5年間のセキュリティアップデートが保証されているし、第13回の「Ubuntuの商用サポートと無償でも使えるKernel Livepatch機能」で紹介したUbuntu Proを使えば、10年間利用可能だ。それに対してUbuntu 22.10は通常リリース扱いとなり、サポート期限は来年の7月となる。かなり短いのだ。22.10にアップグレードした場合は、来年(2023年)4月にリリース予定のUbuntu 23.04がリリースされたら、すぐにでもアップグレードすることが推奨される。
それでも22.10へアップグレードすべきユーザーとなると、主に次のような理由を持っている場合に限られる。
- 新しいハードウェアが、新しいバージョンのUbuntuでしか動かない
- 新しいバージョンのUbuntuで提供されている新しいソフトウェア・バージョンを使いたい
- 次のLTSに向けて機能/不具合の調査を行ないたい
- Ubuntuの開発者
1番目の理由は主にカーネル側の理由に由来する。たとえば新しいCPU、新しいGPUなんかは新しいカーネルのほうが安定して動くことは多い。ただしLTS版のUbuntuは ポイントリリース として新しいUbuntuで使われたカーネルに更新されるため、1カ月から2カ月のタイムラグを許容できるなら、LTSを使い続けたほうが安全だ。
2番目については、[第5回]でも少し説明したように、Ubuntuはあるバージョンをリリースしたあと、そこの含まれるパッケージのバージョンは更新されない。たとえば22.04で採用されたVimのバージョンは8.2.3995となる。だが、その後Vimのバージョンは9.0系になっているが、22.04向けの公式パッケージとしては用意されない。もしより新しいバージョンを使いたいなら、自分でビルドするか他人がビルドした非公式のパッケージを使うか、より新しいUbuntuのリリースを使うしかない。
3番目と4番目は、積極的に最新版を使って問題点を洗い出したり、UIの翻訳を行なってくれるユーザー向けの理由だ。積極的に最新リリースや開発版を利用し、問題点を報告してくれるあなたのようなユーザーがいるから、Ubuntuの品質が保たれている。本当に感謝しかない。
ちなみにLTSから通常リリースへのアップグレードは、通常は無効化されている。どうしてもアップグレードしたい場合は、「ソフトウェアとアップグレード」アプリを起動し、「アップデート」タブの「Ubuntuの新バージョンの通知」を「長期サポート(LTS)版」から「すべての新バージョン」に変更しておこう。
すべての新バージョンにしておかないとLTSから通常バージョンへのアップグレード通知は行なわれない
当然のことではあるのだが、 アップグレードする前には必ずリリースノートを読もう 。Ubuntuのリリースノートは単に新機能の紹介だけでなく、「そのリリースを使う上での注意点」が書かれている。具体的には 「このデバイスでアップグレードするとシステムが破壊される」 とか 「特定のノートPCだと画面が表示されなくなる」 とか、そういうクリティカルなものもしれっと書かれているのだ。基本的にそうそう問題になることはないため神経質になる必要はない。必要はないのだが、だいたいにおいてリリースノートを読まなかった時に限って、とんでもない既知の不具合を踏んでしまうのが世の常だ。心の安心を得るためにも、常にリリースノートは読むようにしよう。
ちなみにリリースノートの途中から「s390x」というメインフレームの話がひたすら出てきて心が折れかけるかもしれない。s390xの話が影響するユーザーはごく僅かなので、安心して読み飛ばして欲しい。
また、アップグレード中はインターネット経由でUbuntuのパッケージリポジトリと通信する必要がある。よってネットワーク回線と時間的余裕が潤沢な状態で実行しよう。ちなみに「日本の公式ミラー」については、普段は何も問題なく使えるのだが、たまに特定の日本の大企業が大量にアクセスを試みて、負荷が上昇し応答が悪くなることを観測している。明らかに反応が悪く、全然進まなくなったのなら時間をおいてリトライしてほしい。
Ubuntuのリリースプロセス
せっかくの機会なので、ここからはUbuntuのリリースプロセスについて説明しよう。
Ubuntuは「タイムベースリリース」を採用している。これは最初からリリース日を決めておいて、リリース日になれば 多少の不具合があってもリリース後に直す前提でリリースする スタイルのモデルだ。これだけだと、適当なリリーススタイルに見えるかもしれないが、実際のところは最初からスケジュールを立てて、それに対して大きくずれないようにマネジメント、新機能の取捨選択を行ないながら開発を進めていく必要があるため、プロジェクトとしてのマネジメント力が非常に問われる。
そもそもいくら合理性を尊び真面目な人が多いIT技術者とは言え、夏休みの宿題を新学期直前に片付けられるなら、まだ良いほうだ。むしろ新学期になってからが本番と言うタイプも多いかもしれない。締切なんてものは破るためにあるのだ。そんな考えの人たちをなんとかおだてて、なだめすかして、叱咤し、半年ごとのリリース日を20年近く守ってきたのだから、こうしてみるとかなりすごいことだと思えてくるだろう。え、Ubuntuって登場してからもう20年近くになるの!?
さて、Ubuntuの開発は前リリースの開発終了とともに開始する。つまり22.10がリリースされた10月は次の23.04の開発開始のタイミングでもあるのだ。開発開始にあたってもっとも重要な儀式、それが コードネームの決定とそのアナウンス だ。
Ubuntuは伝統的に開発コードネームをアルファベット順とし、「形容詞 生物名」というスタイルを取っている。アルファベット順というのは、コードネームからリリースの前後関係が分かりやすく、OpenStackやAndroidでも同じようなルールが採用されるようになった。Ubuntuの場合、最初数リリースはアルファベット順ではなかったのだが、2006年にリリースされたUbuntu 6.06 LTS(Ubuntu史上唯一2カ月遅れのリリース)から、アルファベット順が維持されている。
22.10は開発を開始する2022年4月に 「Kinetic Kudu(動的なクードゥー)」 として発表された。つまり次のリリースである23.04は(コードネームが決まるまでは「kinetic+1」みたいに表示されることが多い)は、「Lxxx Lxxx」となる。ちなみに23.04のコードネームについては、先日 「Lunar Lobster(月のロブスター)」 となることがアナウンスされた。
このコードネームは単に象徴的な名前であるだけでなく、リポジトリのURLやパッケージ情報等でも使われるため、開発開始にあたって必要な情報なのだ。以前はUbuntuの創設者のマーク・シャトルワースが、自身のブログの中でコードネームの由来を、難解な英文で解説するのが定番ではあったが、最近はプロジェクト内部で決まったものがさらっとアナウンスされるだけにとどまっている。
コードネームが決まれば、リリーススケジュール等の作成が行なわれる。ものによっては多少前後するが、リリースまではおおよそ次のような流れになる。4月リリースのものと10月リリースのものを両方併記している。
| Ubuntuの開発スケジュール | |
|---|---|
| 10月後半・4月後半 | ビルドシステムの準備・コンパイラのバージョンアップ |
| 2月中旬・8月中旬 | Feature Freeze |
| 3月中旬・9月中旬 | UI・ドキュメントフリーズ |
| 3月下旬・9月下旬 | ベータリリース |
| 4月上旬・10月上旬 | カーネルフリーズ |
| 4月中旬・10月中旬 | 最終フリーズ・RCリリース |
| 4月下旬・10月下旬 | リリース |
順番に見ていこう。まず、最初に開発用のリポジトリおよびLaunchpad上のプロジェクトが作られる。Ubuntuの場合、開発の単位は「パッケージ」だ。あるパッケージのバージョンを新しくする、あるパッケージの不具合を修正する、新規のソフトウェアのパッケージを作る、そんなことを開発期間は繰り返していく。パッケージはリポジトリ上にあるリリースごとのディレクトリに紐付いている。つまり特定リリース向けのパッケージを作るためには、特定リリースのリポジトリが必要になるのだ。それをまず最初に用意する。
また、特定のリリース向けにパッケージをビルドする際に、どのバージョンのコンパイラやライブラリを使うかもあらかじめ決めておく。GCCについては開発初期に決定するが、それ以外のビルドツールについては開発途中のどこかで決めて、一気に移動することもある。いずれにせよ比較的初期に決めておく必要がある。
リポジトリの準備が整ったらパッケージのバージョンをあげていく。これには次の手順が存在する。
- Sync：Debianリポジトリの最新バージョンをそのまま同期し、Ubuntu側で再ビルドする
- Merge：Debianリポジトリの最新バージョンと、Ubuntu側の既存の修正をマージして、Ubuntu側で再ビルドする
- Upgrade：Ubuntuリポジトリにしかないパッケージのバージョンを更新する
- New：これまでUbuntuリポジトリに存在しなかったソフトウェアを新規にパッケージングする
現在ではSyncはほぼ自動化されている。ただし複雑な依存関係を持ったものは都度対応することはある。よってUbuntuの開発者は上記のいずれかを開発期間中に繰り返していく。開発期間がおおよそ半分経過すると「Feature Freeze」フェーズに入る。ここから先は新規機能の追加はやめ、不具合修正をメインにしようというフェーズだ。パッケージのバージョンをあげる場合はある程度のプロセスを経る必要が出てくる。
ただしUbuntuの場合は、 Feature Freezeになってからが新機能投入の本番 になることが多い。単純に開発期間の前半は燃え尽きていたりとか、開発そのものが時間かかっているとか、いろいろな事情が絡んでいる。よって大きめの機能については、Feature Freeze後に調整して投入されるのが近年のトレンドだ。たまにリリース直前に取り込まれて物議を醸すこともある。
UI・ドキュメントフリーズは、どちらかと言うとUIの翻訳向けの対応になる。UIのメッセージがころころ変わってしまうとそれを翻訳する側の追随が難しくなる。よって特定の時期以降にUIを変更する場合は、翻訳チームに連絡を取り、変更の許可を得なければならない。
リリースの1カ月前にはベータ版がリリースされる。またベータ版の1週間前には一旦リポジトリを凍結し、パッケージのアップロードにあたってはリリースチームによるレビューが入る。ベータ版はより広くテストを依頼するためのポイントとなる。Ubuntuの場合は、インストール用のISOイメージを毎日ビルドし・公開している( デイリーイメージ )。そのため、単に最新のテスト版をテストしたいだけならこのデイリーイメージを使えばいいのだが、「ベータリリース」と明示することで、テストしてくれるユーザーを増やすのが目的だ。
リリースの半月前にはカーネルパッケージの更新を止めるカーネルフリーズが行なわれる。移行は不具合対応で必要な場合のみに更新される。ちなみにカーネルのベースバージョン自体はもっと前に決めることになる。たとえば22.10では2022年7月にリリースされたKernel 5.19を採用している、その後、2022年6月にKernel 6.0がリリースされているが、これはUbuntu 22.10に取り込むにはリリース時期が遅すぎるために見送られた。
リリースの1週間前になるとリポジトリのフリーズが行なわれる。これ以降、パッケージの更新にあたってはリリースチームのレビューと承認が必要になる。同時に1週間前から、最新のビルドが「リリース候補版」となる。不具合が見つかったら、パッケージを修正し、再度イメージを作り直す。今度はそれがまた「リリース候補版」となる。それをリリースまでの1週間続けるわけだ。テスト内容はQAチームのサイトなどで管理される。
リリースイメージのテストはQAチームが主体となって実施しているが、もちろんQAチーム以外が実施しても構わない。もし致命的な問題を見つけたら積極的に報告しよう。まずはLaunchpad上で不具合を報告すると良いだろう。まずは不具合かどうか相談したいということであれば、メーリングリストやフォーラムに咆哮するという手もある。
リリーススケジュールに影響する不具合は「リリースクリティカルバグ(RC bug)」として扱われる。最終的には 「リリースまでに修正する」 か 「リリースノートに記録し、リリース後に修正する」 かをリリースチームが判断を下す。このあたりはいずれもオープンな場で状況が見えるので、リリースまでの「わちゃわちゃ感」を眺めるのも楽しいかもしれない。
最後に 「リリースアナウンス」 がアナウンスされたらリリース完了だ。ちなみにリリースに先立って、リリース候補版の最終イメージが正式版となり、アーカイブサーバーに配置される。同時に各地域のローカルミラーにも配信される。たまに「アーカイブサーバーにイメージが登場したらリリース」と先走る人も居るが、 公式のリリースアナウンスが出るまではまだリリースされていない ので注意しよう。イメージを配置したけれども、やっぱりダメだったので差し替える、なんてこともごく稀にあるのだ。
リリースアナウンスはアナウンス用のメーリングリストやアナウンス用のフォーラムで行なわれる。Ubuntuのリリース状況を追いかけたい人は、フォローしておくと良いだろう。
コメント