Windows 10アップグレードテスト

Windows 10へのアップグレードにともなって気づいたことをいくつか。

初回起動時のブランクスクリーン

アップグレードによる初回起動時、「さぁ、はじめましょう」と表示されるが、そのあとブランクスクリーンのままになってしまう。

この問題は、4回アップグレードして

ちなみに、この現象は、Ctrl+Alt+Delでタスクマネージャーを起動し、CPUが落ち着いたところでもう一度CADを使ってログオフしてからログオンすれば改善する。

アップグレードに伴うプログラムの動作不具合

アップグレードしたWindows 10には動作不具合がある、という報告が多いが、手元の環境ではそれはなかった。

ただし、いくつか問題があった。

Catalyst関連

AMD Quick Stream Error 「権限情報がみつかりません」と言われる。

Catalystの入れなおしが必要だった。

また、Catalyst Control Centerを起動するように求められたりもする。ドライバは入れなおすのが無難に見える。

PeaZip

PeaZipのコンテキストメニューが開かない。

Google日本語入力

Windows 7のデフォルトのIMEによらずMS IMEに戻されてしまう。
コントロールパネルから戻せるのかもしれないが、一応FAQに従い再インストールした。

デュアルディスプレイ時のタスクバー

マルチディスプレイの場合、タスクバーはWindows 7ではプライマリディスプレイに表示するのが標準、Windows 10では全てのデスクトップに表示するのが標準で、変更されてしまう。

起動が遅い

遅くない時もあるにはあるが、遅い時は本当に遅い。

ようこそ画面がなかなか出ないなど問題もある。

ちなみに、起動全般インタラクティビティが損なわれており、結構不安になる。
情報が表示されないことは増えた。

終了処理

一見シャットダウンが完了したように見えても、実は終わっていなかったりする。

電源ボタンで強制シャットダウンされる状態になっており、次回起動時に正常なシャットダウンが妨げられたとみなされてしまう。
特に電源断を行っている人は注意。

Windows 7 64bit 古いソフトウェアの互換性テスト (主にエロゲー)

全体的な印象としては、

  • Windowsはよくがんばってると思う
  • しかし結構辛いものも多い。Windows XP 32bitは確保しておいたほうがよさそう
  • メジャーメーカーのタイトルは割とまともに動く。昔のエロゲーはお行儀の悪いプログラムが多い
  • Windows 10で動作しないプログラムは意外と少ないが、ないわけではない。

Lotus SuperOffice 98

動作しない

XGWorks 4.0

インストールできない。
動作はするらしい。

RPGツクール2000

問題なく動作する。

DESCENT

DOSBOXで起動。

CD-ROMのデータをハードディスク上のコピーして起動する必要がある。
実行ファイルはDESCENT.BAT

DESCENT2

DOSBOXで起動。

インストーラによりインストール、起動時はディスクを挿入、CD-ROMを

mount d d:\ -t cdrom -2

のようにマウントした上で起動する必要がある。
実行ファイルはD2.BAT

DESCENT3

通常通りインストールできる。
setupタブでサウンドカードとしてプライマリードライバーを選ぶ必要あり。
マウスの感度がよすぎるなど問題あるが調整可能。

リトルMyメイド パンドラボックス

起動自体はインストーラを含めWindows 2000互換モードで可能。
ただし、最小以外のインストールのためには、予め内容をハードディスクにコピーし、ハードディスクからインストーラを起動する必要がある。

Alive (Witch)

テキストが淡く表示される。

WHITE ALBUM (light)

Windows 2000またはXPの互換モードで起動しなければ画面が出ない

D+VINE LUV

Windows 7ではWindows 2000互換モードでプレイ可能だが、色がおかしくなる。色数の問題か。

Windows 10では起動するものの画面が表示されず、音も出ない。

ロマンスは剣の輝きII

Windows 2000互換モードで起動、プレイ可能

ぴあきゃろTOYBOX

Windows 2000互換モードで起動して設定した後、互換モードを解除し、視覚テーマとデスクトップコンポジションを無効にしてプレイ可能

虹色シーズンさりげなく

インストーラはWindows 95互換モードで実行する必要あり。
テキストが表示されないが、そういうものだっただろうか?

ぱすてるチャイム

問題なく動作する

プレシャスLOVE

管理者権限で実行する必要があり、Windows95互換モードが適切。
データをレジストリに保存するため、お行儀はよくない。

アージュマニアックス

問題なく動作する

Windows 10 テスト

アップグレード

Windows 10がようやくThinkPad e440に入ってきたので、テストした。

まず、事前にClonezillaでディスクイメージを獲得した上でアップグレード。
LUKSを使っていることもあり、Clonezillaは最適ではなかったように思われる。

アップグレードはシンプルで、タスクトレイのWindows 10アイコンから起動したら、あとは表示にしたがって進めていけばいい。
途中再起動しながら進んでいく。不安になるような場面もないではないが、Windows 7のインフォメーションの少なさからすればはるかにわかりやすいレベルだ。

アップグレードして起動すると、かなり時間がかかってからログオンスクリーンが表示される。
だが、ログオンすると黒い画面のまま長く停止する。タスクマネージャを見ていると、ずっとCPUはかなり高い水準にあり、その後落ち着いても変わらず黒いスクリーンのままだ。

