2015年11月27日金曜日

opensslでこさえたオレオレ認証局からWindows向けのコードサイニング用証明書も発行する

現時点でオレオレ認証局を運用していて、当然クライアントにもオレオレルート証明書が入ってる人向けの、とても需要がないこと請け合いの記事です。

なお、EVコード署名証明書の話題ではありませんので念のため。
あれはWHQLが通らない開発元でもMicrosoftに署名してもらいたい時に保証人業者が自分のことを証明してくれてるから信じてね!、という提出用書類なのでこの話題とは関係ございません。

さて、最近はクラウドだとかで個人で使うにも敷居がどーんと下がってきて需要が下がってきていることとは思いますが、まだまだ現在でも個人や小規模なグループで、自分たちの存在を第三者に証明する必要はないが自分たちがサーバにアクセスする際には経路の暗号化は必要ですから、やっぱりオレオレ認証局と証明書は便利です。

それにタダですからね。
コマンドを打ち込む時間を抜きにすれば。

ところで、最近、Windowsはちょっとしたオレオレドライバも証明書を付けないとロードしてくれなくなっています。

ついにWindows10はカーネルモードドライバに限っては必ずMSの認証が必要になってしまって、あまり大きくない測器屋さんとかの独自ハードを作っておいでのところや、個人で大枚払ってコードサイニング証明書を買ってまで自作ソフトを公開していた方が、さらに新しい証明書を買わないとダメですよー的にごっそり切り捨てられて、一部界隈ではちょっとした話題になっちゃいまいた。

ソフト屋としては自由度が減れば減るほどちょっと寂しいのですが、一方で「なにもしてないのに」ウィルスにかかっちゃうエロおやじうっかりさんどころか、本当にまっとうと思われていたサイトにアクセスしても、広告が乗っ取られていてFLASHとかブラウザの脆弱性のせいでウィルスに冒されたり、サイバー攻撃を受けたら軍事的攻撃とみなす、とか、米中首脳会談の主要議題の一つにまでなってしまうとか、ことほど左様にコンピュータへの攻撃が激しい昨今ですから、笑い事ではありません。まさに生き馬の目を抜くような、という世界に一般の人までも巻き込まれてしまう情勢です。そこに「PCってなんスか?」とか、情報教育を受けたとか聞いていたはずの若者が雪崩れ込んで来て、もはや阿鼻叫喚の地獄絵図です(情報教育ってなんスかね。年寄りには想像もつかないわ)。

Microsoftだって商売ですから、自由にモノづくりができる環境と安心して作業できる環境とでは、もはや後者を優先せざるを得ないでしょうし、この流れはWindowsだけでは済まないだろうなあ、と思います。

話がずれてしまいました。
そんなこたぁオレオレ前提な以上、使う側はわかって使うのでどうでもいいわけで、実際にはWindowsでも起動オプションで署名されていないドライバでもロードできるわけです。

が、ちと、手続きが面倒くさい。

そこでオレオレコード署名証明書の出番となるわけですが、どうせテストだから、仮だから、とか言って適当に作りまくっていると証明書ストアが汚れていくのでなんかイヤ。

しかも、そういう向きにはオレオレルート証明書は使用しているクライアントに当然入っているわけです。

従って、そのオレオレルート証明書を発行した当のオレオレ認証局にオレオレコード署名も発行してもらえばいいわけです。

win-win, *nix-*nixなら別にどうということもないでしょうから、ここでは、opensslで構築したオレオレ認証局に署名してもらったコード署名証明書をWindowsのデバイスドライバに署名する方法を記述します。

やるこたぁ単純です。ですが、自分がどの立場で作業しているか、だけは意識してください。
※ 当然認証局がコード署名に対応していないとダメですよ!
opensslの定義体の [ v3_req ] の keyUsage  エントリで、codeSigningが指定されていることを確認してくださいね!
Ex). keyUsage = nonRepudiation, digitalSignature, keyEncipherment, codeSigning

