OSCのLTなどいろんなところで話していた「アセンブラ短歌」に関してですが,アセンブラ短歌の書籍が無事に先行予約開始になりました.

31バイトでつくるアセンブラプログラミング ~アセンブラ短歌の世界~

マイナビで特集ページも組まれています.

普通の解説書では飽き足らないあなたのために - Mynavi Advanced Library


KOZOSのブログ


内容はまあ,アセンブラ短歌です.笑
「アセンブラ短歌」を知らないかたのために一言で説明しますと,「五・七・五・七・七の三十一バイト(みそひとバイト)から成る 機械語コードでプログラムを書いてみるという近未来の文化的趣味」というものです.

「なんの意味があるのか?」と言われるとまあ面白いから,という感じなのですが,いちおう技術的な意味もあります.アセンブラ短歌のホームページ の「アセンブラ短歌の意義」で説明しているのですが, 実はセキュリティ教育の意味があったりします.というのはまずアセンブラを理解することや,加えてこのような特定のバイト数でプログラムを書いたり,決まった制限の中でプログラムを書く技術というのは,脆弱性をついて送り込まれる攻撃コードを理解するために有用だからです(そして防御のためには,攻撃手法をまずは理解することが重要).ところがアセンブラ・プログラミングは空洞化してしまった技術分野で,勉強するのがちと難しくなっているように感じます.とくに「遊び感覚で,楽しく勉強する」という題材が少なく,とっつきにくいイメージがあります.そういう現況を打破するために考案したのが「アセンブラ短歌」です.


書籍中ではx86アセンブラの簡単な解説と説明から始まり,文字列を出力するだけの簡単なアセンブラ短歌から,徐々に高度なプログラム(というか,短歌)を扱っています.特定の命令を各句の末尾に(しかも,意味のある命令を)置くことで韻を踏んでみたり,短歌でなく川柳(川柳は5・7・5)を作ってみたり,電卓もどきを作ってみたり,かるたを作って競技用に難読化してみたり,Quineをやってみたり,内容は様々です.

アセンブラというと難解なイメージがありますが,実は書籍中で使っているアセンブラ命令は数少なく,内容的にもそれほど複雑なプログラムになることもなく(所詮31バイトのプログラムなので),初心者が遊び感覚でアセンブラを学習する良い題材になるかと思います.

アセンブラの解説書は多数ありますが,なんだか難しくてとっつきにくいなあ,読んでても眠くなっちゃうし,もっと遊び感覚でできないかなあ,という初心者のかたにぜひ読んでいただければと思います.

とはいってもまああくまで遊びで,遊びなのだけどそれが勉強にもなればそれって良い趣味になるよね! って感じの考えです.なので「これでほんとに勉強になるのか?」「実用的か?」などあまり肩肘はって考えず,なんか面白そうくらいの感覚でやってみていただければと思います.やってみると,独特のパズル感覚があって実際結構面白いし熱中します.必死になって命令セットを調べたりするので,勉強にもなります.笑 なので初心者に限らず,フツーにアセンブラ使っているよ,というかたもぜひどうぞ.

メインは私が書いていますが,今回は共著で書かせていただいており,執筆陣がなかなか豪華です.セキュリティ・キャンプでお馴染み,最近は「たのしいバイナリの歩き方」でも有名な愛甲健二さん,SECCON実行委員で活躍中のネットエージェントの松田和樹(eagle0wl)さん,Shibuya Perl Mongersやセキュリティ・キャンプ,SECCON実行委員長など広範囲に活動されている竹迫良範さんらにも書いていただいています.書籍ホームページで目次を見ていただければわかるのですが,それぞれの得意分野で,64ビット環境でのアセンブラ短歌や6502でのアセンブラ短歌,MS-DOSでのアセンブラ短歌,表示可能文字だけを使ったアセンブラ短歌など書いていただいてます.(とくに松田さんの,「エクストリーム・アセンブラ短歌」がすごい)

あとメインはLinux/x86をターゲットにしているのですが,組込み向けにRXマイコンでのアセンブラ短歌や68HC11でのアセンブラ短歌なども扱っています.なので組込み系のかたもぜひ.

2011年にSoftwareDesign誌で連載していた「全国津々浦々! 勉強会&イベント探訪記」が電子書籍になりました.とはいっても9月末に出版されているので,すでに2ヵ月前の話なのですが.

