他方、ガンダムチャンネルではガンダムシリーズの劇場版、OVAが、宇宙世紀の設定年順に毎週土曜日21:00から24時間限定で公開されています。
今週は「0083 ジオンの残光」の5話〜7話です。
こんなうれしいことはない、ですね。
いい時代になったものです。
[2021-05-25] なんと毎週水曜日のエルガイムの日は先週の13話「コンタクト」（公開期間はおそらく3週間）で一旦お預けです（サンライズの告知）。
いつの日か54話までの放映が再開されますように。
シー・ユー・アゲイン！
でも、よくよく考えると何も心配することはありません。
Apple SiliconはiPhone/iPadのAxxシリーズのように毎年改良されていきます。
コア数を2倍4倍にするのも容易です。
現在のM1でIntel Windowsの地道なエミュレーションに時間がかかっているとしても、M1XやM2では数倍速く処理できるようになって、あっというまに追いついてしまいます。
さらにAppleがその気になれば、Apple Siliconの仕様が公開され、ソフトウェアエミュレーションのコードが最適化されるので、ソフトウェア的にもRosetta 2と同等に数倍速くなる余地もあります（最低でもPallarelsはきっとそうしてくるはずです）。
こちらはそれほどMicrosoftには期待できませんが、Arm版のWindowsとアプリが充実すれば、すでに実用的なパフォーマンスが出ているArm版Windowsを使っても良いわけです。
M1はV1.0製品なので、本領を発揮するのはむしろ今後と言えるでしょう。
将来の見通しは明るいです。
[2021-03-20] 以前書いた、私のM1X/M2の予想の記事はこちら。
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」コマンドに特権昇格の脆弱性、各ディストリビューションの対応一覧）。
しかしながら、この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の間でしか共有できないのです。
次善策をいろいろ考えましたが、どれもしっくりとこず、釈然としません。
そういえばiPhoneとiPadの写真もなんとかしないといけないです（今まではもっぱらMac miniに吸い上げて蓄積してきました。NASのアプリ管理にすれば親和性が良さそうですが、上に書いたようにmacOS側の写真アプリが使えなくなります）。
なかなか悩みが尽きません。
私も書きましたが、Intel x86のOSの実行はArm64のOSを実行するのに比べてパフォーマンス的に不利と明記されています。
webサイトではUTM appのダウンロードリンクに加えて、設定済のゲストイメージや、OSの設定方法がGalleryページに公開されています。
Intel x86のUbuntu、Windows XP、Windows 7などをダウンロードしてすぐに試せるようになっています。
Arm64のUbuntuやWindows 10 に関しては設定方法が記載されています。
他のArm64 Linuxは設定済のものも提供されているものもあります。
一点だけ注意点があって、現在バージョン（v2.0.17）では、ダウンロードしたイメージやISOファイルは ~/Library/Containers/com.utmapp.UTM/Data/Documents というフォルダに置く必要があります。
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の仮想化ゲストも実行できるようになりました。
先日紹介した省電力ミニPCに目論見通りNAS OSをセットアップしました（4TBのUSB HDDを追加）。
NAS OSはミニPCでも稼働でき、macOSのTime Machineバックアップにも対応、iPhone/iPad用アプリで自宅バックアップにも対応、さらにDockerコンテナで色々なものを動かせます。
RockstorはOSSのNAS OSで、従来バージョンのV3.xはCentOS、最新V4.xはOpenSUSEをベースにしていて、btrfsをファイルシステムに使用します。
日本語の情報はあまりないのですが、macOSのTime MachineやWindowsのVolume Shadowingのようなファイルシステムのスナップショット機能が使いたくて、このRockstorを選びました。
何事も最初はうまくいかないもの。
まずは失敗したセットアップ方法を共有させてください。
さらに調べると https://github.com/rockstor/rockstor-installer でRockstorの一括インストーラを作成できることが分かりました。
RPMパッケージをインストールした時に行われる設定だけでは足りない設定が入っているはず。
なんとかこれでうまくいきましたので、セットアップ手順を記しておきます。
なおRockstor V4.0.4は次期正式バージョンのリリース候補版でArm64にも対応していますが、ここでは私が実際に試したx86_64の手順のみです。
Samba上のホスト名（ここではホスト名をrockstorだとします）はDNSのnslookupやdigコマンドでは確認できなくて、macOSでは、
% smbutil lookup rockstor
Windowsでは、
> nblookup rockstor
とします。
接続は、macOSではFinderから [移動] => [サーバーへ接続...] で
smb://rockstor/sharename
WindowsではWindows Explorerに
\\rockstor\sharename
と指定します（ここで指定できるホストはSambaホスト名、DNSホスト名、IPアドレスです）。
M1 MacBook AirのTime Machineの初回バックアップが有線LAN接続で1時間くらいで完了できました。
Rockstor側は [Rock-ons] メニューからNextCloudもすんなり設定できて、いろいろと活用できそうです。
[2021-01-04] 早速V4.0.5に更新されていました、更新内容はAD連携とdocker network関連です。
先日、PCをWindows10 1909から20H2にアップデートしました。
IMEが新しくなり、スマホに近い予測変換が使いやすいと最初は気に入って使っていました。
でもどうしても目に付く問題があり、古いIMEに戻しました。
今回のIMEが早熟だったことはMicrosoft自身も明らかに認めているようで、設定画面に「以前のバージョンのMicrosoft IMEを使う」の項目が堂々と存在しますし、KB4564002（URLがyou-might-have-issuesですよ）でも未解決の問題が残っていることを認めています。
正式バージョンのハズなのに、ちょっと不思議な状況ですね。
わたしが新しいIMEを使っていてどうしても許容できなかったふるまいは以下です。
勝手に変換モードが変わってしまったり、余分な改行が入力されてしまうは、入力効率に大きく影響します。
以前のIMEのように、詳細なキーカスタマイズができるのなら、まだ回避する手段もあったと思いますが、それも今回は無くなっています。
そのうえ、変換キーの置き換えも、以前はremapkeyなどでレジストリ定義だけで出来ていた（私はF13を変換キーに定義して、CapsLockと右AltをF13にしていました、ちなみにUSキーボードの場合です）のですが、新しいIMEではPoｗerToysを常駐させないといけなくなっています。
もう少し、パワーユーザの意見を聞くなど、事前に対策を立てられなかったのでしょうかね、と思います。
 |
