Showing posts with label macOS. Show all posts
Showing posts with label macOS. Show all posts

2024-11-04

わたしのデスクトップ環境にマシンが1台追加

長く面倒な内輪の対応処理にようやく完了の道筋が見え、久しぶりにブログに戻って来ることができました。
めったに出来ない体験ではあったのでお役立ち情報になる部分は改めて整理してお知らせしたいと思いますが、今日は趣味の分野のブログに復帰させてください。

わたしは以前からデスクでは、MacとWindows機をUSB-Cのオスメスケーブルの物理的な差し替えで、切替えて使っています(以前の投稿「わたしのミニマルデスクをご紹介」)。
物理切替えにしているのは、USBの切替え機は周辺機器用のものはいろいろありますが、USB-C DP Altまで対応したものはほとんどないし、あったとしても業務用的な超高価なものだからです。

今回、この切替え運用にもう1台のマシン、iPad Proが加わりました。

というのも、Apple Intelligence 対応の iPad mini の発売を期待して待っていたのですが、ふたを開けてみると chip が A17 Pro で外部ディスプレイはミラーリングのみと、わたしの期待に一歩足りませんでした。
ならばということで、このタイミングで M2 iPad Pro の中古をイイ感じの価格で手に入れました。
なお、後で知ったのですが、Apple SiliconのM1/M2/M4 iPad Proにはメモリサイズが8MBと16MBのものがあり、ストレージ容量の1TB以上を選ぶと16MBになるので、絶対的なパフォーマンス重視の方は間違えないよう注意が必要です(もちろん差額はかなり大きめです)。
わたしのiPad Proの遍歴は、初代 9.7inch 2016、第1世代 11inch 2018と来ていたので、今回のM2第4世代11inch 2022のベースモデル8MB 128GBでもかなりのジャンプアップで、十分に高い満足度です。

物理的なUSB-Cの切替えではありますが、MacとWindows機とiPad Proの3台のマシンに対して、外部ディスプレイとお気に入りのキーボードとトラックパッドそれに有線LANアダプタを、瞬時に同時に切替えて使用できるようになりました。
Bluetooth接続のキーボードやトラックパッドだったり、ディスプレイ側の入力切替えでは、こう簡単にはいかないですよね。
外部ディスプレイがUSB-C対応ではない場合でも、パソコン側が対応していれば、HDMI出力付きのUSB-Cドックを各マシンに差し替えるやり方でも同じように切替えができると思います。

iPadのアプリをパソコンと同じように外部ディスプレイに広く表示できるのは、iPadとしては驚きの革新的な高機能ですし、作業に集中できるすっきりした画面はWindowsにもぜひとも見習ってほしいなと思いました。
わたし自身の経験としても、ここ数年まえから、文章を書くのにWindows機(のごちゃごちゃした画面で集中できず)で煮詰まったときは、続きをiPadでやることでうまく行って助けられたことが実際に何度もあります。

Apple Intelligenceは、OSの言語設定を英語にすれば、もう使えるようになっています。
これって昔々、Mac OS System 4に漢字TalkとかSweetJAMを入れていたころのような感覚を思い出します。
さらに、アプリ毎に表示言語を日本語に設定できるようになっていて、その状態のアプリでも英語の内容に関してはApple Intelligenceが効くので、皆さんもぜひお試しください。
3月に出るであろうiPadOS 18.3/macOS 15.3でのApple Intelligenceの日本語対応がますます楽しみですね。

 

[2024-11-09] MSWordで下書きしたものをそのままwebのBloggerに貼り付けたら、Officeの余分なhtml tagがついていたのを、手で削除しました(いつも困りますね、プレーンテキストコピーがほしい)。

2022-06-16

Apple Silicon macOSのRosetta 2が進化して、仮想Arm Linux内でx86バイナリの実行をサポート

今日はApple Silicon Macの仮想化とIntelエミュレーションに関して2つの話題を書いてみたいと思います。

先日のWWDC22でmacOS 13 Venturaが発表されました。
盛りだくさんの新し機能の中で私が一番だと感じたのは、やはり、仮想環境の中でIntel x86バイナリの実行が出来るようになることです。
ただし、手放しに喜べる機能ではなくて次の使い方に限定されたものです(Apple Developerサイトの解説)。

  • Virtualization Frameworkを使ってArm版のLinuxを起動する
  • Linux内でmacOSが提供するツールのおまじないを設定する
  • Arm Linuxの上でRosetta 2を使ってx86用のバイナリを実行できるようになる

x86のLinuxを直接実行できるとか、ましてやx86 Windowsを実行できるなどは、まだです。
Linuxではなくて、Arm Windowsの中でx86のWindowsアプリを実行する場合には、引き続きMicrosoftのツールを使うことになります。

Rosetta 2のx86エミュレーションはApple Siliconの非公開機能を使用しているのでとても高速に動作します。
また、現状のmacOSの仮想化機能では、仮想OSの中で仮想化機能を使用すること(Nested Virtualization)はまだできません。
今後も徐々にRosetta 2やVirtulization Frameworkの適用範囲が広がっていってほしいと願います。

 

[2024-06-13] x86バイナリのコンテナもそのまま実行できるような環境が整備されてきました。
Docker DesktopやLimaのコンテナ実行環境で、直接Rosetta 2を利用するための 「Linux内でmacOSが提供するツールのおまじないの設定」が適用されるようになったようです。

macOSはLinuxそのものではないので、Docker DesktopやLimaはコンテナ実行マシーンを作成し、リモート環境としてコマンド接続してコンテナを実行するひつようがあります。
dockerコマンドだと、環境変数 DOCKER_HOST 指定、または .docker/config.json の Host 指定、あるいは context での指定、あるいは廃止になった以前の機能なら docker remote xxx をしているのと同じですね。
もっとシンプルなpodmanコマンドなら --remote と --connection の指定をしているのと同じです。

2022-06-02

iPad Pro専用のiPadProOSがmacOSと共通化すればよいはず

Apple Siliconへの移行の仕上げの年のWWDC22開催までいよいよ1週間を切りました(キーノートのページ、WWDC22の全体目次ページ)。

前回の書き込みで指摘したように、Apple Silicon M1になったiPad Proは、処理性能面では完全にMacBook Airと同じものと言えます。

iPadに対してiPad Proのプレミアを付けて、iPadOSから派生してiPadProOSだけをmacOSと統合すればよいのです。
あるいは、むしろ逆にmacOSにiPadOSのタブレット由来機能を統合して、MacBook AirとiPad Proを共通化すればよいのです。

MacBook Airのディスプレイ部分とボトムパーツが分離できるようにして、あるいはiPadにフロ-ティングMagic Keyboardを付けた状態がMacBook Airみなしの状態になって、分離した状態では純粋はiPad Proタブレットモードとしての利用状態になり、一体化した時または外部ディスプレイとキーボードを接続した時にはmacOSモードでマルチウィンドウの動作になる、という仕組みです。

このiPad ProとMacBook Airのハイブリッドマシンは、あえて安価にしなくてもよいので、是非とも実現して欲しいものです。
iPad ProでもMacでもない、Apple Siliconによって生み出された新たなカテゴリの製品としてでも良いかもしれません。

さらに、iPad miniサイズやiPhone Pro Maxサイズで、ポケットに入るMacというものもとてもあこがれます。
これ、最高にわくわくしてしまいますね。


2022-05-23

iPad ProのmacOSモードは永遠の夢物語か

MacRumorsの記事Apple Patent Suggests Future iPad Could Transform Into macOS-Like Experience When Attached to a Keyboardから

Apple Siliconの登場後、とうとうiPad ProとiPad AirにまでM1チップが搭載されました。

macOS側は、Mac CatalystによってiPadアプリとmacOSアプリのソースコードを共通化できるし、実行環境としてはiOSとiPadOS用のアプリをそのまま実行できるようになっています。

MacBookシリーズが電源と外部ディスプレイとキーボードを接続するとクラムシェルモードになるように、iPad Proもドッキングステーションに繋げたらmacOSモードになったら、とてもスムーズですよね。
これ、見ようによってはSurface Proと同じなのですが、タブレットとしてはiPadOSの方が断然使いやすいので、別物として忘れてよいと思います。

以前のわたしの書き込みでも、MacBook Air(あるいは12インチMacBookの復活版)の新筐体デザインとして、ディスプレイ側にロジックボードを組み込む方式を妄想しました。
そもそも、すでにMacBook AirとiPad Proのロジックボードはほとんど同じサイズなのだし、どちらもファンレス、CPU+メインメモリも共通、SSDストレージオプションも全く品揃えです。