KOZOSのブログ-イベント探訪記カバー

「全国津々浦々! 勉強会&イベント探訪記 完全版」の出版社のページはこちら


内容は,まあ全国旅日記の勉強会版です.全国各地のいろんな勉強会に参加して紹介しています.「勉強会ってどんな感じ?」「勉強会に行ってみたい!」と思っているかたは参考にどうぞ.連載時に読んでいただいたかたも,写真がカラーになりカット記事を収録して書き下ろし章も追加されているのでぜひどうぞ.価格は雑誌で既出の内容ということで,500円と安めにさせていただきました.(700ページ弱なのでだいぶお得価格かと)

勉強会の紹介とは言っても単なる参加レポートではなく,私自身が出展や発表をすることで,舞台裏みたいなものを多く紹介するようにしています.また現地での人との繋がりや,往路・復路,食事,懇親会の様子なども紹介することで旅日記っぽくしています.とくに食事は雑誌では(技術誌なので当り前ですが)カットになったものが多かったのですが,今回収録できたのでよかった.

書籍の紹介にもありますが,連載時には誌面の都合でカットされた写真や記事をすべて収録しています.感覚的にはだいたい5割増しくらいかなあ.電子書籍なので,写真もすべてカラーです.

さらに書き下ろしの章を追加しています.新章では6月のオープンソースカンファレンス名古屋 と,6~7月の間で2回行われた SECCON の問題作成合宿の様子を紹介しています.国内最大規模のセキュリティカンファレンス・SECCONのCTF問題はこうして作られています!

今回は技術書の電子書籍で有名な達人出版会 にお願いしたのですが,達人出版会の電子書籍はいわゆるDRMフリーのため,好きな端末で読めます.PCでもスマフォでもOKですし,(もちろん個人の利用の範囲で)自由にコピーできるので便利ですね.私はKindle端末と楽天koboとFreeBSDのPCで読んでます.DRMフリーいいわ~.とっても便利.

フィーリングで読むアセンブラ入門の執筆がひと段落したのだけど,そもそもなんで本を書くのか,ということをあらためて考えてみよう.まあいつもどおり思うまま,つらつらと書いてみる.そして長文.笑

ぼくの場合は改訂版も含めると技術書を出すのも7冊目で,うち新刊で単著のものが5冊目になる(他は共著が1冊と改訂新版が1冊).まあそこそこの数にはなってきたかと思うのだが,ぼくにとっての本を書くことはすでにライフワーク化している部分もあって,書けるものならば書き続けたいし,書く先が無くなっても探してなんらかの形で書き続けたい.書きたいネタも現時点で10冊ぶんくらいはたまっていたりもする.時間があれば,ホント,もっと書きたい.

しかし実際のところ,技術書を書くことには金銭的なメリットがそれほど多いわけではない.たまにまあ世間話で「印税があっていいですね」的なことを言われることもあって,まあそうですねーくらいで別にそれがイヤとか思うこともないのだが,印税って別に何もしないで勝手に入ってくるものではなく,そもそも労働の対価がかなりの期間をおいての後払いで分割で少しずつ支払われているということであって,それほど効率の良い労働のしかただとは思わない.しかも倍の時間をかけて書けば倍の収入があるというわけでもないので,手をかければかけるほどむしろ時給は下がるという側面もあったりする.時間をかけて丁寧に書いたり高度なことを書いたりたくさんの知識を詰め込んだりすることが,経済活動という点でのみ考えると,逆に効率悪かったりするわけだ.

そもそもそんなに儲かるようなことならば,もっとみんなやっていてもおかしくは無いわけで,まあ逆にいうと,だからこそ誰もあまりやっていないのでやりやすいという利点もあるのだが,なので技術書の執筆にはお金以外の別のなんらかのモチベーションがあるということでそれは人によっても違ってくるかと思うわけで,まあぼくの場合もいくつかの理由とかがあるわけです.

ひとつは,単純に勉強になるということだ.勉強のために技術書を読むというのはまあ当然のことなのだが,本を読んでする勉強というのは,ある意味誰でも知ることができる知識ということでもある.もちろんそれを別に意味が無いとかバカにするとかいうことではなく,それはそれで大切なことなのだけど,本に書いてあるという時点で,他人と差別化はしにくい知識でもあるといえる.これはネットとかで検索すれば得られる知識も同様で,ネットでなんでも知ることができるとかネットが万能ということは,少なくともぼく自身はそのようなことは無いと思っている.ほんとうに知りたいことというのは,本にも載っていないしネットで検索しても出てこないものだ.

