最悪（かもしれない）に備えよ（、ですか）：アフターサービス

　5/13のエントリで記した予測結果（予想結果ではない）は当たらずと言えども遠からず。約2週間悲観的だったか。

　不幸中の幸いは今でもデルタ株が最も厄介な変異である点で、対応とその結果が時間遅れ含めてかなり正確に予測可能であることと、ワクチン効果がほぼ期待通り見られること。ゲームチェンジは無い。とは言え、オリンピック終了後にマスコミがまた手のひらクルーするかどうかも影響因子としか思えないのには頭が痛い。

　クルーして与党批判に使うか、パラリンピックにも配慮してクルーしないか、個人的には割と見どころではないかと思っている。オリンピック向け手のひらクルーとほぼ同時期にネット上の言説にも動きがあったが、その動きの内容からは少なくともパラの段階では再クルーは無いかも知れないと思わせるものがある。ただし、スポンサーの意図は不明だ。

　国内大手企業に多いシナリオは９月いっぱいでの流行収束だが、現在の流れはそのシナリオを台無しにする方向だ。職域接種にはそのような切実な背景を見る。これまでのマスコミの振る舞いに正直うんざりしている企業は少なくないだろうと思う。多くのマスコミは気づいていないのか意図してかは不明だが、マスコミの張ってきたキャンペーンは多くの企業の新型コロナ対策活動を、よりにもよって虚偽や印象操作での邪魔してきている。新型コロナウィルスはその蔓延の終焉後にマスコミの一部を殺しにかかってくるかもしれない。

USBメモリ運用にこだわって、Linux MintをXPS 8700で使う

　先のエントリに記載の通り、セカンダリPCとなった私のDell XPS 8700は短期のうちに何度も何度もWindows10をクリーンインストールされるという憂き目にあった。が、それと並行してLinuxの導入も試みられていた。そもそもサーバー用途での運用が目的だから、OSには堅牢性、特に原因不明の（嘘、アパート内に迷惑なパケットをばらまく連中がいる）変な通信負荷を喰らっても落ちない強さが求められる。この視点からは、何れかのLinuxディストリビューション（安定版とされるもの）の導入の検討は自然と言える。ただし現行のサーバー運用はあくまで短期的なものなので、いつでもWindows10運用に戻れる状態をPCとしては維持しておきたい。

　なお、約20年程前にはRedhat Linuxベース、自作PCで数値計算用のベオウルフ型PCクラスター（6台構成）を職場で一人で組んだ経験もあるので、私自身のLinux歴自体はわりと長い。

　と言う訳で、Linux Mint MateをUSBメモリベースで運用できないか色々試してみた。Linux Mintを選んだ理由は特に無いが、パステルグリーンは好きな色だ。まぁ数値計算に使う訳ではないので、個人使用での評判が良い印象のubuntu系が良いかなとはちょっと思っていた。具体的な理由は省略するが、”ベクトル化＆MPI並列”ガチ派（地球シミュレータ全盛期に数値計算高速化を経験的に学んだ世代に多い）の生き残りなので、数値計算用ならCentOS一択だったろう（少なくとも３年前までの知識に基づけば。今はどうなんかね）。

　さて、USBメモリベースと一言で言っても、具体的な運用形態として少なくとも以下の３つの方法がある。

1. ライブUSBメモリとして使う（本来はインストールメディアなのだが、これからブートしてデスクトップ環境まで使える）
2. 書き込み可能なライブUSBメモリとして使う
3. USBメモリにインストールする

　１．のライブUSBを使う方法の利点は動作の軽さだ。Linux Mint MateのライブUSB運用でのキビキビした動作は心底衝撃的だった。また後述するように、読み取り速度がそれなりならばUSBメモリの性能を選ばないのも一つの利点だ。USBメモリからの起動となるので別ドライブにインストール済のWindows10にもEFIシステム領域にも触らないし、別PCに刺しても使える。欠点は作成したデータや変更した設定が残せないことだ。直近のサーバー運用ではウェブブラウザと１つのアドオン、加えて１つのシェルスクリプトを使うだけなので、実のところブート後の10分もあれば必要な環境は構築できる。一旦稼働すれば数週間そのままと考えれば大した手間でもないのだが、それでもそこをなんとか・・・と言うところが人間やね。

　３．はUSBメモリ自体をインストール先ドライブとして使い、既に別ドライブにインストール済のWindows10とデュアルブートできるようにする手だ。EFIシステム領域にはLinuxのブートローダー（Linux Mintではubuntuのブートローダー）が追加される。変更した設定や作成したデータは残るが、USBメモリを別のPCに指せばそのまま動く、と言う訳には当然いかない。またオチを書いてしまうと、パッケージを追加していくにつれて急激に動きがもっさりし始める。これはUSBメモリのランダム書き込み速度の影響が大きい様に思われる。別PCに刺しても動かせない、動作は重いとなると、USBメモリへインストールする旨味は実質的に無くなってしまう。要はHDDなりSSDなりにインストールしろと言うことだ。

　で、結局２．を主案として、具体的な使い方を色々試すことにした。２．の方法の利点は１．の方法の利点に加えて、作成したデータや変更した設定が残せることである。他方パッケージの追加などは、３．の方法と同様に動作を重くする要因となる。だから、「色々試す」とは、動作を遅くすることなくどこまでパッケージが追加できるか、を探ることに等しいのが実態だった。ここでメディアの作成やフォーマットには、rufus Ver.3.7を使った。

　最終結果から書くと、OS付属のウェブブラウザFirefoxにアドオンを１つ入れ、vimのパッケージをインストールして運用開始とし、それ以外は日本語環境パッケージすら入れなかった。まぁ良いんですよここまでで、現時点での利用に関してはね。とにかくキビキビ動作するところがミソで、常に開いているウィンドウはシステムモニタ、ブラウザ×２、ターミナル×１だけだ。いじった設定もファイアウォール、キーボードマッピング、電源管理（スリープ機能のオフ）、フォントサイズ（老眼対応）ぐらいだ。