現在のMacBookシリーズで一番嫌いな点は、ディスプレイを最大限開いた時の角度が少なすぎて、とうてい水平にならない点です。
このせいで、外部ディスプレイを接続する時に内蔵ディスプレイがどうしても邪魔をしてしまうので、せっかくのとても使いやすいキーボードとトラックパッドを使うのを泣く泣くあきらめて、外部キーボードと外部トラックパッドで使わざるを得ないことになります。
外部ディスプレイを接続してクラムシェルモードにしてしまうと、せっかくの良質の内蔵のディスプレイ、キーボード、トラックパッドがすべて無駄になってしまいます。
iPad ProにキーボードをつないでmacOSモードで使えるようになるのであれば、一組のキーボードとトラックパッドだけを所有していればよいことになるし、iPad本体もセカンドディスプレイあるいは超大型のタッチバーあるいはペン入力デバイスとしてそのまま活用出来て無駄がありません。

iPadOSにも、マルチウィンドウ操作用の3つのドットが画面上部に出るようになって、もうゴテゴテしてきています。
この際ですから、macOSと共通化してしまった方がすっきりしそうに思います。

2022-01-08

Apple Silicon MacでこんどはmacOSを仮想化ゲストとして動作可能に(UTM app)

手元のM1 MacBook Airは貴重なApple Siliconマシンなので、いろいろ無茶をして実験することができないでいました。
このたび、私のお気に入りのUTM appがこの状況の打開策を出してくれました。

UTM app 3.0では、仮想化ゲストOSとしてmacOSを動かせるようになります。

v3.0.1ベータが2022年1月9日公開され、以下の問題は修正ずみ、きちんと動作します。
《残念ながら、現在公開されているv3.0.0ベータ(2022年1月1日公開)では、macOSゲストのVM作成処理の最後のステップで、設定パラメータの判断エラー ("AuxiliraryStorage" is nil. のエラーメッセージ) が発生してゲストの作成に失敗してしまいます。
この問題に対してースコードは修正済みなので、git cloneして頑張ってビルド(一部手を入れる必要があり(後述)、時間も1時間くらいかかります、わたしはビルドを通すための試行錯誤にさらに2日ほど要しました)すれば問題なく動作します。
本家でもそれほど日を置かずに新しいビルドが公開されると思うので、わたしのようなよっぽどの新しい物好きじゃない限り、少し待つのが良いと思います。》

右の画像が、macOS 12.1 MontereyをApple Silicon Macで実際に仮想ゲストとして動かした様子です。
現在の動作状態は以下のようになりますが、不足機能はどんどん改善されていくと思います。

  • CPUは「Apple M1 (Virtual)」と認識されます。コア数やメモリサイズは設定で変更できます。メモリサイズはデフォルトは4GBですが、6MBくらいにしないと最初のインストールに時間がかかってしまうと思います。
  • CPUエミュレーションではなくて、macOSのVirtualization Frameworkが直接使用されるのでフルスピードで動作します。
  • ディスプレイは初期状態では、物理1920x1200、Retina表示で960x600の固定サイズになります。仮想ゲストのウィンドウの大きさを変更すると表示内容が拡大縮小されます。ディスプレイサイズもUTMの設定で変更できます。
  • 仮想ゲストとホストの間のコピペはまだできません。
  • Magic Trackpadの右クリック(2本指タップ)は少し効きが悪くて、タップしてホールドしたまま少し指を動かすと認識されます。
  • macOSのOSイメージは
    ~/Library/Containers/com.utmapp.UTM/Data/Library/Caches/UniversalMac_12.1_21C52_Restore.ipsw
    にダウンロードされます。通常のインストーラとは違う形式で、リカバリイメージを使用するようです。サイズは13GBです。
    このキャッシュファイルは何かのタイミングですぐに消されてしまうので、
    ln ~/Library/Containers/com.utmapp.UTM/Data/Library/Caches/UniversalMac_12.1_*.ipsw ~/Downloads/
    などのコマンドでコピーしておくのがおすすめです。
  • 仮想ゲストは
    ~/Library/Containers/com.utmapp.UTM/Data/Documents/ゲスト名.utm/
    に作成されます。ディスクイメージは最大容量 (例60GB、lsで見た時) で作成されますが、macOS APFSのcopy-on-write機能 (CoW) のおかげで実際の占有サイズは初期20GB程度 (duで見た時) です。
  • 初回起動時に Would you like to install macOS? というメッセージが出て、macOSインストーラが走ります(逆に何かの理由でこのメッセージ出なかった時はVMの作成をやり直さないと一切先には進みません)。インストールは5分くらいで終了します。ものすごく速いと思います(macOSのOSパッチ適用はApple Siliconの場合でも、iOS/iPadOSのインストールはクリーンインストールでも、小一時間かかりますよね)。M1 Macの初期インストールの様子は(Intelと同じですが)今回初めて実施に目にすることができました。

 

UTMをソースコードから自分でビルドする場合のコツを、ご参考用、かつ自分用のメモとして以下に書いておきます。

  • 基本的な手順はUTM appのgithubのここに書いてある通りです。
    わたしはhomebrewよりむしろmacports派なので
    sudo port install glib2 libgpg-error nasm meson gmake
    で不足ツールを事前インストールしました。さらにmacOS付属のbisonが要件に満たないバージョンなので
    sudo port install bison
    もしました。
  • ./scripts/build_dependency.sh -p macos -a arm64
    は30分以上、
    ./scripts/buid_utm.sh -p macos -a arm64
    は5分くらいかかります。膨大なログが出るのでエラーメッセージを見逃しがちです。実行後、ターミナル上で Cmd+F Error: で検索して確認した方が良いです。
    後者のビルドは UTM.xcodeproj をXcodeで開いて行うこともできます。
  • どうしても #include のパスが解決できないため、ソースコード中のインクルードファイルのパスをフルパスに書き換えたソースが
    ./build-macOS-arm64/qemu-6.2.0-utm/include/qapi/qmp/qobject.h
    です。
    ファイルが欠落していて別途追加ダウンロードしたものが
    ./Platform/Shared/HTerm/libapps
    の配下のファイルで、githubのhtermからダウンロードしました。
  • 全てのソースコードをダウンロードしてビルドするには22GBのディスク容量が必要です。

 

Apple Silicon Macでできることがどんどん広がって、ますます無敵感が高まっていきますね。

[2022-01-08] 初出では思い込みでqemuのhvf (macOSのHypervisor Framework) を使用していると書いてしまいましたが、qemuを経由せず、macOSのもう一つの仮想化FrameworkであるVirtualization Frameworkを直接使用するようになっています。
その証拠に、macOSの仮想化ゲスト(とLinuxでApple Virtualizationを選んだ場合)ではゲストシステムの詳細設定オプションがqemuとは違うものが表示されます。
macOSが提供するこの2つの仮想化Frameworkは、ゲストOSのブートの仕方が違うだけでどちらも高速動作します。
Intel CPUをエミュレーションしてLinuxやWindowsを仮想化で実行する場合にはこれらのFrameworkを使用できないのでApple Siliconやarm64に比べて数倍遅くなるのです。
macOS上で動くアプリやコマンドであれば、Rosetta 2で実行され数割の減速ですみます。
[2022-01-09] v3.0.1ベータが出て初期設定の問題が解消しました。
[2022-01-10] もしやmacOS 11も実行できないかと、UTMのソースコードのバージョンチェック箇所をいじくってやってみましたが(転んでもタダでは起きない)、初回起動のBig Surのセットアップの早い段階でエラーになって、これはダメでした。
"macOS on Apple Silicon Mac" の機能は、おそらくホスト側とゲスト側の両方にMontereyでの追加機能が必要なようです。
複数バージョンは今はできないことが分かりましたが、
macOS 12のクリーンインストール環境がいつでもすぐに(5分程度)いくつでも(ディスクが許す限り、外付けディスクに逃してやることも容易)、手に入るのはとても偉大な進歩です。
[2022-01-12] ネストされた仮想化 (nested virtualization、入れ子の仮想化、仮想化ゲストのmacOSの中でさらに仮想化ゲストを実行する (qemuの(遅い)エミュレーションは大丈夫)) はmacOSの制約?のためにまだできないようです。

2021-11-03

Apple Silicon M1シリーズmasOSのCPUコアやGPUの使用率/使用電力を詳しく見るには powermetrics コマンドと、ちょっとした工夫で見やすく

本記事の最後に、何ができるかを掲載しましたので、お急ぎの方はそちらへどうぞ
Apple SiliconがM1/M1 PRO/M1 MAXとシリーズ化されてきました。
パーソナルコンピュータとしては画期的なSoCになって、たくさんのCPUやGPUを積んでいます。
それにもかかわらずアイドリングじの電力消費はスマホ並です。