| Kodlix GD41の製品ページから |
古いMac mini 2012は最新OSの対象から外れましたし、何よりとても暑くなります。
上にWi-Fiアクセスポイントを置いていたらMac miniの熱で動作がおかしくなります。
複数のMac、PC、iPhone、iPadの大事なファイルや写真やメールやノートやバックアップを何とか安全に保管する場所がずっと欲しかったのです。
クラウドではすぐに利用枠を超えてしまいます。
そこで、ミニPCでNAS OSを動かして、簡単便利に運用できれば、と考えました。
今どきのNAS OSはコンテナ機能まであって、より幅広いアプリ（スマホ連携できるnextCloudなど）を動かせるようになっています。
NAS専用機（QNAPやSynologyやAsustor）はスペックが低めの割に価格が高いと感じました（スマホ連携アプリや出先アクセスサービスなどはメリットですが）。
Celeron N4000/J4000のミニPCは似たようなのがいくつも出ています。
GD41の購入後に分かった気になる点をまずは挙げておきます。
手間をかけずに稼働という訳にはいかず、まだ試行錯誤中ですが、うまい使い方が定まればここで紹介させていただきますね。
[2021-12-01] 自分のためのメモ、メモリ32GBでも認識するとの情報アリ、CPU負荷は小さいけれどメモリを大量に消費するアプリ（コンテナじゃなくてVM、LinuxゲストじゃなくてWindows）の家庭内ホスティングに良さそうですね、max 2.4GHzとのバランスが多少悪いですが。
さすがの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の元の記事)、さて実際にはどういうものが出てくるか、楽しみが尽きないですね。
そんな中、ASRockから追加で、Ryzen 4000 Mobile搭載のミニPC、ASUS MARS 4000Uが発表されました。
デスクトップRyzen版のミニPCから減りますがそれでも、ストレージがM.2とSATAの合計2台内蔵可能になっています。
CPUは4300U (4Core 4Thread)、4500U (6Core 6Therad)、4800U (8Core 16Thread)から選べます（モバイルCPUなので付け替えはできない）。
早速 Neweggというカリフォルニアの通販会社が販売を開始しています。
現在は6 CoreのRyzen 5 4500U Mobile版のみで、\46,441となっています（CPUのみ付属。メモリ、ストレージ、OS無しです）。
8 Core 16 Threadの4800Uはおそらくこれより2万円くらい高くなると思われます。
デスクトップ版CPUのRyzen 7 PRO 4750G 8 Core 16 ThreadはTDPが他と同じ65Wとはいえ、ミニPCには排熱設計的に少々無理があるというレポートを見かけます。
モバイル版CPUならTDP 15W、cTDP 10-25Wなので、ミニPCにはうってつけ、安定して動作するのではないでしょうか（さらに縮小してラップトップまで行くと厳しいかも）。
5nmのApple Siliconのパフォーマンスで話題騒然の中ですが、ADM ZEN 2 Ryzen 4000は7nmなので、Apple M1と順当な勝負ができます。
Windowsや、従来のLinuxとの互換性を重視するならRyzenは良い選択肢だと思います。
[2020-12-26] Mouseコンピュータからmouse CT-6という名前で4500U版の販売をするようです（PC Watch - マウス、Ryzen搭載で厚み2.8cmの超小型パソコン「mouse CT6」を本日店頭先行発売。税別6万9,800円から）。
こちらは、デスクトップ向けの 8Core/16Thread Ryzen 4750GEですが、ThinkCentre M75q Gen 2 も割引クーポンが使えてかなりお得なようです（こちら、岡ちゃんさんのYouTubeで知りました）。サイズは 182.9 x 179 x 36.5mm。
またさらに、ベアボーンのミニPCがASrockから出ていますね（Ark - ASRockから久々なベアボーンは組み込み向けRyzen搭載、コンパクトベアボーン「4X4 BOXシリーズ」）。こちらは組み込み用低電力の第一世代ZenのRyzenプロセッサです。サイズは 110.0 x 118.5 x 67.3mm。
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
すると、右の図の１つ目のダイアログが表示されますので、指示の通り [インストール] ボタンを押します
（このように必要なものがオンデマンドでインストールを促されます、面白いですよね。
事前に 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
ただし、今度は右の図の２つ目のダイアログが表示されます。
これは、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
一発で起動できて、これ捗ります。
Posts
All Comments
