Elecom WDC-433SU2Mで802.11acな通信を実現したのかわからないけどとりあえず動いた

2015-03-08 追記

x86-64でも動くという情報をいただいた（x86_64 Linux上でELECOM WDC-433SU2Mを用いて802.11acな通信を実現する）。リンク先記事で紹介される方法で利用が可能となる。
ただし、Arch Linuxの場合はlinux-headersによるファイル群が /lib/modules/`uname -r`/ に配置されるので、Makefileにおける変数 "LINUX_SRC" は "/lib/modules/$(shell uname -r)/build" のままである必要がある。
また make install 後 modprobe を忘れずに（さもないとハマることになる。本記事コメント欄参照）。
id:grafiさん、有難うございました。

2015-03-11 追記

動作が確認できたカーネルは3.18系のもので、3.19.1では（少なくとも私の環境では）コンパイルに失敗した。

　Elecom WDC-433SU2Mで802.11acな通信を実現したかった - テクニカルプアの続き。
　以前の記事と同様の手順をx86-64な環境ではなくx86（Archでいうi686）な環境で実行し、そのままx86な環境で使用してみたところ、WDC-433SU2Mの動作に成功した。ただ、思ったような速度が出ず、802.11acとして接続されているのか不安になっている。でもまあいい感じに通信してもカーネルパニックは起こさないので、動いたとしてよいと思う。
　というわけでドライバはx86向けに書かれていたようだ。

　一応環境を以下に示す。同じバージョンでx86-64な環境ではカーネルパニックを引き起こした。

$ uname -r
3.14.6-1-ARCH
$ gcc --version
gcc (GCC) 4.9.0 20140521 (prerelease)
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Elecom WDC-433SU2Mで802.11acな通信を実現したかった

2015-03-08 追記

体裁がグチャグチャになってたのに気がついたので直した。内容は変わってない）

2014-06-11 追記

進展があった

　今まで使っていたwifiルータ(プラネックスのMZK-W04N)が長いこと不調で、とうとう我慢の限界に達したので、wifiルータを新調することにした。そういうわけで802.11acに対応しているバッファローのWHR-1166DHPを購入し、acが使えるならと併せてエレコムのWDC-433SU2MBKを買うことにした。
　さて、WDC-433SU2MBKだが、こういうものの常として、何も考えずに挿しても認識することはない。適当に型番で検索するとElecom WDC-433SU2M - WikiDeviというのが出てきて、使えるドライバも掲載されていた。GNU/Linux用ドライバが入手出来るのなら動かせるだろうということで、やってみることにした。
　で、結果だが、動作しなかった。
　詳しく言うと、ドライバをインストールすればWDC-433SU2MBKを認識はする。netctlなりwicdなりのネットワーク管理ツールを使えば802.11acでつながりもする。しかし、いい感じに通信をしようとすると、カーネルパニックを起こしてシステムがまるごと死ぬ。原因として思い当たる節は多々あるが、そのへんは後述する。

環境

$ uname -r
3.14.4-2-ck
$ gcc --version
gcc (GCC) 4.9.0 20140521 (prerelease)
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

（2014-06-22 追記：ドライバのコンパイルにはカーネルのヘッダファイルが必要。linux-headersとかそういうのをインストールしないとコンパイル時に怒られる）

作業

　ほぼPLANEX GW-450D KATANAをLinux(CentOS6.5)で動かす | hosiiのメモ帳に沿っている。

ドライバのソースコード入手

　http://www.mediatek.com/en/downloads/mt7610u-usb/からダウンロードする。氏名とメールアドレスを入力し、CAPTCHAを通れば入手できる。GPLv2で頒布されている。

パッチ当て

　以下のパッチをあてる。

planex_gw450_katana_linux_3_13_driver.patch · GitHub

　最後のパッチはGW-450D KATANAのドライバ用みたいになっているが、これはGW-450D KATANAもWDC-433SU2Mも同じMediaTek製のMT7610Uというチップを使用しており、このためドライバも同一のものになるためである。

コンパイル

　パッチを当てたらmakeする。makeが終わると、ドライバのソースがあるディレクトリのうち、os/linux/内にmt7650u_sta.koというカーネルモジュールができている。これを使う。