macOSはLinux系のOSなので、システム稼働状態を見るのに一番有名で手っ取り早いのはtopコマンドです。
ターミナルアプリを開いて次のコマンドを打ちます。

% top

OS全体およびプロセス毎のCPU使用率、メモリ使用量が動的に表示されます。
1秒毎の表示間隔で書き換えられますが、これが早過ぎる場合にはキーボードから s5<Return> と打つとたとえば5秒毎に変更できます。

次に、macOSでもっと有名で老舗なのが Menu Meters です(Menu Metersの最新版の公式サイト)。
ダウンロードしたzipファイルを展開して、/Applications フォルダにコピーして使用します。
Menu Metersではコア毎のCPU使用率、メモリ使用率、ネットワーク使用量をメニューバーに常駐したグラフで見ることができて便利です。

でも、高性能コアと高効率コアにそれぞれどれくらいの負荷がかかっているのか、動作周波数がどうなっているのか、消費電力がどうなっているのか、もっと詳しく知りたくなりますよね。
はい、そんな場合には、macOS専用のコマンドの powermetrics があります。

powermetrics も top と同じように、ターミナルアプリです。
次のコマンドで起動します。

% sudo powermetrics

powermetrics は管理者向けの特権コマンドなので、前に sudo というおまじないを付けて、(私は管理者ですよ、と宣言するために)パスワードを入力して起動します。
他にコマンドオプションを何も指定しないと5秒毎の状態が繰り返し表示されます。
止めるには Ctrl/C を打ちます。
もっと手早く1度だけ表示したい場合は、次のようにします(-i 1000 の部分は表示間隔のミリ秒指定、-n 1 は繰り返し回数です)。

% sudo powermetrics -i 1000 -n 1

このままでは情報量が多すぎて追っかけられないですよね。
内容をCPUとGPUの情報に限定するには次のようにします。

% sudo powermetrics -i 1000 -n 1 --samplers cpu_power,gpu_power

これでなんとなくわかるレベルになったと思います(最後に出力を加工した実際の表示結果を掲載しています)。
E -Clusterのところが(省電力の)高効率コア、P-Clusterのところが高性能コア、それとGPUの、それぞれの動作クロック数、使用率%、使用電力が表示されます。

少し長いですが、次のようにすると繰り返し表示でも一目瞭然の内容に絞り込んだ表示になります。

% sudo powermetrics -i 5000 | \
sed -u 's/(\(.*\) \([0-9]\{1,\}\) MHz:[ 0-9.]\{2,\}%)/<max \2 MHz>/' | \
grep -E 'active freq|[0-9] active resi|GPU active resi|Power:|Sampled|Machine model|OS version'

<> の中のMHzには、それぞれのコアの最大クロック数が表示されるようにしています。
最大クロックに対して、現在の動作周波数はactive frequencyのところのMHzなので、コアの使用率%はこの動作周波数に対する%と考える必要があります。

何度もこのコマンドを入力するのは大変(もちろんコピペでOKなのですが)なので、次のように定義しておけば p5 と打つだけで同じことが実行できるようになります。

% alias p5="sudo powermetrics -i 5000 | \
sed -u 's/(\(.*\) \([0-9]\{1,\}\) MHz:[ 0-9.]\{2,\}%)/<max \2 MHz>/' | \
grep -E 'active freq|[0-9] active resi|GPU active resi|Power:|Sampled|Machine model|OS version'"
% p5 

この定義は、次のように .zprofile ファイルに入れておけば、ターミナルを次回以降起動したときにすぐに使えるようになります。

% touch ~/.zprofile   # 以下の手順がエラーしないようにおまじない
% less ~/.zprofile # 事前の内容確認
% cp ~/.zprofile /tmp/.zprofile.backup # 念のためにバックアップコピーを作成
% # 次のコマンドで .zprofile ファイルにaliasコマンドを追記します
% cat >> ~/.zprofile
alias p5="sudo powermetrics -i 5000 | \
sed -u 's/(\(.*\) \([0-9]\{1,\}\) MHz:[ 0-9.]\{2,\}%)/<max \2 MHz>/' | \
grep -E 'active freq|[0-9] active resi|GPU active resi|Power:|Sampled|Machine model|OS version'"
ここで Ctrl/D を入力
% less ~/.zprofile # 追加内容の確認

最後に、p5コマンド(powermetrics コマンド+上記のα)の実際の表示内容を付けておきますM1 MacBook AirでIntel Windows 10を動かして最大負荷をかけた状態です)。

% p5
Machine model: MacBookAir10,1
OS version: 21A559
*** Sampled system activity (Wed Nov 3 11:22:25 2021 +0900) (5019.73ms elapsed) ***
E-Cluster Power: 1221 mW
E-Cluster HW active frequency: 2064 MHz
cpu 0 active residency: 98.32% <max 2064 MHz>
cpu 1 active residency: 97.68% <max 2064 MHz>
cpu 2 active residency: 97.23% <max 2064 MHz>
cpu 3 active residency: 97.12% <max 2064 MHz>
P-Cluster Power: 11246 mW
P-Cluster HW active frequency: 2988 MHz
cpu 4 active residency: 99.72% <max 3204 MHz>
cpu 5 active residency: 99.62% <max 3204 MHz>
cpu 6 active residency: 99.64% <max 3204 MHz>
cpu 7 active residency: 99.41% <max 3204 MHz>
ANE Power: 0 mW
DRAM Power: 435 mW
CPU Power: 12468 mW
GPU Power: 409 mW
Package Power: 13620 mW
GPU active frequency: 396 MHz
GPU active residency: 40.17% <max 1278 MHz: 0%>
GPU Power: 409 mW
%

ほんの少しマニアックですが、Apple Silicon M1シリーズの動作状態がよく分かるようになると思います(M1の最大クロック数(E-Core/P-Core/GPU)が、2.06GHz、3.20GHz、1.28GHzであることもこれでハッキリしますね)。
自分が普段使っているアプリの中のどの操作がどういう負荷になるのか、色々調べてみると面白いと思います。
M1 PRO、M1 MAXをお持ちの方は、表示結果をコメント欄で共有していただけるとありがたいです(匿名可能です)。

[2021-11-03] 初出に追加して、機種名とmacOSバージョンも表示されるようにしました。

2021-07-07

M1 iMac 24inchにやっと遭遇、感想とその先への希望

5月に発売されたApple Silicon M1 iMac (24inch) を先日、店頭でやっと見てきました。
第一印象は、11.5mmというスペックの割には結構分厚いな、でした。
以下デザイン面に関する感想と考察です。

  • 意外と実際よりも分厚く感じました。
    M1 MacBook AirとMacBook Proの最厚部はそれぞれ、16.1mmと15.6mmでM1 iMacより厚いはずなのですが、これらは端に向かってなだらかに細くなっていて、実際よりも3割以上薄く感じるようになっています。
    これに慣れてしまっているがために、M1 iMacを分厚く感じてしまったのだと思います。
    極限まで細くしたIntel iMacの端面(3mmくらい?)の記憶のせいもあると思います。
    もちろん、たまたま横に置いてあったPro Display XDRの27mmに比べると半分の厚みだったのですが。
  • 厚み比較で感覚的に合うのは、iPad Pro 2枚分。
    iPad Proはフラットな形状で5.9mmなので、ちょうど2枚分になります(11inch版)。
  • 前面の素材は質感的にプラスチックのようです。
    側面のアルミニウムボディーと全面パネルの境界にわずかながら隙間があります。
    前面パネルを立体整形してうまくはめ込んでいるのだと思いました。
    画面の輝度がとても高いのもあって、反射は全く感じられませんでした。
  • あごなしデザインに納めて欲しかったと。
    写真で見ていると、下のあごの部分は、iMacのデザインアイデンティティになっていて良い感じです。
    でも、実物を見てみると、とても邪魔に感じてしまいました。
    きれいなパステルカラーなのでなおさらかもしれませんし、普段使っている外付けディスプレイに慣れているからかもしれません。
    iPad Proは1枚分の厚みの中に全て納めているのだし、電源をACアダプタに外出ししているのだから、M1 iMacもあごなしにできる可能性は大いにあったはず、と考えてしまいました。
  • 雑味の無いスピーカーは確かに良いようです。
    ヘッドホンジャックがきちんと付いていることからも、このマシンをサウンドを入出力するメインのマシンにして欲しいことが伝わってきます。

2021-06-09

WWDC2021 - Apple Siliconについて一切触れられなかったのはなぜ、顔出しなしのミー文字なのはハードウェアの発表ができなかったお詫びか?