なお、PID5の起動失敗がリポートされる。

しかし、再起動すれば正常に起動した。

Windows 10

RAMを予め8GBに拡大していたこともあって、Windows 10はさくさく機能する。
デスクトップテーマは「おおよそ」引き継がれ、ぱっと見の差異は小さい。また、Lenovoのアプリケーションはいずれも引き継がれ、タスクバーに鎮座する。

ショートカットキーが強化されたこと、タスクバーに検索が追加されたことでかなり使いやすくなったように感じる。
もっとも、私が入力中心の起動を元々していたからであって、スタートメニューから階層をたどる方法をしてきた人にとってはやりづらいかもしれない。
ちなみに、私はWindows 7ではLaunchyをメインに、スタートメニューを使う時は検索を使っている。検索は、それなりに速くなった。

Windows 8 (8.1) の絶望的な使いにくさはない。評判は悪いが、実際Windows 8よりは圧倒的に良いと思う。
これできちんと動けば、Windows 7よりも好きだ。

コントロールパネルが隠されたという点は好ましくない。
設定から遠ざけていることが問題ないのに、さらに遠ざける選択をしているからだ。
ショートカットキーを使うか、あるい検索によって見つけることができる。

やはりGodModeを使用することが望ましい。これは、コントロールパネルのフラットメニューのようなものだと考えていい。
godMode.{ED7BA470-8E54-465E-825C-99712043E01C}というフォルダを作ることでgodModeへのショートカットとなる。

Windows 10自体の印象はよく、

  • Audacity
  • ドラコンスピーチ11 日本語版
  • VLC Media Player
  • AIMP
  • XNViewMP
  • サクラエディタ
  • Opera Developer
  • Sylpheed
  • Skype for Desktop

の起動を確認した。

全体には良好なエクスペリエンスを得られるが、起動と終了は非常に遅い。
終了時は終了したと思っても、十胃は電源が切れていないことがある。

元々デュアルブートだった場合は、それは維持される。
グラフィカルな画面で良いが、そのかわり他のOSを選ぶと再起動されるようになった。
直接呼べなかったのかと疑問は残る。

  • DTM

問題はDTMだった。

Image-Line FL STUDIOは、12から正式にWindows 10をサポートしており、確認の必要がないと判断して確認しなかった。

US-366は既にWindows 10をサポートしているが、x64のフォルダにあるsetup.exeを使う必要があるのと、なかなか成功しなくて困ったりもした。

SONAR X3 PRODUCERはちゃんと起動するが、今回MelodyneとXLN Addictiveシリーズは検証しなかったものの、それ以外についても、SONAR X3 PRODUCERを入れた時点でプラグインは65であるはずだか、49しか認識されない。
少なくともBREVERBが認識されていないこと、x64かx86かは関係ないことを確認した。

ThinkPad e440 * Linuxの長い戦い

何を導入する?

e440の構成は以前はWindows 7とPCLinuxOSのデュアルブートだった。
その前はSabayon Linuxで、結構安定していたのだが、使いにくい部分があり、PCLinuxOSとなった。

これが潰されたのは、Windows 7の書き戻しのためだ。

その後、時間がなかったため放置され、今回再編成に伴ってWindows 7はそのまま修正することが決まったため、Linuxを導入することになった。

ところが、これが辛い道のりだった。

望ましい構成は

  • sda1 Windows booy
  • sda2 Windows System
  • sda3 /boot
  • sda4 Extended
  • sda5 truecrypt
  • sda6 LUKS LVM PV

というものなのだが、このためには

  1. /bootにPBRとしてGrubを導入できる
  2. 手動パーティショニングができる
  3. LUKS上にLVM PVが作成できる

という条件を満たす必要がある。
ところが、個々には一般的なことであるにもかかわらず、要件を満たすインストーラがない

  • Manjaro Thus : PBRインストール、LVMに対応しない。crypt swapでエラーとなる
  • Manjaro Calamares : LUKSに対応しない
  • Manjaro CLI Installer : UUIDで設定するが見つけられずエラーになる
  • Linux Mint : LVMに対応しない。複数のcryptデバイスを設定できない
  • openSUSE : PBRへのGrubインストールを無視する、エラー多数でうまく動作しない

困り果ててしまった。
途中、諦めてPCLinuxに戻ったりもしたのだが、AddLocaleが正常に動作せず、ほかを試し、結局3日ほどかかった。

この要件、自動インストールであればちゃんと動作するのだが、手動だとなかなか動かない。
インストーラの品質は難しいところなのか。

ちなみに、Manjaro 0.8.13においては、WiFiが接続はできるが、通信しているとストールしてしまうという問題も発生した。

セットアップ

結局うまくいったのはPCLinuxOSだった。(Reiser4が使えなかったりはした)
AddLocale周りの設定は、手順としては(@PCLOS 2014.12 KDE)

  1. インストール
  2. 初期設定
  3. アップデートとアップグレード
  4. 再起動
  5. Localization ManagerからのAddLocale
  6. リポジトリをJAISTに変更し、Tomcatさんのリポジトリを追加する。パッケージリストはリロードしておく。
  7. アップグレードしておく
  8. gsetime(入力メソッドの選択)でIMEにuimを選択する。uimは私の好みなのでscimやfcitxにしても構わない。i-busを使用する場合はTomcatさんのリポジトリの追加を忘れない

