MacBookをヘッドレス化する（2025年）

MacBookをヘッドレス化する：ある冒険

6 '25年3月27日 読了

はじめに パート1/11

Appleプラットフォーム向けに開発するにはMacが必要だと悟った。

• Macbook Air M1 ヘッドレス ［画像: Macbook Air M1 Headless］

私はApple製品をあまり好まない。しかし、自分のソフトウェアをAppleのプラットフォームでも利用可能にしたいと考えている。

macOS/iOS/iPadOS向けのアプリを公開するには、Apple製ハードウェアがどうしても必要になる。また、自分のプラットフォーム向けにソフトウェアを提供するなら、特にそれを販売したいのであれば、ユーザーが体験するのと同じ方法で自分のアプリを体験できる必要がある。

それはユーザーへの基本的な敬意だ。

仮想化

仮想マシンを試した。過去数年でVirtualBoxやQEMU/KVMで6つほどのmacOS VMを動かしただろう。VMでmacOSを動作させるのは難しく、一貫性がなく、(少なくとも私のマシンでは)パフォーマンスも良くない。Appleはこれを強く望んでおらず、常に逆風の中を進むことになる。

それは喜びのない経験だ。

Codemagic

Codemagicという継続的インテグレーション/継続的デリバリーサービスを試した。これはAppleプラットフォームを含む様々なプラットフォームへの公開を可能にする。素晴らしいサービスで無料枠もあるが、私の使い方では有料枠に入るだろうと思われ、それはすぐに高額になる可能性があった。

それに、遠隔からの操作だ。CodemagicはmacOS GUIへのリモートログインを許可しているが、私の目の前にあるデバイスと同じではない。Codemagicのリモートマシンでアプリの使用体験を徹底的にチェックしたい場合（単にビルドを実行するだけでなく）、それは無料時間をすぐに食いつぶしてしまうだろう。

これは状況によっては解決策になりうることは確かだ――私の状況ではそうではない。

というわけで…

20年以上、数十台のコンピュータを所有してきた中で、初めて「Macが必要だ」と自分で決断した。

どのMacを選ぶべきか？ パート2/11

私が扱えるMacを見つける。

私の決定に最も影響を与えた要因は以下の通りだ：

• コスト。 できるだけ少なく費用をかけたいと思った。
• 消費電力。 私は低電力環境に住んでおり、電力消費を劇的に増加させる新しいデバイスを導入したくなかった。

