そろそろ VMware はやめたいのですが、細かい要件まで含めるとすべての条件を満たす代替手段をまだ見つけられていないためだらだらと使い続けているところです。（とはいえ当の VMware 自体もクリップボード共有まわりが壊れてきていて要件は満たさなくなってきているんですが）

続きを読む

年末が近づくにつれ今年の残り日数の少なさに唖然とすることが増えてくるわけですが、だったらナノ秒単位にして桁数を増やしたらショックも少ないのでは？と思い、今年の残りナノ秒数を表示するページを作ってみました。 https://peta.okechan.net/test/remaining-nanosec/ 景気の良い桁数になりましたが、減る勢いも景気が良すぎて結局ショッキングですね… （多分）2017年最後のコードになります。

続きを読む

昔バイトニックソートについて書いた記事を読んでたところ、「そうだ、可視化してみよう」と思いついたのでやってみました。 検索すると同様のものはゴロゴロ出てきそうですし、自分でやる必要なかったかも。 バイトニックソートの可視化(別ページ)

続きを読む

それなりにユーザー数が多いと思われるとあるサイトにURLを手打ちしてアクセスしたところ、何故かWordPressのインストール画面が表示されました。 URLをよく見るとディレクトリ名のところを1文字打ち間違ってしまっており、正しいURLを入れ直すことで目的のページは表示できました。 WordPressのインストール画面については、「そのサイトの人がWordPressを試そうとした瞬間をたまたま偶然私が目撃してしまっただけだろう」と最初は思ったんですが、数日経ってもそのまま… これはめちゃくちゃ危険です。 どのくらい危険かと言うと、サーバーのSFTPやFTPSのログイン情報を誰でも閲覧できる場所に公開しているのと同じくらい危険です。

インストールを完了しないまま放置したWordPressはなぜ危険か

例えば悪意を持った人(以下、攻撃者)がWordPressのインストール画面を発見したとしましょう。 すると攻撃者はこんな画面を見ることになります。 WordPressインストール時のおなじみの画面ですね。 そしてボタンをクリックして次へ進むと、データベースの情報を入力する画面になります。 すると攻撃者はデータベースの情報を入れてみるわけですが、そのサーバーのlocalhostで動いているデータベースのユーザー名とパスワードを総当りで試してみる…なんてまどろっこしいことはしません。 なぜなら別にlocalhostである必要はないからです。 攻撃者が自分でデータベースサーバーを用意すれば、何度も試行する必要なく一発で次のステップへ進むことができます。 例えば攻撃者が自前で blah.example.com というデータベースサーバーを用意し blah_db データベースと、それに接続可能な blah_user(パスワード、blah_blah) というアカウントを用意したとしましょう。 すると上記の画面では上から順に、 blah_db, blah_user, blah_blah, blah.example.com と入力するだけでこのステップをパスすることができます。 (blah.example.com なんて名前で名前解決できる必要はなく、直接グローバルIPアドレスを入力してもよいです) 攻撃者が上記の画面をパスした後の話は簡単です。 攻撃者はWordPressのインストールを完了させることができますし、管理画面にログインすることもできます。 管理画面にログインできるということは、zipファイルで固めたWordPressのプラグインのアップロードもできるということです。 もちろん攻撃者ですから、害のないプラグインはアップロードしません。 悪意のあるPHPスクリプトを含んだプラグインをアップロードします。 そしたら攻撃者はアップロードしたプラグインに含まれる悪意のあるPHPスクリプトに直接アクセスすることで、攻撃対象のサーバー内で自由にPHPスクリプトを実行することができます。 PHPの実行時の権限でできることは全てできるということになります。 例えば、サイトの「インストールを完了しないまま放置したWordPress”以外”の部分」を好きに書き換えたり、ファイルを消しまくったり、個人情報があればそれをいとも簡単にぶっこ抜くことができます。 スパムメールも送りまくれますね。 サーバー内で好きにPHPのスクリプトを動かせますのでたいていの事はできます。 先に書いたとおり、「サーバーのSFTPやFTPSのログイン情報があれば出来ること」の全てとほぼ同じ事を攻撃者が実行出来るということになります。

インストールを完了しないまま放置したWordPressは攻撃者に発見されるか？

