syghの新フラグメント置き場

プログラミングTipsやコード断片の保管場所です。お絵描きもときどき載せます。

無修正画像のリクエストを受けたとき、どう対処・回答すべきか

三次元のお話

自分には縁のない話ですが、一般論として。
恋人に「裸の自撮り写真を送ってくれ」「他の誰にも見せたりしないから」などとお願いされても、はっきりと拒絶すべきですね。そしてそんなことを臆面もなく言ってくるリテラシーの低い野郎とは即刻別れるべきです。将来表を歩けなくなってもかまわないなら話は別ですが。
つい忘れがちですが、インターネットは全世界につながっています。一見プライバシーが保護されているように見えるメールも例外ではありません。いまや画像はもちろん動画でさえ、誰でも簡単にデータをアップロード・共有できますが、同時にクリックひとつで全世界に公開できてしまいます。ネット上に裸の画像をばらまかれて永久に消せない汚点を残すような、いわゆるリベンジポルノにつながるだけでなく、刑法175条のわいせつ物頒布罪(わいせつ電磁的記録記録媒体頒布罪*1)に問われる可能性もあります。

二次元のお話

では、二次元のイラストや漫画に関してはどうでしょうか?
やはり日本国内では三次元同様「無修正はわいせつ物とみなされてアウト」になります。
pixivなどのSNSサイトで、R18カテゴリーのエッチなイラストや漫画をアップロードされている方は注意が必要です(自分を含めて)。
自分で撮った写真や自分で描いた絵などを、自分だけがアクセスできる個人端末のハードディスクや光学メディアに保存すること、つまり無修正の元データの単純所持自体には法律的に問題ありません。そうでないと作品の創作や制作ができませんので。もちろん児童ポルノは除きます。児童ポルノは無修正だろうが修正済みだろうが、単純所持ですらアウトです*2児童ポルノ、ゼッタイダメ。

しかし、たとえ自作であろうとも、無修正画像を不特定多数に公開・譲渡するとなると、前述の刑法175条に抵触します。公開対象の多い少ないにかかわらず、メールやSNSのファイル添付、ストレージサービスなど、共有目的でインターネットにアップロードすること自体が危険だと考えてください*3
某ポルノサイトでは海外のサーバーに無修正データをアップロードすることで日本の法律を潜り抜けようとしていますが、限りなく黒に近いグレーだということもお忘れなく。

よって、他人から「○○の無修正画像をもらえませんか?」などというリクエストを受けても、安易に譲渡してはいけません。

個人的意見

これは絵描きとしての個人的な意見ですが、せっかく描いたものに、モザイクやぼかし、ベタ/ホワイトで修正なんてしたくないんです。同人誌を発行するときや、SNSサイトに公開するときに、ときおり修正が弱いと指摘されることがあり、しぶしぶ手直ししていますが、内心では引っかかるものがあります。別にゾーニングができていればいいじゃないか。むやみに隠そうとするから逆におかしなことになるんです。むしろ修正したほうが余計にわいせつ感が増すと感じるのは自分だけではないはず。滑稽ですね。ゾーニングができていない(年齢詐称による抜け道があり、事実上誰でも閲覧できる)ことのほうがよほど問題です。

具体的に何をどの程度修正すれば「わいせつ物」とみなされないか、に関しても、法律で明確に定められているわけではありません。警察のさじ加減ひとつで決まってしまいます。修正は出版社・印刷会社・イベント主催者や創作者の自主規制でしかありません。でも捕まりたくはないので、安全側に自主規制せざるを得ない。ジレンマですね。その自主規制も年々強くなっているようで、業界全体が萎縮しているように感じられます。昔はゴールデンタイムに放送されるアニメでも乳首くらいは余裕だった*4というのに……

*1:「記録」が連呼されていますが、どうやら誤植ではなく法律上の正式名称らしいです。ややこしいですね。

*2:非実在青少年」とやらの話は、ここではツッコミません。あしからず。

*3:たとえ個人的なバックアップ目的だとしても、クラウドサーバーに無修正画像をアップロードするのは避けるべきです。

*4:昨今の深夜アニメの謎の光や自主規制マークは、円盤の購買意欲をそそるための差別化戦略でもあるのかもしれませんが。

