テクニカルプア

備忘録と若干の補足

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でも使ってみたいと思った。

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

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

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

単純な人工無脳書いた

2014-06-14 追記

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

 

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

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

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

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

となっている。

$ 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. >> いや、それは違うんじゃないかなーw
>えっ
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は出来たと思う」という感じだった。

ハードウェア的にもソフトウェア的にもキー配列を変更してみた

TL;DR

 /usr/share/X11/xkb/symbols/ 下のキー配列(例えばUS配列なら us )と /usr/share/X11/xkb/rules/下の

  • base.lst
  • evdev.lst
  • base.xml
  • evdev.xml

を編集しXを再起動、そのあと「KDE システム設定」からハードウェア→入力デバイス→キーボードに飛び、キー配列タブから新たに追加したキー配列を加える。

経緯

 唐突だが私は無刻印キーボードとDvorakに憧れている。ふつうの刻印キーボードだとソフトウェア的にキー配列を変更した場合ハードウェアとソフトウェアとで入力に差異が生じて訳が分からなくなるが、無刻印キーボードだとそんなことはない。刻印に支配されない環境はさぞかし過ごしやすかろうと思う*1Dvorakに憧れている理由は、打ちやすいという評判を知ったのと、キーボード左側に記号入力のキーが配置されてるのがエキゾチックな感じがしたためだ。

 で、刻印のあるキーボードでキー配列を変更する場合にキーボードのほうを如何とするかという問題の解決法はいろいろあって、キーをバラして入れ替えるとか、インレタやシールなどで新しいアルファベットをキーに振るというものがある。見栄えがいいのは明らかに前者なのだが、キーボード単体の場合はともかく、ノートパソコンのキーボードでこれをやろうとするとうまくいかない事が多いように思う。私が使用しているThinkPad X200の場合、トラックポイントを採用している都合上G、H、Bキーがトラックポイントにあわせてエグれており、かつFキーとJキーはホームポジションの目安のためにキーに出っ張りが有り、かつパンタグラフの形状が他のキーのそれと違うために他のキーとの入れ替えが不可能なのだ。

 つまりThinkPad X200のキーボードは

f:id:aaodsn:20140118174945p:plain*2

で、これを物理的に組み替えてDvorakをやろうとすると、

f:id:aaodsn:20140118174332p:plain*3

としたいのに

f:id:aaodsn:20140118174528p:plain*4

となってしまうのだ。さらに付け加えれば上図でF、J、U、Hキーは嵌らず脱落した状態になるだろうし、I、D、Xキーはトラックポイントとの干渉箇所を整形しなくてはならない。

 ならば、ソフトウェアのほうをハードウェアの都合に合わせてしまえばいいのではなかろうか、つまり、下図のようなキー配列をでっち上げてしまえばいいのである。

f:id:aaodsn:20140118174904p:plain*5

実践

 KDEはxkbの設定に従う。KDE上でキー配列を設定するのはxkb上でキー配列を設定するのと等価である。よって、xkbの設定ファイルに新しいキー配列を加えてやればいい。私はUS配列のキーボードを使っているので、この場合は /usr/share/X11/xkb/symbols/us を編集する。編集内容は以下の通り。新しく追加したキー配列は「cdv」で表現し、その説明は「English(customized Dvorak)」とした。

for /usr/share/X11/xkb/symbols/us

 次に、新しく加えたキー配列をxkbに読み込ませる。これは /usr/share/X11/xkb/rules/ 下の

  • base.lst
  • evdev.lst
  • base.xml
  • evdev.xml

を編集する必要がある。*.lst の編集内容は以下の通り。

で、*.xml の編集内容は以下の通り。

 以上を終えたらXを再起動させる。再起動後、「KDE システム設定」からハードウェア→入力デバイス→キーボードに飛び、キー配列タブから新たに追加したキー配列を加えれば、新しく追加したキー配列を使用できる。

使用感

 QWERTYに慣れすぎて使いづらい。だがこれは多分普通のDvorakを使おうとしても抱く印象だろう。しかし、キーの物理的制約でDvorakを崩した結果、母音がキーボード左部と中部に分散してしまい、Dvorakの特徴であるらしい、左手と右手でリズミカルにタイピングできるという特徴が損なわれている感じがある。

 ちなみにこの記事はQWERTYで書いている。QWERTY使いやすい。Dvorakは素のままのDvorakを使える環境が手に入るまでお預けとしたほうがいいだろう。

参考

*1:無刻印キーボードを使える人は刻印があろうとなかろうと使用感に差は感じないんじゃないかと思わなくもないが、これは黙殺する

*2:https://upload.wikimedia.org/wikipedia/commons/d/da/KB_United_States.svgを編集して使用した

*3:https://upload.wikimedia.org/wikipedia/commons/2/25/KB_United_States_Dvorak.svgを編集して使用した

*4:同上

*5:同上