　とは言え、おそらく日本語環境パッケージの導入までは、キビキビ動作をスポイルしないものと考えている。ただし、書き込み速度が高いUSBメモリを使うことが前提っぽい。実は日本語環境パッケージの導入は３つのUSBメモリで試していて、キビキビを維持できたものと、耐えられないレベルでもっさりしたものがあった。あと例外なくもっさりを引き起こしたのは、Chromeリモートデスクトップの導入だ。セカンダリPCには専用モニタが無いのでリモートデスクトップが使えると運用が便利なのだが、パッケージ導入後は起動からデスクトップ表示までは早いものの、それ以降はうんともすんとも言わなくなってしまった。

　なお、私の使ったLinux Mint Mateでは「アイドル10分で画面スリープ」がGUIからは解除できなかったので、ネット上の情報に従ってxsetコマンドでこれを解除した。全くもって先人の知恵は有難い。このエントリを書いている時点で既に４日間連続稼働しており、地味で退屈なタスクを10秒単位でこなし続けている。

　最後に検討時に用いた３本のUSBメモリの性能（CristalDiskMark測定結果）と使用感について簡単に触れておく。

　１本目は容量32GB、USB3.1対応だが、ライブUSB以外では使い物にならなかった。理由はおそらく書き込みの遅さで、特にランダム書き込みの低速ぶりが致命的のようだ。下に示すCristalDiskMark測定結果の図中右下の数値がランダム書き込み速度だが、0.00MB/sって何ですか？このUSBメモリにはインストールも試みたが、ファイルのコピー（書き込み）が余りに遅いため、インストール開始から完了まで20時間程を要した。就寝前に開始したファイルのコピーが、起床時には未だ終わっていなかったのには正直驚かされた。繰り返すが、ライブUSBとしては全く問題を感じることは無く、動作は常にキビキビしていた。また同製品はWindows10の回復ツールを格納してクリーンインストールの際に何度も使っており、そちらでも特に問題や不満を感じたことは無かった。最初にisoイメージファイルをシーケンシャルで書き込み、基本読み出しでしか使わないから、ランダム書き込みが悪さする状況が無いんだわな。

　２本目は容量16GBでUSB3.1対応で、インストール先にしてもインストール作業自体は2時間もあれば終わった。１本目との最大の違いはランダム書き込みが数百倍速いことだ。書き込み可能なライブUSBとしても速度的に使えるレベルだが、容量が小さめなのは微妙に問題。書き込み可能領域として8GBは確保できるので日本語環境のインストール（4GB程度必要）もできて２．の使い方でも容量は十分とする向きもあるが、作業内容によってはtmp下に8GBは欲しい場合もある。私の場合はtmp下に16GB欲しかったので、より容量の大きい３本目を使うこととした。

　３本目は容量128GB、USB3.2対応で、書き込み可能なライブUSBとしては容量的にはオーバースペックかと思う。右上のシーケンシャル書き込みが３本の中で圧倒的に速いが、その差を実感したことは無い。２．の使い方では書き込み可能領域に64GB割り当てたが、tmp下の容量は要求ギリギリの16.7GBだった。まぁ不要ファイルの削除をシェルスクリプトで徹底的に処理するようにしたので、問題無いでしょ。３．の使い方のインストール先としても使ってみたが、Chromeリモートデスクトップの導入後は重いどころの騒ぎではなく使い物にならなかった。LinuxのUSBメモリでの運用では、ランダム書き込みの速度がOSの動作速度に明らかに影響するように見えるが、同レベルの別要素も有るようでイマイチすっきりしない。まぁ、書き込むばかり、読み込むばかりなんて状況は実用上はまず発生しないからねぇ・・・

Dell XPS 8700の受難

　余りに馬鹿々々しい経験をしたのでメモっとく。他人にとっては面白くも無いし、まず役にもたたないだろう。

　昨年9月にほぼ６年ぶりに新規PCを購入し、従来のメインPCだったDell XPS 8700はセカンダリPC扱いとなった。手間はかかるが金はかからない正規の手続きに従いとっとと処分する予定だったが、緊急かつかなり非生産的な理由により24時間稼働のサーバーとなった。ある時はデータサーバー、またある時はネット帯域監視サーバーと用途を変えつつ、今後も暫くは稼働予定である。

　私のDell XPS 8700は2014年のWindows7プレインストールモデルで、CPUはIntel i7-4790（4コア8スレッド）、メモリは32GB、グラボは最終的にnVIDIA GTX1070になった。ゲーム、3DCGI、DAWと全て睨んだ上での構成だ。ただ起動途中のシャットダウンなど故障が予測される兆候も示し始めたことから、第一線を退いてもらうことになった。

　さて、 エントリタイトルにもある受難のスタートラインであり、以降でキーとなる初期状態を列挙する。

• レガシーBIOSブートである。これはプレインストールのWindows7から上書きでWindows10に無償アップグレードしたためだ。
• OSはWindows10 Proで、Windows10自体の機能を使って初期化した。

次いで内部のドライブ構成について示す。

• ドライブ０：SATA 2TB HDD、以降は単にHDD、ドライブレターは\D
  
• ドライブ1：mSATA 256MB SSD、以降は単にSSD、ドライブレターは\C

初期状態のブートドライブはもちろんSSDだ。

　さぁ、淡々と行こう。

１．BIOSのアップデート　→　セキュリティ関連ファームウェアの破損

　BIOSをA13から最新のA14にアップデートした。アップデート用ファイルはもちろんDellから入手したものである。BIOS自体はアップデートされたが、セキュリティデバイスである「Intel Management Engine Interface」のファームウェアのアップデート中にエラーが発生、オプションで強制書き込みを指定してもアップデートが弾かれるようになった。もう少し状況を丁寧に書いておくと、アップデートプログラムがファームウェアのバージョンを取得できないままエラーを吐いて落ちる。結果、OS起動後のデバイスマネージャー上で「Intel Management Engine Interface」と「SMバスコントローラ」に「！」マークが付く状態となった。

２．SSDからのUEFIブートにブート方法を変更　→　SSDのディスク形式を誤変換

