2019年のUbuntu

2018年のUbuntuは，18.04 LTSのリリースや，18.04 LTSへの10年サポートの提供のアナウンスが行われる等，派手さはないものの着実な変化が生じた一年でした。

2019年はUbuntuとしては20.04 LTSに向け，19.04と19.10がリリースされる予定の年です。「⁠LTSの前」のリリースは実験的な新機能が数多く投入されるため，激しい変化がもたらされる可能性があると同時に（注1）⁠，Ubuntuを取り巻くコンピューティング環境にドラスティックな変化がもたらされる年となる可能性もあります。業界そのもので見ると，これまでの常識のうちのいくつかが書き換わる年になる可能性がある，ということです。

今回は，『⁠2019年のUbuntu』として，今年のUbuntuそのものの開発の動向や，Ubuntuに影響しうる事柄について（一部妄想を交えて）見ていきましょう。

注1

LTS前の駆け込み新機能投入による混乱（と，新機能投入のスリップによる平穏なリリース）はUbuntuにとっては定例行事的だ，という考え方もあります。

Ubuntuそのものの変化・32bit（i686）との決別

2019年に予想されるUbuntuのもっとも大きな変化は，32bit（i386/i686）サポートの終了でしょう。すでに18.04 LTSから18.10へのアップグレードは抑制されており，「⁠18.04 LTSが最後の32bitリリースとなる」路線はほぼ確定した状態にあります。

現実問題として，AMD64/Intel 64命令セットを実行できないCPUは事実上無視してよく（注2）⁠，x86バイナリと併用する（注3）場合に発生するメモリやストレージフットプリントの肥大以外，大きな問題はなくなりつつあります。メインメモリやストレージのサイズは拡張される傾向にあるので，存在する問題はすべて解決する傾向にある，と言えるでしょう。

Ubuntuとして考える場合は「古い64bit非対応のCPUを利用しているような環境はどうするのか」という問題がつきまといますが，Lubuntuですら32bit版の新リリースはせず，2021年4月まで18.04を使ってもらう（注4）という判断がくだされており，「⁠さすがに2021年には32bit CPUはもう残っていないだろう」（⁠注5）という方針となっています。

少なくとも2021～2023年まではi386環境の利用は可能であることから，事実上，2019年は「32bit CPUが利用されている環境にUbuntuがインストールされる最後の年」となると考えられます。

注2

比較的マイナーなVIA製CPUやその後継にあたるZhaoxin製CPUも現状では64bit対応を果たしており，「⁠対応しないCPU」は現行ラインからは消滅していることになります。

注3

現行のLinux環境では64bit非対応のソフトウェアは消滅しつつありますが，「⁠バイナリだけが存在する」タイプのソフトウェア（特に過去のソフトウェア資産）を利用しようとすると，32bitバイナリとの併用が必要になる場合があります。

注4

LTSリリースのLubuntuは3年サポートです。

注5

中古等を含めて考えても，現在入手/利用可能な32bitサポートのみのCPUはCore Duo（Core 2 Duoではなく無印の方）や古いAtomで，これが2021年まで実用か，と考えると妥当な判断と言えます。

Snapパッケージの進展

2019年のUbuntu Desktopにおける変化を予想するのであれば，Ubuntu seeded snapsをはじめとする「Snapへの移行」を外すことはできないでしょう。Snapは，Ubuntuが採用する「コンテナ技術を応用した」新しいパッケージ形式です。

現時点のUbuntuのパッケージングポリシーの限界として，「⁠最新のソフトウェアを提供し続けるために，大きなコストがかかる」という点があります。ブラウザや一部のテキストエディタのような，非常に早いペースで更新されるソフトウェアを既存のUbuntuパッケージとして（特に，「⁠リリース後はソフトウェアのメジャーバージョンアップはしない」という方針を維持して）提供することは，コストの面でも，セキュリティの面でもあまり現実的ではありません。ソフトウェアによってはStable Release Updatesポリシーの例外（Special Cases）として定義し，ある程度のコストをかけて最新版を提供する，という方式を採っています。ここから状況を変える手段として，「⁠デスクトップで日常的に使うソフトウェア」のたぐいをSnapに切り替えていく一年となる可能性があります。UbuntuではSnapへの移行を積極的に進めており，2017～2018年にかけて，色々な技術的課題が解決しています。

今後，Snapへ軸足を移すことで，特定のソフトウェアだけを最新に更新し続けることが現実的になるため，デスクトップソフトウェアの一部は完全にSnapを前提としたものに切り替わる可能性があります。すでに2018年までにかなりのソフトウェア（たとえばFirefoxやChromium，Visual Studio Code，Skype，SlackといったソフトウェアはすでにSnapで利用できます）を利用できる状態となっており，2019年はこの傾向がますます加速することになるでしょう。

DockerとSnap・juju・LXD

Snapやjuju，LXDは，Ubuntuで提供される「パッケージやシステムの管理をより楽にする」ためのテクノロジーです。2019年は，Ubuntuが提供するこれらの「Ubuntu独自のテクノロジー」に時代や環境が追いついてきてしまった結果，より資本やエンジニアリングリソースの大きな企業や団体によるライバルとの本格的な衝突が始まる年になるかもしれません。

現在のサーバー環境において，Dockerを避けて通ることはできません。Dockerで構成した各種ソフトウェアをk8s環境にデプロイする，というアプローチがマイクロサービスでは定番となっており，結果としてDockerの市場シェアは順調に拡大しています。

Snapは技術的な詳細はかなり異なるものの，「⁠Dockerとできることと目的が同じ」コンテナ環境であり，Ubuntuのデスクトップ環境における一定の立ち位置とは別に，サーバー環境では苦しい立場に立たされています。jujuを用いることで複数のSnapコンテナをデプロイすることができるものの，事実上，利用できるのはUbuntu環境だけに限られており，異なるLinuxディストリビューションやWindows環境でも利用可能なDockerほどのエコシステムの確立には至っていません。これはCanonical/Ubuntuが，「⁠Dockerで良い」もののために一定のコストを支払うことを意味しており，競争上はあまり良い状態ではありません。

こうした状況から，2019年はサーバーにおけるSnapにとって，試練の一年となるかもしれません。一方で，「⁠Snapを使ってDockerをより良く使える環境にできるようになりました」あるいは「K8s環境で発生する○○という問題をSnapで解決できるようになりました」的な新プロダクトの投入の可能性もあります。これによりSnapの存在意義が確立する，という可能性もあります。

逆に，「⁠コンテナ技術を利用した仮想マシンの提供」に注力しているLXDはある程度補完的な立ち位置にあることもあり，Dockerの進展によって住処を奪われる，という展開にはなりにくいと言えます（注6）⁠。

注6

ただし，LXDにもgVisor，Firecracker，Kata Containerといった実質的なライバルは存在しており，戦国時代の中を生きているプロダクトです。