headless 曰く、

The GNOME Projectは7月28日、GNOME OSの仮想マシンイメージを公開した(アナウンス、 Phoronixの記事)。

最新のGNOMEをテストするGNOME OSの計画は、オンラインのみの開催となったGUADEC 2020で発表された。GNOME OSは特定のLinuxディストリビューションに依存しないテスト環境として生まれたもので、元々仮想マシンとして作られていた。しかし、OSTreeを通じたアップグレードが可能となり、Flatpakアプリケーションがインストールできるようになったことで、完全なオペレーティングシステムに近付いているという。そのため、発表は実機にインストールして実行可能なGNOME OSにフォーカスした内容だったが、テスト用の仮想マシンが近々公開できるとも説明されていた。今回公開されたのはナイトリー版の仮想マシンイメージ。より幅広いテストに耐える状態になっているが、少なくともGNOMEコアモジュールのメンテナーは試してほしいとのことだ。

headless 曰く、

EU航空安全機関(EASA)は7月21日、エアバスA350型機の制御パネルにカバーを装備するよう運航会社に命ずる耐航空性改善命令(AD)を発行した(AD、 The Registerの記事)。

同型機では2つの操縦席の間にある制御パネルの組み込まれた台に液体をこぼした場合、運航中にエンジンが停止して再始動できなくなる可能性がある。エアバスは操縦室内の液体禁止ゾーンを定義する航空機運航マニュアル(AFM)暫定リビジョン(TR)を発行しており、EASAはAFM TRに従ったAFM修正を運航会社に命ずるADを2月に発行していた。

その後、エアバスは制御パネルを完全に液体から保護できる取り外し可能なカバー(mod 116010)を開発し、作業指示書(SB)を発行している。また、液体禁止ゾーンの定義に加えてカバーの使用方法や誤って液体をこぼしたときの対応などを含むAFM TRも同時に発行したという。エアバスはさらに、制御パネル自体を耐水化するmod 116038も開発したとのこと。

今回のADは2月のADを置き換えるもので、mod 116038を適用済みのものを除くすべてのA350-941/1041にカバーを装備し、AFMを更新するよう運航会社に命じている。

はてなに子供二人がプログラムの方針で対立したという話が掲載され話題になってるらしい（はてな匿名ダイアリー、[B! 増田] ）。原因は「じゃんけんゲーム」の実装方針であるらしい。ゲーム内容は、画面でグー・チョキ・パーのいずれかを選びボタンを押すと、相手となるCPU側の手と勝敗が表示されるシンプルなもの。喧嘩の原因となった方針の違いを元記事を引用すると、

そうだ。次男は長男の設定したロジックに納得がいかなかったらしく、「兄ちゃんのはじゃんけんで勝負してない」「勝ち負けを最初に決めてしまうなら意味がない」と批判、対して長男は「結果は同じなんだからこれで問題ない」と突っぱね、収拾が付かなくなったようだ。どちらが正しいかの議論は元ネタ自体のコメント欄にも飛び火している模様。

イランのハッキンググループが、自分で撮影していた動画を流出させてしまったようだ。どこのカップルだという感じだが、この動画は新人テロリストを育成するためのトレーニング用として撮影されたものである模様。流出させたハッキンググループは「ITG18」で、「APT35」や「Charming Kitten」「Phosphorus」とも呼ばれるグループであるようだ（WIRED、ZDNet）。

動画はIBM X-Forceの研究者らがオンライン上のサーバーに置いてあったものを誤って公開しているところを見つけたものだそうだ。内容としては、ハッキングしたGmailやYahoo!メールのアカウント情報への対処方法などが実演されていたという。

WIREDのUS版がIBMに見せてもらった動画では、ハッカーが不正アクセスしたGmailアカウントから、ものの約4分ほどで情報を盗み出したところが映し出されていたそうだ。ちなみにYahoo!アカウントの情報は3分ほどで盗み出した模様。

学会誌である情報処理の2020年8月号に「プログラミング教育の最前線」という特集が掲載されているそうだ。2020年度からの学校でのプログラミング教育の必修化の結果、現場では様々なグダグダが発生している模様（学会誌「情報処理」、TAKASU Masakazu｜note）。

ネタ元から勝手に中身を想像してる見る範囲では、フローチャートの意味を理解していない先生によるフローチャートの授業がフローチャートお絵かき教室と化している、市価で2000円程度のmicro:bitが納品ルートのせいで6000円になってる、初めてのコンピューターとして1500円のIchigoJamをハンダ付けしている、というプログラミング教育とはなんぞやな状況が載っているらしい。

