Hatena::ブログ(Diary)

児童小銃 RSSフィード

みえない自由が欲しくて
みえない銃を撃ちまくる
THE BLUE HEARTS 「TRAIN-TRAIN」

なんばりょうすけの仮住まいです

連絡先: rna◎cyber●email●ne●jp


プライバシーポリシー


2017-02-15

[][] 「はてなブログライター」を作りました

はてなブログ用の「はてなダイアリーライター」(http://www.hyuki.com/techinfo/hatena_diary_writer.html) 的なコマンドラインツールを作りました。GitHub で公開しています。

お知らせ

  • 2017-02-16 00:30 バグがありました。まだ使わないで!
  • 2017-02-16 01:10 修正しました。既に使ってしまった人は README.md の「注意事項」を参照して投稿データファイルを修正してください。

あらまし

はてなダイアリーライター(以下はてダラ)は2004年に結城浩(id:hyuki)さんが公開されて以来、僕も勝手に略称を考えたり勝手にパッチを送りつけたりしつつ愛用し続けて、今まさにこの時も使っているのですが、はてなブログに対応した同様のツールというのがなさそうなので作ってみました。ruby は不慣れなので色々アレかもしれませんがお手柔らかに…

というか、はてダラがないためにダイアリーから離れられなかったようなものなのですが。でも、ダイアリーの方はモバイル用の表示がダメ過ぎて、スマホで読まれることがほとんどだと思われる今時のブログ事情を考えると、はてなブログに移行せざるを得ないな、しかたない、作るか、と。

仕様とか

はてなブログライターでははてなブログの AtomPub API 経由で記事を投稿します。API 操作には id:lyokato さんの開発した AtomPub モジュール atomutil を使用しました。そのままでは投稿に失敗することがあったので一部 monky patch で対処しています。*1

はてダラとよく似た仕様になっていますが、いくつか違うところもあります。

  • エントリの書式、エントリファイル名の書式が変わった
  • エントリのテンプレートを生成するサブコマンドを用意した
  • 下書きの投稿、下書きの公開ができるようになった
    • 公開した投稿を下書きに戻すのはできません…

詳細は README.md を参照してください。

内部的には touch.txt とエントリファイルの更新日時を使った更新検出はやめて、エントリファイル毎に最終投稿時のファイル更新日時とハッシュを記録して、エントリファイルが新しくてもハッシュが一致しないなら投稿しないようにしました。これで日記ファイルをコピーして新しいHDDに引っ越したら次に投稿した時に大量の記事が再投稿(更新)されるという悲劇はなくなるはずです。

ただし、あいかわらず投稿先のエントリの内容をチェックしていないので、Webやアプリからエントリを更新した場合でも、はてなブログライターから更新をかけると問答無用で上書きしてしまいます。

出先などからスマホのはてなブログアプリからエントリを投稿したり投稿済みのエントリを修正したりというシーンは結構ありそうなので、双方向に同期できるようにしたいところですが、そのへんは今後の課題です。

なお、「はてダラスプリッタ(hws.pl)」に対応するツールは作っていません。僕自身 diary.txt にダラダラ書いて hws.pl で切って hw.pl で投稿、という流れでずっとやってきたのでなんとかしたかったのですが、記事と投稿先アドレスの対応が投稿後に決まるため、どうにもうまくできませんでした。

とりあえず新しいブログで使っています。まだ始めたばかりなのでエントリが増えた時にまともに動くかわかりませんが…

*1Ruby 2.3 ではてな公式のサンプルを試したところ /usr/lib/ruby/2.3.0/rexml/text.rb:396:in `gsub': incompatible encoding regexp match (UTF-8 regexp with ASCII-8BIT string) (Encoding::CompatibilityError) で投稿できず、encode('BINARY', 'BINARY') をやめたらそこはクリアしたのですが、atomutil.rb:764:in `=~': incompatible encoding regexp match (ASCII-8BIT regexp with UTF-8 string) (Encoding::CompatibilityError) に。結局 Content#body= を上書きして使用しています。

2017-02-08

[][][] mozc のカナ配列をカスタマイズする

以前少し触れたことがあるが、僕は日本語入力をカナ入力、それも NeXT カナ配列で入力している。キヤノン販売(当時)が NeXT の日本語版を出した時についてきたキーボードの配列がそれで、英数は US キーボードの配列で、カナはJISカナ配列をキーの少ない US キーボードに合わせて一部修正したものになっている。

NeXT カナ配列は Mac の US キーボード用のカナ配列とも微妙に違うもので、NeXT 以外でこの配列に対応した OS や IME を見たことがない。それなら Mac 配列なりに乗り換えればいいようなものだが、日本語入力を本格的に身につけたのが大学時代に情報処理教育センターの NeXT でやっていたチャットで、忘れがたい思い出と共にあった NeXT カナ配列には拭い切れない愛着があり、いまでもどうにかして NeXT カナ配列を再現して使っている。

NeXT カナ配列による日本語入力を実現する方法は OS 毎に異なる。Windows ではシェアウェアの Keylay00 を使って IME 使用時のキー配列をカスタマイズすることで、Mac では Karabiner で ATOK に入力されるキーを入れ替えることで、Linux では以前は ATOK X for Linux の IIIMF まわりのソースコード(この部分は OSS なのでソースが CD-ROM に同梱されていた)の一部を書き換えてリビルドし、ATOK X の共有ライブラリを差し替えることで、実現していた。

しかし最近の Linux デスクトップ環境では IIIMF を使い続けるのは厳しい状況で、Ubuntu 15.04 から fcitx-mozc に乗り換えた。この時は mozc のローマ字カナマッピングを工夫して NeXT カナ配列を再現してごまかしたのだが、mozc 的にはローマ字入力なので変換候補に意味のない英数文字列がいくつも出てきたり微妙な使い勝手なのでなんとかしたいと思っていた。

また、Karabiner が macOS Sierra に当分対応できないという状況があり、今はアップグレードを保留して凌いでいるものの、いつまでもそういうわけにもいかないので、mozc または Google 日本語入力に乗り換えて、mozc のソースを改造してカナ配列を変更できるのではないか、ということを思いついた。

そういうわけで mozc のソースを斜め読みしつつ関係しそうなところを探してみたところ、だいたい以下のようなことがわかった。

  • fcitx-mozc は src/unix/fcitx/fcitx_key_translator.cc に KanaMap があり、そこを書き換えればよい。
  • emacs で mozc.el を使う場合は src/unix/emacs/mozc.el に US キーボード用のカナ配列キーマップがあり(mozc-keymap-kana-101us)これを書き換えるか、別途キーマップを定義して mozc-keymap-kana に setq してやればよい。
  • Mac では src/data/preedit/mac-kana.tsv を書き換えればよさそう。残念ながらこのファイルは実行時に読み込まれる設定ファイルではなく、ビルド時に Objective-C のヘッダファイルに変換されて実行ファイルに組み込まれるらしい。

ということで、とりあえず Ubuntu 16.04 でかな入力を NeXT カナ配列で入力できるようにしてみた。

$ mkdir fcitx-mozc-build
$ cd fcitx-mozc-build
$ apt-get source fcitx-mozc
$ sudo apt-get build-dep fcitx-mozc
$ cd mozc-2.17.2116.102+gitfd0f5b34+dfsg
(エディタで debian/changelog を修正。バージョン 2.17.2116.102+gitfd0f5b34+dfsg+rna のログエントリを追加)
(エディタで src/unix/fcitx/fcitx_key_translator.cc を修正)
(エディタで src/unix/emacs/mozc.el を修正)
$ dpkg-buildpackage -rfakeroot -uc -b
$ cd ..
$ sudo dpkg -i  *_2.17.2116.102+gitfd0f5b34+dfsg+rna-1ubuntu1.1_amd64.deb

必要なのは fcitx-mozc と emacs-mozc だけなのだが、バージョンを変えたせいで依存関係のしがらみで mozc 関係は全部インストールすることになった。

インストール後、一度ログアウトしてから再度ログインして mozc をカナ入力モードにすると、NeXT かな配列で入力できるようになった。emacs の方も OK。

誰もそのままでは使わないとは思うけど参考になるかもしれないのでパッチを公開しておく。

あとは Mac。それに Windows の方も Keylay00 は今後サポートされないようなので、他のキー入れ替えソフトを使うか、Windows でも改造 mozc に乗り換えるべきか…

2016-08-28

[][][] Ubuntu 16.04: キーボードのカスタマイズ設定

メインPC を Ubuntu 16.04 にアップデートしたらキーボードのカスタマイズが 15.04 の時の方法では機能せず、少し変更が必要になった。

変更点

Ubuntu 15.04: キーボードのカスタマイズ設定」の記事で紹介した手順は必要だが、さらにもうひと手間必要になる。

以前の記事ではキーマップファイル ~/.xkb/keymap/hhk はテスト用に作成しただけだが、Ubuntu 16.04 ではこれが必要になり、デスクトップにログイン後に xkbcomp -I$HOME/.xkb ~/.xkb/keymap/hhk $DISPLAY を実行しないとキーマップが反映されなくなった。

xkbcomp の設定だけでは以前と同様、入力メソッドを fcitx-mozc に切り替えるなどの操作でキーマップがリセットされてしまう。

デスクトップログイン時に xkbcomp を実行するため、まずシェルスクリプト ~/bin/hhk_setup.sh を作成する。

#!/bin/sh
xkbcomp -I~/.xkb ~/.xkb/keymap/hhk $DISPLAY 2>/dev/null

これを起動させるために gnome session のスタートアップで起動するデスクトップファイル ~/.config/autostart/hhk_setup.desktop を作成する。

[Desktop Entry]
Type=Application
Exec=/home/hoge/bin/hhk_setup.sh
Hidden=false
NoDisplay=false
X-GNOME-Autostart-enabled=true
Name[ja]=HHK Setup
Name=HHK Setup
Comment[ja]=Happy Hacking Keyboard のキーマップ設定
Comment=Happy Hacking Keyboard のキーマップ設定

hoge のところはユーザ名に置き換え。~/ や $HOME が使えないのでフルパスで書くしかない模様。以前は GNOME のスタートアップで xkbcomp を実行しても設定が反映されなかったが今回は大丈夫なようだ。

右 Alt キーを Super キーにする

GNOME Flashback は metacity 版を使っていたが、radeon ドライバになってから動画の再生でティアリングが発生するので compiz 版に乗り換えた。compiz 版では gnome-panel の右クリックメニューを出すのに Super キーを押さないといけなくて、HHK にはそんなキーがないので右 Alt キーを Super キーにするように hhk_swap を以下のように書き換えた。

partial modifier_keys
xkb_symbols "alt_keys" {
  replace key <MUHE> { [ Alt_L ] };
  replace key <HENK> { [ Alt_R ] };
  replace key <LALT> { [ Super_L ] };
};

これで Super キーは使えるようになったが、Emacs で Meta キーが効かなくなった。M-x のつもりが s-x になってしまう。Meta キーが Super_L と解釈されている? でも xev で見ても Alt_L にちゃんとなっているのだが…

とりあえず .emacs

(setq x-super-keysym 'meta)

を追加して Super キーを Meta キーと解釈させることで問題を回避した。

2015-10-14

[][][] Ubuntu 15.04: VLC のスナップショットが間違ったアスペクト比で保存される

Ubuntu 15.04 にしてから、VLC で動画のスナップショットを保存すると、画像の縦横比がおかしくなることがある。

ピクセルアスペクト比が 1:1 でない動画で発生する現象で、例えばアスペクト比 16:9 の 1440 x 1080 の動画でスナップショットを保存すると 1920 x 1080 で保存してほしいのに、1440 x 1080 で保存されて、水平方向に潰れた画像になってしまう。設定でスナップショットの保存サイズを明示的に指定しても無視される。

これは VLC 2.2.x のバグで、2.2.2 で修正予定のようだ(Ubuntu の公式パッケージは 2.2.0)。開発中のソースコード上では既に修正済み。

修正内容はこちら。

一瞬何をどう修正したのかわからなかったが、どうもソースコードに手を入れているうちに if-else 節のネストがおかしくなって括弧の位置がズレてしまったのを修正したようだ。気をつけよう…

たいした量でもないのでソースパッケージに修正内容を適用してビルドする。作業の流れは以下の通り(コマンドの出力等は省略)。ソースコードの修正はパッチを作成して適用したほうがいいのだろうが、面倒なので手でやってしまった。

$ mkdir vlc-build
$ cd vlc-build
$ apt-get source vlc
$ sudo apt-get build-dep vlc
$ cd vlc-2.2.0
(エディタで src/misc/image.c を修正)
$ dpkg-buildpackage -rfakeroot -uc -b

deb ファイルがたくさん出来ているが、misc/image.c は libvlccore パッケージで使われるので、それだけインストールすればよい。

$ sudo dpkg -i libvlccore8_2.2.0-1_amd64.deb

これで OK だった。

追記: 2016-02-19

パッチを適用した vlc で 1080i のMPEG動画のスナップショットを保存すると、画像の高さが1088ピクセルになってしまう。

MPEGでは縦1080ピクセルの動画はデータ上では16の倍数になるように8ピクセル分のダミーデータが追加されて縦1088ピクセルで格納されている。動画プレイヤーは無効な8ピクセル分をカットして縦1080ピクセルで表示している。

上のパッチを当てた VLC で保存したスナップショット画像にはダミー部分は存在せず、1080ピクセルある有効な領域が縦に少し引き伸ばされた形で保存されていた。パッチを適用する前の vlc では縦サイズは正しく出力されていた。

これはコミット 903b3cbcbc3bf4eab01c80e15e91f2cca0bbeb5e の副作用で、これを適用しないビルドでは正しいサイズで出力された。ただし、このコミットで修正されている vlc の設定でスナップショットのサイズを指定しても効かないという不具合は残ってしまう。

追記: 2016-08-28

ビルドの手順に余計な cd があったので訂正した。

2015-10-12

[][][] Ubuntu 15.04: キーボードのカスタマイズ設定

Happy Hacking Keyboard を使っていて Meta キー(スペースキーの隣)を Alt キーとして使うように設定するのにえらく苦労したので記録を残しておく。

要点をまとめると、こんな感じ。

  • XKB の設定ファイルを書く。
  • システム側の XKB 設定ファイルが上の設定ファイルを参照するように書き換える。
    • /usr/share/X11/xkb/rules/evdev
    • X.org のアップデートで上書きされる可能性あり。
  • GNOME の設定(gsettings)に上で追加した設定を適用するよう設定する。
    • これは各ユーザ毎に設定する必要あり。

設定ツールの GUI で気軽に設定というわけにはいかず、失敗するとキー入力に支障をきたすおそれもあり。以下ではなるべく安全な手順を踏むように書いておく。

前提

Ubuntu のインストール時に、言語環境は日本語、キーボードは英語(US)を指定してインストールした環境。入力メソッドフレームワークは fictx (日本語 Remix のデフォルト)。

デスクトップ環境は GNOME flashback (metacity)。Unity での動作は未検証だが同じ設定で大丈夫だと思う。

キーコードを確認

設定ファイルを書くための下調べ。以降の設定ファイルを丸写しするだけならこの作業は不要。

まず、設定したいキーのスキャンコードを調べる。terminal を開いて xev を実行する。xev は太古の昔からある X の動作確認ツールで、マウスやキーのイベントの情報をダンプするもの。xev を実行すると小さなウィンドウが開くので、そのウインドウを選択してキーを押すと terminal にキーの情報が出力される。

左の Meta キーを押すと以下の出力。keycode の値からこのキーのスキャンコードが 102 であることがわかる。

KeyPress event, serial 37, synthetic NO, window 0x3200001,
    root 0x2b8, subw 0x0, time 395098700, (50,135), root:(837,187),
    state 0x0, keycode 102 (keysym 0xff22, Muhenkan), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

右の Meta キーを押すと以下の出力。こちらは 100。

KeyPress event, serial 37, synthetic NO, window 0x3200001,
    root 0x2b8, subw 0x0, time 395099342, (50,135), root:(837,187),
    state 0x0, keycode 100 (keysym 0xff23, Henkan_Mode), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

次に、スキャンコードに対応するシンボル形式のキーコードを調べる。/usr/share/X11/xkb/keycodes/evdev を上で調べたスキャンコードで検索すると、以下のような定義が見つかる。

        <HENK> = 100;   // Henkan
        <MUHE> = 102;   // Muhenkan

これで、(シンボル形式の)キーコードは、左 Meta キーが <MUHE>、右 Meta キーが <HENK> であることがわかる。

シンボル設定ファイルの作成

XKB のシンボル設定ファイル*1を作成する。

まず、後で動作確認のため適切なディレクトリ構造の下に保存しておく必要があるため、あらかじめ ~/.xkb というディレクトリを作成しておく。

そして、~/.xkb/symbols/hhk_swap というファイルに以下の内容を保存する(ファイル名は任意だが、サブディレクトリ名の symbols はこの通りにすること)。

partial modifier_keys
xkb_symbols "alt_keys" {
  replace key <MUHE> { [ Alt_L ] };
  replace key <HENK> { [ Alt_R ] };
};

これは、キーコード <MUHE> のキー(左 Meta キー)を左 Alt キー(Alt_L)に、<HENK> のキー(右 Meta キー)を右 Alt キーに置き換える設定。symbols ファイルの書き方は正直よくわからないが、以下の記事を参考に試行錯誤して書いた。

実は <HENK> の設定の方は効かないことがあるので、何か間違っているのかもしれないがそのままにしておく。二度設定を読み込ませると効いたりするので XKB 側の不具合か何かかもしれない。

シンボル設定ファイルの動作確認

システムファイルを書き換える前に動作確認をしておく。

まず、setxkbmap コマンドで現在の XKB 設定を表示する。

$ setxkbmap -print
xkb_keymap {
	xkb_keycodes  { include "evdev+aliases(qwerty)"	};
	xkb_types     { include "complete"	};
	xkb_compat    { include "complete"	};
	xkb_symbols   { include "pc+us+inet(evdev)"	};
	xkb_geometry  { include "pc(pc104)"	};
};

この出力をコピーして、以下のように修正したファイルを ~/.xkb/keymap/hhk に保存する(太字が修正部分)。

xkb_keymap {
	xkb_keycodes  { include "evdev+aliases(qwerty)"	};
	xkb_types     { include "complete"	};
	xkb_compat    { include "complete"	};
	xkb_symbols   { include "pc+us+inet(evdev)+hhk_swap(alt_keys)"	};
	xkb_geometry  { include "pc(pc104)"	};
};

これはキーマップ設定ファイルで、修正部分は既に作成したシンボル設定ファイルを参照する設定。

hhk_swap は先に作ったシンボル設定ファイルのファイル名。alt_keys はシンボル設定ファイルに書いた xkb_symbols "alt_keys" { の "" 内の名前。つまりこれは、設定ファイル hhk_swap 内の alt_keys という名前で定義されたシンボル設定の {} 内に書かれた設定を適用するという意味。

この設定を実際に動作中のデスクトップ環境に適用する。GNOME デスクトップにログインした状態で、以下のように xkbcomp コマンドを実行する。

xkbcomp -I$HOME/.xkb ~/.xkb/keymap/hhk $DISPLAY

第1引数の -I に続けて記述(スペースは空けない)した ~/.xkb は最初に作った設定ファイルの置き場所のディレクトリ。第2引数は上で作成したキーマップ設定ファイル。第3引数は普通はこのままで気にしなくてよい。*2

コマンドラインを実行すると大量の(40行ぐらい) Warning が標準エラー出力に出力されるが、身におぼえのなさそうなものはシステム側の設定ファイルの問題なので気にしなくてよい。

これで期待したキー割り当てができているか確認する。

システム側の XKB 設定ファイルを変更する

以下の作業はシステムファイルを追加・変更するため、terminal で sudo コマンドを使って実行する。

まず、シンボル設定ファイル hhk_swap を /usr/share/X11/xkb/symbols/ にコピーする。ファイル名を変えている場合はコピー先に同名のファイルがないか確認して、同名のファイルがあるなら上書きしないように別のファイル名でコピーすること。

次に /usr/share/X11/xkb/rules/evdev を書き換える。このファイルには「DO NOT EDIT THIS FILE」などと書いてあるが、他に適切な方法がみつからないので…

/usr/share/X11/xkb/rules/evdev の末尾に次の1行を追加。

  hhk:alt_keys = +hhk_swap(alt_keys)

シンボル設定ファイルの設定をオプション設定として登録している。設定は hhk:alt_keys という名前で登録しており、GNOME の設定からはこの名前で設定を参照する。hhk_swap(alt_keys) の部分は「シンボル設定ファイルの動作確認」のキーマップ設定ファイルの修正部分と同じ意味。

GNOME の設定(ユーザ毎の設定)

実際にキーボードカスタマイズ設定を利用するユーザアカウントで GNOME デスクトップにログインして、以下のコマンドラインを実行する。

gsettings set org.gnome.desktop.input-sources xkb-options "['hhk:alt_keys']"

hhk:alt_keys は、/usr/share/X11/xkb/rules/evdev に追加したオプション設定の名前。

これで設定作業は終わり。

一度ログアウトして再度ログインするとキーカスタマイズ設定が適用されているはずだ。*3

失敗した方法

以下はうまくいきそうでいかなかった方法。

xmodmap は使えない

昔から UNIX 系 OS で X を使っている人なら、まず .Xmodmap で設定しようとするだろうが、これはダメだった。今までこれで大丈夫だったし、実際 terminal から xmodmap を実行すれば実行直後は効いているのだけど、入力メソッドを切り替えたりスリープから復帰したりすると元に戻ってしまう。

これは fcitx がキーボードレイアウトを切り替える際に xmodmap の設定を上書きしてしまうためだが、この時に xmodmap の設定ファイルを再読み込みする設定があるようだ(xmodmap settings being overwritten - FAQ - Fcitx)。

入力メソッドの設定 の [アドオン] タブでを開いて [拡張] チェックボックスにチェックを入れると一覧から [X Keyboard Integration] が選択できるようになるので[レイアウト変更後にこの独自 xmodmap スクリプトを適用する]に .Xmodmap をフルパスで設定する。

しかし、これもうまくいかなかった。設定直後は .Xmodmap が読み込まれるのだが、やはり入力メソッドを切り替えると設定がリセットされてしまう。

xkbcomp は使えない

システムファイルの変更を嫌ってデスクトップログイン時に xkbcomp を実行する方法が「[xkb] Ubuntu 14.04 で Caps Lock を別のキーにする方法」や「xkbでキーバインドを変更する」で紹介されているが、自分の環境では設定が反映されなかった。

GNOME の「自動起動するアプリケーション」に xkbcomp を実行するシェルスクリプトを設定しても、起動タイミングの問題なのか何なのか、設定が反映されないことがある。

また、ログイン完了後に terminal から xkbcomp を実行するなどしても、実行直後は設定が反映されるが、アカウントの切り替えから復帰したタイミングなどで設定がリセットされてしまう。

追記: 2016-08-28
  • 誤字を修正した(settings → gsettings)。
  • Ubuntu 16.04 では追加の作業が必要になる。d:id:rna:20160828:p1 参照。

[][][] Ubuntu 15.04 インストール作業全般

環境設定以前のインストール作業について。

HDD のパーティション作成

今回は 3TB の HDD (Western Digital WD30EZRX)を新規に用意してインストールしたのだが、あらかじめ Ubuntu 12.04 の環境でパーティションを作成してからインストールを行った。

ルートファイルシステム用に64GBを2つ(1つは次のバージョンに移行する際に使うための予備)、home 用に 2.9TBという構成。*4

まずディスクユーティリティで GUID パーティションテーブルを作成。次に先頭パーティションを追加するが、以下のような警告が表示されてしまう。

WARNING: The partition is misaligned by 3072 bytes. This may result in very poor performance. Repartitioning is suggested.

very poor performance とか言われるとなんとかしたいので、エラーメッセージでググると、以下の記事がヒット。

要は以下のようにすればいいらしい。

  • ディスクユーティリティではなく gpartd を使う。
  • 先頭パーティションの手前に 8MiB 空けておくように指定する。

これで警告は出なくなった。インストール後も特にパフォーマンス上の問題は発生していない。

インストール用ブータブルUSBメモリの作成

これも移行前の Ubuntu 12.04 の環境での作業。GNOME デスクトップのシステムツール「ブータブルUSBの作成」(usb-creator-gtk)で、Ubuntu 15.04 日本語 Remix の iso イメージを 2GB のUSBメモリに書き込んだ。

Live セッションを試す

PCをブータブルUSBから起動すると「Ubuntu を試す」と「Ubuntu をインストール」の2つの選択肢が出てくる。「Ubuntu を試す」が Live セッション。

今まで Live セッションを試すことはほとんどなくて、操作感などを事前に確かめるのには VirtualBox で仮想マシンを作って試すようにしていたのだが、今回は Live セッションでしばらく使ってから本番インストールを行うことにした。

仮想マシンでのテストは今回も行ったのだが、15.04 は仮想環境での動作が不安定で、度々仮想マシンが落ちることがあったので、実機でも落ちるようなら移行できないし、LTSじゃないリリースということでデバイスドライバ周りに問題があると怖いのが理由。

Live セッションではソフトウェアのインストールもできる(ただし再起動すると消える)ので、インストールイメージに含まれないソフトウェアも試すことができる。動画再生の性能が気になるので VLC をインストールして試してみたりした。

また、Ubuntu 15.04 のデスクトップ環境は GNOME デスクトップはオプションになっているが、Live セッションでも apt-get install gnome-panel して GNOME3 デスクトップ環境一式をインストールしてからログアウトすると、ログイン画面で GNOME デスクトップ(GNOME flashback)を選択できるようになり、GNOME デスクトップ環境も試すことができる。

結局、仮想環境で発生していた問題は Live セッションでは再現しなかった。また、デバイスドライバについては、AMD のビデオドライバ fglrx を使用したところ X が起動しなくなったので(GPU は Athlon 5350 内蔵の Radeon R3)、X.org の Radeon ドライバを使い続けることにした。

*1:訳語がこれでいいのか不明だが、キーコードとキーシンボルの対応付けを設定するファイル。システム上では /usr/share/X11/xkb/symbols/ の下に保存されている。

*2DISPLAY は X の環境変数で、現在使用している X サーバー(画面表示を行うモジュール)の名前が入っている。古典的なマルチディスプレイ環境だとディスプレイ毎に違う名前になるが、今時のマルチモニター環境では気にしなくてよいはず。このあたりの歴史的経緯の概略は マルチディスプレイ - ArchWiki を参照。

*3:ログアウトせずに「アカウントのロック/切り替え」でログイン画面を出してからロックを解除するだけでも設定が適用される模様。

*4:swap はメモリが 8GB あるので不要だろうと用意していない。

2015-10-11

[][][] Ubuntu 15.04 に移行

リハビリがてらメイン PC の Ubuntu 12.04 + Trusty HWE を 15.04 にバージョンアップした。今回は LTS 版ではない最新リリースへの移行。

今まで LTS をサポートが切れるまで使って次の LTS にバージョンアップというサイクルだったが、今のうちに冒険しておこう的な理由もあって最新リリースに。OS のバージョンアップだけでなく手に馴染んだレガシーなアプリやツールも最新のモダンなものに移行した。

今回のバージョンアップではこんな目標があった。

  • 64bit 環境への移行
  • ATOK X3 から Mozc への移行
  • Mew から Thunderbird への移行

今まで 32bit 環境でも PAE カーネルで 4GB 以上のメモリも使えていたので、64bit でなくても特に不自由はなかったのだが、Atom の deb パッケージが 64bit 版だけ配布されていたりして、今後は 64bit 版バイナリのみ提供されるアプリも増えてくるかもしれないし、コミュニティでの動作検証も 64bit 版が中心になっていると思うので、64bit 環境に移行することにした。

Emacs から Atom への移行も考えていたが、まだちょっと… でも残りの人生を Emacs と共にするのがはたして幸せか? ということも考えて、とりあえず Atom を試していくつもり。会社の Windows PC で試した時はいまいちピンと来なくて本格的には使わなかったのだけど。

とはいえ Emacs 依存度を減らしていこうとは思っていて、Mew から Thunderbird に移行した理由の一つはそれ。一番の理由は操作がダルいとか、HTML メールしか送ってこないサービスも増えてきたし、という理由。

ATOK をやめようというのは結構勇気が必要だったのだが、Linux 版は今後ジャストシステムのサポートが見込めなさそうで、既に GNOME3 対応はパッチを当ててビルドしないといけない状態だし、XIM ベースのインプットメソッドなので、Qt5 ベースのアプリでは使えないという状況がある。

変換エンジンも Google 日本語入力がベースの Mozc なら、変換効率も古い ATOK と比べる分には遜色ないのではないかと思い、今回は真剣に移行を検討した。結果として、多少の不満は残るものの、なんとか移行できた。この記事も emacs 24 + mozc.el で書いている。

移行に際しては Web にノウハウを公開しているブログなどが大いに参考になったので、自分もそれにならって後続の記事でノウハウを書き残していこうと思う。

2014-11-20

[] リフレ政策はトリクルダウン理論じゃないよ、という話

「アベノミクス」の図解としてこんなのが出回っていますが、違いますよ、という話。

これ、元ネタの図は Trickle down economics (トリクルダウン理論)の説明です。

しかし少なくとも、いわゆる「アベノミクス第一の矢」であるリフレ政策は、トリクルダウン理論ではないですよ、という話をします。

トリクルダウン理論というのは金持ちの金儲けを優遇する政策をとって金持ちをもっと金持ちにすれば自然に貧困層も潤うよ、だから大企業の法人税を減税したり、所得税の累進課税を緩めたりするといいよ、というもの。

一方、リフレ政策というのは、要は金利を下げてインフレにするということです。通常はデフレの時は中央銀行が金利を下げればいいのですが、金利をゼロまで下げてもデフレが続くと、それ以上金利を下げられなくなります。そこで、予想インフレ率を上げることで実質金利をさらに下げるのです。やり方は違いますが、目指す結果は基本的に同じです。

金利を下げてインフレにするのは金持ち優遇を目的にしているわけではなく、実際必ずしも金持ちが得するとは限りません。というか、お金を持っている人がお金を溜め込まずに使う方向に行動を変えると得をする(変えないと損する)状況にするのが目的です。

人を雇って事業をしている人は、人をもっと雇うと得するようになります。現金を持っている人は、持っているお金を事業をしている人に投資した方が得するようになります。土地や商品などの資産を担保に借金をして事業をしている人は、事業を拡大した方が得するようになります。

一定の人々が上で述べたように行動を変えて得することで、需要は拡大し、インフレは進み、より多くの人が同様に行動を変えていくことになるでしょう。

お金が上から下へと順番に落ちてくるというような単純な話ではなく、様々な経路でお金が回り出すのです。順番としては、お金を動かしやすい人から得をする傾向はあるし、それはお金持ちから、という部分はありますが、お金持ちたちにお金が行き渡らなくても失業率の低下や企業倒産の減少は進みます。

「景気回復の実感がない」という人は実際少なくないと思いますが、それは行動を変えにくい人、逆に言うと安定している人なのだと思います。たとえば、それなりの企業に正規雇用で長年勤めていて定期預金でがっつり貯金してるような人は、景気回復の途上ではむしろ損するかもしれません。

あと、安倍内閣は「アベノミクス」だけやってるわけじゃないので、他の政策の影響はあります。例えば福祉削減で景気回復以上の損害を被っている人は大勢いるでしょう。そして4月の消費税増税の影響が景気回復分を吹き飛ばしてしまっているのは周知の通りです。

以上、まあ、素人の言うことなので話半分に聞いていただいても構いませんが、とりあえず、

というあたりだけは確かなのでご注意を、ということで。

追記: 甘利経済再生相の「トリクルダウン」発言

ブクマで指摘されるまで知りませんでしたが、甘利経済再生相が「トリクルダウン」とか言っちゃってるんですか。困った人だな。

消費増税を延期する場合の理由として、企業収益が上がっている一方で実質賃金が上がっていない点を指摘。「アベノミクスの基調が頓挫したということではないが、トリクルダウンがまだ弱い。引き上げを延期するとしたら、企業業績が賃金に跳ね返る2巡目、3巡目を起こす時間的猶予が必要になるという判断だ」との考えを示した。

増税延期なら日本売り起こさせぬ決意と手当て必要=経済再生相 | Reuters

誤解を招く表現だし、ひょっとしたらマジでリフレ政策をトリクルダウン理論と理解(誤解)してるのかもしれないけど、政権の誰かがトリクルダウンだと思っていようがいまいが、やることが同じなら起こることも同じです。

「リフレーション!」って叫びながらリフレしたらきれいなリフレになって、「トリクルダウン!」って叫びながらリフレしたらきたないリフレになる、ってことはありませんし、自民党がやろうと共産党がやろうとリフレはリフレです。

ただ、いわゆる第二の矢・第三の矢がトリクルダウン指向じゃないの? というのはその通りかもしれず、いらんことしてかえって景気回復の足を引っぱる可能性も懸念してます。*1どのみちたいして(良くも悪くも)効かないと思ってはいますが。

まあ、自民党が自業自得で誤解を招いて議席を減らすのなら個人的には歓迎しますが(経済政策以外のところで賛成する部分がほとんどないので)、リフレ政策自体が誤解されたままだと困ります。。。

*1:前回衆院選の前からずっと。参照:自民党の経済政策について