なお、解像度がどうしてもXGAになってしまうため、PCLinuxOS Control Centerで設定しておく。KDEの設定で設定しても再起動時には戻ってしまう。

uim

uimを選択したのは、元より日本人が日本語入力のために制作したもの(SCIMやfcitxは日本語のために作られたわけではない)であり、非常に軽量でセキュアだ。シンプルだが、「日本語を入力する」という観点から言えば最高だと思っている。

残念ながら開発が停滞し、国際的にも支持されていないことから消えそうになっている。
日本でもMozcがuimが使えない(そもそも、人気の高いUbuntuやFedoraが国際的なものでSCIM, i-bus, fcitxなどを採用する)といったことで使われなくなってしまっている。

SCIMやi-busと比べ、安定していて高機能なfcitxにさほど不満はないが、やはり私はuimが好きだ。

PCLinuxOSのIMEは、MozcにせよAnthyにせよ、入力効率は非常に悪い。
しかし、Tomcatさんのリポジトリを追加することで、入力効率に優れたかな漢字変換を使用することができるようになる。

野良版のuim関連のパッケージを一通り入れても、UIM appletは起動しない。
だが、uim-toolbar-gtk及びuim-toolbar-gtk3は存在するため、これを自動起動に追加すれば動作するようになる。

uimはWeb変換サービスに対応している。
Ubuntuにもuim-google-cgiapi-jp, uim-baidu-olime-jp, uim-social-ime, uim-ajax-ime, uim-yahoo-jpのパッケージが用意されている。
野良版uimはこれらも既にセットアップされた状態で提供される。

なお、uimだとkkcは利用できない。
kkc愛好家(いるのか?)の方はfcitxを使用すること。

野良版uimだと、公式のfcitx-mozcで生じるかな入力において「ー」が「ろ」になる問題、fcitx-anthyで逆に「ろ」が「ー」になる問題は解決されている。

sudoは

sudoはi586版だとspecialにあるが、x86_64版は普通にある。

サスペンド/ハイバネーション

e440だとサスペンド(スリープ)/ハイバネーションできない。ずっとファンが回っていてハードディスクの音がしているので、復帰できないのではなく、サスペンドに入れないのか。

Window decorationsをいじるとまずい

KDEのBTSにも記載があるけれど、ウィンドウの装飾を変更するとKDEが起動しなくなる。

~/.kde4/share/config/auroraercをトバすだけでは解決しないため、かなり厄介な問題になる。要注意。

Windows XPで一部のサイトにつながらない

うちにはWindows XPがある。
それどころか、実はWindows 98SEもあったりするのだが、こちらのXPはゲートウェイ接続で、実質、携帯万能が32bit Windowsのみの対応、しかもWindows 8は非対応ということから使われている。

しかし、この携帯万能が曲者で、まともに動かない上にバグっている。

送信メールがまともに取り込めないというトラブルに見舞われたのだが、トリスターは「特殊文字を使用したメールのせいなので、OSを初期化せよ」とか無茶なことを言ってきた。
絵文字すら使わない私が送信メールで一体どんな特殊文字を使うというのか。

だいたい、その場合にその後機能しなくなることを仕様として開き直るんじゃない、と思う。

まぁ、仕方がないので今回は応じて初期化しよう、というわけだ。

だが、いきなり問題が発生。いくつかのウェブサイトに接続できない。まず、Googleに接続できない。
接続できるサイトのほうが多いが、Amazonに関しては一見まともに接続できたかのように見えるが、結局おかしな画面になってしまう。CSSや画像が読めない感じか。

このために、携帯万能はAmazonで入手したのだが、ソフトウェアダウンローダは入手できるが、ソフト自体がダウンロードできない。

一見DNSの問題に見えるが、

> nslookup google.co.jp

では値は取れている。
随分と悩んだのだが、やがて「どうもSSLが原因ではないか」というところに思い当たった。
SSLの脆弱性への対応として旧SSLを受け付けないサイトが増えているので、接続できないのだろう。

じゃあ、プロキシ経由ならいけるのだろうか?と思い、

$ ssh -f -N -D 0.0.0.0:1080 localhost

としてWindows XPでSocksを設定してアクセスしてみたが、結果は変わらない。
そこでLinuxでIron PortableをダウンロードしてUSBメモリ経由で導入してみると、Googleにもアクセスすることができ、無事Google Chromeを入手することができた。

SSLの問題ということは分かったが、回避策はなかなか厄介。
Windows XP SP3での修正が期待されるが、そもそもWindowsUpdateをしようとするとIEでMicrosoftのサイトにアクセスするのだが、その時点で接続がはじかれてWindowsUpdate不能。

これでダメなら、ということでLinux経由でMicrosoftからWindows XP SP3アップデータを入手した。

そしてUSBメモリ経由で受け渡し(別にChromeが使える状態になっているので、SSHやFTP経由でも構わないのだが)適用すると、IE7のままではあるが無事にアクセス可能になり、解決した。