Windows 10 1709/1803でキャレットの点滅が止まる

Windows 10 1709 (Fall Creators Update) には、エディットボックスなどのキャレット(縦棒のカーソル)の点滅が5秒程度で止まってしまうバグがあるようです。確かキャレットはシステムタイマーでOSが点滅させているはずですが、フォーカスしてから5秒くらい経過すると点滅が止まってしまいます。キャレットに独自の形状を使って自前で描画しているMIFESでも点滅が停止します。1703 (Creators Update) 以前ではこんな現象は発生していませんでした。1803にも同様のバグがあるようです。

キャレットの点滅は、現在のフォーカスがどのUI要素にあるのか、またアプリ(のUIスレッド)が生きているのかどうかを知ることのできる重要なインジケーターのひとつなので、これが止まってしまうとかなり困ります。この問題は、MFCアプリを開発していたときに気づきました。一瞬アプリ側のバグもしくは設計ミスかとも思いましたが、ありとあらゆるWin32アプリで発生するのでOS側に問題があることは確実です。

しかし、あろうことか窓の杜の某ライターは、キャレットの点滅が止まってしまうのを「仕様変更」だとうそぶいています。これは仕様変更じゃなくてただのお粗末なバグです。なぜ公式発表もないのに、れっきとしたメディアのライターがいい加減なことを書くのでしょうか。

さらに無理やり点滅を継続させるサードパーティ製ツールの紹介までしていますが、こんなくだらないツール作るヒマがあったらMSに不具合報告すべきですね。なんでも日曜大工でDIYすればいいってもんじゃないです。自動車の構造や計器に安全基準不適合の不具合や設計ミスがあったらリコール対象でしょう。不具合に気付いたら勝手に自分で改造して対応したり、その場しのぎの改造方法をユーザー間で共有したりするべきではなく、社会全体のことも考えて国土交通省に報告すべきです。ちなみにWindows 10ではエンドユーザーでもフィードバックHubで不具合報告できるので、おかしな動作に気がついたら個人でもどんどん報告すべきですが、多数の意見・要望が集まらない限りMSは動こうとしません。無視・黙殺されるのがオチです。

Windows 10の品質問題

Windows 10は特に従来のWin32デスクトップまわりの品質が明らかに低下しているように思われます。1709はGetPixel/SetPixel関数のパフォーマンスデグレードもやらかしやがったので、まったく良い印象がありません。1703は2018年10月でサポート期限が切れますが、1709はスキップして1803にすることも検討しています。
それにしても今のWindowsは、すでにある機能を破壊・劣化させてまで追加する価値のある機能など、なにひとつ提供できてないと思います。むしろ余計な新機能のほうがユーザーエクスペリエンスの邪魔をしているくらいです。Windows 7/8.1同様の快適性を得るために、いったいいくつの機能を無効化したか知れません。既存機能の破壊と劣化はApple同様、リリーススケジュールばかり優先して品質確保をおろそかにしているツケがまわってきているだけですが、頻繁な大型アップデートによる新機能追加なぞまったく望んでもいないユーザーが、なぜそこで不利益を被らなければならないのか。極めて疑問です。

FirefoxでGoogle検索結果から特定のサイトを除外する

安全・快適なインターネットライフのために、Google検索結果から不快・不正なサイト(NAVERまとめとか)は除外したいですよね。

Firefox Quantumより前のバージョンでは、「Hide Unwanted Results of Google Search」というアドオンを使っていました。このアドオンの素晴らしいところは、ワイルドカード正規表現で除外したいサイト・ページを柔軟に指定することができた点です。しかし、Quantum (v58以降) では仕様変更により、古いアドオンが使えなくなりました。「Hide Unwanted Results」はその後更新されておらず、Quantumに対応していないので非常に残念です。

Quantumに更新した後、現在は「Personal Blocklist (not by Google)」を使っています。もともとGoogle Chrome向けの公式アドオンとして公開されていた「Personal Blocklist (by Google)」を、Firefox向けに書き直したものだそうです。

ただ、残念ながらこのアドオンは「Hide Unwanted Results」と違い、ドメイン/ホスト単位でしか除外できません。たとえばQiita (qiita.com) から特定のユーザー*1のページだけを除外する、ということはできないわけです。