上記のとおり、インストールを完了しないまま放置されたWordPressは、攻撃者にとってはめちゃくちゃ美味しいと思われるので、探し出すためのbotなんかもそれなりに存在すると思われます。 というか試しにうちのサーバーのログを調べたところ、その手のbotっぽいアクセスがすぐに見つかりました。 ありがちな名前でディレクトリ名を変えながら、WordPressインストール中に使用されるwp-admin/setup-config.phpに対しアクセスを試みてる感じでした。 例えばディレクトリ名をパスワードっぽい複雑な文字列にする、とかすると攻撃者に発見される確率を減らせるとは思いますが、ブラウザの「脆弱性もしくは悪意のあるプラグイン」から漏れたりとか、他にも色んな要因で漏れる可能性があるので、WordPressをインストール完了しないまま放置、なんてことは絶対にしないほうが良いと思います。 といってもだいたいそういうのって、意図的にというより本人が忘れててということがほとんどだと思います。 この記事を読んで思い当たるフシがありましたら、確認することを強くおすすめします。 ちなみに、冒頭に書いた「とあるサイト」については報告し、その後対策(WordPressを削除)されたことを確認済みです。

続きを読む

ということで、とりあえず手順だけのっけておきます。 純粋により多くの人に試してみて欲しいなと思ったので書きました。(簡単ですし) 内容は雑ですが、ある程度PCに慣れている人なら迷わずに実行できるくらいにはキモをおさえたつもりなので是非。 多分1時間くらいあればビルド開始するところまで十分進めれるかと。 Windows 10 Creators UpdateのWSLを使う前提で説明してます。

手順

WSL(Bash on Ubuntu on Windows)のインストール

コントロールパネル → プログラム → Windowsの機能の有効化または無効化 Windows Subsystem for Linux(Beta)にチェックを入れて「OK」を押す。 すると多分再起動を求められるので再起動する。 再起動したらコマンドプロンプトを開き bash と入力してエンター。 そうすると多分開発者モードを有効にしろ的なメッセージが出るので 設定 → 更新とセキュリティ → 開発者向け 開発者モードを選択すると、1分くらい？何かインストールしています的なメッセージが出た後、開発者モードが有効になる。 そしたら、もう一回コマンドプロンプトから bash を起動し、メッセージに従って進めていくと Ubuntu on Windows がインストールされる。 終わったら、コルタナさんのところに bash と入力すると Bash on Ubuntu on Windows が出て来るのでそこから起動できる。

ビルド環境の用意(全てBash on Ubuntu on Windowでの作業)

Bash on Ubuntu on Windows のウインドウのタイトルバーを右クリックして出てくるコンテキストメニューから「プロパティ」をクリックし、「オプション」タブの「簡易編集モード」を有効にすると右クリックで Bash on Ubuntu on Windows にペーストできるようになります。 apt の利用リポジトリを日本(JAIST)のサーバーに変更(パッケージダウンロード時間の短縮のため)

sudo sed -i.bak -e "s%http://[^ ]\+%http://ftp.jaist.ac.jp/pub/Linux/ubuntu/%g" /etc/apt/sources.list

linux のソース等をダウンロード可能にするためのリポジトリを追加

sudo su -c "grep '^deb ' /etc/apt/sources.list | sed 's/^deb/deb-src/g' > /etc/apt/sources.list.d/deb-src.list"

リポジトリのデータベースを更新

sudo apt update -y

とりあえず既存のパッケージを更新

sudo apt upgrade -y

カーネルのビルドに必要なパッケージのインストール

sudo apt build-dep -y linux
sudo apt install -y libncurses5-dev

Creators Update 以前から Bash on Ubuntu on Windows を使っていた環境では apt build-dep が実行できないかもしれません。その場合はこちらの方法で WSL を再インストールすると解決できるかもしれません。(再インストールするともちろん WSL 内の環境が消えますので注意) linux のソースコードを取得