　ブート方法を変更するには、まず起動ドライブのパーティション形式をMBRからGPTへと変更しなければならないが、Windows10には"mbr2gpt.exe"というそのためのコマンドが用意されている。"mbr2gpt.exe"の良いところは、ディスクの内容は一切失わないことにある。早速このコマンドを試したところ、エラーで変更できない。原因は所謂OEMパーティションというやつだ。OSプレインストール版メーカーPCの多くで、起動ドライブのパーティション構成はメーカー独自となっている。Microsoftにとっては預かり知らない状況となっている訳で、"mbr2gpt.exe"にパーティション構成を教えてやらなければならない。ネットを漁ると教えるべき内容を見つけることはできるが、まぁ、当然ながら色々とリスクだらけだ。

　で、Dellのユーザーコミュニティスレッドで見つけたとある情報を使って"mbr2gpt.exe"を実行したところ見事変換完了、BIOS/UEFIでブート方法をUEFI、Windows Boot Managerに変更したところ見事OSが起動した。動作は快調だったのだが、ディスク管理画面を見るとSSD（\C）の中身が見えない。実は "mbr2gpt.exe"実行時に使った情報には１ヶ所誤りがあり、本来ディスク形式を「ベーシック」のままにしておくところを「ダイナミック」に変換してしまっていたのだ。

　SSDの中身を失なわずに「ベーシック」に戻す方法は基本的に無い。有料中華アプリで対応できるものもあるとのことだったが、本質的な原因はWindows7プレインストールPC用のOEMパーティション構成だ。ここはもう意味の無くなったOEMパーティションの呪縛から逃れるべく、Microsoftの回復ツールを使ってWindows10をSSDへクリーンインストールすることにした。既に紐付け済みのマイクロソフトアカウントとXPS 8700のハードウェア情報に基づいてWindowsライセンスを認証してもらう必要から、インストール時はインターネットと有線接続しておいた。

３．Windows10をHDDにインストール後、SSDに再インストール
　　→　OSはSSD、EFIシステムパーティションはHDD

　Microsoftの回復ツールを書き込んだUSBメモリからブートしても、SSDの再フォーマットなどは回復ツール上からはできない。これがダイナミックディスクの罠だ。一方、HDDはNTFSでベーシックドライブ、しかも空っぽだ。

　と言う訳でSSDを取り外し、Microsoftの回復ツールでまずHDDにWindows10をインストールした。HDDからブートすれば再取り付けしたSSDのディスク形式などもディスク管理機能で変更でき、晴れてSSDへのWindows10のクリーインストールの準備が整った。SSDへのインストールの為だけに、一度HDDにインストールした訳だ。当然ながら、EFIシステムパーテションはこの時点ではHDD上にある。

　USBメモリ上の回復ツールを使ったSSDへのWindows10のインストールは何のトラブルも無く完了し、これで万事OKかと思いきや、EFIシステムパーティションがHDDに残っている、っつーか、HDDにあったEFIシステムパーティションがアクティブのまま使われていて、SSDにはEFIシステムパーティションすら無い。これはHDDを使ってSSDをブートすると言う余り上手くない状況と言える。場合によってはHDDは外してしまおうかとも思っていた矢先、本当に上手くない。

４．Windows10をSSDに再々インストール、HDDをまっさらに

　HDDの信号及び電源ケーブルを抜いてMicrosoftの回復ツールを書き込んだUSBメモリでブート、SSDへWindows10を再々インストールした。アクティブなEFIシステムパーティションがSSDに移動したのを確認し、アクティブではないEFIシステムパーティションを含むHDDの全領域を削除、フォーマットした。本来は２．の途中で終わっていた筈の作業がここまでかかってしまった。

　ところが24時間稼働状態にしたところ、特定の通信内容に対してネットワーク機器が停止することが分かった。時に不意の再起動も起こす。調べると、PC起動から10分程度経つと「Intel Management Engine Interface」に「！」マークが付き、不具合が起きた時にはその状態にあることが分かった。

　実は「Intel Management Engine Interface」に「！」マークが付くことは以前から少なからずあり、これまではBIOSアップデートなどで解決してきた。が、「Intel Management Engine Interface」に「！」マークが付いているからと言って、ネットワーク接続やPC自体が不安定化した記憶は無かった。その当時との違いについて改めて考えてみると、ブート方法とWindows10のバージョンの違いしか思いつかなかった。

５．Windows10をSSDに再々々インストール、レガシーBIOSブートに戻す
　　　→　「違う、そうじゃない」ことに思い至る

　レガシーBIOSブートとすべく、SSDにwindows10を再々々インストールした。インストール作業が必要な理由は、SSDのパーティション形式をEFIブート用のGPTからレガシーBIOSブート用のMBRにする際に、ディスクの内容が全て消えるからだ。

　さて、レガシーBIOSブートとすることで、「Intel Management Engine Interface」に「！」マークが付いていても、OS自体の勝手な再起動やシャットダウンは発生しなくなった。 一方、ネットワーク機器の停止は１日に２回程度発生し続けた。

　いよいよ頭を抱えざるを得なくなったところで天啓（になるかも知れない）が訪れた。2000年代前半まで、つまりPCを自作していた時代の自分なら真っ先にやっただろうことを思いついたのだ。

　CMOSのクリアだ、困ったらコレ。That's the PC-AT!!

　手順と結果は別エントリに記載してあるが、"Intel Management Engine Interface"のファームウェア更新も成功し、デバイスマネージャーから全ての「！」が消えた。

６．EFIブート再び

　72時間連続稼働に耐えたし、「！」マークも現れないので、改めてレガシーBIOSブートからEFIブートに変更することにした。今回のSSDのパーティション構成はMicrosoftによるものだから（＝OEMパーティションではないから）、"mbr2gpt.exe"はそのまま使える筈だ。結論から言えば全く問題無し、"mbr2gpt.exe"実行後に２回再起動（BIOS/UEFI設定変更含む）して以降は快調そのものだ。現在24時間稼働の２日目に突入、ログを見ると以前はネットワーク機器停止に至ることが多かったイベントにもきっちり耐えている。テスト兼実運用は暫く続くことになる。