なので他人と差別化するための,つまりあまり知られていないようなことを知りたいとすると,自分で手を動かしたり実際にいろいろやってみるしかない.そしてそんなようなことをいろいろ家で細々とやっていると,そのうち本を1冊書けるような知識は自然とついてくる.なぜならそれはいままで本に載っていない,自分で調べて考えることで得られた知識だからだ.

こういう知識はオンリーワンの技術者になるための効果的な武器になると思うので,ぼく自身はそういう知識を身につけるためにとにかく手を動かしたい.今までぼくがやってきたFPGA関連とか組込みOS関連とか今回のアセンブラとかは,まさにそんな感じだ.まあそれらのことが仕事に役立っているかどうかはわからないが,家で勝手にやっていることだし,勉強になっていることは間違い無いのでそれはそれでよし.笑

で,そんなふうにいろいろ手を動かして,自分用のメモ書きとかをまとめたりしているうちに「これって本にできるんじゃねーの?」みたいな感じになってくる.今まで書籍になっていなくてなかなか調べづらい分野だったりもするので,自分が本にすることで他の困っているひとたちのお役に立てたり,産業発展の助けになることができれば,とも思ったりする.ていうか本が無くて自分が面倒な思いをしたりしていることに,「なんで本がねーんだよ!」とかイライラしてきてじゃあ書くか,となったりする.笑

そんなわけでその後は執筆自体が勉強になるというか,勉強しながら執筆もしてしまうというか,そんな感じで家での勉強作業が徐々に執筆のほうにシフトしていく感じが多い気がする.そういう勉強というモチベーションで進めると,長く続けることもできるかと思う.なので実は書き始める段階ではズブの素人だったりもしたりするのだが,書いていくうちに徐々に知識がついていくという場合も多く,執筆自体がたいへんな勉強になっているのは間違い無く,なので執筆活動は,ぼくにとってはアウトプットでなくインプットであったりもする.

趣味を良い形で世間のために役立てたい,というのもある.

研究者や技術者の仕事に対するモチベーションって,いわゆるマンガで出てくるマッドサイエンティストのような「バカな世間なぞ無視して自分のやりたいことを好きにやっちゃうぜ.うっしっし」みたいのって実際はあまり多くはなくて,ほとんどは「自分の好きな研究や開発をやりたいから,勉強してそういったことをできるようにしたい.そしてその『自分のやりたい研究や開発』が世間のお役に立てるのならばそれはとっても幸せだしみんながハッピーになれるので,社会のためになれればいいなあ」ってのが多いかと思う.

ぼくもまあそんな感じで,本というか文章を書くことはけっこう好きなことであって(子供のころは小説家になりたかった),趣味で技術書を書いているような部分も多い.あまりお金がかかるということもなくPCが1台あればできるので,書籍に限らずブログやホームページや日記でもなんでも文章を書くというのは,生産的ななかなか良い趣味だとも思う(別に他の趣味が悪いというわけではないが).そして何かを褒めたり何かを伝えようとしたりする文章が個人的にはとても好きなので,そういう文章を書きたい.

そしてそれが世間のお役に立てるのならば,それはそれでとても良い趣味といえるんじゃないかなあと思うわけです.まあというかそうなるように,自分のモチベーションとか環境をなんとかコントロールしながら書くように心がけていたりもする.執筆がそういうふうになれば,誰も損したり不幸になったりしない,みんながハッピーになれてもしかすれば応援もしてもらえたりするとても良い趣味,と言えるからです.

あと,およばずながらも国内のコンピュータ技術の発展のために役立てれば,というのもある.

最近はコンピュータやインターネットもインフラとして確立して,それらを利用した応用技術が脚光を浴びることが多い.しかしやっぱりつぶしが効いて,揺るぎ無く役に立つのは基礎技術だ.

基礎技術があって応用するのと,応用技術しか知らなくて使うのとでは全然違う(と思う).ほんとうに斬新な発想とかアイディアとかは,基盤となる基礎知識があってこそ,出てくるものだと思う.ちなみにこれは別に他人がどうこうとかみんなそうしなきゃダメだよとかいうことではなく,自分に対する戒めです.