headless 曰く、

Linux 5.9に向け、ドキュメンテーションなどに多数含まれるHTTPリンクをHTTPSリンクへ置き換える作業が進められている(Phoronixの記事、 Neowinの記事、 The linux-next integration testing tree)。

置き換えの理由としては、細工することが難しいHTTPSに置き換え、リンクを開くカーネル開発者が中間者攻撃にあう可能性を減らすことが挙げられている。ただし、実際にカーネル開発者がこのような攻撃を受けている様子はなく、先を見越した変更のようだ。

置き換え作業はAlexander Klimov氏が一人で進めており、既に148件のパッチが存在する。Klimov氏はスクリプトを使用してHTTPリンクを探し、SVGファイルなどではないことを確認したうえで、HTTPSでHTTP版と同じ内容が表示される場合にのみ置き換えを行っているとのこと。osdn.jpへのリンクもHTTPSに置き換えられている。

headless 曰く、

Microsoftは24日、Windows 10 Insider Preview ビルド19042.421 (20H2)をベータチャネルに提供開始した(Windows Experience Blogの記事)。

本ビルドではスタートメニューのタイルが配色テーマに合わせた色に変わり、コントロールパネルの「システム」の代わりに設定アプリの「システム→詳細情報」が表示される。また、Microsoft Edge Canary/Devを使用している場合はALT+TABキーを押すとアプリだけでなくタブも切り替えられるようになり、タスクバーにピン留めしたWebサイトが既に開いていればそのタブに切り替わるなど、多数の新機能が追加されている。

これらの新機能は7月に入ってDevチャネルのビルド20161およびビルド20175で提供されていたものだが、DevチャネルではA/Bテストが行われているため新機能を利用できないままのユーザーもいる。なお、Devチャネルではビルド20161までのビルドが7月31日に期限切れになるとのことで、早めにビルド20170以降へ更新することが推奨される。

GoogleのAndroid開発チームでは、Android 11をRVC(Red Velvet Cake)というコードネームで呼んでいるそうだ(Android Policeの記事、 The Vergeの記事、 The Next Webの記事、 動画)。

Android 11のコードネームはポッドキャスト番組「All About Android」で、GoogleのAndroidエンジニアリング担当VPデイブ・バーク氏がフローレンス・アイオン氏の質問に答える形で明らかにしたものだ。AndroidのメジャーバージョンはAndroid 1.5 CupcakeからAndroid 9 Pieに至るまで、デザートの名前がアルファベット順に付けられており、Android 4.4 KitKat以降は内部のコードネームとは別に正式名称として発表されるようになっていたが、昨年のAndroid 10 (Q)でその伝統は終了している。

アイオン氏はデザート名の伝統が残っているとしたら内部での名前は何になるか、今度は「R」だから「Rocky Road」とか「Red Velvet」(正解)とか、実際に最新ベータを読んでいる名前はあるか、などと質問。バーク氏はAndroid 11が公式な名前だとしたうえで、チームのエンジニアはRVCと呼んでいることを明らかにした。ただし、オープンソースコードに「RVC」と表示したりしないのかとバーク氏がエンジニアリングマネージャーの一人に聞いたところ、単に「R」と呼ぶだけだと言われたとのこと。マーケティングチームからはRed Velvet Cakeと一緒の人形を作ったりすることも認められていないが、バーク氏はひそかにどこかに潜り込ませたいとも述べている。

Android 10は内部で「Quince Tart (QT)」と呼ばれていたが、Qから始まる英単語自体が少なく、事前予想ではエキゾチックな食べ物が多く挙げられていた。Rから始まる名前のデザートはなじみのあるものが多そうだが、スラドの皆さんが好きなデザートはあるだろうか。

Android版のChrome Canaryで、ダウンロードをいつ実行するか設定する機能のテストが行われている(Techdowsの記事、 Neowinの記事、 Ghacksの記事、 9to5Googleの記事)。

この機能を使用するには、chrome://flagsで「Enable download later」(chrome://flags/#download-later)をEnabledに設定すればいい。アプリの再起動後、ファイルをダウンロードしようとすると「ダウンロード日時の選択」ダイアログボックスが表示されるようになる。また、ダウンロードのオプションに「ファイルをいつ保存するか確認する」が追加され、「ダウンロード日時の選択」を使用するかどうかの設定が可能になる。