なかなか厄介な状態だが、これは一般のWindowserには厳しいのではなかろうか?
既にSP3の状態で使っている人は大丈夫だが、リカバリした瞬間に詰む可能性もある。
SSL問題がWindows XPに止めをさした形か。いや、それで世の中のWindows XPが滅びてくれるなら実に喜ばしいが。

しかし、フィーチャーフォンまわりはかなり厳しい状況だ…

ちなみに、同様の問題はLinuxにおけるPresto版Operaでも生じる。

Vine Linux (Seed)とWindows 7のデュアルブート構築と削除

ThinkPad e440がどんどん環境崩壊してしまい、使い物にならないため、再セットアップ。 考えられる原因が

  • TrueCrypt
  • Avast!

のどちらかなので、とりあえず暗号化なしでやってみる。

Windowsの再インストールについては何度か言及しているが、ディスクイメージを保存してあるので、いつもどおりSystemRescueCDでブートし、

ssh foo@192.168.64.128 cat e440.backup/e440.offset.xz | xz -dcv > /dev/sda
ssh foo@192.168.64.128 cat e440.backup/e440.1.xz | xz -dcv > /dev/sda1
ssh foo@192.168.64.128 cat e440.backup/e440.2.{0..8}.xz | xz -dcv > /dev/sda2

パーティションを調整する必要があったので、リサイズ。余計なsda3があったので、それを除去した上で実行する。

Windowsの再構築は結局一日ほどかかったが、環境として導入したのは、

* Immunet Antivirus
* ZoneAlarm Free Firewall
* Bonjour for Windows
* RLogin
* Opera Developer
* SRWare Iron
* Cyberfox Intel
* VLC Media Player
* AIMP
* Audacity
* XnViewMP
* Geany
* サクラエディタ
* Google日本語入力
* Launchy
* Geek Uninstaller
* Sylpheed
* Start Orb Changer
* MacType
* Skype
* Skype Call Video Recorder
* Free Studio
* DR-C125関連

今回は軽さを保つため、ウィンドウショッピングはごく軽く。しかしながら、実際はかなり重い。重くなった原因はむしろセキュリティ関連か?

Vine Linuxとのデュアルブート

Vine Linuxは7においてもUEFIには対応しないため、あくまでレガシーブートを使っていることが前提となる。

Vine Linuxでのデュアルブートのポイントは、

  • Disk Druidを用いて手動でパーティショニングを行う
  • /bootを別に切る(ほうが良い)
  • Grubは、sda(/bootのあるディスク)に対してインストール、高度なオプションを選択し、sda3に対してインストールする
  • ベースシステムのインストールでパッケージ基本構成を選択

MBR*レガシーブートの場合、Windows7は2つのパーティションを切っているはずだ。 sda1がブート関連、sda2がCドライブになる。

そこで、sda3をプライマリパーティションとして/bootに充て、sda4が拡張パーティション、sda5を/にする。 これ以上切る必要がなければsda5に全てを割り当ててもいいし、sda5をLVMにして、LVMタブで構成してもいい。

そして、/boot(sda3)に対してGrubをインストールする。 この方法が表面的に見えないが、「Grubの高度なオプション」として、次のステップで選択できるようになっている。

この状態でインストールを完了してもまだ起動できないため、SystemRescueCDで起動。

mount /dev/sda2 /mnt
dd if=/dev/sda3 of=/mnt/mbr.img bs=512 count=1	

そして再起動してWindows起動。

bcdedit /create /d "VineLinux" /application bootsector
bcdedit /set {<entry>} device partition=C:
bcdedit /set {<entry>} path \mbr.img
bcdedit /displayorder {<entry>} /addlast

<entry>は1つ目のコマンド実行時に表示される。

デフォルトで30秒あるから、という記事もみかけるが、これだと一瞬で決定されてしまい、操作できなかったので、

bcdedit /timeout 30

で30秒にする。

これでVineLinuxが起動できるようになる。で、Seed化とGUI化

おおよそ手順通りに、