　あと、「！」マークを消す件は色々と重要だ。「Intel Management Engine Interface」に「！」マークが付いている状態では、EFIブートに異様に時間がかかった。Dellロゴが表示されている時間が３～５分、Windowsロゴが表示されている時間が約20秒といった具合だった。今やDellロゴが10～20秒、Windowsロゴは表示されることもなくサインイン画面に至る。

７．実は書いていないこともある

　やれ24時間稼働だ、やれサーバーだ、なんて話なら、Windows10に拘る必然性は全く無い。実際、並行してLinuxの某ディストリビューションの導入も試していたのだが、USBメモリでの運用に拘ったために沼ってしまっている。昨夜辺りで「快適に使いたければここまでにしときなさい」というラインが具体的に見えたので、それが再確認できて気が向いたら別エントリに顛末を書くことになると思う。それはそうと、他製品と比べてシーケンシャルリード・ライト、シーケンシャルライトは悪くないのに、ランダムライトだけ1/200以下っていう製品（個体ではない）があるのは、USBメモリ界隈では普通なんですかねぇ？

ファイターモードからガウォークモードへの変形時もヒンジは開く

　アニメ「超時空要塞マクロス」に登場するVF-1A バルキリーは私の大好きメカであり、海外にもファンは多い。デザイナーの河森正治氏は、英TVシリーズの「サンダーバーズ ARE GO」でS号のデザインを依頼されている。

　しかしながら、後のVFシリーズとは異なり、その変形自体にはマジックが多い。チートではなくてここでは"ANIME magic"と敢えて呼ぶが、表現が適切かどうかはともかく、河森氏が「マジックに頼りつつも何かでっかい扉を開けてしまった」のは間違いないと個人的には見る。とは言え、続くVFシリーズの大部分のように「マジックに頼らないガチな変形」に通じるデザインの方向性は、VF-1においてもあちこちに見ることができる。10年以上前に作った3Dモデルとそれを用いたアニメーションシーンファイルの内容を再確認しつつ、モデル製作当時のことも思い出しながら、あらためて思う。本エントリで触れている話は、基本的に1980年ごろと2020年ごろのことである点に留意願いたい。

　エントリタイトルの通り、ファイターモードからガウォークモードへの変形時もヒンジが開く様が、TV用の作画設定資料の1枚に明確に描かれている。ここで言うヒンジとは時に「トラベルヒンジ」と呼ばれる蝶番構造を指しており、バトロイドへの変形時に脚部付け根（空気吸入口付近）位置を無理やり機首側面まで移動させる、少なくとも強度的にオーバーテクノロジー無しでは成り立たない代物である。

　単純に考えると、ファイターモードからガウォークモードへの変形過程でヒンジが開く必然性は無い。が、ここでヒンジが開くところに「ガチ」を見出して、あまつさえ他人に伝えたくてしょうがないあたりがまぁ私の所謂オタクなところなんだろう。実際のところ、強度ほぼゼロにしか見えないが機械構造としてのヒンジはちゃんと3Dモデル化してしまってあったり、ヒンジを設けるために周囲構造物の厚みをオリジナルデザインより厚くしてしまったりという辺りは、我ながら「異常な愛情」を感じてしまう。そうまでしてヒンジを3Dモデル組み込んでしまうのは、おそらく私がVF-1におけるヒンジの重要性を世界で最も信じている（？）故であろう。（「三次元化するにも3DCGIが限界であるからこそ3DCGIで再現する価値がある」と言う考え方だ。この裏返しのように、他のVFシリーズへの興味は文字通り皆無だ。）

　んで要は、VF-1Aの3Dモデル製作過程で、件の変形過程でヒンジが開く必然性に私は（も？）直面してしまった訳だ。2011年ごろ、今から10年も前の話である。

 　ささっとまとめよう、百聞は一見に如かず。ヒンジを開いて脚を前に振り上げる方向に動かしてやらないと、腕部を機体下面から機体外側面に回転移動させる際にガンポッドの先端が脚にぶつかってしまう。なお、私のモデルの場合、ヒンジが開かなくても回転移動時に肩部と脚はギリギリぶつからない、ぶつからない移動タイミングがある。つまり、ガンポッドが無ければヒンジの出番は無い。

　ヒンジ機構自体は良くも悪くもマジックなのだが、そのヒンジ機構が「地味」に「ガチ」に良い仕事をしている辺りがなんとも趣深い。更にそれが作画設定資料に普通に描かれているのは結構衝撃的な事でないかい？

Intel Management Engine Interfaceに「！」マーク

　Dell XPS 8700で下記の問題症状が出ている場合は、ジャンパスイッチをいじってCMOS設定をリセットしよう。ジャンパスイッチの位置やリセット方法などは、Dellのサポートページにあるオーナーズ・マニュアルのpdfででも確認して頂戴。そのものズバリの名称の章がある。「dell 8700 サポート マニュアル」辺りでググれば見つかる。私はこれで「頻繁なオンボードLANの機能停止」と「たまに問答無用に発生するOSの再起動」を克服シマシタ。

　そもそものトラブルの原因はCMOS内の「ログ」の破損と思われる。Dellユーザーコミュニティへのとある投稿（英語）では、同じ症状の解決にはBIOSだけでなくOSのバージョンも出荷時に戻す必要があることを示唆しているが、これは間違いと思われる。BIOSのバージョンを出荷時に戻す操作はCMOS設定のリセットに他ならないから必要だが、OSを出荷時に戻す必要性は技術的視点から全く見いだせない。

 で、問題の症状。OSはWindows10だ。

• BIOSアップデータ実行時に、BIOS自体は更新されるが、バージョンが取得できないことが原因で「ME」とやらの更新に失敗する。ちなみに「ME」はManagement Engineの頭文字だ。
• デバイスマネージャーのIntel Management Engine Interfaceに「！」マークが付いている。ドライバーは当たっているが、デバイス起動に失敗している。
• UEFIブートの場合、起動中にDellのロゴが表示される時間が１分以上と明らかに長い。
  

CMOS設定をリセットしたら、あとはOSを再起動してBIOSアップデータを実行するだけ*だ。

