Discussing the evolution of container technologies and WebAssembly, the author presents Docker’s shift towards supporting WASM, highlighting its impact on software compatibility and development.
註: このオジさんは横山がモデルではありません。もう少し若いです💦
相模原市で IoT 設計を受託しているファームロジックスです。
今日は少し愚痴っぽい話です。純粋に「HomeBrew と WebAssembly の間にどういう関係があるの!?」という方は、ずっと読み飛ばして、下のほうをお読みください。申し訳ありません。
老化現象!?
最近、世の中の動きが速すぎるのか、私の老化が進んでいるのか、時間の進みを非常に速く感じるようになりました。「あれ!? macOS を Catalina（10.15）にアップグレードしてから、もう4年も経つのか」と驚きを感じます。その一方で、Catalina をインストールした頃の印象は、完全に忘れ去っています。
話は少し逸れますが、最近仕事をしたりネットで調べ物をするときは日記（ログ）が必須になっていて、考えたことや調べたことを、すぐにテキストエディタでメモしていかないと忘れてしまいます。私は Emacs エディタで timestamp というマクロを定義していて、日記中にタイムスタンプをいつでも容易に挿入できるようにしています。そうしないと、あるメモが、いつ書いたものなのか分からなくなってしまいます。これに似ているかも知れませんね。
Apple と HomeBrew にがっかりした話
閑話休題。先日、これも老化現象で何がきっかけか思い出せないのですが、macOS Catalina 上の HomeBrew を少し整理しようと思いました。何かのツールを入れようとして、brew update, brew upgrade に失敗したのがきっかけかも知れません。
念のため、/usr/local 以下のディレクトリとファイルをバックアップした後、古い HomeBrew をアンインストールし、新しくクリーンインストールしようとしました。しかし、ここでいろいろな問題にブチ当たることになります。
後で知ったのですが、HomeBrew は、インストールしている OS のバージョンが古い場合、パッケージをバイナリで持ってくるのではなく、自力でビルドするようです。言い換えると、新しい OS を使っている場合には、home brew でなくて、Debian OS の apt のように、バイナリを持ってくるのでインストールが速い訳ですね。
しかし、HomeBrew のインストール時のメッセージを見ていると分かるように、「macOS Catalina は既にサポート外であり、インストール時に何か問題が起きても報告しないように」（原文は英語）とあります。そのメッセージの中では、理由として Apple が macOS Catalina のサポートを中止しているため、とありますが、本当に Catalina はそんなに古い OS なのでしょうか!?
ちょっと愚痴っぽくなりますが、私も若い頃は OS でもアプリでも新しいバージョンが好きでした。しかし、最近はそういうことはなくなりました。Catalina の前は El Capitan（10.11）を使っていましたが、何かの事情（使いたいアプリが El Capitan に対応していなかった等）で Catalina にアップグレードしました。既に当時 Big Sur（11）がリリースされていましたが、さすがに新しすぎて不安を感じたので Catalina をインストールしました。
その時も Catalina へのアップグレードで、Emacs で愛用していた拡張機能が動かなくなったり、VMware Fusion が動かなくなって購入し直したり、いろいろ大変な思いをしたのです。（VMware Fusion の話題は、また下の方で触れます。）
ところで、最近知ったのですが、私の iMac（Late 2012）は、Big Sur の対象外になっていたようですね。しかしそれでも、既に当時 Catalina 単体のインストールパッケージが入手困難になっていました（アップデートツールは、入手できた）。そのため、入手方法について、いろいろネットで情報を漁っていたことが、「日記」に記されています。
そんな次第で Catalina を使っているのですが、リリースされてからまだ 5年も経たない OS ですよ!? それがサポート外となり、各種のアプリケーションが動かなくなる、というのは不思議に思います。Microsoft の Windows 10 は私にとっては非常に新しい OS という認識ですが（実際には、Windows 11 が出てますね）、Windows 10 がリリースされてから、もう 9年近く経つのです。Apple の最近の OS のアップデートは頻繁すぎる、と感じるのは私だけでしょうか。（iPhone の iOS も同様です。）
Catalina みたいな 5年前の OS を使っているのは私だけかと疑問に思うのですが、実際、私の家族などは、いまだに High Sierra（10.13）を使ってますからね。（私と違ってソフト開発者である訳でも、特殊な古いアプリを使っている訳でもないので、そろそろ新しい OS にしたら? と思うこともあります。）
最近、Apple 社自身もソフトウェアの更新にアグレッシブすぎると感じているようで、新機能の追加よりも問題の修正に力を入れようとしている、というニュースもありましたが、先日、今度は iPad Pro の広告で非難を浴びたりと、私は Apple の文化に少し辟易してきています。
Catalina の利用が困難になってきたら、外付けの SSD でも繋いで、Ubuntu でもインストールするか、と考えたりしています。（幸い、Thunderbolt が付いているので高速で安定した SSD を接続することは可能です。Thunderbolt 3 からのコンバータが必要ですが。）
HomeBrew のクリーンインストールを諦める
話を戻します。実際、HomeBrew をクリーンインストールしたのですが、まず最初に、インストール済みの Apple Xcode のバージョンが古いことに気付きました。Catalina でもインストールできる Xcode を入手するのに、また一苦労することになりますが、その話は割愛します。
ようやくインストールが終わり、私が必要なツールを brew install し始めました。ところが、とにかくインストールが遅いです。昔を思い返すと、FreeBSD（使っている方、いますか?）でもパッケージのインストールにソースのビルドが必要で大変だったのですが、それと同じ思いをするはめになりました。LLVM のビルドなどは、数時間単位が必要になりました。
なんとか LLVM のビルドはできましたが、ImageMagick のインストールで引導を渡されることになります。依存しているライブラリのビルドに失敗し、ネットの情報を元にしばらく頑張っていましたが、結局諦め、Time Machine を使って、安定して使えていた頃の /usr/local に戻しました。
Autodesk Fusion 360 にがっかりした話
ここで思い出したので、また脱線します。
先日、あるプラスチックの部品を自作したくなり、もうすっかり使い方を忘れていた 3D CAD、Fusion 360 を起動してみました。するとどうでしょう。エラーが出て起動しないではないですか。（2021年の10月頃にインストールしたバージョンです。）
Fusion 360 はスタンドアロンのアプリだと思っていたのですが、どうも、ネット接続が前提だったらしく、Autodesk 社のサーバーのアップデートにより、私の使っていた Fusion 360 が動かなくなったらしいのです。Autodesk 社のサイトで調べると、最新の Fusion 360 にアップデートしろ、とあったのでインストールしようと思ったのですが、これまたお約束で、Catalina はサポート対象外になっていました。結局、私が設計した 3D の図面（?）は、Windows 10 あるいは 11 の PC を用意するか、Mac を買い直さない限り、利用することができないことが分かりました。（私の iMac は Ivy Bridge Intel Core i7 搭載で、今となってはかなり古いのですが、通常のソフト開発には全く問題ありません。）
これもどうでしょう? 私は同社の姿勢とサポート体制にひどくがっかりしてしまったので、今後 Autodesk の製品を使うことはないでしょう。以前も、Autodesk が買収した EAGLE CAD を discontinue したというニュースがあって、ブルーな気分になったばかりなのです。
古い OS を安心して使うにはどうしたら良いか?
最初に注意しなくてはならないこととして、基本的に、古い OS を使い続けることにはセキュリティ上のリスクがある、ということを忘れてはいけません。ですから、私も iMac Late 2012 + Catalina を使い続けていることを威張るつもりはありません。ただ、昔から使って指に馴染んでいる環境を簡単に捨て去りたくない、ということと、OS のアップデートの度にアプリを買い直す、というのは避けたい、という二点に終始します。（もう一つ言えば、近年は macOS をアップデートする度に、感激することよりガッカリすることのほうが多くなった、ということもあるでしょう。一番印象が良かったのは、Yosemite の頃かな?）
これまた脱線ですが、私は 2002年に購入した PFU Happy Hakking キーボード（モデル PD-KB02）を 22年間も使っていて、おそらく、仕事を引退するまで使い続けることになるだろうなあ、と想像しています。慣れた HID（Human Interface Device）というのは、非常に重要なものです。
はい。ようやく本題に入ります。
私は考えました。今回はなんとか、ImageMagick を取り戻しましたが、今後似たようなことが起きたらどのように対応しようか、と。
一番簡単なのは、VMware や VirtualBox のような仮想化アプリを使って、その中で新しい OS（Ubuntu 24 など）を起動し、その上で ImageMagick を使う、という方法です。しかし、ImageMagick を使うためだけに VM（仮想マシン）を使うのはオーバーヘッドが大きいです。
もう少しマシなアイデアは、Docker などのコンテナ化技術を使う方法です。調べると、ImageMagick の Docker イメージがあり、けっこう広く利用されているようです。（100万回以上 pull されている。）
ちなみに、ここまで来ると苦笑いしかないのですが、Docker デスクトップの最新版は Catalina で動きません。Catalina で動作する最新の Docker Desktop については、以下を御参考ください。嬉しいことに、ベータ機能ではありますが、この Docker Desktop 4.15.0 は、後述の WASM WASI に初めて対応したバージョンでもあるようです。
仮想マシンからコンテナ技術までの 10余年
ここまで見てきたように、コンピュータの OS のバージョンアップには、常に、古い資産の切り捨て、という出来事がリンクしています。
1999〜2001年にかけて、VMware という新興企業が PC のための仮想マシン（ハイパバイザ）という技術を引っさげて登場し、企業の IT システム管理者を狂喜させました。それまでも、エミュレーションという技術を使って、ある OS を別の OS 上で動かす技術はありましたが、VMware の優れていた点は、さまざまな OS を、ほぼネイティブの速度で仮想的に実行することができた、というものです。（簡単に言うと、CPU の通常の命令はそのまま実行させ、特権命令だけをトラップしてエミュレートすることで、余計な実行オーバーヘッドを無くしている。）
このような仮想マシン技術により、例えば Windows 95 時代のアプリケーションでも、原理的には最新の PC 上で実行することができるようになりました。しかし、その後にも様々な技術が登場します。その最も有名、かつ広く使われているのは Docker によるコンテナ化技術でしょう。
Docker によるコンテナ化技術は、2013年頃に登場しました。このブログ記事の目的はコンテナ化技術を説明することではないので、詳細は別途ネット上の情報を御参考頂くとして、コンテナ化により、例えば最新の Debian OS と最新の LLVM コンパイラ、最新のライブラリをインストールしないと使えないようなアプリを、比較的古いホスト上でも、コンテナの中で簡単に動作させることができるようになりました。
今回、私は Docker を使って ImageMagick の最新版を Catalina で動かす方法を見つけ、ほっと胸をなで下ろした訳です。
WASM の登場
Docker コンテナが広く使われるようになっても、ソフトウェア技術者は満足しませんでした。Docker コンテナをよく見ると、それぞれのコンテナは、Intel あるいは AMD の x86-64 というアーキテクチャ用のものだったり、ARM 用だったり、ARM64 用だったりします。つまり結局のところ、コンテナ化技術によっても、もっとも下位のアーキテクチャである CPU および命令セットに依存している、ということになります。
つまり、あるソフトウェアパッケージをコンテナとして提供する場合、さまざまな利用者のために、異なる CPU と命令セットのためのコンテナを個別に提供する必要がある訳です。
さらに、コンテナ化技術とは別に、ウェブアプリケーションのソフトウェア技術も重要です。長い間、ウェブ技術者にとって JavaScript 言語は基本的な技術、知識でした。なぜなら、広く利用されるウェブブラウザ上でアプリケーションのロジックを実装したい場合、JavaScript がもっとも高速で現実的な選択肢だったからです。
しかし最近になって、WebAssembly（WASM）という技術が開発され、広く利用されるようになってきました。WASM なんて聞いたことない、というソフトウェア技術者の方もあるかも知れませんが、2017年頃にリリースされた Google Chrome、Mozilla Firefox、Safari などでサポートが始まったようです。最新のブラウザをお使いであれば、問題なく利用できる状況になっています。
上述したように、従来、ウェブブラウザ上でアプリのロジックを実装するには JavaScript が数少ない選択肢でしたが、他のプログラミング言語でもブラウザ上で実行したい、というニーズは長く存在した訳です。WASM が登場する前は、それらのプログラミング言語の実行コードを JavaScript に変換するなどして対応していましたが、WASM の登場により、プログラミング言語を区別することなく、あらゆる言語が対等となる下地が整いました。既に、C 言語、C++言語、Rust、Python など多くのプログラミング言語を、WASM の技術を使ってブラウザ上で実行できるようになっています。
以下に、私の好きな Python の例を挙げておきます。御興味のある方はお試しください。
WASM の未来に思いを馳せる
このような技術が登場したことにより、ソフトウェア技術者はすぐ、別のアイデアに気付きました。何もウェブブラウザに限定した話ではないんじゃないか。一般のパソコン OS やスマートフォンに WASM のランタイム（実行処理系）が載れば、ソフトウェアの同じリリースファイル（イメージ）が、Windows でも macOS でも Linux でも iOS でも Android でも動くんじゃないだろうか!?
そのような考えが広まったことで、PC や組込環境で動作する WASM ランタイムがたくさん開発されてきました。以下に、それら多くの WASM ランタイムを紹介しているサイトを紹介させて頂きます。
個人的には、WAMR というものに興味を持っています。数十キロバイトのフットプリントで WASM コードを実行できるそうで、ESP32 マイコンなどでの実績が広く報告されています。
中には、C 言語を WASM にコンパイルして WAMR で動かす、という話もあるようです。私は当初、C 言語をわざわざ WASM にコンパイルして動かさなくてもいいんじゃないか、と思ったのですが、これには重要なアイデアが隠されています。つまり、品質の十分でない、あるいは出所の不明な C 言語のコードでも、WASM にコンパイルして仮想マシンとして動作させることで、実行をサンドボックス（お砂場）内に閉じ込めることができる、ということです。
かつて、マルチユーザーの OS（オペレーティングシステム）が登場し、特定のソフトウェアや特定のユーザーがコンピュータリソースを消費したり、コンピュータをダウンさせたりしないよう、リソース保護を担うようになりましたが、マイコン上における WASM による仮想化技術は、これと同様のことを、大きなオーバーヘッドやフットプリントを必要とすることなく、可能にしたわけです。今までも、マイコン用のリアルタイム OS は広く使われていましたが、これはスケジューリング（マルチタスク）や同期、データ共有を主な目的としたものであり、リソースの保護は、あまり重要視されていなかったと思います。（最新のリアルタイム OS 動向に詳しい訳ではないので、間違っていたらゴメンなさい。）
Docker の動向
上でも少し触れましたが、Docker も WASM を重要視し始めています。
2019年に、Docker 社の共同創業者の Solomon Hykes が、”If WASM+WASI existed in 2008, we wouldn’t have needed to create Docker.” と発言したという話は有名ですが、それを置いておくとしても、Docker は WASM を無視できなくなってきているようです。
Google で検索すると多くの情報が見つかりますが、2つほど引用しておきます。
2つめの記事は特に興味深いです。今までの Docker は x86_64 や ARM など、物理的な CPU 命令セットのためのコンテナを生成して利用してきましたが、それに加えて WASM のコンテナを簡単に利用することができるようになったのです。以下のような WASM ランタイムをサポートしています。
- io.containerd.slight.v1
- io.containerd.spin.v2
- io.containerd.wasmedge.v1
- io.containerd.wasmtime.v1
- io.containerd.lunatic.v1
- io.containerd.wws.v1
- io.containerd.wasmer.v1
有名な WASM ランタイムの名前が見えますね。
近い将来、Docker コンテナのイメージを配布する際、WASM 向けのコンテナが広く利用されるようになるかも知れません。（私の夢）
Python の動向
もう一つ、Python の動向も見逃せません。WASM が登場してから、WASM を利用して Python のコードをブラウザ上で実行する、という話が広く聞かれるようになりました。有名なプロジェクトとしては次のようなものがあります。
これらは、JavaScript に代えて、Python で実装したコードをウェブブラウザで動かそうという試みで、既に十分な品質を備えているようです。
問題は、Python で利用されるサードパーティのライブラリです。多くの方が利用しているように、Python では pip コマンドを使って、PyPI で公開されているライブラリを簡単に導入できるようになっています。その中で、いわゆる pure Python と呼ばれる、Python だけで実装されたライブラリは、既に Pyodide で問題なく利用できるようになっているようですが、Python だけでなく、バックエンドを C 言語等に頼った、すなわち CPU 命令セットに依存したバイナリに依存する Python ライブラリは、そのままでは Pyodide で動作させることができません。
これは当然のことで、Pyodide は Python を WASM で動作させるものであり、CPU の命令セット、いわゆるバイナリコードを変換するためのものではないからです。Pyodide のプロジェクトでは、このようなライブラリについても、個別に Pyodide で動かすような努力を続けていて、現在利用できるライブラリはリストにまとめられています。
これを見ると、NumPy や Matplotlib など、重要なライブラリが Pyodide で利用できることが分かります。
余談ですが、上記のリストにはまだ入っていないのですが、Pygame というライブラリが利用できるようになりつつある、という情報もあります。
つまり、Pygame で実装した 2D ゲームが、ウェブブラウザ上で動作してしまう訳ですね。以下に、動作例が紹介されています。現在の Pyodide 正式リリースには含まれていませんが、将来が楽しみです。
もう一つ、Python と WASM の関係としては、興味深い提案がありました。
これは、PyScript のサイトでも触れられているのですが、Python の PyPI（つまり pip）の wheel として、x86 や ARM に加えて、WASM も追加しようという提案です。これが実現すると、PyPI で公開されているライブラリの多くが、Pyodide チームの特別の努力なしに利用できることになるのではないか、と思います。（私の夢、その 2）
余談: VMware が心配になった話
さて、ここからは余談です。最初の方で書いたように、VMware は 2000年頃に登場した重要な仮想化技術ですが、最近になり、VMware 社が Broadcom 社に買収されました。様々なニュース（噂）によると、従来無償で利用できた ESXi が利用できなくなるとか、vSphere（私には高くて導入できませんけれど）がサブスクリプション契約になるとか、いろんな噂があります。（真偽はまだ分かりません。）
しかし一つ確認できたことは、VMware 製品のダウンロードが、半月にわたり中断されているということです。このことを知らずに、重要なプロジェクトで VMware を利用していた人が、誤って VMware 製品を動かなくしてしまい再インストールしようとして、大いに慌てている可能性があります。私は、このような対応を非常に残念に思います。
VMware 製品のダウンロードが半月ほどできなくなっている
まとめ
2000年頃、PC の OS を選ぶ際には、OS の使い勝手や利用したいアプリケーション、ツールに基づいて、最適な候補を選択することが重要でした。フリーの UNIX 系 OS としては、既に Linux が重要な位置を占めていましたが、FreeBSD や NetBSD を選択肢として考える UNIX ユーザーも多かったのです。
その後、VMware などの仮想マシン技術が登場し、OS の選択はそれほどシビアではなくなりました。普段は Windows OS を使いながら、必要なときだけ仮想の Linux や FreeBSD を起動することができるようになったからです。もし、ある研究者が FreeBSD でしか利用できない技術を評価したかったら、仮想マシンで FreeBSD を技術評価しながら、デスクトップの Windows の PowerPoint でプレゼンテーション資料を作成することができるようになたのです。
この流れは、コンテナ化技術でさらに加速しました。今回紹介したように、ImageMagick が PC 上にインストールできなくなっても、Docker から ImageMagick コンテナを実行すれば、ほとんどオーバーヘッドなしに、ImageMagick の convert や identify コマンドをシェル上のコマンドと同様に実行できる訳です。
さらに、Python 言語の普及にも重要な意味合いがあります。
例えば、ある画像処理のプログラムを開発することを考えましょう。2000年当時であれは、おそらく誰も疑問を持たずに C 言語で設計したことでしょう。ところが、ネット上で必要なライブラリ（例えば、色空間の変換ライブラリ）を見つけたとして、それは Linux ではコンパイルできるが、Windows でのコンパイルは難しい、ということがありました。
現在であれば、そのようなプログラムを C 言語で書くことは、まずないでしょう。多くの技術者が Python を選択すると思います。例えば、ネットを探すと colormath というライブラリが PyPI で公開されているのを、すぐに見つけることができるはずです。このライブラリは pure Python のようなので、Linux や Windows はもちろん、macOS、Raspberry Pi など、Python が利用できる環境であれば、どこでも利用できるはずです。プログラムの実行速度の観点からも、以前ほど「何がなんでも C 言語」という考えは薄れてきていると思います。
このように、OS の選択が重要でなくなっただけでなく、実行プラットフォームの選択の重要性も下がりました。Python が使えて、PyPI で公開されているライブラリが利用したいアーキテクチャで提供されていれば「動作環境なんて、なんでも良い」という時代になったのです。
いずれこの流れがさらに進み、「WASM が動けば、なんでも良い」という時代が来るかも知れません。あるソフトウェアが WASM ランタイムで実行できるのであれば、もはや、OS の種類だけでなく、CPU アーキテクチャだってなんでも良い、ということになるのではないでしょうか。
いまいちど時代を遡って、大昔（1980年台）、多くのパソコンメーカーが、どれだけ多くの市販アプリケーションソフトウェアに対応しているか、競っていた時代がありました。メーカーの投資と競争により、多くのプログラマが、ワープロソフトやゲームソフトを、IBM、NEC、富士通、日立などの PC への移植に奮闘していた時代があったのです。
現在では、デスクトップ環境では Windows と macOS が市場を制覇し、モバイルでは Android と iOS が支配していますが、例えば Flutter のような技術が広がってきていることから、IT デバイスの差異化はますます難しくなっていくことでしょう。その一方で、プログラマの苦労は、少なくなっていくことが期待されます。（現状はまだ、そんなことはないのでしょうが、そうなることを私は期待しています。）
今日はここまでとします。Python や WASM の明るい未来に期待して参りましょう。長文にお付き合い頂きまして、ありがとうございました。