いつもながら内容盛り沢山なWWDCが今年も始まりました(developer.apple.com内のページ)。
え、本当にみんなそう思ってます?
確かに5つの全てのプラットフォーム(iOS, iPadOS, watchOS, tvOS/HomeKit, macOS)での盤石な更新はありました。
しかしながら、ハードウェア、特にApple Siliconについて何も触れられなかったのはなぜなのでしょう。
いつもなら最低でも、Apple Siliconは発売からxx%もxxしたとか、アプリの移行が50%以上進んだとか、キーノートスピーチでしか聞けないような成果や予定があって然るべきだし、当然期待しています。
もしかして、半導体不足がかなり深刻で、ハードウェアの生産見込みが業績に影響が出るほどで、需要をトーンダウンさせたい意志が働いているのでしょうか(iPhoneは多少遅れてでも出さない訳にはいかないので全ての生産をそこだけに集中させている)。
それとも、新製品の発表が直前のバグか何かで出来なくなってしまったのでしょうか。

矢継ぎ早だったApple Silicon版 MacBook Air / MacBook Pro / Mac mini / iMac / iPad Pro の発売開始のペースに慣れた私たちユーザにとって、一切何も話がないというのは期待外れというか、お預けにされてしまった感が強いです(他のサイトではこの気持ちをなかなか代弁してくれていないも不思議ですが)。
私などは、Appleサイトの役員ページがミー文字に入れ替わったのは、ハードウェアが発表できなかったお詫び、遺憾の気持ちから顔出しできなくなったのかと、真っ先に勘繰ってしまいました。

とは言え、事前予想の答え合わせ会をうまく回避した、とも言え、その点はとても素晴らしかったというか、本来のキーノートらしさを取り戻した嬉しい誤算だったと思います。

さて、私にとって気になったWWDCキーノートの5大トピックは以下です。

  • FaceTimeがAndroidやWindowsでも使える、FaceTime Link(ミー文字作成まではwebでもできたとしても動かすのはFaceTime Cemeraとアプリじゃないと無理ですよね)
  • MessagesにはMessages LinkやiCloudサイトでの扱いは無し、あくまでインタラクティブにやりとりするショートメッセージとしての位置付けからか?
  • Walletが運転免許証などのライセンスカードが扱えるように
  • iPad(とおそらくmacOS)のSwift PlaygroudからApp Storeにアプリをリリース可能に(じつは私もSwift Playgroundのリリース当時にこの機能は予想・期待していました、なお当時はまだiOSとiPadOSが分かれていませんでした)
  • ShortcutsがmacOSにも(私はまだ全然活用できていないので、今後の研究課題です)

それと私からのOne more thingです。

macOS Monterey(モントレー)のバージョン番号はmacOS 12になるようです。
developer.apple.comのページに”macOS 12 SDK”とひっそり書かれているのを見つけました。
iOSのようにどんどん数字を大きくしていくんですね。
これでバージョン99まで70年以上は番号の心配がなくなりましたwww。
(ところで、去年のEngadgetの記事に『アップル、Swatchに「One more thing」の商標を取られる』というのがあって気になりました)

2021-05-02

私のMacBook AirのUS配列のキーボードをカスタマイズして、左端の一番の特等席をCtrlに

カスタマイズ後の私のM1 MacBook Airのキーボード

MacBook Air/ProのUS配列キーボードや、外付けコンパクトキーボード(テンキー無しキーボード)でどうしてもしっくり来ないのが、左下端のfnキーです。
この位置は、手探りでも間違いなく確実に押せるいちばんの特等席なのに、通常のタイピングでは全く使わないfnキーが置かれています。
ターミナルでのコマンド操作や、リモートデスクトップでのWindowsへの接続ではCtrlキーをよく使います。
この場所はWindows機でよくあるようにCtrlキーになっているべきです。
JIS配列(日本語配列)のキーボードの場合、Ctrlキーは文字Aの左(US配列でのCaps Lockの位置)にあってとても優遇されているのに比べると、ひどいものです。

MacBook Air(とMacBook Pro、それにテンキー無しの現行のMagic Keyboard)をよく見ると、都合の良いことに、fnキーとCtrlキーのサイズが同じなので、入れ替えられそうに見えます。
キーの手前の左右の角に精密ドライバを差し込んで、注意深く持ち上げてやると、パチンと爪が外れ、そのまま手前にずらすとキートップを取り外せます。
この要領で、MacBook AirのfnキーとCtrlキーを入れ替えたのが右の写真です(ちなみにMicrosoft Lensアプリで写真を長方形に綺麗に補正しました)。

最初はどことなく違和感を感じますが(どうでしょう、あなたは違いに気づきましたか?)、目はすぐに慣れますし、なによりCtrlキーの押しやすさに雲泥の差が出ます。

物理的にキートップを入れ替えただけではもちろん動作は変わりません。
キーカスタマイズアプリの定番、Karabiner Elementsを使って、キーを押した時に入力されるキーコードを入れ替えてやる必要があります。

【fnとCtrlを入れ替え】
設定は簡単で、2番目の画面のように、[Simple modifications] タブで、fnをleft_controlにお互いに入れ替えるだけです。
[Target device] のところは、規定値の [For all devices] でも良いのですが、他の外付けキーボードを接続した時のことも考えて、私は [Apple Internal Keyboard / Trackpad (Apple Inc.)] を指定しました(本体のキーボード以外ではこの入れ替えを実行しない)。

物理的なキートップの入れ替えまでやらないにしても、Karabiner ElementsのfnとCtrlの入れ替え設定は、Ctrlキーを多用するUS配列の方には是非とも試してみていただきたい設定です。


以下、長くなりますが、私がKarabiner Elementsで設定しているあと3つの便利な設定を紹介したいと思います。
いずれも [Complex modifications] で設定するものです。

【Ctrl+DeleteをDelに】
WindowsではBackspaceキーで左の一文字が削除、Delキーで右の一文字が削除されるので、カーソル位置の文字を消したい時に一発で行えてとても便利です(カーソルを消したい文字の右側に移動してから削除とやらなくて良い)。
もしかすると、それほど知られていないかもしれませんが、Macでは、fn+DeleteでWindowsのDelのように右側の一文字削除を行えます。
今回fnとCtrlを入れ替えたがために、fn+Deleteが押しにくくなってしまいました。
これをカバーするために、Ctrl+DeleteでもDelが実行されるようにしたいと思います。

この設定は Karabiner Elements にテンプレートとして用意されています。
[Complex modifications] の [Add rules] ボタンを押した後、
[Import more rules from the Internet (open a web browser)] を押し、
開いたブラウザの中で "backspace" を文字列検索し、見つかった [Map Ctrl+Backspace-Delete to Fn+Backward-Delete (suppr current character)] を
[Import] します。
すると一覧に [Map Ctrl+Backspace-Delete to Fn+Backward-Delete (suppr current character)] が表示されるので [Enable] します。

【Caps Lockキーで日本語英語入力切り替え、ただしリモートデスクトップでは何もしない】
US配列キーボードで日本語を入力するには、メニューで [あ] を選んでも良いのですが、M1 Macではfnキーに地球儀マークがありこのキーで切り替えることができます。
さらにキーボード環境設定の [入力ソース] タブの [Cpas LockキーでABC入力モードと切り替える] にチェックを入れると、Caps Lockキーを日本語英語切り替えに設定できます。
このCaps Lock設定を行うと、リモートデスクトップで接続先のOSに対して本来のCaps Lockキーが送信されなくなってしまい、とても不便です(WindowsでもCaps Lockキーを日本語英語切り替えに設定している場合には動作しなくなる)。
Karabiner Elementsを使うと、この悩みを解消することができます。

Karabiner Elementsの [Complex modifications] では、対象アプリを絞ったり、除外したりしてキー割り当てのカスタマイズを行うことができます。
テンプレートとして用意されていない設定は、設定ファイルを作成することで対応します。
フォルダ /Users/your_user_name/.config/karabiner/assets/complex_modifications に以下の内容のJSONテキストファイルを作成します。