具体的には以下となります。
  1. opensslで構築した認証局側で、オレオレコード証明書を認証してください、とオレオレ認証局に対して申請書を書きます。
    その申請書のために、まず秘密鍵を生成します。まあ、長さは2048でいっときましょう。

    # openssl genrsa -des3 -out オレオレコード認証秘密鍵 2048

    ※ オレオレコード認証秘密鍵は、せめてchmod 600しておいたほうがいいですね

    次に、実際のコード署名証明書の申請書を書きます。
    今はやりのSHA-256がいいかな、と。

    # openssl req -new -sha256 \
                -config  あらかじめCN等を定義しておいた定義体があるなら指定してください \
                -days 10000日くらい。どうせ近いうちにまた暗号強度がドーとか言われて作り直しさ \
                -key オレオレコード認証秘密鍵 \
                -out 認証要求のお願いの申請書
  2. コード証明認証要求が届いたので、今度は認証局側の立場で申請書を認証します。

    # openssl ca \
                 -config  認証局を作った時の設定ファイルを指定すると楽です \
                 -in 認証要求のお願いの申請書 \
                 -cert 認証局の証明書 \
                 -keyfile 認証局の秘密鍵 \
                 -out オレオレコード署名証明書
  3. オレオレコード署名証明書が届いたので、今度は申請者側に戻ってWindowsでも利用できる形式に変換します。

    # openssl pkcs12 -export \
                 -in オレオレコード署名証明書 \
                 -inkey オレオレコード認証秘密鍵 \
                 -out Windowsで署名するためのpfx形式のファイル.pfx
  4. 実際にWindowsでファイルに署名します。

    X:\signtool.exe sign  /a /f Windowsで署名するためのpfx形式のファイル.pfx  /p パスワード 対象ドライバ名.sys

    ※パスワードは平文です。。。

    なお、signtool.exeは各OSのSDKに入っています。
    Windows10 は こちら

    説明するのが楽なのでVisual Studio の Community Editionを推薦する人も多いんですが、自分がライセンス的に使えるかどうかだけはどうか意識してください。
    さもないと真綿で自分の首を絞めることになります。
    MSは確かに昔から開発者に対して親和的だと(個人的には)言って憚りませんが、不正利用が蔓延ってしまったら彼らだって手を引いてしまいます。
うーん、なんだか和文で書くとかえってわけがわからない感じになってしまった気もします。
そもそも、こんな話題、誰が読むんだろうか。
そして、読んでいただいたとして、まさに釈迦に説法ではなかろうか。

何でこんな記事を書いたかというと、某所で壮絶な勘違いを見てしまって。。。
いやまてよ、自分が壮絶な勘違いをしている可能性のほうが高いですね。経験上、バグを見つけたら原因は自分をまず疑うと解決が速まりますから。

なお、当然ながらsecdrv.sysの署名m




2015年11月24日火曜日

タスクバーが半ギレ

エクスプローラってしょっちゅうおかしくなるので、タスクマネージャでも特別扱いにされてほかのプロセスでは出来ない「再起動」というメニューが用意されてますから、いまさら驚くことではないのかもしれませんが、こればかりは本当に初めて見ました。
(Microsoft Windows 10 version 1511)

タスクバーの描画が面白いことになっています。


長すぎて見えませんねえ。

まず前半。



なぜかタスクビューボタン以後、アイコンの下半分が描画されていません。

で。

通知領域のほうはというと、


今度は上半分が描画されていません。

なんて器用な障害の作りこみをするんだろう。
見た時にスゴイ感心してしまいました。

思わずSSをとってしまったので、折角ですので記録しておきます。

オモチャオモチャといじめすぎておこなの?
激おこなの?

?・。・?

2015年11月23日月曜日

cpufreqにおけるondemand時での最大動作速度を指定する

恥の記録です。

前置きです。
CentOS5でHandBrakeで過去にmencoderでエンコードしたファイルをh265形式に一括変換するバッチを流して1日放置。

平均処理速度が1~2fpsしか出ていない。
・・・何かがおかしい。

こうして、自分の愚かさにまたもや向き合うこととなりました。

原因はcpufreqがondemandになっていて、ondemand時のcpu速度の上限が1.2GHzになっていたからです。

なぜ愚かかというと、以前仮想マシンの関係でクロックがコロコロ変わるとゲストOSの時計がひどく狂う問題があって、cpuspeedは停止設定にしていたのに、元に戻ってしまっている点と、HotSaNICの記録から、元に戻ったのは1年以上も前だったことが分かったことです。

仮想マシン上で動かしていたゲストOSはあるシステムの検証用に必要だっただけで、検証が済んだ後は起動していませんでしたから時計が狂うという点からは気づきませんでした。

