テクニカルプア

備忘録と若干の補足

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で過ごすぶんには何も問題はないので、こちらもそれでお茶を濁すことにしようと思う。

参考

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

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

Arch Linux

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

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

f:id:aaodsn:20140523004341p:plainかっこいい

　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に書けばよい。

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

参考

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

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

単純な人工無脳書いた

書いた
2014-06-14 追記

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

 

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

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

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

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

となっている。

$ 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. >> またねー

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

rm -rf / した後の廃墟を探索する

雑記

　2/28から3/1まで、OSC2014 Tokyo/Springが開催されていた。ノベルティ獲得を目的に2日間とも参加した。感想はこことここにクソみたいな内容で残してある。

　で、聴講したとあるセミナーにて、"rm -rf /"の話題が出ていた。rm -rf / はUnixとかUnix系OSではもはやおもしろワードのような扱いであり、実際に試すことは（少なくとも故意には滅多に）無いようなコマンドである。セミナー後、この話題について、ある質問が出ていた。

rm -rf / した後って何が出来るんですか？

　rm -rf / したあとなんて 、まっさらなファイルシステムが残されるのみであって、もはや何も実行できるものもない死の空間である、という認識しかなかった私にとって、その質問は興味深いものだった*1。

　なので実際にやってみた。

記録

環境

  • QEMU
  • Arch Linux (Kernel: 3.13-5-ARCH)

  • archlinux-2014.03.01-dual.isoを使い、Installation guide - ArchWikiに盲従

  • ホスト名はThereseとした。（'T'est -> Therese：私は使用するマシンのホスト名にはドイツ語圏の女性名をあてている）
  • ブートローダはSyslinuxをいれた

実践

[root@Therese ~]# rm -rf /
rm: it is dengerous to operate recursively on `/'((実際には文字化けして"■/■"みたいになっていた。))
rm: use --no-preserve-root to override this failsafe

　親切だ。だがその親切は無用だ。

[root@Therese ~]# rm -rf / --no-preserve-root

<以下、cannot removeの嵐>

[root@Therese ~]# ls
-bash: /usr/bin/ls: No such file or directory
[root@Therese ~]#

　かくして廃墟が構築された。

　ここでお馴染みのUNIXコマンドを色々試してみたが、軒並み"command not found"か"No such file or directory"が返ってくるのみだった。当然だ。だが、中にはcdとかpwdのように、普通に使えるものも存在した。そこで、bashの補完機能（Tabキー押すやつ）を用いて色々観察してみることにした。

  • /にてcdに対して補完
[root@Therese ~]# cd
boot/ dev/ proc/ run/ sys/ tmp/
[root@Therese ~]#
  • /にてコマンドの補完
[root@Therese ~]#
:       builtin		disown	false		jobs		readonly	trap
!	caller		do	fc		kill		return		true
./	case		done	fg		let		select		type
[	cd		echo	fi		locale		set		typeset
[][[	command		elif	for		logout		shift		ulimit
]]	compgen		else	function	mapfile		shopt		umask[]
{	complete	enable	getopts		popd		source		unalias
}	compopt		esac	hash		printf		suspend		unset
alias	continue	evel	help		pushd		test		until
bg	coproc		exec	history		pwd		then		wait
bind	declare		exit	if		read		time		while
break	dirs		export	in		readarray	times
[root@Therese ~]#

　割と残ってるみたいだ。しかし見慣れないコマンドばかりだ……。

　では見るもん見たし、終了するとしよう。shutdownがないので、とりあえずexitでログアウトしてみる。今思うとCtrl+Alt+Delでも良かったかもしれない。

[root@Therese ~]# exit
logout

<応答しなくなった>

　死んだ。この後強制的に終了させた。

　この後、再び起動させてみると、以下のメッセージが得られ、臨終の旨を得た。

booting...
SYSLINUX 6.02 EDD Copyright (C) 1994-2013 H. Peter Anvin et al

Failed to load ldlinux.c32
Boot failed: please change disks and press a key to continue.

参考

　先人たちの記録である。

*1:ちなみに質問に対する答えは「cdは出来たと思う」という感じだった。