Mojaveれなかった理由

iOS 12が正式リリースされたのは9月18日。筆者が日常使用しているiOSデバイスでその日のうちにアップグレードしました。macOS Mojaveの正式リリースはその1週間後の9月25日。それからさらに1月後の現在も，本記事を執筆している筆者のiMacはHigh Sierraのままです。おかげでアップグレードを促す通知が表示されるようになりました（図1）⁠。

うーん，うざい（笑）

筆者のように，iOSはすぐにアップグレードしても，macOSのアップグレードはしばらく待つという人は多いのではないでしょうか。……でも，なぜ？

そこにこそ，iOSとmacOSの違いが集約されています。

iOSソフトウェアの世界は，事実上100％をAppleが支配しています。我々サードパーティが開発したアプリケーションも，App Storeを通してしかリリースできません。新規アプリをApp Storeに上げるには最新OSに対応していることが当然求められますし，すでにApp Storeで配布しているアプリも最新OSに対応するか，それが不可能であれば取り下げるかし なければなりません。

Macの世界はそうはいきません。App StoreはMacにもありますが，そこで配布されるソフトウェアはいまだ氷山の一角。本誌の読者であればMacPortsかHomebrewのどちらかあるいは双方を利用されていると思いますが，そのどちらもApp Storeとは別の，Appleからは独立したソフトウェア配布システムです。そしてそのどちらも，バイナリはOSごとに分けているのです。これはOSをアップグレードすると（バイナリ）パッケージを1つ残らずインストールし直すことからもわかります。

なんて無駄が多い……いえ，これがOSアップグレードの常識です。Linuxのディストリビューションの過半も，FreeBSDも，同一なはずのソフトウェアをOSメジャーバージョンごとに別パッケージにしています。なぜそうなっているか？

ABI=Application Binary InterfaceがOSバージョンで異なるからです。もちろんどのOSもある程度の下位互換性は確保されているので，旧OS上のアプリケーションもある程度そのままで動くことは期待できます。が，それは期待できるだけのことであって，その期待に応えなくても良いというのがOS=ABIを更新するということ。それであれば，ソフトウェアを新OS用にビルドし直して，全部入れ替えてしまったほうが動かない公算は減る。全部あわせても高々数GBから大きくても十数GB。映画1本分にも満たないのであれば全部入れ替えてしまったほうが楽というものです。

それでもなお，自分の使っているソフトウェアが新OSで動くことは保証されません。パッケージされたソフトウェアの作成者はあなたがそもそも新OSにアップグレードするかどうかすら知れませんし，それ以前にソフトウェアを作成した人があなたのOSのことをまるで知らないケースすら珍しくないのです。OSSではこれがとくに顕著で，Linuxしか使っていない人が開発したソフトウェアがmacOSやFreeBSDで使われていることはざらで，Macで動かないと文句を言おうにも誰に対して言えばいいのかわからないことも多々あり，実際いくつかのOSSのメンテナーでもある筆者のもとにもこの手の誤チェストが後を絶ちません。

話がそれかけました。つまりmacOSはiOSよりもはるかに自己責任率が高いのです。Appleの支配からのある程度の自由の代償として，OSアップグレードにまつわる諸問題は基本的に自分で解決せねばならないのです。で，筆者の場合ですが，Mojaveにできなかった一番の理由は，OpenZFS on OS Xでした。Mojave対応の安定版がなかなか出なかったのです。OSの非互換性で，ファイルシステムというのはある意味もっとも深刻でしょう。何しろデータが読めなくなってしまうのですから。仮想マシン上の検証のあと，筆者がMacBook Proをアップグレードしたのはつい昨日のことです（図2）⁠。ふぅ。

このようにOSアップグレードというのはたいへんな心労を伴うものですが，かといって古いOSをそのまま使い続けるのは，ダイアルアップでインターネット接続していた時代であればともかく，OSアップグレードすらネット前提の現代ではセキュリティの観点から無理がありました。Appleはこの点では決して優等生とは言いがたく，実績ベースで2代前のOSしかセキュリティアップデートを出してくれない。先代だけでなく先々代のOSも一足飛びにアップグレード可能とはいえ，WindowsやLinuxよりもアップグレードへの「圧力」は強く感じます。

GitHubというSPOF

ネット大前提。OSアップグレードはもとより，ポケモンGOの幻獣配置に至るまで。おかげで物理パッケージの物流から自由になった一方，クラウドという別の依存が生まれました。それも作り手だけならず，使い手たる我々が。

それが実に嫌な形で問題化したのが，本原稿執筆時点で，まさに現在起こったGitHubのブラックアウトです。クラウドサービスが瞬断することは珍しくありませんが，24時間以上に渡って落ちたのです（図3）⁠。

Swiftというプログラミング言語，Xcodeというプログラム開発環境自体はオフラインでも動きます。さもなければ飛行機の中でコードは書けません（苦笑）⁠。しかしその利用にあたっては大いに依存します。以前紹介したSwift Package Manager（SPM）は，事実上GitHubが前提になっています。建前上はGit repositoryであればGitHubでなくても動くのですが，筆者のrepoを含めSPMのパッケージの配布はGitHubの寡占状態。ソフトウェアが使うソフトウェアのハブが止まったことで，仕事にならなくなった読者も少なくないのではないでしょうか？

Convenience over Freedom

「誰もが自由に情報を発信できる」⁠。それがインターネットの売り口上で，それを信じていた時代が筆者にもありました。しかしこうして振り返ると，我々が求めていたのは自由ではなく利便だったのかと嘆息もします。「⁠消費者」としてApp Storeを受け入れるにとどまらず，「⁠開発者」としてすらGitHubの寡占を唯々諾々と受け入れているとあっては。それは強者による抑圧の結果では断じてありません。App Storeの審査を受けるのもGitHubにrepoを立てるのもそれぞれ我々の自由意志の結果なのですから。

高々パソコンOSのアップデートでこんな疲れるようになったのは，筆者の健康状態と年齢のせいなのでしょうか？

そうでないといいのだけど……いや，そうであればまだいいのだけど……。

次回予告

次回こそはSwiftに話を戻します。GitHubの復旧を願いつつ……。