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

Docker互換のPodmanが公開

Docker互換のオープンソースコンテナエンジン「Podman 1.0.0」が公開 - ＠IT

　未使用なのでPodmanについてのコメントはしないが、メリットがよく解らないところ。
　DockerはDocker社が開発しているが一応はオープンソースだし、Docker互換のコンテナエンジンは既にいろいろとある。いわゆるDockerイメージ（※通称）はOpen Container Initiativeにて公開されているので旧CoreOS（Red Hatが買収）のrktやGoogleが主導で開発しているKubernetesに含まれるCRI-Oなどはオープンソースの互換エンジンである。

　記事を読む限りでは、デーモンを必要としないというのがPodmanの特徴とも思われるが、個人的には「デーモンを使わないことによるメリット」はあまり思いつかない。
　そもそもコンテナ技術はchrootの隔離を高めたものなのでデーモンが必ずしも必要とは限らないが、各種の管理機構を実現するためにデーモンが動作することが多い。例えばDockerをデプロイするとdocker0という名称のLinux Bridgeが作られてコンテナはブリッジ経由でネットワークに接続されるが、IPアドレスをDHCPで割り当てたりホスト名で名前解決しているのはDockerデーモンである。これらを、別の技術で代替することは可能で、例えばホストeth0とdocker0とをフォワーディングしDHCP・DNSサービスを提供するソフトルーターをデプロイしてもいいだろうし、ホストeth0をdocker0に接続して外部のDNS・DHCPサーバーを利用する方法も考えられるが、前者は面倒だし後者ではコンテナのスケーラビリティーを活かせない。だからDockerデーモンに任せるのは手軽で理にかなっている。

AlexaやSiriにプライベートな会話を聞かれないようにする技術

Project Alias makes sure Alexa and Google Assistant won't hear a damn thing - TheRegister

　正直に言うと、私にはこの手の技術の需要が理解できない。

　スマートスピーカーは、「Hey Siri」「Alexa」や「Okay Google」といった特定の呼び掛けでコマンドを実行するために常に音声を拾い続けて待機している。しかし、もしユーザーが「待機している」と思っているだけで音声をGoogleやAmazonに送り続けていたとしても不思議ではないし、あるいは「聞き間違い」に近い誤認識によってユーザーが意図しないコマンドを実行してしまい、それらの結果としてプライベートな会話がAppleやAmazonやGoogleに送信されてしまうプライバシー問題は否定できない。

　…というのが、これらの研究のモチベーションなのであろうが…
　しかし、もしApple・Amazon・Googleがプライバシーを侵害していると思うならスマートスピーカーを使わなければいいし、特定の場合以外で動作してほしくないなら普段は電源を切っておけばいい。
　この記事の装置はRaspberry Piを使ってスマートスピーカーにホワイトノイズ（あらゆる周波数の音を含むノイズ）を聞かせることで実現しているようだが、その装置のオン/オフはできるのにスマートスピーカーのオン/オフができない理由がわからない。

　私が思いつくのは、例えばパブリックなスペースにスマートスピーカーが設置されており、その横に商談など秘密/機密情報を取り扱う部屋（会議室/応接室など）があるような場合に、部屋から漏れ出た音声をスマートスピーカーから遮断するような場合だが…その場合でも、その部屋の防音を高めるべきであってスマートスピーカーにホワイトノイズを聞かせるというのはズレている気がする。

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

カエルの合唱を通信の効率化に応用

「すごすぎる」「発想の勝利」　カエルの合唱の“法則性”、通信の効率化に応用　研究者に聞く - ITMedia

　この発想は私も素晴らしく見習いたいと思う。
　無線LANを含めた無線通信というのは厄介だと思う。ケーブルを介してやり取りする場合でも輻輳したり衝突が発生する場合はあるが、そのような場合でも検出は比較的容易だし回避する方法をプロトコルに織り込むことすら可能である。何より、異なるネットワークは物理的あるいは論理的に切り離される（あるいは、それが可能）なので衝突を起こしにくい。ところが、無線通信ではそうはいかない。