*：アップデータのBIOSのバージョンが現状と同じか古い場合は、コマンドプロンプトかパワーシェル上で"/ForceIt"オプション（大文字小文字は区別しないので、"/forceit"でも"/fORcEiT"でも結果は同じ）を付けてアップデータを実行すれば良い。例えばバージョンA14のBIOSにバージョンA14を強制的に上書きする場合は

<フォルダ>\XPS_8700_BIOS_A14.EXE /forceit　[ENTERキー]

とする。アップデータである"XPS_8700_BIOS_A14.EXE"がHドライブのルート（\）に有る場合は

H:\XPS_8700_BIOS_A14.EXE /forceit　[ENTERキー]

となる。ちなみに、BIOSのバージョンをA03やA06からA14へ直接アップデートできることは確認している。逆にA14からA06やA03への書き換えも、意味は無いが可能である。

　なおCMOS設定のリセットでBIOS周りの設定やログが初期化されるので、BIOS/UEFIの設定が一度必要だ。警告っぽいビープ音１回を伴うPCの再起動が２～３回発生すると思うが、そこは驚かず気にせず淡々と画面の指示に従うだけだ。ビープ音１回ならばむしろリセット成功を知らせていると見做して良い。また、特に理由が無い限り、BIOS/UEFIでは何も考えずにデフォルト設定をロードしてしまうことをお勧めする。まずはBIOS/UEFI起動に成功してナンボだから、その可能性が最も高い状況から始めるべきだ。設定をいじるのは、起動することを確認してからでも遅くない。

　似た症状で、

•  デバイスマネージャーのSMバスコントローラに「！」マークが付いている。そもそもドライバーが当たっていない。 

というのもあるが、こちらは上記の件とは無関係に、「Dellが提供するIntel関連のドライバーの最新版を一切合切インストールする」ことで解決できている。私の場合はWindows10をクリーンインストールした際に現れた症状だ。Chipset関連は当然ながら、せっかくだからBluetoothやWirelessLAN関連のドライバーも更新しておこう。OS起動が遅い原因が特定のBluetoothドライバーせいだった、なんて疑いが拭えないケースの情報もかつてネット上で読んだことがある。因みにデバイスの動作に問題が無い場合、デバイスマネージャー上に「SMバスコントローラ」なんてデバイスは最初っから現れない。「SMバスコントローラ」とは機器名称が特定できないために使われた仮名みたいなもののようで、そのようにデバイスの認識に失敗している状態では適切なドライバーが当たる筈も無い。なお正常状態における「SMバスコントローラ」の名称とか、或いはそのデバイス自体がデバイスマネージャーに表示されるのかどうか等は確認していない。

　この「！」を放置すると「OSの再起動が頻発する症状」に見舞われる可能性があるので軽く見ない方が良い。

　ここでドライバーが「Dellが提供する最新版」である点を強調しておきたい。Intelは第４世代コアベースのシステムのサポートを既に打ち切っているため、Windowsアップデート経由も含めてIntelからXPS 8700への適用が保証されたドライバーやツールを入手することはもはや期待できない。結局「今は存在しない、Intelサイト上のファイルへのリンク」に行き着くばかりなので、本件に関しては2020年以前の口コミやブログ記事をググっても時間の無駄に終わる可能性が高い。故にインストーラーに「古いドライバーで置き換えますか？」と聞かれてもここはまずはYes一択だ。最新版ドライバーで動作していない時点で、最善の策は古いドライバーを試してみることだ。現時点でIntel提供の最新版ドライバーやツールがサポートしているのは、第７世代以降のコアとそれらをベースとしたシステムだけと考えてほぼ間違いない。

ウチんとこの自治体は・・・

　もう２か月くらい前のことだが、訪れていた病院の待合室の外れ、ちょうどスタッフ以外立ち入り禁止区域との境辺りに人だかりができていた。外来診療時間も終わる時間帯のタイミングということで、どうやら医療関係者枠の新型コロナワクチン接種者の集団だったようだ。ただ、その集団の端でダラダラしている、全然病院勤務者っぽくない若い男性３人が気になった。視線の動きから分かる、目的がないままそこにいる人間特有の挙動にしか見えなかったことが原因だ。

　その光景に何か記憶にひっかかるものがあったが、その場ではそれ以上は特に思い出そうとはしなかった。あっ！と思ったのは病院から自宅に帰った直後で、かの大震災の際に給水車を前にどうしていいか分からず半ば立ち尽くす役所の人間の姿に似ていた・・・。かくいうような何の根拠も無い単なる私の個人的な連想・・・からウチの自治体は上手くワクチン接種を進められていないのではないかと・・・繰り返すが本当に何の根拠も無く・・・思っていたのが今週頭までの話だった。

　お！と思ったのは今週半ば、所謂接種券が配達され、接種予約方法と予約開始日時が公開されたからだった。思っていたよりも早かったし、そもそも上述のように自治体の動き具合に疑心暗鬼となっていたのも大きかった。何気にやるな、ウチの自治体。

　ところが今週末にして、はや大逆転となった。病院から帰宅すると、「接種時期と接種予約開始時期が未定となった」旨の通知がポストに入っていたのだ。

　まぁ、それ自体は良いよ、仕方ないよ、因果応報よ。でも、通知の”文面”と言うか、本文中の文字装飾の使い方がとっても不愉快、下品にして下劣でねぇ。「太字＋下線」で最大級に強調されていた文は「国からのワクチン供給不足に伴い・・・」というところだけで、直前にスマホで「国は、某システムへの登録内容に基づき、６週間分の備蓄を持つ自治体へのワクチン供給量を制限する」との報道を見た身としては本当に呆れ果ててしまうしかなかった。この通知で一番大事な、通知を受け取る人間に伝えたい内容はそこなのかい？「国の所為で遅れます」とでも主張したいのかな？そんな主張が今時通じるとでも？そりゃ変更後の内容も「太字＋下線」になっているけど、それは本文とは別の表の中だし、その文章も推敲されたとは思えない割と酷い文章だ。力を入れるべき場所が間違っている。