*1:Qiita自体は有用で参考になりますが、他のユーザーをバカにした不快なコメントを連発している傲慢なユーザーや、コメント欄でたびたびケンカ・炎上させているようなユーザーのページは検索結果にすら表示させたくないです。

Windowsセキュリティ認証とネットワークパスワード

Windowsで共有フォルダーにアクセスする場合、セキュリティ認証のためのパスワード入力を求められることがあります*1

しかし、PCを再起動/シャットダウンするなどして、ログオンセッションが終了すると、再度入力が必要になってしまいます。

コマンドプロンプトでセキュリティ認証を実行する場合、以下のようにnetコマンドを使うことができます。

net use \\<IPアドレスもしくはホスト名>\<共有名> /user:<ユーザー名> <パスワード>

再入力の手間を省く方法として、コマンドをバッチファイルに書き込んでおいて、バッチファイルをスタートアップに登録する手法もあるのですが、パスワードを平文でテキストファイルに書き込むのはセキュリティ上のリスクがありますね。

代わりに「資格情報マネージャー」(Credential Manager) を利用するとよさそうです。

www.mtecweb.com

Windows 10の場合もコントロールパネルからアクセスできます。

ちなみにTortoiseGitなどもWindowsのセキュリティ認証を使用しますが、あろうことか認証ダイアログで誤ったパスワードを入力してしまった場合でも、その誤ったパスワードが資格情報マネージャーに記録されてしまいます。以後、認証ダイアログが出ずに接続が延々と失敗し続けてしまう現象が発生します。誤ったパスワードを削除する場合、コントロールパネルの資格情報マネージャーから各情報セットを削除する必要があります。

*1:同一ユーザー名で同一パスワードの場合、パスワード入力なしに透過的にアクセスできます。

Visual C++コンポーネントの復旧

Visual Studio 2015 Update 3がインストールされているWindows 7 x64環境において、Python Tools for Visual Studioを2017年1月版に更新した後、Visual C++プロジェクトを含むソリューションファイルを開くと、

インストール コンポーネントがないため、プロジェクト 'XXX' を読み込めませんでした。修正するには、以下の選択をして Visual Studio セットアップを起動してください:
Install Visual C++ 2015 Tools for Windows Desktop

というエラーメッセージが出るようになりました。VC++プロジェクトは「利用不可」と表示されます。

しかし、Visual C++のプロジェクトテンプレート群はインストールされていて、Visual Studioのバージョン情報にもVisual C++コンポーネントは表示されます。どうやら、何らかのファイルが破損するなりして、VC++コンポーネントが正常に認識されていない模様。

[プログラムと機能]からVisual Studioのインストールウィザードを使って[修復]インストールしても改善しません。
[変更]インストールでコンポーネントのインストール状態をチェックしたところ、なぜか[プログラミング言語]→[Visual C++]配下のコンポーネントのチェックがすべて外れていました。

チェックを入れ直してインストールを実行すると、問題が解消されました。

一度「利用不可」状態になってしまったプロジェクトは、.suoファイルにアンロード状態が記録されてしまうようなので、コンテキストメニューから[プロジェクトの再読み込み]を実行して状態をリセットすればOK。

たぶんPython Toolsを更新したときに一部のVC++コンポーネントが勝手に削除されてしまったのだと思われます。ひどいバグですね。

Visual Studio 2015のコード整形機能のバグ

Visual Studioのコードエディターでは、C#コードを入力する際、ペースト時や閉じ中カッコ0x7Dあるいはセミコロン0x3Bを入力したタイミングなどで自動的にフォーマット(コード整形)が発動し、タブや空白などが自動調整されます。以前のバージョンのVisual Studioでは、C++コードでは明示的なフォーマット機能(ショートカット:Ctrl+K, Ctrl+F)のみをサポートしていましたが、Visual Studio 2015では、C++でもC#に近いオートフォーマットがデフォルトで発動するようになりました。
ただし、VS2015のソースコードエディターは、Update 3時点でもオートフォーマットのバグをいくつか抱えています。大半はVS2013時点では存在していなかったリグレッションです。VS2017は試していないので、不具合が修正されているかどうか、それとも依然として存在するかどうかは分かりません。なお、たとえMS Connectに不具合報告しても、VS2015では修正されず、どうせ新しいバージョンでしか修正されないことが分かり切っているので、報告するつもりはありません。また、せっかくユーザーが報告した不具合のチケットを、あろうことか勝手に削除することがあるようなので、MS Connectにはもう報告しないつもりです。傲岸不遜で恥知らずなMSにはもう協力したくありません。