インストールとか

　mt7650u_sta.koをカーネルモジュールが格納されているディレクトリへ配置して、設定ファイルを適切な位置へ置く。以下ではカレントディレクトリをドライバのソースがあるディレクトリとする。

# cp os/linux/mt7650u_sta.ko  /lib/modules/`uname -r`/kernel/drivers/net/wireless/
# mkdir -p /etc/Wireless/RT2870STA
# cp RT2870STA.dat  /etc/Wireless/RT2870STA/

　次にWDC-433SU2Mをra0として扱えるように、modprobeの設定ファイルを書く。内容は以下の通り。

$ cat /etc/modprobe.d/99-local.conf
alias ra0 mt7650u_sta

　最後に、カーネルモジュールをカーネルに読み込んで、ドライバとして使えるようにする。

# depmod -a
# modprobe mt7650u_sta

　こうすれば、ifconfigなりiwconfigなり、あるいはip aとかでra0を確認できる。

結果

　以上でWDC-433SU2Mをシステムへ認識させることはできる。しかし動かそうとすると、これはまた別の問題になる。前述のとおり、いい感じに通信させようとするとカーネルパニックを起こして死ぬのだ。いい感じに通信をすると死ぬというのは、pingを飛ばす程度なら死なないのにレポジトリを更新させようとしたり、ブラウザを立ち上げてインターネットしようとすると死ぬ、という意味でつかっている*1。
　で、思い当たる節というのは、config.mkへのパッチでコンパイルオプションとして-Wno-date-timeをつけるようにしていることだ。こいつは

@item -Wdate-time
@opindex Wdate-time
@opindex Wno-date-time
Warn when macros @code{__TIME__}, @code{__DATE__} or @code{__TIMESTAMP__}
are encountered as they might prevent bit-wise-identical reproducable
compilations.

（Tobias Burnus - [Patch: libcpp, c-family, Fortran] Re: Warning about __DATE__ and __TIMEより引用、各行先頭'+'を除去）
だそうで、こいつを付けないと

  CC [M]  /dev/shm/mt7610u_wifi_sta_v3002_dpo_20130916/os/linux/../../sta/sta_cfg.o
/dev/shm/mt7610u_wifi_sta_v3002_dpo_20130916/os/linux/../../sta/sta_cfg.c: In function ‘RTMPIoctlShow’:
/dev/shm/mt7610u_wifi_sta_v3002_dpo_20130916/os/linux/../../sta/sta_cfg.c:5401:85: error: macro "__DATE__" might prevent reproducible builds [-Werror=date-time]
             snprintf(extra, size, "Driver version-%s, %s %s\n", STA_DRIVER_VERSION, __DATE__, __TIME__ );
                                                                                     ^
/dev/shm/mt7610u_wifi_sta_v3002_dpo_20130916/os/linux/../../sta/sta_cfg.c:5401:95: error: macro "__TIME__" might prevent reproducible builds [-Werror=date-time]
             snprintf(extra, size, "Driver version-%s, %s %s\n", STA_DRIVER_VERSION, __DATE__, __TIME__ );
                                                                                               ^
cc1: some warnings being treated as errors
scripts/Makefile.build:308: recipe for target '/dev/shm/mt7610u_wifi_sta_v3002_dpo_20130916/os/linux/../../sta/sta_cfg.o' failed
make[2]: *** [/dev/shm/mt7610u_wifi_sta_v3002_dpo_20130916/os/linux/../../sta/sta_cfg.o] Error 1
Makefile:1278: recipe for target '_module_/dev/shm/mt7610u_wifi_sta_v3002_dpo_20130916/os/linux' failed
make[1]: *** [_module_/dev/shm/mt7610u_wifi_sta_v3002_dpo_20130916/os/linux] Error 2
make[1]: Leaving directory '/usr/lib/modules/3.14.4-2-ck/build'
Makefile:393: recipe for target 'LINUX' failed
make: *** [LINUX] Error 2