　それでも、PCやスマートフォンの無線LANの場合は比較的大きなアンテナ・アンプと大容量バッテリーを備えており、たとえ通信が途切れても再接続・再送すれば済む。
　それがIoTではうまくいかない。まず、数百・数千というデバイスが無線でネットワークに接続され通信が干渉しあうことが想像できる。さらに、小型・省電力のIoTでは通信障害が発生しやすく再接続や再送はしたくない。ならばIoT機器では最初から通信障害の発生し難いプロトコルが使用されるべきだというのが想像できる。

MongoDBがライセンスを変更

MongoDBとLLVM、ライセンス変更の動き - マイナビニュース

　新ライセンスは名前が実に厄介だと思う。新しいライセンス名は「Server Side Public License (SSPL)」という。
　例えばApache FoundationのソフトウェアはApache Public Licenseとソフトウェアの名前とライセンス名が一致しているので判りやすいが、MongoDBのAGPL改変版は「Server Side Public License (SSPL)」と実に汎用的な名前である。

　邪推するにMongoDB社はオープンソースコミュニティーは賛同こそすれ批判を受けると予想していなかったのではないか――つまり「Server Side Public License」というのはApache Public Licenseのような団体と強く結びついたライセンスではなくAGPLに代わる業界標準にしよう――としていたのではないかと思う。実際はというと、この改定を受けてDebianやFedoraはMongoDBをリポジトリ―から削除したそうであるが。

USB Power Delivery

これで失敗しない、USB PD充電器選び(解説編) - PC Watch

　充電器の話題ではあるのだが、充電器としての使い方に拘るのはテクノロジー系ニュースサイトとしては感心しない。
　USB Power DeliveryはAmpare/Volt/Watt数が問題となるため、まずは単純化して従来のUSBでとUSB給電＝5V/0.5-1Aで考えたい。Ankerなどが製品化している充電器では5ポート程度のUSB機器に同時に給電することができる。スマートフォンやタブレットの充電は当然として、小型Wi-FiルーターやRaspberry Piも5V/1Aで動作するし、空気清浄機や加湿器や電気スタンドへの給電も可能だ。さらに変換ケーブルを使うと様々な機器に給電できる。例えば私の手元にある装置ではAndroid TVボックスや7インチのモバイルディスプレイが5V/1Aだった。
　つまり充電器としてではなく新種の電源タップとして書斎や居間のデスクやベッドサイドに設置しておくと重宝する。
※注：後半はUSBの規格としてはかなりグレーで、変換ケーブルを使う方法はUSB Power Deliveryでは使えないので注意が必要

　より大容量の給電能力を安全に扱えるUSB PDではさらに用途が広がる。最近のラップトップPCではUSB PDで給電しつつDP Alternate Modeでディスプレイ出力・USB3.0をケーブル1本で接続できる。「スマートフォンの充電」という観点で選ぶのもいいが、ラップトップPCへの給電を視野に入れると容量が65-90w程度必要になることから選択肢はガラリと変わる。

　例えば、出張にUSB PD対応のMac Bookを持って行くと仮定する。このとき、Macへの給電用に純正のアダプターを持って行くという選択肢もあるが、どうぜスマートフォンやタブレットの充電もしたいだろうし、人によってはモバイルWi-Fiルーターや加湿器なども持参するかもしれない。そういった機器に同時に給電できれば便利だ。
　例えば1つめの選択肢としては、Apple純正アダプターの代わりにAnkerなどが製品化しているマルチポートのPD対応の充電器を使うことが考えられるが、上のAnker製品の場合は最大30wまでだったりと容量に注意が必要だ。
　そこで2つめの選択肢としては、デスクにPD対応USBハブを設置して、純正のUSB PD対応アダプターとPCとの間に挟みこむことで卓上機器に給電することができる。

先週の興味深かった記事（2019年 第02週）

産総研ABCIスーパーコンピューター