重い日例、週末、月末バッチは、終了後に結果をメールで確認しますが、受信時刻を特に気にしたこともなく、ここからも気づけませんでした。

日常使う上でも、特に重い処理なんてでかいパッケージのmake作業くらいですし、時間がかかることは元からわかっていますから、まさかcpuの動作周波数が抑えられているとは考えつきませんでした。

以前のエンコードが遲くて気づかなかったのは、ぶっ壊れたサーバのCPUの上限周波数が1.6GHzだったので、1.2GHzとそう大して変わりがないので、これもやはり気づきませんでした。

今回の変換処理では変換記録をログに残すようにバッチを書いておいたので、処理時間を見てみると、最大8時間もかかっているのがあってびっくりしましたが、時刻を見ると日例と週末バッチが重なる時間帯だったのでこれは除外して、他を調べると、特に負荷がかかるはずがない時間帯の処理でも5時間半かかっています。

しかし、今回導入したTX1310 M1は2.7GHzのcpuを乗せています。
いくらなんでもオカシイだろう、とようやく気付いたのでした。

本当に自分は頭が悪いんだと思います。

で、/proc/cpuinfoを見てみると、cpu MHz : 1200.000 となっているじゃあありませんか。
こりゃあcpufreqだな、と、やっと見当がついたので
/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
を見てみると、しっかり1200000と表示されました。

そこで、/etc/sysconfig/cpuspeedを開いてみるとMAX_SPEEDに1200000が指定されていました。。。

ファイルの日付を見ると、最終更新日時が2008/03/20 14:09:24でした。
うーん、2008年・・・前代のExpress5800が2007年だったからCPU速度は1.6GHzなのになぜ1.2GHzを指定してあるのか、さっぱりわかりません。
それ以前も、壊れたサーバからHDDを乗せ換えてそのまま利用していますが、そもそも1.2GHzのCPUなんて使ったことないんですよねぇ。

どのタイミングでondemandになったかもわからないし、そもそもcpuspeedは起動しない設定にしてあったはずだし、謎の周波数が指定されているしでわけがわからないのですが、どれもこれも確かに自分でやった所業のはずなのにすっかり忘れている挙句に、cpuが遲いから調べることとなるという愚かさは我ながら救いようがありません。

さて、ほとんど前置きで書いてしまいましたが、本題です。

私の場合は愚かさによるものでしたが、CPUの性能にかかわらずにCPUの周波数を変更したい場合はあると思います。
  • 長時間CPU資源を占有するプロセスを起動する必要があるが、速度は求めていない場合
  • 温度が上がりすぎるのを抑えたい
  • 電気代の節約
  • 重いプロセスが走るはずがない時間帯に突発的にクロックが上がることを抑止したい
などなど、いろいろ考えられると思います。
そんな場合はcpufreqのondemandガバナで対応できます。
/sbin/lsmod して cpufreq_ondemand  が読み込まれていればondemandが有効になっています。
なっていない場合は/etc/sysconfig/cpuspeedで
GOVERNOR=
の行の右辺に別のガバナが指定してあると思いますので、デフォルト値がondemandなのでカラにしておくか、明示的にondemandと記述し、cpuspeedを再起動します。

上限周波数は直接/sys/devices/system/cpu/cpu*/cpufreq配下のファイルを書き換えてもいいです。
時間帯ごとにcronでスクリプトから直接制御するなどの用途ならこちらのほうが簡単かもしれません。
scaling_max_freqを書き換えるだけです。

手動の場合はコア数が増えると面倒ですからcpufreq-utilsパッケージを導入したほうがいいでしょう。cpufreq-set というコマンドがありますので、それを使用すれば簡単です。

デフォルト値として上限を設定しておきたい場合は/etc/sysconfig/cpuspeedファイルにMAX_SPEEDという左辺値がありますので、右辺にクロック数を指定します。
指定可能なクロック数のリストは
/sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies 
に記述されていますので、その中から選択します。
scaling_max_freqを直接書き換える場合も同様です。

ただ、ondemandは最低と最大の2値しかとらず、瞬間湯沸かし器のようなヤツですので、本来であればconservativeをガバナに指定したいところですが、CentOS5は対応前のカーネルなので使えません。

普段は上限にソコソコの値を指定しておき、本当にcpuパワーがほしい時だけ手動でガバナをperformanceに切り替えたほうが筋としてはいいのかもしれません。