　国内の幾つかの自治体の公式ページを興味本位で調べたとところ、７～８月の接種数が下がることを原因としてウチの自治体と同様の動きをしているところは少なくない。が、これはたまたまなのかもしれないが、「これは国の所為」みたいな表現には（既に報道のある某市は除く）出会わなかった。そりゃそうだ、国からの供給量が自治体の従来予測より減少するのは事実だが、そうなった原因が大なり小なりい自分の側にあることを、マトモな自治体なら既に理解している。わざわざブーメランになるような文書等を公開したりなんかしない。また、地元新聞ウェブページの本件にからむ最初の報道内容を信じれば、県内でワクチン供給量が半分にまで減らされた自治体はホント数ヶ所だけやで。

　と言う感じで、ウチの自治体は７、８月はワクチン接種のハンドリングで負け組決定済です。負け組と言うか落第組ですね、勝ちはそもそも無い。

母より電話あり

　少なくとも私が物心つくころには、両親は朝〇新聞を取っていた。それは値上げした筈の今も変わらない。実家に帰省した際に彼らに「新聞を辞めないか」と言ってみたこともあったが、「朝日の必然性はないが新聞は欲しい」と言う母親に「代わりの新聞」を提示できなかったのであきらめた。

　そんな母親が、最近の電話で一言。

「〇階と山〇ら公〇党なんとかしたいんだけど、何か方法無い？」

まぁ、そんな朝〇新聞読者も居るので、ね。彼らは絶対投票に行くよ。

　なお、父親はグーグルアース大好きといった具合にインターネットに繋がったつPCが手放せない一方、定年後も長いのに飲み友達とかが未だ多い。

「秩序」を与える存在である限り、中国共産党の存在は人民により是とされる

 　今回は紛れも無く爺の戯言。

　とある人が自著で「『民族自決の原則』なんて唱えた人がいたもんだから地獄の窯の蓋が開いた」旨の 文章を書いた。それを始めて読んだ私は、成程、と膝を打った。本日100周年を祝っている中国共産党（中共）の中華人民共和国支配がどうしてこんななに続くのか、米国はアフガニスタンをいずれ失うだろうという直観的な未来像、それらの一因を見た気がしたからだ。

　どこで読んだか聞いたか忘れたが、「中華の人々（≠中華人民共和国人民）は基本的に秩序を与えてくれる存在を求める」という言葉を記憶している。ここで秩序とは、極端な話で言えば「食えること」、つまり食料品市場に常に（塩を含む）品物が並び、屋台が商売をしていて朝食を食べたり買ったりできる状況を指す。背景には中華の長い歴史、風土とその土地の大きさが挙げられるが、直近では国共内戦の記憶もあるという。国共内戦の時代は流通は麻痺し、食うのにも困った人々が溢れた。故に、「食える状態」を与えてくれる権威的存在は無くてはならないものとなる。それが中共である必然性は全く無いが、逆に中共ではダメな理由も無い。

　国共内戦後、中共は支配地域に秩序を与えた。支配地域内の人々の多くはその秩序を受け入れた、或いは受け入れることを自ら決めた。共産主義を嫌ったり、国民党を支持したりと様々な理由で中共の「秩序」を受け入れなかった人々の一部は香港や台湾へ逃げた。今は無き香港九龍城が生まれた一因である。

　このような視点に立つと、亡命した元中共エリートが「共産党は張り子の虎であって、時を待たずして自壊する」と語ろうと、その発言は説得力を著しく欠く。ほぼ間違いなく、発言者は「秩序を求めた経験」を持たないか、家族や地域に記憶されている「秩序の渇望」を忘れている（場合によっては、何らかの意図をもってそこに触れない可能性もある。反中共メディアもプロパガンダ機関の一面を持つことを忘れてはいけない）。現在の秩序を受け入れている人々にとっては、一時的であっても現在の秩序が失われるようなことがあるならば、中共の自壊なんぞ望まないだろう。

　故に、自壊をも含む中共の崩壊や消滅は、「秩序」を与えてくれる別の存在が明確な状況でなければ、現在の中華の人々には受け入れられないし、求められもしない。歴史的に見れば別の存在たり得るのは侵略民族による王朝や宗教団体なのだが、前者は国民党への浸透、後者は徹底的な弾圧でそれらの台頭の芽を中共は徹底的に潰してきている。中共の抜け目の無さが際立つ点だ。

　他方、実のところ堅牢な官僚機構を既に確立した国家は、政変に対する「秩序の維持能力」が高い。ソ連然り、第二次大戦後のドイツ、日本然り、フセイン・イラクの官僚機構を引継いだダーイシュ然り、そして現在の中華人民共和国も然りだ。法輪功弾圧を苛烈にした大きな原因として、個人的には高級中共官僚への急激な普及があったと見るが、そう見る理由は説明不要だろう。ただぺーさんが指導者となってから、次期及び次々期指導層級の高級官僚から優秀な者が腐敗撲滅を名目に多数排除された。これは大きな禍根を残す可能性を秘めている。すなわち、中華人民共和国が人民解放軍もろとも中共から官僚機構のみ奪うようなことがあっても、その官僚機構を動かせる能力を持つ人間は収容所を門を開ければ直ぐに大量に手に入る状況にある。

　米国の政治学者の中国観のズレにはやはり宗教が影響している。学者とは言え、自身の信教の世界観からは逃れ得ない。特に米国はプロテスタントどころか、より原理主義的なキリスト教徒も少なくない。これらキリスト教が個人に求めたり、個人が備えているとしているものを、キリスト教徒ですらない中華の人々が有していると期待してはいけない、同じ考え方はしないのだ。むしろ「自由より飯」という価値観の存在を忘れてはいけない。また、「秩序」は常に「今」求められていることも忘れてはならない。大躍進運動による実質的な中共による中華人民共和国人民虐殺は、例え皆が改めて知ることになろうとも「過去の話」でしかない。

　かくて私自身は「中共自壊論」には懐疑的であり、それが起きても誰も得をしないようにしか思えない。いや正確には、気軽に「中共滅ぶべし」と言えないということになろうか。