cd
mkdir linux.ubuntu-16.04
cd linux.ubuntu-16.04
apt source linux
cd linux-4.4.0
chmod -R u+x debian/scripts/*
cp debian.master/changelog debian/

カーネルコンフィグ

make menuconfig

TUI(Text User Interface)が表示される。 こんな感じでちょっと崩れた感じで表示されるかも。 右矢印キーを1回押し、 Exit がハイライトしたらエンター。 そのまま Yes がハイライトされている状態でエンター。 無限ビルドスクリプトのダウンロード

wget -O do.sh https://gist.githubusercontent.com/satoru-takeuchi/23afbf565c2d97c3ef16e5d46d11f5bf/raw/f7098d66a6df3b118d8906aa08eafd2ef1b797ee/ryzen-problem-repro3

スクリプトの中身が下記と同じになってるか一応確認

#!/bin/bash

export LANG=C

if [ $# -ge 1 ] ; then
  CONCURRENCY=$1
else
  CONCURRENCY=16
fi

for ((i=0;1;i++)) ; do
  if make -j$CONCURRENCY >/dev/null 2>>log.txt ; then
    echo "$i: $(date): OK" >>log.txt
  else
    echo "$i: $(date): NG" >>log.txt
  fi
  dmesg >dmesg.txt
  make clean >/dev/null 2>>log.txt
done

※このスクリプトは satoru-takeuchi 氏が書いたのもです。 ryzen-problem-repro3 · GitHub 無限ビルドの実行

bash do.sh

確認

無限ビルド中の Bash on Ubuntu on Windows のウインドウを開いたまま、別の Bash on Ubuntu on Windows を起動し、このコマンドを実行。

tail -f -n 10000 linux.ubuntu-16.04/linux-4.4.0/log.txt | grep -e '^make' -e '^[0-9]\+:'

※ grep はコンパイラの警告などを取り除くために使ってます。 Bash on Ubuntu on Windows のタイトルバーを右クリックして出てくるコンテキストメニューの「プロパティ」から「レイアウト」タブの「画面バッファーのサイズ」の「高さ」を 9999 とかにしておくと出力が長くなってもスクロールバックして確認できます。 これであとは、ビルドが終わる度にビルド回数と日時と OK/NG が表示されます。 8コアRyzenならだいたい4分前後で1回のビルドが終わるようです。 うちの場合は、最初に実行したときは30回を待たずして2回 NG が出ましたが、次に実行したときは93回目にしてやっと NG が出る、という感じで再現頻度はかなりランダムな感じです。 特に2回目の実行のときは371回まで回しましたが、途中200回以上(時間にして約14時間もの間) NG が出ないという事もありましたので、運が悪い(良い?)と数百回まわしても再現しないという事もあるかもしれません。 私のスタンス的にはRyzenに問題があると主張したいわけではなく「正直良くわからない」という感じです。 Windows 10 Creators Update も WSL もまだ全然枯れていないソフトウェアですし、Ryzen以外のハードウェアの問題かもしれませんしね。 また、恥ずかしながら低レイヤを深く調査するスキルもないですし。 さらに言うと、WSLでビルドに失敗する件が、話題の実行命令64バイトズレ問題や実際のLinuxのgcc等でSEGVする問題との関係があるのかも私にはよく分からないです。 ただ、このままだと本格的に実戦投入するのは怖いので(軽めの用途で半分くらいは実戦投入してるんですが)何らかの形で解決して、少しでも早くRyzenライフをエンジョイできればいいなと思っています。 追記 [WARNING] Intel Skylake/Kaby Lake processors: broken hyper-threading という話が出てきました。 IntelのSkylake世代のCPUとKabylake世代のCPUにHT(ハイパースレッディング)関係の問題があって、HT有効だとOS問わずデータ破壊の可能性があるという話です。 盛り上がってまいりました！ さらに追記 Intelの件の日本語の記事が出ました。 Skylake/Kaby Lakeでシステムクラッシュを引き起こすエラッタが発見。BIOS更新が必要 – PC Watch BIOSアップデートで修正されるみたいですね。 AMDのほうも、もし原因の一端がCPUにあるのであれば、このくらいの説明は欲しいところです。

参考

Tech TIPS：Windows 10のBash on Ubuntu on Windows環境を初期化／再インストールする – ＠IT apt-getの利用リポジトリを日本サーバーに変更する – Qiita Ubuntu 16.04: apt sourceでソースコードをダウンロードする – Narrow Escape Ubuntu 16.04でカーネルを再ビルドする – Narrow Escape ryzen-problem-repro3 · GitHub Ryzenにまつわる2つの問題 – 覚書 日記 (2017 年 6 月下旬)

続きを読む

three.js も WebGL もはじめてではないんですけども、思いつきでこういうの作ってみました。 細かく分割した線を描画し、頂点シェーダで波を重ね合わせて頂点の位置を変更しているだけです。 ちなみに、ドラッグやスワイプで見る角度を変更可能です。 まるで回る洗濯機のように、いつまでも見続けてしまいます。 我ながらなんて危険なものを作ってしまったんだという思いですw

続きを読む

表題のとおり luks で暗号化したルートディレクトリを今回拡張してみたのでそのメモを。

まずは拡張前の状況

$ uname -a
Linux ******** 4.9.9-200.fc25.x86_64 #1 SMP Thu Feb 9 17:28:13 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

$ cat /etc/redhat-release
Fedora release 25 (Twenty Five)

$ sudo gdisk -l /dev/sda
…省略…
Partition table scan:
  MBR: MBR only
  BSD: not present
  APM: not present
  GPT: not present
…省略…

MBR です。

$ sudo fdisk -l　/dev/sda
/dev/sda1  *        2048   1026047   1024000   500M 83 Linux
/dev/sda2        1026048   9152511   8126464   3.9G 82 Linux スワップ / Solaris
/dev/sda3        9152512 134195199 125042688  59.6G 83 Linux

sda3 が　luks パーティション。 中身のファイルシステムは ext4 。 ここに / 以下が全て入ってます( /boot を除く)。 ストレージ全体の容量は64GBで、これを今回100GBに変更したので sda3 をストレージいっぱいまで拡張する、というのが今回の目的です。

作業内容

一旦シャットダウンしてフルバックアップをとってから fedora25 の live DVD で起動。 現状を確認。

$ sudo parted /dev/sda unit MiB print
Model: VMware, VMware Virtual S (scsi)
Disk /dev/sda: 102400MiB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start    End       Size      Type     File system     Flags
 1      1.00MiB  501MiB    500MiB    primary  ext4            boot
 2      501MiB   4469MiB   3968MiB   primary  linux-swap(v1)
 3      4469MiB  65525MiB  61056MiB  primary

sda3 の End を 102400MiB にすると良いっぽい。 実際にパーティションを拡張してみる。

$ sudo parted /dev/sda
GNU Parted 3.2
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) resizepart 3 102400MiB
Error: The location 102400MiB is outside of the device /dev/sda.
(parted) resizepart 3 102399MiB
(parted) quit                                                             
Information: You may need to update /etc/fstab.

102400MiB ではギリギリアウトだったので 1MiB 減らしました。 再度シャットダウンして通常の環境で起動。 luks ボリュームの名前を確認

$ mount
…省略…
/dev/mapper/luks-********-****-****-****-************ on / type ext4 (rw,relatime,seclabel,data=ordered)
…省略…

拡張前のサイズを確認

$ df -h
ファイルシス   サイズ  使用  残り 使用% マウント位置
…省略…
/dev/dm-0         59G   54G  1.8G   97% /
…省略…

luks ボリュームと ext4 ファイルシステムの拡張

$ sudo cryptsetup resize /dev/mapper/luks-********-****-****-****-************
$ sudo resize2fs /dev/dm-0
resize2fs 1.43.3 (04-Sep-2016)
Filesystem at /dev/dm-0 is mounted on /; on-line resizing required
old_desc_blocks = 4, new_desc_blocks = 6
The filesystem on /dev/dm-0 is now 25069568 (4k) blocks long.

拡張後のサイズを確認

$ df  -h
ファイルシス   サイズ  使用  残り 使用% マウント位置
…省略…
/dev/dm-0         95G   54G   36G   61% /
…省略…

続きを読む

最近、HiLetgo Mini USB Nano V3.0 ATmega328P CH340G 5V 16M マイクロコントローラーボード Arduinoと互換という中国製のArduino Nanoクローンを入手しました。 中国からの発送となるため到着に2週間くらいかかったんですけども330円というめちゃ安価格で普通に動作するので満足しております。 それはさておき、同時に以下の2製品、赤外線受信モジュールと赤外線送信モジュールも入手し、Arduinoで学習リモコンみたいなものを作成しました。 HiLetgo 38kHz 赤外線受信機モジュール IR レシーバー　Arduino 電子建物知能ロボット [並行輸入品] HiLetgo 赤外線送信機モジュール IR 赤外線センサー Arduino 電子建物知能ロボット LED表示 [並行輸入品]

こんな感じ

ソースはここ

https://github.com/peta-okechan/irecho (IRremoteというArduinoのライブラリを使っています) 仕組みとしてはPC(Pythonスクリプト)からシリアル通信でArduinoに赤外線信号の受信 or 送信のコマンドを送信する感じです。 Arduinoで受信した赤外線信号のデータをPCに保存したり、PCに保存した赤外線信号のデータをArduinoに送ったりすることで学習リモコンとして機能するようになってます。

問題点

でまぁ安定して動作はするのですが、赤外線信号の生データをシリアル通信でやりとりするのでそのへんがボトルネックになってしまいました。 受信、つまり学習は基本最初の1回やれば済むのであまり気にならないんですけども、送信に時間がかかると結構不便です。 私が学習させたリモコンの場合だと送信に1秒くらいかかるので、例えばテレビのリモコンの複数のボタンを連続してパパパッと操作するような場合のリアルリモコンの使い勝手とくらべると、非常に使いづらい感じです。 これは生データをシリアル通信でやりとりしてるのが原因なので、デコードされたデータを扱うようにすると解決できると思います。 IRremoteには生データだけでなくデコードされたデータを扱う仕組みもあるので、というかデコードされたデータを扱うのが主目的なライブラリなので、対応はそう難しくはないはずです。 ちなみにデコードされたデータというのは、例えばNEC方式の信号の12345(32bitデータ)みたいな感じになりますので、この場合1信号で5バイトあれば十分に表現できることになります。 生データだと私が学習させたリモコンの場合、1信号あたり32bit整数68個分くらいで、単純計算で272バイトになりますので、デコード済みデータと比べると50倍以上のサイズになります。 さらに今回デバッグのしやすさを考慮して生データを整数じゃなくてカンマ区切りの文字列として送信してますので300バイト以上になってます。 各整数が3～5桁に収まってるのでこの程度で済んでますけど、かなり無駄が多いです。 後々デコードされたデータを扱うよう変更するとして、現状の仕様のままでシリアル通信の速度を変えたらどのくらい処理速度に変化があるか気になったので測ってみました。 計測に使ったスクリプトはこんな感じ。

#!/usr/bin/env python
# coding=utf-8

import subprocess
import timeit


def main():
    command = [
        'python', 'irecho.py', 'send', '--serial-port', 'COM3', '--name', 'ue',
    ]
    result = timeit.timeit(
        '''subprocess.run(
            command, stdout=subprocess.PIPE, stderr=subprocess.PIPE
        )''',
        'import subprocess',
        number=10,
        globals={'command': command}
    )
    print(result)

if __name__ == '__main__':
    main()

送信処理を10回行ってその合計時間を表示します。 追記: これ最初のimport subprocessはいらないですねw これを元のソースを書き換えながら2400bpsから230400bpsまで計測した結果が以下です。

2400bps	31.465807555238776秒
4800bps	16.709830173437872秒
9600bps	10.859490425279164秒
14400bps	6.955400712758374秒
19200bps	5.69991770016631秒
28800bps	4.4919952482775秒
38400bps	3.902442195295795秒
57600bps	3.2598146828225234秒
76800bps	2.9445462580185318秒
115200bps	2.5869034925160372秒
230400bps	51.266840769779044秒

元が9600bpsだったんですけども10回の送信処理で約10秒でやはり1回の送信処理あたり1秒くらいかかってた事が分かります。 2400bpsから19200bpsまではボーレートに応じて結構速くなる感じですけども、シリアル通信以外の処理がボトルネックの主要因になりはじめると思われる19200bps以降はあんまり速くならない感じですね。 230400bpsでグラフが跳ね上がってますけども、これはシリアル通信に失敗してPC側のスクリプトとArduinoがうまく連携出来なくなり、タイムアウトが発生するまで止まってしまうせいでしょう。 Arduino側のソースで送信時のタイムアウト時間は5秒としてますので、10回の処理で約51秒かかったということは10回全てタイムアウトしてるものと思います。 115200bpsが一番速いんですけども通信の安定性という点で少し心配なのでひとつ下の76800bpsにしてみました。 思ったより効果が高かったので根本解決するまえにボーレートを上げてしばらく使ってみたいと思います。

続きを読む

少し前にこちら（Macで重いバックグラウンドアプリケーションを劇的に軽くするPythonスクリプト）の記事についてコメントをいただきまして、私が書いたPythonスクリプトがSheepShaverというアプリに対しては動作しないよ、というコメントだったのですが、ここ数年Macを使っておらず検証用の環境がすぐに用意できない状態だったので結構適当に返答してしまってました。 最近少し暇になったので環境を用意し少し深く問題を調査した結果、原因が判明したので軽くメモ程度に残しておきます。

Carbon APIのGetProcessForPIDとGetProcessBundleLocationについて

コメントへの返信で、appscriptパッケージから最終的に呼ばれる当該関数がうまく動作してないのではないか、と書いていたのでその予想がアタリなのかハズレなのかをまず調べました。 結果を先に述べると、完全にハズレでした。（お恥ずかしい…） 確認のためにC言語でザッと下記のコードを書いて実行してみたところ、SheepShaverでも普通にプロセスIDからアプリケーションバンドルのパスが取得できました。 ちなみに検証環境のOSのバージョンは10.11.6 El Capitanですが、当該関数は現在では非推奨になってるようです（コメント参照）。

//
//  main.c
//  GetBundleLocationFromPID
//
//  Created by peta on 2016/10/02.
//  Copyright © 2016年 peta. All rights reserved.
//

#include <stdio.h>
#include <Carbon/Carbon.h>

int main(int argc, const char * argv[]) {
    if (argc != 2) {
        printf("Usage: %s PID\n", argv[0]);
        return 1;
    }

    int pid;
    pid = atoi(argv[1]);
    if (pid <= 0) {
        printf("The PID is invalid.\n");
        return 1;
    }

    OSStatus stat;
    ProcessSerialNumber psn;
    stat = GetProcessForPID(pid, &psn); // 10.9 から deprecated
    if (stat != errSecSuccess) {
        printf("Failed calling GetProcessForPID().\n");
        return 1;
    }

    FSRef loc;
    stat = GetProcessBundleLocation(&psn, &loc); // 10.9 から deprecated
    if (stat != errSecSuccess) {
        printf("Failed calling GetProcessBundleLocation().\n");
        return 1;
    }

    UInt8 path[PATH_MAX];
    stat = FSRefMakePath(&loc, path, sizeof(path)); // 10.8 から deprecated
    if (stat != errSecSuccess) {
        printf("Failed calling FSRefMakePath().\n");
        return 1;
    }
    
    /*
    CFStringRef str = CFStringCreateWithBytes(kCFAllocatorDefault, path, sizeof(path), kCFStringEncodingUTF16, false);
    CFIndex len = CFStringGetLength(str);
    CFIndex max = CFStringGetMaximumSizeForEncoding(len, kCFStringEncodingUTF16) + 1;
    char *cstr = (char*)malloc(sizeof(char) * max);
    if (!CFStringGetCString(str, cstr, max, kCFStringEncodingUTF16)) {
        free(cstr);
        printf("Failed calling CFStringGetCString().\n");
        return 1;
    }
    
    printf("%s\n", cstr);
    free(cstr);
    */
    
    printf("%s\n", path);
    return 0;
}

