OMRON BY50Sのバッテリー交換

先日、使用中のUPS (OMRON BY50S)のバッテリ交換ランプが点灯、アラームが鳴ったので、その交換を行った。

申し込み手続き

OMRONのUPSを購入して3ヶ月以内に利用者登録をすることで、3年以内にバッテリ交換が必要となった場合の無料交換サービスを受けられる。

* OMRONのwebsiteから必要な手続きをする
* このとき、UPSのserial numberなどが必要になるので控えておく
* 申し込むと折り返しemailでの連絡がある
* 受け付けられると納入日などの連絡があり、交換用バッテリが送られてくる

交換作業

必要なもの

* UPS本体
* 交換用バッテリ
* プラスドライバ (2番)
* ペンチ or プライヤ
* 保護用のテープ (マスキングテープ、ガムテープ、etc)
* 絶縁テープ (ケーブルの被覆を傷付けてしまった場合に巻く)
* UPSの取り扱い説明書

UPSの電源を切るか、入れたままか

BY50Sは電源を入れたままでもバッテリ交換が可能なので、今回はそうした。ただし、その場合は以下のような注意がある:

* UL規格 (機能と安全性の規格)を満たさなくなる (cf. [UL (安全機関) - Wikipedia](https://ja.wikipedia.org/wiki/UL_(%E5%AE%89%E5%85%A8%E6%A9%9F%E9%96%A2)))
* 交換中の瞬停、停電は保護されない

従って、負荷側の電源を落としUPSを停止させてからの交換が推奨される。設置した場所から動かすことで交換作業がしやすくなる利点もある。

手順

* UPSの右側面を上にしてゆっくり倒す
* 底面のネジを1本外してカバーを開く
* バッテリに貼られているラベルの一部が接着されていないので、そこを引っ張り半分くらい取り出す
* 赤と黒の電源ケーブルを外す
* バッテリを完全に引き抜く

新しいバッテリは逆の順で挿入、装着する。

交換後、ブザー停止／テストボタンを長押しして新しいバッテリを認識させる。

注意点など

実際にやってみるとバッテリとケーブルを接続するコネクタが固くてなかなか外れなかった。説明書にあるように、ペンチやプライヤの類で上下に揺らしながら少しづつ外していく必要があった。このとき、ケーブルの被覆を傷付けないように、金属部分を予めテープで巻いておくと良いだろう。

また、新しいバッテリにケーブルを接続する際もなかなか奥まで入らなかった。やはりケーブルの被覆を傷付けないように注意しながら、道具をうまく活用する必要がある。

交換後のバッテリーの処分

送料のみ負担で不要となったバッテリを処分してもらえる。バッテリが送られてきた箱はそのまま使えるので取っておく。

不要となったバッテリの処分を急ぐ必要は特にないので、年末年始の混雑を避けて、来年の適当な時期まで待つ予定。

今年破壊したモノたち (2017年)

2017年中に主に不注意で破壊してしまったモノたち

Linear Technology LT1364CN8

OPAMP。方向を間違えてICソケットに挿入、通電 → 破損。

0.5mmピンバイス (ダイソー)

スルーホール基板に残ったハンダに穴開け作業中に折れた。セットの0.8mmは存命、使用中。

ネオンランプ ×2

電流制限抵抗なしで100VACに直結 → 破裂。

SHARP S108T02

SSR。

SSRでネオンランプ点灯を制御する実験中↑に巻き込まれ、AC側に過電流が流れた。ショートモードで故障。

Cree XP-L

パワーLED。

放熱対策のためアルミ基板の裏にはんだを盛っている最中に加熱し過ぎた。樹脂製カバーが外れ破損。

豆電球

昔ながらの豆電球。電圧を盛り過ぎて焼き切れた。

キセノンランプ

National SemiconductorのレギュレータLM338Tで実験中に、可変抵抗器の調整が狂って電圧を上げ過ぎ焼き切れた。

不注意ではなく、意図して破壊 (分解)したモノたち

コイズミ 蛍光灯

部屋の照明をLEDに変更し不要になった。別の部屋での再利用も考えたが、もう10年以上経過していたので分解。

アイリスオーヤマ ECOLUX

LED電球。

点灯しているとチラつくようになり、分解して調べてみた。

番外編 寿命を迎えたモノたち

ASUS A31N1302

Li-ion battery pack。

分解してみると、3本の18650セルが直列に繋がっており、そのうちの1本が死亡していた (起電力0V)。

OMRON BY50Sのlead battery

交換用batteryを手配中。 → 交換した cf. http://typeinf-memo.blogspot.com/2017/12/omron-by50s.html

SwissMicros DM42のfirmware update (w/ dfu-util)

update information:

* 2018-10-15: 2018-10-07にfirmware v3.11がreleaseされた。USB cable接続時にfreezeするbugが解決されたのでupgrade推奨
* 2018-03-26: 2018-03-25にfirmware v3.5がreleaseされた
* 2018-02-19: 2018-02-12にfirmware v3.3がreleaseされた
* 2018-01-07: 2018-01-05にfirmware v3.2がreleaseされた

(追記は以上)


届いたDM42のfirmwareはv3.0だったので、2017-12-26現在の最新版であるv3.1にupgradeした。

upgrade前 (v3.0)

upgrade後 (v3.1)

手順はhttps://www.swissmicros.com/dm42/doc/dm42_user_manual/#_firmware_updateに詳しく解説されているので参照のこと。

たぶん、Windowsでdm_toolを使ったfirmware upgradeは誰かがやっていると思うので、Linux (Debian)からdfu-utilを使ってやってみた。

概要

必要なもの

* SwissMicros DM42
* Linux box (w/ USB)
* USB cable (A-microB)
* 細いピン (或いは伸ばしたゼムクリップ)

手順

準備 ※一度行えば以降は不要

* Linux machineにdfu-utilをinstall (apt-get install dfu-util)
* DM42を認識するようにudevを設定 (あるいはsudoでdfu-utilを使う)

firmware update

* firmwareをdownload (DM42_flash_XX.bin)
* DM42をbootloader modeに移行
* DM42とLinux machineをUSB cableで接続 (DM42側はmicroUSB, PC側はA)
* dfu-utilsで書き込み
* DM42の背面にあるRESET buttonを細いピンのようなもので押してreset

実際のlog

USB cableでDM42 (bootloader mode)を接続した際のdmesg。

% dmesg
...
[676590.811335] usb 1-1.7: new full-speed USB device number 8 using ehci-pci
[676590.890786] usb 1-1.7: New USB device found, idVendor=0483, idProduct=df11
[676590.890789] usb 1-1.7: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[676590.890791] usb 1-1.7: Product: STM32  BOOTLOADER
[676590.890792] usb 1-1.7: Manufacturer: STMicroelectronics
[676590.890794] usb 1-1.7: SerialNumber: ************

dfu-utilで認識しているか確認。

% dfu-util -l
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Found DFU: [0483:df11] ver=2200, devnum=8, cfg=1, intf=0, path="1-1.7", alt=2, name="@OTP Memory /0x1FFF7000/01*0001Ke", serial="************"
Found DFU: [0483:df11] ver=2200, devnum=8, cfg=1, intf=0, path="1-1.7", alt=1, name="@Option Bytes  /0x1FFF7800/01*040 e/0x1FFFF800/01*040 e", serial="2069328B4834"
Found DFU: [0483:df11] ver=2200, devnum=8, cfg=1, intf=0, path="1-1.7", alt=0, name="@Internal Flash  /0x08000000/512*0002Kg", serial="************"

実際の書き込み。

% dfu-util -D DM42_flash_3.1.bin -d 0483:df11 -a "@Internal Flash  /0x08000000/512*0002Kg" -s 0x8000000
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 0483:df11
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing 
DFU mode device DFU version 011a
Device returned transfer size 2048
DfuSe interface name: "Internal Flash  "
Downloading to address = 0x08000000, size = 865928
Download        [=========================] 100%       865928 bytes
Download done.
File downloaded successfully

蛇足: 失敗例

ちなみに、CLIで実行する場合には手順を説明したpageから (ここからではなく)のcopy'n'pasteを推奨する。著者は-s 0x8000000とすべきところを-s 0x800000と「0」を1つ少なく書いたばかりに「書き込めない」とのerrorを見る羽目になった。

% dfu-util -D DM42_flash_3.1.bin -d 0483:df11 -a "@Internal Flash  /0x08000000/512*0002Kg" -s 0x800000

dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.

Copyright 2010-2016 Tormod Volden and Stefan Schmidt

This program is Free Software and has ABSOLUTELY NO WARRANTY

Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

dfu-util: Invalid DFU suffix signature

dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!

Opening DFU capable USB device...

ID 0483:df11

Run-time device DFU version 011a

Claiming USB DFU Interface...

Setting Alternate Setting #0 ...

Determining device status: state = dfuIDLE, status = 0

dfuIDLE, continuing

DFU mode device DFU version 011a

Device returned transfer size 2048

DfuSe interface name: "Internal Flash  "

Downloading to address = 0x00800000, size = 865928

dfu-util: Last page at 0x008d3687 is not writeable

SwissMicros DM42が届いたのでfirst impressionなど (2018-10-15更新)

*** 更新情報 ***

2018-10-15: DM42のfirmware v3.7以降には、一部個体でUSB cableを接続するとfreezeするbugがある。Affectしている場合はv3.11へのupdateで解消するので適用を検討されたい。

*** 更新情報ここまで ***


注文していたSwissMicros DM42 (往年の名機HP-42Sのclone)が届いた。

左側はDM42、右側はSwissMicros DM-15L (HP-15Cのclone)

* 寒いせいもあってかcoverから取り出すときにとてもキツかった
* key pressの感触は固め (特にENTER)
* LCDが大きくとても見やすい
* 本体の質量は176g (電池込み)で、SwissMicros DM15L (電池込み)が129gなのと比較して重い
* 黒い艶消しの塗装・表面処理がなされているAl製 (かは未確認だがおそらく金属製)筐体
* DM42が薄いこともあり、よりsolidに感じられる

User manualが公開されているので参照されたい。

cf. [DM42 User Manual](https://www.swissmicros.com/dm42/doc/dm42_user_manual/)

なお、現時点 (2017-12-26)では電池交換についていまいち分からないので、今後情報のupdateがなされるのを待ちたい (ざっくり検索してみた限りはCR2032×1のようだ)。

 cf. [SwissMicros DM42 | A collection of programmable and non-programmable calculators](http://calculators.torensma.net/index.php?page.id=16&calculator.id=724&action=detail)。

ちょっと使ってみる

よくわからなくなったときは、とりあえずEXITを押せばOK。とにかく元に画面表示に戻るまでEXITを押す。

日付と時間がズレているので修正

* □＋SETUP (0)でSetup menuに入る
* 3. Settingsを△/▽で選択してENTER
* 1. Set Timeと2. Set Dateでそれぞれ時間と日付を調整できる。下に+1Y (1年足す)とか出ているのでそれらの中から適切な機能を選んで日付と時刻を合わせたらENTERを押して確定する

stack表示の調整

* XYZTL (default) → X, Y, Z, Tの4つに加えてlast answer (L)を表示する。L-registerの内容は□＋LAST X (x≶y)でX-registerにcopyされる。T-registerは特殊で、ここに入った値はstackが1段下がった時にZ-registerにcopyされる

stackを用いた演算について

数値を入力すると最初にX-registerに、以下ENTERを押すごとにY → Z  → Tと順に積まれていく。1つのoperandに対する演算はX-registerに適用される (eg. √とかlogとかsinとか)。2つのoperandsに対する演算はXとYの両registersを引数とし、演算結果をX-registerに積む。このとき、Y←Z, Z←Tでregistersの内容がcopyされる。

mode設定

□＋MODES (+/-)でmode設定に入る。

関数電卓ではお約束の角度単位 (DEG/RAD/GRAD)、複素数表示形式のRECT/POLARなどが調整できる。

disp設定

□＋DISP (E)でdisp設定に入る。

やはり関数電卓で重要な数値の表示形式を設定する。

* FIX → 小数点以下の表示桁数を固定
* SCI → scientific notation、科学技術計算でよく出てくる指数による表示
* ENG → engineering notation、指数表示だが3ごと (SI接頭辞に対応する)表示

など。

CASIOの関数電卓とかだと確か[E↔F]みたいな名前の機能があって (手持ちのfx-JP500だとENGと←が対応？)表示を切り替えるが、HPのRPN電卓ではdisp設定から行う。

menu keyについて

* menu key (function key)はdefaultでは表示されていないが、機能そのものは
[Help][Menu][     ][Volum][RegFm][FonSz]
の順に割り当てられている。[Menu] (左から2番目)を押下して表示/非表示を切り替える
* □＋CUSTOM (2)でcustom menuを表示 → □＋ASSIGN (1)でよく使う機能を最大18個登録できる

よく使う関数や機能が何かは人や用途によって違うが、以下のようなものは候補になるんじゃないかと:

* IP (integer part) → 整数部分を取り出す eg. 16.22 → 16.00
* MOD (modulo) → 整数除算の余り eg. 2 MOD 7 → 2
* GAM (gamma) → Γ function (階乗の一般化)
* COMB (combination) → nCr (組み合わせ)
* PERM (permutation) → nPr (順列)

既に割り当てられていても□ (shift？)を押さないといけない機能 (πとかy^xとか)をよく使う場合には有効活用できるだろう。

その他、気になったことなど

off時の画面表示

DM42のdefaultでは電源offでも画面に何かしら表示されているがこれは正常。

確か設定で切れるはず。

なお、好きな画像を表示するようにもできる:

cf. [DM42の画面にNieR:Automataの2Bさんの画像を表示する](https://typeinf-memo.blogspot.com/2018/02/swissmicros-dm42off-imagenierautomata2b.html)

stack段数設定について

HP 50gだとstack段数は実質的に∞ (memoryの上限がlimit)だし、WP 34S (HP 10b/HP 20bのfirmware改造版)だと4段と8段を切り替えられるが、DM42 (中身のFree42)では今のところこの機能はないようだ。

programmable

programはまだ試していないので、時間を見つけていずれ。

試しにユークリッドの互除法を実装してみたので参照されたい:

cf. [SwissMicros DM42で簡単なprogramを組んでみる](https://typeinf-memo.blogspot.com/2018/03/swissmicros-dm42program.html)

firmware updateについて

DM42はfirmware updateによりbugfixや機能強化がなされる。方法については既に記事を書いているので参照されたい:

cf. [SwissMicros DM42のfirmware update](https://typeinf-memo.blogspot.com/2017/12/swissmicros-dm42firmware-update.html)

参考URL

* [SwissMicros](https://www.swissmicros.com/dm42.php)
* [HP-42S - Wikipedia](https://en.wikipedia.org/wiki/HP-42S)

shell scriptでsignal handling (w/ trap)

ちょっとしたshell scriptを書いていると、Ctrl-Cでprocessを殺した時などに適当な処理をさせたいことがある。

例えば、gpioに出力するscriptを実行中にCtrl-Cを押下すると、タイミングによってはgpioに出力しっ放しになり、後からpinを調べてgpio write $PIN 0などと手作業で始末しなければならない。これはいかにも面倒なので、Ctrl-Cによる中断 (SIGINT)が発生した際に終了処理を行わせたくなる。

この目的を達成するために、shell builtin commandであるtrapが使える。ただし、trapの仕様 (受け付けるoptionの種類や数)がshellによって異なるので注意が必要。以下、bashにおける利用例を挙げる。

使い方

singalに対する処理を指定する

trap <commands> <signals>

<commands>にはdouble quotation (")で括ってcommandの羅列が指定できる。

<signals>にはSIGINTやSIGTERMなどが指定できる。bashのtrapでは、trap -pで指定できるsignalsのlistが表示される。1つの処理に対して複数のsignalsを指定できる。

例: SIGINT (Ctrl-C)とSIGTERMが発生した時にgpio 25番 (WiringPi)に0を出力して終了する

$ trap "gpio out 25 0; exit" SIGINT SIGTERM

signalを単に無視する

<commands>に"" (空文字列)を渡す。

trap "" <signals>

例: SIGINTを無視する

$ trap "" SIGINT

signal handlingをdefaultに戻す

<commands>に"-" (hyphen)を指定する。

trap - <signals>

例: SIGINTのsiginal handlingをdefaultに戻す

$ trap - SIGINT

※bashの場合は<commands>を省略しても同じ効果。

$ trap SIGINT

注意

* shebang (shell scriptの1行目)を/bin/bashにしておくこと

* trapはshell scriptで使う場合が殆どだが、その際、なるべく早い段階で設定しておくこと → trapによるsignal handlingが設定されていない状態で主たる処理が始まってしまう。

少し考えれば当たり前なのだが、なぜか最後にtrapを指定していたscriptがあったので敢えて注意を。

補遺

shellによるtrapの動作やoptionsの違いについて。

options

* bashのtrapのみ、-lや-pといったoptionを受け付ける

* zshのtrapは何もしない

* dash (Debian defaultの/bin/sh)のtrapではerror

書式

* bashやzshのtrapは、<signals>として例えば"SIGINT"もしくはSIG抜きの省略形"INT"のような名前、或いは対応する番号 (SIGINTは2)で指定する

* dashでは、"INT" (SIG抜き)或いは番号 (2)で指定する

出典

* man bash-builtins

* man zshbuiltins

* man dash

Saka Keyという選択肢

Firefox 57 (Firefox Quantum)ではlegacy extensionsであるVimperatorや (そのalternativeであった)VimFxが押し並べて使えなくなる (cf. http://typeinf-memo.blogspot.com/2017/11/firefox-57-aka-firefox-quantum.html)。以前のentryでalternative browserであるWaterfoxについて紹介した (cf. http://typeinf-memo.blogspot.com/2017/11/keysnail-user-waterfox.html)が、最新のFxに乗り換える場合にはSaka Keyという選択肢がある。

cf. https://github.com/lusakasa/saka-key

Saka Key

Saka KeyはWebExtensions対応なのでFx 57以降も継続して利用可能だ。VimperatorやVimFxほどcustomizeの自由度はないが、差し当たってVi(m)っぽいkeybindでFxを操るには問題ない。

個人的にSaka Keyは設定が簡単 (項目数が多過ぎない、変更方法が直感的)で使いやすいと思う。

一方で、addonの画面など一部のwindowでkeyboard navigationがきかなくなる場合がある (おそらく仕様)のと、history関連にkeyを割り当てられないなどの不便な点もあるので、これから改善されていけば良いなと思った。

Extensionsやcustomizeとの付き合い方

KeySnailとかVimperatorとかがそうなのだが、徹底的にcustomizeできるようにしようと頑張れば頑張るほど、Fxの(公開されていない)深い部分に突っ込むことになり、core側で大きな変更があった場合に対応不能 (或いは全面的なrewrite)になってしまう。そうならないためには、web browserの浅い部分だけをさらっとなぞるだけにする (=WebExtensionsを使う)必要があるが、今度は痒い所に手が届かない (届きにくい)。

変化が早い時代には、好みに基いて徹底したcustomizeを施すよりも、適当な所で妥協して御仕着せのUIに合わせる方が良いのかもしれない (web browserに限らず)。表層だけならどのweb browserも似たようなものだから乗り換えも自由自在だ。

Waterfoxでkeysnailの調子が悪かったので修正した

Waterfoxをupgradeした所、KeySnailの調子が悪くなったので原因を探ってみた。

症状

* KeySnailが有効になっているのにkeybindsが反応しない
* tanything (KeySnail pluginの一つ)が反応しない
* 一部の機能は動くが"C-g" (cancel)でwindowが消えない

原因と解消法

Waterfoxの最近の更新でdefaultの設定値が変わったのが原因のようだ。

* extensions.e10sBlocksEnablingをfalse → true
* extensions.e10sMultiBlocksEnablingをfalse → true

へ変更してrestartした結果、正常動作するようになった。

発見までの道程

* "Add-ons" (about:addons)の画面を眺めていた所、multiprocessがonになっていることに気付く
* about:configでe10s関連の設定値を眺めて、怪しそうな所を取り敢えず変えてみた → うまくいった

PostgreSQL10への移行に伴うMediaWikiのupgrade

注: 2017-09-23ごろの情報なので古い (eg. PostgreSQLは10rc1ではなく10.1になっている)が、うっかり忘れていたので今更ではあるがup。



PostgreSQLをupgradeした際 (cf. http://typeinf-memo.blogspot.com/2017/09/postgresql-10.html)に、PostgreSQLをbackendとして利用しているMediaWikiのupgradeも行ったのでメモ。

環境は:

* Debian GNU/Linux (AMD64)
* MediaWiki 1.29.1
* Nginx 1.13.5-1
* PHP-FPM 7.0.22-3
* PostgreSQL 10rc1

という、主流ではない構成なので注意。大体の場合はapache2 + php module + MySQLとか、nginx + php-fpm + mariaDBとかだと思う。

MediaWiki本体のupgrade手順

* sudo service php7.0-fpm stop
* sudo service nginx stop
* cd /path/to/wiki/
* git checkout <VERSION>
* cd maintenance/
* php update.php
* sudo service nginx start
* sudo service php7.0-fpm start

※MediaWikiをgitでinstallする場合は、必要に応じてPHPのpackage managerであるcomposerのupdateを行う → composer update

外部packageのupgrade

pg_upgradeclusterを使ったdatabaseの移行に際し、必要に応じてtextsearch_jaなど外部packageのupgradeも行う

* make USE_PGXS=1
* sudo make USE_PGXS=1 install
→ これで/usr/lib/postgresql/10/textsearch_ja.so他必要filesがinstallされる

sudo -u postgres psql -f /usr/share/postgresql/10/contrib/textsearch_ja.sql wikidb
が失敗する場合は、一度uninstallを試みる
sudo -u postgres psql -f /usr/share/postgresql/10/contrib/uninstall_textsearch_ja.sql
そしてもう一度改めてinstallを試みるとうまくいく場合がある

MediaWikiでerrorが出た時見るべきlog files

* MediaWikiのlogは、LocaleSettings.phpの$wgDebugLogFile = "/path/to/the/debuglogfile";で指定する。comment outするとlog fileを作らない
* /var/log/postgresql/
* /var/log/nginx/
* /var/log/syslog
* /var/log/php7.0-fpm.log

GNU screenのvisual bellがvimやlessと干渉していた

地味に不便な不具合

Terminal emulator使いにとっては欠かせないterminal multiplexerのGNU screen (今時はtmuxとかneercsとかmtmなんだろうか)。

そんなscreenの内部でlessやvimを使っている時、fileの先頭や末尾にcursorが到達した後もうっかりkeyを押下し続けているとterminal emulator全体がしばらく固まってしまう現象に悩まされていた。硬直時間はkeyを押下していた時間 (=入力文字数)に比例して長くなるので、repeat speedを上げ、repeat delayを短かく設定している (=短時間に多くのkey repeatが発生する)環境では顕著だった。

いろいろと試してみた結果、screenが提供しているvisual bellの機能を切れば問題が発生しないと分かった。

Visual bellの切り方 (audible bellへの戻し方)

* ~/.screenrcにてvbell offの行を追加する (或いはcomment outする)。

* 起動中のscreenでは、C-a : (prefix + :)でvbell offを実行する。

Visual bellについて

音ではなく「目で見 (え)るベル」という意味合い。

pager (lessとか)やeditor (vimとか)でfileの先頭或いは末尾に達してそれ以上はscrollできない時とか、何かしらのactionをcancelした時など、eventが発生した時に音を鳴らすのではなく、かわりに画面を瞬間的に反転させたり、最上行・最下行を反転させたりする機能である。

今回の問題は以下のような機序で発生するものと推察する:

* visual bellをonにしたscreen内部でvimやlessを使っている時、fileの先頭や末尾に到達したなどの理由でvisual bellが発動すると、screenがそのための処理をする

* その最中にkey inputが継続すると、screenはbufferに蓄えられていたその一つ一つに対して馬鹿正直にvisual bellの処理を実行する

* key inputが大量だった場合、結果としてterminal emulator全体をfreezeさせてしまう

* 何れ処理が終わると復帰し、その後に入力されていたkeyに反応しはじめる

問題の原因特定に至る試行過程

* Editorやpagerを疑う → lessとvimでは発生したが、lv (Powerful Multilingual File Viewer, lessのかわりに使えるpager)やnano (editor)では発生しなかった

* Terminal emulatorを疑う → Xfce4 terminalを使っていたので、xtermなどで実験した

* screenを疑う → Xfce4 terminalでもxtermでもscreenを使っている時のみ発生したのでscreenが怪しいと思い始めた

* visual bellを疑う → 何となく「visual bellを切ったらどうなるのか」と思い試してみたら当たりだった

その他の対処法

著者の使い方ではvisual bellを切るのが最も簡単な手段だったので採用したが、他にも幾つか方法は考えられる:

* screenから乗り換える → tmuxなどでは試していないので不明

* key repeatのspeedを下げ、delayを大きくする

* lessではなくlvを使う、vimではなくnanoを使う

Shuttle SZ170R8のBIOSをupdateし、Intel MEのvulnerabilitiesに対応する

Skylake以降のIntel CPUに (明示的にdisableできない状態で)搭載されているIntel ME (Intel Management Engine)にて、remote control vulnerabilitiesが発見されて問題になっている。これがどんなものかについては以下のlinksを見てほしい:

* [Intel® Product Security Center](https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00086&languageid=en-fr)

そもそも、Intel MEとは？については以下のsiteが参考になる:

* [インテルMEの秘密 - チップセットに隠されたコードと、それが一体何をするかを見出す方法 - by イゴール・スコチンスキー - Igor…](https://www.slideshare.net/codeblue_jp/me-32214055)

各vendorsが対応に追われているが、11/26にShuttleも対応BIOSを公開した (cf. [Shuttle Global - SZ170R8](http://global.shuttle.com/main/productsDownload?productId=1995))ので、手持ちのSZ170R8に適用した。

手順の概要

* 起動用のUSB flash keyを作る
* SZ170R8をUSB flash keyからboot
* FreeDOSのcommand promptからflash.batを実行

以上の手順でBIOSのversionが2.07→2.08に更新される。なお、Windows usersは別途"Driver"のpageにあるChipset → ME_Intel_Z170の11.8.50.3399も適用のこと。

適用後の確認

適用後、Intelが公開している、Intel ME関連のvulnerabilityをcheckするscriptを実行して確認 (環境はDebian GNU/Linux (4.15-rc1)):

> % sudo intel_sa00086.py
> ...
> *** Intel(R) ME Information ***
> Engine: Intel(R) Management Engine
> Version: 11.8.50.3399
> SVN: 3
>
> *** Risk Assessment ***
> Based on the analysis performed by this tool: This system is not vulnerable. It has already been patched.

きちんとpatchされていると確認できた。

なお、適用前のIntel MEのversionは11.6.10.1196だった。

今後の予定

Intel MEは、主となるcomputer systemから独立した、別個の(another) computer systemであり、普段userが触れているOS (WindowsやLinux)からはそれが何をしているのか感知できない。そのような場所に今回のような外部からaccessibleなvulnerabilitiesがあり、しかもIntel MEの機能を必要としないuserが明示的にそれをdisableできないのは問題である。

そこで、Intel MEのfirmwareを無効化したBIOSの作製に挑戦してみたい。SZ170R8でBIOS記録用として用いられているWinbondのflash chipと、SOIC用のsocket adapterを注文したので、届き次第Raspberry Pi 3を使って実験する予定だ。

cf. [Neutralizing the Intel Management Engine on Librem Laptops – Purism](https://puri.sm/posts/neutralizing-intel-management-engine-on-librem-laptops/)

Shell scriptで計算する際の注意

Raspberry Pi 3 Model BでLED照明をPWM制御するshell scriptを書く為にちょっとした計算が必要になった。

このscriptに与えるのは0% (消灯)〜100% (フルパワー)の数値 (0-100)で、これを実際のPWM制御に使っている0-255に変換したい。つまり、percentage → 実際の数値の変換である。この時、percentageもPWMの数値も整数とする。

Shell scriptで計算するには主に次の3つの選択肢がある:

* expr
* bash/zshなどのbuiltin → $(( EXPR )) ※shebang注意 (/bin/shだと使えなかったりする)
* bc

exprは整数演算しかできないし、shell builtinは整数への丸め方が分からないのでbcを使っていたのだが、最終的には「小数点以下の切り捨てを回避できればどれでもok」だと分かった。

うまくいったやりかた

例題: 255の76%は193.8 (193)

expr

 % expr 76 \* 255 \/ 100

 193

exprに与える式はescapeしてある (*とか/とか)

shell builtin

zshで実験した:

 % echo $((76 * 255 / 100))

 193

exprと違いescapeする必要はない。

bc

 % echo "76 * 255 / 100" | bc
 193

最初試した間違っているやりかた

percentage = A / B * 100

という式から:

A = percentage / 100 * B

と変形してそのままimplementすると、percentage / 100の結果が小数点以下の数値になり、小数点以下の演算を扱えない場合に切り捨てられて0になる。例えばbcで:

 % echo "scale=0; 3 / 255 * 100" | bc -l
 0

となるのはこのため。無論、3 / 255 * 100 = 1.1765... なので (数学的には) この結果はおかしい (少なくとも意図した結果ではない)。

bcの場合はexprと違って小数点以下の数も扱えるのだが、この場合はscale=0の効果で 3 / 255 = 0.0039...が0になるので、その後から幾ら数を掛けようと0にしかならない訳だ。

そこで、乗算と除算は (実数の範囲では) 順序を変えても計算結果が変わらない性質を利用する。

A = percentage * B / 100

つまり、3 * 100 = 300 を計算してから 255で割れば、無理なく整数部分を取り出せる:

 % echo "scale=0; 3 * 100 / 255" | bc -l

 1

これが望んだ結果である。

蛇足

乗算の順序に拘るような学校教育を真に受けた子供達が、結果の同じ演算の順序を変えることを思い付かずにこの手の問題を解決できなかった、なんて理由でプログラミング教育や実際のコーディングに悪影響が出なければ良いなとつくづく思う。

まあ、大抵のプログラミング言語は小数点以下も扱えるし問題ないか……。

KeySnail userの行き着く先: Waterfox

Firefox 57が近々releaseされる (2017-11-14)が、それに伴いlegacyとされているaddonが使えなくなる。

FirefoxをEmacs風のkeybindで操作できるKeySnailもその一つである (ちなみにVi (Vim)風に操作できるVimperatorも)。

前のentryでこのことについて書いたが、対策はざっくり:

* ESRで当座を凌ぐ
* WaterfoxやPale Moonに移行してKeysnailを使い続ける
* 似た機能を提供するWebExtensions対応のものに乗り換える

である。

取り敢えず、現在使っているaddonを変える必要がないであろうWaterfoxを導入して試してみた。

Install

環境

* Intel Core i7 7600K
* Linux kernel 4.14rc6 (rc7でtroubleが発生し戻している、ちなみに最新はrc8)
* Debian Sid (amd64)

Prebuilt binaryからのinstall

手軽だし早いので特に理由がない限りこちらを勧める。

* Binaryを落として適当なdirectoryに展開する

cf. [Waterfox - The free, open and private browser](https://www.waterfoxproject.org/)

Source codeからのinstall

* 本家Fxはhg (mercurial)で管理されているが、Waterfoxはgitで管理されている
* git clone https://github.com/MrAlex94/Waterfox.git ※sizeが大きいのでshallow cloneが良いかもしれない

* Build systemはFxと同じなので./machを使う

* .mozconfigを眺めてみた所、default compiler (CC)はclangだった。そのままでも良かったがgccでbuildするよう書き換えた

うまくいかなかった点

* .mozconfigのprocessor数から並列buildの数を決める部分でコケた
* Build時のCPU使用率などをmonitorするpython scriptがコケた

それぞれ適当に対策した結果buildが通った。

./mach build → ./mach packageでtar.bz2を生成し、それを適当なdirectory (~/.waterfox/とか)に展開し、~/bin/waterfoxあたりにsymlinkを張っておくと便利。

既存のFxのprofileをimportする

* waterfox -ProfileManagerでprofile managerを開く
* 適当な名前 (または以前と同じ名前)でprofileを作る
* 一度waterfoxを終了する
* ~/.waterfox/以下にprofile directoryがあるので、copy元の~/.mozilla/firefox/以下あたりからcp -Rとかでcopyする eg. cp -R -f ~/.mozilla/firefox/default.XXXXXXX ~/.waterfox/default.YYYYYYY

cf.

* [古いプロファイルから必要な情報を復旧する | Firefox ヘルプ](https://support.mozilla.org/ja/kb/recovering-important-data-from-an-old-profile)
* [プロファイル | Firefox ヘルプ](https://support.mozilla.org/ja/kb/profiles-where-firefox-stores-user-data#w_firefox-acioaoaoaecucgciaaacceciaececaacdoacaaaoaeag)

動作確認

* waterfox -ProfileManager或いはwaterfox -P <PROFILE>でprofileを指定してinvokeする
* うまくいっていればbookmarkとかhistoryとかextension (addon)とかが引き継がれているはず

結果

* bookmarkやhistory、passwordなどが引き継がれていた
* addonもそのまま利用可能だった
* Flash (Pepper Flash)も動いた

思っていたよりもWaterfoxへの移行は楽に完了した。Sourceからのbuildではなく、prebuilt binaryをdownloadして展開すればもっと早く終わる。

KeySnailはもちろん、Tab GroupsとかFireGestures、Down ThemAll!、Tab Mix Plus、Tile Viewといったlegacyなaddonsも確認した範囲では正常に動作していた。既存のaddonsが必須な人はWaterfoxへの移行を検討する価値があると思う。

Firefox 57 (aka. Firefox Quantum)がやって来る

Mozilla Firefox 57 (Firefox Quantum)のreleaseが間近に迫っている (2017-11-14)。

既にdeprecatedとされている従来のadd-on (extension)が使えなくなるため、特に以前からのuserは大きな環境の変更を迫られる。

対策は大きく分けて次の通り:

* Firefox ESR 52を使って暫く環境を維持 (〜2018-06-26)
* WebExtensionsに対応した代替を見付けて新しい環境へ移行
* Firefoxから別のweb browserに乗り換える (Firefox系列 / 非Firefox系列)

ESRで暫く繋ぐ

主に企業user向けに提供されているESR版は、新機能の追加や抜本的な変更が (次のreleaseまでは)行われない。最新版であるESR 52は2018-06-26までsecurity updateの対応がなされる。

cf. <https://www.mozilla.jp/business/#esr>

Pros

* Firefox 52をbaseにしているので従来のadd-onも問題なく動く (はず)
* 移行の手間がそれほど掛からない
* 頻繁なupdateから開放される

Cons

* あくまで対症療法であり、何れは移行先を見付けなければならない

WebExtensionsの世界へ移行

今使っているadd-onやthemeなどの必要性や移行先を検討し、新しい環境へと移行する。

Addonやthemeに余りこだわりがないとか、使い始めたばかりで移行すべきものがないとか、customizeを全く／ほとんどしないuserに向いている。

Pros

* 根本的な対策であり今後暫くは継続的に使える環境が構築できる (はず)
* 改良されたFirefoxのuser experienceを満喫できる

Cons

* 様々にcustomizeしていたuserほど手間も時間も掛かる
* 便利に使っていたaddonやお気に入りのthemeの代替が存在しない

同系統のBrowserへ乗り換え

例えば、以下はFirefoxからforkしたbrowsersである:

* Waterfox (cf. <https://www.waterfoxproject.org/>)
* Pale Moon (cf. <https://www.palemoon.org/>)

XULやXPCOMといった技術が引き継がれるので「深い所まで自由にcustomizeできてこそFirefox」という人には向いている。

Pros

* (おそらく) 移行にかかる手間は少なくて済む
* 現在使っているaddonやthemeなどの資産をそのまま使える
* 見た目や操作体系が同じ

Cons

* 枯れた技術が保守されている状況なので大幅な性能の改善は見込めない
* Browserそのものshareが少ない (websiteが正式に対応していなかったりする可能性が高い)

全く別のBrowserへ乗り換え

現在使っているaddonやら何やらの代替が見付からない場合、いっそ全く別のbrowserに乗り換えてもかかる手間は変わらないかもしれない。

* Google Chrome (或いはChromium)
* Microsoft Edge (Microsoft Windowsのみ)
* Apple Safari (Apple macOS, iOSのみ)
* Opera
* Vivaldi
* Brave
* etc, etc ...

特にChromeはuser数が多くextensionsも充実している (と考えられる)。

Pros

* BrowserはFirefoxだけではないと分かる
* 真っ新な環境から始められる

Cons

* 検討すべき候補がありすぎて選ぶのに手間取る
* これまでの操作体系とかなり異なる場合慣れに時間がかかる
* 移行に手間がかかる (かもしれない)

SwissMicros DM42がcoming soon

2017-12-26追記: 発売され、手元に届いた (cf. http://typeinf-memo.blogspot.com/2017/12/swissmicros-dm42first-impression.html)

RPN方式の関数電卓でも名機と名高いHP-42Sのclone、SwissMicros DM42がそろそろ発売か？

cf. [SwissMicros | DM42](https://www.swissmicros.com/dm42.php)

しばらく前から開発中という話は聞いていた。楽しみ過ぎるが、サイズと価格がどのくらいなのかが気になる。

半導体技術の進歩でコアとなるprocessor他の部品はどんどん小型化しているが、一方で人間側のサイズには変化していないので、機器全体の行きすぎた小型化・薄型化には問題がある。

クレジットカードサイズより、オリジナルのHP-15Cと同じサイズのDM15Lが個人的には使いやすい。

あとはDM15Lみたいに機能表示のシルク印刷が剥れなければいいのだが……。

PostgreSQL 10への移行

PostgreSQL 9.6 → PostgreSQL 10への移行作業について。

Debian SidにPostgreSQL 10のrc1が入ったので移行した。

upgradeの手順は/usr/share/doc/postgresql-10/README.Debian.gzの"Default clusters and upgrading"にある通り。

cf. PostgreSQL 9.5→9.6へupgradeに伴うMediaWikiへの影響と対策
(https://typeinf-memo.blogspot.jp/2016/09/postgresql-9596upgrademediawiki.html)

PostgreSQLのupgradeに伴うdatabaseの移行手順

現行のdatabase serverを止める

% sudo service postgresql stop

※ps aux | grep postgresqlあたりで確認して止まっていない場合:

% sudo pg_ctlcluster 10 main stop

Install時に自動で作られた新しいversionの (空の)database clusterを削除

10をinstallした際に自動で作られたclusterをdrop:

% sudo pg_dropcluster 10 main

pg_upgradeclusterでdataを移行する

今回は9.6 → 10へ移行:

% sudo pg_upgradecluster 9.6 main

Portの変更

新しい側 (10)のport numberはinstall時に5433なので、これをdefaultの5432に変更する。うっかり忘れるとphp-fpmなど外部のprocessからdatabaseに接続できなくなる。

或いはclient側を新しいport numberに接続するよう変更する。

% sudoedit /etc/postgresql/10/postgresql.conf

新しいdatabaseを立ち上げる

% sudo pg_ctlcluster 10 main start

動作を確認した後、古い方のversionを削除する

必要に応じて。

共同通信デジタルとソニーによるバーチャルアナウンサー「沢村碧」

Amazonのtext-to-speech service (TTS)であるPollyを活用するBananaFMの取り組みを知って (cf. https://typeinf-memo.blogspot.com/2017/08/banana-fmaws-pollyfm.html)から数日、今度は音声に加えてキャラクターのアニメーションが付いた「バーチャルアナウンサー」の存在を知った (cf. [バーチャルアナウンサー「沢村碧」を実現する「アバターエージェントサービス」を提供開始 | 共同通信PRワイヤー](http://prw.kyodonews.jp/opn/release/201708024326/))。

バーチャルアナウンサーは「テキストを与えるだけで音声と、それに応じた (ニュース番組的な)動きが自動的に生成される」のが特徴。

YouTubeにuploadされていた動画を見たが、このTTSは自然で殆ど違和感がなかった。また、キャラクターの動きも適度に2次元寄りなのでやはり違和感がない。ここでうっかりリアル路線を求めると、いわゆる「不気味の谷」に突っ込んでしまうのだろう。

将来的には、複数の異なる「性格付け」を持つキャラクターを、例えば聞き役と解説役に分けて「対話形式」にしたりとかできたら面白そうだ。

この技術を応用して、6O & 21O (『NieR:Automata』)とか、レイシア (『BEATLESS』)とか、セリオ (『To Heart』)とか、御坂妹 (『とある魔術の禁書目録』)とかが興味のあるニュースを喋ってくれるようにならないものか……。

fcitx-skkのローマ字かな変換テーブルを改造する

fcitx-skkを使っていて、個人的に非常に使いづらかった点を修正した:

1. かな入力時に「!」を押した時に全角の「！」が出るようにした
2. かな入力時に「z 」(z+space)で全角スペース「　」を入力できるようにした

特に1.は重要で、「？」は全角なのに「！」は半角というdefaultのちぐはぐな状態は理解し難い。

手順

* 設定をhomedirにcopy
* 設定file (default.json)を修正
* fcitx-skkの設定を更新

設定例

~/.config/libskk/rules/以下に適当な名前 (MyRuleでもMyDefaultでも何でも良い)で設定をcopyする

 % cp -R /usr/share/libskk/rules/default/ ~/.config/libskk/rules/MyRule

お気に入りのtext editor (例ではvim)でdefault.jsonを修正する

 % vim ~/.config/libskk/rules/MyRule/rom-kana/default.json

ずらずらと並んでいるので、適当な場所に設定を追加したり、既存の設定を書き換える:
...
"z ": ["", "　"],

...

"!": ["", "！" ],

...

前述の通り、"!"に関しては半角の"!"から全角の"！"へ変更した。

fcitx-skkの設定を更新するには、fcitx-configtoolをterminal emulatorから叩いて実行するか、window manager (今時はdesktop environmentかな)の設定menuの何処かにそれっぽいものがある (と思う)。

configtoolにて:

* SKKを選択して設定ボタンを押す → SKKの設定windowが出る

* "Dictionary and Rule" → Dictionary Managerのwindowが出る

* Ruleのdrop-down menuの中に、適当につけた名前 (eg. MyRule)が見付かるので選択

* Windowの下の方にあるsave buttonを押す

* configtoolを閉じる

以上で設定が反映される。

CFMの役割と自動化への取り組み

CFMの役割

BananaFMの取り組み (Amazon PollyベースのTTSの導入)を知って最初に思ったのは、地元のコミュニティFM局の大雨への対応だった。

1日積算で150mmに達する激しい降水が目下発生していて、気象庁から記録的短時間大雨情報とかが出ていても、それについて何ら触れることなく通常通り録音した番組の放送をしていた。幸いにも今回は目立った被害は出なかったが、ふと「こんな状態で本当に非常時に対応できるのだろうか？」と心配になったのだ。

3.11以降各地に設立されたCFM局は「防災」をその目的の一つしたものが多いし、地域によってはCFM局を従来の (コストのかかる)防災無線代わりに使おうと取り組んでいたりしている。その場合、日頃から使い慣れていないものを非常時に使い熟せるかは疑問だ。

ただし、ずっとそのCFM局を聞き続けていた訳ではないので、何処かしらのタイミングで触れられていた可能性はある。ユーザー (リスナー)側から見れば、他に幾らでも大雨などの情報を流しているメディア (或いはチャンネル)がある筈なので、必要なら積極的にそれを探しに行けば良いだけの話でもある。

そもそも、大雨など災害が発生している最中にできることは限られている。その後の避難或いは復旧や復興の局面でCFMが果たす役割が大きいのは分かるので、情報の速報性だけで評価すべきでない。

人手が少なく小さなCFMだからこそ整えるべき「仕組み」

地域に密着した (細かい)情報を随時流せる小回りの良さこそがCFMの最も良い所なので、全国はもちろん県域局でも取り上げにくい局地的な気象変化は大規模な災害発生時の訓練になると考えて積極的に流してほしいと思う。

そのような放送の姿勢やありかたが、徐々にではあっても地域住民やリスナーの「いざという時に頼りになる」という意識を作って、日頃から協力しようとか、或いは情報を提供しようという動機になる。

そのための仕組みは、別に自動化しなければ成立しないものではない。けれど、少人数で運用されているCFMの場合は特に、一人あたりにかかる負担が大きくなる。それを可能な限り低減して人でなければならない仕事に集中できる環境を作る、或いは人が対応するのに必要な時間を稼ぐ仕組み作りは、中長期的に事業を維持するための大きな武器になる。

Pollyでも、事前録音の音声でも構わないのだが、何かしら情報を受け取ったら自動的に放送に割り込む仕組みは、人手の少ないCFMだからこそ積極的に取り入れていく必要があると思う。

ぼくのかんがえたさいきょうの災害時放送

架空の豪雨災害を例に、CFM局が災害時果たすべき役割について考えてみた。

災害発生前

* 人員の確保
* 気象情報 (大気の状態が不安定、etc)を伝える
* 避難或いは安全確保について伝える
* 無理のない範囲での情報提供を呼び掛ける (リスナーにも、提携している他業種や行政にも)

災害発生直前 (降りはじめ)

以下のアナウンス:

* 〜地区 (或いは〜市とか〜町)で大雨が降っている

* 一通りの注意事項テンプレ (田畑や川を見に行かないとか外に出ないとか)
* 気象庁が出すであろう記録的短時間大雨情報や土砂災害警戒情報

災害発生

明らかになった情報をまとめつつ随時流す:

* (大抵は提携なり出資している筈の)地域行政機関が出すであろう避難に関する情報

* 開設されている避難所の情報、或いは安全確保に関する情報

* リスナーや警察・消防からの被害情報 (道路の冠水とか通行止めとか)

避難〜復旧

何かしら被害が発生し、中長期的に避難などが必要になった場合:

* 停電などライフラインに関する被害と復旧に関する見通し
* 保険金や見舞金の支払いに関する情報
* 公共料金や税金などの猶予の情報

* 相談先がどこにあるか

Banana FMにおけるAWS Pollyの応用事例に見るコミュニティFM局の今後

和歌山県のコミュニティFM局「Banana FM」が、7/31からAmazonの提供するクラウドベースのテキスト読み上げサービス「Polly」(cf. [よくある質問 - Amazon Polly | AWS](https://aws.amazon.com/jp/polly/faqs/))を利用した「ナナコ」による放送をスタート (cf. [人工知能　ナナコの放送が始まりました｜Banana FM 87.7MHz](https://877.fm/new.php?id=94))。

慢性的に人手不足だったり、仮にそうでなくても様々な問題から24/7な対応が難しかったりする小規模なCFM局は、BananaFMの取り組みを参考にして似たような手段を取るんじゃないかと。

緊急地震速報にしても、特別警報にしても、避難に関する情報に関しても、深夜とか祝祭日とか年末年始とかに関係なく起こりうる事態すべてに、地方の小さいCFM局が対応するのは本当に難しいと思う。だからこそ、情報が出たら人間が居なくても (或いはワンオペ状態でも)自動的に流す仕組みが必要で、それとPollyのようなtext-to-speech serviceは相性が良い。

そのうち、Twitter上のbotみたく、24/7でTTSが喋り続けるラジオなんてものができたりするんだろうか (或いはもうあったりするのかも)。

非常時の情報収集手段としてのラジオ

非常時の情報収集手段としてのラジオについてちょっと考えてみる

なぜスマホだけではだめか？

東日本大震災とか、近年多発している豪雨災害とかでも、放送による情報入手で一番確実なのはラジオだと思っている。その理由は大きく2つあって、1つ目は原理的に輻輳が発生しない放送であること、2つ目は消費電力が小さいので長時間の利用が可能なこと。

スマートフォンは通信手段にもなるし、(機種によっては)ワンセグも見れるし、アプリを入れておけばラジオ番組も聞けるし、ライトにもなるしと万能だ。万能な物は日常生活では持ち物が減るなど利点が多いが、非常時は少々勝手が違ってくる。

一番の問題は電源で、モバイルブースター (大容量バッテリー)も随分普及したが、それでもバッテリーの持続時間が十分とは言えない現状がある。生存性を考えると、最低限、明り (ライト)とラジオは別口で専用品を持つ方が、機能別にデバイスを分けられる (なくしたり壊したりすることへの抵抗性)点でも、バッテリーの持ちの点でも望ましい。

理想的な電源

非常時に確実に使えることを考えると「電源が何か」はとても重要なファクターだ。非常用持ち出し袋に入れておいたラジオや懐中電灯が電池切れで使えない、なんてケースは枚挙に暇がない。電池が切れているだけならばまだマシだが、場合によっては液漏れによって故障している場合すらある。乾電池は抜いて別に保管しておくことを勧める。

ラジオで言うと、最も入手性の良いAA×1で長時間聞けるのが理想的ではある。そう言う意味で、容量は大きくても入手性の悪いD (たぶん最も悪いのはC)より、AAやAAAを電源にするのは理に適っていると思う (応用範囲も広いし)。

ちなみに、手元にあるICF-801はC×3だが、スペーサと金属製のゼムクリップ (これがないと導通しない)を使ってAA eneloop×3で運用している。

持ち歩きに向いたカードサイズのラジオ (SONY ICF-R351とか)では、AAA×1或いはAAA×2が標準的である。

日常的に使ってこそ、非日常でも頼りになる

あと重要だと思うのは、日常でラジオ (のハードウェア)を使う、ラジオを聞くことだと思う。非常時に役立つからと言っても、日頃から支えているリスナーがいなければそもそも事業として立ち行かない。また、どの局でどんな情報が得られるのか傾向を掴んでおくと情報の取捨選択もやりやすい。

東日本大震災の時は特に酷かったが、どこもかしこも自粛ムードの中で、延々と災害の情報とACのCMばかり見せられ聞かされるのは、例え直接的な被害がなくとも気が滅入る。全く関係ない日頃の番組や、音楽を聞きたくなる。そういう時に、複数のチャンネル (複数の局、時間帯、或いはメディア)を知っていることは強みになる。

SONYのラジオICF-801がdiscontinuedな模様

SONY (製造は下請けである十和田オーディオ)の日本製ラジオであるICF-801 (cf. [ICF-801 | ラジオ／CDラジオ・ラジカセ | ソニー](http://www.sony.jp/radio/products/ICF-801/))が生産完了 (discontinued)っぽいと今更ながら知った (7/18頃に発表されていた？)。

以下のページでICF-801に「生産完了」のマークがついていると確認できる → [AMラジオの番組がFM放送でも聴ける ワイドFM（FM補完放送）！ | ラジオ／CDラジオ・ラジカセ | ソニー](http://www.sony.jp/radio/radio_sony/fm/)

このモデルのように長く生産されて「時代によって証明されている」モデルは細々とでも続けて欲しいと思ってしまうけれど、企業的には儲けが出なければどうしようもないって所なのだろうか。

後継機種とされているICF-506 (cf. [ICF-506 | ラジオ／CDラジオ・ラジカセ | ソニー](http://www.sony.jp/radio/products/ICF-506/))では、基本的な操作体系に変更はないようだが、部品点数削減のためかAM/FM切り替えスイッチに電源機能が統合されていたり、表示板のバックライトが無くなっていたりと、合理性は理解できるが「なんだかなぁ」と思う点がある。一方で、電源がC×3ではなくAA×3になっている点は、稼働時間が減りはするものの、電源の入手性という点から堅実な改善点だと思う。

カードサイズのシンセサイザーチューニングラジオICF-R351もいつの間にやらカタログから消えているし (後継機種はICF-R354MかSRF-T355あたり？)、世代交代は進んでいるんだなと。SRF-T355は、ワンセグの音声が受信できるXDR-63TVと共通点が多いようで、一度使ってみたい気はする。

fcitx-skkで「ゐ」や「ゑ」を入力する方法

defaultの変換テーブルでは:

* xwi → ゐ (ヰ)
* xwe → ゑ(ヱ)

fcitx-skkはlibskkを利用しているので、defaultのかな変換テーブルは、/usr/share/libskk/rules/default/rom-kana/default.jsonにある。これを見るまで入力できることすら分からなかった。

このmappingが気に食わなければ、適当な場所にcopyして内容を変更した上でそれを使うように設定すればoverrideできる (cf. [fcitx - Omong Kosong Lagi](http://www.lapangan.net/omongkosong/tag/fcitx/))。

ちなみに、fcitxってどう読むかご存知だろうか。ファイティクス、だそうな。

Raspbianで起動時にscriptを自動実行させる

Raspberry Pi 3 Model B (RasPi3)で部屋のLED照明とか、RasPi3自身の冷却ファンのPWM制御とか、室温の計測&loggingをさせている。それらのscriptを起動時に自動実行させたくなったので調べてみた所、以下のwebpageがとても参考になった (というかそのものズバリ)。

* [Raspberry Piでプログラムを自動起動する5種類の方法を比較・解説](http://hendigi.karaage.xyz/2016/11/auto-boot/)

採用した方法と理由

題にもあるように5つの方法が紹介されているが、個人的な用途やpros/consを考えると
cronのjobとして登録する方法が一番のお勧め。

* 登録と削除がcrontab -eで出来て楽
* 起動するscriptはuser権限で起動する

cronを使う時の問題点 (2017-08-25追記)

RasPi3はRTCを持たないので再起動時した直後など暫く時刻がズレていることがある。室温・湿度などをCSV fileに記録する際にはこれが問題となり、本来時系列順であるべき所がいきなり時間が戻ったりする。

19:01:03 ...
19:01:04 ...
18:30:33 ... <--- ここから...
...
18:30:52 ... <--- ここまでおかしい
19:03:12 ... <--- NTPで補正された
19:03:13 ...

cron側でNTPで時刻が補正される迄実行しないようにできれば一番良い。試してはいないが、systemdを使っているのだから依存関係を適切に設定すればNTPの実行後にcronを立ち上げられるような気もする。

取り敢えずsensorから値を取得するscriptの冒頭で、現在時刻とlog fileのmtimeとを比較して、現在時刻がmtimeよりも前 (eg. 現在=16:30でmtime=17:00)なら異常と判断してNTPによるsyncを待つようにした。

発展

もしこれで足りなければ (super userで動かしたいとか)、/etc/rc.localに細工 (exit 0の前あたりに追記)する方法を取る。

正当なやり方はsystemdのserviceとして登録する方法なんだろうけど、たかが小さなscriptを自動実行させたいってだけであんな長ったらしい設定fileを書くのは面倒すぎる。

補足

検索時に気になったのは、あちこちに残っている古い情報が検索の上位に出て来ること。例えばRaspbianのdefault init systemがsystemdに移行したとかの事前情報が無いと、上手く起動しないとか、設定fileが無いとか、無駄に混乱する原因になりそう。

libc6 (glibc)をgcc-7でbuildする (@Debian Sid)

Debian Sidのgcc-7 (7.1)でlibc6 (glibc)をsource packageからbuildしようとすると、-werrorの効果でwarningがerror扱いになり途中で止まってしまう。これは使い方によっては有用なoptionだが、取り敢えずbuildを通したい時には面倒なので細工してみる。

glibcの./configure scriptには--disable-werrorという便利なoptionがあるのでこれを与えれば良さそうだと分かる。問題は、dpkg-buildpackageでbinary packageをbuildする際にどのようにこのoptionを./configureに渡すか。

まず最初に思い付いたのがdebian/rulesに適当な記述を加える方法だが、./configureに直接optionを渡せそうな設定項目が無かった。

次に目を付けたのがdebian/sysdeps/amd64.mkで、これはamd64 (aka. x86_64, x64) platformにて利用されるbuild script。中身を見てみると、丁度利用できそうな部分があったので次のように書き換え:

extra_config_options = --enable-multi-arch

↓

extra_config_options = --enable-multi-arch --disable-werror

あとはいつも通り、top levelで:

 % dpkg-buildpackage -us -uc -B -d -rfakeroot -j8

あたりを発行しbinary packageをbuild。

Intel CPUの殻割りとリキプロ化

今更ながら手持ちのCPU 2つを殻割り (delid)し、TIMをLIQUID PROに変えてみた。

動機

メインマシンの6700KでCPUに負荷を掛けるとパッケージ温度が70度Cを超えてしまい夏場の使用が不安である。

Shuttleのキューブ型ケースを利用しているのでCPUクーラーの交換は難しい。そこで、いわゆる「グリスバーガー」を解消すれば状況が改善とすると考えて殻割りすることにした。

定格運用でも、いわゆる「熱ダレ」(thermal throttling)が起き難くなることが期待できる。

使った物

対象CPU

• Intel Core i5-3330
• Intel Core i7-6700K

3330はoverclockできない（マザーボードもH61）ので殻割りする意味は余りないが、いきなり6700Kで作業するのが怖かったので練習がてらやってみた。

事前調査 (3770Kと6700Kについて)どちらもヒートスプレッダ内部にチップコンデンサ等が実装されていないので、難易度は低いと思う。

道具類

• カッターナイフ (今回はその辺にあったものを利用したので刃は厚さ0.39mm。OLFAから壁紙カット用として販売されている0.2mmぐらいの薄い刃を勧める)
• テレホンカード (厚さ0.27mm。ボロボロになるので使用済み、もしくは不要なポイントカードなどがあればそちらを勧める)
• LIQUID PRO (液体金属。もしくはクマメタル)
• ブラックシーラー (ゴム系接着剤。本来は車のボディの補修に使う物だが、殻割りする人々の間でも広く用いられている)
• マスキングテープ (裏側の電極やチップコンデンサなどの保護のために利用。この用途にセロハンテープなどを使うと接着剤が残るのでNG。一方でゴミ取りには少々接着力不足)
• 綿棒 (CPUグリスやダイに残ったTIMを掃除する、LIQUID PROを塗るなど)
• 爪楊枝 (基盤やヒートスプレッダの内側に残った接着剤を擦り取ったり、ブラックシーラーを塗る時に使う)
• ティッシュペーパー (手に入るならキムワイプとかの方が良いだろう。一応のためダイは綿棒で掃除した)
• 燃料用アルコール (毒性の問題があるので無水エタノールを用いた方が良いが代用)
• 金属板 (静電気でCPUを壊さないように作業場として利用。気休め)
• エアダスター

作業を終えて、あったら良かったなと思ったもの:

• 絶縁テープ (6700Kはヒートスプレッダ内の基盤に剥き出しの電極があるのでそこを覆う。注文したが届いていないので今回はブラックシーラーで代用)
• セロハンテープ (ヒートスプレッダの位置を固定したり、飛び散った接着剤を掃除するのに便利。今回はマスキングテープで代用)

手順

• CPUのヒートスプレッダの隅から基盤との間にカッターの刃を入れる
• 或る程度入ったらテレホンカードやポイントカードを差し込んで接着剤を切っていく
• TIMと接着剤を除去してLIQUID PRO (もしくはクマメタル)をダイの上に塗る
• ヒートスプレッダの周囲にブラックシーラーを塗り元の位置に固定
• 乾燥させて固定する
• マザーボードに取り付けて動作確認

感想

• 最初にカッターの刃を入れる時が一番緊張する。角度を間違えると基盤を傷付け故障の原因になるので入らなくても無理をしない
• カッターだけでやる人もいるがテレホンカード類を用意した方が安全。或いは殻割り専用ツールを使う
• 3330でも6700KでもTIMは完全に乾燥してボロボロになっていた。これは冷えない訳だ
• ヒートスプレッダを綺麗に戻すのは結構難しいが、最初に写真を撮っておいてそれを参考にすると良いと思う。最終的には取り付けられれば問題ない
• 本来なら或る程度乾燥の為に時間を置くべきだが、壊していないか確認したくなり早速取り付けてしまったが今の所問題なく動いている

結果

試しに負荷を掛けてみた。室温は23度C程度。CPU温度はpackage temperature。

i5-3330

マシン構成

• OS: Microsoft Windows 10 (64bit)
• CPU: Intel Core i5-3330
• Mem: DDR3-1333 16GBtyes
• GPU: HIS (AMD RX480)
• HDD1: WD5000AAKX (500GBytes)
• HDD2: WD30EZRX (3TBytes)
• 適当なケースがなくバラック状態

主にゲーム用として使っているのでCINEBENCH、手持ちのゲームなどを試してみたが60度Cを超えない。

手持ちのソフトはCPUよりGPUパワーを必要とするタイトルばかりなので、AMD RX480がbottleneckになっている感じ。当然ながらCPU負荷も温度も上がらない

6700K

マシン構成

• OS: Linux (Debian/Sid) w/ Linux kernel 4.10.10 (64bit)
• CPU: Intel Core i7-6700K
• Mem: DDR4
• GPU: Onboard
• SSD: SATA 512GBytes
• HDD: WD 8TB

Linux machineで行う負荷の高い作業は:

• Source codeからのbuild (Linux kernel, Mozilla Firefox, etc)
• 3D graphics (iGPU)を多用するsoftware (Stellarium, Celestia, etc)
• ffmpegなどによる動画encodingなど

※以下、PC内温度32度C

• Linux kernel (v4.10.10)、Mozilla Firefox (55.0a1, 54.0a2)などをbuildして60度Cを超えない
• Celestia, Stellariumなどを実行しても40度Cを超えない
• ffmpegでのsoftware encoding (h264)では最大63度C。QSVを利用したtranscoding (h264, rescaling)なら40度Cを超えない

これからの展望

巷で話題のAMD Ryzenならソルダリングなのでこんな手間は必要ない。

利益率を上げる為に行われる製品の製造プロセスの見直しは必要だが、さすがにやってい良いことと悪いことがあると個人的には考えている。Intelは（せめてK付きとかは）ソルダリングに戻してほしいし、AMDにはこのままソルダリングで続けて欲しい。

NieR:Automata Original Soundtrackのヨコオタロウ氏のメッセージをshellとnkfでdecodeする

NieR:AutomataのOriginal Soundtrackに付属するブックレットに、ディレクターであるヨコオタロウ氏のメッセージが16進数で記載されており、（大抵の人間は）そのままでは読めない。

ネット上では既に多くの先人達が解読しており、URL等で使われる「パーセントエンコーディング」であると知られている。これをshell scriptとnkfを使ってdecodeしてみる。

なお、メッセージの内容については一切触れない。

実際の作業

* 写真を取る／スキャンする
* OCRで文字に変換
* 16進数文字列→日本語

最も面倒だったのがOCRで文字に変換する部分だった。写真の撮影のしかたが悪かったのもある。今回はGoogle driveにuploadしてOCRにかけ、目視で比較して修正するという方法を取らざるを得なかった。

一旦文字列になってしまえば後はnkfに掛けるだけである。

% echo '\n＜16進数の文字列＞' | fold -s2 | tr '\n' '=' | nkf -WwmQ

まず、foldで2文字ごとに区切る。次に、trで改行コードを'='に変換する。最後にnkfに文字列を渡してdecodeする。

参考URL

* [shell で4文字づつ切り出す方法 - Qiita](http://qiita.com/mapk0y/items/51e6765add9b79264714)
* [40.Linuxのコマンドから行うURLエンコード、URLデコード](http://www.garunimo.com/program/linux/linux40.xhtml)
* [パーセントエンコーディング - Wikipedia](https://ja.wikipedia.org/wiki/%E3%83%91%E3%83%BC%E3%82%BB%E3%83%B3%E3%83%88%E3%82%A8%E3%83%B3%E3%82%B3%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0)

SwissMicros DM15Lのfirmware v22がreleaseされていた

(2017-06-16更新) Firmware V23がreleaseされていたのでupgrade (詳細はhttp://typeinf-memo.blogspot.com/2016/07/swissmicros-dm-15lfirmware-upgrade.htmlにて)。

WP 43Sのhardwareを開発していることについて何か書いてないかとSwissMicrosのwebsiteを覗いてみたら、DM15L (及びその他製品の) firmware v22がreleaseされていた。

前回同様に無事update完了。WP 34Sもこれくらい楽だったら良かったのだが……。

Debian sid/experimentalのgcc-6/gcc-7でLinux kernelがbuildできない問題とその対応

Linux kernel 4.10.1がreleaseされたのでbuildしようとしたら……

>   LD      vmlinux
> kernel/built-in.o: In function `update_wall_time':
> (.text+0x5fa0a): undefined reference to `____ilog2_NaN'
> Makefile:969: recipe for target 'vmlinux' failed
> make[1]: *** [vmlinux] Error 1

つい数日前 (2/20)はbuildできた4.10.0もダメだった (@gcc-6, gcc-7)。

`/var/log/aptitude`を確認してみた所、Sidのgcc-6 (6.3.0-8)を2/22に、experimentalのgcc-7 (7-20170221-1)を2/24にそれぞれ更新していた。

"linux ____ilog2_nan"でGoogle検索したら、次のpageを発見:

詳しくはよく分からないが、Linux kernel内部で利用されている`ilog2()`をcompileする際にGCCのtree-optimizationで問題が発生している模様 (cf. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72785)。どうやらkernel側のbugっぽい。

既にworkaroundがあり`include/linux/log2.h`へのpatch (cf. http://lists.infradead.org/pipermail/linux-arm-kernel/2016-October/462224.html)を当てた所buildできた。

Debian unstableでFirefox 50.1.1 (release)とFirefox 52.0a2 (aurora)のbuildが失敗する

2017-01-18追記: Firefox 51.0で修正されbuild可能になった

Debian unstableでFxをsourceからbuildするとconfigureの段階で転ける。

> cannot determine icu version number from uvernum.h header file

libicu関連。いつからだったのか分からないが、libicuのversion情報が取得できないせい (因みにunstableが57でexperimentalが58。stableは55)。

firefox-release (50.1.1)は56にdependしており、firefox-aurora (52.0a2)は58にdependしている。何れもsystemにinstallされているlibicuを見付けられず、そこでbuildが止まる。

取り敢えずworkaroundを発見したので暫く様子見。

firefox-aurora

experimentalのlibicu58関連にupgrade。libicu57は別の色々なpackagesがdependしているのでそのまま。

build/autoconf/icu.m4を変更 (72行あたり):

    version=`sed -n 's/^[[:space:]]*#[[:space:]]*define[[:space:]][[:space:]]*U_ICU_VERSION_MAJOR_NUM[[:space:]][[:space:]]*\([0-9][0-9]*\)[[:space:]]*$/\1/p' "$icudir/common/unicode/uvernum.h"`

↓

    version="58"

icuのversionを調べるscriptが何故か失敗する (consoleでやると上手くいくのだが)ので、versionを決め打ちする (この場合はexperimentalの58)。

firefox-auroraについてはこれだけでbuildが通る。

firefox-release

firefox-release (50.1.1)は少々面倒:

* build/autoconf/icu.m4を変更 (versionを58で決め打ち)
* cp -i /usr/include/unicode/uvernum.h /usr/include/unicode/uversion.h intl/icu/source/common/unicode/ → localで持っているversionが古いのでsystemのlibicu58を使う (一応のため)
* cp -i /firefox-aurora/config/external/icu/data/icudt58l.dat config/external/icu/data/ → icudt58l.datが無いとbuildが転けるのでauroraの(libicu58用)をcopyしておく

これで取り敢えず./mach buildが通って、./mach runで動いた。ミソは多分icudt58l.datをauroraから貰って来る所だと思う。

Emacsのdiff-modeでauto-refinesの仕様変更とworkaround

diff-modeの移動に関する変更があった後、間も無く別のcommit (e5ef59b87da5c2ddfa22f7342efe29b3eea6ed97)でauto-refinesに関する仕様も変更されていた。

移動が確実に行われた時のみ、細かい変更点 (refines)をcoloringする挙動になった。これに伴いauto-refinesの関連codeが別の場所に移され、以前取った方法では移動するだけではrefinesへのcoloringが適用されなくなった。

対策として、「Emacsのdiff-modeでdiff-hunk-prev/next等の挙動が変更された」で紹介したcodeをベースにして以下のように変更し解決した:

(with-eval-after-load "diff-mode"

  (defun my-diff-hunk-next (&optional count)

    (interactive)

    (diff-hunk-next count nil)

    (diff-refine-hunk))

  (defun my-diff-hunk-prev (&optional count)

    (interactive)

    (diff-hunk-prev count nil)

    (diff-refine-hunk))

  ;; key bindings

  (define-key diff-mode-shared-map "n" 'my-diff-hunk-next)

  (define-key diff-mode-shared-map "p" 'my-diff-hunk-prev))

やっていることは、それぞれのfunction内で移動するためのfunctionを呼び出した後に、coloringする為のdiff-refine-hunkを呼び出すだけである。