・・・万が一、これと同様の考えで2008年にcpuspeedの設定を自分で書き換えたとしたら、それをずっと忘れているんだからやっぱり愚かとしか言えません。

以上、恥の記録とおまけでした。

2015年11月22日日曜日

CPU資源を特定のプロセスに使わせない方法

HandBrakeって、昔はできたような気がするんですが、CPU資源を制限するオプションが消えてますね。記憶違いかなあ、ず~っと以前に使ってみてすぐだめだと思って採用を断念したときにはあった気がするんですが。

まあ、わざわざCPU資源を制限する場合というのもあまりないのですが、プロセスの優先度だけだと、結局全部の資源を持っていかれるので、高TDPを誇るCPUさんが搭載されているシステムで急がないけどほっとくと長時間高負荷になることが事前にわかっているプロセスさんにちょっと遠慮をしていただきたい時や、マルチスレッドだとかえって性能が落ちてしまうプロセスさんに指定するときに有効です。

で、コマンドラインでお手軽に特定のプロセスのCPU資源を制限する方法って意外に知られていないので、とりあえずご紹介します。

*Windowsの場合
Vista以後はアカウントごと制限をしてしまう方法と、プロセスごとに制限する方法があります。
前者の機能は当時Windows2000からのNT5.0系(XP含む)からVistaになってNT6.0に確かに進化した、と思った機能の一つです(Windows10はいきなりNT10.0になりましたが、機能より政治的理由がvernoのインフレを招いているように見えますが・・・ま、命名者の勝手ですからね)。確かにちゃんとOSに近づいたぞ、的な。

アカウントさえこしらえてしまえば、レジストリにちょこっと制限帯域を登録するだけなので、お手軽です。
しかし、アカウントごとまとめて制限してしまう方法は本当にすっっっっばラシイのですが、アカウントを作成したりする手間があるので、今回は臨時に指定する方法をご紹介します(意外に知られていないらしいのですよね。処理を早くするほうはみんな関心がありますがわざと遅らせるという方面の情報があんまり知られていないようです)。

起動後で制限するならタスクマネージャで可能です。詳細画面で対象のプロセス名を右クリックメニューから「関係の設定(F)」を選択するだけです。

コマンドラインから起動時に制限してしまう場合はstartコマンドを使います。
start /affinity オプションで指定しますと、使用するCPU(但し、HTT、ハイパースレッディングが有効なCPUは実コア数ではなくて仮想コア数で指定します)を制限できます。
バッチファイルなどで活躍してくれますのでこっちのほうの需要が多いでしょう。

ただ、ちと指定方法が特殊です。数を指定するのではなく、使いたいCPU(またはHTTによる仮想コア)をビットフィールドで指定します。

例えば、CoreI7機であれば実コア4,HTTのため8コアに見えてしまいます。
ここで、コア番号01234567があったとして、使いたいコアを1、使いたくないコアを0として2進数を16進数に変換した値を指定する必要があります。

例1: コア番号0と7だけ使わせたい
 -> 2進数で 1000 0001 なので 16進数に直すと81
     start /affinity 81 notepad.exe
例2: コア番号0から5まで使って2ツ開けておきたい
 -> 2進数で 0011 1111 なので3F 
     start /affinity 3f notepad.exe

といった具合です。

*linuxの場合
確かカーネル2.6からでしたか、こちらも実装されています。
taskset というコマンド名で、windowsと同じようにマスクを16進数で指定します。
tasksetはタスクマネージャとstartコマンドの機能を同時に実現できます。
つまり、pid指定で後追いでCPU資源を制限することも、起動前に制限しておくこともできます。
まあ、windowsとちがってmanページもありますから、コマンド名さえわかればもうどうにでもなるでしょう。

以上、HandBrakeがらみで思い出したので、記録しておくことといたしました。

2015年11月21日土曜日

HandBrakeCLI 0.10.2 をCentOS5向けにビルドする

まだlinux版ではQSVも使えませんし、こんな間抜けなことをするのは世界中でもわずかでしょうから一応メモ。もっとも、QSVはh264。Windows10で視聴するならh265でしょう!!

ってことで。