※初出のソースではFSRefMakePathで得られたバイト列path（UTF8でエンコードされたデータ）をUTF16としてデコードし再度UTF16としてエンコードしてC言語形式の文字列に変換するという謎な処理を行ってましたが（複数行コメントの部分）、元のデータがUTF8ならターミナル.appでも普通に表示できるだろうということで特に変換せずにprintfに渡すようにしました。

ちょっとappscriptのソースを読んでみた

予想がハズレたので観念して少し深くソースを読んでみることに。 appscript/py-appscript/tags/py-appscript-1.0.0/appscript_2x/lib at master · mattneub/appscript · GitHub 超ざっくり言うとappscriptは、アプリケーションリファレンスに対する最初のプロパティ等の呼び出しがあった際にそのアプリケーションがどういったプロパティやコマンド等を持っているのか動的に調べキャッシュし、2回目以降はそのキャッシュを使う（あくまでもプロパティ名やコマンド名等をキャッシュするだけで多分結果はキャッシュしない）ような仕組みになっています。 まぁ今回の件についてはキャッシュするという点は関係ないんですが、アプリケーションのプロパティ名やコマンド名等を動的に調べるという点が関係ありました。 appscriptでは動的に調べるために、アプリケーションに対して”ascrgdte”(GetDynamicTerminology)Appleイベントというものを送信してるようなんですが、SheepShaverの場合だけこの結果が空でした。 つまりSheepShaverがどんなプロパティやコマンド等を持っているかをappscript側では全く検知不可能で、当然frontmostプロパティもappscript側的には存在しないという事になるので私のスクリプトではエラーが発生してました。 もうこうなるとappscriptパッケージを使うのを止めて別の方法を使うしかないじゃん、と思ったのですが、ここでふと思い当たる点があったので試してみることに…