フォーマット機能は、コーディング規約にそぐわないコードを整形するときは便利なのですが、意図しない形に勝手に自動整形されてしまうとイライラの原因になるだけです。また、明示的なフォーマットと、自動フォーマットとで整形結果が異なるときもあります。特にC#ラムダ式まわりで違いが具現化するのでイライラします。オートフォーマットが嫌いな人は、Visual Studioの設定で無効化しておくのが無難だと思います。

例1 (C++)

OpenGLDirect3Dで頂点バッファの初期データを定義するときによくある例です。

namespace
{
    struct MyVertex { float X, Y, Z; float Color[4]; };
    // 以下の行をカット&ペーストすると、Z の後ろのコンマと Color の間の空白がなくなる。
    const MyVertex Vertex1 = { 0.0f, +0.5f, 0.0f, { 1.0f, 0.0f, 0.0f, 1.0f } };
}

例2 (C++)

MFCが自動生成するコードとしてよく見られるものを、抽象化した例です。

class CMyDialog
{
public:
    CMyDialog() {} // 標準コンストラクター

// ダイアログ データ
    enum { IDD = 1 };
};

上記コードに対して明示的なフォーマットを実行したときに期待される動作は「// ダイアログ データの行が1レベルだけインデントされること」ですが、実際にフォーマットを実行しても何も起こりません。一方、カット&ペーストすると、// ダイアログ データ// 標準コンストラクターの開始桁位置と揃うように勝手にタブ文字および空白が挿入されてしまいます。