{
  "title": "For Japanese",
  "rules": [
    {
      "description": "Caps_lock to Toggle ja/en unless RDC",
      "manipulators": [
        {
          "type": "basic",
          "conditions": [
            {
              "type": "frontmost_application_unless",
              "bundle_identifiers": [
                "^com\\.microsoft\\.rdc\\.macos$"
              ]
            },
            {
              "type": "input_source_if",
              "input_sources": [
                {
                  "language": "ja"
                }
              ]
            }
          ],
          "from": {
            "key_code": "caps_lock",
            "modifiers": {
              "optional": [
                "any"
              ]
            }
          },
          "to": [
            {
              "key_code": "japanese_eisuu"
            }
          ]
        },
        {
          "type": "basic",
          "conditions": [
            {
              "type": "frontmost_application_unless",
              "bundle_identifiers": [
                "^com\\.microsoft\\.rdc\\.macos$"
              ]
            },
            {
              "type": "input_source_if",
              "input_sources": [
                {
                  "language": "en"
                }
              ]
            }
          ],
          "from": {
            "key_code": "caps_lock",
            "modifiers": {
              "optional": [
                "any"
              ]
            }
          },
          "to": [
            {
              "key_code": "japanese_kana"
            }
          ]
        }
      ]
    }
  ]
}

このJSONファイルを作成したのち、[complex modifications] の [Add rule] ボタンを押すと、一覧に [Caps_lock to Toggle ja/en unless RDC] が表示されるので、[Enable] します。

【リモートデスクトップの中では右CommandキーをApplicationキー(ポップアップメニュー表示)に】
Windows機でスペースバーの右の方にあるポップアップメニューのキー(正式にはApplicationキーと言う)は、わざわざマウスに持ち替えて右ボタンを押すのを省けてとても便利です。
Macのキーボードにはこのキーがないので右のCommandキーで代用したいと思います、ただしリモートデスクトップを使っている時だけ。

一つ前の設定と同様に、フォルダ /Users/your_user_name/.config/karabiner/assets/complex_modifications に以下の内容のJSONテキストファイルを作成します。

{
  "title": "Windows context menu",
  "rules": [
    {
      "description": "RDC right_command to context_menu",
      "manipulators": [
        {
          "type": "basic",
          "conditions": [
            {
              "type": "frontmost_application_if",
              "bundle_identifiers": [
                "^com\\.microsoft\\.rdc\\.macos$"
              ]
            }
          ],
          "from": {
            "key_code": "right_command"
          },
          "to": [
            {
              "key_code": "f10",
              "modifiers": [
                "shift"
              ]
            }
          ]
        }
      ]
    }
  ]
}

このJSONファイルを作成したのち、[Complex modifications] の [Add rule] ボタンを押すと、一覧に [RDC right_command to context_menu] が表示されるので、[Enable] します。

2021-04-26

MacBook Airのキーボードをカスタマイズしたいけれども、macOS Big Sur 11.3待ち

Apple SiliconがM1のままiMacが来たのには意表をつかれました。
でも、よくよく考えると、筐体の新デザインと、新しいCPUは、片方ずつ出せば良いので、至極順当だったのだと思います。
薄くフラットになったのも、ロジックボードの小型化の結果として、うまくできていると思います。
空間オーディオを入れてきたのはiMacの個性付けとして良いですね。
おそらく一番のポイントは、シルバー+6色のレインボーカラーですね。
それと、ベゼルが白くなったのも度肝を抜かれました。

その中で、パステルカラーのキーボード(とうとうTouchID付き)とトラックパッドはとても欲しくなりました。
色違いでのコーディネートも良いと思います。

さて、最近はM1 MacBook Airを触っている時間が長くなって、社用のWindows機と行き来することが多くなりました。
そうしていると、Ctrlキーの位置の違いをものすごく煩わしく感じます。
Windowsでのキー配置を手が覚えていて、MacでCtrlキーを押そうとするたびに集中力が切れてしまいます。
特にCtrlキーを頻繁に使う、Terminalでのshell操作や、たまに使うMS Remote Desktop ConnectionでのWindowsへの接続の時に辛いです(RDCもM1対応してレスポンスが良くなったような気がするので、Macの気持ちいいMagic Trackpadの下で常用したい)。

macOSの標準機能ではfnキーの配置を変更してCtrlキーと入れ替えることができないので(申し遅れましたがわたしはUSキーボード派です、日本語キーボードの場合は標準機能で左下隅のCapsLockをCtrlに設定できますよね)、このブログでも何度か登場しているKarabinerのお世話になる場面です。
ところがKarabinerのサイトによると、現バージョンのBig Sur 11.2には問題があるので11.3まで待て、と書いてあります。
11.3はすでにRCまで進んでいるので、来週、新しいiMacに合わせて正式版が出てくるのでしょう。
もう少しの辛抱です。
併せて、新しいキーボード・トラックパッドも単体発売が始まって欲しいですね。

ところで、新しいキーボードの配置を見ていると、カーソルキーを逆Tにしなかったのが不思議です(角のキーを丸いデザインにしたたためですね、iPad Pro用は逆Tになっています)。
さらにCtrlとfnのキートップの入れ替え改造もできないですね。
日本語版は相変わらず配置がおかしいですね(個人の意見です)。
テンキー付きだとCtrlキーが都合よく端っこ(fnキーは特殊キーのブロック)なのと、Backspace、PgUP/Dwn、Home/Endが独立しているので、もしかすると、ものすごく使いやすそうです。
トラックパッドを左側に置けば、右手(カーソル移動)と左手(ポインタ移動)の使用頻度が平均化して良いかも知れないなと思いました。
机の上を整理整頓してテンキー付きを考えてみようかな(マルチペアリングができればもっと良いのに、なら他社エルゴノミックキーボード+超安定のMagic Trackpadの組み合わせも検討の余地あり(Magic Trackpadはマルチペアリングできないので統一できない)、いやいや新しい "Colorful" Magic KeyboardのTouchIDは捨てがたいですね)。

2021-04-04

Apple M1 MacBook AirからUSB-C接続で4K外部ディスプレイに表示できない問題はケーブル交換で解消したけれど

以前『Apple M1 MacBook AirとiPad ProのUSB-Cポートは(おそらく)規格が違うので要注意』という記事の中で、Apple Silicon MacをUSB-C接続で4K外部ディスプレイに表示できない現象を書いたのですが、先日、USB-Cケーブルをディスプレイ付属のケーブルから別途購入したケーブルに交換することで解決できました。

コメント欄に kingtoshさん にいただいたアドバイスの内容がまさにドンピシャでした。
ありがとうございます。

以下、今日までの経緯です。

当方の環境:ディスプレイ LG 32UL750-W、Apple M1 MacBook Air 2020、iPad Pro (11inch 1Gen 2018)、Windows PC (HP EliteBook 840 G5)。
追加購入したケーブルGOPPA GP-CCU325A10M USB 3.2 gen 2x2 (SS 20) 認証ロゴ付き、パッケージにアイ・オー・データ機器が代理店と書かれています。

Apple Silicon MacBook以前にできていたこと:iPad ProとWindows PCをディスプレイ付属のUSB-Cケーブルで画面出力できていました。ただ、HDMI接続に比べてUSB-C接続はたまに瞬間的に画面が消えたりする現象があり、なんとなく動作が不安定のイメージを持っていました。

Apple Silicon MacBookにて:USB-Cケーブルでの画面出力ができない、USB-C to DisplayPort変換アダプタでDisplayPortケーブルでの画面出力は問題なし。

その後の状況:因果関係はわかりませんが、iPad ProとWindows PCでUSB-C接続での画面出力がなぜかできなくなってしまっていました。ディスプレイをファクトリーリセットしてもダメでした。USB-C to HDMI変換アダプタやWindows PCのHDMIポートからのHDMI接続での画面出力は問題なし。

USB-Cケーブルの購入交換:USB 3.2 gen 2x2 (SS 20)の認証ロゴのついたケーブルを使用すると、Apple Silicon MacBookでもUSB-C接続で画面出力できるようになりました。4K 60Hz HDRモードで表示されています。

不可解な現象:画面出力ができるようになった後、試しにディスプレイ付属のUSB-Cケーブルに戻して、Apple Silicon MacBookを接続してみたら、なぜか画面出力ができてしまうのです。ディスプレイ側が何か変な表示モードを記憶してしまっていて、ケーブル交換によってそれがリセットされたのかのような現象です。

ケーブル1本で画面出力と充電の両方ができるUSB-Cですが、何か問題が起こってしまうとなかなか厄介なのかもしれません。

2021-01-29

Linuxのsudoの脆弱性CVE-2021-3156への対応方法 - Windows 10 WSLの場合

Linuxコマンドで特権操作を行う場合によく使うsudoコマンドに脆弱性CVE-2021-3156が発見されました。
ITmediaの記事(sudoにパスワード不要で特権昇格が可能な脆弱性が見つかる 2021-01-28)と、JPCERTの記事(sudoの脆弱性(CVE-2021-3156)に関する注意喚起)に、情報が公開されています。