AppleScriptを許可せよ

結果から言うと下記のコマンドを実行するだけで私のスクリプトでも問題なく動作するようになりました（アプリのパスは実際の環境にあわせてくださいね）。

defaults write '/Applications/SheepShaver_UB_20140201/SheepShaver.app/Contents/Info' NSAppleScriptEnabled -bool YES

アプリのInfo.plistでAppleScriptによる操作を許可しただけです。 多分AppleScriptによる操作を許可しなくてもfrontmostなどのプロパティを読むだけなら可能なんでしょうけど、”ascrgdte”Appleイベントで全てのプロパティやコマンド等を列挙するような操作はAppleScriptによる操作を許可しないとできないんでしょう。 しかし初歩的なことで解決できてしまい脱力してしまいました…

余談

私が書いたスクリプトは6年くらい前のもので今見ると酷いソースだな（特にエラー処理）と思うんですが、もうMacは使ってないので多分改良はしません。 いらっしゃるかどうか分かりませんが改良したい方はご自由にどうぞ。 ただappscript自体開発もサポートもストップし新規開発では使わないよう公式に勧めているくらいなので、私もおすすめはしません。

続きを読む

往年の？AndroidタブレットであるXOOMにコントローラー基板を接続し、HDMI/DVI/VGAの映像を表示できる汎用的なモニターにしてみたお話です。