　アフガニスタンにも類似の構造を見る。米国介入前のタリバンの勢力拡大の原因をどこに置くかだが、私の考えはやはり「勢力圏内に秩序をもたらした」からだ。 タリバンの勢力圏内ではかなり厳格にイスラム法が適用、運用された。その結果、域内住民の生活には主に禁欲的な方向でかなりの制約が加わったが、同時に犯罪行為は徹底的に摘発、犯罪者にはイスラム法に従った厳罰が加えられた。賄賂は機能しなくなった。結果、域内住民は不合理な金品の支払い要求を含む犯罪行為や性的なものを含む暴力行為におびえる必要がなくなった。これも一種の秩序が与えられた状態ではなかろうか。

　現在のアフガニスタンの政体は、部族間対立、宗教宗派間対立を背景に、金や利権も絡んだ勢力争いの常に変化するスナップショットのようなものにしか見えない。国内の「秩序」の担い手として機能していないし、その意思も無い。首都近郊の治安（≒秩序）は米軍が、地方の治安は再び台頭してきたタリバンが担っているのが一見したところの現実だ。故に米軍の撤退後は、タリバンに再び国内全域が支配されるだろうと信じて疑わない。少なくともベターな選択として、住人達がそれを望むだろうからだ。

　で、ハマスとファタハの人気の差の原因は？ 同じ考えが適用できるように思う。ハマスは兵力はもちろん、官僚機構に基づくコンパクトな地域統治能力を有している。影響下の地域での経済活動や医療活動などを可能とするのだ。だからと言って現時点ではハマス礼賛などできはしない。軍事抵抗組織を起源とするファタハの主な収入は、その初期においては国や王族を含む反イスラエル勢力からの援助資金であることが顕著だった。一方、ファタハの軍事資金の多くは影響地域での経済活動に負う。ファタハは影響化の地域住民に等しく「秩序」を与えるが、それが戦闘で消える費用や命の供給手段でもあることは明確だ。

Windows11互換性 × Dell XPS 8700 = やっかい

　Windows11が公式発表され、互換性チェックプログラムなるものも公開された。互換性チェックプログラムによれば、現行のメインPCは「互換性に問題無し」、先代のメインPCは「互換性に問題あり」となった。この先代のメインPCがDell XPS 8700である。

　で、互換性チェックプログラムをマイクロソフトのサイトからダウンロードしたのは昨夜なのだが、今日の午前中にはダウンロード用のリンクは消滅、「準備中」となっていた。「DellやHPなどの多くのメーカーPCで、互換性が担保できなかったせいではないか」と邪推しているのだが、如何だろうか？実際、私のDell XPS 8700の状況はやっかいだ。

　 Dell XPS 8700は2014年モデルで、CPUとして第４世代Intelコア、ハズウェル・リフレッシュ世代のコアを搭載している。私のPCではIntel i7-4790（4コア8スレッド）だ。現時点でこのCPUは対応プロセッサリストに含まれていないが、いやいやまだ切れんでしょうよと思うのだ。だから現時点では未対応でも気にしないことにしている。それに実際のところ、大ボスは別のところにいた。

　さて、Windows11は「UEFIによるセキュアブート」を要件としている。別の書き方をすると「トラステッド プラットフォーム モジュール (TPM) バージョン 2.0の実装」を必須としている。Dellは幅広いラインナップでTPMを採用しておらず、Intel PTTという安価な代替ソリューションをBIOSレベルで提供している。ここでまず引っかかる。

　ちなみにIntel PTTを採用している大手メーカーのPCは決して少なくなく、マイクロソフトが要件を緩めるか、或いは各メーカー独自でこの辺りの顧客対応をちゃんとしないと、次からそのメーカー製品を選んでもらえなくなる可能性も出てくるのではないかと思う。企業や官庁に自社製品を一括大量導入しているメーカーの中には、リアルタイムで頭抱えてるところもあるんじゃないかな？DELLのサポートは技術仕様書類を公開するだけでトラブルシューティングはもうユーザーコミュニティへ丸投げだから、一部の顧客は捨てることになるんだろう。が、「うちのやり方はDELLとは違います」なんてサポートについてDELLとの違いをアピールしてきたメーカーで「新しいのにWindows11互換性が無い製品が多数」なんてことになったら、技術も含め顧客に直接接する現場は目も当てられない。

　技術畑の人なら理想論としては分かってもらえると思うのだが、この種の要件の導入には１商品サイクルぐらいの移行期間がやっぱり必要だ。Windows10のサポート終了時期こそ、その種のサイクルに基づいて決めたものじゃないのかねぇ？

　閑話休題。

　現時点では「互換性で弾かれる」という意味で駄目なIntel PTTだが、将来的には分からない。上述の通り、この要件はメーカーに対して大きな負荷要因となり得る、つまり少なくとも歓迎はされない。それに特定の機能の有無が問題ならば、BIOSのアップデートは必要かもしれないにしてもPTTでTPMを代替し得る筈だからだ。機能を代替できる（ことになっていた）からこそPTTには意味があったのだ。が、Intel PTTはレガシーBIOSでは使えず、Windowsの起動をUEFIとしないといけない。XPS 8700はWindows7と8.1のプレインストール機が並売された最後の世代の製品であり、かく言う私も「最後のWindows7プレインストール機」故に購入したと言って良い。ここでDellは、Windows7プレインストール機をレガシーBIOS起動でセットアップして出荷した。従って、そのままWindows7からWindows10に無償アップデートしたXPS 8700はレガシーBIOS起動のままなのだ。つまり、Intel PTTすら使えない。

　「じゃあ起動をUEFIに変えれば良いじゃないか」と思うかもしれないが、そうは問屋が卸さない。起動ドライブ（普通はCドライブ）もUEFIに対応していなければならないからだ。具体的には、パーテションがMBRベースではなくGPTベースでなければならない。レガシーBIOSの場合がMBR、UEFIの場合がGPTだ。この点についてはWindows10自体が"mbr2gtp.exe"という変換プログラムを用意しているので、一見対応可能だ。通常は1分程度で変換される。が、Dell製品の多くで、起動ドライブのパーテション分割が独自のもの（OEMパーテションという表現が見られる）となっている。XPS 8700も然りだ。