ほぼすべてのLinux系/UNIX系OSに影響があると思います。
macOSに関してはまだ情報が出ていないですが注意が必要と思います(macOSにはsudoeditコマンドがないので直接の影響が少ない可能性があります)。

JPCERTによると

% sudoedit -s /

のコマンドで簡易的に影響を調べることができるようです。
sudoedit: から始まるメッセージが表示されると問題があり、
usage: のメッセージが表示されると問題は対策済みです。

わたしも早速、自分のPCに対策をインストールしました。
Windows 10のWSL1 Ubuntuの場合の手順です(おそらくWSL2でも同じ)。

WSLを起動して
$ sudoedit -s /                    ##状態の確認
[sudo] password for xxxx:
sudoedit: /: not a regular file    ##問題があることが分かります
$
$ sudo apt-get install sudo        ##インストール済みのsudoのバージョンを確認
Reading package lists... Done
Building dependency tree
Reading state information... Done
sudo is already the newest version (1.8.21p2-3ubuntu1.3).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
$    ##WSL Ubuntu 18.04での対策済バージョンは1.8.21p2-3ubuntu1.4なので古いことが分かります
$    ##以下、対策のインストール方法
$
$ sudo apt-get update              ##レポジトリ情報の最新化
$ sudo apt-get upgrade sudo        ##sudoのバージョンアップ
$
$ sudoedit -s /                    ##対策結果の確認        
usage: sudoedit [-AknS] [-r role] [-t type] [-C num] [-g group] [-h host] [-p prompt] [-T timeout] [-u user] file ...
$                                  ##OK
$

まだ実際の攻撃は検知されていないようですが、早めの対策が必須です。

[2021-02-02] 問題はsudoeditに限定されるようです(参考記事:GIGAZINE - 「sudo」コマンドに特権昇格の脆弱性、各ディストリビューションの対応一覧)。

2021-01-27

macOSの写真アプリ(Photos.app)の非互換性にうんざりする

macOS 10.0 が誕生した時からずっと気に入って 写真アプリ (Photos.app、以前はiPhoto) を使っています。
Appleらしい使いやすさは昔から変わりません。

しかしながら、このApple Siliconの世代になって、どうしても受け入れ難い問題にぶつかってしまいました。
macOSのバージョンが違うと、写真アプリが全く互換性がないのです。
私はMac mini 2012とApple Silicon MacBook Airを主に使っているのですが、古い方のMacはBig Surに対応しません。
写真は、Mac mini 2012でずっと管理してきて写真ライブラリは150GB以上になっています。
この機会にNASに移動して、2台のMacのどちらからでも使えるようにしようと考えていました。
さすがにネットワーク経由だとコピーに24時間以上かかるので、exFATにフォーマットしたUSB HDDに一旦コピーし、NASに移しました。
Big SurのMacの写真アプリでこの写真ライブラリを開くと、ライブラリの変換・修復が行われ、一呼吸の遅れはあるものの、NASに置いた写真ライブラリがきちんと使えるようになりました。
次に、CatalinaのMacの写真アプリで開こうとするとエラーになってしまい、脆くも私の計画は崩れ去ってしまいました。
写真ライブラリは同じバージョンのmacOSの間でしか共有できないのです。

次善策をいろいろ考えましたが、どれもしっくりとこず、釈然としません。

  • 古いMac miniは捨てて、新しいMacだけの運用にする。
    私のApple Silicon MacBook Airの内蔵SSDは500GBです。150GBの写真ライブラリは置けないことはないですが、途端に窮屈になってしまいます。もっと大容量にしておけばよかったのかもしれませんが、写真ライブラリは長期保存が重要なので内蔵SSDに置くのはちょっと違う気がします。もしかしてMacは1台運用が良いのでしょうか。
  • iCloudを経由すればバージョン違いのmacOSの間でも写真ライブラリが共有できる。
    iCloudは無料枠で使っているのでこの案はダメです。
  • Mac miniを新しくしてしまう。
    最新OSが動かなくなったマシンはどんどん新陳代謝のように入れ替えていく方針にすれば、実は一番悩みが少なくて済むのかもしれません。Apple SiliconのMac miniはIntel Mac miniに比べて発熱が圧倒的に少ないので、連続運転させておくのにも適していると言えます。しかしながら今の時点ではあまりにももったいない使い方という感覚が強くて踏み切れません。
  • 写真の管理をNASのアプリに移してしまう。
    これをやってしまうと、macOSの使いやすい写真アプリを捨てることになります。
  • 古いMac miniはそのままで、そこでは写真アプリだけは使わないことにする。
    共有したかったので、元も子もないですが、致し方ないのかもしれません。

そういえばiPhoneとiPadの写真もなんとかしないといけないです(今まではもっぱらMac miniに吸い上げて蓄積してきました。NASのアプリ管理にすれば親和性が良さそうですが、上に書いたようにmacOS側の写真アプリが使えなくなります)。
なかなか悩みが尽きません。

2021-01-16

Intel/Arm64 WindowsやLinuxをApple Silicon Macで簡単に実行出来るUTM appの一般公開が始まりました

先日ご紹介した、UTM appのwebサイトが https://mac.getutm.app/ に公開されました。
UTM appを使えば、簡単にIntel WindowsやArm64 WindowsやLinuxをApple Silicon Macで実行することができます。

私も書きましたが、Intel x86のOSの実行はArm64のOSを実行するのに比べてパフォーマンス的に不利と明記されています。

webサイトではUTM appのダウンロードリンクに加えて、設定済のゲストイメージや、OSの設定方法がGalleryページに公開されています。
Intel x86のUbuntuWindows XPWindows 7などをダウンロードしてすぐに試せるようになっています。
Arm64のUbuntuWindows 10 に関しては設定方法が記載されています。
他のArm64 Linuxは設定済のものも提供されているものもあります。

一点だけ注意点があって、現在バージョン(v2.0.17)では、ダウンロードしたイメージやISOファイルは ~/Library/Containers/com.utmapp.UTM/Data/Documents というフォルダに置く必要があります

[English version of this post]

2021-01-07

Apple Silicon MacのUTM appを使えばWindows for Intelが簡単に動く、そして熱い

macOS Big Sur 11ではRosetta 2によって、Intelコードで書かれた従来のMacアプリを、Apple Silicon上でスムーズに実行することができますが、あくまでMac用に書かれたアプリ限定です。
仮想化のためには、Hypervisor Frameworkと、Linux向けに簡易化したVirtualization Frameworkが提供されていますが、これらではIntel向けのOSを実行することはできません。
Arm用のWindowsはMicrosoft Surface Pro X向け限定でリリースされていますが、それ以外の環境での利用は現時点では(評価版以外は)許されていませんし、それ以前にArm向けのアプリはとても少ないです。

Windowsの主流はやはりIntel版(Wintelという言葉があるくらい)。
これをそのままApple Silicon Macで実行できないことには、ユーザにとってのメリットが少ないと思えます。

なぜか他ではまだなかなか紹介されていないのですが、iOS上でWindows XPを実行するという離れ技をやってのけたUTM appというアプリがあります。
このUTM appがApple Silicon Macにも対応(dmgがまさにmacOS用のインストーラ)しました。

右のスクリーンショットは、UTMを使って、Intel Windows とArm Windowsの両方を、Apple Silicon MacBook Airで実行したところです。
Intel WindowsもArm Windowsも評価版をダウンロードして、UTMで仮想ゲストを作成し、Cドライブとして設定して実行しました。

Arm Windowsはフルスピードで実行されます。
これはUTMが、内部的にHypervisor Frameworkを使って(実際にはQEMUがhvfに対応)ハードウェア仮想化技術を利用できているためです。
Arm Windowsの注意点は、起動ディスクのvhdはNVMeとして(おまじないとして)設定しないと起動しないこと、ネットワークはvirtio用ドライバを追加でインストールしないと通信できないこと、それ以外のデバイスもDevice ManagerでUnknownが多数残ってしまうことです。
画面サイズの変更もできません。
まだまだドライバ周りなどで未対応のものが残っているようです。

Intel Windowsを動かすと、UTMが内部のQEMU(Linux上で有名なCPUエミュレータ)を使って、Apple Silicon上でIntelコードをエミュレーションします。
そのため、パフォーマンスは1/4〜1/8程度、大昔のSoftPCやVirtual PCを見ている感じです。
ですが確かにIntel WindowsがApple Silicon Macで動きます。
vagrant用に設定済みのWindows 10イメージで試したこともあって(別記事に設定手順)、デバイスの認識は問題ありません。