200x年代にエンコードしたタモリ倶楽部をもっと圧縮すべく、HandBrakeさんにお願いするとしましょう。
CentOS5ではFFmpegやらmencoderはしがらみが多すぎて最新版にするのが面倒くさいという事情もあります。FFmpeg vs libavの抗争に巻き込まれるのも面倒ですしね。

早速、HandBrake-0.10.2.tar.bz2を展開したら
./configure
すると./buildに入ってmakeしろという指示が出るのでmakeします。

すると、libdvdreadやlibdvdnavなどでコンパイルに失敗します。
CentOS5のautomakeが古いためで、この場合、configure.acでエラーが発生している場合、以下の4パターンが起きます。
  • aclocal -Im4 オプションなんか知らねえよと怒られる。
     -> configure.ac中に
           ACLOCAL_AMFLAGS = -Im4
        という行があるので -I m4 というようにホワイトスペースを挿入する。
  • AM_PROG_CC_C_Oが未定義と怒られる
     ->configure.acの適当なところにAM_PROG_CC_C_Oを追記。
    ま、要するに最近のautomakeでは廃止されるマクロを使わないでくれという要請に従っているプログラムがエラーになるので、廃止されるマクロをいちいち追記するということです。
  • AC_PROG_LIBTOOLが未定義と怒られる。
     ->configure.acの適当なところにAC_PROG_LIBTOOLを追記。
  • AS_CASEがどうたらと怒られる。
     ->configure.acのAS_CASEの行はlinuxとは関係ないので丸ごとコメントアウトしてしまう。
また、Makefile.amで docdir未定義、と怒られたら、
dist_doc_DATA = AUTHORS ChangeLog COPYING README TODO
という行があるのでコメントアウトしちゃっていいです。
我ながら乱暴ですが、まるで問題ありませんのでご安心ください。

ちょいちょい上記のようなエラーで止まりますが、コンパイルそのものはgcc4.1.2でも通ります。有難いことです。

但し、期待されているライブラリやファイルがなければ当然ヘッダがねーよとかライブラリがねーよ、というエラーは出ます。
私の場合は以下を追加で入れました。
baseリポジトリになければrpmforgeにあります。

libass-devel
libx264-devel
lame-devel
libogg-devel
libvorbis-devel
libsamplerate-devel と libsamplerate
fribidi-devel と fribidi
bzip2-devel
intltool
perl-Compress-Zlib
perl-HTML-Parser
perl-HTML-Tagset
perl-XML-Parser
perl-libwww-perl

まあ、ヘッダがないとかライブラリがないとか言い出したら適当にrpmを見繕って突っ込めばいいです。パッケージャの皆さんありがとう!!

但し、libtheora-develだけは残念ですが利用できません。
CentOS5向けのパッケージは古いのでヘッダもライブラリも足りないからmakeが通りません。
古いlibtheoraはgnomeやmencoderが依存しまくっているので消さずに残し、別途ビルドして/usr/localに突っ込みます。

今回はlibtheora-1.1.1.tar.bz2を利用しましたが、ビルド方法は、これまたありがたいことに./configureを実行後、make installするだけです。
defaultで/usr/local配下に展開してくれるようになっています。

あ、LD_LIBRARY_PATHはお忘れなく。DLLがないよ、と怒られますからね。

最後に
No package 'gtk+-3.0' found
No package 'gio-2.0' found
No package 'libnotify' found
No package 'dbus-glib-1' found
No package 'gudev-1.0' found
というエラーで止ってしまった場合ですが、GUI版がほしい人は要求に従ってください。
今回はHandBrakeCLI自体はできているので無視して終了です。
お疲れ様でした。

早速、以前にmencoderでオリジナルtsの1/3程度にmpeg4でエンコード済みのファイルを早速h265で再エンコードしてあげると・・・さすがにIntel(R) Celeron(R) CPU G1820 @ 2.70GHzでは4~5時間かかります。

同一ファイルを同一オプションでCore-i7機で処理すると3~40分です。
但しCPU温度は90度を越えます。G1820のほうは26度程度です(設置場所が違うとか諸条件がまるで違うのですが)。

そして、出来上がってみると音声がずれています。
オプションに音声をコピーするよう指示してあってもです。

ここからがHandBrakeの楽なところですよね。コマンドラインに--cfrを指定してあげるだけで固定ビットレートになるので音声がずれなくなります。

-q 28 の場合、実に 205 MB までスリムになりました( -q 20 の場合は 622 MB でした)。

