今週の興味深かった記事（2019年 第13週）

NVIDIAがShield Android TVの新モデルを計画中か？

NVIDIA is working on a new SHIELD Controller and SHIELD Remote - XDA Developer

　Androidコミュニティーサイト、XDAがNVIDIAがShield Android TV用の二種類のコントローラーを開発中と報じており、そこから「Shield Android TVの新モデルが出るのでは」と飛ばし記事が出回っている。
　そもそも現行のShield Android TV (2017)はNintendo Switchと同じプロセッサーを採用しており、2019年後半にNintendo Switchの次世代モデルが登場するというウワサがあったことから、コントローラーの登場＝新モデルが出るのでは？というウワサに飛躍している。

　実際のところ、2015年以降のNVIDIAはAndroidタブレットやセットトップボックスでの使用を想定したプロセッサーを発表しておらず、Tegra X2 (Parker。2017)やXavier (Xavier。2018)は車載を想定していて設定価格や消費電力が高すぎる。そのため、Nintendo Switch用にプロセッサーを準備する場合はTegra X2かXavierをそのままではなくカットダウンした縮小版が準備されると想像できる。

　NVIDIAはよくプロセッサーや設計を流用する会社である。例えば2015年にTegra X1で採用したCortex-A57を2017年のTegra X2で流用している。ArmのCPUコアIPとしては新しいCortex-A72/A73が選択可能であったが、NVIDIAからすればハイパフォーマンスCPUは自社設計のDenver 2を使っているからCortex-A57だろうがCortex-A72/A73だろうが大きな違いは無かったのだろう。また、そのTegra X1自体も当初はGoogle Pixel C・Shield TV (2015)で採用されていたがShield Android TV (2017)・Nintendo Switchさらに先日発売されたJetson Nanoで流用している。
　そしてNVIDIAがNintendo Switch用にXavierのカットダウンモデルを作成すると想定すれば、それを流用したShield Android TVの新モデルも想像できる（想像の域を出ないが）。設計や製品を流用することは、エンジニアリングコストの削減や量産効果による製造コスト削減に繋がるので理にかなっている。

仮にXavierを1/2規模に縮小すると仮定する（右端）

		Tegra X1 (Nintendo Switch)	Xavier	1/2 Xavier (estimate)
CPU	Core	Arm Cortex-A57	NVIDIA Carmel	NVIDIA Carmel
	Spec	1.02 GHz x 4 cores	2.26 GHz x 8 cores	? GHz x 4 cores
GPU	Core	NVIDIA Maxwell	NVIDIA Volta	NVIDIA Volta
	Spec	307.2-768 MHz x 256 cores	1377 MHz x 512 cores	- ? MHz x 256 cores
	Perf	157 - 393 GFLOPS	1410 GFLOPS	- 512 GFLOPS (@ 1000 MHz)
RAM	Type	LPDDR4 x64	LPDDR4 x256	LPDDR4 x128
	Perf	4 GB 25.6 GB/sec	16 GB 137 GB/s	8 GB 68.5 GB/sec

これらの数字はXavierのスペックを単純に1/2にしたもので想像の域を出ないが、消費電力10-30WのXavierを半分にしても十分にTegra X1からアップグレードできることになるので（実現するかどうかはともかく）現実的に見える。

Windows 10 version 1903の後

8億台稼働を達成したWindows 10の“次”は何が変わる？  - ITMedia

　今週の記事ではなく先週の記事であるが、今週読んだので本稿に含めておこうと思う。
　寡聞にして知らなかったのだが、Windows Insider PreviewのSkip Aheadが19H2ではなく20H1であるのはWindowsのコア部分が19H2では更新されないということが原因なのだそうだ。確かに記事中（というか記事中で参照されているZDNet記事）の説明なら納得はいく。

　とはいえ、これで納得がいくのは19H1の次が20H1ということだけである。現在のWindows 10のLifecycleは複雑怪奇すぎる。

　恐らく、世のWindowsアプリケーション開発者たちは「Windows-as-a-Service」のコンセプトを知った時には狂喜したはずである。なにせWindows 10には1バージョンしか存在しないのだから、いわゆるDLL Hellのような微妙なバージョン不一致によるフラグメンテーションが解消される…はずであった。
　実際はそうでもなく、19H1=1903がリリースされる時点ではWindows 10だけでも1507 (LTSB)、1609 (LTSB、SAC)、1703 (SAC)、1709 (SAC)、1803 (SAC)、1809 (LTSC、SAC)、1903 (SAC)の合計7バージョンがサポートされていることになる（！）。さらにWindows 7・Windows 8.1もあるから系9バージョンである。Windows 10リリースされる以前の2015年7月時点ではWindows Vista Service Pack 2、Windows 7、Windows 8、Windows 8.1の計4バージョンしかサポートされていなかったことを考えれば、フラグメンテーションはむしろ酷くなった気すらする。恐らく状況をより一層と混沌とさせているのはYY09（例：1709・1809）の30ヶ月サポートではないか。基本の18ヶ月サポートと大企業向け（E3・E5サブスクリプション）のLTSB/LTSCは仕方がないとして、一般向けの30ヶ月というのは理解不能である。
　Ubuntuも似たような半期リリース+LTSのモデルを採用しているが、半期リリースはサポート期間18ヶ月固定なので、4月時点でサポート対象となるのは14.04または19.04に加え16.04、18.04、18.10の4バージョンのみである（Ubuntuは18.04まではLTSでも5年間サポートだった、というのも理由だが…仮に昔から10年間だったとしても6バージョンのみである）。

　ところで、記事中では「Vanadium」や「Vibranium」というコードネームがでてきているが、なかなかややこしい。ZDNetでは正確に記載されていると仮定するとVibranium等はWindows Kernelのコードネームと思われるが、検索してみると"Redstoneの次はVanadium/Vibraniumだ"というようなニュース記事が散見される。私の理解ではThresholdやRedstone（あるいはその先の19H1・20H1など）はWindows OS全体のコードネームなので別だと思うのだが判然としない。また、逆算してみるとWindows 10 version 1507のコアは元素記号=15のPhosphorus（燐）ということになり、こちらも何やら中途半端である。