基礎技術が無いと,思いついたことがほんとうに新しいことなのか判断できないし,アイディアを膨らませたり,問題点などがあってもそれを回避したりすることができないからだ.実際ぼく自身も,あまり基礎を知らないような分野では,誰でも思いつくようなありきたりのアイディアしか出てこなかったりというのを実感している.

だからぼくはとにかく基礎技術をつけることに興味とかモチベーションとかがあって,そんなわけで大学の専攻的にも会社の仕事的にも本来まったく専門ではないコンピュータ・アーキテクチャの話とか,組込みシステムの話とか,OSの内部構造の話とかが好きだったりする.ぼくはソフトウェア技術者なので,そのあたりが基礎技術になるのかなあ,と思う.

そして基礎技術がしっかりと普及するためには,国産の良質の書籍が多くあることがとても重要だと思う.まあぼくの書いた本が良質かどうかはぼくではなく読者のかたがたが判断することではあるが,良質とか有意と思ってもらえるような本を書いていきたい.

大学の講義とかも重要だしそういったものを否定するものではないのだが,ただそれだけだと情報科の学生限定の話になってしまう.書籍ならば本屋に行けば誰でも買って勉強することができる.ぼく自身も情報科とかの出身ではなく本で勉強したクチなので,なおさらそう思うわけだ.

あとは自分が今までいろんな技術書にとてもお世話になっているので,自分もなんらかの形で知識をアウトプットすることで誰かのお役に立てるのなら,という思いもある.恩返しというと大げさかもしれないが.

お世話になった人やモノに対して,感謝としてその人やモノにお返しをするのはいいことだと思う.しかしそれとは別に,今度は自分が誰かのお役に立つことでその感謝を他人にリレーしていくことができれば,それは間接的な恩返しとして,とてもいいことだと思う.若いうちに先輩にさんざんおごってもらったならば,何かのときにその先輩にお返しをするのもいいことだけど,それよりも今度は自分が後輩におごってあげるようにしたいという考えだ.そういうのはおごった先輩からしても,とても嬉しいものだからだ.

ぼくも若かりしころ,当時の先端を走っている技術者のかたたちに憧れて勉強した.まあ月並な言いかただが夢とか希望とかいったものをもらったわけだ.まあそれは今でもあまり変わっていなかったりもするのだが,なのでそういったかた達にとても感謝しているところがある.

しかし今はそれに加えて,できることならばそろそろ自分も他人に憧れるだけではなく,そういう憧れられる立場になっていかなければいけないというか,なれるならばそうなりたい,という思いがある.まあ実際になれているかどうかは別としてという注釈つきだが.笑

これは「自分が尊敬されたい」ということではなく,自分がいろいろなかた達に与えていただいた夢とか憧れとか感謝という気持ちを,感謝としてそのかた達に返すのではなく次に伝えていくことが,最大の恩返しになると思うからだ.憧れの対象とか憧れられる存在というものが若いひとにはとても重要だと思う.(自分がそうだったので,そう思う)

だからぼくは現役の技術者として,技術者になってよかったといわんばかりに,楽しそうに仕事をしたりモノづくりをしたり,面白い活動をしたりしたいという思いがある.そしてそういう楽しそうなのを若い人たちに見ていただいて,若いひとたちが技術職というものに憧れて,がんばって勉強したりするためのきっかけになることができれば最高かなあ.別にぼく自身に憧れてほしいということではなく,技術職というものに憧れてほしい.

そんな理由もあってぼくはオープンソースカンファレンスに出展するとか勉強会で喋るとか,そんな活動もしたりしている.勉強会とかで現役の技術者が自分の好きなモノを紹介したり,オープンソースカンファレンスとかでいろいろ楽しそうにやっていたり,面白そうなモノづくり活動をしたりしているのは生産的でとても素晴らしいことだとも思うし,技術者がそういうふうに活気あって楽しそうにいろいろやっているのを,現役の技術者のかたや若いひとたちや学生のかたがたにもぜひ見ていただければとも思う.まあもちろんぼくが勝手に思っているというだけで,ぜひ見ろといったり強制したりするようなものではないのだが.

