この新しいプログラムに参加した最初のデバイスは、Vanmoof の電動自転車 S3 および X3、Belkin のワイヤレスイヤーバッド Soundform Freedom、そして Chipolo One アイテムファインダーだ。Apple の Made for iPhone プログラムの拡張が Find My ネットワークの一部分となり、認可を受けた個々のデバイスはプライバシーに関する Apple の標準に適合していなければならない。しかしながらまだ出荷されている製品はない。
今回の発表が意味するのは、あなたが Find My アプリを使って場所を追跡できる対象が iPhone、iPad、Apple Watch、AirPods (加えて Apple 製品を使っているあなたの友人たち) だけではなくなるということだ。電動自転車やイヤーバッドなど、互換なデバイスをすべて追跡できるようになる。とりわけ興味深いのは Chipolo One が加わったことで、このデバイスをバックパックや鍵束、リモコン、あなたの自動車など、事実上どんな物にも取り付けておける。
長らく噂されてきた AirTags については何も触れられなかった。これは Tile に似たワイヤレス追跡装置で、もう何年も開発が続いているという報道がなされてきた。Apple が今回 Find My クラウドソーシングを開放することで、その種の製品のための基礎作りをしているのだとしても不思議はない。また、噂されている次世代の Apple TV リモコンにもこのテクノロジーが組み込まれることを期待したい。何しろ、Apple のリモコンは滑りやすくて見失いやすいことで悪評が高いのだから。
Find My 互換性が追加されれば、皆さんがそれに対応したデバイスを購入したい気持ちが高まるだろうか？ 皆さんが特に Find My 互換性を組み込んで欲しいと思われるデバイスはどんなものだろうか？
GPS だけの Apple Watch Series 3 モデルはオンボードストレージとして 8 GB しか持っていない。それ程多くないアプリをインストールしている人々にとってっも、この限られたストレージ容量は watchOS 7 へのアップデートをインストールする時に問題となる可能性がある。ユーザーは、このアップデートをインストールするための十分な空き容量が無いとするエラーを Watch アプリで経験している事を報告している。この問題はどうも Apple Watch Series 3 だけに限られている様に見える - 私はこの問題がより最新の Apple Watch モデルの所有者を苦しめているという報告を未だ目にしたことがない。
アップデートは、Apple Watch を充電器に乗せ、少なくとも 50% 迄充電され、そして Wi-Fi が使える状態になる迄はインストールされない。この過程は、通常 Apple Watch を充電する時間に始めるのが一番やり易い。
Apple Watch のペアリングを解除し、そして再ペアリングする
前記の方法で成功したとするユーザーは何人かいたが、もしこの方法で解決しない場合、もう一つの選択肢がある。それは面倒だし時間が掛かるので、時間が十分に取れる時が来るまでやらない方が良い。要するに、時計をペアリングから解除することで、それを消去しそしてアップデートのために空きを作り、そして再度ペアリングを行い、バックアップから復元する必要がある。iPhone と Apple Watch をお互いに近い所に置いて、以下の手順を踏む：
Watch アプリの My Watch タブで、All Watches をタップ。
ペアリングを外したい時計の隣にある情報ボタンをタップ。
Unpair Apple Watch をタップ。もしセルラープランを保持するか削除するか聞かれたら、保持するを選ぶ - 削除するのは、その時計を売却するか誰かにあげる時だけである。
確認のため再度 Unpair Apple Watch をタップ。もう一つのバックアップが作成され、消去の課程が始まる。
Apple Watch が工場出荷時のデフォルトへの再設定が終わると、それを iPhone の近くに置くことで再びペアリング出来る状態になる。Apple Watch を設定するか聞かれたら Continue をタップ、そしてペアリングのためのアニメーションをスキャンする。要求された所で、Restore from Backup をタップ、そしてもし聞かれたら、最新バージョンの watchOS にアップデートさせる (それが目的なので)。
私の仕事上の生活は Mac を中心に展開している。数少ない素晴らしい例外として私を解き放っているのは、printing history and letterpress印刷の歴史と凸版印刷に関するものである。私は、毎日の殆どを画面を見つめ、キーボードを叩き、そしてマウスを操ることで過ごしている。2017 年に、私は quad-core 21.5-inch iMac Retina ディスプレイモデルを購入し、二次の 4K ディスプレイを追加した時、私は私のニーズに対して適切な額のお金を使ったと感じていた。しかし、その能力を真の意味で解き放てたのは、つい２週間前になってからであった。
私はその性能トレードオフに殆ど気付かなかった。この Fusion Drive は最初 macOS 10.12 Sierra で私のニーズには十分応えてくれ、そして 10.13 High Sierra でも私を悩ませることはなかった。でも、10.14 Mojave にアップグレードした途端、私は、アプリが立ち上がるのに、そしてディスクを多用するタスクが終了するのに、永遠とも思える程待たされる経験をするようになった。
この性能向上はドライブを多用するアプリでは大きな違いをもたらした。具体的には、ポッドキャスト用の音声編集に対する愛が私に戻ってきた。私は何年も前に Adobe Audition を標準とする事を決めたが、Audition はドライブを多用する。以前は、立ち上げそしてプロジェクトをロードするのに数分はかかったし、編集性能は貧弱なことが多く、そして編集したファイルをエクスポートするのも良く言ってトロかった。今やそれは流れるように走る。他の５人との 90 分のレコーディングを、私がホストする番組、Pants in the Boot、のために６回の回に分ける編集作業も数時間で出来た。１年前だったら、同じ様な作業をするのに、少なくとも２倍の時間を要し、そして山程のイライラを経験したであろう。それはとても心地良い経験であった。
我々誰もが大金持ちではないし、2017 年にこの iMac を買った時、私は２年間で２回目の Mac mini 故障に遭遇した。私は、余りお金をかけずに仕事に戻ろうと必死であった。お金をケチって SSD の代わりに Fusion Drive にするという決定は、それ程ひどいものだとは当初は思えなかったが、やがて痛みの伴うものとなった。
しかし、我慢しただけの価値はあった。Thunderbolt 3 SSD の性能は実質的に、内蔵 SSD 用に Apple に支払ったのと同じ程度に良い。もしこのボリュームに関して何かが悪くなったとしても、iMac を開いてみる必要も無く、私はただ単にそれを置き換えることが出来る。或いは、１，２年後には、私はそれを 2 TB 或いは 8 TB にアップグレード出来るかも知れない - SSD 価格は下がり続けている。少なくとも今の所、私は好きな Mac の一つを使っての満足感をあと数年は味わえることに満足している。今や、私はもはやその真の性能を意図せずに低下させてはいない。
何十年間もかけて、Apple はプロセッサやオペレーティングシステムの移行を数回にわたって、何とか成功裏に進めてきた。そこでは エミュレーション と 仮想化 との組み合わせが働いていた。エミュレーションはコンピュータが異なる CPU のためのコードを走らせることができるようにするもので、例えば Intel プロセッサを装備した Mac が Motorola チップのために書かれたコードを走らせるために使われる。一方、仮想化は Apple (や他の会社) が古いオペレーティングシステムをしばらくの間 (時には無期限にということもあるが) 生きながらえさせるために、一種の泡 (バブル) を作成してその中で古いコードがハードウェアのコンピュータを動かしていない事実を知らないままネイティブに走ることのできる環境を作るものだ。
Apple がエミュレーションの世界に繰り出した最新のものが Rosetta 2 だ。これは Intel ベースのアプリが Apple の M1 チップ上で走れるようにする。ただ、Mac ユーザーの Intel から Apple silicon への移行をより良いものにするために、今後さらに新たなものがいくつか登場するはずだ。例えば、仮想化アプリを使って私たちが 10.15 Catalina を、あるいはもっと古い Intel 専用版の macOS を、さらには Intel 版の Windows、Linux、その他のオペレーティングシステムを走らせられるようになるかもしれない。では、そのための障害になっているのは何だろうか？
お互いに似たような機能を提供するように見えているかもしれないが、エミュレーションと仮想化との間には大きな溝が横たわっている。機能の限られた Apple の Rosetta 2 エミュレータは、Indiana Jones で地面の裂け目の上に架かったロープの吊り橋の一つのようなものだ。ここにちゃんとした橋脚のあるハイウェイを構築してくれる者が、はたして登場するのだろうか？ ここではまず、その背後にある概念を検討してみよう。
一般的に、エミュレーションは命令のレベルで働く。通常エミュレータはコンピュータのプロセッサが持つ機能の大多数または全部をシミュレートするが、実際の CPU が実行できる可能な命令すべてのうち一部分しか処理できないこともある。エミュレータ内部でアプリまたはオペレーティングシステムがロードする際、エミュレータはその命令をエミュレータが走っているプロセッサの上でネイティブに働くバージョンの命令へと変換する。(他のエミュレータの内部にネストされて働くエミュレータさえあって、特に電話ネットワークやその他の旧来からあるシステムにそれがよくある。それからハードウェアエミュレータもあって、自分自身を再構成して他のチップをエミュレートするようにプログラミングされているチップもある！)
エミュレーションがこれほどまでに基本的なレベルで働くので、もしもホストのプロセッサが再現対象のプロセッサに比べて十分に高速でないと、動作はかなり遅くなってしまう。Rosetta 2 は Intel プロセッサのコードを M1 上で Apple silicon の命令に変換するので、macOS での必要に最適化されているとともに従来の Intel CPU に比べて十分に高速だという利点がある。
エミュレーションは実際に重要な目的のためにも使われることがある。例えば、ビジネス用の重要なソフトウェアがそのために必要なハードウェアが古くなり入手できなくなった後も走り続けられるようにするために使われる。個人用にも、世界規模の法人用にも、ソフトウェアへの投資を失わずに必要を満たすことができるからだ。とりわけ、新しいものが入手できなかったり、妥当な料金でアップグレードできなかったりする場合には不可欠だ。また、コンピュータのアーカイブを管理している人や、歴史的なマシンやゲームを愛する人たちにとっても大きな恩恵となる。Internet Archive には初期の Mac のエミュレータがあって例えば Mac 版の Oregon Trail ゲームを動かしたりできるし、さらには Adobe Flash を生き続けさせるエミュレータさえあって、保存されたアニメーションやインタラクティブなゲームなどを動かせる。特記すべきことだと思うが、それらのエミュレータはすべてウェブブラウザの中で動作する。
Intel プロセッサから Apple silicon へ移るに際しての Apple の解決策は、エミュレーションを活用することであった。ただしこれは、その上での仮想化を許さないやり方だ。Rosetta 2 は Apple の M シリーズ Mac 用の 64-bit Intel x86 エミュレータだが、これは完全機能のエミュレーション環境ではなく、32-bit アプリには対応していない。仮想化アプリのメーカー各社は、いずれ時間が経てば Apple silicon 用に独自のアプリを提供して、Apple の ARM ベースの M1 (およびそれ以後に出てくると思われる M シリーズのチップ) と互換な ARM チップのために設計されたオペレーティングシステムを走らせることができるようにするだろう。既に Parallels は M1 ベース Mac 用の ベータ版 Parallels Desktop を作っていて、これで Microsoft の ARM ネイティブな Windows プレビューが走るようにしている。Apple の ARM 実装と互換だからだ。(Parallels Desktop beta と Windows Insider プログラムの双方にサインアップすれば、Windows プレビューを無料でダウンロードできる。)
このようなエミュレーションと仮想化の違いを念頭に置いた上で、ここからは Apple が現在まで歩んできた道筋を辿りつつ、すべての Mac を Apple silicon に移行させる中でどのような将来の道筋が開けてゆくのかを考えてみたい。
Apple が歩んできたエミュレーションと仮想化の旅
私はずっと以前から、Apple がいくつもの世代の同社のハードウェアとオペレーティングシステムを越えて、いかに効果的に移行の道筋を提供してきたかについて大きな感銘を受けていた。Michael Spindler、Steve Jobs、そして Tim Cook の指揮の下に、Apple は感情に流されずに将来を見越した姿勢を一貫して保ち続けてきた。
エミュレーションと仮想化に関する Apple のタイムラインは次のようなものだ。これ以外にも細かなステップや追加すべき微妙な点はいくつかあるけれども、そういうものは Wikipedia のページを探せば見つかるだろう：
Motorola 68040 から PowerPC へ： Apple は "68K" エミュレータを作って、最新世代 68040 プロセッサのために書かれたソフトウェアが PowerPC ベースの Mac で走るようにした。これは 1994 年に始まり、2001 年の Mac OS 9.2 まで続いた。
Mac OS 9 から Mac OS X へ： Mac OS 9.04 またはそれ以降の Classic Mac ソフトウェアは Mac OS X が提供する仮想マシンの中で走った。この "Classic 環境" は 2000 年ごろの Mac OS X 公開ベータ版から利用できるようになり、2007 年の 10.4.11 Tiger まで続いた。
Parallels Desktop は、そして将来には VMware Fusion もそうなると言われているが、現在 Intel ベース Mac 上で Intel ベースのオペレーティングシステムを走らせられるのと同じように、他の ARM ベースのオペレーティングシステムをネイティブに走らせられるようになる。そこには Unix や Linux や Windows の変種も含まれる。ただし、Catalina やそれ以前のバージョンの macOS を仮想化することはできない。なぜなら、M1 ベース Mac 上で Intel オペレーティングシステムのエミュレートと仮想化を同時に実行する方法はまだ存在していないからだ。もちろんその点は将来変わるかもしれない。
Rosetta 2 の向こう側に完全なるエミュレーションはあるのか？
Apple の設計の結果として、Rosetta 2 は Intel プロセッサ上のすべての機能と活動を処理できる訳ではない。これは、macOS の内部で Mac ソフトウェアが実行するタスクのみに対応する。Apple は Mac ソフトウェアが設計されコンパイルされている全環境をコントロールするので、Rosetta 2 を構築する際に開発者たちがその環境の中で実行を許されていることのみをエミュレートするようにしたが、その環境は Intel CPU 命令のうち一部のみに依存する。
Big Sur よりも前のバージョンの macOS や、Intel 版の Windows、あるいは Intel x86 チップの上で走るように作られた他のいろいろなオペレーティングシステムをエミュレートするためには、弾力性を持ち完備したプロセッサ・エミュレータを何らかのグループまたは会社が構築しなければならない。
どうやらそこが難しいところのようだ。ARM チップ用の完全な x86 エミュレータを一つの会社が作成することができない技術的理由が存在する。Apple と Microsoft はそれぞれに部分的なエミュレータをそれぞれのオペレーティングシステム用に既に作成済みだ。皮肉なことに、いったん誰かが全面的な x86 エミュレータを作成したとすれば、Catalina より前のバージョンの macOS を許容して 32-bit アプリを走らせられるようにするのはそれほど困難なことではないだろうし、そうなれば M シリーズの Mac の上でもエミュレーションと仮想化の組み合わせを使って古いアプリを使い続けることができるだろう。
完全なプロセッサ・エミュレータを構築しなかった Apple の動機の正確なところは私たちには分からない。Apple が Catalina で 32-bit 互換性を切り捨てた理由として私たちが推測できるのは、おそらく M シリーズ Mac の上で走る Rosetta 2 にかかるパフォーマンスとテスト作業の負担を考慮しての結果だろうということくらいだ。そのすべてを、大多数の顧客に大きな利益を提供しつつ実現しなければならないのだから。Apple は長い年月を費やして開発者たちや Mac ユーザーたちを 32-bit アプリから引き離そうと努め続けてきた。加えて、Apple による移行は通常すべての人を可能な限り素早く最新のテクノロジーにシフトさせることを狙っているのだから。
さらに法律的な懸念もあるかもしれない。Intel は 2017 年に Microsoft と Qualcomm に対して皮肉めいた言葉を発して、その中で Qualcomm 製のチップのための ARM ベースのバージョンの Windows が何らかの x86 命令をエミュレートすればそれは法的手段に直面することになるだろうと匂わせた。Intel は長い年月と何世代ものチップにわたって命令セットを発展させてきており、一部の x86 命令は特許権の保護下にあり、残りのものはもはや保護されていないという状態にある。細かな点は訴訟を通じてのみ明らかにされ得るものであろうし、極めて面倒で長期にわたる民事訴訟へと結び付くに違いないだろう。(実例として、Oracle は最近になって 11 年もの長い期間にわたって Google を相手に争ってきた知的所有権訴訟に敗訴した。これは、Google が Android で互換バージョンの Java を使用していることを巡るものであった。争いは延々と最高裁判所まで続いた。)
けれども Intel が咳払いをした後にまだ訴訟は起こされていない。Microsoft は ARM 用 Windows と共に自社の 32-bit x86 エミュレータをリリースし、その後 2020 年 12 月に 64-bit x86 エミュレータを追加した。Intel の暗黙の脅迫には小規模の会社やオープンソースの取り組みを抑止する効果があったかもしれない。誰も、数十億ドル規模の大会社を相手の争いに巻き込まれたくはないからだ。ただ、その証拠もまた、どこにも存在しない。もしその種の脅迫が実際になされたならばオープンソースの開発者たちはためらわずに警鐘を鳴らすだろうから、そういう事態になればきっと私たちの耳にも聞こえてくるだろうと思う。
Sonny Software が Bookends 13.5.3 をリリースして、この文献参照管理ツールに個別添付物マネージャを付けて更新し、どの開いたライブラリにも付属していないファイルのリストを生成できるようにした。今回のアップデートではまた、Autocomplete Paper で新規に参照物を添付する際にメタデータから PDF の title と subject を読み込むようにし、表示枠の中にある画像を Finder やその他のアプリにドラッグできるようにし、PDF を別のアプリケーションに表示させるオプションとして PDF Viewer を追加し、BibTeX key を生成する際にアポストロフィーを含んだ名前がエラーを起こしていたバグを修正し、何百個もの PDF を一度に添付しようとすると起こることがあったエラーに対処し、クラウド内の既存のライブラリにリンクさせようとすると起こったクラウド同期の問題を解消している。(新規購入 $59.99、TidBITS 会員には 25 パーセント割引、96.2 MB、リリースノート、macOS 10.13+)
The Pixelmator Team が Pixelmator Pro 2.0.6 をリリースして、Tools サイドバー上のツールの上にマウスをかざすと現われるビデオツールチップを追加した。このツールチップは Pixelmator Pro の環境設定でもオン・オフできるし、ツールチップを閉じる際に Option-クリックすれば環境設定を開かずにオフにできる。この画像編集アプリはまた、Automator で Change Type of Images アクションを使う際に WebP ファイルフォーマットが使えるようにし、Finder の Get Info ウィンドウからコピーしたアプリのアイコンを (ようやく！) ペーストできるようになり、選択域を図形に変換した後に Style ツールが自動的に選択されるようにし、カラー調整がマスクに正しく働くようにし、テキストレイヤーを含むグループレイヤーをリサイズした後に個々のテキストレイヤーがぼやけてしまったバグを修正し、Photos の中の Pixelmator Pro 編集拡張で gradient color stop が正しく働かなかった問題を解消している。(Pixelmator からも Mac App Store からも新規購入 $39.99、無料アップデート、273.6 MB、リリースノート、macOS 10.14.4+)
