Mojaveれなかった理由
iOS 12が正式リリースされたのは9月18日。筆者が日常使用しているiOSデバイスでその日のうちにアップグレードしました。macOS Mojaveの正式リリースはその1週間後の9月25日。それからさらに1月後の現在も、本記事を執筆している筆者のiMacはHigh Sierraのままです。おかげでアップグレードを促す通知が表示されるようになりました（図1 ） 。
図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 ） 。ふぅ。
図2 アップグレードに屈するこのようにOSアップグレードというのはたいへんな心労を伴うものですが、かといって古いOSをそのまま使い続けるのは、ダイアルアップでインターネット接続していた時代であればともかく、OSアップグレードすらネット前提の現代ではセキュリティの観点から無理がありました。Appleはこの点では決して優等生とは言いがたく、実績ベースで2代前のOSしかセキュリティアップデートを出してくれない。先代だけでなく先々代のOSも一足飛びにアップグレード可能とはいえ、WindowsやLinuxよりもアップグレードへの「圧力」は強く感じます。
GitHubというSPOF
ネット大前提。OSアップグレードはもとより、ポケモンGOの幻獣配置に至るまで。おかげで物理パッケージの物流から自由になった一方、クラウドという別の依存が生まれました。それも作り手だけならず、使い手たる我々が。
それが実に嫌な形で問題化したのが、本原稿執筆時点で、まさに現在起こったGitHubのブラックアウトです。クラウドサービスが瞬断することは珍しくありませんが、24時間以上に渡って落ちたのです（図3 ） 。
図3 GitHub落ちる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の復旧を願いつつ……。
第1特集 MySQL アプリ開発者の必修5科目 不意なトラブルに困らないためのRDB基礎知識 第2特集 「知りたい」「使いたい」「発信したい」をかなえる OSSソースコードリーディングのススメ 特別企画 企業のシステムを支えるOSとエコシステムの全貌 ［特別企画］Red Hat Enterprise Linux 9最新ガイド 短期連載 今さら聞けないSSH ［前編］リモートログインとコマンドの実行 短期連載 MySQLで学ぶ文字コード ［最終回］文字コードのハマりどころTips集 短期連載 新生「Ansible」徹底解説 ［4］Playbookの実行環境（基礎編）