ダウンロード時に選択可能なオプションとしては、開始日時を指定する「日付と時間を選択」のほか、Wi-Fi接続に切り替わったタイミングでダウンロードを開始する「Wi-Fi接続時」や通常通りダウンロードを実行する「たった今」が選択可能だ。ただし、スケジュールの指定を完了すると保存先に.crdownloadファイルが作成され、ダウンロードするファイルサイズが小さい場合はこの時点でダウンロードが完了してしまうようだ。また、現時点では指定通りにダウンロードが始まらないことも多いようで、何度か試してみた限り「日付と時間を選択」で指定した通りにダウンロードが開始されることはなかった。

なお、このダイアログはモバイルデータ接続時にのみ表示されるが、chrome://flagsの「Show download later dialog on WIFI」(chrome://flags/#download-later-debug-on-wifi)をEnableにすることで、Wi-Fi接続時にも表示されるようになる。

headless 曰く、

GDCが8月のGDC Summerを前に、2,500人近いゲーム開発者を対象に実施した調査報告書「State of the Industry: Work from Home Edition」を公開した(GDCのニュース記事[1]、 [2]、 Windows Centralの記事、 報告書ダウンロードページ)。

回答者の勤務先の規模としては、1～5人(35%)と500人以上(18%)が過半数を占める。COVID-19パンデミックのために在宅勤務へ移行したという回答者は70%で、以前から在宅勤務だった27%を加えると97%が在宅勤務という状況になっている。27%が在宅勤務による生産性への影響はないと回答しており、「どちらかといえば低下」と「大きく低下」を合わせて41%が低下、同様に32%は向上したと回答。創造性は40%が変わりなく、35%が低下、25%が向上したとのこと。

いずれも大きく低下/向上は10%未満にとどまるが、自宅で仕事に集中できるかどうかが分かれ目になったようだ。仕事の時間が普段より長くなったという回答者も39%おり、その理由としては通勤時間分も仕事に割り当てる、仕事を終えるきっかけがつかみにくい、子供の相手で同じ量の仕事に時間がかかる、といったものが挙げられている。

パンデミック中に取り入れた仕事の方法などをパンデミック後も継続していくとの回答は64%を占める一方、勤務先がオフィスでの業務再開を計画しているとの回答も66%を占める。ただし、オフィス再開計画なしという回答の中には、オフィスが閉鎖されていないケースも含まれるそうだ。再開計画があってもいつになるかわからないという回答者もおり、今すぐオフィスに戻っても安全だと考える人は11%にとどまるとのことだ。

headless 曰く、

Microsoftのフィル・スペンサー氏がフランスのゲーム情報動画ニュースサイトJeuxVideo.comのインタビューに対し、より多くの日本製ゲームをXboxへもたらすには日本のゲームクリエイターとの信頼関係再構築が重要との考えを示した(動画、 Windows Centralの記事)。

Xboxユーザーは優れたクリエイターによる素晴らしいゲームを求めており、優れたクリエイターには日本のクリエイターも多い。既にMicrosoftでは日本のクリエイターとの信頼関係再構築を進めており、E3ではXboxのステージに日本製ゲームが登場するなど大きく進歩したという。日本時間24日1時から開催されるXbox Games Showcaseでは、日本のクリエイターと共同で作成した将来のゲームリリースのロードマップを公表するそうだ。Microsoftは今後も引き続き日本のクリエイターの要望に耳を傾け、Xboxが成功できるプラットフォームだと日本の素晴らしいクリエイターに感じさせることが最も重要とのことだ。

Appleは16日、ドキュメントやユーザーインターフェイスなどで使用する用語のガイドライン「Apple Style Guide」を更新した(Appleの告知、 The Registerの記事)。

更新版には「blacklist/whitelist」「master/slave」といった非包括的な用語の使用を禁止する項目が追加されている。blacklist/whitelistについては使用が禁じられ、文脈に応じて適切な代替用語を選ぶよう求めている。代替用語の例としては「deny list/allow list」「unapproved list/approved list」が挙げられている。

master/slaveに関しては、2つのデバイスやプロセスの関係を説明するために使用することが禁じられる。こちらも文脈に応じて適切な代替用語を選ぶよう求めており、代替として「primary/secondary」「primary/replica」「main/secondary」「host/client」といった例が挙げられている。

いずれの場合も、非包括的用語が変更不可能なコード内で使われていて、それに関するドキュメントを作成する場合は例外として認められる。ただし、例外となるのはユーザーがコードの通りに入力する必要がある部分のみで、その説明には代替用語を使用する必要がある。