例3 (C++, C#)

void MyFunc()
{
    const int MyConst = 0; // 定数。
    // 処理。
    if (false) {}
}

上記コードに対して明示的なフォーマットを実行したときに期待される動作は「何も変更されないこと」ですが、C#の場合は、// 処理。// 定数。の開始桁位置と揃うように勝手にタブ文字および空白が挿入されてしまいます。また、C++においても、カット&ペーストするとC#同様に勝手な整形が実行されてしまいます。
行末尾のコメントを禁止するコーディング規約を採用している場合はこの問題に遭遇することはないと思いますが、勝手に桁位置を揃えられてしまうとイライラしますね。

例4 (C#)

class MyClass
{
    // ここで
    // #if false
    // #
    // と入力すると、既存の #region および #endregion のインデントが消失する。
    #region Fields
    int field;
    #endregion
}

通常、#regionおよび#endregionは対象となるコードブロックのインデントレベルに合わせてインデントされますが、このバグが発動するとインデントが消失します。

他にも、

    {
        ...
    }

というブロックを含むC++ソースファイルをフォーマットすると、なぜか

    {
        ...
}

というようにブロックのインデントが消失することもあります。このバグは発動条件が不明で、まったく同じソースなのに現象が出たり出なかったりと不安定です。確かVS2012か2013あたりまでは、少なくともこういった不安定な挙動を示すことはなかったように記憶しています。

Windows Updateとの戦い(2018年春の陣、休止状態解除の亡霊)

Windows 10 1703にて、2018-04-18にいくつかのセキュリティアップデートを適用したら、勝手にWindowsの休止状態 (hibernation) が解除されて復帰する(PC電源が勝手に入る)問題が多発するようになりました。休止状態はメモリ内容をストレージに保存してPC電源を落とすので、スリープよりも復帰に時間がかかりますが、休止中に停電が発生しても復帰ができるというメリットがあるので、就寝前にいつも使っています。

以前、休止状態の解除が頻発して困っていたときに、キーボードやマウス、ネットワークアダプターが原因かもしれないと思って、デバイスマネージャーにて[このデバイスで、コンピューターのスタンバイ状態を解除できるようにする]のチェックをすべて外していたので、これらのデバイスが原因である可能性は最初から除外しました。

まず、コマンドプロンプトを管理者権限で起動*1し、powercfgコマンドで前回の復帰の理由を調べます。

Microsoft Windows [Version 10.0.15063]
(c) 2017 Microsoft Corporation. All rights reserved.

C:\WINDOWS\system32>powercfg -lastwake
スリープ状態の解除履歴カウント - 1
スリープ状態の解除履歴 [0]
  スリープ状態の解除元カウント - 1
  スリープ状態の解除元 [0]
    種類: スリープ解除タイマー
    所有者: [SERVICE] \Device\HarddiskVolume2\Windows\System32\svchost.exe (SystemEventsBroker)
    所有者によって示された理由:

イベントビューアーのシステムログで「Power-Troubleshooter」を検索すると、以下のレコードが2018-04-20 05:35:00に記録されていました。

システムは低電力状態から再開しました。

スリープ時間: 2018-04-19T16:44:22.759254000Z
スリープ解除時間: 2018-04-19T20:34:53.450160600Z

スリープ状態の解除元: タイマー - svchost.exe

「スリープ解除タイマー」とは何者でしょうか? 調べてみると電源オプションで無効化できるそうです。

[コントロール パネル] > [ハードウェアとサウンド] > [電源オプション]にて、現在選択されている電源プランの[プラン設定の変更] > [詳細な電源設定の変更]をクリック。
[電源オプション]ダイアログで、[スリープ] - [スリープ解除タイマーの許可]が[有効]になっていました。コイツを[無効]に変更して[OK]または[適用]ボタンをクリック。

これで一安心……と思いきや、やはり休止状態が勝手に解除されてしまいました。

もう一度powercfgとイベントビューアーで調べます。

Microsoft Windows [Version 10.0.15063]
(c) 2017 Microsoft Corporation. All rights reserved.

C:\WINDOWS\system32>powercfg -lastwake
スリープ状態の解除履歴カウント - 1
スリープ状態の解除履歴 [0]
  スリープ状態の解除元カウント - 0

イベントログには2018-04-21 04:38:25に記録があります。

システムは低電力状態から再開しました。

スリープ時間: 2018-04-20T17:57:22.602822200Z
スリープ解除時間: 2018-04-20T19:38:20.464928200Z

スリープ状態の解除元: 不明

はい原因不明でした。

UpdateOrchestratorタスクグループ

タスクスケジューラで確認したところ、UpdateOrchestratorのRebootタスクが指定日時をトリガーとして登録されていました。
UpdateOrchestratorはWindows Updateに関わるタスクグループらしく、スリープや休止状態の勝手な解除を発生させる諸悪の根源です。UpdateOrchestratorを組み込んだMSのエンジニアは、本当に頭のおかしいキチガイでしょう。Windows 8.1からWindows 10に更新した後、しょっちゅうコイツに悩まされていましたが、ここ最近は小康状態だったので油断していました。1703でWindows Updateによる再起動前のリマインダーや、更新の一時停止(最大35日間)をできる機能が追加されたので、再起動の回数自体も減っていました。
ひとまずRebootタスクの[条件]にて、[タスクを実行するためにスリープを解除する]のチェックを外しておきましたが、次回のWindows Update後にはまた勝手に復活していることでしょう。なお、1709ではこの設定がUIから変更できなくなっているそうです。ユーザーにさらなる不自由を強いるとは許せませんね*2

しかし、UpdateOrchestratorのRebootタスクを修正しても、やはり休止状態が勝手に解除されてしまいました。解除元は相変わらず不明です。

WindowsUpdateタスクグループ

WindowsUpdateのAutomatic App Updateタスク*3およびScheduled Startタスクを修正すると改善されるとの情報あり。前者は4時間ごとに無期限に繰り返すよう設定されていました。後者は指定日時をトリガーとして登録されていました。
しかし、[タスクを実行するためにスリープを解除する]はともにチェックが外れていました。
ほかに、AUSessionConnectというタスクも登録されており、これは[タスクを実行するためにスリープを解除する]にチェックが入っていました。
ひとまずAutomatic App UpdateタスクとAUSessionConnectタスクを無効化しておきました。Scheduled Startタスクは無効化しても、一定時間経つと勝手に有効化されるようです。なお、AUSessionConnectは[タスクを実行するためにスリープを解除する]のチェックを外して[OK]をクリックしても、なぜか以下のようなメッセージが表示されて、変更を反映できません。

---------------------------
タスク スケジューラ
---------------------------
タスク スケジューラ サービスが利用できません。タスク スケジューラはサービスへの再接続を試行します。
---------------------------
OK
---------------------------

しかし、Automatic App UpdateタスクとAUSessionConnectタスクを修正・無効化しても、やはり休止状態が勝手に解除されてしまいました。解除元は相変わらず不明です。

powercfgコマンドを使って、スリープ解除元のデバイスとタイマーを列挙してみます。

Microsoft Windows [Version 10.0.15063]
(c) 2017 Microsoft Corporation. All rights reserved.

C:\WINDOWS\system32>powercfg -devicequery wake_armed
NONE

C:\WINDOWS\system32>powercfg -waketimers
[SERVICE] \Device\HarddiskVolume2\Windows\System32\svchost.exe (SystemEventsBroker) によって設定されたタイマーは 04:33:06 (2018-04-24) で有効期限が切れます。
  理由:

バイスは案の定存在しませんでしたが、タイマーが存在するようです。しかし「理由」が分からないのでタスクの特定ができません。

Windowsのタスクキャッシュ

Windowsの各タスクの設定情報自体は"%WinDir%/System32/Tasks"配下にXMLファイル(拡張子は無し)の形で保存されていますが、レジストリ"HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache"上にもバイナリキャッシュが保存されているようです。またキャッシュのほうが優先されるらしく、XMLファイルを直接編集&保存してWindowsを再起動しても変更内容が反映されません。タスクスケジューラのUIによる変更を確定しようとしたときにエラーとなるのは、おそらくキャッシュが破損しているからではないかと推測されます(4月のWindows Updateで破損した?)。しかしレジストリエディターでキャッシュを削除しようとしても、タスクスケジューラのサービスによってロックされているらしく、削除操作が拒否されます。また、タスクスケジューラのサービスはユーザーが停止させることができません。

セーフモードで起動してキャッシュを消そうかとも考えましたが、いい加減疲れたので、休止状態の勝手な復帰現象の原因追及はひとまずここまでとします。結局、休止状態にした後はPC電源スイッチを切る(|→○)という原始的な方法で対処することにしました。電源スイッチのあるオーソドックスな自作デスクトップ機でよかった。

もう少し追跡してみます。Tasksフォルダー配下のすべてのファイルを対象に、

<WakeToRun>true</WakeToRun>

をグローバル検索してみたところ、前述のAUSessionConnect以外にいくつか引っかかりました。

rempl\shellUpdateOrchestrator\AC Power Downloadはタスクが有効(準備完了)になっていたので、前者は[タスクを実行するためにスリープを解除する]のチェックを外し、後者は無効化しました。それ以外はすでに無効になっているので放置することにします。

Microsoft Windows [Version 10.0.15063]
(c) 2017 Microsoft Corporation. All rights reserved.

C:\WINDOWS\system32>powercfg -waketimers
システムにアクティブなスリープ解除タイマーがありません。

ようやくタイマーがなくなりました。ひとまずこれで様子見とします。

グラフィックスドライバーの勝手な更新

休止状態の解除問題とは直接の関係はありませんが、Windows Updateの履歴を見ると、2018-01-21に、NVIDIA GeForceドライバーが384.94から388.13に許可なく勝手に更新されていました。グラフィックスドライバーは特に相性問題を起こしやすく、たいていのパワーユーザーはドライバーの更新に慎重になるのですが、これが勝手に更新されるとなるとかなり困ります。以前はデバイスドライバーの更新に関してはオプショナル(任意)だったはずなのですが……
ひとまずグループポリシーでデバイスドライバーの更新を無効化する([Windows Updateからドライバーを除外する]を[有効]に構成する)ことで対処しました。

Windows 10更新アシスタントの無限復活

3月頃には「Windows 10更新アシスタント」が勝手にインストールされて、1709のダウンロードが始まる事案が発生しました。更新アシスタントはコントロールパネルで削除しても無限に復活する、まさにゾンビのように厄介なアプリです。グループポリシーでは無効化できず、以下のサイトを参考にしてようやく抑制できました。
www.atmarkit.co.jp

MSはどうしても1709の導入ベースを増やしたがっているようですが、だからといってユーザーの許可なく勝手にアプリをインストールするなんて破廉恥極まりないですね。年2回の大型アップデートスケジュールも、無理やりスケジュールを守ろうとして品質の確保ができなくなってしまっているのが目に見えています。機能追加のためのアップデートとスケジュールではなく、スケジュール遵守のための無理な機能開発になってしまっていて、目的と手段が完全に入れ替わってしまっていますね。お粗末としか言いようがないです。そもそも大型アップデートにより追加あるいは削除される機能のうち、大半は誰も望んでいない変更です。しかも新機能はことごとくオプトアウトなのも始末が悪いです(余計な機能がデフォルトで有効化されていて、無効化するためにはユーザーがいちいち設定を変更しなければならない)。

Windows 10はユーザーの自由と時間と情報と安眠と電気代を奪っている

Windows 8.1までは良くも悪くもエンドユーザーがWindows Updateのタイミングと内容を完全にコントロールすることができていました。翻ってWindows 10では、ユーザーにほとんど自由がありません。せっかく設定を変更して抑制しても、Windows Updateを適用すると(MSにとって都合のいいように)設定が毎回リセットされてしまいます。ましてや、余計な機能てんこ盛りで品質の低い大型アップデートを勝手にインストールして、ユーザーのシステムを台無しにするなんて、犯罪にも等しいです。また、MSは個人情報収集のためには手段を選びません。なりふり構わずあの手この手を使ってきます。知識がないライトユーザーは簡単に騙されて大量に個人情報をぶっこ抜かれてしまうでしょう。こういう汚いことを続けていれば、どんどんパワーユーザーが離れていくということにMSは気付かないんでしょうか。本当に過去最悪のOSです。Windows 10の汚らしい挙動と、MSの下品なゴリ押しのせいで、Direct3D 12*4もUWPも開発に使う気がすっかり消え失せました。開発環境としてずっと慣れ親しんできたWindowsですが、もうウンザリです。もはやWindowsプラットフォーム固有の開発には積極的に投資したくありません。

今のところゲームやクリエイティブツールの関係上、どうしてもWindowsを使わざるを得ない状況ですが、今後Wineの完成度が上がればいずれWindowsを捨ててLinuxに移行したいですね。ソフト電池のような認証ツールもWine環境に対応してくれたらいいのですが。

※2018-06-03追記
5月度のWindows Updateを実行すると、案の定またスリープ解除タイマーが復活しました。例のごとくタスクのXMLファイル群をグローバル検索してみると、

というタスクが有効かつWakeToRunがtrueになっていたので、[タスクを実行するためにスリープを解除する]のチェックを外しておきました。

※2018-07-16追記
6月度のWindows Updateを実行すると、以下のタスクが有効かつWakeToRunがtrueになっていたので、[タスクを実行するためにスリープを解除する]のチェックを外しておきました。Windows Updateのたびにスリープ解除タイマーを復活させやがることが分かったので、そろそろ無効化作業を自動化したいですね。

*1:余談ですが、最初のカレントディレクトリは通常権限だと「%UserProfile%」で起動する一方、管理者権限だと「%SystemRoot%\System32」で起動しますね。

*2:MSが運営している各種フォーラムには、こういった明らかにユーザーに不利益を強いているMSの姿勢すら擁護する大量のマゾ信者がグルとして涌いていて、本当に気持ち悪いです。

*3:Windowsストアアプリを自動更新するためのタスクらしいです。ところでストアアプリなんていう不自由なもの、誰が好き好んで使うんですか?

*4:Direct3DとHLSLの進化が停滞すると競合のOpenGL/VulkanとGLSLも停滞することが予想されるので、Direct3Dの更新自体は続けて欲しいのですが、個人的には今後Direct3D/MetalよりもVulkanのほうが普及率が高くなり、API統一が進むのではないかと予想しています。