Hatena::ブログ(Diary)

児童小銃 RSSフィード

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

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

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


プライバシーポリシー

最新タイトル


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 を修正)
$ cd ..
$ 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 の設定でスナップショットのサイズを指定しても効かないという不具合は残ってしまう。

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 デスクトップにログインして、以下のコマンドラインを実行する。

settings 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 を実行するなどしても、実行直後は設定が反映されるが、アカウントの切り替えから復帰したタイミングなどで設定がリセットされてしまう。

[][][] 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:前回衆院選の前からずっと。参照:自民党の経済政策について

2014-07-06

[]「集団的自衛権問題」についてのメモ

最初に自分の現在の立場を述べておくと「いずれかの時点で適切な歯止めを持った制限付きの集団的自衛権を憲法改正によって確立することが望ましい」というのが僕の立場です。

しかし「安倍政権が」「閣議決定で」「解釈改憲」というのはネガティブに受け止めています。

  • 近隣諸国に対して挑発的な行動を繰り返した上での決定であること。
  • 重大な判断について国民的議論や国民に信を問うプロセスを回避したこと。
  • 憲法解釈の不安定さを対外的に印象付けてしまったこと。

が、理由です。後ろの二つは今に始まったことではないですが、繰り返せば繰り返しただけ弊害が大きくなるので、今更だからどうでもいい、とは思いません。

僕から見ると、世間での集団的自衛権に関する議論は、賛成派・反対派共に極論・暴論に思えるものが多く、デリケートな意志決定の参考にするには頼りないものに思えました。

じゃあお前が模範的な議論をしてみろよ、と言われても、僕にはそれをやるだけの見識はありません。だからこそ賢い人たちの議論を参考にしたいわけで…

しかし、どういうことを踏まえた議論が必要だと思うか、読みたいか、という要望はありますので、以下それについて述べます。

安全保障のリスク論

国民の生命や財産の安全のためには、あらゆる可能性に対応できるように可能な限り武力行使可能な範囲を広げるべきでしょうか。それによって国民の生命や財産は、より安全になるのでしょうか。

他国からの侵略や地域紛争に巻き込まれるような状況で先手が打てる等、ある面ではイエスです。が、国民の生命や財産の安全に対するリスクは戦争だけではありません。

たとえば、国際社会から信用されないとか、経済が停滞するとか、そういうことも国民の生命や財産に関わるリスクです(他にも、もっと大きなリスクがありますがそれは後述)。

戦争放棄、あるいは専守防衛の原則にしても、安全保障上のリスクと引き替えに外交上のリスクや経済上のリスクを低減することが優先課題とされた時期に日本が選択した(あるいはタテマエとして利用した)態度です。

その態度を変更するには、

  • 安全保障リスクが高まった。
  • あるいは他の対抗リスクが低下した。

という情勢の変化があって最適なバランスが崩れた、という理由が必要です。

実際、日本は国際社会に復帰し、世界的な経済大国になり、一方で冷戦が終結し、地域紛争に対して国際社会が対応していく、という変化の中で、9条を含めた改憲論が一定の説得力を持つ時期がありました。90年代から2000年代にかけての話です。

しかし、その後、約20年続いたデフレ不況、日韓・日朝・日中関係の悪化、排外主義の台頭など、また状況は変化しています。今、どうバランスを取るのがベストなのか、冷静な議論と合意が必要だと思います。

個人的には、やっとデフレ脱却へと前進させたと思ったら消費税増税でその勢いを削いでしまい、外交的には失点が重なっていて、一方で9条以外にも問題だらけの改憲案を抱えている今の自民党・安倍内閣は、タイミング的にも資質的にも、こういうデリケートな仕事ができる内閣ではない、と判断しています。

戦争のリスク

ここまで、軍が動きやすくなれば戦争で国民の生命や財産が失われるリスクが減るという前提で書きましたが、本当にそうか? それだけか? とも思います。

戦争のリスクと言っても、他国から戦争を仕掛けられたり、他国間の戦争に巻き込まれたりするリスクだけではなく、自国がするべきでない戦争を始めてしまったり関わるべきでない戦争に関わってしまったりするリスクもあります。

特に日本の場合、最後にやった戦争(太平洋戦争)では、開戦国側になって多くの国民の生命・財産を失わせる結果になっています。

無謀にも自分から戦争を仕掛けてしまった、戦争を始めてからも降伏のタイミングを見失って徒に被害を増やしてしまったこと、軍の犠牲者の過半が戦闘ではなく餓死や病死という形で命を失ってしまうほど、個別の軍事作戦も無謀であったこと、など反省すべき過ちは多々あります。