すげえ...

これでタモリが100歳超えても大丈夫。
長生きしてくださいね!!

私が先にくたばること請け合いですが。

*** ご参考 ***
変換元ファイルを作成した時のmencoderのオプションは以下でした。
-demuxer lavf \
  -vf harddup,crop=0:0:0:0,scale=1440:-2 \
  -sws 9 \
  -ovc lavc \
  -lavcopts \
vcodec=mpeg4:vbitrate=6000:vmax_b_frames=0:vme=4:mbd=1:autoaspect:dia=1:vb_strategy=0:predia=1:last_pred=0 \
  -af volnorm=1 \
  -oac mp3lame \
  -lameopts aq=5:cbr:br=192

変換先を作成するHandBrakeのオプションは以下でした。
-e x265 --h265-profile main --modulus 2 -q 28 --cfr --aencoder copy

2015年11月19日木曜日

PT3が突然動かなくなった原因

以前こちらで記事にした、PT3が突然動かなくなった理由が今頃わかりました。
恥の記録として残しておきたいと思います。

たまたまWindows10のデバイスドライバに関連した事柄を調べていると、偶然このトラブルの原因が分かりました。

結論から言えば、PT3のドライバがミドルウェアとして採用しているWinDriverがWindows10上では試用版として作動したため、試用版の制限として30日後に使用できなくなるという仕組みによって、突然使用できなくなったように見えたもののようです。

最新のPT3用ドライバ4.0はミドルウェアもWindows10に正式対応したものを採用しているため、その後は問題なく使えた、ということでした。

要するに、対応していないOSで勝手に使って自滅しただけという、いつも通りの恥ずかしい行いが原因というわけでした。

ともかく、原因がわかって大変すっきりしました。
あの時は「何もしてないのに?!」とちんぷんかんぷんでしたが、実際には何もしてないどころか「1月前にOSを変えた」というとんでもない不始末をしでかしていたのでした。
我ながらなんと愚かな考えを抱いたことが恥ずかしい。

動作対象OSでもなんでもなかったデバイスなのに素早くWindows10に対応してくれたメーカにもあらためて感謝の念がわきました。

ところで、試しに、Windows10にPT3用ドライバを動かなくなった日の30日前にインストールしたのか調べようとすると、驚いたことにThreshold2に更新する前のイベントログが見事に消されていました。。。

クリーンインストールならともかく、更新前のログを消す必要がどこにあるのか、というよりログなんだから引き継がないと何の意味もないだろう、とマイクロソフトさんとの考え方の違いに思いを致しつつ、さすがにWindows.oldには残っていた(というより引き継がずに放置されていた)ログファイルで確認したところ、確かに、当方の場合は 2015/09/04 にPT3用ドライバをインストールしていました。
バージョンは以前に記しました通り、3.1(WinDriverのバージョンは11.6.0とリリースノートにありました)ですので、早朝5:30まで動いていたのは若干不可解ではありますが、9月は30日ありますから、31日目に起動しなくなったので辻褄は合います。

ただ、いまさらですが試用版として使用しているならその旨をユーザに表示するとミドルウェアの開発元のホームページにはありますが、当時そんなメッセージなどどこにも出ていませんでしたし、イベントログを再びじっくりと調べても一切そのような記録は残っていませんでした。これが機能していたらすぐにスッキリできていたのですが、ちょっと残念です。

2015年11月17日火曜日

Windows10 Threshold 2 でまたまた増えた回復パーティション

Windows10初の大型アップデートと言われるThreshold 2が世に放たれました。
なにしろここ最近のWindowsはアップデートと言いながら何をしでかすかわからないので、世間様の様子を見てから入れようと思ってアップグレードを延期していましたが、特に大きな問題も起きていなさそうなので本日アップデートしてみました。

表題とは関係はありませんが、試しに再起動を求められたときにWindowsUpdateの設定を「アップグレードを延期する」に戻してリブートすると、正しく更新に「失敗」しました。
これは今後うっかりダウンロードされちゃったけどしばらくPCが使えないのは困る!というときに助かることになるかもしれません。

しかしいやあ、驚きました。
アップデートというよりほとんどOSの入れ替えを行うようなシロモノじゃないですか、これ。
それほどの改良点が本当にあったのか?これ。。。

