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/下の
を編集しXを再起動、そのあと「KDE システム設定」からハードウェア→入力デバイス→キーボードに飛び、キー配列タブから新たに追加したキー配列を加える。
経緯
唐突だが私は無刻印キーボードとDvorakに憧れている。ふつうの刻印キーボードだとソフトウェア的にキー配列を変更した場合ハードウェアとソフトウェアとで入力に差異が生じて訳が分からなくなるが、無刻印キーボードだとそんなことはない。刻印に支配されない環境はさぞかし過ごしやすかろうと思う*1。Dvorakに憧れている理由は、打ちやすいという評判を知ったのと、キーボード左側に記号入力のキーが配置されてるのがエキゾチックな感じがしたためだ。
で、刻印のあるキーボードでキー配列を変更する場合にキーボードのほうを如何とするかという問題の解決法はいろいろあって、キーをバラして入れ替えるとか、インレタやシールなどで新しいアルファベットをキーに振るというものがある。見栄えがいいのは明らかに前者なのだが、キーボード単体の場合はともかく、ノートパソコンのキーボードでこれをやろうとするとうまくいかない事が多いように思う。私が使用しているThinkPad X200の場合、トラックポイントを採用している都合上G、H、Bキーがトラックポイントにあわせてエグれており、かつFキーとJキーはホームポジションの目安のためにキーに出っ張りが有り、かつパンタグラフの形状が他のキーのそれと違うために他のキーとの入れ替えが不可能なのだ。
で、これを物理的に組み替えてDvorakをやろうとすると、
としたいのに
となってしまうのだ。さらに付け加えれば上図でF、J、U、Hキーは嵌らず脱落した状態になるだろうし、I、D、Xキーはトラックポイントとの干渉箇所を整形しなくてはならない。
ならば、ソフトウェアのほうをハードウェアの都合に合わせてしまえばいいのではなかろうか、つまり、下図のようなキー配列をでっち上げてしまえばいいのである。
実践
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/ 下の
を編集する必要がある。*.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:同上
Pig Latinをするプログラム書いた
Pythonでどれくらい書けるようになったかを試したくなったのとPig Latinで遊びたくなったのとを兼ねて書いてみた。Pythonの特徴を活用できていない感じがある。
Pig Latinについてはhttps://en.wikipedia.org/wiki/Pig_Latinを参照のこと。
（2014-06-01 編集：オブジェクト指向っぽくした）
動作
$ echo "The quick brown fox jumps over the lazy dogs" | python PigLatin.py ethay uickqay ownbray oxfay umpsjay overway ethay azylay ogsday
CodingBatで悩んだ問題に対するメモ書き（其の一）
2014-05-17 追記
はてなブログの LaTeX 数式表示がデフォルトで MathJax 化された - 余白の書きなぐり ということなので、記事中の数式の書き方をなおした。本文も少し修正した）
「其の一」とか書いたが続編なんか書きたくないぞ。
最近、Pythonを勉強しようと思い、CodingBatで問題をちまちまと解き続ける生活をしている。今週の日曜日（12月15日）からはじめて現在Logic-1まで解き進めた。Logic-1までは対して悩むこともなく解き進められたのでこの調子でLogic-2も解いて行こうと挑戦してみたら早速第1問目(CodingBat Python Logic-2 make_bricks)で詰まってしまった。
以下問題（と拙訳）。
We want to make a row of bricks that is goal inches long. We have a number of small bricks (1 inch each) and big bricks (5 inches each). Return True if it is possible to make the goal by choosing from the given bricks. This is a little harder than it looks and can be done without any loops.
goalインチの長さの煉瓦塀を作りたい。小さい煉瓦（各1インチ）と大きい煉瓦（各5インチ）がいくらかある。用意された煉瓦から適当に選び出して［注：用意された煉瓦全部を使わなくてもよいということだろう］目標の長さの煉瓦塀を作れるならTrueを返すようにせよ。この問題は見た目よりも若干難しい。それと問題はループなしで解くことが出来る。
最終的には偶然が重なって解けたし答えの理屈もきちんとわかったので問題は解決している。しかし、この「わかった」内容をどこかに控えておかないと、たぶん寝て起きたら忘れてしまうだろうし、同じ問題でまた詰まってしまうのは避けたい。
というわけでここに控える。はじめに断っておくとCodingBatでも言っているように他に解き方がいっぱいあるだろうし、私の解き方が最もふさわしいなんて言うつもりも全く無い。自分用のメモとして残しておくものである。
始めの一歩
小さい煉瓦が個、大きい煉瓦が
個あるとして、長さ
の煉瓦塀を作ることを考える。煉瓦をすべてを使う必要はない。
考え方は、大まかに大きい煉瓦で煉瓦塀をつくっていって、細かい調整は小さい煉瓦で行うという方針になる（書くまでもないだろうけど）。
場合分け
まずとなる場合は明らかに長さ
の煉瓦塀を作れないのでFalse。この場合
と
の値にもよるけど、煉瓦塀を作っていたら大きい煉瓦は与えられた個数を使い切ったが、最後の最後で小さい煉瓦の数が足りなくなった、というものに相当する。大きい煉瓦の数は足りていた、煉瓦塀の長さの端数が問題になった、というような感じか。
次にとなる場合、これは大きい煉瓦が余ってしまうという場合に相当する。よって小さい煉瓦の数が重要になってくるわけだが、小さい煉瓦を5個集めると大きい煉瓦1個と等価であることを考えると、
（剰余）と
を比較して
ならFalseとすればよい。つまり
に対して
が十分なだけあれば煉瓦塀は作れるという意味になる。
最後に、(2)は満たすが(3)は満たさないというと
の組み合わせが求めるべき数の組み合わせであるので、このような入力の場合はTrueを返すようにする。
プログラム
一応。
Distccを使って余剰PCで分散コンパイルする&してみた結果
例えばMozcを使いたいなと思った時、Arch LinuxにおいてMozcはAURにあるので導入にはソースコードからのコンパイルから始まるパッケージの作成が必要である*1。このコンパイルという作業だが、周知の通りマシンスペックによっては時間のかかる作業で、コンパイルが始まったが最後終わるまで待つ必要がある。コンパイルを早く終える手っ取り早い方法は高性能のパソコンを使うことだが、おいそれと高性能マシンを買えるんだったらそもそも問題にならない。しかし、高性能マシンを買う余裕はないが、今までに乗り換えてきたパソコン達が目に付くところに転がっている。このホコリを被って放置されているパソコンを使って分散コンパイルすれば、手っ取り早く、お金を掛けずにコンパイルをさっさと終わらせることができるのではなかろうか。
というわけで、Distcc(https://code.google.com/p/distcc/)というソフトウェアを使って、Mozcを分散コンパイルしてパッケージを作成してみた。加えて、makepkgの設定ファイルである/etc/makepkg.confを編集し、Distcc、Ccache、MAKEFLAGSの設定によってコンパイルにかかる時間がどれだけ変わるかを参考までに計測してみた。
あらかじめ言及しておくと、それっぽい感じのタイムが出なかったので、環境に不備がある可能性がある。データは参考までに。
今考えると分散コンパイル試すだけだったらMozcじゃなくてよかった。もっと手軽なやつにしとけばよかった。
ちなみにCcacheというのはgcc向けのワンダフルなツールである*2。
使用マシン
環境
makepkg関連
- PKGBUILD
- mozc-ut(https://aur.archlinux.org/packages/mozc-ut/)のPKGBUILDに以下の変更を施したもの。
結果
ccache、distcc、MAKEFLAGSの内、容を適宜以下の表のように変更して、それぞれの場合においてのコンパイル時間を計測した。時間の計測にはtimeを使用した。
なお、時間の計測は一回限りである。前述の通り、データは参考までに。
| ccache | distcc | MAKEFLAGS | 時間［秒］ |
|---|---|---|---|
| 875.36 | |||
| ○ | 438.30 | ||
| ○ | -j6(=3+3) | 439.66 | |
| -j3 | 950.98 | ||
| ○ | -j3 | 396.67 | |
| ○ | ○ | -j6(=3+3) | 395.84 |
| ※ | ○ | -j6(=3+3) | 451.69 |
ccache、distcc、MAKEFLAGSを効かせた場合が最速なのはいいとして、それがdistccを無効にした場合と1秒差というのはどうなんだろう。それと何も有効化していない場合よりもMAKEFLAGSを設定したほうが遅いというのも納得がいかない。2,7Mbpsという通信速度もボトルネックになっている気がする。
再計測の余地がある。
結論
Distcc便利。
*1:pnsft-purを使えばバイナリが手に入る(https://wiki.archlinux.org/index.php/Mozc)けど出オチなので見なかったことにする。
uimで./configureに--enable-kde4-appletとか--enable-notify=knotify4をつけるとコンパイルに失敗する事案の解決法
結論
automoc4とcmakeをインストールすればいい。
蛇足
cmakeのほうはhttps://code.google.com/p/uim/wiki/InstallUim#Installing_required_packagesをみればわかるのだけれど、automoc4は必要とされるパッケージとして挙げられてないので忘れがち。でもautomoc4はcmakeに必要なパッケージだし、よく考えてみれば気付くはずだからわざわざ書くようなことはしてないのかもしれない*1。
Arch Linux公式のuimでは前述のオプションは無効化されており、これを使うにはabsからPKGBUILDを取得して編集し、パッケージを作らなきゃならない。そういう事情のため、uimのPKGBUILDにおけるdepends欄やmakedepends欄にはautomoc4及びcmakeの記述はない。ストレスなくuimのパッケージを作るには前述の要項をPKGBUILDに加えるパッチをつくるとよい。
*1:私は気付かなかった
QtEmuで設定できる仮想マシンのRAMの上限を拡げる
2013-09-23 追記
本文中で触れているgendeskをbuild()から呼び出す方法ではうまくいかないというのはgendesk 0.5.4におけるバグであったようだ。現在は0.5.5になり、バグも修正された(https://github.com/xyproto/gendesk)。本文での言及箇所には打ち消し線を引いた。
QtEmuというのはQEMUをGUIで扱うためのソフトウェアだ。
QtEmuで仮想マシンをいじくるとき、RAMを1024MBまでしか割り当てられないのがけっこう不満だった。ある機会があってVirtualBoxを使った時、こいつはシステムが許す限りのRAMを割り当てることができて、RAM割り当てたい欲を満足することができた。
QtEmuが仮想マシン管理のためにつくるXML（<仮想マシン名>.qte）のmemory要素をいじくってみても変更は反映されず、どうしたもんかなあと悩んでいたが、先程、ソースコードをいじればいいのだという着想を得た。得るのが遅すぎる。
とりあえずQtEmuのソースを落としてきて、"1024"MBの制限を掛けているということから
$ find . -name '*.cpp' -print | xargs grep 1024
で全文検索を掛けた結果、machinetab.cppがそれらしいという反応を得た。このファイル中の1024を軒並み4096に変更したら、仮想マシンに4096MBまでRAMを割り当てることができるようになった。RAM割り当てたい欲を満たすことができるようになった。
パッチを書いた。手で書き換えるよりはマシだと思う。
自動的にこのパッチをあてて、https://wiki.archlinux.org/index.php/DeveloperWiki:Removal_of_desktop_filesに沿ったgendeskを行うためのPKGBUILD用パッチも書いた。
このgendeskだが、https://wiki.archlinux.org/index.php/DeveloperWiki:Removal_of_desktop_filesとhttps://wiki.archlinux.org/index.php/Desktop_Entriesで扱い方が異なっているのだけれども、どちらがよいのだろう。prepare()から叩くほうがわかりやすいかなと思うのだけれど。あとbuild()から叩いた場合うまく動いてくれず、prepare()からだと動いた。環境依存かもしれず怖い。