export LANG=C
/etc/init.d/network start
apt-get update && apt-get upgrade
sed -i 's/6/VineSeed/g' /etc/apt/source.list.d/*
apt-get install apt-libxml2

Xのインストールよりも先に更新しておかないとコケる。

apt-get update && apt-get dist-upgrade
apt-get install task-xorg-x11 task-mate lightdm

これでまぁいけるのだが、いくつか追加

apt-get install fcitx-mozc task-kde

inittabの修正

cp -p /etc/inittab /etc/inittab.orig
cp -p /etc/inittab.sysv /etc/inittab
vim !!$

コピーしただけではランレベルは修正されていなかった。 なお、ベースシステムでインストールすると、ログイン時はキーボードがUSなのは仕様。

で、ここまでやったのだけれど、SeedのカーネルでもThinkPad e440のワイヤレスネットワークアダプタをサポートしていないので、結局断念…

bcdedit

これで目的のVine Linuxエントリを確認

bcdedit /delete {<entry>}

で削除できる。

コンピュータのプロパティからでもいけるよ、という話もあるようだ。

ところが

やっぱりDR-C125は認識されたりされなかったり。 というかほとんど認識されない。 ログオンしてもまっくらなままでログオンできないことが多い。 非常に不安定だ。フリーズや、Explorerの停止もよく出る。

Explorer停止に伴って再起動したところ、

Windowsの機能を構成する準備中

でパーセンテージ表示。 再起動すると

23799個のうちn個目の更新を適用中

という。

なんだこれは。

しかし、まるで普通に更新したかのように普通に立ち上がり、それ以降振る舞いは改善されたように見える。 これでWindowsが崩壊するようだと、なかなか困る。

悪いのはMicrosoftか。Lenovoか。

アメリカか。中国か。

Manjaro 0.8.13 LXQTを入れてみた

という理由でうまくいかなかったので、デスクトップと同じくArch派閥のManjaro Linux 0.8.13を入れてみた。

LXQTは古いコンピュータも活用できる軽量版で、軽量デスクトップ環境として人気のLXDEのQt portsだ。LXDEと同様の思想のQTデスクトップ環境を開発していたRazor-qtと合流し、LXDEはGtk+2バージョンをしばらくメンテナンスした後に、LXQtに統合されることになっている。

つまり、現在はGtk+2のLXDEと、Qt5のLXQtの2つがあるが、LXQtはLXDE Nextでもあり、徐々にLXDEは削除され、LXQtになるということだ。 LXQtがLXDEの後継である、ということでもある。

LXQtのコンポーネントは、多くがLXDEのPortsだが、LXTerminalをやめてQTerminalを採用している。

ちなみに、洪任諭氏がLXDEを離れてLXQtに移ったのに対して、LXDE開発チームは、むしろ活発にLXDEを開発し、洪任諭氏とは袂を分かち、LXDEを存続させる動きもみえる。 そのため、LXDEの存続が発表通りになるかはわからないし、LXDEユーザーがLXQtにうつるかもわからない。

LXQtは現在のところ、LXDEよりも、そしてXFceよりも重い。 XFceが意外とリソースを使うため、MATEよりも、そして場合によってはCinnamonよりも重いということになる。 もっとも、これは起動時に限ったことであり、必ずしも使っていて同様の体感が得られるわけではない。実際、XFceは結構軽い。

Manjaro 0.8.13 LXQtの導入については、手動ディスクパーティショニングを行うのだが、うまくいかなかった部分がある。

  • Thusインストーラは手動ディスクパーティショニングでLVMが使えない。
  • Swapパーティションを暗号化すると起動時にディスクを見つけられずエラーになる
  • 既存パーティションをフォーマットしようとすると失敗して書き込めなかったりおかしくなったりする。基本的にパーティションを消して作りなおす

既存パーティションに書けないというのは、前方に配置してしまうとインストールできないということになる。なかなか厄介。また、Swapパーティションが暗号化できないのもセキュリティ面では結構痛かったりする。 Windowsも暗号化されていない現状のため、看過するほかない。今までのところ完全なソリューションを提供したのはPCLinuxOSで、openSUSEも恐らくは問題ない。 openSUSEは安定した、完全なソリューションであることが多い。 ただし、openSUSE 13.2は不完全さが目立つと言われている。また、openSUSEはかなりパッケージは多いものの、割とstrictなOSSポリシーのため外部リポジトリに依存する部分が大きい。Factoryを使うのはかなり限定的な使用になり、望ましい環境さえ作れればArchほどの快適性はない。

どのようにするか、ということが決めかねるので現状このままとし、Windows10にするのであれば(EFSが使えるようになるので)Windows7は旧来の方式に戻して、Windows10にアップグレード、LinuxはopenSUSEを選択。 もしそこでUEFIへの変更が叶うのであれば、Manjaroでも問題ない。

とりあえず、バックアップの上でManjaro GrubをPBRへインストールすることを試みてみようと思う。

update-grubが何を対象にするかが心配なところ。

PureBuilder2 (2)

Kramdown拡張でPDocオブジェクト化

PureBuilder2はもともと思っていたよりもかなり大規模なものになっているが、MarkdownオブジェクトをPureDocと同様に扱えるようにする、というのが今回のテーマ。

例えばテンプレートで

DOC.body

のように書かれている場合がある。この場合は当然、HTMLへ変換したのであればHTML文字列が得られなくてはいけない。 また、

DOC.meta["title"]

のようにもアクセスできる。 それだけなら単にアクセッサを拡張してやればいい話なのだが、PureDocオブジェクトはTOCのためのループ機能が組み込まれている。 これにより章立てをループさせることができ、簡単に任意の形式でTOCを組める。 これはどうしてもパース時に情報を取らなくてはいけない。

もし、HTMLに出力するものである、というのであれば、単純に結果のHTMLをパースして取得する方法もある。 だが、KramdownライブラリはLaTeXとPDFをサポートする。PureDocもゆくゆくはLaTeX形式での出力をサポートする予定である。

であれば、やはりKramdownでのMarkdownパース時にTOCを作りたい。

基本的な方針としては、実際にPureDocオブジェクトを使用する。 これはパーサ/コンバータを含まないベースクラスで、本来は直接このクラスのインスタンスを生成することは想定していなかった。 だが、外側から使用するメソッドは一通り持っており、インターフェイスは揃っている。

DOC.bodyで返すべき@bodyDOC.body=を用いて入れ、DOC.metaに関してはPureDocクラスが持っている機能によってドキュメントから取り込むといったことが可能。 そのため、DOCPureDocインスタンスであり、Kramdownの結果はDOC.body=によって入れるだけだ。

だが、DOC.stock_ehaderを用いてヘッダを入力し、TOCを生成できるようにしなければいけない。 そこで、Kramdownに手を入れる必要があった。

ソースコードを追っていったが、結局Kramdown::Parser::Kramdown#new_block_elをオーバーライドするのが良いと分かった。 ヘッダを取得するパートはあるが、new_block_elメソッドはメソッド自体が短く、あくまでパース時に各エレメント対して呼ばれるものだ。何のために呼ばれているかを判定する必要もなく、引数を丸々渡すだけで良いため、overrideしやすかった。

require 'kramdown'

# Override Kramdown
class Kramdown::Parser::Kramdown

  alias _new_block_el_orig new_block_el
  

def new_block_el(*arg)

   	if arg[-1].kind_of?(Hash)
    
      case arg[0]
      
      # Is Header?
      when :header
        p arg[-1][:level]
        p arg[-1][:raw_text]
      end
      
    end
    
    _new_block_el_orig(*arg)

end end

p Kramdown::Document.new(ARGF.read).to_html

というテストコードを書き、実際に動作することを確認、when :header部分を

::DOC.stock_header(arg[-1][:level], arg[-1][:raw_text])

と書き換えた。

KramdownはPure Rubyで書かれているため、扱いやすいし、ソースコードを書くのも楽だ。 だが、できればサブクラス化するなど、もう少しスマートな方法でできればよかったな、と思う。クラスが細かく分割されて連携しているため、置き換えるのはかなり難しいと判断した。

Kramdownは非常に良いライブラリなのは間違いない。

forkの代わりに

RubyのKernel.forkをはじめとするfork機能(例えば、IO.popen-を渡すことを含む)はWindowsでは動作しない。 Perlerだった私としてはこれはかなり不満な点だ。Perlはコミュニティの努力により、forkがWindows上で動作する。これは、Windows版Perlではforkをエミュレートするためだ。

今回は、設定やドキュメントオブジェクトなどをセットアップした状態で、forkによって環境を独立させたいと考えていた。 これはグローバルなオブジェクトに変更を加えるためであり、また出力先の制御をSTDOUT.reopenによって行うことができるかということについて考えていたためだ。

RubyのforkとWindowsについて検索すると、「forkは邪悪だ、threadを使え」という内容があふれる。 だが、今回は並列化のために使いたいわけではないため、Threadは用を成さない。

また、大量のドキュメントを変換する際のオーバーヘッド低減という目的もある。

Unicorn(Webアプリケーションサーバー)がこのforkによるCOWを活用した設計となっている。Unicornはどうしているのかと調べてみたら、UnicornもMongrelもWindowsでは動作しないらしい。

というわけで、forkの利用は諦めて、グローバルな名前に対する変更をいなす方向とした。

グローバルな名前のオブジェクトが変更されるのは、ほとんど

DOC.is {
...
}

という書式で記述するためだ。 これはPureDocドキュメントを分かりやすく記述するためであり、実際にテンプレートもDOCオブジェクトを利用したデザインとなっている。 つまり、DOCはthe PureDoc objectであることを期待している。

この設計を維持するため、Delegateライブラリを使用することとした。 実体はDOCではなく、DOCはただのDelegatorというデザインだ。これはDOCに実体はなく、ただの代名詞となるわけだ。

DOC = SimpleDelegator.new(nil)

とすることにより、まずDOCという名前を用意しておく。 実際に新しいドキュメントを生成する場合は、

::DOC.__setobj__ @@config[:puredoc_class].new

のようにする。 これにより、DOCが意味するドキュメントを入れ替えることができ、DOCを変更しても、変更されるのはDOCではなく、移譲されているドキュメントであり、DOCをまた新しいドキュメントにすることもできる。

Windows10への自動アップグレードとその意図

アップグレードとその拒否

Windowsは最新のWindowsである、Windows 10のデビューが迫っている。 今回はMicrosoft社がWindows 7/8/8.1からのWindows 10への更新の無料パスを用意するなど、「Windows 10への更新」を望んでいることが伺える。

Windows 10への更新は、「用意ができ次第、順次バルーンヘルプによって通知される」。

用意ができ次第というのは、Windows 10がリリースされ次第という意味ではなく、アップグレードを許すフラグが立てられてからだ。 パッケージWindowsを利用している場合、おそらくはリリースされ次第告知される。 一方、メーカーから購入したプリインストールWindowsを使用している場合、メーカーが検証を完了し、Goサインを出した時に更新される。

この更新を確認・通知するための更新は、Windows 7がKB3065987、Windows 8/8.1はKB3065988として提供されている。この更新を適用すると、通常の更新にWindows 10へのアップグレードが含まれるようになる。 アップグレードを入手し、アップグレードを促すところまでは、半自動で行われる。

その拒否方法はAsk COREで紹介されている。

これを適用した後、その適用(つまりWindows 10になる)は手動でGoサインを出さなければ行われない。(Get Windows 10というソフトで行われる)。 しかし、これは「うっかり」やってしまう可能性は大いにあり、かつ将来的に強制される可能性もある。 現時点ではWindowsのパッケージまたはライセンス販売を優先することと、急速な移行を狙って期間限定であるとしている。ただし、MicrosoftがWindows 7/8/8.1への残留を望まない気持ちのほうが強くなれば、これを延長して強制することも考えられる。 現在は更新の強制よりもWindowsを販売することを優先しているようだ。

意図の推測

Windows 10はMicrosoftが「最後のWindows」だとしている。 事実上ローリングリリースとなり、常に最新のWindowsが保たれる。例えばWindows 7→Windows 8のような変更はそもそもなくなり、毎日少しずつ変化し、やがてWindows 8になっている、という感覚に近い。

このようにするのは、検証・サポートコストの低減のためだ。 複数の状態を維持していると、そのサポートにも検証にも、コストと時間がかかる。 特に古いものを現状に合わせるというのは非常に困難であり、もちろんコストもよりかかるため、新しいものを出すよりもずっと負担が大きい。場合によっては競争力を失う結果にもなる。 リソースが少ない場合は、最新版以外は面倒を見ない、とすればそれなりにの競争力と品質を保つことができるる

ここに近づけるためのWindows 10のローリングリリース化である。 将来的なオープンソース・ソフトウェア化に言及するなど、Microsoftがその企業規模を以ってしてもWindowsの開発、保守が破綻しそうなほどに膨らんでいることが伺える。

だが、Microsoftにはかなり迷いがあるようだ。 よりオープンで、誰もが使えるインフラにしようとしている一方で、その収益やモデルを変更することを拒否する姿勢も見える。 現在までを見る限り、その体制変更は「変化の兆し」として歓迎されてはいるものの、それ以外については全てが悪化していると見られている。

自由や公開が不十分であり、利益の確保と強権の行使が過剰である。 どの立場からも激しく批判されているのが現状だ。

実際にMicrosoftにとってWindowsは大きなビジネスだ。 Windowsの売上の割合は意外と小さく、Microsoftのクラウドシフトによりさらに小さくなっている。 だが、Windowsの販売不振が業績に響く程度には大きい。それを手放す勇気がないのだ。

さらにWindows 10はHome editionに関してはWindows Updateの調整ができなくなる。 常に強制ダウンロード、強制適用である。 この強制がシャットダウン時などユーザーを妨げることなく行われるという情報もない。現在の自動適用と同様に、作業中でも構わずダウンロードし、適用した上で突如として再起動される可能性が高い。

さらに、Windowsの開発体制の変更に伴い、「アップデートを適用すると軌道できなくなる」というトラブルの発生頻度が激増している状況下だ。 Windows 10になると、おそらくこの頻度はさらに増加すると見られる。Arch Linuxのようなローリングリリースディストリビューションで言うところの、TestingあるいはUnstable相当の体制であるため、その頻度は高止まりするだろう。

これを強制するというのは明らかに非常に問題がある。

Windows 10をライブアップグレードにしたのも問題だ。 更新が破損することは、Windowsでは「よくある」。 実際、私のThinkPad e440は、初期化してもアップデートに必ず失敗する。そのため、Windows 10が降ってきても更新できないし、そもそも降ってこない。

かなり迷走していると見られる。 そもそも、今回アップグレード/アップデートの延期機能があるのはエンタープライズユースのもののみで、一般ユースのものはそれらは「強制する」という。 これらの情報もしょっちゅう変わっているが、Windowsを安定したインフラとして使いたい層はかなり多いはずであり、動かなるリスクを冒してまで最新の機能を求める層はWindowsにおそらくそこまで多くはない。 その選択権を剥奪するのが妥当なことだとはとても思えない。

WindowsはパソコンOSのデファクトスタンダードとしての自覚と責任を求めたい。 面白く革新的であることが求められるのは挑戦者であり、基盤であり標準となるものであれば、常に安定して使えるものであるべきだ。 一部のユーザー、特定の使われ方のみに適合するOSは標準としてふさわしくない。 また、行政などがMicrosoft製品を強要する社会的状況も早急に改善してほしいと思う。

適切な対応は

Windows 10のカーネル上の変更点は大きく、周辺機器が動かなくなる可能性はかなり高い。 出たばかりのホットなデバイスであればおそらく近い将来Windows 10に対応するだろうが、旧型デバイスだと期待薄だ。 私が使用しているスキャナー、プリンターもおそらくはダメだろう。

さらにソフトウェアが動かない可能性も高い。 私の場合、仕事で使っているソフトウェアがアップグレードするのも結構しんどい、SONAR PRODUCER, KOMPLETE ULTIMATEがある。 完全に動かなければ、アップグレードには10万円程度は必要になる。 FL STUDIO SISGNATURE BANDLEはライフタイムアップグレードに救われるが、ドラゴンスピーチの対応も疑問。

このあたりを考えると、デスクトップは更新しないことになるだろう。 特に新しいソフトウェアを導入する予定もないため、Windows 7のサポート切れ(2020年1月14日)まではかなりあることから、そのまま維持することになる。 新しいソフトウェアが動作しないようであれば、システム全体のアップグレードを検討する。 音楽関連ソフトウェアは集中させるしかないため、Windowsの更新を行うのであれば、全体を上げるしかない。 その際に対応できないソフトウェアは切り捨てられることとなる。既にWindows 7でXG Worksは動かなくなっている。

比較的無難な対応としては、Windows 7/8/8.1でアップグレード前にディスククローニングしておき、Windows 10にアップグレードしてさらにディスククローニングする、という方法だろう。

グレード間の巻き戻しをライセンス的にMicrosoftが許容するのかがわからないが、これであればWindows 10で動作しなければWindows 7/8/8.1のクローンを用いて巻き戻し、Windows 10移行に適切な時期が来た時にはクローンを用いてWindows 10を書き戻すことで、無償期間後にもアップグレードすることができる。

Microsoftが煽るほどにはWindows 10へのアップグレードは勧められない。 プレビューでもかなりの不具合が報告されている。趣味ユーザーであれば試してみるのもいいかもしれないが。

もう少し言うのであれば、Windows 8/8.1ユーザーは無条件にアップグレードしても良い、という意見も見る。 一方、Windows 7ユーザーはアップグレードは控えたほうが良い、ということだ。

なお、サポートが終了しているWindows XPと、延長サポート終了が近いWindows Vistaは無償アップグレードから外されている。 Windows 10はWindows Vistaが余裕をもって動くコンピュータであれば性能的には動作する可能性が高いが、これはMicrosoftの経営上の判断だろう。

Windows 10 previewからもWindows 10にアップグレードすることができるが、これにはWindows 7/8/8.1のライセンスでアップグレード認証したものだけであり、Windows XP/Vista、非正規Windows、Windowsなしコンピュータからのアップグレードはできない。

hp pavilion x2 10 修理へ

hp Pavilion x2 10のカメラが動作しないために、修理送りとなった。

Skype for Windows Desktop起動時に「全面緑」で動作しない。カメラはインジケータランプはついているのにだ。 Firefox Helloで試すと真っ白。

そして、今回はチャットサポート。 前回と同じ方の対応で、やりやすかった。

「カメラ」アプリでテスト、ドライバ削除からの再起動、BIOSリセットからの再起動と試したものの改善せず、引き取り修理へ。

ついでに、先の液晶の傷?問題も見てもらうことに。

2時間もお付き合いいただき、ありがとうございました…

しかし、私、ハードウェア不良ひく確率高くないか。先日もカメラ初期不良で送ったばかりだし、その前はThinkPadをファクトリー送りにしたし、電熱スリッパも送ったし、なんか憑いてる。

Windowsのセットアップ

問題点

WindowsUpdateでコケてまともに起動しなくなったWindowsをリカバリし、まっさらにした。

だが、やはりWindowsUpadteでコケる。かなり慎重に行ったが、それでもコケる。

updateを終了してリブートすると15%まで進行したあと数時間停止、 その後ようやく再起動して構成して再起動(これもかなり長い。ステージ)、5/5になっている。 構成して、構成に失敗したので戻すとして再起動、 そして戻すとして数時間にわたって待たされた後再起動。 そして構成を戻すとし、1回目はステージ5/5の35%から構成して、2回目はそのままログオン画面へ。

見てみると117個中97個、x64 based systemとある修正と、同じ記載のある.NET FrameWorkが全てコケている。2回実行したが、結果はこの通りだ。

そもそも、WindowsUpdateの最中に自動スリープするというのは相当おかしいし、 Update中のネットワーク断(うちではしょっちゅう起きる)や電源断も想定して叱るべきだろう。それでシステムが壊れる設計というのはイカれてる。

セットアップ

まぁ、もうUpdateは諦めよう。近く10が来るのだし。

まず、いつも通りTrueCrypt.chによるドライブ暗号化。

導入するソフトは順序はそれほどない。

カテゴリ ソフトウェア
ウェブ Cyberfox, Opera Developer, SRWare Iron
メール Opera Mail
Twitter TweetDeck, V2C
2ch V2C
エディタ UnEditor, SakuraEditor
マークダウンエディタ Markdown#Editor, HarooPad, CuteMarkEd
オーディオ AIMP
ビデオ VLC Media Player
マルチメディア Free Studio
IM Skype
IME Google日本語入力
アンチウィルス Avast!
アンインストーラ Geek Uninstall
ランチャ Launchy
SSHFS Win-SSHFS
端末 TeraTerm
VSパッチ UXThemePatcher

これはWindowsを単独で使う想定ではなく、なるべくサテライトとして、ここにデータをためずに使う想定だ。 だから、ソフトウェアもそれなりに絞っているし、データは主にsshfsを介する。

だが、これだけやるとWindowsでも結構使えるようになる。

VSとフォント

ビジュアルスタイルに関しては、FunkVSを使用したのだが、フォントがかなり多岐に渡って変更される。この影響は大きく、「どこの部品にどこで定義されたフォントが使われるか」ということも変更されるらしい。

色とデザインの詳細から設定できない部分のフォントに日本語でないフォントを設定されてしまい、Operaではアドレスバーとタブに日本語が表示されなくなった。豆腐になる。

Funkはかなり気に入っていたのだが(特にサブメニューが網掛けで表示されるのは凝っている)、この問題は様々なところに影響を及ぼすため、Skylim VSに変更した。

加えてWindows7 Start Orb Cahngerを使ってstart orbを変更していっちょできあがり。

もちろん、事前にフォントの導入は済ませてあり、またMacTypeも導入してある。壁紙やフォント設定も行った。