おまけにアップグレード直後は開けていたのに数分経つとスタートメニューも電卓も開けなくなってしまいました。
ユニバーサルアプリだかストアアプリだか知らないが、どっちもそっち系統のプログラムなのでイベントビュアを見てみたら、延々と

アプリ Microsoft.WindowsCalculator_(略)!App のライセンス認証がエラーで失敗しました: アプリは必要な時刻に開始されませんでした。。詳しくは、Microsoft-Windows-TWinUI/Operational ログをご覧ください。
とかいうメッセージが山ほど記録されていました。再起動したら直りましたが。。。テストしてんのかねぇ。
(ていうかWindows10の電卓、ユニバーサルだかストアだか知らないけど異常に起動が遲いので以前のcalc.exeに戻させてほしい・・・)

どうでもいいけどCortanaもさん付けしないとガン無視くれるし、たいていBingの検索結果が出るだけだし、しかも音声合成の名前が私と同じ名前ってのが妙に小馬鹿にされたような気がする(どういう僻み方なんだ?)。

で。
OSのアップグレード並みなことをしたってことは・・・
今回も。
期待通りに?

そう、期待通りに!
どどーんと回復パーティションが増殖いたしました!!
やったね!

でもなあ。500MBの回復パーティション(Windows10無印クリーンインストール時に作成したもの)ではダメなのかな。TH2に更新した際に新しく追加されてしまったのは450MBで、Windows10無印をクリーンインストールした場合に自動で作られる容量と一緒なんだけどなあ。

まあ一応念のため、どっちの回復パーティションを使っているか確認してみました。
X:\>reagentc /info
Windows 回復環境 (Windows RE) およびシステム リセット構成
情報:
    Windows RE の状態:         Enabled
    Windows RE の場所:         \\?\GLOBALROOT\device\harddisk0\partition5\Recovery\WindowsRE
    ブート構成データ (BCD) ID: 58b89e97-52d3-11e5-af67-b1d0abcb4533
    回復イメージの場所:
    回復イメージ インデックス: 0
    カスタム イメージの場所:
    カスタム イメージ インデックス: 0
新しいほうを使っているみたいです。
まあそうだわな。

不思議なのは、回復ドライブが増えてない人もいるんです。
というよりも、今回はそんな話は検索しても出てこないので、私だけなのかも。ちょっとだけ増量して500MBにしてあげたことがWindows10TH2さんの逆鱗に触れてしまったのでしょうか。

Windows8->8.1の時は350MBの回復ドライブの中身が空っぽにされていましたが、今回はどうなのかな、と思ってドライブレターを振って中身をのぞいてみると。。

パーティション1(Windows10無印の回復パーティション)
X:\>dir recovery\windowsre /a-
 ドライブ X のボリューム ラベルは Recovery です
 ボリューム シリアル番号は F4D5-A812 です
 X:\recovery\windowsre のディレクトリ
2015/09/04  16:19    <DIR>          .
2015/09/04  16:19    <DIR>          ..
2015/07/10  19:59         3,170,304 boot.sdi
2015/09/04  16:19             1,032 ReAgent.xml
2015/07/11  01:13       322,790,888 Winre.wim
               3 個のファイル         325,962,224 バイト
               2 個のディレクトリ     181,395,456 バイトの空き領域

あれあれ。今回はしっかり中身が残っていますね。
ついでにパーティション5の450MBの回復パーティション(TH2で追加されたもの)をみると
Y:\>dir /a- Recovery\WindowsRE
 ドライブ Y のボリューム ラベルがありません。
 ボリューム シリアル番号は 008F-E467 です
 Y:\Recovery\WindowsRE のディレクトリ
2015/11/16  21:32    <DIR>          .
2015/11/16  21:32    <DIR>          ..
2015/10/30  16:17         3,170,304 boot.sdi
2015/11/16  21:32             1,041 ReAgent.xml
2015/11/16  20:53       350,347,938 Winre.wim
               3 個のファイル         353,519,283 バイト
               2 個のディレクトリ     101,474,304 バイトの空き領域
だそうで。
しかしなんですねえ。多少大きめに作っておいても回復パーティションが増殖しちゃうんですねえ。
でもデフォルトの450MBのままの人でも増殖しない人がいる。

もうこれ、わかんないわ。