　"mbr2gtp.exe"は独自のパーテション分割には自動で対応してくれないので、プログラム実行時にユーザーがパーテション情報をオプション（/map=・・・）として具体的に与える必要がある。とは言え、どうやってそのオプションの数値を手に入れるのかも分からんし、入力間違いなどしようものなら変換結果がどうなるかも分かったもんじゃない。OEMパーテションの情報と対応したオプションに関する情報は国内外で蓄積が進んでいるようだが、やっかいな問題であることには変わりなく、余りに建設的ではない作業に能力ある人間の労力が割かれるというのも悲しいばかりだ。

　ちなみに私のDell XPS 8700はこれまたイマイチ建設的ではない用途で24時間稼働中だが、とてもWindows10のサポート終了時まで運用することになるとは思えない。だから本来はWindows11との互換性なんてほっておけば良かったのだが、PCを自作していた10年以上前の気分がちょっと蘇ってしまっていじりだしたのが運の尽きだった。様々な困難や勘違いが生み出した結果に打ちのめされ、結局Windows10のクリーンインストール（ただしUEFI起動に変更）に至るのだが、その過程での知見は上述の通りである。散々調べ、考えて実行した結果、1文字のタイプミスのせいで取り返しのつかない事態を引き起こした・・・なんて醍醐味は久しぶりだなぁ（棒

　思えば最初の作業、BIOSのA13からA14へのアップデートが正常終了しなかった（インストールは終了したのだが、チェックプログラムがクラッシュした）時点で、その後の泥沼、やろうとしていることの筋の悪さを予見すべきだったのかもね。得たものの少なさは正直つれえ。

レンダーファーム、使用料おいくら？

　最近、13～10年前にYouTubeに上げた3DCGI動画のリメイクに手を染めた。ざっくり10年でのCPUパワーの増加は10倍強で、20倍には届かないというのが実感だ。ただ、3DCGIで最も時間のかかるレンダリングは並列計算向きで、アプリ側もマルチコア/スレッドCPUの特性を最大限利用するように発展してきている。加えて、メモリやストレージの性能向上もレンダリング時間短縮に明らかに寄与しているよう見える。結果、CPUによるレンダリング速度は、20倍をやや超える程度までは向上したように思う。

　20倍強というと微妙な感じもする人もいるだろう。だが一般的なサラリーマンの１ヵ月あたりの出勤日が約22日であることを考えると、1日の出勤だけで給料一ヵ月分貰えるような「比率」ではある。３週間かかっていたレンダリングが1日で終わる。丸1日かかっていたレンダリングが１時間ちょっとで終わる。特に前者の場合は、私なら以前は絶対やろうとしない条件だ。とは言え、"Enough  is not enough"なのが人間だ。そんな人こそレンダーファーム・・・なのかな？

　レンダーファームとはレンダリングのためのCPUパワーのレンタルサービスや、そのためのハードウェア・ソフトウェア環境を指す。歴史をすっ飛ばして現状だけ見れば、クラウドコンピューティングサービスの一種と見做せるんじゃないかと思う。要は自分のPCの代わりに、レンタルした並列計算環境にレンダリング計算をしてもらうサービスだ。時間をプロダクションコストに含めなければならないプロフェッショナルの世界では、昔から必須のサービスだ。また、フリーランスの3DCGIアーティストが自己宣伝用デモリールを作る際に、仕上がりをプロフェッショナル級にするために使われることもあるようだ。

　で、いくつかのレンダーファームサービスの価格を調べてみた。結論から言うと、良くも悪くもサービス提供元による価格差はほとんど無かった。もう少しばかり定量的に書くと、円-ユーロ、円-ドルの為替レートの変化でどこのサービスが一番安いかが変動するレベルの差だ。と言う訳で、米国ベースのとあるサービスの簡単見積りページで価格を見積もってみた。条件は、私のメインPCでレンダリング実績のある以下の通りとした。

• 600枚の静止画をレンダリング
• Intel i7-10700で静止画1枚／分、総レンダリング時間は10時間
• 200ノード並列
• 優先度は普通
  

ここでは、CPUを特定し、そのCPUでのレンダリング時間を与えている。サービス提供元のノード又はCPUの計算能力と特定したCPUの計算能力との換算が妥当ならば、かなり正確な見積りになるのではないかと思う。ノード並列数には特に意味は無いが、レンダリング枚数を超える意味が無いことと、レンダリング枚数の約数であることは意識した。優先度というのはざっくり実行順で、お金を積んで「高」とか「最高」にすれば、「普通」の他ユーザーの計算を止めてでも先に計算してもらえるようになる。

　見積り結果は以下の通り。

• 実効計算時間は約80秒
• 価格は約￥1,300-

実効計算時間はノードの性能から妥当な感じ、使うとしても全く文句は無い。データのアップロード、ダウンロードを含めたターン・アラウンド・タイムは15分ぐらいだろうか。生成され、ダウンロードするデータの量は多いが、これらデータの一時保存などのコストは見積りに含まれていなかった。まぁ大抵はそのためのネットワークストレージサービスを別途契約しておいて、レンダリング結果はレンダーファーム側が適宜書き込む形にすべきなのだろうけれども。

　 対して価格だが、これが微妙。趣味かつ作成動画からの収益無し、という条件下ではやはり高値感がある。せめて半分、ただ￥300＋消費税なら使うかもしれない。ちなみにCPUの最大TDP60WでメインPCを10時間全力駆動した場合の電気代の「増分」は約￥16-で、計算する前の予想よりは安かった。結局のところ、レンダリング時間である10時間が「睡眠時間＋アルファ」又は「出勤で部屋のPCに触れられない時間以下」なので、金を払ってでも取り返したい時間になかなかならないのが高値感の原因だろう。

　レンダリング時間が更に100倍になる辺り・・・価格￥13万-以上・・・からがレンダーファーム利用の本領発揮ラインだろう、というのが今回の感覚的な結論かな？200並列ならば「40日後の結果を今日の午後に得られる」となるが、こうだとさすがに価格の見え方も変わってくる。場合によっては「40日後に得られる予定だった結果を見ることで、40日後に得る筈だった新アイディアを今日の午後に得られる」なんてこともあるかもしれない。後者の場合、本来無かった筈の40日も別途購入したようにも考えられなくもなくない？