平和憲法、というか、それを追認した国民の選択は、その反省の上に成り立っています。戦後の大半の時期が保守政権だったにも関わらずその選択が維持されてきたのは、理想主義的な「平和主義」によるというよりは、「ウチら戦争下手すぎヤバい」みたいな現実主義的な認識が国民の大半に共有されていたからではないでしょうか。

だから、さすがに今の日本はそんな過ちは繰り返さない、何らかの形で戦争に関わることになったとしても戦前に回帰するようなことはありえない、そう思っていた時期が僕にもありました… 昨今の世情を見ると、そうでもないか? という気になっています。

過去の過ちに対する反省は、不十分とはいえ、少しずつ進んでいるものと思っていたのですが、ここ10年程の間に逆風が吹いている、というか、今までの「反省」も、豊かな経済を背景とした余裕があってこそだったのか、とか、一部の階級の人たちの知的流行でしかなかったのか、とか、そういうことを考えてしまいます…

その他、軍が戦争に備える動きをすることが近隣諸国を刺激してしまい、かえって戦争の引き金になってしまう(相手国の攻撃の口実に使われてしまう等)、ということは実際あります。そうなった場合、もちろん善悪で言えば先に武力行使した側が悪いに決まっているのですが、自国のリスクマネジメントという観点では失敗には違いありません。

その他

余裕がなくて書ききれなかったことをメモ的に

2014-07-03

[][] Ubuntu 12.04 の shotwell で flickr に公開できなくなった時の対処法

昨日久々に月を撮って shotwell からアップロードしようとしたら「http://api.flickr.com/services/rest が Forbidden」的なエラーが出てログインも何もできなくなってました。

もしやと思ってぐぐったら、FlickrAPI が 6/27 移行 HTTPS のみになってて、そのせいみたい。

Ubuntu の launchpad にも報告が上がってて、Ubuntu 14.04 用には修正版が昨日リリースされたのだけど 12.04 の方はまだ出てません。

というわけでとりあえず対処法。

  • 適当なワークディレクトリを作ってその下へ cd
  • apt-get source shotwell
  • cd shotwell-0.12.3
  • plugins/shotwell-publishing/FlickrPublishing.vala の "http:" ってなってるところを "https:" に書き換え。
    • https://api.flickr.com/services/rest
    • https://www.flickr.com/services/oauth/authorize?oauth_token=
    • https://www.flickr.com/services/oauth/request_token
    • https://www.flickr.com/services/oauth/access_token
    • https://api.flickr.com/services/upload
  • ./configure
  • make
    • No package 'gee-1.0' found とかいっぱい出てきてエラーになるのでがんばってそれっぽい dev パッケージを sudo apt-get install する。。。
    • がんばったらビルドできた。
  • /usr/lib/shotwell/plugins/builtin/shotwell-publishing.so をビルドしてできた plugins/shotwell-publishing/shotwell-publishing.so に差し替える。

これでアップロードできるようになりました。

ちなみにうちの環境では以下の dev パッケージをインストールしたらビルド通りました。

libgtk-3-dev
libexif-dev
libwebkitgtk-3-dev
libsqlite3-dev
libgee-dev
libgexiv2-dev
libgstreamer0.10-dev
libunique-3.0-dev
libgstreamer-plugins-base0.10-dev
libgudev-1.0-dev
libgphoto2-2-dev
liblaunchpad-integration-3.0-dev
libraw-dev
valac-0.16
librest-dev

エラーに出てくるパッケージの名前と Ubuntu のパッケージの名前が一致しないので、それっぽい名前のライブラリを試行錯誤して探してなんとかしたけど、こういうのってみんなどうしてるんでしょ?

2014-04-12

[][] Ubuntu 12.04 で ATOK X3 が使えなくなった時の対処法

4月9日の gtk2.0 や gtk3 関係のソフトウェアアップデート実行後、firefoxATOK (ATOK X3 for Linux の gtk3 対応版)*1 が使えなくなりました。具体的には Ctrl+Space とかで ATOK を ON にできません。他の GTK アプリでもダメなのがあって、入力欄で右クリックメニュー出して「入力メソッド」で「Xの入力メソッド」を選ぶと ATOK が使えるようになったり、という感じ。Ubuntu を再起動してもダメ。

結局以下のようにして対処しました。

1. Terminal から以下を実行。

sudo bash -c '/usr/lib/i386-linux-gnu/libgtk2.0-0/gtk-query-immodules-2.0 > /usr/lib/i386-linux-gnu/gtk-2.0/2.10.0/gtk.immodules'
sudo bash -c 'gtk-query-immodules-3.0 > /usr/lib/i386-linux-gnu/gtk-3.0/3.0.0/immodules.cache'

2. GNOME Desktop をログアウト。

3. GNOME Desktop にログイン。

これで firefox でも gedit などのアプリでも ATOK が使えるようになりました。

*1:詳細は http://d.hatena.ne.jp/rna/20131120/p1 を参照。