まあ、面倒なのでまだやってないけど、今回は容量的に元の回復ドライブに移してreagentc.exeで再指定するだけで済みそうではありますが、回復パーティションを利用するシーンもメディア作成ツールが公開されているおかげで思い浮かばないし、そもそもHDDがいかれしまえば回復パーティションも一緒にお星さまになるほうが可能性が高いし、今後もアップグレードのたびに同じことを繰り返すんだろうから、もう削除するだけにしちゃおうかなあ。

古いゲームはできなくなるし、相変わらずタブレットで使ってもらいたいのかPCでも使てもらいたいのかどっちつかずの半端なUIだし、OS入れ替え級の更新がWindowsUpdateでお気軽に適用されちゃうしで、なんだか迷走しているようにしか見えないんですよねぇ。
このままだと、やっぱりWindows11がリリースされちゃう事態になるんじゃないかなあ。

2015年11月16日月曜日

Cities: Skylinesをやってみた その3

ふと気づくと膨大な時間を費やしていて「自分はいったい何をしていたのだろう」と自問自答することがわかっているのにも拘わらず、やっぱり起動してしまうのは典型的な中毒症状なんでしょうね。

わざわざdespawnさせないmodを入れて数十キロに及ぶ渋滞を見事に解消できた瞬間の醍醐味はたまりません。

主に渋滞の原因となるのは道路も線路も貨物輸送です。
特に貨物駅前の渋滞は深刻になりがちですが、実は割合簡単に貨物駅前の渋滞は解消できます。渋滞してしまうのは主に

  1. 貨物駅から出た車両がスムーズに目的の商業施設に到達できずに途中で信号待ちや交通量の多い車線と合流させていて渋滞してしまう
  2. 輸入(市内移送を含む)に加えて輸出車両が多すぎて貨物駅への帰還と搬入速度が追い付かない
の2点が主な原因となりますが、項番1は単純に目的地近くまで遅滞なく到達できる道路を引けばそれでしまいです。というよりも、これを行うことがまず大前提です。なのでおいておくとして、深刻なのは項番2です。
こうなると貨物駅の増設が最も効果的ですが、小手先で何とかしたい場合は貨物駅へのアクセス口を若干工夫すると搬入速度が上がります。

例えば、以下のような直線道路に沿って貨物駅が敷設されている場合、計測してみると41両/毎分程度、貨物駅に入場できます(画面では速度3になっていますが、計測時は速度1でカウントしました)。
一方、以下のように搬入するトラックをなるべく減速させないように入口を工夫して計測してみると、47両/毎分まで搬入可能になります。
両者とも数回づつカウントしましたが、概ね誤差は0~1両でした。
20%弱の搬入量の向上が見込めますので、「あと少し搬入速度が速まればなんとかなる!」という場合には有効かもしれません。
ですが、やはり王道は輸出入量に合わせた貨物駅の増設ということになると思います。

まあ、道路は引き方次第で結構どうにでもなるのですが、貨物列車の渋滞はかなり厳しいです。
勿論貨客分離は当然のこと、さらに外部につながる貨物駅は限定する、渋滞した貨車が経路を分岐点を塞がないように線路を引くことを前提としていても、

たとえば、こーんなのや、

 こーゆーのや、
 こーんな具合に
画面が続く限りに貨物列車がイモムシの行列のように延々と画面に収まらない長さで連なってしまうと途方に暮れてしまいます。
まさに圧倒的な物量作戦で都市を破綻させる恐るべき事態に見えます。

しかし、原因は簡単で、貨物駅の荷捌き時間がかなり遅いにもかかわらず、一駅に集中させすぎているから列車を捌ききれずにこんなことが発生するわけです。

そんな時は、経路ツールmodで貨物駅から出場する貨物トラックが最も多く向かう先を調査して、その近くに貨物駅を設置すると、一気にイモムシの行列が激減します。

しかし、これらをすべて一つ一つ、地道に解決していった先に待ち受けるものがあります。
オブジェクト制限です。

たとえば、
左が本来の車両数、右が上限に達してしまった後spawnした車両です。
運転台がない電車が120km/hで疾走していきます。

貨物列車も同様です。貨車なんか1両も引いてないただの機関車が爆走してきます。
編成の長さゆえにあれほど苦しんだ配線なんぞお構いなしです。

結局こんなむなしい事態に陥ることが分かっているのに、やっぱりやってしまいます。
つくづく典型的な中毒症状を呈しているなあ、と我ながら思います。