包括的用語といえるかどうか微妙だが、「Asia Pacific」という用語を使用する場合に「Japan」を分けて列挙することを禁じる項目も追加されている。つまり、Asia PacificにはJapanが含まれているため、「Asia Pacific and Japan」という表記はガイドラインに違反するというわけだ。

blacklist/whitelistからdeny list/allow listへの置き換えはWWDC20で公開したベータ版ソフトウェアや開発者向けドキュメントで導入されており、Xcode 12のデフォルトSCMブランチ名はmasterからmainに置き換えられているという。今後、排他的用語を使用しているAPIに関しても、内部のコードベースで代替を導入した段階で非推奨にしていくとのこと。なお、Appleは以前からAllowList/DenyListという用語を一部で使用していた。

MicrosoftはPHPの次期バージョン「PHP 8.0」をサポートしないそうだ。MicrosoftでPHP関連のプロジェクトマネージャを担当するDale Hirt氏は、公式サイト上でPHP 8.0以降では、PHP for Windowsをサポートする予定はないと明言した。

Microsoftが公式にサポートするPHPは現行でサポートしているPHP 7.2、PHP 7.3。PHP 7.4のみとなる。この中で最も新しいPHP 7.4のMicrosoftサポート期限は2022年11月28日までとなっている（Microsoft Support of PHP on Windows - Externals、窓の杜）。

なおKOYAMA Tetsujiさんのツイートによれば
、

これってバイナリ提供の話ではなくて、Windows版PHPは実はMSの公式サポートによって開発が支えられていたってことだよね。8.0以降で同レベル開発力をコミュニティが維持できるのか問題。 / “Microsoftが「PHP」サポートを縮小 ~「PHP 8.0」バイナリは公式提供せず - 窓の杜”

これにsjiさんが、

はい、その通りです。Windows 版特有のバグとかはわりと MS の中の人が対応して直したりしてました

と返信している。

headless 曰く、

IBMがオープンソースのコンテナオーケストレーションツールKubernetesの管理者経験12年以上という要件で、アーキテクト/エンジニアを募集していたようだ(The Registerの記事)。

うっかりすると見過ごしてしまうところだが、GitHubでKubernetesプロジェクトに最初のコミットが行われたのは2014年6月7日、バージョン1.0のフィーチャーフリーズは2015年5月22日とのことで、現在はまだ要件を満たす人が存在しない。この求人は既にIBMのサイトから削除(Googleキャッシュ)されているが、インドの求人サイトIntelliJobsには複数の求人が残っている。

WebフレームワークFastAPIを開発したSebastián Ramírez氏は、作ってから1年半ほどしか経過していないFastAPIについて、4年以上の経験を要求する求人を見かけたそうだ。スラドの皆さんは、このような未来からの求人を目にしたことがあるだろうか。

headless 曰く、

Googleによれば、Android 10は過去のどのAndroidバージョンよりも導入が速く進んだそうだ(Android Developers Blogの記事)。

iOSデバイスと比べて機種のバリエーションが多いAndroidデバイスでは、OEMが個別にOSアップデートを開発していたため新バージョンの導入に時間がかかり、OSの断片化が問題になっていた。しかし、Android 8.0 OreoではOSフレームワークとベンダー実装部分を分離するProject Trebleが導入され、Android 9 Pieへの移行速度が2.5倍になったという。

さらにPieでは異なるOEMの端末で実行可能な単一のシステムイメージ「Generic System Images(GSI)」の提供を開始し、主要なOEMパートナーと協力してOEM開発者プレビュープログラムを開始したことで、Android 10への移行はさらに1.5倍高速化。その結果、Android 10を実行するデバイスが1億台に到達したのは、Pieよりも28%早いリリースから5か月後だったそうだ。また、Android 10ではOSのアップデートコンポーネントをGoogle Playで提供するProject Mainlineを開始し、2億8,500万台のデバイスを直接更新したとのこと。

GoogleによるとAndroid 11ではOEM7社が計13機種にプレビュービルドを提供しており、Google Playで更新を提供可能なOSコンポーネントは21に増えたという。ただし、タレコミ時点でAndroid 11 Betaの提供が確認できたのはOnePlusとOppo、Vivoが各2機種、Xiaomiが3機種、Realmeが1機種の計10機種。OEM開発者プレビュー開始時の7社(Essential/Nokia/OnePlus/Oppo/Sony/Vivo/Xiaomi)のうちEssentialは既にない。Nokiaはベータプログラムに参加しないと報じられており、Sony Developer Worldで提供される開発者プレビュー版はAndroid 10(Android Q Beta)で止まっている。