XOOMの分解

まず、XOOMを分解して内部にある液晶パネルのコネクタを露出させます。 こちらの分解記事（英語）が参考になりました。一番よくまとまってると思います。（天下のiFixitですし） Motorola Xoom Teardown – iFixit トルクスのT5とT6が必要でした。 裏蓋はある程度スライドして開くとツメが引っかかって止まるようになってるので、そのツメを押すために薄くて細くてしっかりした棒があれば開けやすいでしょう。 裏蓋を開け、バッテリーを外し、メインの基板を外すところまでやれば液晶パネルのLVDSのコネクターが見えるようになります。 この状態でB101EW04 V0という液晶パネルの型番が確認できました。 裏蓋を外すのに少々コツが必要でしたが基本的にネジを外すだけなので楽です。 その代わりネジの数は多め。 でもツメではめこまれてたり接着剤とか使われているよりは遥かにマシです。

液晶パネルB101EW04 V0のコントローラー

パネルの型番でググッていくつか出てきたものの中から、こちらのコントローラー基板を選んで購入しました。 HDMI VGA DVI Driver Board LVDS Converter for 10 1inch 1280 800 B101EW04 V 0 | eBay 追記 商品ページには記載がありませんでしたが確認したところHDCPにも対応してるようです。 私が購入したときはほんの少し値下げされてて$44.64でした。 送料無料のやつで注文したのですが、何故かEMSで1.5日で届いてしまい焦りましたw 多分通常だと2週間～1ヶ月ほどはかかるのではないでしょうか。 LVDSケーブルなどは付属しますがACアダプターは付属しないので注意が必要です。 説明書（同梱されていたペラ紙）によると、12V 3Aのものが必要らしいのですが、私は使ってない外付けHDDのACアダプターが端子のサイズがピッタリだったのでそれを使っています。 12V 2Aしかないんですけどとりあえずという事で。 追記 ワットチェッカーで消費電力を測ってみたところ、液晶パネル込み＆内蔵スピーカー無しの状態で8Wでした。 なので12Vx2A=24Wでも十分間に合いそうです。 説明書に大きく12V 3Aを使えと書いてあったのは、もっと大きいパネルを駆動する場合の話かもしれません。（コントローラー基板のハードウェア自体は今回のパネル専用というわけではない。） 腕に覚えありな方なら、この基板を使わなくても、似たような基板にファームを書き込むとか、自分で基板を起こしちゃうとか、FPGAでHDMI/DVI/VGA – LVDS変換機能を実装するとか色々やりようはあるんでしょうけど、私は腕に覚えがないのでポン付けできるやつにしました。