書籍執筆にもそういう考えの理由があったりもする.本を書くことは,いろんな人との出会いや勉強や気づきがあって楽しいものだ.そんなようないろんな活動をしていると,技術職っていうのは活気があってとても面白い職種だと思えるんじゃあないかなあと思う.だから本を書いたり勉強会で喋ったりすることは,同じ技術職のかたや若い技術者のかたや技術職を目指している学生のかたに個人的にはおすすめしたいなあとも思う.

技術者は元気に,楽しそうにモノを作ってほしいと思うし自分はそうしたい.
そしてそうして作られたものを,愛着を持って長く大切に使いたいと思う.

「フィーリングで読むアセンブラ入門」(http://kozos.jp/books/asm/)ですが,本日無事に原稿を送付し脱稿しました.本来は年末に脱稿の予定でしたがなにせページ数が多く最終チェックに長引き,正月休みで何とかまとまりました.いろいろ情報提供していただいたかた,応援していただいたかた,どうもありがとうございました.あとは(赤入れがありますが)出版されるのを待つばかりです.

内容としては,まずは簡単なサンプルプログラム(1関数が数行程度)をコンパイル・逆アセンブルして生成されたアセンブラを読んでみて,必要に応じてバイナリエディタで機械語コードを直接書き換えたりして逆アセンブラがどのように変化するのかを見て,試して,推測して,という感じです.C言語でただ返るだけの関数とか,ただ1を返すだけの関数とか,最初はそういうのから始めて,徐々にいろいろなものを見ていきます.

あまり資料は調べずに,逆アセンブルで得られた現物をベースにして,推測とフィーリングでテキトーに読んでいきます.推測は,ホントに多いです.資料をカッチリ調べたりして読むタイプの書籍ではないです.というのはアセンブラの説明というとまんまデータシートみたいなものも多く(そして実践的な書き方がわからず理解しにくい),そういうものはすでにあるし,そういう路線にはしたくなかったからです.なにせ「気軽にパッと読む」という路線にしたかった.

なのでそういうテキトーなのが許せなかったり,ダメなひとはダメかもしれません.もしもそうだったり期待外れだったりしたらゴメンナサイ.

アセンブラは40種類について言及しました.とはいってもビット数を変化させて出力させたものや同じ系列のアーキテクチャなどもありますのでISAとしてホントに40種類というわけでもなく,またあまり深く説明せずに軽く流しているだけのものもありますが,ひとまず以下については触れています.

第1部でアセンブラの基礎として説明しているもの

PowerPC, MIPS ... 導入部分で題材として利用 (読みやすいため)
ARM, SH ... その他の固定長命令のプロセッサの例として説明
H8/300, i386 ... 可変長命令のプロセッサの例として説明

第2部でTips的に説明しているもの (ただし簡単に流しているものもあり)

SPARC, PA-RISC ... RISC系CPU
Alpha, PowerPC64, MIPS64, SH64, x86-64, IA-64, MMIX ... 64ビット・アーキテクチャ
M32R, V850, i960, MN10300, FR30, FR-V, Xtensa ... 組込み向け32ビットマイコン
AVR, Xstormy16 ... 組込み向け低スペックマイコン
68HC11, 68000 ... 昔ながらのマイコン
VAX, PDP-11 ... 往年のミニコンのCISC系コンピュータ
S/390 ... メインフレーム系
MIPS16, ARM(Thumb) ... 縮小命令セット
AVR(8bit), 68HC11(16bit), H8/300H ... ビット幅を変化させてアセンブラ生成
StrongARM, XScale ... ARM系
ARC, CRIS, M・CORE ... よく知らないアーキテクチャ (を,とりあえず読んでみた)

さらにMIST32という,つくばの学生が開発した独自アーキテクチャについても触れています.これについては伊藤君と川田君にいろいろ協力していただきました.ありがとうございました.

http://open-arch.org/

またAlpha向けビルド用パッチやPDP-11,その他アーキテクチャに関して,七誌さん(http://7shi.hateblo.jp/)にいろいろ情報をいただきました.ありがとうございました.

また写真提供で協力していただいた@hasegawさん,@syuu1228さん,OSC事務局のかたがた,ありがとうございました.CQ出版社のInterface誌とTECH-Iには執筆の上でかなりお世話になったので,参考文献にいっぱい載せさせていただきました.また秋月電子のマイコンボードやInterface誌付録基板にも感謝です.翔泳社の編集Uさんも,ありがとうございます.そしてどうぞよろしくお願いします.

今回,このような本を書くことでぼくとしてはたいへん勉強になりました.いろんな歴史的な経緯やアーキテクチャとしての思想など,勉強することがホントに多かったなあと思います.なので1年半もかかってしまったわけですが,そんなわけでまあしばらくは執筆に専念して外に出ていく活動ができていなかったので,今後はまたいろいろ復活させたいです.今回のことでいろいろネタもできたことだし,とりあえずはIT基礎技術勉強会でアセンブラ大会かな.

自宅のPCはFreeBSDでデュアルモニタで利用している.Xでデュアルモニタを使う方法はネットで調べるといろいろ出てくる.

nvidiaのドライバを使う方法とかもあるがグラフィックチップ依存になるのでなるべくならXの設定のみでなんとかしたい.
xorg.confにはXineramaというオプションもあってこれだとディスプレイ2台を1枚の巨大なスクリーンとして使えるのだがこれはウィンドウマネージャが対応しているかどうかによっているらしく,そしてほとんどのウィンドウマネージャは対応していないようだ.

なのでXinerama未指定で普通にスクリーン2枚として使っているのだが,でもこれだとちょっと使いにくい部分があるので設定を改良してみたのでメモがてらブログに書いておく.

まずXineramaオプション無しでスクリーン2枚で使うような設定だと,マウスカーソルが画面端にいったときに(xorg.confでScreenの設定をLeftOfにしているなら,マウスカーソルが画面左端にいったときに)スクリーンが切り替わる.しかしこれがAfterstepの仮想画面と相性が悪くて,ゆっくり移動するとAfterstepの仮想画面が切り替わるが速く移動するとスクリーンが切り替わる,みたいな動作になってしまってとてもうっとうしい.

ということで,マウス移動ではスクリーンは切り替わらない(Afterstepの仮想画面のみ切り替わる)ようにして,さらに右Altキーでスクリーンが切り替わるように設定する.

まずマウス移動でスクリーンが切り替わらないようにする設定.xorg.confに以下の修正を入れてスクリーンの位置を離すことで,スクリーンを隣接させないようにする.もしかしたら何かオプションとかでできるのかもしれないが調べてもみつからなかったので,(あまりきれいなやりかたじゃないが)とりあえずこれで対応しておく.
 Section "ServerLayout"
Identifier "X.org Configured"
Screen 0 "Screen0" 0 0
- Screen 1 "Screen1" LeftOf "Screen0"
+# Screen 1 "Screen1" LeftOf "Screen0"
+ Screen 1 "Screen1" Relative "Screen0" 10000 0
InputDevice "Mouse0" "CorePointer"
InputDevice "Keyboard0" "CoreKeyboard"
Option "AutoAddDevices" "false"

さらにxbindkeysとxdotoolをpackagesでインストールする.xdotoolはマウス移動などのイベントを発生させることができるツールで,実はxautomationというツール(に付属するxteというツール)でも同等のことができるが,xdotoolにはスクリーンを切替えたりスクリーン番号を取得したりする機能があるので,こちらを利用する.

で,以下のようなスクリプトを chgscreen.sh として作成する.実行するとスクリーンを切替えることができる.
#!/bin/sh

OLDSCREEN=`xdotool getmouselocation | cut -d " " -f 3 | cut -d : -f 2`
XPOSITION=`xdotool getmouselocation | cut -d " " -f 1 | cut -d : -f 2`
YPOSITION=`xdotool getmouselocation | cut -d " " -f 2 | cut -d : -f 2`

NEWSCREEN=`echo "1 - $OLDSCREEN" | bc`

#echo $OLDSCREEN
#echo $XPOSITION
#echo $YPOSITION
#echo $NEWSCREEN

xdotool mousemove --screen $NEWSCREEN $XPOSITION $YPOSITION

スクリプト実行してスクリーンが切り替わることを確認する.さらに以下のような内容で.xbindkeysrcを作成する.
"/home/hiroaki/chgscreen.sh"
Alt_R

"/home/hiroaki/chgscreen.sh"
Control+Return

xbindkeysを起動し,右AltもしくはCtrl+Enterでスクリーンが切り替わることを確認する.

xbindkeysを起動するように.xinitrcに追加.これで完了.