ここで面白いのが、Intel Windows上で何かを動かしている最中は、Apple Siliconの8個のCPUコアがフル回転になって、なんとMacBook AirのF6キー辺りとその裏側が徐々に熱くなることです。
他のアプリで負荷をかけても、なかなかこういう状況を作り出すのは難しいのですが、WindowsのようなOSを丸ごとエミュレーションさせると、いくらApple Siliconといえどもフルパワーを発揮せざるるを得ない状況になるようです。
まさに『アツいぜ!Apple Silicon』です。

[English version of this post

[2021-01-08] タイトルを
「UTM appを使えば容易にIntel x86_64 WindowsやArm WindowsをApple Silicon M1 Macで実行でき、Apple Siliconがもっと熱くなる」
から
「Apple Silicon MacのUTM appを使えばWindows for Intelが簡単に動く、そして熱い」
に変えました。
[2021-01-10] Arm Windowsの動作上の制約について追記しました。
[2021-01-17] UTM appが専用webページで一般公開されて、すぐ使えるゲストイメージも公開されたので記事を書きました
[2021-03-04] UTM appが使用しているQEMUのIntelエミュレーションが、たとえ現在はM1 Macで実用的な速度を出せない状況だとしても、M1XまたはM2のApple Siliconなら馬力で解決できるはず、という記事を書きました
[2021-04-19] 有名なポッドキャスト「Appleるんるん」でこの記事が紹介されました、ありがとうございます。
お試しでIntel x86 Windows10をApple Silicon Macで実行する最短の手順を書きました
[2021-05-05] Intel x86 Windows 10をApple Silicon Macにインストールする手順を書きました
クリーンインストールすることでWindowsが以前よりも高速に動作しています。
[2022-01-08] UTM appでmacOSの仮想化ゲストも実行できるようになりました。

2020-12-11

今のうちに来年のApple Silicon(M1XまたはM2)を予想してみる

Apple Silicon M1は発売早々から、驚きのパフォーマンスと、省電力で騒然となっていますね。
ビデオの編集もサクサクできる反面、書き出し処理はGPUの馬力に依存するので、案外苦手という結果も出ています。
これは、Apple M1のGPUは8コア 2.6TFlops、対してMacBook Pro 16は40 GPUコア 5.3TFlopsと、まだ性能を伸ばすべき課題となる点が残っているということです。

さすがのApple Ailiconでも各コアの性能を一気に上げたり、1つのチップに今の何倍ものコア数を詰め込むことは物理的にも無理だと考えられます。

Apple Silicon M1の解説をよくよく見ると、CPU/GPU/メモリ/キャッシュが汎用的なひとつのファブリックで接続されています。
このファブリックをチップとチップの間まで延長しさえすれば、2倍4倍の拡張が容易に可能になります。
さすがにローエンドのMacBook Airではスペース的に無理ですが、MacBook Pro 16インチやiMac以上であれば、複数チップ構成はまったく問題ないと思います。

単純倍増方式:
単純に現状のApple M1を複数接続する方式がまず考えられます。
もしかすると現行のApple M1は既にファブリックを外に出す仕組みを持っているかもしれませんよね。
新たなチップを開発せずに、ものすごく簡単に性能を広げることができます。
図では最大構成的に4つのApple M1を接続していますが、2つでも3つでも構わないです。
この方式のデメリットは、CPU/GPU/メモリのバランスを自由に選べない点と、セキュアクレイドルやI/Oインターフェースなど複数は必要ないものまで重複してしまう点です。

機能特化チップ拡張方式:
GPUだけ増やしたい、メモリだけ増やしたいなど、目的によってニーズは様々です。
チップ間ファブリックで接続するのを、何も均質なApple M1に限定する必要はありません。
GPUだけを搭載したチップや、メモリだけを搭載したチップ、さらに1チップ内の搭載数も幅を持たせて用意しておけば、ものすごく自由な構成を組むことができます。

汎用ファブリックは古くはDEC Alpha、最近ではAMD ZENでも使われていて、個別に専用のマルチCPU用のチップセットを一から設計するよりも、ずっとスマートにハイエンドシステムを構成することができると思います。
iPhone/iPadのApple Silicon Axは1年毎に数パーセントの順調な改善を続けていますが、ことApple Silicon Macに関してはこの2年のうちにMac Proレベルまで一気に駆け上ることが期待されていていて、単純なチップ内の改善だけでは到底追いつかないと考えられます。
そこを何とかする「Appleの魔法」は何だろうかと考えてたどり着いたのがこれです。
すでにブルームバーグが、来年のApple Siliconについて20コアとか32コアを予想していますが(9to5Macの解説記事と、Bloombergの元の記事)、さて実際にはどういうものが出てくるか、楽しみが尽きないですね。


[2020-12-15] こんなところにも「ファブリック」が既にありました。
Mac Pro 2019のMPXグラフィックカードの中で、GPUチップ間と、さらに2枚(Duo)のMPXカード間の接続に使われています。

[2021-09-25] 単純倍増方式を仮にM1X-Dualと名付けた記事を書きました。

2020-11-26

Apple Silicon MacでshellをIntelモードで簡単に起動するには arch -arch x86_64 zsh、Intelコードをコマンドで作成するには cc -arch x86_64、Universalバイナリ作成は lipo -create

新しいコンピュータでまずやってみるのがHelloWorldアプリ。
Xcodeでの例はたくさんあると思います。
でももっとシンプルにC言語でのHelloWorldももちろん作れます。
macOSは少し特殊なので、「はじめてのC」の方でも作成できるように、手順を少していねいに紹介してしてみたいと思います。

macOS上でのはじめてのプログラムの作り方(Xcodeに頼らずに)
こんな感じのソースコードをテキストエディット(textEdit.app)に入力します。

#include <stdio.h>
int main () {
    printf ( "hello world.\n");
}

この内容をソースコードとして保存するためには、少し面倒ですが、次のおまじないが必要です。

保存する前に [フォーマット] => [標準テキストにする] を指定します(※1)。
ファイルの保存は [ファイル] => [保存...] メニューなのですが、以降のCLIコマンドで扱えるように次の指定をします。
保存先シートの [場所:] がデフォルトでは [書類] が選ばれていると思いますが、この一覧から自分のユーザ名を選び(またはShift+Cmd+H)、
その右側の下矢印 [v] を選んでフォルダ一覧を出します。
さらに [新規フォルダ] ボタンを押して、[名称未設定フォルダ] のところを tmp に書き換えて [作成] ボタンを押します(※2)。
保存先シートの [名前:] に a.c と入力し、[保存] ボタンを押します。
※1 プログラムファイルはテキスト形式にするのが必須なので、このようにします。)
※2 書類フォルダに a.c を保存することもできるのですが、次に実行するターミナルでのアクセスがmacOSの保護機能で制限されるので、このようにします。)

次にterminal.app(アイコン名はターミナル、アプリケーション配下のユーティリティフォルダの中にあります、あるいはCmd+Spaceでterminalまたはターミナルで検索してもよいです)を起動します。

ターミナルアプリの中で shell が起動されます。
まずはプログラミング環境一式を整えるために make コマンドを呼び出します。

make

すると、右の図の1つ目のダイアログが表示されますので、指示の通り [インストール] ボタンを押します
(このように必要なものがオンデマンドでインストールを促されます、面白いですよね。
 事前に Xcode をインストールしてある場合はこのダイアログは表示されません)。
次のコマンドでコンパイルします。

cd tmp
cc a.c

これでエラーメッセージがでなければ a.out という名前で、アプリの実行ファイルが作成されます。
ファイルの確認は次のコマンドでできます。

ls -l

作成したアプリは次のようにして実行できます。hello worldと表示されれば成功です。

./a.out

動きましたか?

Intel版アプリの作成方法
この手順でアプリを作成するとApple Silicon専用のアプリが作成されます。
file コマンドで確認すると、a.out: Mach-O 64-bit executable arm64 と表示されると思います。

file a.out

Apple Silicon Mac上で、Intel用のアプリを作成することもできます。
コンパイルする際に次の指定を行います。

cc -arch x86_64 a.c

先ほど同じように file コマンドで確認すると a.out: Mach-O 64-bit executable x86_64 と表示されます。

file a.out

作成したIntel用のアプリも同じ様に実行できます。

./a.out

ただし、今度は右の図の2つ目のダイアログが表示されます。
これは、macOS Big Surの初期状態ではRosetta 2がインストールされていないためなので、ここでも [インストール] ボタンを押します。
Rosetta 2のインストールが終わるとIntel版の a.out アプリが実行できるようになります。

Universalアプリの作成方法
さてここで私は、macOSが提供しているコンパイラアプリ自体はApple Silicon用なのか、Intel用なのかの疑問が湧きました。
次のコマンドで見てみると、Apple SiliconとIntelのUniversalアプリになっていることがわかります。