SC18 - 日本のAI普及の加速を後押しする産総研のABCIスパコン - マイナビ

　AI普及促進のため、というコンセプトは高く評価したいが…このSkylake世代Xeonに1CPUあたり複数個のNVIDIA Volta世代Teslaで構成された計算ノードにDDN製ストレージという組み合わせは2018年のスーパーコンピューターとしては一般的なものの気がしてならない。このスーパーコンピューターの見どころは温水冷却だと思うがAIとは関係がない。

Huawei Kunpeng

HUAWEI、64コア・2.6GHzのサーバー向けARMプロセッサ「Kunpeng 920」を発表 - PCwatch

　先進国ではネットワーク機器ベンダーとして知られるHuaweiは中国ではサーバーベンダーとしても知られている。Kunpengは、そんなHuaweiが同社製サーバー向けに開発・採用したプロセッサーであるが、Armv8-Aコアを64個集積されているということしか情報が無くCaviumやAmpareのように独自設計コアなのかすら不透明なところ。

　私が勝手に想像するに、Huawei/HiSiliconが独自設計するとしたら利益の大きい同社製スマートフォン向けプロセッサーKirinに搭載するものが先になると想像できる。一方で同社はKirinのAIアクセラレーターとして中国CambriconのIPを採用したように同じ中国内半導体企業のIP採用に積極的である。そのため、恐らくはArm純正のコアあるいは中国Phytium Technologyが2015年のHotChips 27で発表したMarsコアではないかと想像する。

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

AMD ZEN2世代 Ryzen "Matisse"のSKUのウワサ

AMD Ryzen 9 3800X "Matisse" listed with 16 cores and 125W TDP - VideoCardz

　ロシアのメディア経由でVideoCardzがZEN2世代のRyzen "Matisse"のSKUのウワサについて報じている。

　コア数の構成はそれらしく見えるが、個人的には動作周波数が高過ぎる気がしてならない。
　個人的な推測だが、AMDはZEN2世代で動作周波数をあまり上げてこない。なぜならZEN2世代ではコアの消費電力が増える可能性が高いからである：(1) ZEN/ZEN+世代に比べコア数が増える (2) Load/Storeが256-bit帯域になる。
　加えて、ZEN2登場以前の時点でIntel 第8/9世代 Core（Kaby Lake Refresh/Coffee Lake/Whiskey Lake/Amber Lake/Coffee Lake Refresh）に対する優位を考慮すると、仮に動作周波数を上げられるとしても第10世代に備えて温存する可能性が高い。

Sony a7000のスペックのウワサ

Sony A7000 specs leaked and it's set to be a jaw dropper of a camera - Digital Camera World

　Digital Camera WorldがSony a7000、いわゆるミラーレスカメラのスペックのウワサについて報じている。

　個人的には滅茶苦茶という気がしてならない。

• New Ultra Fast LSI・New BIONZ X
"Ultra Fast LSI"と"BIONZ X"の何が違うのだろうか？デジタルカメラは主に3種類の半導体で構成される。(1) Image Sensor (2) Analog Front-end (3) Digital Front-endだが(1)と(2)は通常は纏めて扱われる。Exmor RS CMOSセンサーが(1)で(2)も内蔵・BIONZ Xは(3)にあたる。
• 10fps/16Bit Mechanical Shutter

いわゆるミラーレスカメラは構造上メカニカルシャッターを持てない。オートフォーカスカメラでは像をセンサーで解析して測距・測光する必要があるが、一眼レフカメラの場合はミラーで反射した先にセンサーを置くためメカニカルシャッターを使用できる。これに対し、ミラーレスカメラはミラーが無いのでCMOSセンサーの裏側にセンサーを配置する必要があり、メカニカルシャッターを置けない

「空母」いずも

従来の延長線上に留まった新防衛大綱 - アゴラ

　日本国政府の国防に関する戦略などわからないが、私の意見を述べておきたい。