液晶パネルとコントローラー基板をどう固定するか

不器用で手持ちの道具も材料もろくなものがないので、なるべく簡単に固定する方法が無いか考えた結果以下のようになりました。 まず、コントローラー基板の外箱として使われていたタッパー（タッパーに入った状態で基板が届いたのです）の蓋にLVDSのフラットケーブルを通すための穴を開け、さらに基板を固定するためのビス穴を開け、ナットでメインの基板とOSDを操作するためのボタンの基板を固定。 次に液晶パネル（というかXOOM）を固定するためにこちらのタブレット用のアームを購入。 Amazon.co.jp： 【ieGeek】ipadスタンド フレキシブル アーム付き ホルダー マウント グースネック サイズ/360度調整可能【１年間の安心保証】iPad mini/iPad air/iPad2/3/4等対応(ブラック): パソコン・周辺機器 これにXOOMを取り付け、さらに結束バンドでタッパーの蓋（基板を固定済みのもの）を固定しました。 縦向きで使いたかったので縦向きで取り付けてます。 XOOMの縦のサイズだとアームの開き具合的に結構ギリギリでした。 基板がむき出しなのでカバーを作りたいところです。（普段見えない部分なので忘れるかも…） 追記 使用中はチップ（メインの基板の真ん中のチップ）が触れないほどではないですがずっと触ってると「熱っ」と思うくらいには熱くなるのでHM-17Aというヒートシンクを貼りました。 チップの温度を測るような機材は持ってないので効果の程は不明です。（気休め） チップのサイズは2cm x 1.4cmほどでしたのでこのヒートシンク（2cm x 2cm）は少し大きいですがしっかりと張り付いてるようです。