とかいってコンパイルに失敗するのが、こいつをつけると抑制できる。しかし、無事コンパイルが通ってもカーネルパニックでシステムをブチ殺してしまうのなら、このオプションなしでコンパイルが通るようにしたほうがよさそうだ。しかし、上の中で表示されているエラーで検索してみても、AUR (en) - broadcom-wlなどのように、-Wno-date-timeでお茶を濁している感じで、どうにもならない。
　802.11acの恩恵を受けたかった。WDC-433SU2MBKを使わず802.11nで過ごすぶんには何も問題はないので、こちらもそれでお茶を濁すことにしようと思う。

参考

• Elecom WDC-433SU2M - WikiDevi
• PLANEX GW-450D KATANAをLinux(CentOS6.5)で動かす | hosiiのメモ帳
• http://paritparit.blogspot.jp/2013/08/planex-gw-450dlinux.html
• planex_gw450_katana_linux_3_13_driver.patch · GitHub
• Tobias Burnus - [Patch: libcpp, c-family, Fortran] Re: Warning about __DATE__ and __TIME

*1:詳しく調べていないので確証は無いけれど、たぶんICMPは大丈夫でTCPとかUDPだと死ぬんだと思われる。その他のプロトコルについては不明。

Arch LinuxからChakraのレポジトリを利用する

　Chakra*1というArch Linux派生のLinuxディストリビューションがある。Arch Linux開発者の中でもKDEに突出した人達がKDEを極めるために立ち上げた*2もので、KDEのあらゆる利点を強烈に増幅したディストリである。KDEユーザの端くれとしてKDEのあらゆる利点を強烈に増幅したディストリを無視出来るはずもなく（Arch Linux派生というのも理由だけれども）、その存在を知ってから今日に至るまでずっとニュースを追ったり、たまに冷やかし目的で使ってみたりしていた。

　さて、去る5月21日、最新版のイメージが公開された*3。早速落としてきて使ってみたところ、起動時に表示されるスプラッシュスクリーン（Siriusという）の格好良さが強烈に印象に残った。その他動作速度が前版に比べてかなり向上していたり、前版に輪をかけてUIが格好良くなっていたりしていたけれども、スプラッシュスクリーンの格好良さの印象が強く、是非普通のArch Linuxでも使ってみたいと思った。

かっこいい

　Chakraのパッケージは全部http://rsync.chakraos.org/で公開されているので、そこからインストールしても全然構わないのだけれど、出来ればバージョンアップにも追随したいので、pacmanで扱えるレポジトリのひとつとしてChakraのレポジトリをどうにか出来ないかと考えて、試してみることにした。

　で、出来た。

方法

　今回使いたいSiriusは、rsync.chakraos.org/desktop/x86_64/下に"kde-ksplash-themes-sirius-<お決まりの接尾辞>"という名前で存在する。なのでrsync.chakraos.org/desktop/x86_64/をpacmanで管理できるようにすればいい。

　pacmanで管理できるレポジトリを追加するには/etc/pacman.confにレポジトリの情報を追加する必要があるので、何を追加するのか確かめなければならない。追加内容の凡例は

[custom]
SigLevel = Optional
Server = URI

となる。Serverへは"http://rsync.chakraos.org/desktop/$arch"*4とすればよい。またcustomは、適当な名前を入れると「そんなものは無い」と怒られるので、レポジトリ内のデータベースの名前を入れておくのがよい。今回の場合はURL内に"desktop"という記述があるし、またディレクトリ内にdesktop.dbというズバリなファイルがあるので、"desktop"をcustomと置き換えれば良い。

　よって、以下を/etc/pacman.confに追記すれば、pacman -Ss siriusでkde-ksplash-themes-siriusを見つけられるようになる。SigLevelはお好みで変更しても良い。

[desktop]
SigLevel = Optional
Server = http://rsync.chakraos.org/desktop/$arch

雑文

　スーパーpre記法を使いたくて編集モードをはてな記法に変更したらあまりの便利さに感激している。と同時にスーパーpre記法で今までの記事におけるpreタグを置換したくなったが、ちょっと置き換えたあたりで、編集モードを変更するために記事を消してまた作りなおすのは内容は同じでも、ある意味今までの微々たる蓄積を捨ててしまうことになるわけで、どうしたものかと考えてしまった。管理の上でも煩雑になりそうなので、たぶんやらない。