file /usr/bin/cc

自分でUniverasalバイナリを作成するには次のようにします。

cc a.c
mv a.out a_arm64.out
cc -arch x86_64 a.c
mv a.out a_x86.out
lipo -create -output a.out a_x86.out a_arm64.out

このコマンドで a.out が作成されます。
file コマンドでUniversalになっていることを確認してください。

file a.out

もちろん実行も問題なくできると思います。

./a.out

Intelモードのshellを起動する最も簡単な方法
先ほどやってみたように、Apple Silicon版でもIntel版でもアプリは区別なく必要に応じて自動的にRosetta 2で翻訳されて実行されるので、通常の利用目的ではとても都合が良くできています。
ところが、アプリ開発やパフォーマンス検証等の目的で明示的にIntel版環境を使用したい場面もあります。
その場合は、最初からターミナルのshellをIntel版にしておくのが便利です。
他の方のブログ等では、ターミナルアプリ自体の属性を [Rosettaを使用して開く] に明示的に変更する方法が紹介されているケースが多いです。
しかしながらこの方法はmacOSの [アプリケーション] => [ユーティリティ] に保存されているターミナルアプリを直に書き換えることになるため、あまりスマートではないと感じていました。

次のコマンドを使用すれば、ターミナルアプリの設定を書き換えることなくIntel版環境のshellを起動できることがわかりました。

arch -arch x86_64 zsh

実行中のshellがApple Silicon版なのかIntel版なのかは、次のいずれかのコマンドでの確認できます。

arch
uname -m
echo $CPUTYPE
machine

Intel版のshellからApple Silicon版のshellに戻るには次のコマンドを使います。

exit

逆に、Intel版のshellからApple Silicon版のshellを呼び出すのは次のコマンドです(引数に注意)。

arch -arch arm64e zsh

なお、Intel版環境のshellでは、Universalアプリはx86_64のコードが優先的に実行されます。
少しややこしいのですがIntel版環境においてもApple Silicon専用のアプリを意識することなくそのまま実行できるようになっています(macOS自体がApple Siliconなので)。

archコマンドでCPUタイプを指定した起動を行えるのはshellだけではありません。
例えばSafariをIntel版で動かしたい場合は次のようにします。

arch -arch x86_64 /Applications/Safari.app/Contents/MacOS/Safari

一発で起動できて、これ捗ります。

[English version of this post]

2020-11-23

Apple M1 MacBook AirとiPad ProのUSB-Cポートは(おそらく)規格が違うので要注意

[2021-04-04] その後、USB-Cケーブルを交換し、Apple M1 MacbookとiPad Proの両方で画面出力を正常に行うことができるようになりました。
こちらの記事
を参照願います。

 

待望のApple M1MacBook Airがわたしにも届きました。
少しずつ試しているので、分かったこと、気になったことを記事にしていきたいと思います。

まずは2つあるUSB-Cポートについて。

Apple M1 MacBook Air/Proの仕様表には、Thunderbolt 3/USB 4と書いてあり、対応する接続は、充電、DisplayPort、Thuderbolt 3 (40Gbps)、USB 3.1 Gen2 (10Gbps) となっています。
ビデオ出力としては、Thuderbolt 3、USB-C経由のDisplayPort、アダプタを介してVGA、HDMI、DVI、Thuderbolt 2となっています。

他方、最初にUSB-Cを採用したiPad Proには、単にUSB-Cとしか書かれていません。

一見、同じかと思ったのですが、少し試した中でも違いがありました。

  • iPad ProをUSB-CでLGの4Kディスプレイに接続すると正常出力、M1 MacBook Airでは充電はされるがディスプレイ出力はされません。
    ディスプレイはLG 32UL750-Wです。
    信号方式・接続方式はThunderbolt 3ではなくてUSB-C DisplayPort Alt Modeです。
    このことから、iPad ProはAlt Modeに対応しているが、M1 MacBook Airはおそらく対応していないのか、互換性の問題、ということになりそうです。
    これ、とてもまずいです。
  • iPad ProはUSB-Cしかなくて有線ヘッドホンが接続できなくて不便です。
    そのために、USB-CドックとしてサンワのKC036CMH(USB-C入力、PD用USB-C、HDMI 4K 60Hz出力、ヘッドホン出力、USB 2.0)を使っています(イーサプライ版も同じもの)。
    試しにこのUSB-CドックをM1 MacBook Airに接続し、HDMIケーブルで4Kディスプレイに接続すると、4K 60HzかつHDRできちんと表示されました。
    同時にUSB-Cからの充電もできました。
    なぜ、ドックを噛ませるとうまくいくのかは、ちょっと説明に苦しみます。
    が、わたしの環境では、USB-Cドックが流用できて、なんとかギリギリセーフです。
  • M1 MacBook Airの対応一覧に載っている外部ディスプレイは、Apple Pro Display XDR (6K)、LG UltraFine 5K、LG UltraFine 4Kですが、いずれもデイジーチェーンに対応しているものなのでThunderbolt 3接続で間違いありません。
    このことから、少なくとも現状は、外部ディスプレイはThunderbolt 3接続のみで、USB-C DisplayPort Alt Modeでの接続はできない可能性がもしかすると高いのかもしれません。
    将来的にドライバが改善されて出来るようになるのかもしれません。
    複数ディスプレイに対応していないこと以前に、互換性にも注意が必要なのかもしれません。

 

[2020-11-24] これ、何も起こらなかったら気付けなかった愛おしさの一種ですね。

ちなみに、キーボードは、不幸なパンタグラフキーボードの数年を経てのMagicKeyboardなので、注意深く触ると少し独特だけれども、とても安定したキーボードです。
唯一奇異なのは、TouchIDカメラの邪魔をしないように何のシンボルも刻印されていない、のっぺらぼうの電源ボタン。
トラックパッドも、思い通りに反応してくれる安定・絶品のMagicTrackpadです。

2020-11-17

わたしのApple M1 MacBook Airカスタマイズモデルが順調に出荷されました

先週のSpecial Eventのすぐ後に、Apple M1 MacBook Air 512MBモデルを、メモリ16GB、USキーボードにカスタマイズして発注しました。
今夜、順調に上海から出荷されました。

経過は以下の通りです。
  • 先週11月11日(火)未明、Special Eventのすぐ後に発注し、処理中に
  • 昨日11月15日(日)夜、発送準備中に
  • 本日11月16日(月)夜、Appleから出荷完了に、SMSでも出荷のお知らせを受信、
    ヤマト運輸さんの上海にて「海外荷物受付」の状態
  • 11月19日(金)朝、深センにて「海外発送」、深センは香港の近く(2020-11-19追記)
  • メールによるお知らせでは11月22日(日)到着予定、
    発注時の到着予定11月23日(月)~25日(水)の最早日より1日短縮、出国・入国があるのでこれくらいですね
  • 11月21日(土)午後、(ADSC、羽田クロノゲートベース)を作業店通過(2020-11-22追記)
  • 11月22日(日)朝、最寄りのヤマト運輸営業店から、配達中に
  • 11月22日(日)ちょうどお昼に到着

カスタマイズ無しの場合は、納期から考えると日本の倉庫から出荷されるようですね。
iPhoneと違ってベースモデル以外は事前の在庫がなくて、中国の工場でBTOするんですね。 


[2023-06-27] 記録のために、
Air/M1/16/512の購入価格は174,800円(外税)だったようです(当時のレシートがなかなか見つからず、ウェブニュースにて調査)。

2020-11-13

Apple M1 MacBook Air、MacBook Pro、Mac miniが直販ショップ以外でも取り扱い開始、ポイント付与ありでお得

11月11日の即日発売日にはApple Online Storeのみの販売だったApple M1 Macですが、その他のショップでも取り扱いが始まったようです。
価格.com(例としてMacBook Air最安モデルのリンク)でも一覧が表示されるようになっています(ただしヨドバシさんアマゾンさんはまだ価格.comの一覧に出ていないですが同様に始まっています)。

気になるお値段は、完全に横並び+5%ポイント付与(ヨドバシアマゾンも同じ価格、同じポイント)。

基本スペックが欲しい場合は、自分のご贔屓のお店でApple直販よりもお得に買えます。

そのうちカスタマイズモデル(16MBとかUSキーボード)の扱いも始まると思います。
最速でカスタマイズモデルが欲しい人はグッと我慢ですね。

[2020-11-13] 先ほど15時前にヨドバシからDM来ました。
やはりまだ基本モデルのみのようですね。
たとえばMacBook Airは2モデル×3色の6アイテムだけです。
いずれにしてもポイント分お得なのには違いないです。