　まず、日本の国防は意図的に「言葉遊び」だらけである。そもそも憲法第九条のような無理難題を前提に世界3位の経済大国を防衛する軍隊を維持しているのだから致し方ない。
　諸外国から見れば世界有数の軍隊は「自衛隊」だし、他国では駆逐艦は「護衛艦」・ドック型揚陸艦は「輸送艦」・ヘリコプター空母は「ヘリコプター搭載護衛艦」である。13500トンDDH ひゅうが の場合はこれが顕著で、建造前のイメージ図では航空母艦を連想させないように前後の甲板が艦橋構造物で分断されていた。それが実際の建造時にはひっそりと加筆され艦橋構造物を右舷側に寄せ全通飛行甲板をもつ姿に変更された。そういうフィクションと既成事実化によって成り立っているのが我が国の防衛政策である。「言葉遊び」という指摘は「何をいまさら」と思う。

　さて「空母」だか「多用途運用護衛艦」だかの いずも 改修計画であるが、運用可能な航空機の数がイマイチ判然としない。記事中には「甲板上に8機、艦内の格納庫に2機、合計10機」とあるが、現在のヘリコプターの搭載定数や満載排水量を見ても少なすぎるとように見える。ここで米軍の強襲揚陸艦では比較にならないので排水量が比較的近いイタリア軍カヴールを比較してみたい。

	いずも級	Cavour	Wasp級
全長	248.0 m	244.0 m	257.3 m
全幅	38.0 m	39.0 m	42.7 m
排水量 基準/満載	19,500 / 26,000 トン	27,100 / 30,000 トン	28,233 / 41,335 トン
艦載機	F-35B 10機程度	F-35B 8機 ヘリ 12機	F-35B 20機 MH-60R 6機

貨物船のように全幅が広く基準排水量が大きい（ただし速度が遅い）米海軍ワスプ級はともかく、イタリア海軍カヴールは自衛隊 いずも 級と同等だが、F35B 8機にヘリ 12機を搭載できる。漫画『空母いぶき』ではF35Bを15機搭載可能という設定だそうだが、こうして並べてみれば突飛な数字でないのが分かる。

　記事中では時々の任務に応じてF-35Bを搭載するという政府の主張について「早くも2023年には「空母いずも」を運用するらしいが、一体いつ、どこで発着艦訓練を積むのか。「時々」訓練する程度では搭乗員らの安全をとうてい確保できない」と指摘しておられるが、ワスプ級強襲揚陸艦のWikipedia記事を見ても分かる通り、任務（例：制海任務・空中強襲）に応じて艦載機の構成が変更されるのは、この規模の航空母艦では割と普通である。

　ちなみに、JSF=Joint Strike Fighterについての記事中の主張は揚げ足取りレベルの言い分である。
　昨今はコストの都合で専用設計の多品種の機体を作れないためマルチロール機になる傾向がある。F-35は戦闘機を示すF=Fighterを名乗るが攻撃機A=Attackerや電子戦機Eの任務もこなすことが可能となっている。F-35B/F-35CがA-10やF/A-18Cの置き換えを計画されているのだから、これは当然である。
　この「戦闘機」と「攻撃機」の違いであるが、他国を攻撃するかなどではなく、空戦に特化しているか地上攻撃が可能かどうかによる違いである。実は航空自衛隊は「支援戦闘機」という名称で戦闘/攻撃機を保有してきた経緯を持つが、離島防衛などを念頭に置くとしても地上攻撃能力が無い航空機など役に立たない。

　以上、いろいろとコメントしてきたが、恐らく私のようなド素人が上述のようなコメントをしなくとも、記事の著者のような専門家は全て御存知のはずである。知った上で野暮な指摘をするのは非生産的なことこの上ない。
　聞くところによれば、かつて地中海世界を支配したローマ帝国は、元老院で戦争をするかどうか議論している所を異民族に進入されて全員殺されて滅亡したのだという。議論することは悪い事ではないがイデオロギーと心中するほど馬鹿馬鹿しいことはないと主張しておきたい。