*1:http://chakraos.org/home/

*2:Chakra - Chakra | Wiki、上の記述は脚色している

*3:Chakra-2014.05-Descartes released - Chakra | News

*4:別にx86_64のままでも良さそうだけど、慣例に従うことにした

mikutterを日本語化する

　2014年5月7日、mikutter 3.0.0-alpha1が公開された*1（おめでとうございます）。

で、ver. 3.0からついに多言語に対応される事になり、日本語を介する者以外にもmikutterへの道が開かれた。多言語化に際し、使用されている言語の識別はシステムのロケールの設定から判断される。

　しかし、システムのロケールは日本語だけどCUIでなんかするときは英語のほうがいいという、私のような非国民には、このロケールから使用言語を識別するというのはちょっと問題になる。というのも、ロケール、とくにLC_MESSAGESがen_US.UTF-8に設定されているため、mikutterは言語環境を英語と解釈してしまっているようなのだ。

　さて、Arch LinuxにおいてはmikutterはAURで提供されており*2、そこでのPKGBUILDでは、mikutterの実体は/opt/mikutter/下にインストールされ、/usr/bin/下には/opt/mikutter/下のmikutter.rbを実行するように記述されたシェルスクリプト(/usr/bin/mikutter)がインストールされるようになっている。mikutterを起動する時にmikutterの実体が直接呼ばれるわけではなく、シェルスクリプトを経由して実行されるならば、/usr/bin/mikutterの内容を編集し、LC_MESSAGESをja_JP.UTF-8に設定してから/opt/mikutter/mikutter.rbを実行すれば良いはずだ。

　というわけでmikutterをja_JP.UTF-8な環境の下で実行するための、PKGBUILDへのパッチを書いた。

*1:mikutter開発日記: mikutter 3.0.0-alpha1、記事を書いている現在ではalpha-2が最新

*2:AUR (en) - mikutter

CaboChaをpython3で使うためのパッチ書いた

2014-10-28 追記

パッチの内容を編集した。とはいってもdiffをとるファイルの関係をちょっと変えただけ。

　CaboChaの更新を知り、AURのPKGBUILDを更新したついでに試みにやってみたら動いたっぽいので。

　このパッチを当てた後にインストールした後、setup.pyと同じディレクトリにあるtest.pyの動作にも成功したので、一応おそらく正常に動くと思われる。なお、test.pyにもpython3で動かすための変更を以下のように加えた。

xprofileとxinitrcとの違い

2014-06-14 追記

実体験に基づき追記。本文中に示したstartxでDEを利用する流れだが、どうにも異なるようだ。というのも、startxでDEを立ち上げた場合にxprofileの記述が反映されないことがあった。この場合、xprofile - ArchWikiに従ってxinitrcへ

[ -f /etc/xprofile ] && source /etc/xprofile
[ -f ~/.xprofile ] && source ~/.xprofile

と追記すればよい。追記する場所は"exec startkde"などのDEを立ち上げる記述の前にする。こういう事情があるので、startxすればxinitrcを読んだあとでxprofileを読みに行く、というわけではないらしい。

おことわり

　この記事の内容について、私はあまり自信を持てない。おそらくこうであろうとは思うのだが、明確な根拠を示せない。仮に正確な知識をお持ちの方がこの記事をご覧になり、訂正の必要があると判断された場合、ぜひとも訂正箇所をお教え願いたい。

本文

　uimを普通に使う時に、設定ファイルへ追記する

export GTK_IM_MODULE='uim'
export QT_IM_MODULE='uim'
uim-xim &
export XMODIFIERS='@im=uim'

という記述を、どのファイルへ加えればいいのか設定のたびに悩んでいた。Uim を使って日本語を入力 - ArchWikiに従えば、

~/.xprofile、~/.xinitrc、~/.xsession などに設定