電力という点では、明らかにApple Siliconが必要だった。私は長年ARMプロセッサを好み、できる限り多くの仕事でそれを使用している [https://mm-dev.rocks/posts/android-as-a-dev-environment/intro/]。Appleの特殊なARMチップの使用と、ハードウェア/ソフトウェアアーキテクチャに対する厳格な管理は、パフォーマンス・パー・ワットを最大化する上で有利な立場にある。もしAppleのプールで泳がなければならないなら、Apple Siliconは当然の選択だ。

安く抑えるために、第一世代のM1チップを選ぶのが明白な選択肢だった。それらはまだうまく機能し、OSアップデートも当分受けられるはずだ（OpenCore Legacy Patcherを使えばさらに長く）。

私はラップトップをあまり好まない（自分でキーボード、ポインティングデバイス、画面を選びたいので、それらの冗長なコピーがコンピュータにくっついているのは無駄だ）。そのため、当初はM1 Mac Miniに惹かれた。それは単なるコンピュータであり、私が不要とするヒューマンインターフェースデバイスが付いていない。

しかし、M1 Mac Miniを見送った理由は二つある：

ファンがある

人々は静かだと言う。たとえそれが真実だとしても（それにはレベルがある）、ファンは摩耗する可能性のある機械部品であり（そして騒音を発生させる）、ほこりを吸い込んだり吹き出したり（掃除が必要になる）、故障したりする。また、電力を消費する。

電源供給

私の家を電化しているバッテリーバンクは12Vだ（24Vまたは48Vの方が良いだろう。適切な時期が来たらアップグレードする）。私のすべての電力はこのバッテリーバンクから供給されている。

私は電源インバーターを持っている。つまり、通常の家庭用プラグを持つ電化製品を使用できるが、インバーターは12Vから220Vへの変換プロセスでいくらかの電力を無駄にする。次に、電源アダプターを接続すると、220Vをデバイスが使用する電圧に再び変換する際にさらに電力が無駄になる。これは二重の無駄であり、プラグと配線の混乱を招く。

バッテリーからDC 12Vが得られ、昇圧コンバーター経由で容易にアクセスできる20Vフィードがある。もちろん、USB経由で5Vも得られるし、さらに多くのエキゾチックなUSB-Cバリアントもある。これらの方法のすべてを使って、私が定期的に使用するすべてのものを電力供給できる。

• 様々なXT-60アダプター ［画像: Assorted XT-60 adapters］

新しいデバイスを購入すると、まず最初に行うことは電源コネクタを切り取り、私がすべてに使用しているXT60コネクタのいずれかに取り付け、デバイスの電源アダプターを捨てる（実際には保管する）ことだ。私はこれを複数のラップトップや小型PCで問題なく行ってきた。それらは通常19V～21Vを要求し、20Vに耐性があるように見える（ただし、私の無謀な行動に似た行動で物を破損したという話を聞いたことがあるので、私は運が良かったのかもしれない）。

M1 Mac Miniの電源アダプターでこれを行うことに関する情報を探したが、問題があったと言う人もいた。これを書いている間に再度検索したが、比較的簡単だという情報が見つかった。以前は検索語句を間違えていたか、あるいはAppleデバイスの電源供給を改造することにただ単に臆病だったのかもしれない。Appleはオフロードに対して非常に非友好的であり、'承認されていない'方法で物事を行うのを防ぐ措置を実装することで知られている。お金を無駄にして使えないものを買いたくなかった。

良くも悪くも、M1 Mac Miniは断念した。

M1 MacBook Air パート3/11

これは現代の傑作だと認めよう。

ラップトップであるにもかかわらず、MacBook Airについてさらに深く考えることにした：

• 薄く、軽く、特に低消費電力である
• ファンレスである
• 好むことはないだろうが、Apple（/私の）ユーザーはトラックパッドを愛する傾向があるため、M1 Airのトラックパッドでアプリを確認し、すべてが問題ないか確認できる能力は役立つかもしれない。

（私には）冗長なディスプレイが付属していることへの問題は？…これは利点になるかもしれない。

Appleは修理をあまり重視しないため、人々は画面が壊れたこれらのマシンを安価に売却する。私は画面が壊れたMacBookを購入し、それを取り外すことができる。これが可能かどうか確認した（そのようなことはほとんどのラップトップでは当たり前だが、Appleではどうなるか確信が持てなかった）。人々がそれをやっているのを見つけた。素晴らしい。

「即決購入」

eBayで£300で、画面が割れた8GB M1 MacBook Air（ローズピンク）を見つけた。実際、もう少し待てばもっと安く手に入れられたかもしれない。

しかし、これは鉄は熱いうちに打てという状況だった。長年抵抗してきたが、待てば簡単に気が変わってしまうかもしれない。

8GB RAM？ ローズピンク？

理想的には最新のラップトップで最低16GB RAMが欲しいところだが、8GBとの価格差は、中古市場でも顕著だった。誰もが、Apple Siliconの8GBはAMD64の16GBのようなものだと言っていた。それは現実歪曲フィールドの効果のように聞こえたが、それらを裏付ける（少なくとも1GBあたりの性能がApple Siliconの方が良いという考え）アーキテクチャ上の現実、例えば「ユニファイド」メモリアーキテクチャがあった。私は信じることにした。

主にこのマシンをFlutter開発に使用することに興味があり、M1で8GBで問題なく開発しているという人を何人か見つけた。（未来からの注：素晴らしい、心配なく、私には十分な速さだ）

このモデルはローズピンクで、私が通常最も選ばない色だ。すぐに分解するために購入することを考えると、これはすべてをさらに完璧にした。

eBayで購入した。本当に動くのか？ パート4/11

eBayでの購入経験は概ね良好だった。しかし、分解を始める前に、それが実際に機能することを確認する必要がある。

eBayでの購入（ただし、評価の良い出品者から）なので、まず最初に確認する必要があったのは、このマシンが実際に機能するかどうかだった。

画面は損傷していた（出品リストの通り）そしてほとんど何も表示されなかった。具体的には、黒い割れた背景に、マシンがオンかオフかを示唆する数本の単一ピクセルの色の線が表示された。

現代のMacでは、電源が入っていることを示す「LED」のような派手なものは許されないだろう。これらの細い単一ピクセルの色の線が、私の電源インジケーターになるだろう。

モニターとケーブル

ここで最初の困難に遭遇した。私は非常に小さく、非常に安価なUSB-Cモニターを持っている。これが私の唯一の実際のモニターだ。私は通常、VNCやNoMachineなどを介してヘッドレスで作業し、Galaxy Tab S8 UltraのようなタブレットをリモートOLEDディスプレイとして使用している。モニターをあまり必要としないのだ。Boox Max Lumi E-inkタブレットにはマイクロHDMI入力があり、それはモニターとして機能するが…後で試すかもしれない。

そこで、小さなモニターを、2つあるポートの1つに接続した。（もう一方のポートは電源用だ）。モニターは点灯しなかった。

混乱の広大な風景が私の前に開けた。間違ったポートに接続したのか？ USB-CポートはUSB-Cポートではない、特にディスプレイと電源に関しては。特定のポートだけがMacに電力を供給できるのか、あるいは片方のポートだけがディスプレイ信号を出力できるのか？

ケーブル、両方のケーブルはどうだろう？ それらは実際に電力を供給したりピクセルを出力したりしていたのか、それとも間違ったストランドが入っていたのか？

MacBookはUSB-C経由でモニターに十分な電力を供給していたのか？ 追加のケーブルを接続して電力を供給する必要があったのか、バッテリーをさらに充電する必要があったのか、モニター自体に電力を追加する必要があったのか？

私のモニターは互換性がなかっただけなのか？ それはシンプルなAliExpressの汎用品で、Appleはサードパーティ製品との広範な互換性で知られているわけではない。OSでまだ有効になっていなかっただけなのか？

この時点で私はOSに入っていたのか、それともMacBookはまだ起動中だったのか…あるいは、間違ったボタンを無造作に押すとOSが破壊される可能性のある恐ろしい「リカバリゾーン」に stuck していたのか？ その解決策は「持っていない他のAppleコンピュータに接続する」か、「Apple Storeに持っていく（もしあなたのような格好の人間が中に入ることを許されるなら）そこで、GeniusがヘッドレスMacBookの概念に喘息を起こし、あなたが持っていないポンドで新しいものを買わせるだろう」というものだった。

恥ずかしいほどのケーブル交換の後（私のUSB-Cケーブルの80％は十分な電力を供給できなかったか、ピクセルを供給できなかった。そして私はこの問題を何度も経験しているので、ケーブルが良いと決して仮定しないことを今でも知っているべきだ）、ついに進展があった。

モニターが点灯した。

次に再び黒くなった。死んだような黒ではなく、TFTパネルが管理する、モニターが電力を供給され何かを表示しようとしているが何も表示されていないことを示す、あのゴミのような灰色の光沢のある黒だ。

電源ボタン

• Macbook Air M1 電源ボタン ［画像: Macbook Air M1 power button］

MacBookは少なくとも電源ボタンを提供してくれる。キーボードの隅にある特別なキーの形だ。それはキーボードの他のキーよりもわずかに低く、他のキーとはわずかに異なる触覚的な応答がある。これはユーザビリティ上の理由で「他」としてマークされているのかもしれない（それは気に入っている）、あるいはボタンに指紋センサーが組み込まれていることの副産物かもしれない。

Appleの経験不足と動作する画面がないため、このボタンは少し混乱した。タップが必要なのか、少し長押しが必要なのか、あるいは長押しで異なる機能が実行されるのか、それが「適切に」押されたのかどうか、確信が持てなかった。

ボタンに関する情報を検索しようとしたが、MacBookのモデルが非常に多く、さまざまな方法でアイデアを伝えるユーザーが多く、公式の詳しいドキュメントがなく、もちろんMacBookには画面があるという合理的な仮定がある。そう、私は電源ボタンに混乱した。

• 外部モニター - ログインUIなし ［画像: External monitor - No login UI］

電源ボタンを数回押し、再起動しているか確認するために待つと、さらに進展があった。木々だ！ macOSのログイン画面が表示されたが…完全にそうではなかった。ボタン、ダイアログ、あるいはユーザーインターフェース要素がなかった。

少し調べたところ、ログインUIが欠けているのは、2番目の画面がMacBookに接続されていることを示しているとわかった。ログイン画面は（私には見えない形で）壊れた内部ディスプレイに表示されており、私の小さなモニターは単に拡張として機能していた。なるほど。

さらに「インターネットリサーチ」をしたところ、CMD + F1で外部モニターに出力が出力されることがわかった。これは機能した。素晴らしい。これで、11インチのmacOSログイン画面が表示された。

• ログイン画面：成功 ［画像: Login screen: Success］

それは（ほぼ）機能した。

ディスプレイの取り外し パート5/11

ついにハードウェアの剪定に取り掛かる。

ディスプレイの取り外しは比較的簡単だったが、時間がかかった。多数のネジがあり、ペンタローブとトルクスヘッドだったが、これらはどの電子機器用ドライバーセットにも標準装備されている――私はそれを持っている。

YouTubeでいくつかの分解ビデオをチェックして、壊れる可能性のあるプラスチックタブや、短く引き裂けるリボンケーブルなどに遭遇しないようにし、ディスプレイコネクタがどこにあるかを確認した。私はかなりの数のラップトップを分解してきたが、これは最悪ではなかった。

蓋を本体から分離するのが難しかった。すべての固定具が取り外された後も、まだくっついていた。ヒンジの公差がきつかったのか（公差を十分にきつくすれば金属は金属にくっつく...Appleの確かに正確なエンジニアリングをもってしても、これはおそらく通常の固着であり、それ以上の神秘的なものではないだろう）、それとも組み立ての一部が邪魔になっていたのか、何か見落としたのか、判断できなかった。

ラップトップを90度に開き、テーブルの端にぶら下げて、蓋を本体から分離するために鋭く叩くことを提案するビデオを見つけた。彼らは私が見つけたよりも簡単にやっているように見えたが、最終的に蓋を取り外した。

蓋の保管

いくつかのケースやスリーブを検討した後（少なくとも、MacBookを片付けたときにキーが押されてスリープ状態になるのを防ぎたかった）、蓋は保管することにした。薄く、軽く、丈夫なので、コンピュータを保護するために使い続けるのはなぜだろうか？それはその仕事のために設計されたのだ。

蓋からガラスパネルを取り出すのは大変な作業だった。ほとんどの現代のディスプレイと同様に、非常に薄く壊れやすい（この場合はすでに壊れていた）もので、粘着剤か薄いテープのようなもので、蓋の金属シェルの内側にしっかりと固定されていた。熱とスクレーパーを使用する必要があり、恐ろしく、おそらく危険な混乱を引き起こした。何千ものガラスの破片が、見た目はキャラメルのリンゴのようだったが、実際には切りやすく、吸入可能なガラスだった。

ゆっくりと作業し、1分ごとに最新の破片を容器に掃き集め、手に埋め込まれたり、角膜や気管支に入ったりしないようにした。ブラシの勢いで破片をあちこちに拡散させないように、優しく行った。

しばらくして、ガラスをこすり取る前に、各ガラス領域にダクトテープを貼るというアイデアを思いついた。これはうまく機能し、破片の飛散を防ぎ、ガラスを蓋の金属シェルからこすり取るのを容易にした。

• Macbook Air M1 蓋、画面取り外し後 ［画像: Macbook Air M1 lid, screen removed］

最終的にすべてのガラスが取り外された後、粘着性が残っている領域がいくつかあり、鋭利な金属の端が未処理だった。髪の毛がくっついたり、キーボード/タッチパッドを傷つけたりするのを防ぐために、蓋の内側の表面全体を透明な粘着性プラスチックシートで覆った。

最終的な効果は、過保護なソファを連想させるが、手元にあったものであり、今のところはこれで十分だ。

工場出荷時リセット パート6/11

ただの形式的なもの…

ディスプレイが取り外され、物事はきれいになった。

これは中古のデバイスだ。OSはクリーンインストールされているように見えたが、念のため工場出荷時リセットを行った。プロセスはスムーズに進んでいるように見えたが、再起動時に問題が発生した。

工場出荷時リセット後の起動にどれくらい待つべきか確信が持てなかった。私はいくつかのデバイス（カスタムROMインストール後のAndroidフォンなど）でリセット後の初回起動に数分かかるのを見たことがあるが、オンラインの情報ではM1 Macではこれはかなり速いはずだと言っていた。

数分が経過したが、ディスプレイには何も表示されなかった。何が起こっているのか確信が持てず、電源ボタンで推測ゲームを始めた。電源LEDがあればと再び思った。壊れた画面が取り外されたため、手がかりを得るために数本のピクセル線が点灯するのさえ頼ることができなかった。

私が何かを壊した/中断したのか、それともリセットプロセスの通常の part だったのか、まだわからない。タップ、長押し、さらに長く押し続けるといった様々なパターンを試したが、それぞれ10、30、または60秒待ってから何か起こるのを待った。画面に何か表示されるのを期待する前に、どれくらい待つべきか？

ついに何かが起こった。黒い（しかし点灯/電源オンの）画面に戻った。起動途中のどこかにいると推測した。ログイン画面の時に外部モニターをプライマリにしたCMD + F1のコンボを試した。機能しなかった――キーコンボ/切り替えはmacOSの機能であり、まだ起動していなかった。オンラインで少し調べたところ、リカバリモードに入っている可能性があることが示唆された。

外部モニターのみを持つマシンでのリカバリモードの仕組みと、それを処理する方法を説明するビデオを見つけた。

外部モニターしかない場合のリカバリモード

状況はこうだ：

• リカバリモードは外部モニターを認識するが、内部ディスプレイの拡張として扱う。
• すべての便利なユーザーインターフェースが含まれるウィンドウは存在するが、「内部ディスプレイ」上にある（それが存在するかどうかにかかわらず）。
• ファントム内部ディスプレイは外部モニターの右側に描画される。

私の場合、外部モニターの解像度は内部モニターよりも高さが低かった。これが状況をさらに混乱させた可能性がある。メニューバーが両方のディスプレイにまたがって表示され、モニターが高ければ、空の黒い画面よりもはるかに役立つ手がかりが見えただろうと思う。

• macOSリカバリ ファントム画面 ［画像: MacOS Recovery Phantom Screen］

リカバリモードで作業を行うには、ファントム画面からウィンドウを外部ディスプレイにドラッグする必要がある。ウィンドウはタイトルバーでしかドラッグできない。そのため、画面の右端にタッチパッドポインターを飛ばし、タイトルバーがどこにあるかを推測して、左側の実際の表示画面にドラッグして戻す必要がある。

これには時間がかかった。見えない画面上のウィンドウは中央揃えだったと思うが、モニターと解像度が異なっていたため、視覚化して狙いを定めるのが難しかった。しかし、一度完了すると、リカバリモードのすべてにアクセスできた。

リセットを完了した後、起動した。モニターは起動プロセスの後半まで表示されないが、それは問題ない。

内部画面を取り外したMacBookで、外部モニターからアクセスできた。

このマシンは動いているのか？ パート7/11

LEDへの嫌悪感を問い直す。

このマシンをヘッドレスで使用する上で最も困難な問題の一つは、電源が入っているかどうかを知ることだ。マジで。

外部モニターを接続した場合（まあ、その場合はヘッドレスではない）、画面に何も表示されないのは以下の可能性がある：

• MacBookの電源が入っていない
• MacBookがスリープ状態である
• モニターまたは接続に問題がある（例：ケーブル不良）

NoMachineやVNCで接続しようとして失敗した場合、それは以下の可能性がある：

• MacBookの電源が入っていない
• MacBookがスリープ状態である
• MacBookがネットワークに接続されていない
• NoMachine/VNCがMacBookで起動していない

私は、デザイナーが電子機器に貼り付ける無数の点滅するLEDが本当に嫌いだ。それらは常に邪魔で注意をそらし、悪いと思う。しかし、このMacBookには一つくらい欲しい！

試したこと

• 電源インジケーター付きUSB-C SDカードリーダー ［画像: USB-C SD card reader with LED indicator］

小さなUSB-C SDカードリーダーを持っている。電源供給時に点灯する赤いLEDが付いている。しばらくこれを使ったが、実用的ではない。小さいが、壊れるリスクがあるほど突き出ている。USBポートに良いテコがかかり、何かに引っかかったらすぐに引き抜こうとする（充電中の第一世代Apple Pencilのようなものだ）。

• LEDインジケーター付きCaps Lockボタン ［画像: Capslock button with LED indicator］

ある時点で、キーボードのcaps lockボタンにCaps Lockがオンのときに点灯するLEDがあることに気づいた。そして（通常はBluetoothキーボードとポインティングデバイスを使用することを覚えておいて）、Caps Lockを内蔵キーボードに適用しても、Bluetoothキーボードには影響しない。Caps Lockをオンにしたままにしておけば、LEDは点灯したままになる。

上記の両方のアイデアの決定的な問題は、MacBookが完全に起動して準備ができたときにしか機能しないことだった。ポートとCaps Lock LEDはそれ以外の時間はオフになっているのだろう。電源が入っているかどうか混乱する期間のほとんどは、起動中、スリープ中、シャットダウン中など、半オンの状態だった。

現在の最良の解決策

ルーターが「接続されているクライアント」のリストで、MacBookが接続されているかどうかについて比較的迅速/最新の情報を提供していることに気づいた。起動プロセスのごく早い段階でWi-Fiに接続され、シャットダウンを開始するとすぐに切断されるようだった。

それに続いて、ターミナルウィンドウでMacBookをpingし始めた。これは作業中に近くに置いておくことができる。

当然の次のステップは、これを適切にスクリプト化することだった。私の目標は、MacBookが接続されているかどうか、およびバッテリー充電レベルを示す短いステータス行を取得することだった。以下のスクリプトがその役目を果たした：

#!/bin/bash

# LAN上のMacをPingする
# 生きている場合は、別のスクリプト`battery-check`（Mac上に存在する）を使用してバッテリーレベルを確認する
# オフ/オンの状態、およびおおよそのバッテリーレベルを示すために色付きテキストで結果を返す
# 結果のテキストを毎回同じ単一行に上書きして繰り返しループする

ip_to_check=192.168.8.123
hostname=AIR

wht='\033[1;15m'
red='\033[1;31m'
ylw='\033[1;33m'
ong='\033[38;5;208m'
grn='\033[1;32m'
nc='\033[0m' # 色なし

update_battery ()
{
  # SSHでログインし、バッテリー充電情報を取得するスクリプトを呼び出す。
  battery_check_output=$(ssh AIR "bash --login -c battery-check")

  # `battery-check`は`battery: 18%`のような文字列を返す。数字を抽出したい。
  percentage=$(echo "${battery_check_output}" | tr -dc '0-9')

  if [[ $percentage -lt 15 ]]; then
    battcolor=$red
  elif [[ $percentage -lt 30 ]]; then
    battcolor=$ong
  elif [[ $percentage -lt 80 ]]; then
    battcolor=$ylw
  else
    battcolor=$grn
  fi 
}

# カーソルを隠す
tput civis

# 時々（起動しすぎ？）最初の呼び出しが失敗する
# それを乗り越える
update_battery
sleep 1
update_battery
sleep 1


i=0
while : 
do

  # -c 1 ... カウント 1（一度だけpingする）
  if ping -c 1 ${ip_to_check} &> /dev/null; then
    # 一時的に白にして、バッテリーがチェック/更新されたことを示す（2 * 5 = 10秒）
    if [[ $i -lt 2 ]]; then
      color=$wht
    else
      color=$battcolor
    fi

    echo -ne "  ${hostname} ${grn}    ON     ${nc}${color}${percentage}%${nc}\r"

    # iは5秒ごとにインクリメントされる
    ((i++))
    
    # インクリメントしてnカウントごとにバッテリーを更新する
    # 5秒 * 36 = 180秒 = 3分
    if [[ $i -eq 36 ]]; then
      i=0
      update_battery
    fi
  else
    echo -ne "  ${hostname} ${red}   OFF       ${nc}\r"
  fi

  sleep 5
done

https://codeberg.org/mm-dev/shell-scripts/raw/branch/termux-proot-ubuntu/mac-get-status

私はすでにMacにバッテリーレベルを報告する小さなスクリプトを持っていました（Macの組み込みsystem_profilerの非常に単純なラッパーで、出力を短縮するためだけです）。

#!/bin/sh

percent=$(system_profiler SPPowerDataType | grep "State of Charge (%)" | awk '{print $5}')
echo "battery: ${percent}%"

• 小さなフローティングウィンドウに表示される監視スクリプト（クローズアップ） ［画像: Monitoring script in a tiny floating window with close-up］

次に、mac-get-statusスクリプトを小さなウィンドウにフローティングさせたいと思った。

次のスクリプトは、新しいウィンドウでターミナルを開き、macmonitorという特定のタイトルを付け、mac-get-statusを実行します：

#!/bin/bash

$TERMINAL --title macmonitor -e "mac-get-status" &

https://codeberg.org/mm-dev/shell-scripts/raw/branch/termux-proot-ubuntu/mac-monitor

次に、ウィンドウマネージャー（DWM）に、その特定のタイトルを持つウィンドウに特別なルールを適用するように指示します。これはDWMでのやり方ですが、他のウィンドウマネージャーも同様のことを達成する方法があるかもしれません。

static const Rule rules[] = {
    // If an Xfce4-terminal window has title 'macmonitor':
    // - Make it float
    // - Make its dimensions 150px x 22px
    {"Xfce4-terminal", NULL, "macmonitor", 0, 1, -1, 0, 0, 150, 22, 1},

    // other rules...
};

マグネット パート8/11

マグネットは楽しい。

• MacBookを蓋の上に置いている。やらないでください。 ［画像: Macbook sitting on top of its lid. Don't do it.］

私のささいな見落とし（繰り返し！）のために、途方もない混乱と時間の無駄を経験した。

前述したように、MacBookの蓋をヒンジから外し、壊れた画面を取り除いて、一種の…蓋として使用することにした。

使用中は、蓋をMacBookの下に置くのが当然のように思えた。そこには完璧にフィットした。

最初の数時間、数日、数週間、マシンがランダムにオフ/オンになる（実際にはスリープ/ウェイクだが、その時は知らなかった）という断続的な問題があった。

初期の頃、マシンがオンになっているかどうかを知るのに十分な苦労をしていたのを覚えているか。

それは蓋の中のマグネットが、ベースのホールセンサーをアクティブにし、蓋を開閉していると思わせたためだった。ベースの厚さのため、マグネットは通常よりも近くになく、アライメントも完璧ではなかった。そのため、「ラップトップの下に蓋があるとスリープ状態になる」という単純な問題ではなかった。これは、環境の揺れによって現れたり消えたりする散発的な問題だった。精神的なつながりを見つけ、何が起こっているのかを理解するのにしばらく時間がかかった。

# TODO 蓋からマグネットを取り除く！

リモートアクセス パート9/11

このマシンを実際にどのように使用しているか。

モニターを接続する面白さは過ぎ去ったので、実際にマシンを使用しているのはこの方法だ。

SSH経由のリモートビルド

私はほとんどの時間Androidタブレットで作業しており、Termux、Proot-distro、Termux/X11を使用してDebian Bookworm arm64を実行している。このセットアップには欠点があるが、非常に快適で、仕事の90％をこなすことができる。

現在の問題の一つは、Android SDKのarm64バージョンではarm64 APKをAndroid用にビルドできないことだ。メイン開発中は、作業中のアプリのLinuxバージョンをビルド/実行するだけで十分だ――Flutterはマルチプラットフォームで、プラットフォーム間でも驚くほど一貫性がある。しかし、もちろん、いつかはAndroidデバイス用のAPKをビルドする必要がある。

特定のプロジェクトのAPKをすばやくビルドする必要がある場合は、次のスクリプトのようなものを使用する（これは私のWebDAVオーディオブックプレーヤーアプリ、auDAV用だ）：

#!/bin/sh

# Termux/proot-distroから実行するスクリプト
# - AIR（`~/.ssh/config`で定義されたホスト）に接続する
# - 作業ディレクトリにログインする
# - APKをビルドする
# - APKをローカルマシンに同期する


remote_commands=$(cat << 'EOF'
echo "~~~~~~~ Remote: Source local environment ~~~~~~~"
source ~/.zprofile
source ~/.zshrc

echo "~~~~~~~ Remote: Change working directory ~~~~~~~"
cd ~/development/audav

echo "~~~~~~~~~ Remote: Pull latest from git ~~~~~~~~~"
git pull

echo -e "\n~~~~~~~~~~~~~~ Remote: Build APKs ~~~~~~~~~~~~~~"
flutter build apk --split-per-abi
EOF
)

ssh AIR "bash --login -c '${remote_commands}'"

echo "\n~~~~~~~~~~~ Local: Sync APKs to local ~~~~~~~~~~"

rsync -r --mkpath --progress AIR:development/audav/build/app/outputs/flutter-apk $HOME/000-WORK/audav/build/app/outputs/

https://codeberg.org/mm-dev/shell-scripts/raw/branch/termux-proot-ubuntu/audav-build-on-mac

NoMachineによる完全なリモートグラフィカルアクセス

• S8タブレット、トラックボール、スプリットキーボードでmacOSにリモート接続 ［画像: Remoting into MacOS with S8 tablet, trackball and split keyboard］

macOS、iOS、iPadOS向けのアプリをビルドするには、macOSの（そしてXCodeに到達する前の） torturous なウィンドウ管理、退屈なアニメーション、ひどいファイルマネージャーに耐えなければならない。

苦痛を和らげるために、少なくともGalaxy Tab S8 UltraのOLEDスクリーン、DEFT PROトラックボール、Ferris Sweepスプリットメカニカルキーボード経由でmacOSを使用できる。

NoMachineはmacOSへのリモート接続にうまく機能し、LAN上では遅延が非常に少なくパフォーマンスが良い。Androidとarm64 Linux向けのクライアントソフトウェアがあり、私の好みのLinux/DWM環境からmacOSに素早く簡単にアクセスできる。

ヘッドレス実行：学んだこと パート10/11

いくつかの発見。

蓋

• 蓋を取り外すと電源が入る（ベースのホールセンサーは蓋のマグネットによってアクティブになる）。
• 蓋を元に戻すとデバイスはネットワーク上で見える状態になるが、SSHでアクセスできなくなる（何らかの「スリープ」状態）。
• ユーザーが開始したシャットダウンプロセス中（完了までに最大20〜30秒かかる）、蓋を元に戻すとマシンが再起動する――そのため、蓋を元に戻す前に少なくとも15〜20秒待つこと。蓋はもはや接続されていないため、「開閉」は意味をなさないので、「取り外し/取り付け」を使用する。

電源ボタン

• 電源ボタンを5秒長押しするとシャットダウンプロセスが開始されるが、マシンは数秒間ネットワーク上で見える状態のままである。シャットダウン完了まで少なくとも15〜20秒待つこと。
• 電源ボタンを2秒長押しするとマシンがオンになるが、ネットワーク上で見えるようになるまで約20秒かかる。このシリーズの前のパートで述べたように、「ネットワーク上で見える」ことは「マシンがオンになっている」ことの代理として受け取られる。

デッド（電源なし/低電力）から

数回、1週間以上マシンを使用せず、バッテリーが非常に消耗したことがあった――正直なところ、この状況にもっとうまく対応できるように設計されていないのは残念だ。

しばらくの間、充電に苦労し、以下のすべてを試したが成功しなかった：

• 最初のUSB-Cポートで10分以上充電
• 2番目のUSB-Cポートで10分以上充電
• 上記の充電期間中に数回電源を入れようとした
• 電源投入の試行ごとに、MacBookがLANで見えるようになる兆候を2分待った。充電ユニットはDC 12V/20Vフィードに直接配線された専用のUSB PD/QC充電器であり、非常に安定/信頼性が高く、十分なアンペア数がある。

最終的にこの問題を解決したのは以下の方法だった：

• すべてのケーブルを抜く
• 充電ケーブルの一方の端を最初にMacBookに接続する（上部/コーナーポート）
• 次に、ケーブルのもう一方の端をUSB充電器に接続する
• 30秒後、アクセスできた（MacBookはルーターにクライアントとして表示され、sshでアクセス可能になったなど）。

これは見当違いかもしれない。例えば、ケーブルの接続順序は重要ではなく、代わりにバッテリーが充電され、最終的に成功した試行が起動を可能にする閾値を超えただけかもしれない。応答が非常に速かった（この順序でケーブルを接続してから30秒後にマシンがオンになった）という事実は、これが可能性が低いことを示唆している。

私が考えられる唯一の説明は、充電ケーブルのどちらの端を最初に接続するかが重要であるということだ。おそらくUSB-Cハンドシェイク/電源ネゴシエーションに関連する何らかの理由で、私は無知だ。これは推測であり、現実には意味をなさないかもしれない。私はこの情報/観察を非常に低い重み付けでここに残す。それが現状だ。

最終結果とボーナス パート11/11

私は自分の選択と、MacBookをビルドマシンとして私の作業環境に統合できた方法に本当に満足している。

良い点

• 静かなのが気に入っている。
• Apple Siliconは期待通り素晴らしかった――私の太陽光発電などの状況では、ワットあたりの性能が非常に良い。
• 電源が入っているかどうかわからないという煩わしさは、スクリプトのおかげで、LAN上で使用している限り（現実的には常にそうだが）ほとんど解消されている。

悪い点

• macOS。使用しなければならないとき（Macファンごめんなさい…Windowsよりは好きだ）。
• 電源オフ時（オフ、スリープではない）にバッテリーが全く電力を保持しない。満充電の状態でオフにしても、数日後には完全に空になり、電源を入れる前に充電が必要になる。

私はこれをメインマシンとして使うことは決してないだろうし、それが計画でもなかった。私は最小限のLinuxと、DWMのような見えないタイリングウィンドウマネージャーが好きで、ウィンドウをドラッグしたり、アニメーションを見せられたりするのは、私の好みに合わない。

Asahi Linuxのことは知っているが、それは電力効率をそれほど特別なものにしなくなり、私がFlutterに必要な開発スタックとどのように連携するかわからない。さらに重要なのは、執筆時点ではDP Alt Modeが機能しておらず、USB-Cポートに接続されたモニターが機能しないことだ。ディスプレイを取り外したことで、これは私を困らせる。

私にとって、これはAppleエコシステムとそのユーザーのために責任を持ってソフトウェアをビルドできるようにするための投資だった。それは特定のタスクサブセットのためのツールであり、その条件下では必要なことをしてくれる。

ボーナス：E-ink MacBook

Boox Max LumiがMacBookのモニターとして機能できると言ったのを覚えているか？ それが完全に機能しているところだ。

• MacBookがBoox Max LumiをE-inkディスプレイとして使用 ［画像: Macbook using Boox Max Lumi as an E-ink display］

アクセシビリティ/ディスプレイの設定を調整した後、macOSはE-inkでもそこそこ見栄えがするようにできる。

もちろん、E-inkの通常の注意点（リフレッシュレートやゴースト）は適用されるが、Vimで快適に作業できるだろう。もし私がAppleのウォールドガーデンに閉じ込められた想像上の未来のディストピアにいたら、爆弾が投下される直前に彼らが起動できた数兆ドル規模のリアリティディストーションフィールドによって保護された、存在するすべてのものであれば…。