設置

こんな位置関係です。 下の2枚のモニターはメインPC用のデュアルモニターで、今回作ったモニターは時間がかかる処理を行う別のPCやサーバー用です。 あるソフト（HDDレコーダーの映像を自動でPCに取り込むソフト。拙作）のウインドウが縦長なので縦画面にしました。 アップ XOOMのフロントパネルをそのまま残してるので正面から見る限りチープさはあまりないと思いますがいかがでしょうか？

金額

コントローラー基板で約5,000円、タブレットアームで約2,000円の計7,000円かかりました。 微妙！ この半分くらいで済めば嬉しかったんですが…。 実は今回トルクスドライバーセットも新しく買ったのでそれにも1,000円くらいかかってますw

課題

HDMI経由の音声については今のところコントローラー基板のイヤホン出力から外部のスピーカーで再生するようにしてますが、できればXOOMに内蔵されていたスピーカーを流用してモニターから直接音を出したいなと思っています。 基板上にはすでにスピーカー出力用のコネクタ（PHR-4, 4pin）が実装されているため、ちょっとした材料と工作でできそうです。 ただPHR-4のメスのハウジングをどう入手するか…？という点でちょっと悩んでます。 PHR-4自体は1個数円～数十円で普通にネットでも買えるんですが、それがゆえに送料が500円以上とかかかるのがちょっと悲しいので、秋葉原などに行く機会があればついでに買おうかななんて考えているところです。 ただあまり無いんですよね最近、秋葉原に行く機会が…。

余談

XOOMというと2011年発売のもうかなり古いAndroidタブレットなんですけども、当時はモトローラ製だしTegra 2だし凄ぇと思いつつも私が手に入れたのはそれから1～2年くらい後のことです。 新古品？で2.5万円くらいでした。 当初から遅いなぁと思ってあまり使ってなくて長らく存在自体忘れてました。 最近部屋の掃除をしてたら出てきたので分解してみたところ、液晶パネルが流用しやすそうな感じだったことから今回の件に至りました。 タブレットのモニター化というと今回のような面倒なことをしなくても、それ用のAndroid/iOSアプリがあったりして、PCやMacにそれ用のソフトウェア/ディスプレイドライバーを入れ、Wi-FiやUSBケーブルで繋いで仮想的にモニター化する方法もあるようです。 ただ、私の場合PCのBIOS画面を見たいとかOSのインストールプロセスを見たいとかPCやMac以外の何かを繋ぎたい場合が多々あるため、ソフトウェア的な対応ではあまり満足出来ないうえに、XOOMの遅さだと使っててイライラしそうです。 だからハードウェア的な改造を行った、というわけではないんですけどね。 （やりたいからやってみただけです。） タブレットやノートPCの液晶パネルを利用したモニターの自作は調べてみるとある程度コモディティ化してるようです。 フルHD以上の高解像度なパネルを利用するのがメジャーなようですね。 XOOMの液晶パネルは10.1インチのサイズで1280×800の解像度であり、タブレットとしてはDPIが低いと言わざるをえません。 ですがそれでも149dpiあり（画面解像度(dpi,ppi)計算機で計算）、これは30インチの4Kモニターとほぼ同じです。 ある程度目から離して使うモニターとして考えるとこのくらいのDPIが細かすぎずちょうどいいと言えるギリギリのラインなのではないかなと個人的に思っています。 （もっと目に近いところで使うノートPC等ならもっと細かくてもよいですし、もっともっと目に近いところで使うタブレットやスマホならもっともっと細かくてもよいと思います。）

続きを読む