とのことなのだが、この設定ファイル達の違いがわからない。 また、指示通りに記述してもuim-ximが立ち上がってくれなかったり、あるいはmultilibなソフトウェアで日本語が入力できなかったりという事があった。/etc/profileへ追記すればいい感じに動いてくれるということが判明してからは前述の記述を/etc/profileへ追記していたが、なんだか気持ちが悪い。
　なので、xprofileとxinitrcについて少々学んでみることにした*1。
　xprofileについては、xprofile - ArchWikiによると、ウィンドウマネージャ（以下WM）の起動前に実行したいコマンドを記述しておくものである。KDMとかGDMとか、名の知られたディスプレイマネージャ（以下DM）であれば、その実行時にユーザディレクトリ下の .xprofile を参照し、コマンドを実行する。WMとDMは独立して実行されるが、Xを使用するという意味ではDMのほうが先んじているので、DMがxprofileを参照することで、WMの起動に先んじて所望のコマンドを実行できる。
　xinitrcは、同様にxinitrc - ArchWikiによれば、startxやxinitなどの、デスクトップ環境（以下DE）を立ち上げる際に使用するコマンドが参照するものである。
　どちらもあまり変わらないような気がするが、このstartxやxinitといったコマンドが関わるかそうでないかが重要なところだ。SystemdなどでDMを有効にし、電源投入後に自動的に起動するように設定している場合、

$ ps aux | grep "startx\|xinit" 

とかやれば、startxやxinitが実行されていない事がわかる。つまり、DMを使用する場合、DEを立ち上げる上でstartxは実行されず、よってxinitrcは参照されない。従ってDEを利用する際、startxなどを使用して立ち上げるときはxinitrcに、そうでない場合はxprofileに設定を記述すれば、期待した動作を得ることが出来る、という訳なようだ。加えて、startxでDEを利用する場合でも、

1. startx
2. ~/.xinitrcを見る
3. DEが立ち上がる
4. WMが立ち上がろうとする
5. ~/.xprofileを見る
6. WMが立ち上がる
7. 見慣れた光景を得る

という流れのようなので、xinitrcではなくxprofileに設定を記述しても良い。

結論

　迷ったらxinitrcに書けばよい。

　ああ、つっかえていたものがとれたようでスッキリした。

参考

• xprofile - ArchWiki
• xinitrc - ArchWiki
• What's difference between .xinitrc & .bashrc & .xprofile / Applications & Desktop Environments / Arch Linux Forums

3番目のサイトではxprofileがいらない子扱いされている。

*1:xsessionについては、xprofileとxinitrcとを調べて解答を得た結果満足してしまったので調べていない。

単純な人工無脳書いた

2014-06-14 追記

コードをちょっと書き換えた。

　ツイッターを見漁っていたら、以下のようなpostをみつけた。

「ああ、そうなんだー」と「へー」と「すごいねー」をランダムに、20回に１回くらい「いや、それは違うんじゃないかなーw」って喋らせるプログラム作ったら多分一日中会話し続けちゃうと思う。

— りみく (@tasuroto0101) 2013, 11月 30

　じゃあ書いてみよう。ってことで書いた。

　元のアイデアをちょっと変更して、

• 「いや、それは違うんじゃないかな―ｗ」を挟むタイミングを変更可能にした
• 会話終了時の挨拶を付け加えた

となっている。

$ python SimpleChatBot.py 20
press 'Q' to quit
>やあ
Res. >> すごいねー
>ありがとう
Res. >> すごいねー
>それほどでも
Res. >> すごいねー
>いやいや
Res. >> ああ、そうなんだー
>はい
Res. >> ああ、そうなんだー
>そうですね
Res. >> すごいねー
>ありがとう
Res. >> へー
>はい
Res. >> ああ、そうなんだー
>そうです
Res. >> ああ、そうなんだー
>はい
Res. >> へー
>はあ
Res. >> へー
>うん
Res. >> ああ、そうなんだー
>はい
Res. >> へー
>うん
Res. >> へー
>はい
Res. >> へー
>ええ
Res. >> ああ、そうなんだー
>そうです
Res. >> へー
>はい
Res. >> ああ、そうなんだー
>そうなんですよ
Res. >> へー
>はい
Res. >> ああ、そうなんだー
>そうです
Res. >> ああ、そうなんだー
>はい
Res. >> いや、それは違うんじゃないかなーｗ
>えっ
Res. >> ああ、そうなんだー
>あっはい
Res. >> へー
>q
Res. >> またねー

　どちらが人工無脳か見分けがつかない。